76 8600 50121h 8600 smart routers routing protocols configuration guide

Terms and AbbreviationsABR Area Border RouterAFI Authority and Format IdentifierARP Address Resolution Protocol AS Autonomous SystemASBR Autonomous System Border RouterBFD Bidirectional

Routing Protocols Configuration Guide

76.8600-50121H 15.05.2015

Revision History Document No Date Description of Changes

76.8600-50121H 15.05.2015 Added support of 8615 Smart Router stacked and 8665 Smart

Added:

• 6.4 IS-IS L1 to L1 Route Redistribution Configuration

• 3.12 BGP Multipath

76.8600-50121G 29.10.2014 Added 8602 Smart Router and 8615 Smart Router

Added a note clarifying the support of unnumbered links in

1.7 OSPF Unnumbered Links.Updates and changes applied in9 Equal Cost Multipath (ECMP).Changes and updates applied in10.3.1 VRRP Configuration.Added2.4 OSPF Authentication

Added3.2 Router ID.Changes and updates in4 BGP Configuration Examples.76.8600-50121F 13.01.2014 Renewed related documentation table in8600 Smart Routers

Technical Documentation.Added ECMP support in ELC1 line card in9 Equal Cost Multipath(ECMP)

Added3.10 BGP Failover.Added support of BFD for single hop BGP in7 BidirectionalForwarding Detection

Updates applied in6.1 IS-IS Basic Configuration.Added a configuration example of8.1.4 Single Hop BGP.Added clarification of VRRP multiple instances configuration to

an interface in10.2.1 VRRP Parameters.Added ELC1 support of VRRP + IRB and VRRP + ELP in

10.3.1 VRRP Configuration.VRRP master and backup roles corrected in11.1.2 Router–2Configuration

Updates and corrections applied in8.2 BFD Configuration forStatic Routes

Changes applied in3.3 BGP Attributesand reworked

3.3.6 COMMUNITY Attribute

The functionality described in this document for 8615 Smart Router is also applicable to 8615 Smart Router stacked, unless otherwise stated.

© 2015 Coriant All rights reserved.

This manual is 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, modification,

distribution, display or other use of this manual may result in criminal and civil penalties.

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

Terms and Abbreviations

ABR Area Border RouterAFI Authority and Format IdentifierARP Address Resolution Protocol

AS Autonomous SystemASBR Autonomous System Border RouterBFD Bidirectional Forwarding DetectionBGP Border Gateway Protocol

CDC Control and DC Power CardCLI Command Line InterfaceCPU Central Processing UnitCSPF Constrained Shortest Path FirstDCN Data Communications Network

DD Database DescriptionDiffServ Differentiated Services

DR Designated RoutereBGP External Border Gateway ProtocolECMP Equal Cost Multipath

EGP Exterior Gateway ProtocolELP Ethernet Layer ProtectionES-IS End System to Intermediate SystemiBGP Internal Border Gateway ProtocolICMP Internet Control Message ProtocolIFC Interface Module ConcentratorIFM Interface Module

IGP Interior Gateway ProtocolIIH IS-IS Hello

IP Internet ProtocolIRB Integrated Routing and BridgingIS-IS Intermediate System to Intermediate SystemLAG Link Aggregation

LAN Local Area NetworkLDP Label Distribution ProtocolLSA Link State Advertisement

LSP Label Switched PathLSP Link State PacketLU1 Line Unit in 8665 Smart RouterMAC Media Access Control

MDA Message Digest AuthenticationMED Multi Exit DiscriminatorMPLS Multiprotocol Label SwitchingNBMA Non-Broadcast MultiaccessNET Network Entity TitleNSAP Network Service Access PointNSEL NSAP selector

NSSA Not-So-Stubby AreaORF Outbound Route FilterOSPF Open Shortest Path FirstQoS Quality of ServiceRFC Request For Comments (IETF documents)RFD Route Flap Damping

RIB Routing Information BaseRID Router ID

RR Route ReflectorRSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions

RT Route TargetSAFI Subsequent Address Family IdentifierSCM Switching and Control ModuleSLA Service Level AgreementSPF Shortest Path FirstSOO Site of OriginTCP Transmission Control Protocol

TE Traffic Engineering

Table of Contents

About This Manual 11

Objectives 11

Audience 11

8600 Smart Routers Technical Documentation 11

Interface Numbering Conventions 15

Documentation Feedback 15

8600 Smart Routers Discontinued Products 16

1 OSPF 17

1.1 Overview 17

1.2 OSPF Hierarchical Routing 17

1.2.1 Autonomous System 17

1.2.2 Areas 18

1.3 OSPF Hello Messages and Link State Advertisements 18

1.4 Extensions for Support of Differentiated Services-Aware MPLS Traffic Engineering 19

1.5 OSPF Graceful Restart 19

1.6 Fast OSPF Adjacency Establishment 19

1.7 OSPF Unnumbered Links 20

1.8 OSPF References 21

2 OSPF Configuration Examples 22

2.1 Basic Configuration 22

2.2 Interface Configuration 22

2.3 Area Configuration 23

2.4 OSPF Authentication 23

2.5 TE Configuration 24

2.6 Graceful Restart Configuration 24

2.7 Fast OSPF Convergence 25

2.8 Fast OSPF Adjacency Establishment Configuration 26

2.8.1 Enabling Hello replies 26

