Routing Protocols Con Guration Guide

Tellabs
8600 Smart Routers

Routing Protocols Conguration Guide
76.8600-50121F
13.01.2014
Document Information
Revision History
Document No. Date Description of Changes
76.8600-50121F 13.01.2014 Renewed related documentation table in Tellabs 8600 Smart
Routers Technical Documentation.
Added ECMP support in ELC1 line card in 9 Equal Cost Multipath
(ECMP).
Added 3.9 BGP Failover.
Added support of BFD for single hop BGP in 7 Bidirectional
Forwarding Detection .
Updates applied in 6.1 IS-IS Basic Conguration.
Added a conguration example of 8.1.4 Single Hop BGP.
Added clarication of VRRP multiple instances conguration to
an interface in 10.2.1 VRRP Parameters.
Added ELC1 support of VRRP + IRB and VRRP + ELP in
10.3.1 Implementation.
VRRP master and backup roles corrected in 11.1.2 Router2
Conguration.
Updates and corrections applied in 8.2 BFD Conguration for
Static Routes.
Changes applied in 3.2 BGP Attributes and reworked
3.2.6 COMMUNITY Attribute.
76.8600-50121E 28.08.2012 New Tellabs 8600 brand: Tellabs 8600 managed edge system and
Tellabs 8600 network elements changed to Tellabs 8600 smart
routers.
Related documentation table updated.
Major changes and updates applied to BGP section 3 Border
Gateway Protocol :
Added BGP attributes 3.2 BGP Attributes.
Route policing updates 3.4 BGP Routing Policy .
Renewed 3.5 Route Aggregation and added route aggregation
for VPNs 3.5.2 BGP VPN Route Aggregation.
Renewed RFD and graceful restart in .
Renewed 3.7 Route Refresh.
Renewed 3.8.1 Route Reector and 3.8.2 AS Confederation.
BGP conguration updates and CLI examples layout change from
table to step list in 4 BGP Conguration Examples:
Updates in 4.1 Basic Congurations.
Added route aggregation for VPNs conguration in 4.2 Route
Aggregation Conguration.
Renewed RR and AS confederation conguration examples in
4.3 Advanced Congurations .
Corrections made to 7 Bidirectional Forwarding Detection .
Updates in 9 Equal Cost Multipath (ECMP) and ECMP
9.3.4 Scalability.
VRRP support in ELC1 10.3.1 Implementation.
CLI examples layout change from table format to step list
in: 2 OSPF Conguration Examples; 6 IS-IS Conguration
Examples; 8 BFD Conguration Examples and 11 VRRP CLI
Conguration Examples.
Tellabs
8600 Smart Routers 76.8600-50121F

Routing Protocols Conguration Guide 2014 Tellabs.
2
Document No. Date Description of Changes
76.8600-50121D 02.11.2011 Updated VRRP parameters in 10.2.1 VRRP Parameters.
Added VRRP timers, starting conditions and initial timer values of
a VRRP backup router in 10.2.2 VRRP Timers.
Added tracking delay timer in 10.3.2 Object Tracking.
76.8600-50121C 27.09.2011 BGP overview updates (introduction, BGP peering, managing
route preferences, next-hop attribute and BGP routing policy) in
3 Border Gateway Protocol .
Updated BGP basic conguration examples in 4.1 Basic
Congurations.
Added precautions of avoiding packet loss in VRRP after
mastership role switchover in 10.3.2 Object Tracking.
Added a setup of waiting time after VRRP initialization before
mastership role switchover to prevent unnecessary switchover in
10.3.3 VRRP with IRB.
Added conguration step of setting the waiting time after VRRP
initialization in 11.2 VRRP with IRB Conguration.
76.8600-50121B 25.08.2011 BFD monitoring for static routes 7 Bidirectional Forwarding
Detection . BFD conguration in static routing 8.2 BFD
Conguration for Static Routes. BFD session information
8.2.1 BFD Status.
Virtual Router Redundancy Protocol 10 Virtual Router
Redundancy Protocol. VRRP Conguration 11 VRRP CLI
Conguration Examples.
ECMP routing 9 Equal Cost Multipath (ECMP).
OSPF status and statistics 2.10 OSPF Status .
BGP overview in 3 Border Gateway Protocol and BGP peering
TCP session. BGP next-hop area support 3.2.3 NEXT HOP
Attribute. BGP Policing using communities attribute and
route-map in 3.4 BGP Routing Policy .
Renewed BGP basic conguration (also added BGP conguration
status); added BGP routing policy conguration examples and
updates in BGP authentication, connection reset 4.1 Basic
Congurations. BGP advanced conguration changed AS
numbers.
This revision of the manual documents the following network elements and the corresponding
feature packs or higher.
Tellabs 8605 smart router FP1.6
Tellabs 8607 smart router FP1.1
Tellabs 8609 smart router, Tellabs 8611 smart router FP1.2
Tellabs 8620 smart router, Tellabs 8630 smart router, Tellabs 8660 smart router FP4.1
If you have a different feature pack of Tellabs 8600 products, please refer to the relevant product
document program on the Tellabs Portal by navigating to www.portal.tellabs.com > Product
Documentation > Data Networking > Tellabs 8600 Smart Routers > Technical Documentation.
2014 Tellabs. All rights reserved.
This Tellabs manual is owned by Tellabs or its licensors and protected by U.S. and international copyright laws, conventions and
treaties. Your right to use this manual is subject to limitations and restrictions imposed by applicable licenses and copyright laws.
Unauthorized reproduction, modication, distribution, display or other use of this manual may result in criminal and civil penalties.
The following trademarks and service marks are owned by Tellabs Operations, Inc. or its afliates in the United States and/or
other countries: TELLABS
, TELLABS
logo, TELLABS and T symbol
, and T symbol
.
Any other company or product names may be trademarks of their respective companies.
The specications and information regarding the products in this manual are subject to change without notice. All statements,
information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind,
express or implied. Users must take full responsibility for their application of any products.
Adobe
Reader
are registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Tellabs
8600 Smart Routers 76.8600-50121F

4
Terms and Abbreviations
Term Explanation
ABR Area Border Router
AFI Authority and Format Identier
ARP Address Resolution Protocol
AS Autonomous System
ASBR Autonomous System Border Router
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
CDC Control and DC Power Card
CLI Command Line Interface
CPU Central Processing Unit
CSPF Constrained Shortest Path First
DCN Data Communications Network
DD Database Description
DiffServ Differentiated Services
DR Designated Router
eBGP External Border Gateway Protocol
ECMP Equal Cost Multipath
EGP Exterior Gateway Protocol
ELP Ethernet Layer Protection
ES-IS End System to Intermediate System
iBGP Internal Border Gateway Protocol
ICMP Internet Control Message Protocol
IFC Interface Module Concentrator
IFM Interface Module
IGP Interior Gateway Protocol
IIH IS-IS Hello
IP Internet Protocol
IRB Integrated Routing and Bridging
IS-IS Intermediate System to Intermediate System
LAG Link Aggregation
LAN Local Area Network
LDP Label Distribution Protocol
LSA Link-State Advertisement
76.8600-50121F Tellabs
8600 Smart Routers

2014 Tellabs. Routing Protocols Conguration Guide
5
LSP Label Switched Path
LSP Link State Packet
MAC Media Access Control
MDA Message Digest Authentication
MED Multi Exit Discriminator
MPLS Multiprotocol Label Switching
NBMA Non-Broadcast Multiaccess
NET Network Entity Title
NSAP Network Service Access Point
NSEL NSAP selector
NSSA Not-So-Stubby Area
ORF Outbound Route Filter
OSPF Open Shortest Path First
QoS Quality of Service
RFC Request For Comments (IETF documents)
RFD Route Flap Damping
RR Route Reector
RSVP-TE Resource Reservation Protocol with Trafc Engineering Extensions
RT Route Target
SAFI Subsequent Address Family Identier
SCM Switching and Control Module
SLA Service Level Agreement
SPF Shortest Path First
SOO Site of Origin
TCP Transmission Control Protocol
TE Trafc Engineering
TED Trafc Engineering Database
TLV Type Length Value
VLAN Virtual LAN
VPN Virtual Private Network
VRF Virtual Routing and Forwarding
VRRP Virtual Router Redundancy Protocol
Tellabs
8600 Smart Routers 76.8600-50121F

6
Table of Contents
Table of Contents
About This Manual ............................................................................................................ 11
Objectives........................................................................................................................................................................11
Audience..........................................................................................................................................................................11
Tellabs 8600 Smart Routers Technical Documentation ..................................................................................................11
Interface Numbering Conventions ................................................................................................................................. 15
Documentation Feedback............................................................................................................................................... 15
Tellabs 8600 Rebranding.................................................................................................. 16
Tellabs 8600 Discontinued Products............................................................................... 17
1 OSPF............................................................................................................................. 19
1.1 Overview ............................................................................................................................................................. 19
1.2 OSPF Hierarchical Routing ................................................................................................................................ 20
1.2.1 Autonomous System............................................................................................................................ 20
1.2.2 Areas.................................................................................................................................................... 20
1.3 OSPF Hello Messages and Link-State Advertisements ...................................................................................... 21
1.4 Extensions for Support of Differentiated Services-Aware MPLS Trafc Engineering....................................... 21
1.5 OSPF Graceful Restart ........................................................................................................................................ 21
1.6 Fast OSPF Adjacency Establishment .................................................................................................................. 22
1.7 OSPF Unnumbered Links.................................................................................................................................... 23
1.8 OSPF References................................................................................................................................................. 23
2 OSPF Conguration Examples .................................................................................. 24
2.1 Basic Conguration ............................................................................................................................................. 24
2.2 Interface Conguration........................................................................................................................................ 25
2.3 Area Conguration .............................................................................................................................................. 25
2.4 Authentication ..................................................................................................................................................... 26
2.5 TE Conguration ................................................................................................................................................. 26
2.6 Graceful Restart Conguration............................................................................................................................ 26
2.7 Fast OSPF Convergence...................................................................................................................................... 27
2.8 Fast OSPF Adjacency Establishment Conguration........................................................................................... 28
2.8.1 Enabling Hello replies ......................................................................................................................... 28
76.8600-50121F Tellabs
8600 Smart Routers

7
Table of Contents
2.8.2 Designated Router (DR) Wait Time Conguration ............................................................................. 29
2.9 OSPF Unnumbered Links Conguration ............................................................................................................ 31
2.10 OSPF Status ........................................................................................................................................................ 32
3 Border Gateway Protocol .......................................................................................... 33
3.1 Overview ............................................................................................................................................................. 33
3.2 BGP Attributes .................................................................................................................................................... 36
3.2.1 ORIGIN Attribute................................................................................................................................ 37
3.2.2 AS PATH Attribute.............................................................................................................................. 37
3.2.3 NEXT HOP Attribute .......................................................................................................................... 38
3.2.4 LOCAL PREFERENCE Attribute ...................................................................................................... 39
3.2.5 ATOMIC AGGREGATE Attribute ..................................................................................................... 40
3.2.6 COMMUNITY Attribute..................................................................................................................... 40
3.2.7 AGGREGATOR Attribute................................................................................................................... 41
3.2.8 MED Attribute..................................................................................................................................... 42
3.3 Managing Route Preferences............................................................................................................................... 43
3.4 BGP Routing Policy ........................................................................................................................................... 44
3.4.1 Route Map ........................................................................................................................................... 45
3.5 Route Aggregation............................................................................................................................................... 47
3.5.1 Conguration Parameters .................................................................................................................... 49
3.5.2 BGP VPN Route Aggregation............................................................................................................. 49
3.5.3 Route Aggregation Support ................................................................................................................. 50
3.6 Route Flap Damping............................................................................................................................................ 50
3.6.1 RFD Conguration .............................................................................................................................. 52
3.7 Route Refresh ...................................................................................................................................................... 53
3.8 Increasing AS Scalability .................................................................................................................................... 53
3.8.1 Route Reector .................................................................................................................................... 53
3.8.2 AS Confederation ................................................................................................................................ 55
3.9 BGP Failover ....................................................................................................................................................... 56
3.9.1 iBGP and Multihop eBGP Sessions .................................................................................................... 56
3.9.2 Single Hop eBGP................................................................................................................................. 57
3.9.3 Performance of BGP Failover ............................................................................................................. 58
3.10 BGP Multiprotocol Extension ............................................................................................................................. 58
3.11 BGP References................................................................................................................................................... 59
4 BGP Conguration Examples .................................................................................... 60
4.1 Basic Congurations............................................................................................................................................ 60
4.1.1 BGP Neighbor and Path ...................................................................................................................... 61
4.1.2 BGP Routing Policy Conguration ..................................................................................................... 64
4.1.3 BGP Authentication............................................................................................................................. 66
4.1.4 BGP Connection Reset ........................................................................................................................ 66
4.2 Route Aggregation Conguration ....................................................................................................................... 67
4.2.1 NODE-1 Conguration........................................................................................................................ 67
4.2.2 NODE-2 Conguration........................................................................................................................ 68
4.2.3 Conguration Status ............................................................................................................................ 68
4.2.4 Conguration with Suppression Disabled ........................................................................................... 69
4.3 Advanced Congurations ................................................................................................................................... 70
4.3.1 Route Reector Conguration............................................................................................................. 70
Tellabs
8600 Smart Routers 76.8600-50121F

8
Table of Contents
4.3.2 Conguring AS Confederation ........................................................................................................... 73
5 IS-IS .............................................................................................................................. 77
5.1 Overview ............................................................................................................................................................. 77
5.2 Routing Areas ...................................................................................................................................................... 78
5.3 Addressing........................................................................................................................................................... 79
5.4 Multihoming........................................................................................................................................................ 80
5.5 Multiarea Routing................................................................................................................................................ 80
5.6 Open Shortest Path Algorithm............................................................................................................................. 81
5.7 Adjacencies and Hello Packets............................................................................................................................ 81
5.8 Link-State Database and Link-State Packets ...................................................................................................... 81
5.9 Route Summarization .......................................................................................................................................... 81
5.10 Route Redistribution............................................................................................................................................ 82
5.11 Authentication ..................................................................................................................................................... 82
5.12 Extensions for Support of Differentiated Services-Aware MPLS Trafc Engineering....................................... 82
5.13 IS-IS References .................................................................................................................................................. 83
6 IS-IS Conguration Examples.................................................................................... 84
6.1 IS-IS Basic Conguration.................................................................................................................................... 84
6.1.1 IS-IS Process Conguration ................................................................................................................ 85
6.1.2 IS-IS Interface Conguration .............................................................................................................. 85
6.2 IS-IS Area Conguration.................................................................................................................................... 86
6.2.1 Router 1 Conguration........................................................................................................................ 87
6.3 Fast IS-IS Convergence ....................................................................................................................................... 89
7 Bidirectional Forwarding Detection .......................................................................... 90
7.1 Overview ............................................................................................................................................................. 90
7.2 BFD in Dynamic Routing.................................................................................................................................... 91
7.3 BFD in Static Routing ......................................................................................................................................... 92
7.4 BFD References................................................................................................................................................... 92
8 BFD Conguration Examples..................................................................................... 93
8.1 BFD Conguration with Routing Protocols ....................................................................................................... 93
8.1.1 OSPF.................................................................................................................................................... 93
8.1.2 IS-IS..................................................................................................................................................... 93
8.1.3 RSVP-TE............................................................................................................................................. 94
8.1.4 Single Hop BGP .................................................................................................................................. 94
8.2 BFD Conguration for Static Routes .................................................................................................................. 97
8.2.1 BFD Status........................................................................................................................................... 98
76.8600-50121F Tellabs
8600 Smart Routers

9
Table of Contents
9 Equal Cost Multipath (ECMP)................................................................................... 100
9.1 Overview ........................................................................................................................................................... 100
9.2 ECMP Network Application ............................................................................................................................. 100
9.3 ECMP Operation ............................................................................................................................................... 101
9.3.1 Dynamic Routing .............................................................................................................................. 101
9.3.2 Static Routing .................................................................................................................................... 102
9.3.3 Forwarding Plane Functions.............................................................................................................. 102
9.3.4 Scalability.......................................................................................................................................... 102
10 Virtual Router Redundancy Protocol ...................................................................... 104
10.1 Introduction ....................................................................................................................................................... 104
10.2 Operation ........................................................................................................................................................... 104
10.2.1 VRRP Parameters .............................................................................................................................. 106
10.2.2 VRRP Timers..................................................................................................................................... 107
10.3 VRRP Supported Features................................................................................................................................. 109
10.3.1 Implementation.................................................................................................................................. 109
10.3.2 Object Tracking ................................................................................................................................. 109
10.3.3 VRRP with IRB..................................................................................................................................110
10.3.4 Accept Data ........................................................................................................................................111
10.4 VRRP Faults.......................................................................................................................................................112
10.5 VRRP References ...............................................................................................................................................112
11 VRRP CLI Conguration Examples ......................................................................... 113
11.1 VRRP Conguration...........................................................................................................................................113
11.1.1 Router1 Conguration ......................................................................................................................114
11.1.2 Router2 Conguration ......................................................................................................................115
11.2 VRRP with IRB Conguration...........................................................................................................................116
11.3 VRRP Status.......................................................................................................................................................118
Tellabs
8600 Smart Routers 76.8600-50121F

10
About This Manual
About This Manual
This chapter discusses the objectives and intended audience of this manual, Tellabs 8600 Smart
Routers Routing Protocols Conguration Guide and consists of the following sections:
Objectives
Audience
Related Documentation
Conventions
Documentation Feedback
Objectives
This manual provides an overview of the Tellabs 8600 smart routers routing protocols and
instructions on how to congure them with a Command-line Interface (CLI) using a routers console
or remote terminal (telnet).
Audience
This manual is designed for administration personnel for conguring Tellabs 8600 smart routers
functions with CLI. On the other hand, Tellabs
8000 intelligent network manager provides access

to equal functionality for administration personnel with a graphical user interface. It is assumed that
you have a basic understanding of the routing protocols.
Tellabs 8600 Smart Routers Technical Documentation
The document numbering scheme consists of the document ID, indicated by numbers, and the
document revision, indicated by a letter. The references in the Related Documentation table below
are generic and include only the document ID. To make sure the references point to the latest
available document versions, please refer to the relevant product document program on the Tellabs
Portal by navigating to www.portal.tellabs.com > Product Documentation > Data Networking >
Tellabs 8600 Smart Routers > Technical Documentation.
76.8600-50121F Tellabs
8600 Smart Routers

11
About This Manual
Document Title Description
Tellabs
8600 Smart Routers

ATM and TDM Conguration Guide
(76.860050110)
Provides an overview of Tellabs 8600 system PWE3 applications,
including types, Single-Segment and Multi-Segment; PWE3
Redundancy; ATM applications, including PWE3 tunneling,
Trafc Management, Fault Management OAM, protection and
TDM applications as well as instructions on how to congure
them with CLI.
Tellabs
8600 Smart Routers

Boot and Mini-Applications
Embedded Software Release Notes
(76.8600-50108)
Provides information related to the boot and mini-applications
software of Tellabs 8605 smart router, Tellabs 8607 smart router,
Tellabs 8609 smart router, Tellabs 8611 smart router, Tellabs
8620 smart router, Tellabs 8630 smart router and Tellabs 8660
smart router as well as the installation instructions.
Tellabs
8600 Smart Routers

CLI Commands Manual
(76.860050117)
Provides commands available to congure, monitor and maintain
Tellabs 8600 system with CLI.
Tellabs
8600 Smart Routers

Embedded Software Release Notes
Consists of the embedded software release notes of the Tellabs
8600 NEs. The following embedded software release notes are
available:
Tellabs
8605 Smart Router FP1.6 Embedded Software

Release Notes (76.8616-50154)
Tellabs
8607 Smart Router FP1.1 Embedded Software Re-

lease Notes (76.8611-50139)
Tellabs
8609 Smart Router and Tellabs
8611 Smart Router

FP1.2 Embedded Software Release Notes (76.8612-50155)
FP4.1 Embedded Software Release Notes (76.8641-50156)
of Tellabs 8620 smart router, Tellabs 8630 smart router and
Tellabs 8660 smart router
Tellabs
8600 Smart Routers

Equipment Management
Conguration Guide
(76.860050118)
Provides an overview of Tellabs 8600 system HW inventory,
software management, equipment protection 1+1 (CDC and
SCM) as well as instructions on how to congure them with CLI.
Tellabs
8600 Smart Routers

Ethernet Conguration Guide (76.
8600-50133)
Provides an overview of Tellabs 8600 system Ethernet
applications, including interfaces; Ethernet forwarding (MAC
Switching, Ethernet PWE3, IRB, VLAN, VPLS); Ethernet OAM;
LAG; ELP as well as instructions on how to congure them
with CLI.
Tellabs
8600 Smart Routers

Fault Management Conguration
Guide (76.860050115)
Provides an overview of Tellabs 8600 system fault management,
including fault source, types and status as well as instructions on
how to congure it with CLI.
Tellabs
8600 Smart Routers

Frame Relay Conguration Guide
(76.860050120)
Provides an overview of Tellabs 8600 system Frame Relay
applications, including interfaces; Performance Monitoring;
protection; Trafc Management as well as instructions on how to
congure them with CLI.
Tellabs
8600 Smart Routers

Hardware Installation Guide
(76.8600-40039)
Provides guidance on mechanical installation, cooling,
grounding, powering, cabling, maintenance, commissioning and
ESW downloading.
Tellabs
8600 Smart Routers

Hardware Release Notes
(76.8600-40027)
Consists of the hardware release notes of the network element
components in Tellabs 8605 smart router, Tellabs 8607 smart
router, Tellabs 8609 smart router, Tellabs 8611 smart router,
Tellabs 8620 smart router, Tellabs 8630 smart router and Tellabs
8660 smart router
Tellabs
8600 Smart Routers 76.8600-50121F

12
About This Manual
Tellabs
8600 Smart Routers

Interface Conguration Guides
The Interface Conguration Guides provide an overview of the
Tellabs 8600 NEs interface functions, including NE supported
interface types and equipping; interface features; conguration
options and operating modes; fault management; performance
monitoring; interface conguration layers and port protocols as
well as instructions on how to congure them with CLI. The
following interface conguration guides are available:
Tellabs
8605 Smart Router FP1.6 Interface Conguration

Guide (76.8616-50157)
Tellabs
8607 Smart Router FP1.1 Interface Conguration