2.8.2 Designated Router (DR) Wait Time Configuration 27

2.9 OSPF Unnumbered Links Configuration 29

2.10 OSPF Status 29

3 Border Gateway Protocol 31

3.1 Overview 31

3.2 Router ID 34

3.3 BGP Attributes 35

3.3.1 ORIGIN Attribute 36

3.3.2 AS PATH Attribute 36

3.3.3 NEXT HOP Attribute 37

3.3.4 LOCAL PREFERENCE Attribute 38

3.3.5 ATOMIC AGGREGATE Attribute 39

3.3.6 COMMUNITY Attribute 39

3.3.7 AGGREGATOR Attribute 40

3.3.8 MED Attribute 41

3.4 Managing Route Preferences 42

3.5 BGP Routing Policy 43

3.5.1 Route Map 44

3.6 Route Aggregation 46

3.6.1 Configuration Parameters 48

3.6.2 BGP IP VPN Route Aggregation 48

3.6.3 Route Aggregation Support 49

3.7 Route Flap Damping 50

3.7.1 RFD Configuration 51

3.8 Route Refresh 52

3.9 Increasing AS Scalability 52

3.9.1 Route Reflector 52

3.9.2 AS Confederation 54

3.10 BGP Failover 55

3.10.1 iBGP and Multihop eBGP Sessions 55

3.10.2 Single Hop eBGP 56

3.10.3 Performance of BGP Failover 57

3.11 BGP Multiprotocol Extensions 57

3.11.1 BGP Labeled Unicast 57

3.12 BGP Multipath 57

3.12.1 Limitations and Restrictions 59

3.13 BGP References 60

4 BGP Configuration Examples 61

4.1 Basic Configurations 61

4.1.1 BGP Peers Configuration 62

5 IS-IS 80

5.1 Overview 80

5.2 Routing Areas 80

5.3 Addressing 81

5.4 Multihoming 82

5.5 Multiarea Routing 82

5.6 Open Shortest Path Algorithm 83

5.7 Adjacencies and Hello Packets 83

5.8 Link-State Database and Link-State Packets 83

5.9 Route Summarization 83

5.10 Route Redistribution 84

5.10.1 Redistribution of Static and IGP Routes 84

5.10.2 IS-IS Routes Redistribution from L2 to L1 84

5.10.3 Redistribution between IS-IS L1 to L1 Instances 85

5.11 Authentication 87

5.12 Extensions for Support of Differentiated Services-Aware MPLS Traffic Engineering 87

5.13 IS-IS References 87

6 IS-IS Configuration Examples 88

6.1 IS-IS Basic Configuration 88

6.1.1 IS-IS Process Configuration 89

6.1.2 IS-IS Interface Configuration 89

6.2 IS-IS Area Configuration 90

6.2.1 Router 1 Configuration 91

6.2.2 Router 3 Configuration 92

6.2.3 Router 4 Configuration 92

6.3 Fast IS-IS Convergence 93

6.4 IS-IS L1 to L1 Route Redistribution Configuration 94

6.4.1 Configuration Summary 94

6.4.2 Configuring Routes Redistribution 94

7 Bidirectional Forwarding Detection 96

7.1 Overview 96

7.2 BFD in Dynamic Routing 97

7.3 BFD in Static Routing 98

7.4 BFD References 98

8 BFD Configuration Examples 99

8.1 BFD Configuration with Routing Protocols 99

8.1.1 OSPF 99

8.1.2 IS-IS 99

8.1.3 RSVP-TE 100

8.1.4 Single Hop BGP 100

8.2 BFD Configuration for Static Routes 103

8.2.1 BFD Status 104

9 Equal Cost Multipath (ECMP) 106

9.1 Overview 106

9.2 ECMP Network Application 106

9.3 ECMP Operation 107

9.3.1 Dynamic Routing 107

9.3.2 Static Routing 108

9.3.3 Forwarding Plane Functions 108

9.3.4 Scalability 109

10 Virtual Router Redundancy Protocol 110

10.1 Introduction 110

10.2 Operation 110

10.2.1 VRRP Parameters 112

10.2.2 VRRP Timers 113

10.3 VRRP Supported Features 115

10.3.1 VRRP Configuration 115

10.3.2 VRRP Object Tracking 116

10.3.3 VRRP with IRB 117

10.3.4 VRRP Accept Data 118

10.4 VRRP Faults 118

10.5 VRRP References 118

11 VRRP CLI Configuration Examples 119

11.1 VRRP Configuration 119

11.1.1 Router–1 Configuration 120

11.1.2 Router–2 Configuration 121

11.2 VRRP with IRB Configuration 122

11.3 VRRP Status 124

About This Manual

This chapter discusses the objectives and intended audience of this manual, 8600 Smart Routers

Protocols Configuration Guide and consists of the following sections:

8600 Smart Routers Technical Documentation

The document numbering scheme consists of the document ID, indicated by numbers, and thedocument revision, indicated by a letter The references in the Related Documentation table beloware generic and include only the document ID To make sure the references point to the latestavailable document versions, please refer to the relevant product document program on the Tellabsand Coriant Portal by navigating towww.portal.tellabs.com> Product Documentation & Software

> Data Networking > 8600 Smart Routers > Technical Documentation

Document Title Description

8600 Smart RoutersATM and TDM Configuration Guide(76.8600-50110)

Provides an overview of 8600 NEs PWE3 applications,including types, Single-Segment and Multi-Segment; PWE3Redundancy; ATM applications, including PWE3 tunnelling,Traffic Management, Fault Management OAM, protection andTDM applications as well as instructions on how to configurethem with CLI

8600 Smart RoutersBoot and Mini-ApplicationsEmbedded Software Release Notes(76.8600-50108)

Provides information related to the boot and mini-applicationssoftware of 8605 Smart Router, 8607 Smart Router, 8609Smart Router, 8611 Smart Router, 8620 Smart Router, 8630Smart Router and 8660 Smart Router as well as the installationinstructions

8600 Smart RoutersCLI Commands Manual(76.8600-50117)

Provides commands available to configure, monitor and maintain

8600 system with CLI

8600 Smart RoutersEmbedded Software Release Notes

8600 Smart Routers SR7.0 Embedded Software Release Notes(76.8670-50177) for the following products:

Provides an overview of 8600 system HW inventory, softwaremanagement, equipment protection 1+1 (CDC and SCM) as well

as instructions on how to configure them with CLI

8600 Smart RoutersEthernet Configuration Guide (76

8600-50133)

Provides an overview of 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 configure them with CLI

8600 Smart Routers Smart RoutersFault Management ConfigurationGuide (76.8600-50115)

Provides an overview of 8600 system fault management,including fault source, types and status as well as instructions onhow to configure it with CLI

8600 Smart RoutersFrame Relay Configuration Guide(76.8600-50120)

Provides an overview of 8600 system Frame Relay applications,including interfaces; Performance Monitoring; protection; TrafficManagement as well as instructions on how to configure themwith CLI

8600 Smart RoutersHardware Installation Guide(76.8600-40039)

Provides guidance on mechanical installation, cooling,grounding, powering, cabling, maintenance, commissioning andESW downloading

Document Title Description

8600 Smart RoutersInterface Configuration Guides The Interface Configuration Guides provides an overview of the8600 NEs interface functions, including NE supported interface

types and equipping; interface features; configuration options andoperating modes; fault management; performance monitoring;interface configuration layers and port protocols as well asinstructions on how to configure them with CLI The followinginterface configuration guides are available:

• 8600 Smart Routers Network Interfaces ConfigurationGuide (76.8600-50161) (for 8602 Smart Router, 8615 SmartRouter and 8665 Smart Router)

• 8609 Smart Router and 8611 Smart Router FP7.0 InterfaceConfiguration Guide (76.8670-50179)

• 8600 Smart Routers FP7.0 Interface Configuration Guide(76.8670-50180) (for 8630 Smart Router and 8660 SmartRouter)

8600 Smart Routers

IP Forwarding and TrafficManagement Configuration Guide(76.8600-50122)

Provides an overview of 8600 NEs IP, forwarding and trafficmanagement 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 configure them with CLI

8600 Smart RoutersManagement CommunicationsConfiguration Guide

(76.8600-50125)

Provides an overview of 8600 system managementcommunications functions, including communication protocols:BMP; FTP; RADIUS; SNMP; SSH; TELNET as well asinstructions for configuring them with CLI

8600 Smart RoutersMobile Optimization ConfigurationGuide (76.8600-50100)

Provides an overview of 8600 system Mobile Optimizationapplications as well as instructions on how to configure themwith CLI

8600 Smart RoutersMPLS Applications ConfigurationGuide (76.8600-50123)

Provides an overview of 8600 NEs MPLS applications (includingFRR (one-to-one and facility backup); LDP; protection andTraffic Engineering), MPLS-TP applications (including OAM,linear protection), S-MPLS applications as well as instructions

on how to configure them with CLI

8600 Smart RoutersPerformance Counters ReferenceGuide (76.8600-50143)

Provides an overview of 8600 system supported performancecounters

Document Title Description

8600 Smart RoutersReference Manuals The reference manuals describe the 8600 network elementfeatures including:

• NE enclosure, baseboard, power supply modules, andinterfaces in 8602 Smart Router FP7.0 Reference Manual(76.8670-40130)

• NE enclosure, baseboard, power supply modules, interfacesand physical LM types in 8609 Smart Router FP7.0 Refer-ence Manual

• NE enclosure, baseboard, power supply modules, SCMs, HMand LM types in 8611 Smart Router FP7.0 Reference Manual

• NE enclosure, baseboard, power supply modules, and terfaces in 8615 Smart Router FP7.0 Reference Manual(76.8670-40132)

in-• NE subrack, fan modules, CDCs, line cards and IFMs in 8630Smart Router FP7.0 Reference Manual

• NE subrack, fan modules, CDCs, line cards and IFMs in 8660Smart Router FP7.0 Reference Manual

• NE subrack, fan modules, line unit and switch unit in 8665Smart Router FP7.0 Reference Manual (76.8670-40128)

8600 Smart RoutersRouting Protocols ConfigurationGuide (76.8600-50121)

Provides an overview of 8600 NEs routing protocols, includingBFD; BGP; BGP MP; ECMP; IS-IS; OSPF and VRRP as well asinstructions on how to configure them with CLI

8600 Smart RoutersScalability Reference Manual(76.8600-50160)

Provide a summary of tested scalability limits of the 8600 SmartRouters

8600 Smart RoutersSNMP MIB Support(76.8600-50116)