Guide (76.8611-50136)
Tellabs
8609 Smart Router Tellabs
8611 Smart Router

FP1.2 Interface Conguration Guide (76.8612-50158)
FP4.1 Interface Conguration Guide (76.8641-50159) of
Tellabs 8620 smart router, Tellabs 8630 smart router and
Tellabs
8600 Smart Routers

IP Forwarding and Trafc
Management Conguration Guide
(76.860050122)
Provides an overview of Tellabs 8600 system IP, forwarding and
trafc management functionality, including: IP addressing; IP
hosting (ARP, DHCP); IP routing (static); ACL; Differentiated
Services (Policing, Queue Management, Shaping) as well as
instructions on how to congure them with CLI.
Tellabs
8600 Smart Routers

Management Communications
Conguration Guide
(76.860050125)
Provides an overview of Tellabs 8600 system management
communications functions, including communication protocols:
BMP; FTP; RADIUS; SNMP; SSH; TELNET as well as
instructions for conguring them with CLI.
Tellabs
8600 Smart Routers

Mobile Optimization Conguration
Guide (76.860050100)
Provides an overview of Tellabs 8600 system Mobile
Optimization applications as well as instructions on how to
Tellabs
8600 Smart Routers

MPLS Applications Conguration
Guide (76.8600-50123)
Provides an overview of Tellabs 8600 system MPLS applications
(including FRR (one-to-one and facility backup); LDP;
protection and Trafc Engineering), MPLS-TP applications
(including OAM, linear protection) as well as instructions on
how to congure them with CLI.
Tellabs
8600 Smart Routers

Performance Counters Reference
Guide (76.8600-50143)
Provides an overview of Tellabs 8600 system supported
performance counters.
76.8600-50121F Tellabs
8600 Smart Routers

13
About This Manual
Tellabs
8600 Smart Routers

Reference Manuals
The reference manuals describe the Tellabs 8600 network
element features including:
NE enclosure, baseboard, power supply modules, interfaces
types in Tellabs
8605 Smart Router FP1.6 Reference

Manual (76.8616-40099)
and physical LM types in Tellabs
8607 Smart Router FP1.1

Reference Manual (76.8611-40067)
and physical LM types in Tellabs
8609 Smart Router FP1.2

Reference Manual (76.8612-40100)
NE enclosure, baseboard, power supply modules, SCMs, HM
and LM types in Tellabs
8611 Smart Router FP1.2 Refer-

ence Manual (76.8612-40101)
NE enclosure, baseboard, power supply modules, fan mod-
ule, timing module, IFMs in Tellabs
8620 Smart Router

FP4.1 Reference Manual (76.8641-40102)
NE subrack, fan modules, CDCs, line cards and IFMs
in Tellabs
8630 Smart Router FP4.1 Reference Manual

(76.8641-40103)
NE subrack, fan modules, CDCs, line cards and IFMs
in Tellabs
8660 Smart Router FP4.1 Reference Manual

(76.8641-40104)
Tellabs
8600 Smart Routers

Routing Protocols Conguration
Guide (76.860050121)
Provides an overview of Tellabs 8600 system routing protocols,
including BFD; BGP; ECMP; IS-IS; OSPF and VRRP as well as
instructions on how to congure them with CLI.
Tellabs
8600 Smart Routers

SNMP MIB Support
(76.8600-50116)
Describes SNMP MIB support by the Tellabs 8600 NEs and
provides information on the supported objects and traps. For
further information on SNMP MIBs, see the related RFCs.
Tellabs
8600 Smart Routers

Statistic Counters Reference Guide
(76.8600-50142)
Provides an overview of Tellabs 8600 system supported statistic
counters.
Tellabs
8600 Smart Routers

Synchronization Conguration
Guide (76.860050114)
Provides an overview of Tellabs 8600 system synchronization
applications, including physical layer Frequency Synchronization
(SEC, EEC); Frequency Packet Synchronization (CES, PTP);
Phase-Time Synchronization as well as instructions on how to
Tellabs
8600 Smart Routers

Test and Measurement Conguration
Guide (76.860050124)
Provides an overview of Tellabs 8600 system measurement and
connectivity verication tools, including Ethernet loopback;
IP ping and traceroute; MAC swap loopback; MPLS ping and
traceroute; PLT; PWE3 loopback; VCCV (VCCV BFD, VCCV
LSP ping) as well as instructions on how to congure them with
CLI.
Tellabs
8600 Smart Routers

VPNs Conguration Guide
(76.860050128)
Provides an overview of Tellabs 8600 system virtual private
network (VPN) layer 3 applications as well as instructions on
how to congure them with CLI.
Tellabs
8000 Intelligent Network

Manager Online Help
Provides instructions on how different operations are performed
with Tellabs 8000 intelligent network manager. Describes also
different parameters and controls of the Tellabs 8000 intelligent
network manager dialogs and windows.
Note that the online help is not available on the portal but it is
incorporated in Tellabs 8000 intelligent network manager.
Tellabs
8600 Smart Routers 76.8600-50121F

14
About This Manual
Interface Numbering Conventions
To be able to follow more easily the feature descriptions and conguration examples given in this
document, see also the Tellabs 8600 system interface numbering and related gures described in
Tellabs
8600 Smart Routers CLI Commands Manual.

Documentation Feedback
Please contact us to suggest improvements or to report errors in our documentation:
Email: -documentation@tellabs.com
76.8600-50121F Tellabs
8600 Smart Routers

15
Tellabs 8600 Rebranding
Tellabs 8600 Rebranding
Starting from September 2012, Tellabs 8600 product names are being rebranded. The table below
lists previous and new product names. You may see instances of both the previous and the new
product names in the customer documents during the transition period to the new naming system.
Previous Product Name New Product Name
Tellabs
8600 Managed Edge System Tellabs
8600 Smart Routers

Tellabs
8605 Access Switch Tellabs
8605 Smart Router

Tellabs
8607 Smart Router

Tellabs
8609 Smart Router

Tellabs
8611 Smart Router

Tellabs
8620 Smart Router

Tellabs
8630 Smart Router

Tellabs
8660 Edge Switch Tellabs
8660 Smart Router

Tellabs
8600 Smart Routers 76.8600-50121F

16
Tellabs 8600 Discontinued Products
Tellabs is announcing the Manufacture Discontinued (MD) for the following Tellabs 8600 products:
Discontinued Product Replacement
Product/Solution
MD Notication
Tellabs 8605-A AC
(81.86S8605ACCHA-R6)
Tellabs 8605-B AC
(81.86S8605ACCBA-R6 Rev. B or
higher)
SC1005056-1
Tellabs 8605-A DC
(81.86S-8605A-DC-R6)
Tellabs 8605-B DC
(81.86S-8605B-DC-R6 Rev. A or
higher)
SC1005056-1
Tellabs 8605-A DC24
(81.86S8605DC24C-R6 Rev. D)
Tellabs 8605-A DC
(81.86S-8605A-DC-R6 Rev. A or
higher)
SC1002892-1
Tellabs 8605-A DC48
(81.86S8605DC2BC-R6 Rev. C)
Tellabs 8605-A DC
(81.86S-8605A-DC-R6 Rev. A or
higher)
SC1002892-1
Tellabs 8605-B DC24
(81.86S8605DC2DC-R6 Rev. C)
Tellabs 8605-B DC
(81.86S-8605B-DC-R6 Rev. A or
higher)
SC1002892-1
Tellabs 8605-B DC48
(81.86S8605DC48C-R6 Rev. B)
Tellabs 8605-B DC
(81.86S-8605B-DC-R6 Rev. A or
higher)
SC1002892-1
Tellabs 8605-D DC24
(81.86S8605DC4BC-R6 Rev. C)
Tellabs 8605-D DC
(81.86S-8605D-DC-R6 Rev. A or
higher)
SC1002892-1
Tellabs 8605-D DC48
(81.86S8605DC4DC-R6 Rev. C)
Tellabs 8605-D DC
(81.86S-8605D-DC-R6 Rev. A or
higher)
SC1002892-1
(81.86S-8609-R6 Rev. A)
Tellabs 8609 smart router R2
82.86S-8609-R6 Rev. A
SC1004862-1
Tellabs 8620 smart router AC
(81.86S8620ACCHA-R5 Rev. B)
For most applications Tellabs 8609
smart router and Tellabs 8611 smart
router can be used, please check.
SC1005135-1
Tellabs 8620 smart router DC48
(81.86S8620DC48C-R5 Rev. B)
For most applications Tellabs 8609
smart router and Tellabs 8611 smart
router can be used, please check.
SC1005136-1
Tellabs 8660 smart router subrack
V3.1
(81.86S-8660-R6 Rev. A)
Tellabs 8660 smart router R2
subrack
82.86S-8660-R6 Rev. A
SC1003044-1
IFC1-A (81.86IFC1A02024-R5
Rev. B)
IFC2-B (81.86L-IFC2B-R6) is
main replacement but check IFM
compatibility.
SC1005144-1
76.8600-50121F Tellabs
8600 Smart Routers

17
Discontinued Product Replacement
Product/Solution
MD Notication
8x10/100BASE-TX IFM
(81.86MFETX82018-R6 Rev.
D)
8x100/1000BASE-X R2 IFM
(81.86M-IFMGEX08-R6) with
IFC2
SC1005147-1
8x100BASE-X IFM
(81.86MFEX082028-R6 Rev.
A)
IFC2
SC1005148-1
2x1000BASE-X IFM
(81.86MGE0022019-R5 Rev.
A)
IFC2
SC1005149-1
8x1000BASE-X IFM
(81.86MGE0082208-R6 Rev.
B)
IFC2
SC1005150-1
1xchSTM-1/chOC-3 Multiservice
IFM (81.86MS1C012203-R5 Rev.
B)
4xchSTM-1/chOC-3 Multiservice
IFM (81.86MS1C042234-R6)
SC1005145-1
24xchE1/chT1 Mobile Optimization
IFM (81.86ME1M242237-R6 Rev.
A)
None. SC1005146-1
For details regarding Tellabs MD policy, refer to the Tellabs North America Manufacturing
Discontinued Policy found on the Tellabs Portal (www.portal.tellabs.com).
Tellabs
8600 Smart Routers 76.8600-50121F

18
1 OSPF
1 OSPF
1.1 Overview
The Shortest Path First (SPF) routing algorithm is the basis for the Open Shortest Path First (OSPF)
routing protocol operations to calculate the shortest path between the source and the destination.
A typical OSPF network is comprised of Autonomous Systems (AS) which are groups of areas.
Each OSPF router oods link-state advertisements throughout the area that contains information
about the router interfaces and routing metrics. Each link is assigned a value that represents its cost.
Each router maintains a database that describes the topology of the area. All routers that belong
to the same area have an identical link-state database. OSPF quickly detects topological changes
and calculates new loop-free routes.
Routers that connect areas are Area Border Routers (ABRs) and they must be part of the AS
backbone. For communication to happen between areas, each ABR advertises reachability
information to all other areas.
All OSPF protocol exchanges can be authenticated. This means that only trusted routers can
participate in the routing.
Externally derived routing data, i.e. routes learned from Border Gateway Protocol (BGP), are
advertised throughout the AS. This externally derived data is kept separate from the link-state data
of the OSPF protocol. Each external route can also be tagged by the advertising router, enabling the
passing of additional information between routers on the boundary of the AS.
OSPF can be augmented with Trafc Engineering (TE) extensions. TE extensions announce
information about the reservation status of the links. DS-TE extensions advertise the reservation
status per TE class for each link. That information is used when Label Switched Paths (LSPs) are set
up by Resource Reservation Protocol with Trafc Engineering Extensions (RSVP-TE) signalling.
76.8600-50121F Tellabs
8600 Smart Routers

19
1 OSPF
1.2 OSPF Hierarchical Routing
With hierarchical routing it is possible to build much larger OSPF networks. When networks grow
the memory and computing resource requirements will grow as well. Hierarchical routing is a way
to keep the requirements for the router at an acceptable level in large networks. OSPF hides the
topology of an area from the rest of the AS. OSPF supports two-level hierarchical routing.
1.2.1 Autonomous System
AS is a group of routers under the same administrative control that share the same routing
information.
A router that exchanges routing information with routers in other ASes is called an AS boundary
router. Such routers advertise the external routing information of the AS throughout the AS. Every
router in the AS knows the route to the AS boundary router.
1.2.2 Areas
A group of networks and hosts, together with the routers having interfaces to any one of the included
networks, is called an area. Each area runs a separate copy of the link-state routing algorithm, i.e.
each router in the area sees the topology of the area where they belong. Routers in other areas cannot
see the topology, which reduces routing trafc within the AS. The router that belongs to more
than one area is called an area border router.
OSPF backbone area, i.e. area 0.0.0.0 always contains all area border routers. Backbone area
distributes the routing information between all other areas. The backbone must be contiguous but
not necessarily physically since one can set up virtual links in order to create backbone connectivity.
OSPF supports an area type called stub area in order to lower memory consumption of the routers in
that area. External advertisements of the AS are not ooded into or through stub areas. Routing to
the external destinations of the AS in these areas is based on a default route.
Not-So-Stubby Areas (NSSAs) are similar to the OSPF stub areas but have the additional capability
of importing AS external routes in a limited fashion. NSSA allows external routes to be ooded
within the area but does not accept external routes from the other areas.
Tellabs
8600 Smart Routers 76.8600-50121F

20
1 OSPF
1.3 OSPF Hello Messages and Link-State Advertisements
OSPF router uses the Hello messages of OSPF to acquire neighbors. On Broadcast and
Non-Broadcast Multiaccess (NBMA) networks the designated router for the network is elected by
Hello protocol. The router will setup adjacencies with new neighbors.
Link-state databases are synchronized between adjacent routers. A router periodically advertises
its link state. Link state is also advertised when the state of the router changes. Link-State
Advertisements (LSAs) are ooded throughout the area. The advertisements depict the topology
of the AS. The ooding algorithm is reliable, ensuring that all routers in an area have exactly
the same link-state database.
The database is used to determine the route to each destination. The routes are calculated by using
the SPF algorithm. Such calculation is used within a single area. For inter-area routes summary
LSAs are generated by ABRs for other areas. AS border routers ood information about external
routes (external LSAs) throughout the AS except to stub areas.
The OSPF protocol runs directly over the IP network layer and uses IP protocol number 89. All
OSPF protocol packets share a common protocol header [RFC2328]. There are ve different OSPF
packets: Hello, Database Description, Link-State Request, Link-State Update, Link-State Ack. The
formats are described in the previously mentioned RFC. See chapter 1.8 OSPF References for other
relevant RFCs. A designated router that is selected by Hello protocol for multiaccess networks has
the responsibility to announce network LSAs for the network. The designated router has adjacencies
with all the other routers in the network but the other routers do not have adjacencies with each
other. This reduces the number of adjacencies and helps OSPF to scale better.
1.4 Extensions for Support of Differentiated Services-Aware MPLS
Trafc Engineering
In the networks where optimization of transmission resources is seen important, mechanisms of
Differentiated Services can be complemented by Multiprotocol Label Switching (MPLS) TE
mechanisms. To implement DS-TE in the network, OSPF must support extensions where link
reservation status per each TE class is exchanged between the routers. Opaque LSA extensions are
used for this purpose. Trafc Engineering Database (TED) is used to store this information. TED
is used by Constrained Shortest Path First (CSPF) when calculating an optimal route to LSP. See
Tellabs
8600 Smart Routers MPLS Applications Conguration Guide.

1.5 OSPF Graceful Restart
OSPF graceful restart support enables OSPF router to stay on the forwarding path even if its
OSPF software is restarted. The router that is restarting sends out link-local Opaque LSA, Grace
LSA, which indicates its intention to perform a graceful restart within a specied amount of time.
Neighboring routers, which receive Grace LSAs, continue to announce the restarting router in their
LSAs as if it were fully adjacent, but only if the network topology remains static.
76.8600-50121F Tellabs
8600 Smart Routers

21
1 OSPF
1.6 Fast OSPF Adjacency Establishment
When a link goes up, OSPF can take quite long time to negotiate adjacencies on the link. This is
caused by two design choices in the OSPF protocol itself:
Hellos are only transmitted periodically. If a neighbor has sent a hello in the link just before a new
neighbor appears, it might take almost 10 seconds, which is the default hello timer, for the rst
router to acknowledge the existence of the new router. As reaching full adjacency takes several
round trips, this whole operation can take 30 seconds.
If a link is located in a broadcast network and no Designated Router (DR) is active, all OSPF
speakers will wait 40 seconds (the default wait time is the same as the dead time) to ensure that
there is indeed no OSPF DR active.
This means that after a transient link failure, it can take over one minute for OSPF to reestablish
the link. The Tellabs 8600 system implements three strategies to allow the fast reestablishment of
OSPF links in case of transient failure.
Immediately replying Hello as specied in [draft-kou-ospf-immediately-replying-hello]. With
this method, a router will immediately reply with a Hello Packet to its peer when receiving
a neighbor's Hello Packet without increasing the OSPF packet trafc. Hello replies avoid the
penalty of waiting for the next periodic hello to acknowledge the state change in a neighbor. Al-
though hello replies marginally increase network load when changes occur, in steady state no
overhead is incurred. To prevent malfunctioning routers from causing a hello storm, a limit can
be specied for the number of hello replies that can be sent between any two periodic hellos.
Congurable designated router (DR) wait time. This conguration parameter allows setting the
DR wait time independently from the dead time. When hello acknowledgements are used, DR
wait time can be very small, as the DR is guaranteed to respond almost immediately to hellos
from the routers joining the network. If the DR wait time is set to zero, IS-IS like behavior is
obtained, so that the DR can change when a new router is introduced. In general, it is desirable
to keep the DR wait time value such that the DR does not accidentally change, that is, either it is
longer than the hello interval or the hello acknowledgements are used and DR wait time is longer
than the time it takes for the DR to respond to the hellos, e.g. 500 ms.
Optimized Database Description (DD) exchange as specied in [draft-ogier-ospf-dbex-opt]. With
this optimization, a router does not list an LSAin Database Description packets sent to a neighbor,
if the same or a more recent instance of the LSA was listed in a Database Description packet
already received from the neighbor. This reduces Database Description overhead by about 50%
in large networks, since it reduces the total number of LSA headers exchanged by about one
half when the two routers are already nearly synchronized. This optimization does not affect
synchronization, since it only omits unnecessary information from Database Description packets
and it is fully backward compatible with OSPF.
Tellabs
8600 Smart Routers 76.8600-50121F

22
1 OSPF
1.7 OSPF Unnumbered Links
The Tellabs 8600 system supports unnumbered IPv4 links as specied in [RFC1812] Unnumbered
links are point-to-point links that connect two routers but do not have an IP address. Unnumbered
links are used in some core networks and often for connecting equipment at customer premises.
When using unnumbered links no allocation is needed for IP addresses and they also allow easier
conguration and network planning. On the other hand, unnumbered links in the Tellabs 8600
system do not support LDP or RSVP. Maintenance is more difcult as it is not possible to ping link
addresses; moreover, the ICMP messages show errors in unnumbered links as originating from the
loopback.
Each unnumbered interface is always associated with one numbered interface. Usually the
associated interface is a loopback, however other interface types are also permitted. However if the
associated interface goes down, the operation of unnumbered interface is also hindered, hence using
loopbacks as associated interface is recommended.
The address of the associated interface is used as a source address for locally generated packets
transmitted to a unnumbered interface.
1.8 OSPF References
Reference Description
[draft-ietf-tewg-diff-te-proto] draft-ietf-tewg-diff-te-proto-07.txt (200403), Protocol extensions
for support of Differentiated-Service-aware MPLS Trafc
Engineering
[draft-kou-ospf-immediately-
replying-hello]
draft-kou-ospf-immediately-replying-hello-02.txt (200701),
Update to OSPF Hello procedure
[draft-ogier-ospf-dbex-opt] draft-ogier-ospf-dbex-opt-00.txt (200606), OSPF Database
Exchange Summary List Optimization
[RFC1812] RFC1812 (199506), Requirements for IP Version 4 Routers
[RFC2328] RFC2328 (199804), OSPF version 2 (OSPFv2)
[RFC3623] RFC3623 (200311), Graceful OSPF restart
[RFC3630] RFC3630 (200309), Trafc Engineering (TE) extensions to OSPF
version 2
76.8600-50121F Tellabs
8600 Smart Routers

23
2 OSPF Conguration Examples
This section gives some CLI examples of OSPF conguration in the Tellabs 8600 system.
It is advisable to always refer to Tellabs
8600 Smart Routers CLI Commands Manual for the

latest information on:
Default values to avoid unnecessary conguration;
Available conguration options and parametric range.
2.1 Basic Conguration
To enter the Conguration mode and to set up routing process use the following command.
Step 1 Activate and dene OSPF instance with ID 10.
router(config)# router ospf 10
Step 2 Assign a subnet to backbone area. OSPF routing can be enabled per IPv4 subnet basis. Each subnet
can belong to one particular OSPF area.
router(cfg-ospf[10])# network 10.0.0.0/8 area 0.0.0.0
Step 3 Each router needs to be congured with a unique router ID. This step is not necessarily needed since
the OSPF router ID is selected automatically if this command is not entered. The highest loopback
address is used as the OSPF router ID by default.
router(cfg-ospf[10])# ospf router-id 2.3.4.5
router(cfg-ospf[10])# exit
Tellabs
8600 Smart Routers 76.8600-50121F

24
2.2 Interface Conguration
The following is an example of OSPF settings at interface level.
Step 1 Set the OSPF cost to 10.
router(config)# interface fe 3/0/1
router(cfg-if[fe3/0/1])# ip ospf cost 10
Step 2 Congure the Ethernet port as a point-to-point network.
router(cfg-if[fe3/0/2])# ip ospf network point-to-point
Step 3 Priority for designated router selection is set to 3. In multi-access networks a router priority is set to
determine the designated router for the network.
router(cfg-if[fe3/0/1])# ip ospf priority 3
Step 4 Set the interval between Hello packets hello-interval to 3 seconds.
router(cfg-if[fe3/0/1])# ip ospf hello-interval 3
Step 5 Set the interval during which, if no Hello packets are received a neighbor is declared not available.
In this example the dead-interval is set to 10 seconds.
router(cfg-if[fe3/0/1])# ip ospf dead-interval 10
router(cfg-if[fe3/0/1])# exit
2.3 Area Conguration
An AS can be split into multiple areas in order to reduce LSA trafc and the size of the LSA
databases, the routers need to maintain.
In chapter 2.1 Basic Conguration the network area command was illustrated by connecting the
network to the OSPF backbone area.
Step 1 Assign subnet to area 1.1.1.1.
router(cfg-ospf[10])# network 10.0.0.0/8 area 1.1.1.1
Step 2 Set an area as a stub area.
router(cfg-ospf[10])# area 1.1.1.1 stub
There are no external routes in an OSPF stub area, so you cannot redistribute from another protocol
into a stub area. An NSSA allows external routes to be ooded within the area. These routes are
then leaked into other areas. The external routes from other areas still do not enter the NSSA. To
congure area as NSSA use the following command.
Step 1 Note that with this command it is possible to dene if the router will translate Type-7 LSAs
received from the NSSA into Type-5 LSAs. Also to dene whether or not to redistribute external
routes to NSSA.
router(cfg-ospf[10])# area 1.1.1.1 nssa
76.8600-50121F Tellabs
8600 Smart Routers

25
2.4 Authentication
To enable the OSPF authentication for an interface use the following commands. These commands
activate Message Digest Authentication (MDA), which is a cryptographic authentication.
Step 1 This enables the OSPF packet to use authentication on the interface. MDA scheme is selected.
router(config)# interface fe 3/0/1
router(cfg-if[fe3/0/1])# ip ospf authentication message-digest
Step 2 Set the key and key ID for an interface.
router(cfg-if[fe3/0/1])# ip ospf message-digest-keychain <key-chain-containing-
the-key>
router(cfg-if[fe3/0/1])# exit
2.5 TE Conguration
OSPF-TE is used together with RSVP-TE in trafc engineering applications. A complete example
of this is given in Tellabs
8600 Smart Routers MPLS Applications Conguration Guide, whereas

this guide illustrates the conguration needed for OSPF-TE. For instance, the bandwidth constraints
and bandwidth constraints model conguration are explained in the previously mentioned guide.
TE is enabled as a default.
OSPF is used to advertise networks and information about TE classes.
Step 1 Enable trafc engineering extensions.
router(cfg-ospf[10])# traffic-eng
Step 2 Enable constraint-based shortest path rst calculation.
router(cfg-ospf[10])# cspf
Step 3 You can specify cspf tie-break method (used if more than one candidate link satises all the route
constraints). This sets preferred path to be the one with the largest minimum available bandwidth
ratio. This command is optional. Default is random.
router(cfg-ospf[10])# cspf tie-break least-fill
2.6 Graceful Restart Conguration
Graceful restart is enabled by default. Default parameters are optimized to most networks and they
should not be modied unless absolutely necessary. You can congure graceful restart feature
with the following commands.
Step 1 Enable graceful restart feature and specify grace period to be 250 seconds.
router(config)# ospf restart grace period 250
Step 2 Acts as helper only if received grace period is less than 300 seconds.
router(config)# ospf restart helper max-grace-period 300
Tellabs
8600 Smart Routers 76.8600-50121F

26
2.7 Fast OSPF Convergence
Traditionally, OSPF has slow convergence if multiple changes occur within a short period of time.
Usually the OSPF installations have the following default values:
SPF triggering delay: 5 s
SPF hold time: 10 s (minimum time between two consecutive SPF calculations)
MinLSInterval: 5 s
This means that the rst change of a kind is updated within 5 seconds, but later changes can take
5+10=15 seconds.
The Tellabs 8600 system allows the use of exponential delay for these parameters. As a result, the
system allows rapid response to a small number of events while preventing overload when multiple
events occur continuously.
Both SPF and LSA refresh timers are based on exponential curves. Both of them have three
parameters:
Initial delay
Multiplier
Maximum delay
The rst event is n=0 whereas the following events are 1, 2, 3... An event number is set to zero
when 2 * maximum delay has elapsed without further events.
The SPF delay is calculated per area but the LSA refresh time per each individual LSA. The formula
used for this is as follows:
for n=0: delay = initial
for n>0: delay = MAX(initial + multiplier*2^(n-1), max_delay)
The delay is calculated from the previous SPF calculation or from the previous refresh of LSA.
However, if an initial value is non-zero, the event will not be executed until now+initial (even if the
prev_event+delay would be before that). This allows the collecting of multiple events to a single
execution. The values are specied as milliseconds.
The traditional OSPF values could be specied as stated in the following table.
init mul
max
SPF 5000 10000 10000
LSA refresh 0 5000 5000
The Tellabs 8600 system uses more optimized values for SPF.
init mul
max
SPF (non-VRF) 200 100 10000
SPF (VRF) 500 2000 10000
76.8600-50121F Tellabs
8600 Smart Routers

27
In the case of non-VRF SPF this would yield (for the constantly repeating event) the following SPF
delays: 200, 300, 400, 600, 1000, 1800, 3400, 6600, 10000, 10000, 10000, ...
LSA refresh timers are not optimized by default, as OSPF architectural constant MinLSArrival
must be set (network wide) so that LSAs are not generated faster than MinLSArrival permits them
to be received.
The default OSPF LSA refresh parameters are reasonable, if it is assumed that only single changes
per network occur quickly. However, sometimes it might be necessary to update the router LSAs
faster. In such cases, reasonable parameters might be as follows: LSA refresh: init 0, mul 400, max
5000. This would yield delays 0, 400, 800, 1600, 3200, 5000, 5000...
Please note that LSA refresh timer does not apply to the initial generation of LSA (which is, as the
name says, not a refresh). N is zero for rst refresh.
However for this to work, all NEs must set MinLSArrival to values less than 400 ms (for example
200 ms). The default OSPF value for MinLSArrival is one second. Initial delay of 0 ms is
reasonable, but to ensure that multiple events can update router LSA sufciently fast, the multiplier
should be sufciently low.
Normally updates are rate-limited to one LSA update per 33 ms. Thus, it may become necessary
to allow faster ooding. Setting the pacing timer to 10 ms would allow 10 updates for each 100
ms period.
Step 1 Set the above parameters according to the examples.
router(config)# router ospf X
router(cfg-ospf[X])# timers spf <init> <multiplier> <max>
router(cfg-ospf[X])# timers lsa refresh <init> <multiplier> <max>
router(cfg-ospf[X])# timers lsa arrival <miniarrival>
router(cfg-ospf[X])# timers pacing flood <delay>
router(cfg-ospf[X])# exit
Step 2 Take these steps to convene the OSPF setup quickly.
router(cfg-ospf[10])# timers spf 200 100 10000
router(cfg-ospf[10])# timers lsa refresh 0 400 5000
router(cfg-ospf[10])# timers pacing flood 10
2.8 Fast OSPF Adjacency Establishment Conguration
2.8.1 Enabling Hello replies
To enable Hello replies in one or all interfaces use the following commands as it corresponds.
Step 1 Specify that a maximum of 15 Hello replies per Hello interval for all interfaces are permitted.
router(cfg-ospf[10])# hello-reply 15
Step 2 Specify that a maximum of 15 Hello replies per Hello interval are permitted for the specied
interface.
router(config)# interface fe 0/0
Tellabs
8600 Smart Routers 76.8600-50121F

28
router(cfg-if[fe0/0])# ip ospf hello-reply 15
router(cfg-if[fe0/0])# exit
2.8.2 Designated Router (DR) Wait Time Conguration
When the link has only two OSPF speakers, DR wait time can be optimized entirely. This can be
accomplished by running the link in point-to-point mode. This is also possible for Ethernet. This is
the preferred conguration which allows the fastest OSPF link recovery times. To use point-to-point
mode in a link that naturally is multicast or broadcast use the following command.
Step 1 Enable the point-to-point mode.
router(cfg-if[fe0/0])# ip ospf network point-to-point
When the link has more than two routers but only one needs to be DR (this would be the uplink
conguration, where the network is useless unless an uplink router is available), the DR wait time
can be congured to zero. This conguration is also allowed if trafc interruption is permitted
whenever a new DRcapable router (DR priority is not zero) joins the network. To congure the DR
wait time for one or all interfaces use the following commands as it corresponds.
Step 1 Set the DR wait time to zero for all interfaces.
router(cfg-ospf[10])# wait-time 0
Step 2 Set the DR wait time to zero for the specied interface.
router(cfg-if[fe0/0])# ip ospf wait-time 0
The above conguration is only recommended in those cases when:
There is only one DR and all the other routers in the subnet have DR priority set to zero, but not
if the network should function with loss of the designated DR. The conguration would make
sense if DR is in the RNC front node and without it the network would be useless.
IS-IS behavior is desired and trafc interruption is permitted when a new router joins the subnet.
The recommended conguration, when the point-to-point mode cannot be used, is to enable the
hello acknowledgements and congure the DR wait time to a small value, in the range of 300-500
ms. When the hello acknowledgements are also enabled, 500 ms is enough time for the DR to
respond, if any DRs exist. To congure the DR wait time for one or all interfaces use the following
commands as it corresponds.
Step 1 Set the DR wait time to 500 ms for all interfaces.
router(cfg-ospf[10])# wait-time 500
Step 2 Set the DR wait time to 500 ms for the specied interface.
76.8600-50121F Tellabs
8600 Smart Routers

29
To get the full benet of these optimizations, fast OSPF convergence should be congured as
specied below, there is no use in having the OSPF adjacencies for up in subsecond time frame, if
the update of the network LSA takes from 5 to 10 seconds and the additional SPF calculation adds
30 seconds. See the two following examples.
The rst example illustrates a case with a ring of point-to-point links and a relatively small OSPF
network that allows the use of aggressive timers.
router(cfg-if[fe0/0])# ip ospf network point-to-point
Step 2 Generate LSA updates quickly.
Step 3 Default value.
Step 4 Accept LSAs quickly.
router(cfg-ospf[10])# timers lsa arrival 50
Step 5 Disable LSA pacing.
Step 6 Permit hello replies.
router(cfg-ospf[10])# Hello-reply 15
In the second example , there is a multiaccess network and a relatively small OSPF network that
allows the use of aggressive timers.
Step 2 Generate LSA updates quickly.
Step 3 Default value.
Step 4 Accept LSAs quickly.
router(cfg-ospf[10])# timers lsa arrival 50
Step 5 Disable LSA pacing.
Step 6 Permit hello replies.
router(cfg-ospf[10])# Hello-reply 15
Tellabs
8600 Smart Routers 76.8600-50121F

30
The OSPF parameters and hello reply statistics are available from the show ip ospf interface
command 2.10 OSPF Status .
2.9 OSPF Unnumbered Links Conguration
The following is an example showing how to congure an OSPF unnumbered link for an interface.
Step 1 Set the loopback interface.
router(config)# ip interface lo0
router(cfg-if[lo0])# ip address 1.1.1.1/32
router(cfg-if[lo0])# no shutdown
router(cfg-if[lo0])# exit
Step 1 Select the interface to be congured.
router(config)# interface so 10/0/0
Step 2 Specify that the IP address is borrowed from the loopback interface. The unnumbered interface is
automatically taken into OSPF routing when the associated loopback is taken.
router(cfg-if[so10/0/0])# ip unnumbered lo0
router(cfg-if[so10/0/0])# no shutdown
router(cfg-if[so10/0/0])# exit
The following is an example on how to enable OSPF routing on the interface so10/0/0.
Step 1 Activate and dene OSPF instance with ID 10.
Step 2 Assign a subnet to the backbone area.
router(cfg-ospf[10])# network 1.1.1.1/32 area 0
OSPF routing can be enabled per IPv4 subnet basis. Each subnet can belong to one particular
OSPF area.
The loopback address is the same for the node and for all the interfaces, so if there are customer
interfaces that you want to use as unnumbered, but do not wish to have them OSPF enabled, use a
different loopback interface for those interfaces.
OSPF can also be disabled from the customer interfaces by setting customer interfaces to passive
mode using the following command
Step 1 Set the customer interface to passive mode.
router(cfg-ospf[10])# passive-interface so 10/0/0
76.8600-50121F Tellabs
8600 Smart Routers

31
2.10 OSPF Status
OSPF information can be inspected using the OSPF options of the show command. The following is
an example showing the OSPF interface parameters and statistics:
Fig. 1 OSPF Parameters and Statistics
Tellabs
8600 Smart Routers 76.8600-50121F

32
3 Border Gateway Protocol
3.1 Overview
Border Gateway Protocol (BGP) is a Routing Protocol that is used to create an inter-domain routing
between autonomous systems or inside of an Autonomous System (AS). The Tellabs 8600 system
implements BGP version 4 (BGP-4) according to [RFC1771]. The main purpose of BGP is to
exchange network reachability information, including a list of the autonomous systems and paths
connectivity to other BGP routers. The information is mainly used to construct a network topology
outlining a loop free connectivity, where routing policy decisions can be enforced.
BGP supports two different types of routing information exchanges, interior BGP (iBGP) and
exterior BGP (eBGP).
An iBGP is used between BGP routers inside a single AS. To prevent routing loops, iBGP to iBGP
advertisements are not allowed within the iBGP routers. Therefore, in an AS, the iBGP routers must
have either a full-mesh connectivity, or use Router Reector (RR), or confederations instead.
An eBGP is used to exchange routing information between routers within different autonomous
systems. In a typical case, eBGP routers are directly connected.
Fig. 2 BGP Topology
Fig. 2 illustrates a classical BGP network topology, where all routers within the AS65100 are iBGP
peers. Route information exchange between AS65100, AS65200 and AS65300 is accomplished
through eBGP.
76.8600-50121F Tellabs
8600 Smart Routers

33
A simple scenario of mobile backhaul BGP application with the Tellabs 8600 system deployment
(inter-AS with multihoming connectivity) is presented in the following diagram. Mobile backhaul
typical applications use RR, which is described in 3.8.1 Route Reector.
Fig. 3 Inter-AS BGP in Mobile Deployments
Another more complex mobile backhaul network scenario using BGP is presented in the following
diagram.
Tellabs
8600 Smart Routers 76.8600-50121F

34
Fig. 4 Complex Mobile Network BGP Application
In the transit autonomous systems, all P-routers on the path used by transit trafc must either
participate in iBGP routing, or the Autonomous System Border Router(s) (ASBR) of the transit
AS must use MPLS tunneling (BGP free core).
The following table denes the terms used in the BGP section including CLI conguration examples.
Terminology Denition
Autonomous System (AS) An AS is dened as a consistent set of routers that are administered by a
single operator/ISP and advertise a coherent interior routing plan to the
external routers.
AS confederation It is a logical AS formed by multiple sub-autonomous systems.
Attribute It is a parameter used in BGP to describe detailed characteristics of a
prex/route.
BGP router Refers to a router implementing BGP. When two or more BGP routers
establish a BGP session, they are called as either BGP speakers, BGP
peers or BGP neighbors.
BGP routing process Refers to an action of setting a router to become a BGP speaker.
Cluster A logical area formed by route reector(s) and clients.
Multihoming Refers to multiple sites connectivity with aim to increase reliability.
Non-transitive Refers to a characteristic of a BGP attribute not being sent past the AS
that received the attribute in case.
Route reection Route reection is the advertisement of routes between iBGP peers by a
designated router, known as router reector.
76.8600-50121F Tellabs
8600 Smart Routers

35
Terminology Denition
Route Reector (RR) A dedicated BGP router tasked to re-advertise routing information to other
iBGP peers.
RR client An iBGP router operation of which relies on RR to re-advertise its routing
information to the entire AS and also to learn about other routes from
the network.
Transitive Refers to a BGP attribute being sent past the AS that is receiving it, due to
the fact that the attribute is unknown to BGP implementation.
Well-known attribute A BGP attribute that is required to be known by all BGP implementations.
Well-known discretionary Refers to a set of well-known attributes that may or may not be included in
every update message.
Well-known mandatory Refers to a set of well-known attributes that must be included in all update
messages exchanged by BGP routers.
A peering session is used to advertise network reachability information, which contains a list of
networks and information on how the networks can be reached. Initially, when the connection is
established, the BGP peer routers exchange their full routing tables. After a connection has been
established, only route changes (incremental or triggered) are advertised.
In order to exchange routing information, a BGP peering session has to be established between two
BGP routers. BGP utilizes TCP as a transport layer protocol and the TCP session is carried on port
179. Two BGP routers form a TCP connection between each other and exchange messages to
open and conrm the peering session parameters. The session is maintained by sending keepalive
messages, and in case of errors or in other special conditions, a notication message is generated.
John W. Stewart's book BGP4 Inter-Domain Routing in the Internet is recommended for those
seeking more operational details and how to use BGP.
3.2 BGP Attributes
The terms used in this chapter are dened in 3.1 Overview. In BGP, the attributes play an essential
role to the operation of the protocol by making BGP exible for later extensions, so that new
features can be added without changing the base protocol. The BGP attributes are a set of parameters
describing the detailed characteristics of a prex or path information that can be used, for example,
to enforce path selection and routing policy. The BGP attributes can be classied into the following
four groups [RFC4271]:
1. Well-known mandatory. These attributes are mandatory and must be recognized by all BGP
routers. They are included in all update messages exchanged by BGP peers.
ORIGIN
AS_PATH
NEXT_HOP
2. Well-known discretionary. These attributes must be supported by all BGP routers and may or
may not be included in every update message.
LOCAL_PREFERENCE
ATOMIC_AGGREGATE
Tellabs
8600 Smart Routers 76.8600-50121F

36
3. Optional transitive. These attributes are transitive between autonomous systems and are not
mandatory to be recognized by all BGP routers. When sent in an update message and the re-
ceiving router does not recognize them, the attributes are sent over to the next AS.
AGGREGATOR
COMMUNITY
4. Optional non-transitive. These attributes may be recognized by some, but not by all BGP
routers. When an update message containing any attribute of this group is received by a router
not recognizing it, the update will be advertised to other BGP peers without the unrecognized
attribute.
MED (Multi-Exit-Descriminator)
3.2.1 ORIGIN Attribute
ORIGIN is a well-known mandatory attribute that indicates the origin of routing information or
how a given route has been learned by BGP. That is, the attribute is generated by the AS originating
the associated routing information and it is included in the update message of all BGP speakers
advertising this information to other BGP speakers. The attribute can be used to inuence BGP path
preference selection. By the way in which a route is learned by BGP, the ORIGIN attribute can
assume three possible values listed below in the precedence order:
IGP (Interior Gateway Protocol), which indicates that the prex is interior to the AS of origina-
tion;
EGP ( Exterior Gateway Protocol), which indicates that the prex is originated from an EGP
protocol.
INCOMPLETE, which indicates the prex has been learned via other sources.
3.2.2 AS PATH Attribute
AS_PATH is a well-known mandatory attribute that identies those autonomous systems through
which a route being announced has traversed. The attribute will be handled differently depending on
whether the route is being originated, or propagated.
When a BGP router originates a route, the AS_PATH information is empty in all the updates sent
within the AS where the BGP router is located. If the originating router has an eBGP sessions
towards neighboring autonomous systems, then a router will add its AS number when advertising
the route information to the neighbors (BGP routers).
When a route is being propagated to BGP peers within an AS, a peer propagating this route is not
allowed to modify the AS_PATH attribute associated with a route. However, if a route is being
propagated from one local AS to another, i.e. when a route traverses an AS border, a border BGP
router modies the attribute by adding the AS number of the traversed AS. An appended AS number
appears rst in the AS_PATH information as illustrated in the following topology.
76.8600-50121F Tellabs
8600 Smart Routers