Describes SNMP MIB support by the 8600 NEs and providesinformation on the supported objects and traps For furtherinformation on SNMP MIBs, see the related RFCs

8600 Smart RoutersStatistic Counters Reference Guide(76.8600-50142)

Provides an overview of 8600 system supported statistic counters

8600 Smart RoutersSynchronization ConfigurationGuide (76.8600-50114)

Provides an overview of 8600 NEs synchronization functionality,including physical layer Frequency Synchronization (SEC, EEC);PTP Frequency Synchronization; Phase-Time Synchronization(L2 and L3 applications) as well as instructions on how toconfigure them with CLI

8600 Smart RoutersTest and Measurement ConfigurationGuide (76.8600-50124)

Provides an overview of 8600 NEs measurement and connectivityverification tools, including Ethernet loopback; IP ping andtraceroute; MAC swap loopback; MPLS ping and traceroute;PLT; PWE3 loopback; VCCV (BFD, LSP ping) as well as

Interface Numbering Conventions

To be able to follow more easily the feature descriptions and configuration examples given in this

document, see also the 8600 system interface numbering and related figures described in 8600

Smart Routers CLI Commands Manual.

Documentation Feedback

Please contact us to suggest improvements or to report errors in our documentation:

Email: fi-documentation@tellabs.com

8600 Smart Routers Discontinued Products

8600 Smart Routers Manufacture Discontinued (MD) notifications are available on the Tellabsand Coriant Portal,www.portal.tellabs.com > Product Documentation & Software > Data Networking > [8600 Smart Router product name] > Product Notifications.

to the same area have an identical link-state database OSPF quickly detects topological changesand calculates new loop-free routes.

Routers that connect areas are Area Border Routers (ABRs) and they must be part of the ASbackbone For communication to happen between areas, each ABR advertises reachabilityinformation to all other areas

All OSPF protocol exchanges can be authenticated This means that only trusted routers canparticipate in the routing

Externally derived routing data, i.e routes learned from Border Gateway Protocol (BGP), areadvertised 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 thepassing of additional information between routers on the boundary of the AS

OSPF can be augmented with Traffic Engineering (TE) extensions TE extensions announceinformation about the reservation status of the links DS-TE extensions advertise the reservationstatus per TE class for each link That information is used when Label Switched Paths (LSPs) areset up by Resource Reservation Protocol with Traffic Engineering Extensions (RSVP-TE) signaling

With hierarchical routing it is possible to build much larger OSPF networks When networks growthe 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 thetopology of an area from the rest of the AS OSPF supports two-level hierarchical routing

1.2.2 Areas

A group of networks and hosts, together with the routers having interfaces to any one of the includednetworks, 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 cannotsee the topology, which reduces routing traffic within the AS The router that belongs to morethan 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 areadistributes the routing information between all other areas The backbone must be contiguous butnot 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 inthat area External advertisements of the AS are not flooded into or through stub areas Routing tothe 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 floodedwithin the area but does not accept external routes from the other areas

OSPF router uses the Hello messages of OSPF to acquire neighbors On Broadcast andNon-Broadcast Multiaccess (NBMA) networks the designated router for the network is elected byHello protocol The router will setup adjacencies with new neighbors

Link state databases are synchronized between adjacent routers A router periodically advertisesits link state Link state is also advertised when the state of the router changes Link StateAdvertisements (LSAs) are flooded throughout the area The advertisements depict the topology

of the AS The flooding algorithm is reliable, ensuring that all routers in an area have exactlythe same link-state database