37
Fig. 5 AS Path Attribute
The set of autonomous systems, through which a route has traversed in AS_PATH information,
allows the receiving BGP router to identify the autonomous systems a route has traversed. To
avoid routing loops, BGP routers do not accept advertisements that contain a local AS number as
illustrated in Fig. 5. Thus the attribute is used for routing loop detection and prevention. Routing
policy is another application of the AS_PATH attribute in BGP.
3.2.3 NEXT HOP Attribute
NEXT_HOP is a well-known mandatory attribute, which carries information on how to reach the
advertised network in the form of an IP address of the next router towards the destination.
By default, the Tellabs 8600 system follows standard conventions ([RFC4271] for basic rules,
[RFC2796] for route reection, [RFC3065] for confederations) on setting the NEXT_HOP attribute.
A somewhat inaccurate assumption is that the NEXT_HOP is changed usually when advertising to
eBGP neighbors, while advertisements to iBGP neighbors do not change the attribute. For VPNv4
Subsequent Address Family Identier (SAFI), the NEXT_HOP is also changed by default on option
D eBGP iBGP advertisements. Setting the NEXT_HOP for VPNv4 route to any local address,
also changes the MPLS label to a locally-assigned label.
A manual control of the NEXT_HOP attribute is available via several options, which are provided
below in order of preference. If multiple options are set, then the ones listed rst take precedence:
1. Set statement in route-map ("set ip next-hop A.B.C.D")
2. Unchanged next-hop conguration ("router bgp x / address-family / neighbor
X.X.X.X transparent-next-hop")
Tellabs
8600 Smart Routers 76.8600-50121F

38
3. Next-hop-area conguration ("router bgp x / address-family / neighbor X.X.X.X next-
hop-area Y")
4. Next-hop-self conguration ("router bgp x / address-family / neighbor X.X.X.X next-
hop-self")
From the conguration options listed above, the most complex is the next-hop-area.This
option is intended to allow more ne-grained control of the NEXT_HOP setting on the borders of
various types of regions. It allows using both the source and the destination peers as part of the
policy. The next-hop-area option works as follows:
When no next-hop-area is congured to a source or destination peer, the NEXT_HOP pro-
cessing is per regular rules.
If both source and destination have next-hop-area congured, then:
1. If it is the same area, this is taken as a request to keep the NEXT_HOP unchanged. This
overrides the iBGP eBGP/eBGP iBGP rules and the "next-hop-self" directive,
if present.
2. If the area is different, then this is taken as request to set the NEXT_HOP to self. This does
not override the next-hop-unchanged directive.
All the rules above are evaluated on per prex basis, where source peer is the one advertising that
particular prex to the local node and destination peer is the peer to which the prex is being
advertised.
A typical user case of the next-hop-area attribute is to allow direct data transfer between
multiple eBGP neighbors within a specic access network or ring. This is particularly useful when
using N-PE with inter-AS option D [draft-kulmala-l3vpn-interas-option].
3.2.4 LOCAL PREFERENCE Attribute
LOCAL_PREFERENCE is a well-known discretionary attribute that is exchanged only within the
local AS. When a route rst arrives to an AS (either via eBGP or via redistributes), the ingress route
(ASBR) classies a route and sets the LOCAL_PREFERENCE to it, which is then advertised to the
local AS peers. All other iBGP speakers use this attribute that is transmitted over iBGP. However,
the LOCAL_PREFERENCE attribute is not transmitted over eBGP, that is, autonomous systems are
independent and may use different routing policies.
The LOCAL_PREFERENCE attribute indicates the priority of a BGP router and it is used to
inuence BGP path selection and determines the best path for trafc exiting the local AS. If a
BGP router receives from several iBGP peers multiple routes to the same destination, a route with
a higher degree of preference will be selected as the best route. Due to the fact that the routers
within an AS receive the LOCAL_PREFERENCE attribute along with the route, a consistent routing
decision is always possible throughout the AS.
76.8600-50121F Tellabs
8600 Smart Routers

39
Fig. 6 Local Preference Attribute
Fig. 6 illustrates an example of the best path selection using the LOCAL_PREFERENCE attribute. In
AS65200, theLOCAL_PREFERENCE attributes are set on border routers R20 (to 200) and R40 (to
400), which are then advertised to iBGP peer R30. Since R40 has a higher LOCAL_PREFERENCE
set to 400, it will be selected as the best path to exit the AS65200 for any trafc destined to AS65100.
After a selection has been made based on the LOCAL_PREFERENCE, R20 may no longer advertise
it's low preference value. Instead will just forward route information through the selected best path.
3.2.5 ATOMIC AGGREGATE Attribute
ATOMIC_AGGREGATE is a well-known discretionary attribute that allows BGP routers to indicate
to each other the decisions they might make when presented with a set of overlapping routes.
If a BGP router decides to perform route aggregation, then the aggregating router attaches the
attribute when advertising it to the neighbors. A BGP router receiving a route with this attribute
attached does not detach the attribute when propagating it to other BGP peers. Moreover, the
received aggregated prex should not be de-aggregated either. Thus, the ATOMIC_AGGREGATE
attribute signals to the receiver that path information that was present in the original routing updates
may have been lost when the updates where aggregated into a single entry. Route aggregation is
described in 3.5 Route Aggregation.
3.2.6 COMMUNITY Attribute
COMMUNITY is an optional, transitive attribute of variable length that facilitates the transfer of local
policies through different autonomous systems. A COMMUNITY attribute can be assigned to a
specic prex, or to a group. If assigned to a group, it gives an identity of the group that shares
some common properties. By specifying a COMMUNITY attribute, the network administrator can for
example limit local routes to propagate only within a certain region and advertise the aggregate
prex outside the region.
COMMUNITY attributes are of two types:
Tellabs
8600 Smart Routers 76.8600-50121F

40
Communities [RFC1997]
Extended communities [RFC4360]
Communities
Communities attribute is treated as four-octet values. The communities attribute has a global
signicance and xed attribute values. The well-known communities are dened in [RFC1997]
and are implemented in all BGP routers. However, since the publication of RFC 1997, other
communities have been added, e.g. BGP data collection communities dened in RFC 4384. The
Tellabs 8600 system supports the following attribute values:
NONE removes the communities attribute from the prexes that pass the route-map.
LOCAL_AS species routes that are not to be advertised outside of the local AS boundary.
NO_ADVERTISE species routes that are not to be advertised to other BGP peers.
NO_EXPORT species routes that must not to be advertised outside a BGP confederation or AS
boundaries.
There is a wide range of other communities that are not predened and are meant for private use,
typically these are set via route-map (please refer to3.4.1 Route Map) and are supposed to be coded
as 16-bit values that must include the AS number of the originator.
Extended Communities
Extended communities attribute [RFC4360] is eight-octets long. The extended communities
attribute can be used to specify the destination group with further details. E.g. MPLS VPN routing
information is distributed by using a route target extended communities attribute.
The Tellabs 8600 system supports the following attribute values:
RT (Route Target)
SOO (Site of Origin )
In the Tellabs 8600 system, the user can arbitrary encode the extended communities attribute to
implement the desired BGP routing policy.
3.2.7 AGGREGATOR Attribute
AGGREGATOR is an optional transitive attribute that conveys the IP address of a BGP router
generating the aggregate route. When a BGP router aggregates some routes it has learned from peers
and then advertises the aggregated prex to the other routers, it may opt to attach the AGGREGATOR
attribute into the aggregated route to specify the AS and its IP address. For more details about BGP
route aggregation see 3.5 Route Aggregation. The AGGREGATOR attribute does not inuence the
best path selection process.
76.8600-50121F Tellabs
8600 Smart Routers

41
3.2.8 MED Attribute
Multi-Exit-Discriminator (MED) is an inter-AS optional and non-transitive attribute that is used to
convey relative preference of the entry or exit points to the same neighboring AS, provided that
the two neighboring autonomous systems have multiple paths connectivity to each other. The
attribute is exchanged between two neighboring autonomous systems and due to the fact that it is
no-transitive, it is never advertised to any other autonomous systems. However, it should be noted
that the MED attribute is set only by one AS, and the neighboring AS will only use the set value
when deciding which path to choose. For example, if all other conditions are the same, the entry or
exit point with the lowest attribute value is preferred. Thus, the attribute can be used to inuence the
best path selection process.
Fig. 7 MED Attribute
Whenever there are several paths between two adjacent autonomous systems, MED may be used by
one AS to tell the other AS to prefer one of the paths over the other for a given destination. Within
the same AS, when the MED attribute is received via eBGP, it may be only propagated internally to
other iBGP peers. In Fig. 7, all trafc destined to AS65101 will be routed via R20 from AS65100
according to the MED attribute selection process.
For a single path connectivity between two adjacent autonomous systems, the MED attribute
is not compared.
There are three command options available to inuence a comparison process of the MED attribute,
which are highlighted in the following table.
Tellabs
8600 Smart Routers 76.8600-50121F

42
Command Option Description
bgp always-compare-med The command species to compare the MED attribute for paths from
neighbors in different autonomous systems.
bgp deterministic-med The command species to compare the MED attribute when choosing
among routes advertised by different peers in the same AS.
bgp bestpath med The command species two options of the MED attribute: confed and
missing-as-worst.
The option confed enables MED comparison among paths learned
from confederation peers. The attributes are compared only if there is
no external autonomous system, i.e. an AS which is not within the
confederation on the path. If there is an external AS in the path, then
MED comparison cannot be made.
The missing-as-worst option is used to consider a path without
a MED value the least desirable path. If missing-as-worst is
disabled, then the missing MED is assigned the value of 0, which makes
a path with the missing MED attribute the best path.
3.3 Managing Route Preferences
Multiple routes to the same destination network with the same prex may exist depending on the
network topology. There is a certain logic that the BGP process uses when selecting the best path to
the destination among multiple alternatives. The user can easily inuence which route the BGP path
selection process prefers by knowing the rules used and by modifying the relevant attributes. The
path selection algorithm used by BGP is as follows:
1. Routes with inaccessible next-hop are ignored.
2. Connected routes have high precedence.
3. The smallest administrative distance is preferred. This step is used between BGP routes and for
routes redistributed to BGP and is not a decision factor when comparing different BGP routes.
4. A higher weight has high precedence.
5. A route with the highest local preference value is preferred.
6. BGP subtype from best to worst:
Local network statements
Local aggregate
7. Unless bgp bestpath as-path ignore is congured, the shortest AS-path is preferred.
If bgp bestpath compare-confed-aspath is set, confederation elements are also
accounted.
8. The smallest origin attribute is preferred.
9. The smallest MED is preferred:
MED is not compared for different autonomous systems, if this option has not been selected
MED comparison has multiple CLI options that can be used to change the behavior
10. Routes from eBGP neighbors are preferred over iBGP neighbors and confederation neighbors.
76.8600-50121F Tellabs
8600 Smart Routers

43
11. If path selection [RFC1771] is not congured:
The shortest path to the next-hop is preferred
A route already installed is preferred, unless if bgp bestpath compare-routerid has been
congured
12. The smallest router-id in the originator attribute is preferred (tie breaker).
13. The shortest cluster length is preferred (tie breaker).
14. The smallest peer IP is preferred.
The following table explains the attributes used by the BGP best path selection algorithm.
Attribute Description
Neighbor Weight When all the received routes from one peer should have a higher
preference than routes advertised by another peer, the weight attribute
is used. The weight is congured per peer and when the router has
multiple routes to the same destination, the route with the highest weight
is preferred. The router never advertises this attribute to other peers, i.e.
it has only a local signicance for the router.
Weight Weight can be given also to a specied set of routes in the routing table.
As in the neighbor weight attribute, the scope of this attribute is limited
to a single router.
BGP path selection is performed on the list of path per each prex. For VPN routes, it is possible
that routes only differ by Route Distinguisher (RD). In such case, the algorithm will choose a route
that is "last on the list" for that prex in VRF, for which route evaluation is performed. Typically,
"last on the list" corresponds to a route that is the oldest in the system. Note however, that oldest
in the system does not correlate to a route uptime. Instead, it correlates to the time when a route was
inserted to the list for that specic VRF/RD.
3.4 BGP Routing Policy
Routing policy sets the rules for controlling the ow of routes through a router. BGP routing
policy can be used by Internet Service Providers (ISP) to enforce business relationships between
autonomous systems, by taking into account political, geographical, and administrative, among
other considerations. That is, transit costs, transit agreements, type of agreements and so forth.
Therefore, BGP routing decision process is policy-driven.
The concept of routing policy and preference decisions can be illustrated by the actions a router
applies to route advertisements to its neighbors. As illustrated in Fig. 8, the rst action is inbound
policy, a set of rules that are applied to all incoming routes to determine which routes should be
eliminated from consideration. The routes complying to the set of rules in the rst stage are passed
to the next, which is the decision making process where policy decisions are applied and the best
routes are selected. The best routes in the last stage complying with the outgoing routing policy
are advertised to their destination neighbors.
Tellabs
8600 Smart Routers 76.8600-50121F

44
Fig. 8 BGP Policing and Decision Process
An ISP may implement its policy by means of controlling any of these actions, or by modifying
route attributes to prefer certain routes over the others, or by modifying outbound policy to prevent
certain routes to go via some neighbors. Additionally, with BGP policing, an ISP may opt to modify
the BGP path attributes of an update it advertises to inuence neighbors' path selection.
The BGP inbound and outbound policies are often used to control how the packets enter and exit a
router. They can be categorized as preference, ltering and tagging.
Preference, which can be used to control which route a packet will take for each destination
prex. A preference can be changed by adding, deleting or modifying BGP path attributes in the
advertisement messages.
Filtering, which can be used to scope, or to control how certain routes will be propagated. For
example, for a given prex to prefer one neighbor over another, or certain AS paths over others.
Filtering can be applied as inbound, i.e. before preference, or as outbound after preference is
applied.
Tagging, which allows router administrators to associate additional states with a route. These
states will coordinate the decisions with different routers using community attributes. Therefore,
different routers can perform different tasks within an AS, or share a common context across the
AS boundaries.
3.4.1 Route Map
A BGP route-map is a set of statements or conditions used to control and/or modify the distribution
of the routing information. BGP route-map can be applied to the incoming, the outgoing or the
redistributed routes and only the routes that meet route-map rules can be distributed or modied. A
BGP route-map can be built of a list of match and set statements:
Match condition, which sets the attributes used to evaluate routes where the condition should be
applied.
Set condition, which is used to modify the specied attributes of routes that meet all the match
conditions set in route-map.
In the Tellabs 8600 system, BGP route-map supports: match criteria only, set criteria only, or
both the match and set conditions.
76.8600-50121F Tellabs
8600 Smart Routers

45
A match condition can be implemented for example, with the command options listed below. Please
always refer to Tellabs
8600 Smart Routers CLI Commands Manual for the latest information
on available options.
match as-path <aspathlist>
match community <communitylist>
match community <communitylist> exactmatch
match extcommunity <ecommunitylist>
match extcommunity <ecommunitylist> exactmatch
match ip address <accesslist>
match ip address prex-list <prexlist>
match ip next-hop <accesslist>
match ip next-hop prex-list <prexlist>
match metric <04294967295>
match origin (egp | igp | incomplete)
match vrf <vrfname>
match vrforigin
A set condition can be implemented for example with the command options listed below. Please
always refer to Tellabs
8600 Smart Routers CLI Commands Manual for the latest information
on available options.
set aggregator as <165535> <A.B.C.D>
set as-path prepend <165535>
set atomic-aggregate
set community-list <communitylist> delete
set community [.AA:NN | internet | localAS | noadvertise | noexport] [additive]
set community none
set extcommunity rt .AA:NN
set extcommunity soo .AA:NN
set extcommunity-list <ecommunitylist> delete
set ip next-hop <A.B.C.D>
set local-preference <04294967295>
set metric <04294967295>
set origin (egp | igp | incomplete)
set originator-id <A.B.C.D>
set vpnv4 next-hop <A.B.C.D>
set weight <04294967295>
set mpls-resolution (disable | to-nexthop | to-peer | as-congured)
Tellabs
8600 Smart Routers 76.8600-50121F

46
The BGP route-map instances must be identied by sequence numbers, which are used by
route-map execution algorithm from the lowest to the highest sequence number. BGP route-map
rst evaluates the match criteria. If a match is found, no further instances are evaluated and the
actions are taken as dened by the permit or deny rules. Also some of the attributes might be
modied by the set condition. In the cases when no match condition is found, i.e. the rule is not
applicable to that route, the next sequence is evaluated and so forth until the end of the sequences, or
when a match condition has been found.
BGP route-map can utilize a prex-list as match condition. When a prex-list is used as match
condition, the permit entry is considered as positive match and deny is considered as no match. Both
route-map and prex-list end on implicit default deny rules, i.e. if no entry in route-map or
prex-list matches, then the returned result is deny.
A prex-list can be used directly to lter the prexes from a neighbor. Direct ltering is the most
effective method, especially if the Outbound Route Filter (ORF) is used to push the incoming lter
dynamically to the peer as an outgoing lter. If set actions or a more complex policy is desired, then
prex-list can be used as a match criteria in route-map.
If a single route-map entry contains multiple match-criteria, match of the route-map entry is
determined as follows:
or-match matches if any of the match criteria match
and-match matches if all of the match criteria match
If a single route-map entry has multiple set entries in the event of a match, all of the set entries are
executed. That is, it is possible to perform multiple modication actions in a single route-map entry.
3.5 Route Aggregation
The Tellabs 8600 system supports BGP route aggregation, a tool that provides control of the size of
the distributed BGP routing table. Route aggregation is a process of combining several different
routes in such way that a single route can be advertised.
Route aggregation reduces the amount of routes stored in the Routing Information Base (RIB).
When there are less routes in RIB, it leads to a faster routing convergence, network performance
and reduction in resource consumption (memory and processing power) of a router. However, it
is important to note that route aggregation does not reduce the amount of routes in RIB of the
aggregating router. Instead, the aggregating router's RIB has more routes as it can be seen in the
example presented in Fig. 9 (R1). In this example, router R1 is aggregating routes 172.10.10.0/24
and 172.10.11.0/24 to route 172.10.0.0/16.
76.8600-50121F Tellabs
8600 Smart Routers

47
Fig. 9 Route Aggregation Example
The advantage of route aggregation can only be achieved, if address assignments have been planned
in such manner that allows route aggregation to operate efciently. Therefore, an important factor to
consider is how the IP addresses are allocated. For example, to reduce the amount of advertised
routes in an aggregation, it has to be possible to summarize multiple routes into a single route.
Fig. 10 shows a case where the aggregation in router R1 cannot be performed due to the fact that the
aggregated route would contain also route 172.10.11.0/24, which is not going trough R1. However,
router R2 aggregates the three routes in this example, because there is no other route matching the
prex 172.10.0.0/16 on this network.
Fig. 10 IP Addresses Allocation
Typically, aggregation is performed on the areas' border with separate sub-nets allocated for specic
areas. In practice, it can also be done in router reector but it is not recommended, because all
trafc using the aggregated route will go trough the aggregating node, even if better routes inside
the AS may exist.
Tellabs
8600 Smart Routers 76.8600-50121F

48
To reduce the risks associated with routing loops when using route aggregation, it is recommended
that a static route with lowest priority and matching prex to a null interface is set in the aggregating
router. In this case, when the more specic route is not available, trafc will be routed to the null
interface, i.e. discarded. Thus prevent routing loops. The route to the null interface can also be used
for setting the ICMP behavior, i.e. to transmit ICMP error or not about non-connectivity. In cases
where specic statistics for discarded trafc are of interest, a separate null interface can be created
for the specic aggregate, hence allowing monitoring of discarded trafc.
An empty aggregated route (i.e. without more specic routes) can be created in the system.
However, it will not be advertised until routes are added. It is also important to note that an
aggregate can only be removed when all routes are removed. With route aggregation, some routes
may go down. In such case, the next router will be notied only when the aggregated route is
empty, otherwise no notication is sent.
3.5.1 Conguration Parameters
In the Tellabs 8600 system, route aggregation is congured with command aggregate-address
A.B.C.D/M where the aggregated prex is indicated. In addition, there are several conguration
parameters and options that can be used to control the desired behavior of route aggregation. By
default aggregated routes are not suppressed, which means that the aggregated route is advertised
along with the original more specic routes. The option summary-only can be used to suppress
the original routes so that only the aggregated route is advertised. There is also another option the
unsuppress-map that can be used to disable the suppression based on various criteria. The
criteria can be for example, a specic IP address range or a specic BGP neighbor. This is useful if
the original specic routes are needed by some of the BGP neighbors.
The AS_PATH attribute is used to store information of which autonomous systems a route has
traversed. Since route aggregation creates a new route, as a result that will cause the loss of the
aggregated routes AS_PATH information. The option as-set can be used to summarize the
AS_PATH information of all the more specic routes and add that information to the aggregate route.
3.5.2 BGP VPN Route Aggregation
VPN route aggregation is also supported with the VRF routes. The aggregation is VRF specic and
does not affect other VRF(s). The aggregates in VRF are not eligible to be locally redistributed
to other VRFs. However, it is possible to import routes to multiple VRFs. In such case, only the
routes in the same VRF as the aggregate are affected by aggregation, thus suppressed routes are not
prevented to be redistributed to other VRFs. Also routes in the global BGP routing table are not
affected by route aggregation in VRFs. Multiple aggregations with different prexes to a single
VRF, or multiple aggregations with same prex to different VRFs are possible to congure in the
system. The routers without VRF congured cannot perform VPN route aggregation. This might be
the case with non-data path router reectors.
An application network where a VPN route aggregation is used in multiple nodes and multiple
VRFs is shown below. The arrows show which routes are advertised throughout the network. In this
example, NODE-2 aggregates four routes into two, i.e. one aggregated route for each VRF. As a
result, NODE-2 will advertise only two routes to NODE-1 instead of four original routes.
76.8600-50121F Tellabs
8600 Smart Routers

49
Fig. 11 BGP Routes Aggregation for VPNs
VPN route aggregation is congured in similar manner as route aggregation, with the exception of
route aggregation commands being entered under the address family VRF mode. An example of
VPN route aggregation conguration is provided in 4.2 Route Aggregation Conguration.
3.5.3 Route Aggregation Support
NE BGP BGP VPN
Tellabs 8605 smart router Yes No
Tellabs 8620 smart router Yes Yes
3.6 Route Flap Damping
A node or link failure, or misconguration may cause a route to ap, i.e. to appear and disappear
from the BGP routing table at irregular and short intervals. In case a route is not hidden behind route
aggregation, but exists in a BGP routing table, the instability can cause a large amount of additional
control trafc and processing load to the BGP peer routes throughout the entire network.
Tellabs
8600 Smart Routers 76.8600-50121F

50
To avoid BGP messages triggered by an instable route, a router should not advertise any route until it
has a certain degree of condence that the route remains stable. Route Flap Damping (RFD) (dened
in [RFC2439] and usage recommendations described in [ripe-178], [ripe-210] and [ripe-229]) is a
mechanism used in BGP to control the instability caused by a route apping. This is accomplished
by suppressing the routes that ap and stopping those routes from being advertised. Thus, reducing
the processing load caused by BGP update messages and maintaining the stability of the network.
The operation of RFD algorithm is illustrated in the following gure.
Fig. 12 RFD Algorithmic Operation
As illustrated in Fig. 12, a route's instability history is monitored by the RFD algorithm. When a new
route is learned, RFD assigns to it an initial penalty of zero, which means no instability history for
the route. If a route withdrawn message is received, the corresponding route will get a penalty (for
route attribute changes, only half of the penalty is assigned). The RFD will cumulatively increase the
penalty, if a route further exhibits instability. When a cumulative penalty of a certain route exceeds
a predened suppress threshold, the corresponding route is considered to be unstable and the
advertisements of this route are suppressed. During the suppression period, new updates may still be
received and the penalty value will also increment accordingly until the ceiling threshold is reached.
If the ceiling threshold is reached, then the accumulated penalties value is set to ceiling limit.
Over time, the penalty decays exponentially based on the half-life time parameter. When the
cumulative penalty drops below the reuse threshold, a route is unsuppressed, i.e. advertised
again. In the Tellabs 8600 system, the ceiling for accumulated penalties (Pmax) is internally
calculated as following:
Pmax = reuse*2^(max_suppress / half_life)
The ceiling limit is calculated in a way that the time to decay the penalty from ceiling
threshold to reuse limit is the max-suppress time. Thus, the accumulated penalties cannot
go over the ceiling limit.
76.8600-50121F Tellabs
8600 Smart Routers

51
3.6.1 RFD Conguration
In the Tellabs 8600 system RFD is disabled by default. It can be enabled on all routes, or only on
routes received by certain BGP peers. The RFD settings are based on predened parametrization
defaults [RFC2439]. The original RFD parameters were very strict and too aggressive, which led the
RFD to be considered harmful rather than helpful [ripe-378]. However, recently more conservative
parameterization has emerged, e.g. [draft-ietf-idr-rfd-usable] that makes RFD usable and reduces
the high risks imposed by default parameters.
The node default parameters are too aggressive. Therefore, RFD parameters must be chosen
with careful consideration [draft-ietf-idr-rfd-usable].
The following table lists the RFD parameters supported. There are four tunable parameters, which
the user can control to specify the desired behavior of the RFD algorithm.
Parameter Conguration Default
withdrawal penalty No 1000
re-advertisement
penalty
No
attribute change
penalty
No 500
half-life (min) Yes
The parameter is congurable in a range of 1..45
minutes.
15
reuse threshold Yes
The parameter is congurable in a range of 1..20000.
750
suppress threshold Yes
The parameter is congurable in a range of 1..20000
2000
max-suppress time (min) Yes
The parameter is congurable in a range of 1..255.
Maximum suppression duration is dynamically
calculated to be 4 * half-life time.
60
Tellabs
8600 Smart Routers 76.8600-50121F

52
3.7 Route Refresh
Routing policies may change from time to time, or when adding new links or new peering
relationships with other entities. For example, in cases where there is a change to inbound policy of
a BGP router, a new ltering must be performed to all updates received from the BGP peers. One
option to solve this problem is to store locally an unmodied copy of the received route information
and reprocess it without a need to involve the peers that have sent the updates. However, as it can
be seen this option consumes more resources on the BGP router, especially in cases where there
are multiple peering relationships. Another solution to this problem is the route refresh capability
specied in [RFC2918]. A mechanism by which a local BGP router can request a copy of the
Adj-RIB-Out database of the peer.
During session establishment, the peers willing to use the route refresh option must negotiate the
ability using BGP capabilities advertisement. By advertising the route refresh capability to a peer,
a BGP router conveys to the peer its capability of receiving and handling properly route refresh
messages. Thus, a BGP router may only send route refresh message to a peer, if that peer supports
the route refresh capability.
When changing inbound policy, a route refresh based inbound re-conguration must be used.
The re-conguration is done with command clear ip bgp *|A.B.C.D AF in (where A.B.C.D is
the IP address of the BGP route to be refreshed). Similarly, when changing the outbound policy
use outbound soft re-conguration with command clear ip bgp *|A.B.C.D AF out. Also when
some BGP attributes are changed, BGP connection must be reset for the conguration change to
take effect.
3.8 Increasing AS Scalability
The terms used in this chapter are dened in 3.1 Overview. Due to the fact that iBGP routers
do not forward routing information to other peer routers in the same AS, a full mesh peering
connectivity is required in an AS. If there are N iBGP routers in an AS, then N(N-1)/2 connectivity
is required. In case of large AS, such large connectivity will lead to a scalability problem. This
problem can be avoided, either by using Route Reector (RR) or confederation, which are described
in the following chapters.
3.8.1 Route Reector
Route reection [RFC2796] is a mechanism describing the operation of a BGP router (known as
RR) that redistributes routing information to other iBGP speakers. Thus, eliminating the need of
iBGP full mesh within the AS. In an AS, one or more BGP routers can be set to act as RR(s) and
other routers as clients that connect to the RR(s). In this case, BGP sessions between the clients
are no longer required. The operation of the client routers depends on the RR to re-advertise their
routing information to the entire AS and also to learn about routes from the network.
A RR along with its client routers forms a cluster. Within a cluster, the client routers have a BGP
session to RR. However, client routers may on the other hand peer with external BGP speakers. The
BGP peers outside a cluster are known as non-clients and are required to have a BGP session to the
RR. RR redistributes route information to both the clients and the non-client routers. The following
diagram illustrates the basic concept of a network topology with RR.
76.8600-50121F Tellabs
8600 Smart Routers

53
Fig. 13 RR Topology
To improve network reliability and to prevent a single point of failure, a redundancy can be used
by setting more than one RR in a cluster as illustrated in Fig. 3. In such scenarios, route reectors
will have an iBGP session with each other and the clients to the both route reectors. In order to
prevent routing loops, both route reectors must be set up with the same cluster-id. Please see
conguration example details in 4.3.1 Route Reector Conguration.
Operation
RR uses the standard BGP rules to determine the best path when multiple routes to the same
destination exist. However, apart from the standard rules, RR follows additional basic rules that are
specic to its operation and are designed to prevent routing information loops.
Routes froma client peer are reected to all the clients and the non-client peers, with the exception
of the client that is advertising.
Routes from non-client iBGP peers are reected to the client peers only.
Routes from an eBGP peer are reected to all the client and the non-client peers.
In its operation RR performs the following tasks when reecting the updates:
RR sets an ORIGINATOR_ID attribute in the reected update, if it is not already set.
RR adds a cluster-id to the CLUSTER_LIST attribute in the reected update.
RR reects only routes selected as best routes. If more than one update is received for the same
destination, only the best route will be reected.
RR must preserve any attributes of the reected routes especially the NEXT_HOP attribute.
Tellabs
8600 Smart Routers 76.8600-50121F

54
Attributes
Due to the fact that RR eliminates the requirement of full meshed connectivity, then when a route
is reected, it is possible to form route redistribution loops. To prevent situations where route
reection may potentially cause routing loops, the following path attributes [RFC2796] are used
in RR operation:
ORIGINATOR_ID. This is an optional non-transitive attribute. An ORIGINATOR_ID is a router
ID of the originating route within the local AS. A RR is not allowed to reect a route back to the
originator of the same route. If reection back for some reasons may occur, the originator will
discard any update message received with its own router ID. Obviously, a BGP speaker is not
allowed to create multiple ORIGINATOR_ID attributes.
CLUSTER_LIST. This is an optional non-transitive attribute used to trace the sequence of
cluster-id values that represent a reection path through which a route has traversed. It
is similar to the way the AS_PATH attribute traces AS numbers. Within an AS, there may be
multiple clusters and each cluster is identied by a cluster-id. When a cluster has only one
RR, then the cluster-id is the router ID of the RR. But when a cluster has multiple route
reectors, then each RR in the cluster has to be set with the same cluster-id.
When a RR reects a route, it must append a local cluster-id to the CLUSTER_LIST. If a
CLUSTER_LIST is empty, RR will create a new one. By using this attribute, RR can identify if
routing information is looped back to the same cluster. If the local cluster-id is found in
the CLUSTER_LIST, the advertisement received will be discarded.
3.8.2 AS Confederation
An alternative solution to avoid iBGP full-mesh scaling problem is to divide an AS into multiple
sub-AS domains. These sub-autonomous systems are used only internally, i.e. inside the AS, and
only the original AS number is shown outside. A private AS numbering may be allocated to each
sub-AS and full mesh iBGP peering is provided inside each sub-AS. The sub-autonomous systems
are connected together using eBGP. With this hierarchical approach, the total number of peering
connectivity inside an AS can be kept within manageable limits.
76.8600-50121F Tellabs
8600 Smart Routers

55
Fig. 14 AS Confederation
In large scale networks, the network topology can use both RR and AS confederation. In the Tellabs
8600 system, AS confederation are congured with the aid of the commands listed in the following
table. Please refer to 4.3.2 Conguring AS Confederation for a detailed conguration example.
Command Description
bgp confederation identier
id
The command sets BGP AS confederation identier. The identier is
the confederation domain AS number.
bgp confederation peers
asn
The command species peering relationship between sub-autonomous
systems forming the confederation. All sub-AS peers within a
confederation must be listed in this command.
3.9 BGP Failover
When BGP detects that a route is unusable due to lack of connectivity, the route in question
is deselected. This allows selecting some alternative route to carry trafc and allows BGP to
circumvent network failures. Depending on the BGP session type, lack of connectivity is detected in
different ways. These are explained in the following sub-chapters.
3.9.1 iBGP and Multihop eBGP Sessions
Both iBGP and multihop eBGP are characterized by the fact that they produce recursive routes, that
is, routes whose next-hop needs expansion by IGP. For routes received over these session types,
BGP determines route eligibility with two criteria:
Tellabs
8600 Smart Routers 76.8600-50121F

56
Ability to resolve next-hop recursion
BGP session liveliness
BGP session liveliness is more a safeguard than practical thing. BGP default hold-time is three
minutes and that is far too long time for practical recovery. This leaves ability to monitor next-hop
availability as primary trigger. Depending on the route type, next-hop can either be an IGP route
or an MPLS LSP. BGP receives event based information on both LSP and next-hop availability
and can react in milliseconds from the detected failure. Fast BGP reaction can hence be guaranteed
as long as the underlying next-hop or MPLS LSP failure detection is provided. Information for
this is derived from multiple sources:
OSPF and IS-IS liveliness
IP BFD on each link (also on remote nodes (communicated via OSPF, IS-IS, RSVP))
Link state (both on local node and on remote nodes (communicated via OSPF, IS-IS, RSVP))
The user can tune how quickly BGP reacts to next-hop changes by conguring router bgp / bgp
path-selection-delay. This timer can be used to dampen short connectivity aps. However, for
quick recovery the timer can also be disabled or congured to sub-second values. By default
path-selection-delay is 2 seconds, so that BGP topology does not react to transient IGP
changes. For quick protection path-selection-delay should be set to 0.
3.9.2 Single Hop eBGP
Single hop eBGP is characterized by the fact that routes generated are always non-recursive. That
is, a BGP peer is directly connected and hence all routes point to a next-hop that can be directly
used by the forwarding plane. For these routes route eligibility is validated by monitoring eBGP
session liveliness. The following three mechanisms can be utilized:
BGP keepalives
BGP fast external failover
Single hop IPv4 BFD
With the default timers, BGP keepalives detect session failure in three minutes, which is too long
time for practical purposes. While these timers can be shortened, this increases CPU consumption
and the timers cannot hence be made short enough for a reasonable large number of BGP sessions.
When link down notications are reliable (no L2 switches or other devices between BGP speakers),
BGP fast external failover can be congured for the neighbor. Fast external failover works by
monitoring link down events. When a link down event is noted, any single-hop eBGP neighbor
with fast external failover congured will be checked to see if there is a valid interface (in up
state) where the interface prex contains the peer address. If not, then the peer is torn down. It is
typical conguration error to forget multihop conguration statement from loopback to loopback
connection that is a single hop away. Such neighbors are technically speaking multihop (even if TTL
check does not prevent BGP session from forming), and hence by the rule above fail fast external
failover check, causing these BGP sessions to ap whenever any interface goes down.
The most reliable method is to congure a single hop BFD to monitor BGP neighbor. BGP session
is kept down unless associated BFD session is up. Lenient mode can be congured to facilitate
interoperability. In lenient mode only BFD UP->DOWN transitions are monitored (that is, BFD
is not a requisite for BGP session formation, but once BFD is up, any downward transition will
cause BGP session to be torn down). As lenient mode allows BGP session to come up before
BFD, some failures may go undetected (e.g. if remote node does not speak BFD or some error in
the network prevents BFD packet forwarding).
76.8600-50121F Tellabs
8600 Smart Routers

57
While single hop BFD can be congured for iBGP neighbors and multihop eBGP neighbors, it
should be noted that single hop BFD only works on connections that are truly single hop. If this
connection is not available, BGP session gets torn down (that is, even if an alternative path allowed
by multihop session type would be available).
3.9.3 Performance of BGP Failover
The Tellabs 8600 system does not have BGP PIC (Prex Independent Convergence). Any major
BGP failover event will take time that linearly depends on the number of routes involved. In case of
multihop sessions, using protected MPLS LSPs (RSVP-TE one to one protection and RSVP-TE
FRR) allows avoiding convergence changes, as LSP protection is implemented in prex independent
manner. Hence, it is recommended to use multihop sessions and protected LSPs for link protection
and reserve BGP level failover for border node protection.
As the Tellabs 8611 smart router, Tellabs 8630 smart router and Tellabs 8660 smart router have fully
redundant control cards that are able to maintain BGP forwarding during switchover (via use of
BGP graceful restart extension), border node failure is an extremely rare event.
3.10 BGP Multiprotocol Extension
BGP is originally intended to carry routing information for IPv4. Multiprotocol support extends
BGP-4 to carry routing information for other network layer protocols such, as IPv6, IPX, IP VPNs
etc. The supported protocols are advertised to other peers during the BGP capability negotiation.
The extension is specied in [RFC2858]. For more information on how the Tellabs 8600 system
and Multiprotocol BGP (MP-BGP) is used for creating and managing IP VPNs, refer to Tellabs
8600 Smart Routers VPNs Conguration Guide.

Tellabs
8600 Smart Routers 76.8600-50121F

58
3.11 BGP References
John W. Stewart's book BGP4
Inter-Domain Routing in the
Internet
Stewart, John W., III. (1999). BGP4: Inter-Domain Routing in the
Internet. The Addison-Wesley Networking Basics Series.
[draft-kulmala-l3vpn-interas-
option]
draft-kulmala-l3vpn-interas-option-d-02.txt (200602), ASBR VRF
context for BGP/MPLS IP VPN
[draft-ietf-idr-rfd-usable] draft-ietf-idr-rfd-usable-00 .txt (201206), Making Route Flap
Damping Usable
[RFC1771] RFC1771 (199503), A border gateway protocol 4 (BGP-4)
[RFC1772] RFC1772 (199503), Application of the border gateway protocol
in the Internet
[RFC1966] RFC1966 (199606), BGP route reection - an alternative to full
mesh iBGP
[RFC1997] RFC1997 (199608), BGP communities attribute
[RFC2283] RFC2283 (199802), Multiprotocol extensions for BGP-4
[RFC2439] RFC2439 (199811), BGP route ap damping
[RFC2796] RFC2796 (200004), BGP route reection - an alternative to full
mesh iBGP
[RFC2842] RFC2842 (200005), Capabilities advertisement with BGP-4
[RFC2858] RFC2858 (200006), Multiprotocol extensions for BGP-4
[RFC2918] RFC2918 (200009), Route refresh capability for BGP-4
[RFC3065] RFC3065 (200102), Autonomous system confederations for BGP
[RFC4271] RFC4271 (200601), A Border Gateway Protocol 4 (BGP-4)
[RFC4360] RFC4360 (200602), BGP Extended Communities Attribute
[RFC4724] RFC4724 (200701), Graceful Restart Mechanism for BGP
[ripe-178] ripe-178 (199802), RIPE Routing Working Group Recommendation
for coordinated route-ap damping parameters
76.8600-50121F Tellabs
8600 Smart Routers

59
4 BGP Conguration Examples
This section provides CLI examples of conguring BGP. Note that the loopback interface is the
recommended way of dening the update source, as it will always be reachable. In the case of
several links connecting two BGP peers, if one of the interfaces IP address was used as the update
source and this interface for some reason goes down, the BGP session would also be affected.

The terms used in this section are dened in 3.1 Overview.
4.1 Basic Congurations
This chapter gives some CLI examples of basic BGP features conguration. The network shown in
the gure below is used for the basic congurations.
Fig. 15 BGP Features Basic Conguration
Tellabs
8600 Smart Routers 76.8600-50121F

60
4.1.1 BGP Neighbor and Path
A minimum of steps required to establish a BGP peer session congurations are as following:
Creating a BGP process
Conguring BGP peers/neighbors
Dene the networks to be advertised
Path Conguration in AS65237
In this example we will create a BGP process, under which all three nodes are congured to form an
internal neighbor relationship, i.e. iBGP session. In addition, Node-202 will be congured to form
an external neighbor relationship with Node-203.
Node-202 conguration:
Step 1 Enable BGP routing process. The number 65237 species the AS number where Node-202 is
located.
node-202(config)# router bgp 65237
Step 2 Dene for Node-202 BGP neighboring connectivity. In this example, it is dened by their loopback
address as the updating source.
node-202(cfg-bgp[65237])# neighbor 205.205.205.205 remote-as 65237
node-202(cfg-bgp[65237])# neighbor 205.205.205.205 update-source lo0
In Fig. 15 routers Node-203 and Node-202 are connected to network 36.36.36.0/24. To make them
neighbors and to exchange routing information, the following conguration step is required.
Step 1 Dene Node-203 as BGP neighbor. Due to the fact that Node-203 resides in different AS
(AS65219), this will establish an eBGP session.
76.8600-50121F Tellabs
8600 Smart Routers

61
Step 1 Enable BGP routing process.
Step 2 Dene for Node-201 BGP neighboring connectivity.
Step 3 Dene the networks to be advertised by Node-201 BGP.
node-201(cfg-bgp[65237])# network 2.2.2.0/24
node-201(cfg-bgp[65237])# exit
Step 3 Dene the networks to be advertised by Node-205 BGP.
Path Conguration in AS65219
Node-203 conguration
Node-200 conguration
Step 1 Enable BGP routing process
Step 2 Dene Node-203 as BGP neighbor to establish an iBGP session.
Tellabs
8600 Smart Routers 76.8600-50121F

62
BGP Status
In the Tellabs 8600 system, there are several options available to verify the status of BGP. For more
details please refer to Tellabs
8600 Smart Routers CLI Commands Manual.

The following gures show examples of BGP status displayed with different options of the show
command:
Fig. 16 Node-202 BGP Status
Fig. 17 Node-201 BGP Status
76.8600-50121F Tellabs
8600 Smart Routers

63
Fig. 18 BGP Neighbor Status
4.1.2 BGP Routing Policy Conguration
This example shows how to use BGP routing policy by route-map. The conguration is based on the
topology depicted in Fig. 15. The example will cover the following procedures:
Create a prex-list
Use prex-list match criteria with route-map
Use route-map with set option to modify local preference
Use route-map to lter the outgoing advertisements
Use route-map to modify policy
Conguration
First we are creating BGP routing policy to modify the local preference with set options. In this
example, 1.1.1.0 and 5.5.5.0 are the routes injected into Node-205 BGP process.
Tellabs
8600 Smart Routers 76.8600-50121F

64
Step 1 Create a prex-list BGP-prex which will permit routing information from 1.1.1.0/24.
node-205(config)# ip prefix-list BGP-prefix seq 1 permit 1.1.1.0/24
Step 2 Create a route-map instance to match a prex-list and set AS path and its local preference.
node-205(config)# route-map BGP-rmap permit 1 and-match
node-205(cfg-route-map[BGP-rmap])# match ip address prefix-list BGP-prefix
node-205(cfg-route-map[BGP-rmap])# set as-path prepend 100
node-205(cfg-route-map[BGP-rmap])# set local-preference 500
node-205(cfg-route-map[BGP-rmap])# exit
Step 3 Use the route-map to lter the outgoing advertisements.
node-205(cfg-bgp[65237])# neighbor 201.201.201.201 route-map BGP-rmap out
Fig. 19 BGP Routing Policy Status
Fig. 19 shows prex 1.1.1.0 having a local preference 500 and as-path 100 prepended. Notice that
prex 5.5.5.0 is blocked due to the default implicit deny rule.
In the following case, we use route-map to modify the policy to avoid the implicit deny rule.
Step 1 Use route-map to modify routing policy.
node-205(config)# route-map BGP-rmap permit 2 and-match
node-205(cfg-route-map[BGP-rmap])# exit
After the conguration above, the status displayed of the BGP network is shown in the following
gure. Notice that network 5.5.5.0 is now visible.
76.8600-50121F Tellabs
8600 Smart Routers

65
Fig. 20 BGP Network Information
4.1.3 BGP Authentication
BGP authentication allows routers to validate and maintain their BGP neighbor relationship, thus
enhancing security of the network. When BGP authentication is enabled on a router, any TCP
segment that belongs to BGP between the peers is checked and validated. Integrity, authentication
and replay protection is guaranteed for the whole TCP session. For the purposes of authentication to
be successful, the peers must be congured with the same password.
Step 1 Specify Node-202 neighbor 36.36.36.203 password as myBgpPassword.
node-202(cfg-bgp[65237])# neighbor 36.36.36.203 password myBgpPassword
Step 2 Specify Node-203 neighbor 36.36.36.202 password as myBgpPassword.
node-203(cfg-bgp[65219])# neighbor 36.36.36.202 password myBgpPassword
4.1.4 BGP Connection Reset
Resetting BGP sessions must be avoided at all costs. Resetting a BGP session causes forwarding
breaks that can take minutes. Instead, use rout-refresh-based re-conguration (inbound) that is
supported by almost all routers. For the outbound policy changes use outbound soft re-conguration.
Also, if some attributes are changed subsequently, BGP connection must be reset for the
conguration change to take effect. The following is an example showing how to reset BGP
connection after changes have been applied to outbound policy.
Step 1 Reset BGP session to 36.36.36.203.
node-202# clear ip bgp 36.36.36.203 out
To perform a full reset of all BGP sessions use the step provided below.
Step 1 Reset all Node-202 BGP connections.
node-202# clear ip bgp *
Tellabs
8600 Smart Routers 76.8600-50121F

66
For more details about BGP reset options supported, please refer to Tellabs
8600 Smart Routers

CLI Commands Manual.
4.2 Route Aggregation Conguration
This chapter provides a conguration example of routes aggregation for BGP VPNv4 applications.
The main focus here is in the aggregate functionality only and it is assumed that a BGP process
and VRF have to be congured separately. For BGP process basic congurations refer to 4.1 Basic
Congurations and for VPNs, please refer to Tellabs
8600 Smart Routers VPNs Conguration

Guide. The topology used for this example is depicted in Fig. 11, where routes aggregation is
performed in NODE-1 and NODE-2.
BGP route aggregation for non VPNs routes is congured in similar way under BGP process, i.e.
without the usage of address-family conguration mode.
The conguration tasks are:
Enable BGP routing process
Enable the address-family conguration mode
Congure BGP aggregate entries
4.2.1 NODE-1 Conguration
Assuming that VRF and BGP have been already congured, the status of NODE-1 BGP routing
table is presented as following:
Fig. 21 BGP Routing Table without Route Aggregation
Step 1 Enabling BGP routing process.
Step 2 Enable exchange of VRF information and enter command mode to address-family VRF mode.
node-1(cfg-bgp[65000])# address-family ipv4 vrf VRF-2
Step 3 Congure BGP route aggregation entry in NODE-1 for VRF2 route.
node-1(cfg-bgp[6500]-af-vrf[VRF-2])# aggregate-address 88.0.0.0/15 summary-only
as-set
node-1(cfg-bgp[6500]-af-vrf[VRF-2])# exit
76.8600-50121F Tellabs
8600 Smart Routers

67
4.2.2 NODE-2 Conguration
The conguration of NODE-2 will have two route aggregation entries for VRF1 and VRF2 routes.
Step 1 Enabling BGP routing process.
Step 2 Enable exchange of VRF information and enter command mode to address family VRF mode.
Step 3 Congure BGP route aggregation rst entry in NODE-2 for VRF1 route.
as-set
Step 4 Enable exchange of VRF information and enter command mode to address-family VRF mode.
Step 5 Congure BGP route aggregation second entry in NODE-2 for VRF2 route.
as-set
4.2.3 Conguration Status
After the conguration above, the BGP forwarding table for NODE-1 and NODE-2 with route
aggregation are presented in the following gures.
Fig. 22 NODE-1 BGP Routing Table
Tellabs
8600 Smart Routers 76.8600-50121F

68
Fig. 23 NODE-2 BGP Routing Table
4.2.4 Conguration with Suppression Disabled
The following example illustrates how to use the option unsuppress-map to disable suppression
of routes in VRF1 connected to the neighbor NODE-1.
Step 1 Create a route map instance and set the matching criteria.
node-2(config)# route-map rmap-99 permit 11 or-match
node-2(cfg-route-map[11#])# match vrf VRF-1
node-2(cfg-route-map[11#])# exit
Step 2 Disable suppression of VRF1 routes in the neighbor NODE-1.
node-2(config)# bgp 65000
node-2(cfg-bgp[65000])# address-family vpnv4 unicast
node-2(cfg-bgp[65000]-af)# neighbor 10.120.100.167 unsuppress-map rmap-99
After the conguration above, the BGP routing table at NODE-1 is presented in the following gure.
Fig. 24 BGP Routing Table with Suppression Disabled
76.8600-50121F Tellabs
8600 Smart Routers

69
4.3 Advanced Congurations
This chapter provides conguration examples of BGP RR and AS confederation. The terms used in
this chapter are dened in 3.1 Overview.
4.3.1 Route Reector Conguration
The following is an example showing how to congure a topology with RR. To prevent single point
of failure, two route reectors will be set within a cluster and in order to avoid routing loops,
route reectors are set with same cluster-id = 100. More details about RR overview, please
refer to 3.8.1 Route Reector.
Fig. 25 RR Conguration Topology
When using RR, the BGP topology, i.e. RR peer relationships do not necessarily have to match
with physical topology and does not make trafc owing through RR, if alternative paths exist
in the network.
Conguration tasks:
Dene BGP routing process
Set RR and its clients
Set cluster-id
Dene BGP peer relationship connectivity
Tellabs
8600 Smart Routers 76.8600-50121F

70
Route Reectors Conguration
RR10
Step 1 Dene BGP routing process.
node10(config)# router bgp 65100
Step 2 Dene RR20 as BGP neighbor, which will establish an iBGP session between RR10 and RR20. The
loopback address is used as the updating source.
Step 3 Dene R3 as BGP neighbor. R3 is a client of RR.
Step 4 Set R3 as RR10 client. This will set RR10 as RR.
node10(cfg-bgp[65100])# neighbor 3.3.3.3 route-reflector-client
Step 6 Set R4 as RR10 client.
Step 7 Dene R5 as BGP neighbor. R5 is non-client to RR.
Step 9 Set cluster ID for RR10. Note that to avoid routing loops both RR10 and RR20 are set with same
cluster ID.
node-10(cfg-bgp[65100])# bgp cluster-id 100
RR20
Step 1 Dene BGP routing process.
Step 2 Dene RR10 as BGP neighbor. This will establish an iBGP session between RR10 and RR20.
76.8600-50121F Tellabs
8600 Smart Routers

71
Step 4 Set R3 as RR20 client. This will set RR20 as RR.
Step 6 Set R4 as RR20 client.
Step 9 Set cluster ID for RR20. Note that to avoid routing loops both RR10 and RR20 are set with same
cluster ID.
node-20(cfg-bgp[65100])# bgp cluster-id 100
R3 Conguration
Step 1 Dene BGP routing process for R3.
Step 2 Dene for R3 BGP peering connectivity to establish an iBGP session with RR10 and RR20.
node3(cfg-bgp[65100])# neighbor 10.10.10.10 remote-as 65100
node3(cfg-bgp[65100])# neighbor 10.10.10.10 update-source lo0
node3(cfg-bgp[65100])# exit
R4 Conguration
R5 Conguration
Tellabs
8600 Smart Routers 76.8600-50121F

72
Step 2 Dene R6 as BGP peer. R5 and R6 are non-client BGP speakers, therefore an iBGP session between
them must be established.
R6 Conguration
Step 2 Dene for R6 BGP peering connectivity to establish iBGP sessions with peers.
4.3.2 Conguring AS Confederation
The following is an example showing how to congure a topology where AS confederation is used.
For a detailed overview of BGP confederation, please refer to 3.8.2 AS Confederation.
76.8600-50121F Tellabs
8600 Smart Routers

73
Fig. 26 AS Confederation Topology
In Fig. 26, the AS confederation (ID=65100) is formed by three sub-autonomous systems (AS100,
AS101 and AS102). The entire AS confederation is seen by external eBGP routers (R3 in this
example) as a single AS65100.
Conguration tasks:
Split the AS into sub-autonomous systems
Dene BGP routing process
Set the AS confederation ID, which identies all sub-autonomous systems in a confederation
Dene peers relationship connectivity
R30 Conguration
Step 1 Dene BGP routing process for R30. R30 is located in sub-AS 100.
Step 2 Specify BGP AS confederation identier. The AS confederation ID is seen as a single AS by
external eBGP routers.
node30(cfg-bgp[100])# bgp confederation identifier 65100
Step 3 Specify sub-AS 101 and 102 as members of the AS confederation.
node30(cfg-bgp[100])# bgp confederation peers 101 102
Step 4 Dene for R30 BGP peering connectivity.
Tellabs
8600 Smart Routers 76.8600-50121F

74
R40 Conguration
Step 1 Dene BGP routing process for R40. R40 is an iBGP router located in sub-AS 100.
Step 2 Specify BGP AS confederation identier.
Step 3 Dene R30 as a BGP peer.
R1 Conguration
Step 3 Specify sub-AS 100 and 102 as member of the AS confederation.
node-1(cfg-bgp[101])# bgp confederation peers 100 102
R2 Conguration
Step 3 Specify sub-AS 100 and 101 as member of the AS confederation.
node2(cfg-bgp[102])# bgp confederation peers 100 101
76.8600-50121F Tellabs
8600 Smart Routers

75
R3 Conguration
Step 1 Dene BGP routing process for R3. R3 is an external eBGP router located in AS 65101.
Tellabs
8600 Smart Routers 76.8600-50121F

76
5 IS-IS
5 IS-IS
5.1 Overview
Intermediate System to Intermediate System (IS-IS) is a link-state routing protocol which belongs to
the group of IGPs. It is originally specied by ISO in [ISO10589] providing network services for
the ISO transport protocols which do not need to have any interworking with TCP/IP protocols.
The Tellabs 8600 system supports an integrated IS-IS version which is specied by the IETF in
[RFC1195]. Integrated IS-IS supports the exchange of intra-domain routing information for the
network which uses TCP/IP-based protocols. IS-IS also species the End System to Intermediate
System (ES-IS) protocol for the host-server adjacency discovery but in the IP environment other
methods such as Address Resolution Protocol (ARP) are used.
76.8600-50121F Tellabs
8600 Smart Routers

77
5 IS-IS
5.2 Routing Areas
IS-IS supports two-level routing hierarchy to enable routing scalability in large networks. This is
achieved by splitting the network to areas and dedicating the router to be an intra-area router (level
1) or an inter-area router (level 2) or both at the same time. All routers which belong to the same
area share the full routing information between each other and are aware of the intra-area topology.
The benet of a single area routing is that all routers can make the optimal routing decision as
they have the full topology information. The drawback appears in single area routing when the
size of the level 1 area grows while the amount of the routing information to be shared between
the routers increases rapidly.
In multiarea routing the network is divided to areas and each router is assigned to a single area.
The areas prevent the ooding of the level 1 routing information outside the area. The areas
communicate with each other via level 2 routers. Each area has a connection to the backbone via at
least one level 2 router which can act simultaneously also as level 1 router. Each level 1 router uses
the nearest level 2 router for the trafc designated to another area. As the selection of level 2 router
is done using only local information it may lead to suboptimal routing. In such a case it is possible
to manually dene another level 2 router associated to the area to be the gateway to the backbone
to support the most optimum routing from the whole network point of view. This is referred to as
route leaking. Level 2 routers build their own level 2 routing domain in which the dedicated level 2
routing information is shared between the routers.
Fig. 27 IS-IS Routing Hierarchy
Tellabs
8600 Smart Routers 76.8600-50121F

78
5 IS-IS
5.3 Addressing
IS-IS requires each router to have a Network Service Access Point (NSAP) address which consists
of an area ID and a system ID, both of variable lengths and an NSAP selector (NSEL) (1 byte) eld.
The maximum length of an NSAP address is 20 bytes. The router is identied by using a network
address, a Network Entity Title (NET) which consists of an area ID and a system ID while an
NSEL is set to zero. The rst byte of the network address is referred to as an Authority and Format
Identier (AFI) which identies the used addressing domain.
The Tellabs 8600 system uses a 6-byte system ID and a variable of 1...13 bytes while the NSEL
is set to 0. The addressing schema can be simplied for the IP routing application to keep the
minimum addressing requirements. IS-IS requires that each router has a unique system ID inside a
single area and the level 2 router also has a unique domain-wide area ID. Any unique value can
be used to form a NET address but a very popular way is to derive the system ID from the routers
dotted decimal loopback IP address and add zeros to build up 12-digit addresses and convert this to
a 6-byte hexadecimal format. One byte is reserved for the AFI and two bytes are reserved for the
area ID as presented in the following:
IP loopback address 123.23.123.3
AFI= 49 (local address domain)
area1=0001
NSEL=00
49.0001.1230.2312.3003.00
76.8600-50121F Tellabs
8600 Smart Routers

79
5 IS-IS
Fig. 28 NSAP Address Format and Simplied NSAP Address Format.
5.4 Multihoming
It is possible to assign several NET addresses having the same system ID to the same router which
causes the area to be visible with several area addresses while the router still belongs to a single
area. This effectively results in a router to merge two areas together and can be used to migrate
existing areas to a single area or split an area to several areas without causing interruptions in the
service. This addressing scheme is known as multihoming. The routing of multihoming areas is
processed by a single IS-IS process (instance).
5.5 Multiarea Routing
The Tellabs 8600 system enables the creation of several level 1 IS-IS routing processes (instances)
into the same NE while only one level 2 process can be created. Each level 1 process has its own
routing database. A particular interface can only belong to one level 1 area at the time.
This feature can e.g. be used to create an isolated routing network for Data Communications
Network (DCN) trafc without additional equipment.
Tellabs
8600 Smart Routers 76.8600-50121F

80
5 IS-IS
5.6 Open Shortest Path Algorithm
IS-IS uses the open shortest path algorithm in each individual router to calculate the optimum
paths to various destinations and the result is used to dene a routing table. The router runs the
Constrained Shortest Path First (CSPF) calculation periodically and it is possible to dene the
calculation interval. The CSPF is run separately for level 1 and level 2 link-state database.
5.7 Adjacencies and Hello Packets
IS-IS species protocols to solve ES-IS (host-router) and IS-IS (router-router) adjacencies. In
the Tellabs 8600 system only adjacencies between directly connected level 1 and level 2 routers
(IS-IS adjacency) are relevant. Adjacency is discovered by sending point-to-point IS-IS Hello
(IIH) packets over point-to-point level 1 and level 2 links, level 1 LAN IIHs over broadcast level
1 links and level 2 LAN IIHs over broadcast level 2 links. If the point-to-point link builds up
simultaneously level 1 and level 2 adjacency the same Hello packet is used to serve both levels.
IS-IS offers a very exible way to adjust the interface basis of Hello timers.
Take great care when adjusting the Hello packet timers from their default values. Negligent
adjusting of the timers very easily leads to instability problems in the routing domain and
slows down routing convergency in the case of link failures.
5.8 Link-State Database and Link-State Packets
IS-IS routers use Link-State Packets (LSP) to inform the adjacency router about its local routing
status. LSPs are ooded over the whole area and all routers store the LSP information to the local
link-state databases. Over the time all routers have updates about the status of the other routers and
they have identical link-state databases which reect the topology of the network. Each router runs
the CSPF algorithm over the LSP database to dene an optimum routing table locally. LSP packets
and link-state databases are generated separately for level 1 and level 2.
IS-IS offers a very exible way to adjust LSP timers on an IS-IS instance basis.
Take great care when adjusting the LSP packet timers from their default values. Negligent
adjusting of the timers very easily leads to instability problems in routing domain and slows
down routing convergency in the case of link failures.
5.9 Route Summarization
To limit the number of routes to be advertised to other routers it is possible to use route
summarization. IPv4 reachability information can be summarized separately for level 1 and level 2
routes.
76.8600-50121F Tellabs
8600 Smart Routers

81
5 IS-IS
5.10 Route Redistribution
IS-IS routing table is normally built up from the IS-IS link-state database. The Tellabs 8600 system
allows the redistribution of reachability information from other routing protocols such as OSPF and
BGP and additionally static and directly connected routes. Redistribution can be done separately for
level 1 and level 2 routes.
Redistributing the whole BGP table to IS-IS should be avoided. If the Internet routes are needed in
IS-IS, consider the following options:
1. Use iBGP to all NEs.
2. Use BGP free core with MPLS resolution and iBGP to edge NEs.
3. Distribute only a small subset of routes to IS-IS.
Options 1 and 2 are preferred. The current best practice is that only operator routes (links between
routers and loopbacks) are in IS-IS and all customer routes are in BGP.
5.11 Authentication
The Tellabs 8600 system supports the authentication of IS-IS packets exchanged between routers to
prevent malicious attacks. Both clear text and MD5 options are available. It is possible to set one
key for the whole instance which is used in all interfaces or set a password individually for each
interface. To enable interworking in special situations, an authentication check can be disabled in
receive direction. All settings are separate for level 1 and level 2. Several passwords can be stored
to a key chain to support a hitless change of the password.
5.12 Extensions for Support of Differentiated Services-Aware MPLS
Trafc Engineering
The networks with Quality of Service (QoS) type of services traditionally use link metrics to provide
trafc engineering capabilities. When offering DiffServ services in a large network with high
Service Level Agreement (SLA) guarantees, this is not anymore a reasonable way to provide trafc
engineering. As a solution, MPLS is an excellent way to manage trafc engineering in IP networks.
The Tellabs 8600 system provides IS-IS to be used as an IGP protocol to support MPLS trafc
engineering. IS-IS with trafc engineering support allows RSVP-TE to use IS-IS topology database
for CSPF algorithm for automated MPLS tunnel routing. Additionally, the capacity reservations of
established MPLS tunnels are stored to the IS-IS trafc engineering database in each router along
the path. IS-IS trafc engineering extensions [draft-ietf-isis-trafc] allow routers to distribute
reservation information in link-state packets. In DiffServ-aware MPLS engineering the reservations
can be done additionally based on different trafc classes and class types [RFC3564].
Tellabs
8600 Smart Routers 76.8600-50121F

82
5 IS-IS
5.13 IS-IS References
[draft-ietf-isis-trafc] draft-ietf-isis-trafc-04.txt (200108), IS-IS extensions for trafc
engineering
[ISO10589] ISO10589 (2002), Intermediate system to intermediate system
intra-domain routing information exchange protocol
[RFC1195] RFC1195 (199012), Use of OSI IS-IS for routing in TCP/IP and
dual environments
[RFC2763] RFC2763 (200002), Dynamic host name exchange mechanism for
IS-IS
[RFC3564] RFC3564 (200301), Requirements for support of differentiated
services-aware MPLS trafc engineering
[RFC3784] RFC3784 (200406), Intermediate System to Intermediate System
(IS-IS) Extensions for Trafc Engineering (TE)
76.8600-50121F Tellabs
8600 Smart Routers

83
6 IS-IS Conguration Examples
This chapter gives some basic CLI examples for conguring an IS-IS process and an IS-IS interface
as well as one IS-IS area conguration example in the Tellabs 8600 system.

6.1 IS-IS Basic Conguration
To enable IS-IS for IP routing in a router, at least the following steps are needed.
Step 1 Initiate an IS-IS routing instance. Optionally, it is possible to dene a particular area tag at the same
time. For example, router isis bb initiates an IS-IS instance with an area tag bb.
router(config)# router isis
Step 2 Add an NET for the IS-IS instance to start routing. This NET has an area ID 49.0001 and system ID
1720.1910.2029, its N-selector is 00 that indicates NET.
router(cfg-isis)# net 49.0001.1720.1910.2029.00
Step 3 Enable IS-IS routing in an interface. If there is more than one IS-IS process on the router, the
interface needs to choose one. For example ip router isis bb makes IS-IS instance bb routing
on the interface.
router(cfg-if[fe0/0])# ip router isis
After the conguration above, there are several commands available that can be used to verify for
example: IS-IS topology, link-state database, its interface. The following table provide a list of
these commands and please always refer to Tellabs
8600 Smart Routers CLI Commands Manual

for a complete list of the available commands.
Command Description
show isis topology This command displays information of an IS-IS topology.
show isis database This command displays detailed information of the link state database.
show isis interface This command displays detailed information of an interface.
Tellabs
8600 Smart Routers 76.8600-50121F

84
6.1.1 IS-IS Process Conguration
Each IS-IS process has some attributes, which can be congured with CLI commands. Some
examples are provided in this chapter.
Step 1 Set the IS-IS to level-1 routing. CLI is-type denes the IS-IS process routing level.
router(cfg-isis)# is-type level-1
Level 1: the router acts as a station router, and the station router learns about destinations only inside
its area and takes part in level 1 adjacencies over its interface.
Level 12: the router acts as both a station router and an area router. This router runs two level
routes, i.e. level 1 routing and level 2 routing.
Level 2only: the router acts as an area router only. This router is a part of a backbone and does
not talk to level 1only routers in its own area.
Step 1 Congure IS-IS to redistribute BGP reachability information at level-1.
router(cfg-isis)# redistribute bgp level-1
Step 2 Congure summary-address to summarize reachability information. By giving a level at the end of
this command, the summary address will be congured to that specic level.
router(cfg-isis)# summary-address 172.19.102.74/24
Step 3 Congure summary-address 172.19.102.74/24 to level-2.
router(cfg-isis)# summary-address 172.19.102.74/24 level-2
Step 4 IS-IS does not automatically derive metric from bandwidth (as OSPF does). Therefore, set a wide
metric that reects the goodness of the interface (a very large value for E1 and a small value for
GE). TE metric uses the same value unless it is overridden manually. A narrow metric type is not
used when trafc engineering is in use.
router(cfg-isis)# isis wide-metric 100
router(cfg-isis)# exit
6.1.2 IS-IS Interface Conguration
The IS-IS interface has some attributes that can be congured with CLI commands. Some examples
are provided in this chapter.
Step 1 Set circuit-type level-1 to the interface fe0/0.
router(cfg-if[fe0/0])# isis circuit-type level-1
Step 2 Congure a metric value for the interface. The value is used to calculate the cost from each other
router through the links in the network to other destinations. By giving a level at the end of this
command, the metric value will be congured to that specic level.
router(cfg-if[fe0/0])# isis metric 20
Step 3 Congure metric 20 to the interface for level-1 routing.
router(cfg-if[fe0/0])# isis metric 20 level-1
76.8600-50121F Tellabs
8600 Smart Routers

85
Step 4 Specify the priority of a router to the interface. By giving a level at the end of this command, the
priority value will be congured to that specic level.
router(cfg-if[fe0/0])# isis priority 10
Step 5 Congure priority 10 to the interface for level-2 routing.
router(cfg-if[fe0/0])# isis priority 10 level-2
Step 6 Congure hello-interval to be 10 seconds. By giving a level at the end of this command, the interval
value will be congured to that specic level.
router(cfg-if[fe1/0])# isis hello-interval 10
Step 7 Congure hello-interval 10 seconds for the interface at level 1.
router(cfg-if[fe0/0])# isis hello-interval 10 level-1
6.2 IS-IS Area Conguration
Fig. 29 IS-IS Area Conguration
In the gure above there are four routers making up two areas. R1 and R4 are level 1 routers, and
R2 and R3 are level 12 routers. R1 and R2 make up area 49.0001 whereas R3 and R4 make
up area 49.0002.
The system IDs of the routers are dened as follows:
Router R1: 1921.6800.0001
Router R2: 1921.6800.0002
Router R3: 1921.6800.0003
Router R4: 1921.6800.0004
Tellabs
8600 Smart Routers 76.8600-50121F

86
The IS-IS conguration of all routers requires the three basic commands introduced in 6.1 IS-IS
Basic Conguration: initiate IS-IS instance, add an NET and then associate the initiated IS-IS to
an interface. Attributes of IS-IS and its interface can be congured with their specic commands,
some examples having been offered previously.
Detailed conguration examples of each router are presented in the following chapters.
6.2.1 Router 1 Conguration
Step 1 Initiate the IS-IS routing instance with a null area tag.
router1(config)# router isis
Step 2 Add net 49.0001.1921.6800.0001.00 for the IS-IS instance.
router1(cfg-isis)# net 49.0001.1921.6800.0001.00
Step 3 Set the IS-IS instance to be level1 routing.
router1(cfg-isis)# is-type level-1
router1(cfg-isis)# exit
Step 4 Enable IS-IS routing in the interface so1/0.
router1(config)# interface so 1/0
router1(cfg-if[so1/0])# ip router isis
Step 5 Set circuit-type level-1 to the interface so1/0 for level 1 routing. Actually, this conguration is
not really necessary in this case, because level 1 on the interface is implied by setting the IS-IS
process as level-1.
router1(cfg-if[so1/0])# isis circuit-type level-1
router1(cfg-if[so1/0])# exit
Normally IS-IS is run in a at domain. Up to 50% memory and CPU usage savings can be
accomplished by disabling level 1.
Step 1 Disable level 1.
router2(cfg-isis)# is-type level2
Step 2 Redistribute static routes.
router2(cfg-isis)# redistribute static
Usually route-map is used in conjunction with a redistribute clause to lter redistributed routes.
Include the connected routes by using the passive-interface command.
Step 1 Include interface fe1/0 to the IS-IS domain.
router2(config)# interface fe 1/0
router2(cfg-if[fe1/0])# ip router isis
router2(cfg-if[fe1/0])# exit
Step 2 Make the interface not to speak or accept IS-IS protocol in it.
76.8600-50121F Tellabs
8600 Smart Routers

87
router2(cfg-isis)# passive-interface fe 1/0
If multilevel IS-IS is used, route summarization can be used between the levels according to the
following example.
Step 1 Summarize all prexes under 10.123.0.0/16 to level 2.
router2(cfg-isis)# summary-address 10.123.0.0/16 level-2
This means that whenever there are routes in a level that fall within the above prex (e.g.
10.123.30.0/24), route 10.123.0.0/16 is placed in level 2. The more specic routes falling within the
summary address range are not placed in level 2.
The IS-IS conguration of R2 is similar to R1. The difference is that R2 is level 12 router and it
needs a running two level routing. The IS-IS conguration of R3 is the same as R2 except for a
different NET.
Step 4 Enable IS-IS routing in the interface fe1/0.
router3(config)# interface fe 1/0
router3(cfg-if[fe1/0])# ip router isis
router3(cfg-if[fe1/0])# exit
The IS-IS conguration of R4 is the same as R1 except for a different NET.
router4(cfg-isis)# exit
Tellabs
8600 Smart Routers 76.8600-50121F

88
6.3 Fast IS-IS Convergence
Due to historical reasons, the IS-IS commands take the parameters in the following order; max, init,
mul. Note that this is different from the OSPF command order which is init, mul, max. IS-IS uses
two timers that regulate the convergence speed.
SPF timer
LSP generation interval
The IS-IS SPF timer is per level and the parameters are set identically to the OSPF SPF timer.
The IS-IS LSP generation interval differs form the OSPF LSA refresh timer in a few fundamental
ways. The LSP generation time applies also to the rst creation of any LSP. LSPs are generally
much larger than LSAs (especially when routes are redistributed), and hence timers must not be
specied as aggressively as with OSPF. For the proper aggregation of Type Length Values (TLVs),
initial delay should be a non-zero value (>100 ms is a good choice).
The traditional IS-IS parameters are as follows:
init mul
max
SPF 5000 10000 10000
LSP gen interval 300 30000 30000
As IS-IS does not have architectural constants that would prevent sub-second convergence, the
Tellabs 8600 system IS-IS implementation uses fast timers by default. The Tellabs 8600 system
default parameters are specied as stated in the following table:
init mul
max
SPF 200 100 10000
LSP gen interval 100 400 30000
IS-IS also uses 100 ms reachability timer for updating the most TLV types. This timer is not
congured by the user. However, the interface down events bypass this timer and allow fast switch
to the backup paths.
Step 1 Congure the IS-IS timers.
router(config)# router isis
router(cfg-isis)# lsp-gen-interval [<level-1|level-2>] <max> <init> <mul>
router(cfg-isis)# spf-interval [<level-1|level-2>] <max> <init> <mul>
router(cfg-isis)# exit
76.8600-50121F Tellabs
8600 Smart Routers

89
7 Bidirectional Forwarding Detection
7.1 Overview
Bidirectional Forwarding Detection (BFD) is a hello protocol that provides fast fault detection. BFD
can be used as trigger for rerouting or for protection switchover.
A single hop BFD is used to track connectivity between two forwarding planes directly connected
by a link. Multihop BFD can be used on arbitrary paths between systems, which may span multiple
network hops and follow unpredictable paths.
BFD has two operating modes:
Asynchronous mode. In this mode BFD control packets are sent periodically to one another and
if the number of packets stops showing up, the session is declared to be down.
Demand mode. In this mode once a BFD session is established, the systems stop sending BFD
control packets, except when either system needs to explicitly verify the connectivity.
BFD specication also denes echo mode. This mode is used on systems that are not capable of
performing full BFD sessions at suitable rates. BFD in echo mode is not supported in the Tellabs
8600 system.
A separate BFD session is created for each communication path and data protocol in use between
two systems. BFD neighbors negotiate the mode and desired transmit and receive rates of BFD
packets. A router reporting lower rate determines the actual rate that will be used, which allows
slower systems to utilize BFD to the best of their ability.
The following BFD features are supported in Tellabs 8600 system:
Single hop [RFC5881]
Asynchronous mode [RFC5880]
BGP
OSPF
IS-IS
RSVP-TE. BFD monitors the neighbor node, not each LSP separately, which reduces the number
of BFD sessions when multiple LSPs transit between a pair of RSVP neighbors. BFD is sent in
pure IP packet without MPLS labels.
Static routes
VRRP
BFD implementation in the Tellabs 8600 system provides very fast 50 ms fault detection when the
number of BFD neighbors is low. Even with tens of neighbors the detection can be performed
within 200 ms.
Tellabs
8600 Smart Routers 76.8600-50121F

90
7.2 BFD in Dynamic Routing
BFD can be used in conjunction with one or more of the following routing protocols:
BGP - BFD is provisioned on directly connected BGP neighbors IP address.
OSPF - BFD is provisioned on OSPF enabled interfaces.
IS-IS - BFD is provisioned on IS-IS enabled interfaces.
RSVP-TE - BFD is provisioned on RSVP enabled interfaces either for a specic neighbors des-
tination IP address of the interface, or in opportunistic mode.
BFD provides fast failure notication when used with these protocols. This can be particularly
useful in cases where link down indication is not reliable (for example switched Ethernet network).
In the following gure, the VLANs within the Ethernet network can be setup so that the right side
router can see two routes to left most side. When BFD is running through both routes it is possible
to quickly detect network faults within the Ethernet network and perform switchover or rerouting.
Fig. 30 BFD Session
In the Tellabs 8600 system, RSVP-TE hellos are performed in non-real-time context and cannot
support less than 3 seconds detection intervals, while BFD can achieve sub-second detection
intervals. BFD is more efcient and speeds up OSPF and IS-IS. The IETF denes BFD as a
mechanism capable of providing fast and scalable forwarding liveliness detection. More information
about MPLS and RSVP-TE please refer to Tellabs
8600 Smart Routers MPLS Applications

Conguration Guide. Related details about VCCV BFD, see Tellabs
8600 Smart Routers Test and

Measurement Conguration Guide.
76.8600-50121F Tellabs
8600 Smart Routers

91
7.3 BFD in Static Routing
Unlike dynamic IP routing protocols, IP static routes do not have own connectivity verication
mechanisms. In the Tellabs 8600 system static routes can react to locally detected faults, e.g. link or
Packet-Switched Network (PSN) down. However, a static route cannot automatically avert such
network faults without a network administrator effort. This problem can be avoided by establishing
a BFD session upon a connection and binding the static route to the session. If a BFD session is up a
route is selected for routing, otherwise that route is deactivated.
If a router has a backup path to its neighbor (Fig. 31), trafc can be switched automatically to
backup path when BFD detects that the primary path is down. Also a router is able to switch trafc
back to original path when BFD detects that the primary path is restored.
Fig. 31 BFD Monitoring for Static Routes with Backup Path
There are two actions that must be performed in order to use BFD for a static route:
BFD session must be established between adjacent systems by means of provisioning on both
ends
A static route must be explicitly congured to use BFD.
For more information about static routing and conguration, please refer to Tellabs
8600 Smart
Routers IP and Trafc Management Conguration Guide.
7.4 BFD References
[RFC5880] RFC5880 (201007), Bidirectional Forwarding Detection (BFD)
[RFC5881] RFC5881 (201007), Bidirectional Forwarding Detection (BFD) for
IPv4 and IPv6 (Single Hop)
Tellabs
8600 Smart Routers 76.8600-50121F

92
8 BFD Conguration Examples
This section provides BFD CLI conguration examples in the Tellabs 8600 system.

When using BFD, it is recommended to disable the RSVP-TE hello mechanism. On the other
hand, it is always required to enable QoS in the interface that uses BFD, otherwise other trafc
could prevent the progress of the BFD packets .
BFD is congured per protocol, but for each neighbor there is a maximum of one BFD session, in
which the smallest multiplier and interval are used. BFD should be congured to every protocol
where it is required to be used. To avoid erroneous conguration, please notice that fast detection
works only for those protocols in which BFD is enabled for the interface in question. For example, if
OSPF is BFD enabled but RSVP-TE is not, the detection takes longer than if both are BFD enabled.
8.1 BFD Conguration with Routing Protocols
8.1.1 OSPF
In the case of OSPF, BFD can be enabled either per process or per interface. Neighbors which are in
an interface which is BFD-enabled, but do not speak BFD, are left outside the routing.
To enable a BFD session on an interface use the following commands.
Step 1 The router enables BFD for the specied OSPF interface using the default timing values.
router(config)# interface ge 6/0/0
router(cfg-if[ge 6/0/0])# ip ospf bfd
Step 2 The router enables BFD for the specied OSPF interface using 50 ms interval, multiplier 3.
router(cfg-if[ge 6/0/0])# ip ospf bfd 50 3
8.1.2 IS-IS
In the case of IS-IS, BFD can be enabled by process or by interface. The neighbors which are BFD
interface enabled, but do not speak BFD are left outside the routing.
To enable a BFD session on an interface use the following commands.
Step 1 The router enables BFD for the specied IS-IS interface using the default timing values.
76.8600-50121F Tellabs
8600 Smart Routers

93
router(cfg-if[ge 6/0/0])# ip isis bfd
Step 2 The router enables BFD for the specied IS-IS interface using 50 ms interval, multiplier 3.
router(cfg-if[ge 6/0/0])# ip isis bfd 50 3
8.1.3 RSVP-TE
RSVP-TE is not able to dynamically locate the BFD neighbors, as a result the neighbors are
congured using the IP address of the interface. It is also possible with RSVP-TE to congure BFD
in opportunistic mode, where RSVP-TE will not initiate BFD signalling. Instead, RSVP-TE will rely
on routing protocols OSPF or IS-IS to discover BFD neighbors and establish BFD sessions. If OSPF
or IS-IS does not discover desired neighbors, RSVP-TE will consider those neighbors to be down.
To start a BFD session with the directed peer use the following commands.
Step 1 The router enables BFD for the specied destination.
router(cfg-if[ge 6/0/0])# rsvp bfd 1.1.1.1 50 3
Another alternative conguration is to enable IGP in the desired interfaces and congure it to
RSVP_TE BFD opportunistic mode. If it is not desired to speak BFD to all the neighbors, it is
possible to enable RSVP-TE only and leave IGP out.
Step 1 The router enables BFD for the specied RSVP interface using the default timing values.
router(cfg-if[ge 6/0/0])# rsvp bfd opportunistic
Step 2 The router enables BFD for the specied RSVP interface using 50 ms interval, multiplier 3.
router(cfg-if[ge 6/0/0])# rsvp bfd opportunistic 50 3
8.1.4 Single Hop BGP
This chapter provides an example on how to congure BFD for a single hop BGP. The example
provided below focus only on enabling BFD under the BGP process and not all BGP conguration
details are covered in this example. Please refer to 4 BGP Conguration Examples for more details
about BGP congurations. The conguration is based on the following topology.
Tellabs
8600 Smart Routers 76.8600-50121F

94
Fig. 32 BFD for Single Hope BGP Conguration Topology
At least the following tasks are required to congure BFD for a single hop BGP:
Set BGP routing process
Instantiate BGP peers
Enable BFD
NODE-250 Conguration
Step 2 Instantiate BGP peer.
Step 3 Enable the address-family conguration mode and enable BFD monitoring.
node-250(cfg-bgp[65000])# address-family ipv4 vrf BGP_VRF_1
node-250(cfg-bgp[65000]-af-vrf[BGP_VRF_1])# neighbor 172.16.10.246 bfd
single-hop 10 3
node-250(cfg-bgp[65000]-af-vrf[BGP_VRF_1])# exit
NODE-246 Conguration
Step 2 Instantiate BGP peer.
Step 3 Enable the address-family conguration mode. Dene the neighbor and enable BFD monitoring.
node-246(cfg-bgp[65100])# address-family ipv4 vrf BGP_VRF_1
node-246(cfg-bgp[65100]-af-vrf[BGP_VRF_1])# neighbor 172.16.10.250 bfd
single-hop 10 3
node-246(cfg-bgp[65100]-af-vrf[BGP_VRF_1])# exit
76.8600-50121F Tellabs
8600 Smart Routers

95
BFD for Single Hop BGP Status
The following screenshots provide the status of BFD for single hop BGP congured above.
Fig. 33 BFD Status
Tellabs
8600 Smart Routers 76.8600-50121F

96
Fig. 34 Neighbors Status
8.2 BFD Conguration for Static Routes
BFD conguration for static routes requires a manual provisioning on both ends. The following
example uses topology depicted in Fig. 31 to show how to create static routes that track BFD session
state.
Router A conguration:
Step 1 Enables BFD monitoring towards the destination router B on interface fe0/2.
router-A(config)# interface fe 0/2
router-A(cfg-if[fe0/2])# ip bfd 20.1.1.2
router-A(cfg-if[fe0/2])# no shutdown
router-A(cfg-if[fe0/2])# exit
Step 2 Enable BFD monitoring towards the destination router B on interface fe0/3.
router-A(config)# interface fe 0/3
router-A(cfg-if[fe0/3])# ip bfd 30.1.1.2
76.8600-50121F Tellabs
8600 Smart Routers

97
router-A(cfg-if[fe0/3])# no shutdown
router-A(cfg-if[fe0/3])# exit
A static route that intends to track BFD session state must be created with keyword bfd. A
BFD static route can be created before provisioning, but it will never reach the up state until
corresponding BFD session is provisioned and has up state.
Step 1 Congure the static routes that track BFD session state.
router-A(config)# ip route 40.1.1.0/24 20.1.1.2 bfd 50
router-A(config)# ip route 40.1.1.0/24 30.1.1.2 bfd 100
Router B conguration:
Step 1 Enable BFD monitoring towards the destination router A on interface ge2/0/1.1.
router-B(config)# interface ge 2/0/1.1
router-B(cfg-if[ge2/0/1.1])# ip bfd 20.1.1.1
router-B(cfg-if[ge2/0/1.1])# no shutdown
router-B(cfg-if[ge2/0/1.1])# exit
Step 2 Enable BFD monitoring towards the destination router A on interface ge6/0/1.2.
router-B(config)# interface ge 6/0/1.2
router-B(cfg-if[ge6/0/1.2])# ip bfd 30.1.1.1
router-B(cfg-if[ge6/0/1.2])# no shutdown
router-B(cfg-if[ge6/0/1.2])# exit
Step 3 Congure the static routes that track BFD session state.
router-B(config)# ip route 10.1.1.0/24 20.1.1.1 bfd 50
router-B(config)# ip route 10.1.1.0/24 30.1.1.1 bfd 100
8.2.1 BFD Status
BFD routing process information (see example in Fig. 35) can be displayed using the following
commands:
1. show ip bfd - the command will display a summary information about all BFD routing pro-
cesses
2. show ip bfd detail - the command will display detailed information about BFD routing pro-
cesses
Tellabs
8600 Smart Routers 76.8600-50121F

98
Fig. 35 BFD Summary and Detailed Status
76.8600-50121F Tellabs
8600 Smart Routers

99
9 Equal Cost Multipath (ECMP)
9.1 Overview
Equal Cost Multipath (ECMP) is a technique that enables load-sharing trafc over multiple equal
cost paths. Without ECMP, only one of the paths would be used. ECMP can load-share trafc only
between equal cost paths, as load-sharing over non-equal cost paths could cause loops. ECMP also
offers fast protection for locally detected link failures. When using switched Ethernet networks,
use of BFD is recommended to ensure that failures can be detected even when L2 switches do
not propagate link down information.
Paths are considered to have equal cost for ECMP purposes when:
All paths are of the same protocol (OSPF/IS-IS/static)
Have the same distance to destination:
1. For OSPF/IS-IS this is calculated as path metric. Paths must also be of the same type, i.e.
internal, or external;
2. For static routes, administrative distance must be the same, and none of the hops may be
recursive or recursive-mpls.
When ECMP is used, all trafc is distributed equally between equal cost paths. Differences in
outgoing interface bandwidths have no effect on ECMP. An ECMP group consists of several IP
routes that have the same distance and the same destination address. Thus protection and trafc
load-sharing works between the equal cost paths in an ECMP group. There can be up to eight
different paths per ECMP group.
9.2 ECMP Network Application
An application example of network using ECMP is shown in Fig. 36, where three shortest paths
have the same distance of ve from a source to a destination. Trafc load is balanced evenly to
the three equal cost paths. Additionally, the three ECMP paths shown serve as backup paths for
each other. If one of the paths fails, trafc load is automatically redistributed between the other
two paths after failure detection. A routing protocol discovers any possible change of the topology
and calculates all ECMP paths automatically. As mentioned, conguring BFD decreases failure
detection time from seconds to tens or hundreds of milliseconds. Additionally protocol timers can
be adjusted in order to decrease information ooding time. More information about OSPF see
1 OSPF and about IS-IS see 5 IS-IS.
In the topology depicted in Fig. 36, only source router Rs is required to support ECMP, because it is
the only router where trafc load can be balanced and several paths exist to the destination. Other
routers than Rs do not have to support ECMP as equal cost paths do not exist. Source router Rs
uses hash calculations based on IP header information for trafc load balance and denes trafc
ows for each path. Every packet follows always the same path, if the network topology or ECMP
conguration do not change.
Tellabs
8600 Smart Routers 76.8600-50121F

100
In Fig. 36 there is only one node (R4) and one link that shares more than one path. If this node or
link fails, all trafc would end up being carried on path 3 and bandwidth limitation of the links on
path 3 could be exceeded incurring packet loss.
When a mixture of single path and ECMP routers are used, it is very important to use appropriate
link metrics, so that sufcient amount of ECMP paths are created. Optimal costs of each link can be
calculated using network optimization tools and adjusted accordingly. If the link between routers
R2 and R5 would have a cost of 2 instead of 3, then router R2 would nd two ECMP paths to the
destination and it would balance trafc load of path 2 further to these two ECMP paths.
When the three ECMP paths are created using static routes, BFD is the only way to provide
protection for these paths. Otherwise any failure cannot be detected and constant packet loss would
occur. In static routing the distance to destination is congured in the source router and there is
not any route calculation performed.
Fig. 36 ECMP Application
9.3 ECMP Operation
9.3.1 Dynamic Routing
Link-state routing protocols such as OSPF and IS-IS are based on Shortest Path First (SPF)
algorithm, which calculates the shortest paths from the source router to a destination router. SPF
computes automatically equal cost paths, which are then advertised to the forwarding layer.
Thus ECMP does not require any special conguration and new discovered equal cost paths are
automatically taken into use.
76.8600-50121F Tellabs
8600 Smart Routers

101
The maximum number of equal cost paths utilized by ECMP per OSPF or IS-IS instance is
user-congurable with the command maximum-paths, with up to eight paths supported by the
Tellabs 8600 NEs. The default number is eight paths, while setting the maximum number to just one
path effectively will disable ECMP routing. The command maximum-paths sets the number of
ECMP next-hops in a given router. However, there can be several number of consecutive trafc
load-sharing in a sequence (i.e. tree topology type), then the total number of paths can be much
larger than eight for the whole topology.
ECMP works in IP intradomain networks, thus it is not supported with BGP or MPLS. In general, IP
level trafc load-sharing is performed hop-by-hop basis whereas RSVP-TE load balancing shares
load between Label Switched Paths (LSPs), that reach the same destination in MPLS network. The
RSVP load balancing has a higher priority than ECMP trafc load-sharing. If trafc is mapped to
RSVP trunk or to LDP LSP, MPLS takes precedence and ECMP is not used for the MPLS mapped
FECs. More information on MPLS and RSVP-TE load balancing please refer to Tellabs
8600
Smart Routers MPLS Applications Conguration Guide.
9.3.2 Static Routing
Static routes are created manually by network administrator. When static routes are congured,
the distance between the router making ECMP decision and the destination can be adjusted, thus
sum of the metrics of the links do not have an effect on the ECMP group creation, which gives
more exibility in the selection of ECMP members in static routing than in dynamic routing. If
more than 8 ECMP routes are congured, excess routes stay in the control plane as a backup. If
one of the paths fails, backup route is taken into use. Recursive routes and auto-congured routes
use always the rst path of the route and they cannot be used in ECMP group creation. More
information about static routing and conguration, please refer to Tellabs
8600 Smart Routers IP

and Trafc Management Conguration Guide.
9.3.3 Forwarding Plane Functions
Created static or dynamic ECMP routes are installed into forwarding plane, which enables
guaranteed sub 50 ms recovery in case of failures. Trafc is distributed between different ECMP
paths by performing hash calculations over selected elds in the IP packet header:
Source IP address
Destination IP address
Protocol eld
UDP/TCP source port
UDP/TCP destination port
Each trafc ow identied by the elds above keep the same path, thus there is no possibility to
have packets out-of-order. Load-sharing is probabilistic in nature and no counter based rebalancing
is performed.
9.3.4 Scalability
The maximum number of supported ECMP groups in Tellabs 8600 NEs is outlined in the following
table.
Tellabs
8600 Smart Routers 76.8600-50121F

102
NE ECMP Groups
Tellabs 8605 smart router 128
Tellabs 8607 smart router (no ECMP support)
Tellabs 8620 smart router 1K
IFC line card 1K
CDC 1K
ELC1 line card 1K
76.8600-50121F Tellabs
8600 Smart Routers

103
10 Virtual Router Redundancy Protocol
10.1 Introduction
It is still quite common to have network clients that use static routing. These clients are dependant
on the gateway and a re-conguration in case the gateway has to be changed is required. This makes
the clients vulnerable to single point of failure. The problem of single point of failure could be
avoided by using for example some dynamic routing schemes. However dynamic routing usually
needs to be supported also on the client side and that support is not always available. Virtual Router
Redundancy Protocol (VRRP) is designed to remove single point of failure in a such way that no
conguration or additional support from clients is required.
VRRP is a protocol that enables the usage of redundant backup routers in static default routed
environments. VRRP is specied by IETF in [RFC3768]. The goal of adding redundant routers is
to remove single point of failure, which is inherent in static routed environment. Redundancy is
introduced by allowing usage of the same virtual IP address in multiple routers. The VRRP router
that is controlling the virtual IP address is called the master and it forwards packets sent to the
virtual IP address. In addition to the master, backup routers can be added to the same Local Area
Network (LAN) and can automatically switch to forward trafc in case the master fails. A group of
routers that can protect each other is called VRRP group and it is identied by VRRP ID.
10.2 Operation
Fig. 37 shows an example case where a static route is protected by VRRP. Packets sent from RNC to
cell site are routed via a static route with next-hop that is the virtual IP address of the VRRP group.
In normal operation only Router-1 forwards trafc.
Tellabs
8600 Smart Routers 76.8600-50121F

104
Fig. 37 Static Route Protection with VRRP
As previously noted VRRP group has one master router and backup router(s). To make sure that
there is always at least one master, VRRP advertisements messages are used. In order to keep trafc
introduced by the protocol as low as possible, only the master is allowed to send advertisement
messages. These advertisement messages contain the conguration of VRRP group and priority of
the current master router. Advertisement messages are sent with dened advertisement interval.
This allows the backup routers to know the exact time when advertisement messages should arrive.
A backup router can become master automatically, if it receives an advertisement message of a
VRRP group with lower priority. In this case, the backup router switches to master role and sends
an advertisement message with its own priority. This will cause the previous master to switch to
backup role. The process where a mastership transition happens based on the priorities is called
preemption. If VRRP is disabled from a router that is currently the master, an advertisement with
zero priority is sent. A backup router can also assume a master role when it notices that current
master is no longer active. This happens for example, when no advertisement messages are received
during a period of three times the advertisement interval.
76.8600-50121F Tellabs
8600 Smart Routers

105
Fig. 38 VRRP Switchover
Fig. 38 presents a situation where Router-1 loses connection to the Ethernet switch. In this case,
Router-2 will automatically switch to be the master and forward trafc. After VRRP mastership
transition, the Ethernet switch will be notied by gratuitous ARP message sent by Router-2. This
allows Ethernet switches with learning capabilities to update their MAC forwarding tables. On the
other hand, Ethernet switches without learning capabilities, they always send trafc to both routers
connected, thus trafc is not affected by switchover. Gratuitous ARP messages do not affect RNC
because the IP address and MAC address do not change.
The Ethernet switches shown in the examples above can be replaced by internal switching capability
of either RNC or the Tellabs 8660 smart router (see 10.3.3 VRRP with IRB).
10.2.1 VRRP Parameters
The preemption parameter is used to control a mastership transition of the backup router, or to
prevent a backup router to assume a mastership role. With the preemption parameter, it is possible
to overwrite the default skew_time (see 10.2.2 VRRP Timers), or to disable preemption (i.e.
mastership transition based on the priorities). The default behavior is immediate takeover, which
means that previously dened skew_time rule is obeyed. With the option no preemption set,
a mastership is not transferred as long as the master is active. The option fast preemption can
be used to skip the preemption_time (including skew_time) entirely, which will make the
transition to master role faster, but it should be used only if the VRRP group has no more than
two VRRP routers. Unless the fast preemption option is used, specied preemption_time
is in addition of the skew_time.
In practice, when a neighbor decrements own priority, it is because of object tracking (see
10.3.2 Object Tracking). In this case, it is desired that the mastership transition happens as
soon as possible. Therefore, if the decrease in neighbor's priority leads to preemption, then the
preemption_time is skipped. Also, it is possible to disable preemption_time skipping
by using parameter wait_on_decrement, which will revert back to the behavior dened by
[RFC3768].
Tellabs
8600 Smart Routers 76.8600-50121F

106
VRRP group priority is dened in a range 1...254 with default 100 and the router with the highest
VRRP group priority is the master. If the interface IP address is the same as the virtual IP address of
the VRRP group, then the router is considered to be the address owner. The priority of the address
owner is always 255. The virtual IP address can be assigned freely. However, it should be derived
from a subnet the interface is connected, to allow VRRP to operate correctly.
The VRRP group advertisement interval is dened in a range 1...10 (default is 1 second). Longer
interval can be used to decrease trafc and load to the system that is caused by VRRP advertisement
messages. This might be useful in cases where there are many VRRP sessions active simultaneously.
The same advertisement interval value must be set to all routers within the same VRRP group.
Multiple VRRP instances can be congured to a single interface or VLAN as long as each instance
has a different VRRP ID. This can be used to achieve simple load sharing by using different virtual
IP addresses for different routes. However, VRRP by itself does not have load sharing capabilities.
VRRP groups are specic to a port or VLAN interface and can be reused on multiple VLANs.
The delay_after_init parameter is used to add a delay for VRRP mastership transition after
an initialization of the VRRP session. This parameter is mainly to address possible issues when an
interface where VRRP is congured comes up before a connectivity to the master is established.
In this situation, advertisements are not received, therefore preemption timer cannot be started
and as result the backup router takes the mastership role. This issue might occur during the boot
up, when VRRP is used with IRB and the IRB interface comes up before the physical interfaces,
see 10.3.3 VRRP with IRB .
10.2.2 VRRP Timers
VRRP uses different timers to control the mastership transitions. These timers cannot be directly set
but are controlled by VRRP parameters described in this chapter and in 10.2.1 VRRP Parameters.
A master_down_interval is used to dene a time the backup router(s) must wait for
an advertisement from the master before declaring that the master is no longer active. The
master_down_interval is calculated as follows:
master_down_interval = 3*advertisement_interval + skew_time
A timer called master_down_timer is used to track master_down_interval. When
an advertisement is received from the master the master_down_timer is reset to the
master_down_interval and the timer starts to countdown. If the master_down_timer
reaches zero before the next reset by an advertisement, then the backup router will declare that the
master is not active.
Due to the fact that backup routers do not communicate with other routers there is a short period
of time when multiple routers can assume master role simultaneously. This situation can cause
duplication of trafc. It is also possible that the router with the highest priority will not be the rst to
switch to mastership role. To avoid this problem, a parameter known as skew_time is introduced.
It is a period of time in seconds that is waited before a router switches to a master role, after it
has noticed that the master is no longer active.
skew_time = [(256 - priority)/256] seconds
76.8600-50121F Tellabs
8600 Smart Routers

107
The preemption_time denes the time a backup router must wait before assuming the
mastership role, if the current master has lower priority. The preemption_time is used to
ensure that a router has enough time to create stable upstream connections, before it can assume
mastership role. The preemption parameter can be used to dene the preemption_time. When
a backup router notices that it has higher priority than the master, a new preemption_timer is
scheduled with a value dened by preemption_time. A mastership role will be assumed after
the preemption_timer expires.
The following table presents the starting conditions and initial timer values of a VRRP backup router.
Event Master_Down_Timer
Reset to
Preemption_Timer
Scheduled
Interface up delay_after_init +
master_down_interval
Normal advertisement received master_down_interval

Normal preemption
MAX(remaining_value,
skew_time)
Neighbor seen the rst time (0

priority set)
Fast preemption 0

Neighbor seen the rst time
(better priority set)
(clears delay_after_init)

Normal preemption pre-
emption_time + remaining
master_down_timer
Neighbor seen the rst time
(worse priority set)
(clears delay_after_init)
Fast preemption
preemption_time
Normal preemption
MAX(remaining_value,
skew_time)
Neighbor modied priority (0

priority set)
Fast preemption 0

Neighbor modied priority
(better priority set)
Normal preemption remain-
ing master_down_timer
Fast preemption 0
Neighbor modied priority
(worse priority set)
wait_on_decrement
preemption_time+ remain-
ing master_down_timer
Object tracking uses own delay timer, which can be used to dampen apping on the tracked objects.
Object tracking is described in 10.3.2 Object Tracking.
Object Tracking
Event Description
State change in tracked object Start/restart tracking_delay timer.
Tracking delay timer ready Modify priority, send advertisement with new priority
Tellabs
8600 Smart Routers 76.8600-50121F

108
10.3 VRRP Supported Features
10.3.1 Implementation
In the Tellabs 8630 smart router and Tellabs 8660 smart router VRRP is implemented according
to [RFC3768] specication. VRRP is only supported on Ethernet interfaces in IFC2 and in ELC1
line cards.
Interface Conguration VRRP Support
Interface Conguration IFC2 Line Card ELC1 Line Card
Ethernet Yes Yes
Ethernet VLAN Yes Yes
With Integrated Routing and
Bridging (IRB)
Yes Yes
With Virtual Routing and
Forwarding (VRF)
Yes Yes
With Link Aggregation (LAG) Yes
With Ethernet Layer Protection
(ELP)
Yes Yes
VRRP authentication, VRRP with IPv6 addresses and Multiple virtual IP addresses on one
VRRP group are not supported.
10.3.2 Object Tracking
VRRP by itself is unable to detect failures in upstream connections. This is because VRRP
communicates only with the LAN that it is directly connected. For example, in case shown in
Fig. 37, if Router-1 loses connection to the cell site, then Router-2 would be better choice to be the
master. However, the connection between Router-1 and Router-2 would still operational and there
would be no mastership transition. Object tracing is implemented to address this issue, it allows
VRRP to track the state of interfaces, track presence of routes in RIB and track the state of arbitrary
Bidirectional Forward Detection (BFD) sessions. In case of a failure, the VRRP group priority can
be reduced by a predened amount. That amount must be set in object tracking conguration,
and it is dened in a range of 1...255.
Object tracking can be also used to monitor the current master. This is useful because mastership
transition takes quite long time if it relies only on VRRP advertisement messages. Typical hello
interval is one second, therefore, it can take up to 3 seconds plus skew_timefor mastership
transition. This time can be reduced signicantly when object tracking is used. For this type of
tracking a special neighborhood tracking feature is supported, which allows a router to track single
neighbor and assume mastership immediately when the tracked neighbor becomes inactive.
Tracking delay option can also be used to add additional dampening to tracking. This adds a timer
(tracking_delay), which is started whenever a change occurs on tracked object and a new
priority is evaluated only after this timer expires. The tracking_delay timer operates as follows:
76.8600-50121F Tellabs
8600 Smart Routers

109
1. The timer starts with, tracking_delay = A
2. When subsequent changes occur new timer is scheduled with an increment N based on,
tracking_delay = MIN(A+B*2^(N-1), C)
Where:
A - is initial delay;
B - is multiplier;
C - is the maximum delay.
Each parameter above has to be given when this option is set. The timers are reset when a period of
twice the maximum delay is elapsed without changes.
When using directly connected routes and a L2 Ethernet switching in the upstream side
(Fig. 37 PSN side), it is possible to get into a situation where ARP either has not yet been
resolved, or has already expired on the backup router when a mastership switchover is
performed. This can happen when there is no trafc owing trough the backup router and this
might lead to trafc break for several seconds after transition to master role. This behavior
can be avoided by either using static ARP entries, or by ensuring that there is a periodic trafc.
Periodic trafc can be generated using for example BFD with long interval (several seconds).
10.3.3 VRRP with IRB
Since VRRP operates only in single LAN, it requires at least one switch to operate. The Tellabs 8630
smart router and Tellabs 8660 smart router can be used to implement the switching functionality by
using Integrated Routing and Bridging (IRB). This is useful if an external switch is not available
and the RNC does not have internal switching capability either. If additional switches are already
present, there is a risk of creating Ethernet loops within IRB. In such case, an extra care must
be exercised to avoid loops.
Tellabs
8600 Smart Routers 76.8600-50121F

110
Fig. 39 VRRP with IRB
An application example where IRB should be used is shown in Fig. 39. In this case, the RNC does
not have an internal switching capability. IRB can be congured to both routers to add the required
switching functionality. In that case, VRRP will be operating on the logical IRB interface. For more
details about IRB, please refer to Tellabs
8600 Smart Routers Ethernet Conguration Guide.

When VRRP is congured to an IRB interface, it is possible to get into a situation where the
IRB interface comes up before the connected physical interfaces. In this case, the VRRP
instance cannot communicate with the neighboring node and assumes mastership role. If
the neighboring node has a higher priority, this will lead to an unnecessary mastership role
transition(s). To prevent this behavior, there is a CLI command option delay_after_init
that sets a delay for the transition to master role when a VRRP session is initialized.
10.3.4 Accept Data
By the standard denition routers do not accept data with destination to a virtual IP address. This
makes it impossible to receive Internet Control Message Protocol (ICMP) requests destined to a
virtual IP addresses. However, in some cases ICMP packets are useful for verifying connectivity.
In such cases, accept data option can be enabled to allow the current master to reply ICMP echo
requests.
76.8600-50121F Tellabs
8600 Smart Routers

111
10.4 VRRP Faults
Fault Name Description
State transition from backup to
master
VRRP generates delta fault when transition from backup to master
occurs. This is done due to the fact that such transitions are typically
an indication of some problems in the master router.
Conict in VRRP conguration All routers in the same VRRP group share the same conguration
and when a conict is detected, a fault is raised. These faults
are generated in the backup routers, when they receive VRRP
advertisement messages that conict with the backup routers own
conguration.
Tracked object down This fault is generated when tracked object goes down.
10.5 VRRP References
[RFC3768] RFC3768 (200404), Virtual Router Redundancy Protocol (VRRP)
Tellabs
8600 Smart Routers 76.8600-50121F

112
11 VRRP CLI Conguration Examples

11.1 VRRP Conguration
This chapter provides VRRP CLI conguration examples. The conguration scenario used is
depicted in Fig. 40.
Fig. 40 VRRP Conguration Topology
In Fig. 40, two VRRP groups will be created with two different types of object tracking. The
conguration for both VRRP routers is identical, with only exception of VRRP group priorities
assignment that are different.
76.8600-50121F Tellabs
8600 Smart Routers

113
The VRRP group 10 in Router1 is used to route trafc from RNC with gateway address 1.1.1.10
to the PSN. VRRP group priority is congured to 150 and Router1 will be the master for VRRP
group 10 because Router2 has lower priority assigned for the group. Object tracking will be used
to monitor the interface connected to the PSN network. If state of the interface goes down, priority
of the VRRP group will be decreased and that will lead to mastership transition.
VRRP group 11 is congured to have lower priority in Router1 than in Router2. Thus Router1
will act as a backup for gateway 1.1.1.11. Router1 will become a master if Router2 becomes
inactive or the connection between RNC and Router2 is lost. BFD tracking is used to react as
fast as possible to the failure.
11.1.1 Router1 Conguration
VRRP group 10 conguration
Step 1 Create a VRRP group with an ID 10 and priority 150. This will be the master session for trafc
using the default gateway address 1.1.1.10.
There may be several different VRRP group instances with different IP address under any interface.
VRRP group ID is unique only under the interface where it is dened.
router-1(config)# interface ge 11/1/0
router-1(cfg-if[ge11/1/0])# ip vrrp 10 1.1.1.10 priority 150
Step 2 Set preemption mode to fast. Default is immediate takeover.
router-1(cfg-if[ge11/1/0])# ip vrrp 10 preempt fast
Step 3 Enable VRRP ICMP echo requests to the VRRP group.
router-1(cfg-if[ge11/1/0])# ip vrrp 10 accept-data
Step 4 Create second tracking object instance to monitor interface state towards the PSN. Start interface
tracking.
Note there can be many track statements in any VRRP group. By default tracking is not enabled.
router-1(cfg-if[ge11/1/0])# track track2
router-1(cfg-track[track2])# target interface ge 11/1/1
Step 5 Track interface and decrease priority by 60 in case of failure. The decrement interval is dened
in range 1...255.
In this example, when a failure occur VRRP group priority will be decreased from 150 to 90 and a
backup session can switch to master state if it has priority lower than 90.
router-1(cfg-track[track2])# interface ge 11/1/0
router-1(cfg-if[ge11/1/0])# ip vrrp 10 track track2 decrement 60
Tellabs
8600 Smart Routers 76.8600-50121F

114
Step 1 Create a VRRP group with an ID 11 and priority 95. This will be the backup session for trafc using
the default gateway address 1.1.1.11.
Step 2 Set preemption mode to fast.
Step 4 Start BFD session towards other VRRP router.
router-1(cfg-if[ge11/1/0])# ip bfd 1.1.1.1
Step 5 Create tracking object instance.
Step 6 Tracking object is bound to BFD session.
router-1(cfg-track[track1])# target ip bfd ge 11/1/0 1.1.1.1
router-1(cfg-track[track1])# exit
Step 7 Enable VRRP neighbor tracking.
router-1(cfg-if[ge11/1/0])# ip vrrp 11 track track1 neighbor 1.1.1.1
11.1.2 Router2 Conguration
VRRP group 10 conguration:
Step 1 Create a VRRP group with an ID 10 and assign priority 95. This will be the backup session for
trafc using the default gateway address 1.1.1.10.
Step 2 Set preemption mode to fast.
Step 4 Start BFD session towards other VRRP router.
router-2(cfg-if[ge6/0/0])# ip bfd 1.1.1.2
Step 5 Create a tracking object instance and set the target interface bound to BFD session.
router-2(cfg-track[track1])# target ip bfd ge 6/0/0 1.1.1.2
Step 6 Enable monitoring VRRP neighbor.
router-2(cfg-if[ge6/0/0])# ip vrrp 10 track track1 neighbor 1.1.1.2
76.8600-50121F Tellabs
8600 Smart Routers

115
Step 1 Create a VRRP group 11 and assign priority 150. This will be the master session for trafc using
the default gateway address 1.1.1.11.
Step 2 Set preemption mode.
Step 4 Create tracking object instance.
router-2(cfg-track[track2])#
Step 5 Set the target interface of the tracked object.
router-2(cfg-track[track2])# target interface ge 6/0/1
router-2(cfg-if[ge6/0/0])#
Step 6 Enable tracking object to the VRRP group and set the priority decrement interval.
router-2(cfg-if[ge6/0/0])# ip vrrp 11 track track2 decrement 60
11.2 VRRP with IRB Conguration
This chapter provides an example of how to congure VRRP with IRB. When VRRP is used with
IRB, an additional IRB interface conguration is required and the details of IRB conguration are
covered in Tellabs
8600 Smart Routers Ethernet Applications Conguration Guide.

Tellabs
8600 Smart Routers 76.8600-50121F

116
Fig. 41 VRRP with IRB Conguration Topology
To accomplish this conguration, the following steps are required:
Create a bridging instance
Set the IRB forwarding-mode exible in the case ELC1 line card is used
Binding the bridging instance to an interface(s)
Congure an IRB interface
Create a VRRP group
IFC2 line card based IRB conguration ow is covered in this example.
Router-1 conguration:
Step 1 Create a bridging instance with an ID.
router-1(config)# bridging-instance bridge1 10
router-1(cfg-bridge-inst[10])#
Step 2 Bind the bridging instance to interface ge11/1/0.
router-1(cfg-bridge-inst[10])# interface ge 11/1/0
router-1(cfg-if[ge11/1/0])# bridging bridging-instance bridge1
router-1(cfg-if[ge11/1/0])# no shutdown
router-1(cfg-if[ge11/1/0])# exit
76.8600-50121F Tellabs
8600 Smart Routers

117
Step 4 Congure an IRB interface.
router-1(cfg-if[ge11/1/1])# interface irb10
router-1(cfg-if[irb10])# ip address 1.1.1.2/24
router-1(cfg-if[irb10])# no shutdown
Step 5 Create a VRRP group with an ID and priority.
router-1(cfg-if[irb10])# ip vrrp 10 1.1.1.10 priority 150
Step 6 Wait 5 minutes (300000 ms) after the VRRP initialization before mastership role can be assumed.
router-1(cfg-if[irb10])# ip vrrp 10 delay-after-init 300000
Router-2 conguration:
Step 1 Create a bridging instance with an ID.
router-2(config)# bridging-instance bridge1 10
router-2(cfg-bridge-inst[10])#
router-2(cfg-if[ge6/0/0])# exit
Step 4 Congure an IRB interface.
router-2(cfg-if[ge6/0/1])# interface irb10
router-2(cfg-if[irb10])# ip address 1.1.1.1/24
router-2(cfg-if[irb10])# no shutdown
Step 5 Create a VRRP group with an ID and priority.
router-2(cfg-if[irb10])# ip vrrp 10 1.1.1.10 priority 95
Step 6 Wait 5 minutes (300000 ms) after the VRRP initialization before mastership role can be assumed.
router-2(cfg-if[irb10])# ip vrrp 10 delay-after-init 300000
11.3 VRRP Status
VRRP status can be inspected by using any of the commands outlined in the following table.
Command Description
show ip vrrp interface The command displays local VRRP interface status.
show ip vrrp interface ge11/1/0 The command displays status of the specied VRRP
interface.
show ip vrrp interface ge11/1/0 vrid 10 The command displays status of the specied VRRP
interface group ID.
show ip vrrp interface ge 11/1/0 log The command displays recent log events of the specied
VRRP interface.
Tellabs
8600 Smart Routers 76.8600-50121F

118
Command Description
show track The command displays information about the current state
of the tracking object.
show track track1 The command displays information about the state of the
specied tracking object.
show track track1 log The command displays latest log events of the tracking
object of interest.
The following gures illustrate some examples of what VRRP status of the conguration depicted
in Fig. 40.
Fig. 42 VRRP Status
Fig. 43 VRRP Interface Status
76.8600-50121F Tellabs
8600 Smart Routers

119
Fig. 44 VRRP Specic Interface Status
Fig. 45 VRRP Tracking Object Status
Tellabs
8600 Smart Routers 76.8600-50121F

120

Routing Protocols Con Guration Guide

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Routing Protocols Con Guration Guide

Transféré par

Droits d'auteur :

Formats disponibles

Tellabs

8600 Smart Routers

8600 Smart Routers 76.8600-50121F

logo, TELLABS and T symbol

8600 Smart Routers 76.8600-50121F

8600 Smart Routers

8600 Smart Routers 76.8600-50121F

8600 Smart Routers

8600 Smart Routers 76.8600-50121F

8600 Smart Routers

8600 Smart Routers 76.8600-50121F

8000 intelligent network manager provides access

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8605 Smart Router FP1.6 Embedded Software

8607 Smart Router FP1.1 Embedded Software Re-

8609 Smart Router and Tellabs

8611 Smart Router

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers 76.8600-50121F

8600 Smart Routers

8605 Smart Router FP1.6 Interface Conguration

8607 Smart Router FP1.1 Interface Conguration

8609 Smart Router Tellabs

8611 Smart Router

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8605 Smart Router FP1.6 Reference

8607 Smart Router FP1.1

8609 Smart Router FP1.2

8611 Smart Router FP1.2 Refer-

8620 Smart Router

8630 Smart Router FP4.1 Reference Manual

8660 Smart Router FP4.1 Reference Manual

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8600 Smart Routers

8000 Intelligent Network

8600 Smart Routers 76.8600-50121F

8600 Smart Routers CLI Commands Manual.

8600 Smart Routers

8600 Managed Edge System Tellabs

8600 Smart Routers

8605 Access Switch Tellabs

8605 Smart Router

8607 Access Switch Tellabs