The database is used to determine the route to each destination The routes are calculated by usingthe SPF algorithm Such calculation is used within a single area For inter-area routes summaryLSAs are generated by ABRs for other areas AS border routers flood information about externalroutes (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 AllOSPF protocol packets share a common protocol header [RFC2328] There are five different OSPFpackets [RFC2328] (also for other relevant RFCs, please see1.8 OSPF References):

1.4 Extensions for Support of Differentiated Services-Aware MPLS

Traffic Engineering

In the networks where optimization of transmission resources is seen important, mechanisms ofDifferentiated Services can be complemented by Multiprotocol Label Switching (MPLS) TEmechanisms To implement DS-TE in the network, OSPF must support extensions where linkreservation status per each TE class is exchanged between the routers Opaque LSA extensions areused for this purpose Traffic 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

8600 Smart Routers MPLS Applications Configuration Guide.

OSPF graceful restart support enables OSPF router to stay on the forwarding path even if itsOSPF software is restarted The router that is restarting sends out link-local Opaque LSA, GraceLSA, which indicates its intention to perform a graceful restart within a specified amount of time.Neighboring routers, which receive Grace LSAs, continue to announce the restarting router in theirLSAs as if it were fully adjacent, but only if the network topology remains static

When a link goes up, OSPF can take quite long time to negotiate adjacencies on the link This iscaused 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 newneighbor appears, it might take almost 10 seconds, which is the default hello timer, for the firstrouter to acknowledge the existence of the new router As reaching full adjacency takes severalround 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 OSPFspeakers will wait 40 seconds (the default wait time is the same as the dead time) to ensure thatthere is indeed no OSPF DR active

This means that after a transient link failure, it can take over one minute for OSPF to reestablish thelink The 8600 system implements three strategies to allow the fast reestablishment of OSPF links

in case of transient failure

• Immediately replying Hello as specified in [draft-kou-ospf-immediately-replying-hello] Withthis 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 traffic Hello replies avoid thepenalty 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 nooverhead is incurred To prevent malfunctioning routers from causing a hello storm, a limit can

be specified for the number of hello replies that can be sent between any two periodic hellos

• Configurable Designated Router (DR) wait time This configuration parameter allows setting the

DR wait time independently from the dead time When hello acknowledgements are used, DRwait time can be very small, as the DR is guaranteed to respond almost immediately to hellosfrom the routers joining the network If the DR wait time is set to zero, IS-IS like behavior isobtained, 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 islonger than the hello interval or the hello acknowledgements are used and DR wait time is longerthan the time it takes for the DR to respond to the hellos, e.g 500 ms

• Optimized Database Description (DD) exchange as specified in [draft-ogier-ospf-dbex-opt] Withthis optimization, a router does not list an LSA in Database Description packets sent to a neighbor,

if the same or a more recent instance of the LSA was listed in a Database Description packetalready 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 onehalf when the two routers are already nearly synchronized This optimization does not affectsynchronization, since it only omits unnecessary information from Database Description packetsand it is fully backward compatible with OSPF

The 8600 system supports unnumbered IPv4 links as specified in [RFC1812] Unnumbered links arepoint-to-point links that connect two routers but do not have an IP address Unnumbered links areused 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 easierconfiguration and network planning On the other hand, unnumbered links in the 8600 system donot support LDP or RSVP Maintenance is more difficult 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 theassociated interface is a loopback, though other interface types are also permitted However, if theassociated interface goes down, the operation of unnumbered interface is also hindered, hence usingloopback as an associated interface is recommended

The address of the associated interface is used as a source address for locally generated packets

1.8 OSPF References

[draft-ietf-tewg-diff-te-proto] draft-ietf-tewg-diff-te-proto-07.txt (2004–03), Protocol extensions

for support of Differentiated-Service-aware MPLS TrafficEngineering

replying-hello]

[draft-kou-ospf-immediately-draft-kou-ospf-immediately-replying-hello-02.txt (2007–01),Update to OSPF Hello procedure

[draft-ogier-ospf-dbex-opt] draft-ogier-ospf-dbex-opt-00.txt (2006–06), OSPF Database

Exchange Summary List Optimization[RFC1812] RFC1812 (1995–06), Requirements for IP Version 4 Routers[RFC2328] RFC2328 (1998–04), OSPF version 2 (OSPFv2)

[RFC3623] RFC3623 (2003–11), Graceful OSPF restart[RFC3630] RFC3630 (2003–09), Traffic Engineering (TE) extensions to OSPF

version 2

2 OSPF Configuration Examples

This section gives some CLI examples of OSPF configuration in the 8600 system

It is advisable to always refer to 8600 Smart Routers CLI Commands Manual for the latest

information on:

• Default values to avoid unnecessary configuration;

• Available configuration options and parametric range

To enter the Configuration mode and to set up routing process use the following command

Step 1 Activate and define 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 configured 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 loopbackaddress 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

The following is an example of OSPF settings at interface level

Step 1 Set the OSPF cost to 10.

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

An AS can be split into multiple areas in order to reduce LSA traffic and the size of the LSAdatabases, the routers need to maintain

In chapter2.1 Basic Configurationthe 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(config)# router ospf 10

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 protocolinto a stub area An NSSA allows external routes to be flooded within the area These routes arethen leaked into other areas The external routes from other areas still do not enter the NSSA Toconfigure area as NSSA use the following command

Step 1 Note that with this command it is possible to define if the router will translate Type-7 LSAs

received from the NSSA into Type-5 LSAs Also to define whether or not to redistribute externalroutes to NSSA

router(cfg-ospf[10])# area 1.1.1.1 nssa

router(cfg-ospf[10])# exit

This chapter provides an example of setting OSPF authentication to an interface and includesthe following tasks:

• Creating a key chain

• Creating a key in the chain

• Enabling OSPF to use Message Digest Authentication (MDA)

• Setting an interface to use the key chain

Step 1 Create a key chain

router(config)# key chain ospf1chain

router(cfg-keychain[ospf1chain])#

Step 2 Create a key in the chain There can be multiple keys in the chain Note that compatible

configurations must be made in the neighboring network element

router(cfg-keychain[ospf1chain])# key 1

router(cfg-key[ospf1chain/1])# key-string wq1jh3t97587iuekgj

router(cfg-key[ospf1chain/1])# accept-lifetime 18:00:00 15 april 2015 infinite

router(cfg-key[ospf1chain/1])# send-lifetime 21:00:00 15 april 2015 infinite

router(cfg-key[ospf1chain/1])# exit

Step 3 Enable OSPF to use MDA authentication on the interface

router(config)# interface fe 3/0/1

router(cfg-if[fe3/0/1])# ip ospf authentication message-digest

Step 4 Set the key chain to be used on the interface

router(cfg-if[fe3/0/1])# ip ospf message-digest-key—chain ospf1chain

router(cfg-if[fe3/0/1])# no shutdown

router(cfg-if[fe3/0/1])# exit

OSPF-TE is used together with RSVP-TE in traffic engineering applications A complete example

of this is given in 8600 Smart Routers MPLS Applications Configuration Guide, whereas this

guide illustrates the configuration needed for OSPF-TE For instance, the bandwidth constraintsand bandwidth constraints model configuration 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 traffic engineering extensions

router(config)# router ospf 10

router(cfg-ospf[10])# traffic-eng

Step 2 Enable constraint-based shortest path first calculation

router(cfg-ospf[10])# cspf

Step 3 You can specify cspf tie-break method (used if more than one candidate link satisfies all the route

constraints) This sets preferred path to be the one with the largest minimum available bandwidthratio This command is optional Default is random

router(cfg-ospf[10])# cspf tie-break least-fill

router(cfg-ospf[10])# exit

Graceful restart is enabled by default Default parameters are optimized to most networks and theyshould not be modified unless absolutely necessary You can configure graceful restart featurewith the following commands

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 sThis means that the first change of a kind is updated within 5 seconds, but later changes can take5+10=15 seconds

The 8600 system allows the use of exponential delay for these parameters As a result, the systemallows rapid response to a small number of events while preventing overload when multipleevents occur continuously

Both SPF and LSA refresh timers are based on exponential curves Both of them have threeparameters:

• Initial delay

• Multiplier

• Maximum delayThe first event is n=0 whereas the following events are 1, 2, 3 An event number is set to zerowhen 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 formulaused 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 theprev_event+delay would be before that) This allows the collecting of multiple events to a singleexecution The values are specified as milliseconds

The traditional OSPF values could be specified as stated in the following table

The 8600 system uses more optimized values for SPF

In the case of non-VRF SPF this would yield (for the constantly repeating event) the following SPFdelays: 200, 300, 400, 600, 1000, 1800, 3400, 6600, 10000, 10000, 10000,

LSA refresh timers are not optimized by default, as OSPF architectural constant MinLSArrivalmust 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 changesper network occur quickly However, sometimes it might be necessary to update the router LSAsfaster 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 thename says, not a refresh) N is zero for first 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 isreasonable, but to ensure that multiple events can update router LSA sufficiently fast, the multipliershould be sufficiently low

Normally updates are rate-limited to one LSA update per 33 ms Thus, it may become necessary

to allow faster flooding 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(config)# router ospf 10

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

router(cfg-ospf[10])# exit

2.8.1 Enabling Hello replies

router(cfg-if[fe0/0])# ip ospf hello-reply 15

router(cfg-if[fe0/0])# exit

2.8.2 Designated Router (DR) Wait Time Configuration

When the link has only two OSPF speakers, DR wait time can be optimized entirely This can beaccomplished by running the link in point-to-point mode This is also possible for Ethernet This isthe preferred configuration which allows the fastest OSPF link recovery times To use point-to-pointmode in a link that naturally is multicast or broadcast use the following command

Step 1 Enable the point-to-point mode.

Step 1 Set the DR wait time to zero for all interfaces.

router(config)# router ospf 10

The above configuration 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 configuration would makesense if DR is in the RNC front node and without it the network would be useless

• IS-IS behavior is desired and traffic interruption is permitted when a new router joins the subnet.The recommended configuration, when the point-to-point mode cannot be used, is to enable thehello acknowledgements and configure 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 torespond, if any DRs exist To configure the DR wait time for one or all interfaces use the followingcommands as it corresponds

Step 1 Set the DR wait time to 500 ms for all interfaces.

router(config)# router ospf 10

To get the full benefit of these optimizations, fast OSPF convergence should be configured asspecified below, there is no use in having the OSPF adjacencies for up in subsecond time frame, ifthe 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 first example illustrates a case with a ring of point-to-point links and a relatively small OSPFnetwork that allows the use of aggressive timers

Step 1 Enable the point-to-point mode

router(config)# interface fe 0/0

router(cfg-if[fe0/0])# ip ospf network point-to-point

router(cfg-if[fe0/0])# exit

Step 2 Generate LSA updates quickly

router(config)# router ospf 10

router(cfg-ospf[10])# timers lsa refresh 0 150 5000

Step 3 Default value

router(cfg-ospf[10])# timers spf 200 100 1000

Step 4 Accept LSAs quickly

router(cfg-ospf[10])# timers lsa arrival 50

Step 5 Disable LSA pacing

router(cfg-ospf[10])# timers pacing flood 0

Step 6 Permit hello replies

Step 2 Generate LSA updates quickly

router(config)# router ospf 10

router(cfg-ospf[10])# timers lsa refresh 0 150 5000

The OSPF parameters and hello reply statistics are available from the show ip ospf interface

command2.10 OSPF Status

The following is an example showing how to configure an OSPF unnumbered link for an interface

Step 1 Set the loopback interface

router(config)# ip interface lo0

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 define OSPF instance with ID 10.

router(config)# router ospf 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 particularOSPF area

The loopback address is the same for the node and for all the interfaces, so if there are customerinterfaces that you want to use as unnumbered, but do not wish to have them OSPF enabled, use adifferent loopback interface for those interfaces

OSPF can also be disabled from the customer interfaces by setting customer interfaces to passivemode using the following command

Step 1 Set the customer interface to passive mode

router(config)# router ospf 10

router(cfg-ospf[10])# passive-interface so 10/0/0

router(cfg-ospf[10])# exit

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

3 Border Gateway Protocol

Border Gateway Protocol (BGP) is a Routing Protocol that is used to create an inter-domainrouting between autonomous systems or inside of an Autonomous System (AS) The 8600 systemimplements BGP version 4 (BGP-4) according to [RFC1771] The main purpose of BGP is toexchange network reachability information, including a list of the autonomous systems and pathsconnectivity to other BGP routers The information is mainly used to construct a network topologyoutlining a loop free connectivity, where routing policy decisions can be enforced

BGP supports two different types of routing information exchanges, interior BGP (iBGP) andexterior BGP (eBGP)

An iBGP is used between BGP routers inside a single AS To prevent routing loops, iBGP to iBGPadvertisements are not allowed within the iBGP routers Therefore, in an AS, the iBGP routers musthave either a full-mesh connectivity, or use Router Reflector (RR), or confederations instead

An eBGP is used to exchange routing information between routers within different autonomoussystems In a typical case, eBGP routers are directly connected

Fig 2 BGP Topology

Fig 2illustrates a classical BGP network topology, where all routers within the AS65100 are iBGPpeers Route information exchange between AS65100, AS65200 and AS65300 is accomplishedthrough eBGP

A simple scenario of mobile backhaul BGP application with the 8600 system deployment (inter-ASwith multihoming connectivity) is presented in the following diagram Mobile backhaul typicalapplications use RR, which is described in3.9.1 Route Reflector.

Fig 3 Inter-AS BGP in Mobile Deployments

Another more complex mobile backhaul network scenario using BGP is presented in the followingdiagram

Fig 4 Complex Mobile Network BGP Application

In the transit autonomous systems, all P-routers on the path used by transit traffic must eitherparticipate in iBGP routing, or the Autonomous System Border Router(s) (ASBR) of the transit ASmust use MPLS tunnelling (BGP free core)

The following table defines the terms used in the BGP section including CLI configuration examples

Autonomous System (AS) An AS is defined as a consistent set of routers that are administered by a

single operator/ISP and advertise a coherent interior routing plan to theexternal 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

prefix/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, BGPpeers 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 reflector(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 reflection Route reflection is the advertisement of routes between iBGP peers by a

designated router, known as router reflector

Terminology Definition

Route Reflector (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 fromthe 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 ofnetworks and information on how the networks can be reached Initially, when the connection isestablished, the BGP peer routers exchange their full routing tables After a connection has beenestablished, only route changes (incremental or triggered) are advertised

In order to exchange routing information, a BGP peering session has to be established between twoBGP 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 toopen and confirm the peering session parameters The session is maintained by sending keepalivemessages, and in case of errors or in other special conditions, a notification 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

In 8600 NEs, there are two configuration options of Router ID (RID) as follows

• Node level RID – this is configured as global RID for a NE under the configuration mode Thisglobal RID can be used by the routing protocols in a given NE

• Protocol level RID – this is configured under specific routing process configuration mode Thissetting is solely used for the specific routing process

Routing protocols select/determine a router ID in the following way:

• If a RID is configured at protocol level, then this RID is used.

• If no protocol level RID is configured, but a node level RID is configured, then a node level RIDwill be assigned

• If no RID is configured either at node or protocol level, then the RID assignment will occur asfollows:

• If a loopback address has been configured, the RID will be assigned to the loopback address

If multiple loopback addresses are available, then the highest address will be selected as theRID

• If no loopback address is available, the RID will be assigned to the highest IP address of aninterface/VRF

• If either loopback or interface IP addresses are not available, then no RID can be assigned(i.e in this case will be all 0.0.0.0)

Usually it is preferable that a node level RID is configured in the NE, which will allow routingprotocols to work without any extra protocol level configuration tasks Also the loopback address ismore preferable rather than an interface address

The terms used in this chapter are defined in3.1 Overview In BGP, the attributes play an essentialrole to the operation of the protocol by making BGP flexible for later extensions, so that newfeatures can be added without changing the base protocol The BGP attributes are a set of parametersdescribing the detailed characteristics of a prefix or path information that can be used, for example,

to enforce path selection and routing policy The BGP attributes can be classified into the followingfour groups [RFC4271]:

1 Well-known mandatory These attributes are mandatory and must be recognized by all BGProuters They are included in all update messages exchanged by BGP peers

• AGGREGATOR

• COMMUNITY

4 Optional non-transitive These attributes may be recognized by some, but not by all BGProuters When an update message containing any attribute of this group is received by a routernot recognizing it, the update will be advertised to other BGP peers without the unrecognizedattribute

• MED (Multi-Exit-Descriminator)

3.3.1 ORIGIN Attribute

ORIGINis a well-known mandatory attribute that indicates the origin of routing information orhow a given route has been learned by BGP That is, the attribute is generated by the AS originatingthe associated routing information and it is included in the update message of all BGP speakersadvertising this information to other BGP speakers The attribute can be used to influence BGP pathpreference selection By the way in which a route is learned by BGP, the ORIGIN attribute canassume three possible values listed below in the precedence order:

• IGP (Interior Gateway Protocol), which indicates that the prefix is interior to the AS of tion;

origina-• EGP ( Exterior Gateway Protocol), which indicates that the prefix is originated from an EGPprotocol

• INCOMPLETE, which indicates the prefix has been learned via other sources

3.3.2 AS PATH Attribute

AS_PATHis a well-known mandatory attribute that identifies those autonomous systems throughwhich a route being announced has traversed The attribute will be handled differently depending onwhether the route is being originated, or propagated

When a BGP router originates a route, the AS_PATH information is empty in all the updates sentwithin the AS where the BGP router is located If the originating router has an eBGP sessionstowards neighboring autonomous systems, then a router will add its AS number when advertisingthe 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 notallowed to modify the AS_PATH attribute associated with a route However, if a route is beingpropagated from one local AS to another, i.e when a route traverses an AS border, a border BGProuter modifies the attribute by adding the AS number of the traversed AS An appended AS numberappears first in the AS_PATH information as illustrated in the following topology

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 Toavoid routing loops, BGP routers do not accept advertisements that contain a local AS number asillustrated inFig 5 Thus the attribute is used for routing loop detection and prevention Routingpolicy is another application of the AS_PATH attribute in BGP

3.3.3 NEXT HOP Attribute

NEXT_HOPis a well-known mandatory attribute, which carries information on how to reach theadvertised network in the form of an IP address of the next router towards the destination

By default, the 8600 system follows standard conventions ([RFC4271] for basic rules, [RFC2796]for route reflection, [RFC3065] for confederations) on setting the NEXT_HOP attribute Asomewhat inaccurate assumption is that the NEXT_HOP is changed usually when advertising toeBGP neighbors, while advertisements to iBGP neighbors do not change the attribute For VPNv4Subsequent Address Family Identifier (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 providedbelow in order of preference If multiple options are set, then the ones listed first take precedence:

1 Set statement in route-map ("set ip next-hop A.B.C.D")

2 Unchanged next-hop configuration ("router bgp x / address-family / neighbor

X.X.X.X transparent-next-hop")

3 Next-hop-area configuration ("router bgp x / address-family / neighbor X.X.X.X

• When no next-hop-area is configured to a source or destination peer, the NEXT_HOP cessing is per regular rules

pro-• If both source and destination have next-hop-area configured, then:

1 If it is the same area, this is taken as a request to keep the NEXT_HOP unchanged Thisoverrides the iBGP eBGP/eBGP  iBGP rules and the "next-hop-self" directive,

A typical user case of the next-hop-area attribute is to allow direct data transfer betweenmultiple eBGP neighbors within a specific access network or ring This is particularly useful whenusing N-PE with inter-AS option D [draft-kulmala-l3vpn-interas-option]

LOCAL_PREFERENCEis a well-known discretionary attribute that is exchanged only within thelocal AS When a route first arrives to an AS (either via eBGP or via redistributes), the ingress route(ASBR) classifies a route and sets the LOCAL_PREFERENCE to it, which is then advertised to thelocal 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 areindependent and may use different routing policies

The LOCAL_PREFERENCE attribute indicates the priority of a BGP router and it is used toinfluence BGP path selection and determines the best path for traffic exiting the local AS If aBGP 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 routerswithin an AS receive the LOCAL_PREFERENCE attribute along with the route, a consistent routing

Fig 6 Local Preference Attribute

Fig 6illustrates an example of the best path selection using the LOCAL_PREFERENCE attribute InAS65200, theLOCAL_PREFERENCE attributes are set on border routers R20 (to 200) and R40 (to400), which are then advertised to iBGP peer R30 Since R40 has a higher LOCAL_PREFERENCEset to 400, it will be selected as the best path to exit the AS65200 for any traffic destined to AS65100.After a selection has been made based on the LOCAL_PREFERENCE, R20 may no longer advertiseit's low preference value Instead will just forward route information through the selected best path

ATOMIC_AGGREGATEis 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 theattribute when advertising it to the neighbors A BGP router receiving a route with this attributeattached does not detach the attribute when propagating it to other BGP peers Moreover, thereceived aggregated prefix should not be de-aggregated either Thus, the ATOMIC_AGGREGATEattribute signals to the receiver that path information that was present in the original routing updatesmay have been lost when the updates where aggregated into a single entry Route aggregation isdescribed in3.6 Route Aggregation

3.3.6 COMMUNITY Attribute

COMMUNITYis an optional, transitive attribute of variable length that facilitates the transfer of localpolicies through different autonomous systems A COMMUNITY attribute can be assigned to aspecific prefix, or to a group If assigned to a group, it gives an identity of the group that sharessome common properties By specifying a COMMUNITY attribute, the network administrator can forexample limit local routes to propagate only within a certain region and advertise the aggregateprefix outside the region

COMMUNITYattributes are of two types:

8600 system supports the following attribute values:

• NONE – removes the communities attribute from the prefixes that pass the route-map.

• LOCAL_AS – specifies routes that are not to be advertised outside of the local AS boundary

• NO_ADVERTISE – specifies routes that are not to be advertised to other BGP peers

• NO_EXPORT – specifies routes that must not to be advertised outside a BGP confederation or ASboundaries

There is a wide range of other communities that are not predefined and are meant for private use,

typically these are set via route-map (please refer to3.5.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 communitiesattribute can be used to specify the destination group with further details E.g MPLS VPN routinginformation is distributed by using a route target extended communities attribute

The 8600 system supports the following attribute values:

• RT (Route Target)

• SOO (Site of Origin )

In the 8600 system, the user can arbitrary encode the extended communities attribute to implementthe desired BGP routing policy

AGGREGATORis an optional transitive attribute that conveys the IP address of a BGP routergenerating the aggregate route When a BGP router aggregates some routes it has learned from peers