Unicast Guide
Unicast Guide
Unicast Guide
© 2022 Nokia.
Use subject to Terms available at: www.nokia.com/terms/.
Nokia is committed to diversity and inclusion. We are continuously reviewing our customer
documentation and consulting with standards bodies to ensure that terminology is inclusive and
aligned with the industry. Our future customer documentation will be updated accordingly.
This document includes Nokia proprietary and confidential information, which may not be distributed
or disclosed to any third parties without the prior written consent of Nokia.
This document is intended for use by Nokia’s customers (“You”/”Your”) in connection with a product
purchased or licensed from any company within Nokia Group of Companies. Use this document
as agreed. You agree to notify Nokia of any errors you may find in this document; however, should
you elect to use this document for any purpose(s) for which it is not intended, You understand and
warrant that any determinations You may make or actions You may take will be based upon Your
independent judgment and analysis of the content of this document.
Nokia reserves the right to make changes to this document without notice. At all times, the
controlling version is the one available on Nokia’s site.
Copyright and trademark: Nokia is a registered trademark of Nokia Corporation. Other product
names mentioned in this document may be trademarks of their respective owners.
© 2022 Nokia.
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
Table of contents
1 Getting started......................................................................................................................................... 14
1.1 About this guide................................................................................................................................ 14
1.2 Router configuration process............................................................................................................15
1.3 Conventions.......................................................................................................................................15
1.3.1 Precautionary and information messages................................................................................ 16
1.3.2 Options or substeps in procedures and sequential workflows................................................. 16
2 RIP............................................................................................................................................................. 17
2.1 RIP overview..................................................................................................................................... 17
2.1.1 RIP features..............................................................................................................................17
2.1.1.1 RIP version types.............................................................................................................18
2.1.1.2 RIPv2 authentication........................................................................................................ 18
2.1.1.3 RIP packet format............................................................................................................ 18
2.1.1.4 BFD monitoring of RIP neighbor liveliness...................................................................... 20
2.2 RIPng.................................................................................................................................................20
2.2.1 RIPng protocol.......................................................................................................................... 20
2.3 Common attributes............................................................................................................................21
2.3.1 Metrics.......................................................................................................................................21
2.3.2 Timers....................................................................................................................................... 21
2.3.3 Import and export policies........................................................................................................ 22
2.3.4 Hierarchical levels.....................................................................................................................22
2.4 RIP configuration process overview................................................................................................. 22
2.5 Configuration notes........................................................................................................................... 22
2.5.1 General..................................................................................................................................... 22
2.6 Configuring RIP with CLI.................................................................................................................. 23
2.6.1 RIP and RIPng configuration overview.................................................................................... 23
2.6.1.1 Preconfiguration requirements......................................................................................... 23
2.6.1.2 RIP hierarchy....................................................................................................................23
2.6.2 Basic RIP configuration............................................................................................................ 23
2.6.3 Common configuration tasks.................................................................................................... 24
2.6.3.1 Configuring interfaces...................................................................................................... 24
2.6.3.2 Configuring a route policy................................................................................................ 25
2.6.3.3 Configuring RIP parameters.............................................................................................26
2.6.3.4 Configuring global-level parameters................................................................................ 27
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
3 OSPF......................................................................................................................................................... 33
3.1 Configuring OSPF............................................................................................................................. 33
3.1.1 OSPF areas.............................................................................................................................. 33
3.1.1.1 Backbone area................................................................................................................. 34
3.1.1.2 Stub area..........................................................................................................................35
3.1.1.3 Not-so-stubby area...........................................................................................................35
3.1.2 OSPFv3 authentication.............................................................................................................38
3.1.3 OSPF graceful restart helper................................................................................................... 38
3.1.3.1 BFD interaction with graceful restart............................................................................... 39
3.1.3.2 OSPFv3 graceful restart helper....................................................................................... 39
3.1.4 Virtual links............................................................................................................................... 40
3.1.5 Neighbors and adjacencies...................................................................................................... 40
3.1.5.1 Broadcast and point-to-point networks............................................................................ 40
3.1.5.2 Non-broadcast multi-access networks............................................................................. 41
3.1.6 Link-state advertisements.........................................................................................................41
3.1.7 Metrics.......................................................................................................................................42
3.1.8 Authentication........................................................................................................................... 42
3.1.9 IP subnets.................................................................................................................................42
3.1.10 Preconfiguration recommendations........................................................................................ 42
3.1.11 Multiple OSPF instances........................................................................................................ 43
3.1.11.1 Route export policies for OSPF..................................................................................... 43
3.1.11.2 Preventing route redistribution loops..............................................................................43
3.1.12 Multi-address support for OSPFv3......................................................................................... 44
3.1.13 IP fast-reroute for OSPF and IS-IS prefixes.......................................................................... 44
3.1.13.1 IP FRR configuration......................................................................................................44
3.1.13.2 ECMP considerations.....................................................................................................45
3.1.13.3 IP FRR and RSVP shortcut........................................................................................... 45
3.1.13.4 IP FRR and BGP next hop resolution........................................................................... 46
3.1.13.5 OSPF and IS-IS support for loop-free alternate calculation...........................................46
3.1.13.6 Multi-homed prefix LFA extensions in OSPF................................................................. 50
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
4 IS-IS........................................................................................................................................................... 86
4.1 Configuring IS-IS...............................................................................................................................86
4.1.1 Routing......................................................................................................................................86
4.1.2 IS-IS frequently used terms......................................................................................................87
4.1.3 ISO network addressing........................................................................................................... 88
4.1.3.1 IS-IS PDU configuration................................................................................................... 89
4.1.3.2 IS-IS operations................................................................................................................90
4.1.4 IS-IS route summarization........................................................................................................ 90
4.1.4.1 Partial SPF calculation.....................................................................................................90
4.1.5 IS-IS multi-topology support..................................................................................................... 91
4.1.5.1 Native IPv6 support..........................................................................................................91
4.1.6 IS-IS administrative tags.......................................................................................................... 91
4.1.6.1 Setting route tags.............................................................................................................91
4.1.6.2 Using route tags...............................................................................................................92
4.1.6.3 Unnumbered interface support.........................................................................................92
4.2 FIB prioritization................................................................................................................................ 92
4.3 IS-IS graceful restart helper..............................................................................................................93
4.3.1 BFD interaction with graceful restart........................................................................................93
4.4 IS-IS configuration process overview............................................................................................... 93
4.5 Configuration notes........................................................................................................................... 93
4.5.1 General..................................................................................................................................... 94
4.6 Configuring IS-IS with CLI................................................................................................................ 94
4.6.1 IS-IS configuration overview.....................................................................................................94
4.6.1.1 Router levels.................................................................................................................... 94
4.6.1.2 Configuring area address attributes.................................................................................94
4.6.1.3 Interface level capacity.................................................................................................... 95
4.6.1.4 Route leaking................................................................................................................... 95
4.6.2 Basic IS-IS configuration.......................................................................................................... 96
4.6.3 Common configuration tasks.................................................................................................... 98
4.6.4 Configuring IS-IS components..................................................................................................98
4.6.4.1 Enabling IS-IS.................................................................................................................. 99
4.6.4.2 Modifying router-level parameters....................................................................................99
4.6.4.3 Configuring ISO area addresses................................................................................... 100
4.6.4.4 Configuring global IS-IS parameters..............................................................................100
4.6.4.5 Migration to IS-IS multi-topology....................................................................................101
4.6.4.6 Configuring interface parameters...................................................................................104
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
5 BGP......................................................................................................................................................... 115
5.1 BGP overview................................................................................................................................. 115
5.2 BGP sessions..................................................................................................................................115
5.2.1 BGP session states................................................................................................................ 117
5.2.2 Detecting BGP session failures..............................................................................................117
5.2.2.1 Peer tracking.................................................................................................................. 118
5.2.2.2 Bidirectional forwarding detection.................................................................................. 118
5.2.2.3 Fast external failover......................................................................................................118
5.2.3 High availability BGP sessions...............................................................................................118
5.2.3.1 BGP graceful restart...................................................................................................... 119
5.2.3.2 BGP long-lived graceful restart...................................................................................... 120
5.2.4 BGP session security............................................................................................................. 121
5.2.4.1 TCP MD5 authentication................................................................................................ 121
5.2.4.2 TTL security mechanism................................................................................................ 122
5.2.5 BGP address family support for different session types........................................................ 122
5.2.6 BGP groups............................................................................................................................ 123
5.3 BGP design concepts..................................................................................................................... 123
5.3.1 Route reflection.......................................................................................................................124
5.3.2 BGP confederations................................................................................................................126
5.4 BGP messages............................................................................................................................... 126
5.4.1 Open message....................................................................................................................... 127
5.4.1.1 Changing the autonomous system number................................................................... 128
5.4.1.2 Changing a confederation number.................................................................................128
5.4.1.3 BGP advertisement........................................................................................................ 128
5.4.2 Update message.....................................................................................................................128
5.4.3 Keepalive message................................................................................................................ 129
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
5.11.1 General..................................................................................................................................198
5.11.1.1 BGP defaults................................................................................................................ 198
5.11.1.2 BGP MIB notes............................................................................................................ 199
5.12 Configuring BGP with CLI.............................................................................................................200
5.12.1 Configuration overview......................................................................................................... 200
5.12.1.1 Preconfiguration requirements..................................................................................... 200
5.12.1.2 BGP hierarchy.............................................................................................................. 200
5.12.1.3 Internal and external BGP configuration......................................................................200
5.12.1.4 Default external BGP route propagation behavior without policies.............................. 201
5.12.2 Basic BGP configuration...................................................................................................... 202
5.12.3 Common configuration tasks................................................................................................ 203
5.12.3.1 Creating an autonomous system................................................................................. 204
5.12.3.2 Configuring a router ID................................................................................................ 205
5.12.3.3 BGP confederations..................................................................................................... 206
5.12.3.4 BGP router reflectors................................................................................................... 208
5.12.3.5 BGP components......................................................................................................... 210
5.13 BGP configuration management tasks......................................................................................... 214
5.13.1 Modifying an AS number......................................................................................................214
5.13.2 Modifying a confederation number....................................................................................... 215
5.13.3 Modifying the BGP router ID................................................................................................ 215
5.13.4 Modifying the router-level router ID......................................................................................216
5.13.5 Deleting a neighbor.............................................................................................................. 216
5.13.6 Deleting groups.....................................................................................................................217
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
7.5 Broadband Network Gateway (BNG) Control and User Plane Separation (CUPS)........................253
7.6 Certificate management.................................................................................................................. 253
7.7 Circuit emulation............................................................................................................................. 254
7.8 Ethernet........................................................................................................................................... 254
7.9 Ethernet VPN (EVPN).....................................................................................................................254
7.10 gRPC Remote Procedure Calls (gRPC).......................................................................................255
7.11 Intermediate System to Intermediate System (IS-IS)................................................................... 255
7.12 Internet Protocol (IP) Fast Reroute (FRR)................................................................................... 256
7.13 Internet Protocol (IP) general....................................................................................................... 257
7.14 Internet Protocol (IP) multicast..................................................................................................... 258
7.15 Internet Protocol (IP) version 4.................................................................................................... 259
7.16 Internet Protocol (IP) version 6.................................................................................................... 260
7.17 Internet Protocol Security (IPsec).................................................................................................261
7.18 Label Distribution Protocol (LDP)................................................................................................. 262
7.19 Layer Two Tunneling Protocol (L2TP) Network Server (LNS)......................................................263
7.20 Multiprotocol Label Switching (MPLS).......................................................................................... 263
7.21 Multiprotocol Label Switching - Transport Profile (MPLS-TP)...................................................... 264
7.22 Network Address Translation (NAT)............................................................................................. 264
7.23 Network Configuration Protocol (NETCONF)............................................................................... 264
7.24 Open Shortest Path First (OSPF).................................................................................................265
7.25 OpenFlow...................................................................................................................................... 266
7.26 Path Computation Element Protocol (PCEP)............................................................................... 266
7.27 Point-to-Point Protocol (PPP)....................................................................................................... 266
7.28 Policy management and credit control......................................................................................... 267
7.29 Pseudowire (PW).......................................................................................................................... 267
7.30 Quality of Service (QoS)...............................................................................................................268
7.31 Remote Authentication Dial In User Service (RADIUS)............................................................... 268
7.32 Resource Reservation Protocol - Traffic Engineering (RSVP-TE)................................................268
7.33 Routing Information Protocol (RIP)...............................................................................................269
7.34 Segment Routing (SR)..................................................................................................................269
7.35 Simple Network Management Protocol (SNMP).......................................................................... 270
7.36 Timing............................................................................................................................................ 272
7.37 Two-Way Active Measurement Protocol (TWAMP)...................................................................... 273
7.38 Virtual Private LAN Service (VPLS)............................................................................................. 273
7.39 Voice and video............................................................................................................................ 273
7.40 Wireless Local Area Network (WLAN) gateway........................................................................... 274
7.41 Yet Another Next Generation (YANG).......................................................................................... 274
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Table of contents
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Getting started
22.2.R1
1 Getting started
Note: Unless otherwise indicated, this guide uses classic CLI command syntax and configuration
examples.
For a list of unsupported features by platform and chassis, see the SR OS R22.x.Rx Software Release
Notes, part number 3HE 18412 000 x TQZZA.
Command outputs shown in this guide are examples only; actual displays may differ depending on
supported functionality and user configuration.
Note: The SR OS CLI trees and command descriptions can be found in the following guides:
• 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide
• 7450 ESS, 7750 SR, 7950 XRS, and VSR Clear, Monitor, Show, and Tools Command
Reference Guide (for both MD-CLI and Classic CLI)
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Getting started
22.2.R1
• 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide
Note: Content previously found in this guide related to Segment Routing and PCE has been
moved to the 7750 SR and 7950 XRS Segment Routing and PCE User Guide .
Note: This guide generically covers Release 22.x.Rx content and may contain some content that
will be released in later maintenance loads. See the SR OS R22.x.Rx Software Release Notes,
part number 3HE 18412 000 x TQZZA, for information about features supported in each load of
the Release 22.x.Rx software.
OSPF configuration Configure an LFA SPF policy Loop-free alternate shortest path first
policies
Route Policies Configure route policies Configuring route policies with CLI
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Getting started
22.2.R1
1.3 Conventions
This section describes the general conventions used in this guide.
DANGER: Danger warns that the described activity or situation may result in serious personal
injury or death. An electric shock hazard could exist. Before you begin work on this equipment,
be aware of hazards involving electrical circuitry, be familiar with networking environments, and
implement accident prevention procedures.
WARNING: Warning indicates that the described activity or situation may, or will, cause
equipment damage, serious performance problems, or loss of data.
Caution: Caution indicates that the described activity or situation may reduce your component or
system performance.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
2 RIP
This chapter provides information about configuring the Routing Information Protocol (RIP).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
updates can be either sent to a broadcast or multicast address (224.0.0.9). RIPv2 supports subnet masks,
a feature that was not available in RIPv1.
A network address of 0.0.0.0 is considered a default route. A default route is used when it is not convenient
to list every possible network in the RIP updates, and when one or more closely-connected gateways in the
system are prepared to handle traffic to the networks that are not listed explicitly. These gateways create
RIP entries for the address 0.0.0.0, as if it were a network to which they are connected.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
• Must be zero
Not used in RIPv1. This field provides backward compatibility with pre-standard varieties of RIP. The
default value is zero.
• Address family identifier (AFI)
This field indicates the type of address. RIP can carry routing information for several different protocols.
Each entry in this field has an AFI to indicate the type of address being specified. The IP AFI is 2.
• Address
This field indicates the IP address for the packet.
• Metric
This field specifies the number of hops to the destination.
• Mask
This field specifies the IP address mask.
• Next hop
This field specifies the IP address of the next router along the path to the destination.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
2.2 RIPng
RIPng is the IPv6 form of the interior gateway protocol (IGP) Routing Information Protocol (RIP), originally
implemented for IPv4 routing. This protocol is a distance vector routing protocol that periodically advertises
IPv6 routing information to neighbors, typically through the use of UDP based multicast updates carrying a
list of one or more entries, each containing an IPv6 prefix, prefix length, route metric and a possible route
tag.
RIPng is supported in the base routing context and also as a PE-CE routing protocol within a VPRN
context.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
• Destination IP address
The destination IP for any periodic or triggered update should be sent to the multicast group FF02::9,
(all-rip-routers multicast group). When sending responses to an RIPng request, the RIPng response is
sent to the unicast IP address of the requester.
Each route entry in an update message contains the following:
• IPv6 prefix
• prefix length
• route metric
• route tag (optional)
2.3.1 Metrics
By default, RIP advertises all RIP routes to each peer every 30 seconds. RIP uses a hop count metric to
determine the distance between the packet’s source and destination. The metric/cost values for a valid
route is 1 through 15. A metric value of 16 (infinity) indicates that the route is no longer valid and should be
removed from the router’s routing table.
Each router along the path increments the hop count value by 1. When a router receives a routing update
with new or different destination information, the metric increments by one.
The maximum number of hops in a path is 15. If a router receives a routing update with a metric of 15 and
contains a new or modified entry, increasing the metric value by one will cause the metric increment to 16
(infinity). Then, the destination is considered unreachable.
The router implementation of RIP uses split horizon with poison reverse to protect from such problems as
‟counting to infinity”. Split horizon with poison reverse means that routes learned from a neighbor through a
specified interface are advertised in updates out of the same interface but with a metric of 16 (infinity).
2.3.2 Timers
RIP uses the following timers to determine the frequency of RIP updates and the duration that routes are
maintained.
• update
Times the interval between periodic routing updates.
• timeout
This timer is initialized when a route is established and any time an update message is received for the
route. When this timer expires, the route is no longer valid. It is retained in the table for a short time, so
that neighbors can be notified that the route has been dropped.
• flush
When the flush timer expires, the route is removed from the tables.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
2.5.1 General
Before RIP neighbor parameters can be configured, router interfaces must be configured.
RIP must be explicitly created for each router interface. There are no default RIP instances on a router.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
Within these levels, the RIP configuration commands are identical. For repeated commands, the
value most specific to the neighboring router is used. Therefore, a RIP group-specific command takes
precedence over a global RIP command. A neighbor-specific configuration statement takes precedence
over a global RIP and group-specific command. For example, if the user modifies a RIP neighbor-level
command default, the new value takes precedence over group- and global-level settings.
At a minimum, the group- and neighbor-level RIP parameters must be configured in the config>router rip
context.
The following example displays a basic RIP configuration:
ALA-A>config>router>rip# info
----------------------------------------------
group "RIP-ALA-A"
neighbor "to-ALA-4"
exit
exit
----------------------------------------------
ALA-A>config>router>rip#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
CLI syntax
config router
interface ip-int-name
address ip-addr{/mask-length | mask} [broadcast
{all-ones | host-ones}]
port port-id
The following example displays the IP configuration output showing the interface information.
ALA-3>config>router# info
#------------------------------------------
echo "IP Configuration "
#------------------------------------------
interface "system"
address 10.10.10.103/32
exit
interface "to-ALA-4"
address 10.10.12.1/24
port 1/1/1
exit
#------------------------------------------
ALA-3>config>router#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
CLI syntax
config>router>policy-options
begin
commit
abort
policy-statement name
description text
default-action {accept|next-entry|nextpolicy|drop|reject}
entry entry-id
description text
action {accept|next-entry|nextpolicy|drop|reject}
from
to
config>router>policy-options
begin
The following example displays some commands to configure a policy statement. Policy option commands
are configured in the config>router context. Use the commit command to save the changes.
Example
config>router>policy-options# begin
policy-options# policy-statement “RIP policy”
policy-options>policy-statement$ description "this is a test RIP policy”
policy-options>policy-statement>default# entry 1
policy-options>policy-statement>entry$ action accept
policy-options>policy-statement>entry# exit
policy-options>policy-statement# default-action reject
policy-options>policy-statement# exit
policy-options# commit
ALA-A>config>router>policy-options# info
----------------------------------------------
policy-statement "RIP-policy"
description "this is a test RIP policy"
entry 1
action accept
exit
exit
default-action reject
exit
----------------------------------------------
ALA-A>config>router>policy-options>policy-statement#
config>router
rip
authentication-key [authentication-key | hash-key [hash|hash2|custom]
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
group group-name
authentication-key [authentication-key | hash-key [hash | hash2| custom]
authentication-type {none | password | message-digest | message-digest-20}
check-zero {enable | disable}
description string
export policy-name [policy-name ...up to 5 max]]
import policy-name [policy-name ...up to 5 max]]
message-size number
metric-in metric
metric-out metric
preference number
receive {both | none | version-1 | version-2}
send {broadcast | multicast | none | version-1}
no shutdown
split-horizon {enable | disable}
timers update timeout flush
neighbor ip-int-name
authentication-key [authentication-key | hash-key [hash | hash2| custom]
authentication-type {none | password | message-digest | message-digest-20}
check-zero {enable | disable}
description string
export policy-name [policy-name ...up to 5 max]]
import policy-name [policy-name ...up to 5 max]]
message-size number
metric-in metric
metric-out metric
preference number
receive {both | none | version-1 | version-2}
send {broadcast | multicast | none | version-1}
split-horizon {enable | disable}
timers update timeout flush
no shutdown
Note: Careful planning is essential to implement commands that can affect the behavior of global,
group, and neighbor levels. Because the RIP commands are hierarchical, analyze the values that
can disable features on a specific level.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
CLI syntax
config>router
rip
authentication-key [authentication-key | hash-key [hash | hash2| custom]
authentication-type {password | message-digest}
check-zero {enable | disable}
export policy-name [policy-name ...up to 5 max]
import policy-name [policy-name ...up to 5 max]
message-size number
metric-in metric
metric-out metric
preference number
receive {both | none | version-1 | version-2}
send {broadcast | multicast | none | version-1 | both}
no shutdown
split-horizon {enable | disable}
timers update timeout flush
config>router# rip
config>router>rip# authentication-type password
config>router>rip# authentication-key test123
config>router>rip# receive both
config>router>rip# split-horizon enable
config>router>rip# timers 300 600 600
config>router>rip>group# exit
ALA-A>config>router>rip# info
----------------------------------------------
authentication-type simple
authentication-key "ac1865lvz1d" hash
timers 300 600 600
----------------------------------------------
ALA-A>config>router>rip#
config>router# rip
group group-name
authentication-key[authentication-key|hash-key [hash|hash2|custom]
authentication-type {password|message-digest}
check-zero {enable|disable}
description string
export policy-name [policy-name …]
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
config>router# rip
config>router>rip# group headquarters
config>router>rip>group$ description "Mt. View"
config>router>rip>group# no shutdown
ALA-A>config>router>rip# info
----------------------------------------------
authentication-type simple
authentication-key "ac1865lvz1d" hash
timers 300 600 600
group "headquarters"
description "Mt. View"
exit
----------------------------------------------
ALA-A>config>router>rip#
config>router# rip
group group-name
neighbor ip-int-name
authentication-key [authentication-key|hash-key [hash|hash2|custom]
authentication-type {password|message-digest}
check-zero {enable|disable}
description string
export policy-name [policy-name …]
import policy-name [policy-name …]
message-size number
metric-in metric
metric-out metric
preference number
receive {both|none|version-1|version-2}
send {broadcast|multicast|none|version-1}
split-horizon {enable|disable}
timers update timeout flush
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
no shutdown
config>router# rip
config>router>rip# group headquarters1
config>router>rip>group# neighbor ferguson-274
config>router>rip>group>neighbor$ preference 255
config>router>rip>group>neighbor# send both
config>router>rip>group>neighbor# split-horizon enable
config>router>rip>group>neighbor# message-size 255
ALA-A>config>router>rip>group>neighbor# info
----------------------------------------------
message-size 255
preference 255
split-horizon enable
no timers
----------------------------------------------
ALA-A>config>router>rip>group>neighbor#
config>router# rip
group group-name
...
neighbor ip-int-name
...
Example
ALA-A>config>router>rip# info
----------------------------------------------
authentication-type simple
authentication-key "ac1865lvz1d" hash
timers 300 600 600
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
group "headquarters"
description "Mt. View"
neighbor "ferguson-274"
import "RIPpolicy"
message-size 150
preference 255
split-horizon enable
no timers
exit
exit
----------------------------------------------
ALA-A>config>router>rip#
config>router# rip
[no] group group-name
shutdown
config>router# rip
config>router>rip# group "RIP-ALA-3"
config>router>rip>group# shutdown
config>router>rip>group# exit
config>router>rip# no group "RIP-ALA-33"
Deleting the group without first shutting it down displays the following message.
INFO: RIP #1204 group should be administratively down - virtual router index 1,group
RIP-ALA-4
config>router# rip
[no] group group-name
[no] neighbor ip-int-name
shutdown
Example
config>router# rip
config>router>rip# group "RIP-ALA-4"
config>router>rip>group# neighbor "to-ALA-3"
config>router>rip>group>neighbor# shutdown
config>router>rip>group>neighbor# exit
config>router>rip>group# no neighbor "to-ALA-3"
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE RIP
22.2.R1
Deleting the neighbor without first shutting it down causes the following message to appear:
INFO: RIP #1101 neighbor should be administratively down - virtual router index
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
3 OSPF
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
In Figure 6: PEs connected to an MPLS-VPN super backbone, the PEs are connected to the MPLS-VPN
super backbone. To be able to distinguish if two OSPF instances are in fact the same and require Type
3 LSAs to be generated, or are two separate routing instances where type 5 external LSAs need to be
generated, the concept of a domain-id is introduced.
The domain ID is carried with the MP-BGP update and indicates the source OSPF Domain. When the
routes are being redistributed into the same OSPF Domain, the concepts of super backbone described
above apply and Type 3 LSAs are generated. If the OSPF domain does not match, then the route type is
external.
Configuring the super backbone (not the sham links) makes all destinations learned by PEs with matching
domain IDs inter-area routes.
When configuring sham links, these links become intra-area routes if they are present in the same area.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
In Figure 7: Sham links, the red link between CE-3 and CE-4 could be a low speed OC-3/STM-1 link, but
because it establishes an intra-area route connection between the CE-3 and CE-4, the potentially high-
speed PE-1 to PE-2 connection is not used. Even with a super backbone configuration, it is regarded as an
inter-area connection.
The establishment of the (green) sham-link is also constructed as an intra-area link between PE routers, a
normal OSPF adjacency is formed and the link-state database is exchanged across the MPLS-VPRN. As a
result, the needed intra-area connectivity is created, at this time the cost of the green and red links can be
managed such that the red link becomes a standby link only in case the VPN fails.
As the sham-link forms an adjacency over the MPLS-VPRN backbone network, be aware that when
protocol-protection is enabled in the config>sys>security>cpu-protection>protocol-protection context,
the operator must explicit allow the OSPF packets to be received over the backbone network. This
performed using the allow-sham-links parameter of the protocol-protection command.
3.1.1.3.5 DN-BIT
When a Type 3 LSA is sent from a PE router to a CE router, the DN bit in the LSA options field is set.
This is used to ensure that if any CE router sends this Type 3 LSA to a PE router, the PE router does not
redistribute it further.
When a PE router needs to distribute to a CE router a route that comes from a site outside the latter's
OSPF domain, the PE router presents itself as an ASBR (Autonomous System Border Router), and
distributes the route in a type 5 LSA. The DN bit must be set in these LSAs to ensure that they are ignored
by any other PE routers that receive them.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|0| 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
+- TLVs -+
| ... |
For more information, see section 2.2 of RFC 5187, OSPFv3 Graceful Restart.
The Link State ID of a grace-LSA in OSPFv3 is the Interface ID of the interface originating the LSA.
The format of each TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
Grace-LSA TLVs are formatted according to section 2.3.2 of RFC 3630, Traffic Engineering (TE)
Extensions to OSPF Version 2. The Grace-LSA TLVs are used to carry the Grace period (type 1) and the
reason the router initiated the graceful restart process (type 2).
Other information in RFC 5187 is directed to routers that require the full graceful restart mechanism as they
do not support a stateful transition from primary or backup control plane module (CPM).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
The routers attempt to form adjacencies. An adjacency is a relationship formed between a router and the
designated or backup designated router. For point-to-point networks, no designated or backup designated
router is elected. An adjacency must be formed with the neighbor.
To significantly improve adjacency forming and network convergence, a network should be configured
as point-to-point if only two routers are connected, even if the network is a broadcast medium such as
Ethernet.
When the link-state databases of two neighbors are synchronized, the routers are considered to be fully
adjacent. When adjacencies are established, pairs of adjacent routers synchronize their topological
databases. Not every neighboring router forms an adjacency. Routing protocol updates are only sent to
and received from adjacencies. Routers that do not become fully adjacent remain in the two-way neighbor
state.
Note:
• OSPFv3 sends Hello traffic to IPv6 link-local addresses and neighbors must be statically
configured using their IPv6 link-local address.
• OSPF NBMA is supported on Ethernet ports only.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
OSPF sends only the part that has changed and only when a change has taken place. From the
topological database, each router constructs a tree of shortest paths with itself as root. OSPF distributes
routing information between routers belonging to a single AS.
3.1.7 Metrics
In OSPF, all interfaces have a cost value or routing metric used in the OSPF link-state calculation. A
metric value is configured based on hop count, bandwidth, or other parameters, to compare different paths
through an AS. OSPF uses cost values to determine the best path to a particular destination: the lower the
cost value, the more likely the interface will be used to forward data traffic.
Costs are also associated with externally derived routing data, such as those routes learned from the
Exterior Gateway Protocol (EGP), like BGP, and is passed transparently throughout the AS. This data
is kept separate from the OSPF protocol's link state data. Each external route can be tagged by the
advertising router, enabling the passing of detailed information between routers on the boundaries of the
AS.
3.1.8 Authentication
All OSPF protocol exchanges can be authenticated. This means that only trusted routers can participate
in autonomous system routing. Nokia’s implementation of OSPF supports plain text and Message Digest 5
(MD5) authentication (also called simple password).
MD5 allows an authentication key to be configured per network. Routers in the same routing domain must
be configured with the same key. When the MD5 hashing algorithm is used for authentication, MD5 is used
to verify data integrity by creating a 128-bit message digest from the data input. It is unique to that data.
Nokia’s implementation of MD5 allows the migration of an MD5 key by using a key ID for each unique key.
By default, authentication is not enabled on an interface.
3.1.9 IP subnets
OSPF enables the flexible configuration of IP subnets. Each distributed OSPF route has a destination and
mask. A network mask is a 32-bit number that indicates the range of IP addresses residing on a single
IP network/subnet. This specification displays network masks as hexadecimal numbers; for example,
the network mask for a class C IP network is displayed as 0xffffff00. Such a mask is often displayed as
255.255.255.0.
Two different subnets with same IP network number have different masks, called variable length subnets.
A packet is routed to the longest or most specific match. Host routes are considered to be subnets whose
masks are all ones (0xffffffff).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
• Define the system interface in the config>router>interface ip-int-name context (used if the router ID is
not specified in the config>router router-id context).
A system interface must have an IP address with a 32-bit subnet mask. The system interface is used as
the router identifier by higher-level protocols such as OSPF and IS-IS. The system interface is assigned
during the primary router configuration process when the interface is created in the logical IP interface
context.
• If you do not specify a router ID, then the last four bytes of the MAC address are used.
Note: On the BGP protocol level, a BGP router ID can be defined in the config>router>bgp
router-id context and is only used within BGP.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
redistributed from one domain to another, more bits are set in the tag mask, each corresponding to the
OSPF domain the route visited. Route redistribution looping is prevented by checking the corresponding
bit as part of the export policy. If the bit corresponding to the announcing OSPF process is already set,
the route is not exported there.
From the CLI perspective, this involves adding a set of from tag and action tag commands that allow
for bit operations.
config
router
ospf3 64 10.20.1.3
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
CLI syntax
config>router>isis>loopfree-alternates
config>router>ospf>loopfree-alternates
config>service>vprn>ospf>loopfree-alternates
The above commands instruct the IGP SPF to attempt to pre-compute both a primary next hop and an LFA
next hop for every learned prefix. When found, the LFA next hop is populated into the RTM along with the
primary next hop for the prefix.
Next the user enables IP FRR to cause RTM to download to the IOM or the forwarding engine a LFA next
hop, when found by SPF, in addition to the primary next hop for each prefix in the FIB.
CLI syntax
config>router>ip-fast-reroute
config>router>isis>level>loopfree-alternate-exclude
config>router>ospf>area>loopfree-alternate-exclude
The user can also exclude a specific IP interface from being included in the LFA SPF computation by IS-IS
or OSPF.
CLI syntax
config>router>isis>if>loopfree-alternate-exclude
config>router>ospf>area>if>loopfree-alternate-exclude
When an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2. When
the user excludes an interface from the LFA SPF in OSPF, it is excluded in all areas. However, the above
OSPF command can only be executed under the area in which the specified interface is primary and
enabled, the interface is excluded in that area and in all other areas where the interface is secondary. If the
user attempts to apply it to an area where the interface is secondary the command fails.
Finally, the user can apply the same above commands for an OSPF instance within a VPRN service.
CLI syntax
config>service>vprn>ospf>area>loopfree-alternate-exclude
config>service>vprn>ospf>area>if>loopfree-alternate-exclude
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
The primary route is via R3. The LFA route via R2 has two equal cost paths to reach R5. The path by way
of R3 protects against failure of link R1-R3. This route is computed by R1 by checking that the cost for R2
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
to reach R5 by way of R3 is lower than the cost by way of routes R1 and R3. This condition is referred to
as the 'loop-free criterion'.
The path by way of R2 and R4 can be used to protect against the failure of router R3. However, with
the link R2-R3 metric set to 5, R2 sees the same cost to forward a packet to R5 by way of R3 and R4.
Consequently, R1 cannot guarantee that enabling the LFA next hop R2 will protect against R3 node failure.
This means that the LFA next hop R2 provides link-protection only for prefix R5. If the metric of link R2-R3
is changed to 8, then the LFA next hop R2 provides node protection since a packet to R5 will always go
over R4.In other words it is required that R2 becomes loop-free with respect to both the source node R1
and the protected node R3.
Consider now the case where the primary next hop uses a broadcast interface as illustrated in Figure 9:
Example topology with broadcast interfaces.
In order for next hop R2 to be a link-protect LFA for route R5 from R1, it must be loop-free with respect
to the R1-R3 link Pseudo-Node (PN). However, since R2 has also a link to that PN, its cost to reach R5
by way of the PN, or router R4 are the same. Consequently, R1 cannot guarantee that enabling the LFA
next hop R2 will protect against a failure impacting link R1-PN since this may cause the entire subnet
represented by the PN to go down. If the metric of link R2-PN is changed to 8, then R2 next hop will be an
LFA providing link protection.
The following are the detailed equations for this criterion as provided in RFC 5286, Basic Specification for
IP Fast Reroute: Loop-Free Alternates:
• Rule 1
Link-protect LFA backup next hop (primary next hop R1-R3 is a P2P interface):
Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)
Distance_opt(R2, R5) >= Distance_opt(R2, R3) + Distance_opt(R3, R5)
• Rule 2
Node-protect LFA backup next hop (primary next hop R1-R3 is a P2P interface):
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
To limit the time it takes to compute the LFA SPF, the user must explicitly enable the use of an IGP shortcut
as LFA backup next hop using one of a couple of new optional argument for the existing LSP level IGP
shortcut command:
config>router>mpls>lsp>igp-shortcut [lfa-protect | lfa-only]
The lfa-protect option allows an LSP to be included in both the main SPF and the LFA SPFs. For a
specified prefix, the LSP can be used either as a primary next hop or as an LFA next hop but not both. If
the main SPF computation selected a tunneled primary next hop for a prefix, the LFA SPF does not select
an LFA next hop for this prefix and the protection of this prefix relies on the RSVP LSP FRR protection. If
the main SPF computation selected a direct primary next hop, the LFA SPF selects an LFA next hop for
this prefix but prefers a direct LFA next hop over a tunneled LFA next hop.
The lfa-only option allows an LSP to be included in the LFA SPFs only such that the introduction of IGP
shortcuts does not impact the main SPF decision. For a spcified prefix, the main SPF always selects a
direct primary next hop. The LFA SPF selects a an LFA next hop for this prefix but prefers a direct LFA next
hop over a tunneled LFA next hop.
With the selection algorithm when SPF finds multiple LFA next hops for a specified primary next hop is
modified as follows.
1. The algorithm splits the LFA next hops into two sets:
• The first set consists of direct LFA next hops.
• The second set consists of tunneled LFA next hops. After excluding the LSPs which use the same
outgoing interface as the primary next hop.
2. The algorithms continues with first set if not empty, otherwise it continues with second set.
3. If the second set is used, the algorithm selects the tunneled LFA next hop which endpoint corresponds
to the node advertising the prefix.
• If more than one tunneled next hop exists, it selects the one with the lowest LSP metric.
• If still more than one tunneled next hop exists, it selects the one with the lowest tunnel-id.
• If none is available, it continues with rest of the tunneled LFAs in second set.
4. Within the selected set, the algorithm splits the LFA next hops into two sets:
• The first set consists of LFA next hops which do not go over the PN used by primary next hop.
• The second set consists of LFA next hops which go over the PN used by the primary next hop.
5. If there is more than one LFA next hop in the selected set, it picks the node-protect type in favor of the
link-protect type.
6. If there is more than one LFA next hop within the selected type, it picks one based on the least total cost
for the prefix. For a tunneled next hop, it means the LSP metric plus the cost of the LSP endpoint to the
destination of the prefix.
7. If there is more than one LFA next hop within the selected type (ecmp-case) in the first set, it selects
the first direct next hop from the remaining set. This is not a deterministic selection and varies following
each SPF calculation.
8. If there is more than one LFA next hop within the selected type (ecmp-case) in the second set, it picks
the tunneled next hop with the lowest cost from the endpoint of the LSP to the destination prefix. If there
remains more than one, it picks the tunneled next hop with the lowest tunnel-id.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
configure
+--router
+--ospf <0..31>
+--loopfree-alternates
+--multi-homed-prefix
+--preference <all, none>
• MD CLI
configure
+--router
+--ospf <0..31>
+--loopfree-alternate
+--multi-homed-prefix
+--preference <all, none>
When applied to IP prefixes, IP FRR must also be enabled using the following command, which allows the
programming of the backup paths in the FIB.
• classic CLI
configure
+--router
+--ip-fast-reroute
• MD CLI
configure
+--routing-options
+--ip-fast-reroute
This feature makes use of the multi-homed prefix model described in RFC 8518 to compute a backup IP
next hop via an alternate ABR or ASBR for external prefixes and to an alternate router owner for local
anycast prefixes.
The base LFA algorithm is applied to all intra-area and external IP prefixes (IP FRR) and SR-OSPF node
SID tunnels (SR-OSPF FRR), as usual. That is, the MHP LFA is on top of it to improve the outcome for
external prefixes and anycast prefixes. For external /32 prefixes and intra-area local /32 prefixes with
multiple owner routers (anycast prefixes), the base LFA backup path, if found, is preferred over the MHP
LFA backup in the default behavior with the preference command set to a value of none. The user can
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
force the programming of the MHP LFA backup by setting the preference command value to all. The
algorithm details are described in RFC 8518 MHP LFA for OSPF.
After the IP next-hop based MHP LFA is enabled, the extensions to MHP LFA to compute an SR-TE repair
tunnel for an SR-OSPF tunnel are automatically enabled when the following CLI command is configured to
enable Topology-Independent Loop-Free Alternate (TI-LFA) or Remote Loop-Free Alternate (RLFA). The
algorithm details are described in 7750 SR and 7950 XRS Segment Routing and PCE User Guide, section
LFA solution across IGP area or instance boundary using SR repair tunnel for SR OSPF. The computation
reuses the SID list of the primary path or the TI-LFA or RLFA backup path of the alternate ABR, ASBR, or
alternate owner router.
• classic CLI
configure
+--router
+--ospf <0..31>
+--loopfree-alternates
+--remote-lfa
+--ti-lfa
• MD CLI
configure
+--router
+--ospf <0..31>
+--loopfree-alternate
+--remote-lfa
+--ti-lfa
TI-LFA, base LFA and RLFA (if enabled) are applied to the SR-OSPF tunnels of all intra-area and
external /32 prefixes as usual. For node SID SR-OSPF tunnels of external /32 prefixes or intra-area /32
anycast prefixes, the LFA, TI LFA, or RFLA backup path is preferred over the MHP LFA backup path
in the default behavior with the preference command set to a value of none. The user can force the
programming of the MHP LFA backup by setting the preference command value to all.
The MHP backup path protects SR-OSPF tunnels in both algorithm 0 and flexible-algorithm numbers. It
also extends the protection to any SR-TE LSP or SR policy that uses an SR-OSPF SID of those same
prefixes in its configured or computed SID list.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
RFC 8518 creates a specific topology for each external prefix by modeling it as a multi-homed node to
the Points of Attachment (POi nodes). POi can be an ASBR node for an external prefix or an owner router
in the case of an intra-area anycast prefix. The SR OS implementation supports prefixes redistributed by
an ABR or ASBR (OSPFv2 route types 3, 5, and 7) and also extends feature support to inter-area ASBR
(external routes resolved recursively to OSPFv2 route types 4).
In the topology shown in Figure 10: Application of MHP LFA to IP FRR, prefix P has a dotted link with a
metric of 5 to ABR or ASBR node PObest that summarizes the path in the remote OSPF area or instance
to the best ABR or ASBR. Node PObest is ABR or ASBR that lies in the shortest path from the computing
node S to the destination prefix P .
Prefix P also has a dotted line to ABR or ASBR POi that summarizes the path to an alternate ABR or
ASBR with a cost of 3. Node POi propagates prefix P to the local area or instance of computing node S
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
because its shortest path to P is in the remote area or instance, but POi does not lie in the shortest path to
P from the point of view of node S.
Node S computes and finds a MHP LFA backup path for an external prefix P using neighbor N and which
uses ABR or ASBR POi to exit the local area or instance, or which uses an alternate owner router for a
intra-area anycast prefix, if the following rules are satisfied.
• Protection of Link S-E (1)
D_opt(N,POi) + Cost(POi ,P) < D_opt(N,S) + D_opt(S,PObest) + Cost(PObest ,P)
• Protection of Link E (2)
D_opt(N,POi) + Cost(POi ,P) < D_opt(N,E) + D_opt(E,PObest) + Cost(PObest ,P)
Where, D_opt(X,Y) is the distance on the shortest path from node X to node Y and Cost (X,P) is the
external cost to reach prefix P from advertising router X.
The MHP LFA calculation applies to the backup next hop of external OSPFv2 /32 prefixes, propagated
across an area or instance boundary, and resolved in RTM when IP FRR is enabled in that OSPFv2
instance. The calculation also applies to /32 prefixes in the same area as the computing node S that are
advertised by multiple routers (anycast prefixes).
OSPFv2 runs concurrently the base LFA and the MHP LFA computations.
When the alternate ASBR or ABR node POi receives the packet, it always forwards it to the adjacent area
but the path to prefix P in that area may use node PObest. When PObest fails, node S has a non-working
backup path, which blackholes packets if activated during that same time until IGP converges. That is,
unless the neighbor node of PObest in the adjacent area installed a node protect LFA path to reach P.
However, if node Z computed a multi-homed backup path for prefix P using an alternate ABR or ASBR
POi and that path traverses PObest in the adjacent area, a failure of PObest immediately causes a traffic
blackhole. This is because node Z has information that the backup path it activated failed after IGP
converged in the adjacent area and POi updated the local area.
3.1.13.6.4 Enhancement to RFC 8518 Algorithm for backup path overlap with path to PObest
in the local area
The RFC 8518 inequalities in the preceding section for computing a backup path using an alternate ASBR
or ABR node POi can in some topologies result in a path that may still traverse the best ASBR or ABR
node PObest in the local area.
The SR OS implementation enhances the node S computation of the backup path by applying the following
additional inequality to detect that situation:
D_opt(N,POi)+ Cost(POi,P) < D_opt(N,PObest)+ Cost(PObest,P)
Node S prefers a path using a POi node which satisfies this inequality. If there is no such POi node, and in
the case of an external prefix or an anycast SID prefix of a SR-OSPF tunnel, node S attempts to compute a
SR repair tunnel following the enhancement to this feature described in 7750 SR and 7950 XRS Segment
Routing and PCE User Guide, section LFA solution across IGP area or instance boundary using SR repair
tunnel for SR OSPF.
An example topology in which an SR repair tunnel is preferred over the overlapping IP next-hop based
backup path is provided in 7750 SR and 7950 XRS Segment Routing and PCE User Guide, section
Example application of MH prefix LFA with repair tunnel.
In all cases, the backup path using the POi node which does not satisfy this inequality is programmed as a
last resort.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
Each ASBR advertises within Area 2 a route type 5 with the cost to reach prefix P, which is propagated by
ABR1 and ABR2 into Area 1. This also triggers ABR1 and ABR2 to advertise into Area 1 a route type 4 for
each of the prefixes of ASBR1 and ASBR2.
Node S resolves prefix P by recursively with the best path of cost 45 using ABR2 or ASBR2 and link SE2.
Base LFA finds a link-protect backup path of cost 60 using ABR2 or ASBR2 and link SE1.
When an LFA policy is applied to link SE2 to exclude its SRLG in the backup path computation, the backup
path using link SE2 is excluded. Furthermore, ABR1 and ABR2 do not have a link in local Area 1 and,
therefore, no path exists using ABR1 to ABR2 exit router in Area 1. As a result, prefix P remains without
protection.
Next, the MHP LFA in node S is enabled. Now S can use the backup path of cost 102 using alternate exit
ABR1 to reach ASBR1 and link SA2. This MHP LFA backup path satisfies the SRLG constraint.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
config>router>route-next-hop-policy>template template-name
A policy template can be used in both IS-IS and OSPF to apply the specific criteria described in the next
sub-sections to prefixes protected by LFA. Each instance of IS-IS or OSPF can apply the same policy
template to one or more prefix lists and to one or more interfaces.
The commands within the route next hop policy use the begin-commit-abort model introduced with BFD
templates. The following are the steps to create and modify the template.
• To create a template, the user enters the name of the new template directly under route-next-hop-
policy context.
• To delete a template which is not in use, the user enters the no form for the template name under the
route-next-hop-policy context.
• The user enters the editing mode by executing the begin command under route-next-hop-policy
context. The user can then edit and change any number of route next hop policy templates. However,
the parameter value can still be stored temporarily in the template module until the commit is executed
under the route-next-hop-policy context. Any temporary parameter changes are lost if the user enters
the abort command before the commit command.
• The user is allowed to create or delete a template instantly when in the editing mode without the need
to enter the commit command. Furthermore, the abort command if entered has no effect on the prior
deletion or creation of a template.
After the commit command is issued, IS-IS or OSPF re-evaluates the templates and if there are any net
changes, it schedules a new LFA SPF to re-compute the LFA next hop for the prefixes associated with
these templates.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
The user can add as many admin groups as configured to a specified IP interface. The same above
command can be applied multiple times.
Note: The configured admin-group membership is applied in all levels/areas in which the
interface is participating. The same interface cannot have different memberships in different
levels/areas.
The no form of the admin-group command under the interface deletes one or more of the admin-group
memberships of the interface. It deletes all memberships if no group name is specified.
Finally, the user adds the admin group constraint into the route next hop policy template.
CLI syntax
Each group is entered individually. The include-group statement instructs the LFA SPF selection algorithm
to pick up a subset of LFA next hops among the links which belong to one or more of the specified admin
groups. A link which does not belong to at least one of the admin-groups is excluded. However, a link can
still be selected if it belongs to one of the groups in a include-group statement but also belongs to other
groups which are not part of any include-group statement in the route next hop policy.
The pref option is used to provide a relative preference for the admin group to select. A lower preference
value means that LFA SPF first attempts to select a LFA backup next hop which is a member of the
corresponding admin group. If none is found, then the admin group with the next higher preference value
is evaluated. If no preference is configured for a specified admin group name, then it is supposed to be the
least preferred (for example, numerically the highest preference value).
When evaluating multiple include-group statements within the same preference, any link which belongs
to one or more of the included admin groups can be selected as an LFA next hop. There is no relative
preference based on how many of those included admin groups the link is a member of.
The exclude-group statement simply prunes all links belonging to the specified admin group before
making the LFA backup next hop selection for a prefix.
If the same group name is part of both include and exclude statements, the exclude statement wins. It
other words, the exclude statement can be viewed as having an implicit preference value of 0.
Note: The admin-group criterion is applied before running the LFA next hop selection algorithm.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
CLI syntax
The user can add a maximum of 64 SRLG groups to a specified IP interface. The same above command
can be applied multiple times.
Note: The configured SRLG membership is applied in all levels/areas in which the interface is
participating. The same interface cannot have different memberships in different levels/areas.
The no form of the srlg-group command under the interface deletes one or more of the SRLG
memberships of the interface. It deletes all SRLG memberships if no group name is specified.
Finally, the user adds the SRLG constraint into the route next hop policy template.
CLI syntax
When this command is applied to a prefix, the LFA SPF selects a LFA next hop, among the computed
ones, which uses an outgoing interface that does not participate in any of the SRLGs of the outgoing
interface used by the primary next hop.
Note: The SRLG and admin-group criteria are applied before running the LFA next hop selection
algorithm.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
When the route next hop policy template is applied to an IP interface, all prefixes using this interface as a
primary next hop follows the protection type and next hop type preference specified in the template.
When a route next hop policy template is applied to an interface in IS-IS, it is applied in both level 1 and
level 2. When a route next hop policy template is applied to an interface in OSPF, it is applied in all areas.
However, the above CLI command in an OSPF interface context can only be executed under the area
in which the specified interface is primary and then applied in that area and in all other areas where the
interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the
command fails.
If the user excluded the interface from LFA using the command loopfree-alternate-exclude, the LFA
policy if applied to the interface has no effect.
Finally, if the user applied a route next hop policy template to a loopback interface or to the system
interface, the command is not rejected but it results in no action taken.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
CLI syntax
config>router>isis>loopfree-alternates exclude
prefix-policy prefix-policy1 [prefix-policy2…up to 5]
config>router>ospf(3)>loopfree-alternates exclude
prefix-policy prefix-policy1 [prefix-policy2…up to 5]
config>service>vprn>ospf(3)>loopfree-alternates exclude
prefix-policy prefix-policy1 [prefix-policy2…up to 5]
config
router
policy-options
[no] prefix-list prefix-list1
prefix 62.225.16.0/24 prefix-length-range 32-
32
[no] policy-statements prefix-policy1
entry 10
from
prefix-list "prefix-list1"
exit
action accept
exit
exit
default-action reject
exit
If the user enabled the IS-IS prefix prioritization based on tag, it also applies to SPF LFA. If a prefix is
excluded from LFA, it is not included in LFA calculation regardless of its priority. However, the prefix tag can
be used in the main SPF.
The default action of the loopfree-alternates exclude command when not explicitly specified by the user
in the prefix policy is a ‟reject”. Consequently, regardless of whether the user did or did not explicitly add
the statement ‟default-action reject” to the prefix policy, a prefix that did not match any entry in the policy is
accepted into LFA SPF.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
and its FRR bypass backup LSP in MPLS context. The admin-group constraints can, however, be applied
to the selection of the outgoing interface of both the LSP primary path and its FRR bypass backup path.
The following is the modified LFA selection algorithm which is applied to prefixes resolving to a primary
next hop which uses a specific route next hop policy template.
• Split the LFA next hops into two sets:
– IP or direct next hops.
– Tunnel next hops after excluding the LSPs which use the same outgoing interface as the primary
next hop.
• Prune the IP LFA next hops which use the following links:
– Links which do not include one or more of the admin-groups in the include-group statements in the
route next hop policy template.
– Links which belong to admin-groups which have been explicitly excluded using the exclude-group
statement in the route next hop policy template.
– Links which belong to the SRLGs used by the primary next hop of a prefix.
• Continue with the set indicated in the nh-type value in the route next hop policy template if not empty;
otherwise continue with the other set.
• Within IP next hop set:
– Prefer LFA next hops which do not go over the Pseudo-Node (PN) used by the primary next hop.
– Within selected subset prefer the node-protect type or the link-protect type according to the value of
the protection-type option in the route next hop policy template.
– Within the selected subset, select the best admin-groups according to the preference specified in the
value of the include-group option in the route next hop policy template.
– Within selected subset, select lowest total cost of a prefix.
– If same total cost, select lowest router-id.
– If same router-id, select lowest interface-index.
• Within tunnel next hop set:
– Select tunnel next hops which endpoint corresponds to the node owning or advertising the prefix.
• Within selected subset, select the one with the lowest cost (lowest LSP metric).
• If same lowest cost, select tunnel with lowest tunnel-index.
– If none is available, continue with rest of the tunnel LFA next hop set.
– Prefer LFA next hops which do not go over the Pseudo-Node (PN) used by the primary next hop.
– Within selected subset prefer the node-protect type or the link-protect type according to the value of
the protection-type in the route next hop policy template.
– Within selected subset, select lowest total cost of a prefix. For a tunnel next hop, it means the LSP
metric plus the cost of the LSP endpoint to the destination of the prefix.
– If same total cost, select lowest endpoint to destination cost.
– If same endpoint to destination cost, select lowest router-id.
– If same router-id, select lowest tunnel-index.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
it needs to advertise new sub-TLVs. This mode of operation is very similar to the way OSPFv2 advertises
the Segment Routing information. It sends the prefix in the original fixed-format prefix LSA and then follows
with the extended prefix TLV which is sent in an extended prefix opaque LSA containing the prefix SID sub-
TLV.
The extended-lsa only value enables the full extended LSA mode and this causes all existing and new
LSAs to use the extended LSA format.
An OSPFv3 area inherits the instance level configuration but can also be configured independently to the
sparse of full extended LSA mode.
The OSPFv3 instance must first be shut down before the user can change the mode of operation, because
the protocol must flush all LSAs and re-establish all adjacencies.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
3.8.1 General
• Before OSPF can be configured, the router ID must be configured.
• The basic OSPF configuration includes at least one area and an associated interface.
• All default and command parameters can be modified.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
ALA-A>config>router>ospf# info
----------------------------------------------
area 0.0.0.0
interface "system"
exit
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
area 0.0.0.20
nssa
exit
interface "to-104"
priority 10
exit
exit
area 0.0.1.1
exit
----------------------------------------------
ALA-A>config>router>ospf#
A:ALA-48>config>router>ospf3# info
----------------------------------------------
asbr
overload
timers
lsa-arrival 50000
exit
export "OSPF-Export"
area 0.0.0.0
interface "system"
exit
exit
area 0.0.0.20
nssa
exit
interface "SR1-2"
exit
exit
area 0.0.0.25
stub
default-metric 5000
exit
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
when different protocols use different router IDs. To force the new router ID, issue the shutdown and no
shutdown commands for each protocol that uses the router ID or restart the entire router.
It is possible to configure an SR OS to operate with an IPv6 only BOF and no IPv4 system interface
address. When configured in this manner, the operator must explicitly define IPv4 router IDs for protocols
such as OSPF and BGP as there is no mechanism to derive the router ID from an IPv6 system interface
address.
The following displays a router ID configuration example:
A:ALA-B>config>router# info
#------------------------------------------
# IP Configuration
#------------------------------------------
interface "system"
address 10.10.10.104/32
exit
interface "to-103"
address 10.0.0.104/24
port 1/1/1
exit
autonomous-system 100
router-id 10.10.10.104
...
#------------------------------------------
A:ALA-B>config>router#
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
----------------------------------------------
A:ALA-49>config>router>ospf# ex
config>router# ospf3
asbr
export policy-name [policy-name...(up to 5 max)]
external-db-overflow limit seconds
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
external-preference preference
overload [timeout seconds]
overload-include-stub
overload-on-boot [timeout seconds]
preference preference
reference-bandwidth bandwidth-in-kbps
router-id ip-address
no shutdown
timers
lsa-arrival lsa-arrival-time
lsa-generate max-lsa-wait [lsa-initial-wait lsa-initial-wait [lsa-second-wait lsa-second-
wait]]
spf-wait max-spf-wait [spf-initial-wait spf-initial-wait [spf-second-wait spf-second-wait]]
A:ALA-48>config>router>ospf3# info
----------------------------------------------
asbr
overload
timers
lsa-arrival 50000
exit
export "OSPF-Export"
----------------------------------------------
A:ALA-48>config>router>ospf3#
OSPF also supports the concept of multi-instance OSPFv2 and OSPFv3 which allows separate instances
of the OSPF protocols to run independently within SR OSs.
Separate instances are created by adding a different instance ID as the optional parameter to the
config>router>ospf and config>router>ospf3 commands. When this is done a separate OSPF instance
is created which maintains separate link state databases for each instance.
ospf ospf-instance
area area-id
area-range ip-prefix/mask [advertise | not-advertise]
blackhole-aggregate
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
CLI syntax
ospf ospf-instance
ospf3
area area-id
area-range ip-prefix/mask [advertise | not-advertise]
blackhole-aggregate
A:ALA-A>config>router>ospf# info
----------------------------------------------
area 0.0.0.0
exit
area 0.0.0.20
exit
----------------------------------------------
ALA-A>config>router>ospf#A:
ospf
area area-id
stub
default-metric metric
summaries
Use the following CLI syntax to configure virtual links for OSPF3.
CLI syntax
ospf
ospf3
area area-id
stub
default-metric metric
summaries
ALA-A>config>router>ospf>area># info
----------------------------------------------
...
area 0.0.0.0
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
exit
area 0.0.0.20
stub
exit
exit
...
----------------------------------------------
ALA-A>config>router>ospf#
ALA-A>config>router>ospf>area># info
----------------------------------------------
...
area 0.0.0.0
exit
area 0.0.0.20
stub
exit
exit
...
----------------------------------------------
ALA-A>config>router>ospf#
A:ALA-48>config>router>ospf3>area# info
----------------------------------------------
stub
default-metric 5000
exit
----------------------------------------------
A:ALA-48>config>router>ospf3>area#
ospf ospf-instance
area area-id
nssa
area-range ip-prefix/mask [advertise|not-advertise]
originate-default-route [type-7]
redistribute-external
summaries
Use the following CLI syntax to configure stub areas for the OSPF3.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
CLI syntax
ospf ospf-instance
ospf3
area area-id
nssa
area-range ip-prefix/mask [advertise|not-advertise]
originate-default-route [type-7]
redistribute-external
summaries
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
area 0.0.0.0
exit
area 0.0.0.20
stub
exit
exit
area 0.0.0.25
nssa
exit
exit
----------------------------------------------
A:ALA-49>config>router>ospf#
A:ALA-48>config>router>ospf3# info
----------------------------------------------
asbr
overload
timers
lsa-arrival 50000
exit
export "OSPF-Export"
area 0.0.0.0
exit
area 0.0.0.20
stub
exit
exit
area 0.0.0.25
nssa
exit
exit
area 4.3.2.1
exit
----------------------------------------------
A:ALA-48>config>router>ospf3#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
The router-id parameter specified in the virtual-link command must be associated with the virtual
neighbor, that is, enter the virtual neighbor’s router ID, not the local router ID. The transit area cannot be a
stub area or an NSSA.
Use the following CLI syntax to configure stub areas.
CLI syntax
ospf ospf-instance
area area-id
virtual-link router-id transit-area area-id
authentication-key [authentication-key|hash-key] [hash]
authentication-type [password|message-digest]
dead-interval seconds
hello-interval seconds
message-digest-key key-id md5 [key|hash-key] [hash|hash2|custom]
retransmit-interval seconds
transit-delay
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
no shutdown
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
exit
area 0.0.0.20
stub
exit
exit
area 0.0.0.25
nssa
exit
exit
area 1.2.3.4
exit
----------------------------------------------
A:ALA-49>config>router>ospf#
A:ALA-48>config>router>ospf3# info
----------------------------------------------
asbr
overload
timers
lsa-arrival 50000
exit
export "OSPF-Export"
area 0.0.0.0
virtual-link 4.3.2.1 transit-area 4.3.2.1
exit
exit
area 0.0.0.20
stub
exit
exit
area 0.0.0.25
nssa
exit
exit
area 4.3.2.1
exit
----------------------------------------------
A:ALA-48>config>router>ospf3#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
ospf ospf-instance
area area-id
interface ip-int-name [secondary]
advertise-subnet
authentication-key [authenticationkey|hash-key] [hash|hash2|custom]
authentication-type [password|messagedigest]
bfd-enable [remain-down-on-failure]
dead-interval seconds
hello-interval seconds
interface-type {broadcast|point-to-point|non-broadcast}
message-digest-key key-id md5 [key|hashkey][hash|hash2|custom]
metric metric
mtu bytes
passive
priority number
retransmit-interval seconds
no shutdown
transit-delay seconds
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
interface "system"
exit
exit
area 0.0.0.20
stub
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
exit
interface "to-103"
exit
exit
area 0.0.0.25
nssa
exit
exit
area 1.2.3.4
exit
area 4.3.2.1
interface "SR1-3"
exit
exit
area 4.3.2.1
interface "SR1-3" secondary
exit
exit
----------------------------------------------
A:ALA-49>config>router>ospf# area 0.0.0.20
A:ALA-48>config>router>ospf3# info
----------------------------------------------
asbr
overload
timers
lsa-arrival 50000
exit
export "OSPF-Export"
area 0.0.0.0
virtual-link 4.3.2.1 transit-area 4.3.2.1
exit
interface "system"
exit
exit
area 0.0.0.20
stub
exit
interface "SR1-2"
exit
exit
area 0.0.0.25
nssa
exit
exit
area 4.3.2.1
exit
----------------------------------------------
A:ALA-48>config>router>ospf3#
3.9.3.8.1 Overview
The use of protocol authentication is recommended to protect against malicious attack on the
communications between routing protocol neighbors. These attacks could aim to either disrupt
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
communications or to inject incorrect routing information into the systems routing table. The use of
authentication keys can help to protect the routing protocols from these types of attacks.
Authentication must be explicitly configured and can be done so through two separate mechanisms. First
is configuration of an explicit authentication key and algorithm through the use of the authentication and
authentication-type commands. The second method is through the use of the authentication keychain
mechanism. Both mechanisms are described in the following sections.
ospf ospf-instance
area area-id
interface ip-int-name
authentication-key [authentication-key|hash-key] [hash]
authentication-type [password|message-digest]
message-digest-key key-id md5 key [hash]
virtual-link router-id transit-area area-id
authentication-key [authentication-key|hash-key] [hash]
authentication-type [password|message-digest]
message-digest-key key-id md5 key [hash]
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
interface "system"
exit
exit
area 0.0.0.20
stub
exit
interface "to-103"
exit
exit
area 0.0.0.25
nssa
exit
exit
area 0.0.0.40
interface "test1"
authentication-type password
authentication-key "3WErEDozxyQ" hash
exit
exit
area 1.2.3.4
exit
----------------------------------------------
A:ALA-49>config>router>ospf#
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 10.0.0.1 transit-area 0.0.0.1
authentication-type message-digest
message-digest-key 2 md5 "Mi6BQAFi3MI" hash
exit
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
interface "system"
exit
exit
area 0.0.0.1
exit
area 0.0.0.20
stub
exit
interface "to-103"
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
exit
exit
area 0.0.0.25
nssa
exit
exit
area 0.0.0.40
interface "test1"
authentication-type password
authentication-key "3WErEDozxyQ" hash
exit
exit
area 1.2.3.4
exit
----------------------------------------------
A:ALA-49>config>router>ospf#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
ospf ospf-instance
area area-id
interface ip-int-name
priority number
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 10.0.0.1 transit-area 0.0.0.1
authentication-type message-digest
message-digest-key 2 md5 "Mi6BQAFi3MI" hash
exit
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
interface "system"
exit
exit
area 0.0.0.1
exit
area 0.0.0.20
stub
exit
interface "to-103"
exit
exit
area 0.0.0.25
nssa
exit
interface "if2"
priority 100
exit
exit
area 0.0.0.40
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
interface "test1"
authentication-type password
authentication-key "3WErEDozxyQ" hash
exit
exit
area 1.2.3.4
exit
----------------------------------------------
A:ALA-49>config>router>ospf#
ospf ospf-instance
area area-id
stub
summaries
nssa
summaries
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 10.0.0.1 transit-area 0.0.0.1
authentication-type message-digest
message-digest-key 2 md5 "Mi6BQAFi3MI" hash
exit
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
interface "system"
exit
exit
area 0.0.0.1
exit
area 0.0.0.20
stub
exit
interface "to-103"
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
exit
exit
area 0.0.0.25
nssa
exit
interface "if2"
priority 100
exit
exit
area 0.0.0.40
interface "test1"
authentication-type password
authentication-key "3WErEDozxyQ" hash
exit
exit
area 1.2.3.4
exit
----------------------------------------------
A:ALA-49>config>router>ospf#
A:ALA-48>config>router>ospf3# info
----------------------------------------------
asbr
overload
timers
lsa-arrival 50000
exit
export "OSPF-Export"
area 0.0.0.0
virtual-link 4.3.2.1 transit-area 4.3.2.1
exit
interface "system"
exit
exit
area 0.0.0.20
stub
exit
interface "SR1-2"
exit
exit
area 0.0.0.25
nssa
exit
exit
area 4.3.2.1
exit
----------------------------------------------
A:ALA-48>config>router>ospf3#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
Direct attached 0 —
If multiple routes are learned with an identical preference using the same protocol and the costs (metrics)
are equal, then the decision of what route to use is determined by the configuration of the ecmp in the
config>router context.
The following CLI commands are displayed to illustrate route preference features. The command
parameters can be defined at the same time you are configuring OSPF. See Configuring OSPF
components.
Use the following CLI syntax to configure a route preference.
CLI syntax
ospf ospf-instance
preference preference
external-preference preference
Use the following CLI syntax to configure a route preference for the OSPF3.
CLI syntax
ospf ospf-instance
ospf3
preference preference
external-preference preference
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
1 Preference for OSPF internal routes is configured with the preference command.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
traffic-engineering
preference 9
external-preference 140
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 10.0.0.1 transit-area 0.0.0.1
authentication-type message-digest
message-digest-key 2 md5 "Mi6BQAFi3MI" hash
exit
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
interface "system"
exit
exit
area 0.0.0.1
exit
area 0.0.0.20
stub
exit
interface "to-103"
exit
exit
area 0.0.0.25
nssa
exit
interface "if2"
priority 100
exit
exit
area 0.0.0.40
interface "test1"
authentication-type password
authentication-key "3WErEDozxyQ" hash
exit
exit
area 1.2.3.4
exit
----------------------------------------------
A:ALA-48>config>router>ospf3# info
----------------------------------------------
asbr
overload
timers
lsa-arrival 50000
exit
preference 9
external-preference 140
export "OSPF-Export"
area 0.0.0.0
virtual-link 4.3.2.1 transit-area 4.3.2.1
exit
interface "system"
exit
exit
area 0.0.0.20
stub
exit
interface "SR1-2"
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
exit
area 0.0.0.25
nssa
exit
exit
area 4.3.2.1
exit
----------------------------------------------
A:ALA-48>config>router>ospf3#
A:ALA-49>config>router# info
------------------------------------------
IP Configuration
------------------------------------------
interface "system"
address 10.10.10.104/32
exit
interface "to-103"
address 10.0.0.103/24
port 1/1/1
exit
autonomous-system 100
router-id 10.10.10.104
------------------------------------------
A:ALA-49>config>router#
ALA-48>config>router# info
------------------------------------------
IP Configuration
------------------------------------------
interface "system"
address 10.10.10.103/32
exit
interface "to-104"
address 10.0.0.104/24
port 1/1/1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
exit
autonomous-system 100
router-id 10.10.10.103
------------------------------------------
ALA-48>config>router#
config>router# ospf 1
config>router>ospf# area 0.0.0.20
config>router>ospf>area# no interface "to-103"
config>router>ospf>area# interface "to-HQ
config>router>ospf>area>if$ priority 50
config>router>ospf>area>if# exit
config>router>ospf>area# exit
The following example displays the OSPF configuration with the modifications entered in the previous
example:
A:ALA-49>config>router>ospf# info
----------------------------------------------
asbr
overload
overload-on-boot timeout 60
traffic-engineering
preference 9
external-preference 140
export "OSPF-Export"
exit
area 0.0.0.0
virtual-link 10.0.0.1 transit-area 0.0.0.1
authentication-type message-digest
message-digest-key 2 md5 "Mi6BQAFi3MI" hash
exit
virtual-link 1.2.3.4 transit-area 1.2.3.4
hello-interval 9
dead-interval 40
exit
interface "system"
exit
exit
area 0.0.0.1
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE OSPF
22.2.R1
area 0.0.0.20
stub
exit
interface "to-HQ"
priority 50
exit
exit
area 0.0.0.25
nssa
exit
interface "if2"
priority 100
exit
exit
area 0.0.0.40
interface "test1"
authentication-type password
authentication-key "3WErEDozxyQ" hash
exit
exit
area 1.2.3.4
exit
----------------------------------------------
A:ALA-49>config>router>ospf#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
4 IS-IS
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
4.1.1 Routing
OSI IS-IS routing uses two-level hierarchical routing. A routing domain can be partitioned into areas.
Level 1 routers know the topology in their area, including all routers and end systems in their area but do
not know the identity of routers or destinations outside of their area. Level 1 routers forward traffic with
destinations outside of their area to a level 2 router in their area.
Level 2 routers know the level 2 topology, and know which addresses are reachable by each level 2 router.
Level 2 routers do not need to know the topology within any level 1 area, except to the extent that a level 2
router can also be a level 1 router within a single area. By default, only level 2 routers can exchange PDUs
or routing information directly with external routers located outside the routing domain.
The two types of routers in IS-IS are described below.
• Level 1 intermediate systems
Routing is performed based on the area ID portion of the ISO address called the Network Entity Title
(NET). Level 1 systems route within an area. They recognize, based on the destination address,
whether the destination is within the area. If so, they route toward the destination. If not, they route to
the nearest level 2 router.
• Level 2 intermediate systems
Routing is performed based on the area address. They route toward other areas, regardless of other
area’s internal structure. A level 2 intermediate system can also be configured as a level 1 intermediate
system in the same area.
The level 1 router’s area address portion is manually configured (see ISO network addressing). A level
1 router does not become a neighbor with a node that does not have a common area address. However,
if a level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, then
the level 1 router accepts the other node as a neighbor, as address B is common to both routers. Level
2 adjacencies are formed with other level 2 nodes whose area addresses do not overlap. If the area
addresses do not overlap, the link is considered by both routers to be level 2 only and only level 2 LSPDUs
flow on the link.
Within an area, level 1 routers exchange LSPs which identify the IP addresses reachable by each router.
Specifically, zero or more IP address, subnet mask, and metric combinations can be included in each LSP.
Each level 1 router is manually configured with the IP address, subnet mask, and metric combinations,
which are reachable on each interface. A level 1 router routes as follows:
• if a specified destination address matches an IP address, subnet mask, or metric reachable within the
area; the PDU is routed via level 1 routing
• if a specified destination address does not match any IP address, subnet mask, or metric combinations
listed as reachable within the area; the PDU is routed toward the nearest level 2 router
Level 2 routers include in their LSPs, a complete list of IP address, subnet mask, and metrics specifying
all the IP addresses which reachable in their area. This information can be obtained from a combination of
the level 1 LSPs (by level 1 routers in the same area). Level 2 routers can also report external reachability
information, corresponding to addresses reachable by routers in other routing domains or autonomous
systems.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
• End system
End systems send NPDUs to other systems and receive NPDUs from other systems, but do not relay
NPDUs. This International Standard does not specify any additional end system functions beyond those
supplied by ISO 8473 and ISO 9542.
• Neighbor
A neighbor is an adjacent system reachable by traversing a single sub-network by a PDU.
• Adjacency
An adjacency is a portion of the local routing information which pertains to the reachability of a single
neighboring end or intermediate system over a single circuit. Adjacencies are used as input to the
decision process to form paths through the routing domain. A separate adjacency is created for each
neighbor on a circuit and for each level of routing (level 1 and level 2) on a broadcast circuit.
• Circuit
The subset of the local routing information base pertinent to a single local Subnetwork Point of
Attachments (SNPAs).
• Link
The communication path between two neighbors. A link is up when communication is possible between
the two SNPAs.
• Designated IS
The intermediate system on a LAN which is designated to perform additional duties. In particular, the
designated IS generates link-state PDUs on behalf of the LAN, treating the LAN as a pseudonode.
• Pseudonode
Where a broadcast sub-network has n connected intermediate systems, the broadcast sub-network
itself is considered to be a pseudonode. The pseudonode has links to each of the n intermediate
systems and each of the ISs has a single link to the pseudonode (instead of n-1 links to each of the
other intermediate systems). Link-state PDUs are generated on behalf of the pseudonode by the
designated IS.
• Broadcast sub-network
A multi-access subnetwork that supports the capability of addressing a group of attached systems with
a single PDU.
• General topology sub-network
A topology that is modeled as a set of point-to-point links, each of which connects two systems. There
are several generic types of general topology subnetworks, multipoint links, permanent point-to-point
links, dynamic and static point-to-point links.
• Routing sub-domain
A routing sub-domain consists of a set of intermediate systems and end systems located within the
same routing domain.
• Level 2 sub-domain
Level 2 sub-domain is the set of all level 2 intermediate systems in a routing domain.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
An end system can have multiple NSAP addresses, in which case the addresses differ only by the last byte
(called the n selector). Each NSAP represents a service that is available at that node. In addition to having
multiple services, a single node can belong to multiple areas.
Each network entity has a special network address called a Network Entity Title (NET). Structurally, a
NET is identical to an NSAP address but has an n-selector of 00. Most end systems have one NET.
Intermediate systems can have up to three area IDs (area addresses).
NSAP addresses are divided into three parts. Only the area ID portion is configurable.
• Area ID
A variable length field between 1 and 13 bytes long. This includes the Authority and Format Identifier
(AFI) as the most significant byte and the area ID.
• System ID
A six-byte system identification. This value is not configurable. The system ID is derived from the
system or router ID.
• Selector ID
A one-byte selector identification that must contain zeros when configuring a NET. This value is not
configurable. The selector ID is always 00.
Of the total 20 bytes comprising the NET, only the first 13 bytes, the area ID portion, can be manually
configured. As few as one byte can be entered or, at most, 13 bytes. If less than 13 bytes are entered, the
rest is padded with zeros.
Routers with common area addresses form level 1 adjacencies. Routers with no common NET addresses
form level 2 adjacencies, if they are capable (Figure 15: Using area addresses to form adjacencies).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
to IP reach TLVs and in general, for any IS-IS LSP TLV and sub-TLV change that does not impact the
network topology.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
config>router>policy-options>policy-statement>entry>from
config>router>policy-options>policy-statement>entry>action tag tag-value
config>router>policy-options>policy-statement# default-action tag tag-value
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
4.5.1 General
• IS-IS must be enabled on each participating router.
• There are no default network entity titles.
• There are no default interfaces.
• By default, the routers are assigned a level 1/level 2 level capability.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
NSAP addresses are divided into three parts. Only the Area ID portion is configurable.
Procedure
Step 1. Set the area ID.
A variable length field between 1 and 13 bytes long. This includes the Authority and Format
Identifier (AFI) as the most significant byte and the area ID.
Step 2. Set the system ID.
A six-byte system identification. This value is not configurable. The system ID is derived from the
system or router ID.
Step 3. Set the selector ID.
A one-byte selector identification that must contain zeros when configuring a NET. This value is
not configurable. The selector ID is always 00.
Example
The following example displays ISO addresses in IS-IS address format:
MAC address 00:a5:c7:6b:c4:9049.0011.00a5.c76b.c490.00 IP address: 218.112.14.5
49.0011.2181.1201.4005.00
L2 L2 Level 2 only
L2 L1 —
L1 L2 —
L1 L1 Level 1 only
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
hello-authentication
psnp-authentication
no traffic-engineering
no reference-bandwidth
no default-route-tag
no disable-ldp-sync
no advertise-passive-only
no advertise-router-capability
no hello-padding
no ldp-over-rsvp
no advertise-tunnel-link
no ignore-attached-bit
no suppress-attached-bit
no iid-tlv-enable
no poi-tlv-enable
no prefix-limit
no loopfree-alternates
no rib-priority high
ipv4-routing
no ipv6-routing
ipv4-multicast-routing native
ipv6-multicast-routing native
no multi-topology
no unicast-import-disable both
no multicast-import both
no strict-adjacency-check
igp-shortcut
shutdown
tunnel-next-hop
family ipv4
resolution disabled
resolution-filter
no rsvp
no sr-te
exit
family ipv6
resolution disabled
resolution-filter
no rsvp
no sr-te
exit
family srv4
resolution disabled
resolution-filter
no rsvp
no sr-te
exit
family srv6
resolution disabled
resolution-filter
no rsvp
no sr-te
exit
exit
exit
timers
lsp-wait 5000 lsp-initial-wait 10 lsp-second-wait 1000
sfp-wait 10000 sfp-initial-wait 1000 sfp-second-wait 1000
exit
level 1
advertise-router-capability
no hello-padding
no lsp-mtu-size
no auth-keychain
no authentication-key
no authentication-type
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
csnp-authentication
external-preference 160
hello-authentication
no loopfree-alternate-exclude
preference 15
psnp-authentication
no wide-metrics-only
default-metric 10
default-ipv4-multicast-metric 10
default-ipv6-unicast-metric 10
default-ipv6-multicast-metric 10
exit
level 2
advertise-router-capability
no hello-padding
no lsp-mtu-size
no auth-keychain
no authentication-key
no authentication-type
csnp-authentication
external-preference 165
hello-authentication
no loopfree-alternate-exclude
preference 18
psnp-authentication
no wide-metrics-only
default-metric 10
default-ipv4-multicast-metric 10
default-ipv6-unicast-metric 10
default-ipv6-multicast-metric 10
exit
segment-routing
shutdown
adj-sid-hold 15
no export-tunnel-table
no prefix-sid-range
no tunnel-table-pref
no tunnel-mtu
mapping-server
shutdown
exit
exit
no shutdown
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
Caution: Careful planning is essential to implement commands that can affect the behavior of
global and interface levels.
isis
Example
config>router# isis
IS-IS also supports the concept of multi-instance IS-IS which allows separate instances of the IS-IS
protocol to run independently of the SR OS router.
Separate instances are created by adding a different instance ID as the optional parameter to the
config>router>isis command.
config>router# isis
level-capability {level-1|level-2|level-1/2}
level {1|2}
Example
config>router# isis
config>router>isis# level-capability 1/2
config>router>isis# level 2
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
A:ALA-A>config>router>isis# info
#------------------------------------------
echo "ISIS"
#------------------------------------------
level-capability level-1/2
level 2
----------------------------------------------
A:ALA-A>config>router>isis#
config>router>isis#
config>router>isis# area-id 49.0180.0001
config>router>isis# area-id 49.0180.0002
config>router>isis# area-id 49.0180.0003
A:ALA-A>config>router>isis# info
----------------------------------------------
area-id 49.0180.0001
area-id 49.0180.0002
area-id 49.0180.0003
----------------------------------------------
A:ALA-A>config>router>isis#
config>router# isis
config>router>isis# level-capability level-2
config>router>isis# authentication-check
config>router>isis# authentication-type password
config>router>isis# authentication-key test
config>router>isis# overload timeout 90
config>router>isis# traffic-engineering
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
A:ALA-A>config>router>isis# info
----------------------------------------------
level-capability level-2
area-id 49.0180.0001
area-id 49.0180.0002
area-id 49.0180.0003
authentication-key "H5KBAWrAAQU" hash
authentication-type password
overload timeout 90
traffic-engineering
----------------------------------------------
A:ALA-A>config>router>isis#
Ensure that all MT routers have the IPv6 reachability information required by MT TLVs.
CLI syntax
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
CLI syntax
TLVs :
Area Addresses :
Area Address : (13) 47.4001.8000.00a7.0000.ffdd.0007
Supp Protocols :
Protocols : IPv4 IPv6
IS-Hostname :
Hostname : ALA-49
TE Router ID :
Router ID : 10.10.10.104
Internal Reach :
IP Prefix : 10.10.10.104/32 (Dir. :Up) Metric : 0 (I)
IP Prefix : 10.10.4.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.10.5.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.10.7.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.10.0.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.0.0.0/24 (Dir. :Up) Metric : 10 (I)
MT IPv6 Reach. :
MT ID : 2
IPv6 Prefix : 3ffe::101:100/120
Flags : Up Internal Metric : 10
IPv6 Prefix : 10::/64
Flags : Up Internal Metric : 10
I/f Addresses :
IP Address : 10.10.10.104
IP Address : 10.10.4.3
IP Address : 10.10.5.3
IP Address : 10.10.7.3
IP Address : 10.10.0.16
IP Address : 10.0.0.104
I/f Addresses IPv6 :
IPv6 Address : 3FFE::101:101
IPv6 Address : 10::104
TE IP Reach. :
IP Prefix : 10.10.10.104/32 (Dir. :Up) Metric : 0
IP Prefix : 10.10.4.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.10.5.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.10.7.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.10.0.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.0.0.0/24 (Dir. :Up) Metric : 10
Authentication :
Auth Type : Password(1) (116 bytes)
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
TLVs :
Area Addresses :
Area Address : (13) 47.4001.8000.00a7.0000.ffdd.0007
Supp Protocols :
Protocols : IPv4 IPv6
IS-Hostname :
Hostname : ALA-49
TE Router ID :
Router ID : 10.10.10.104
Internal Reach :
IP Prefix : 10.10.10.104/32 (Dir. :Up) Metric : 0 (I)
IP Prefix : 10.10.4.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.10.5.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.10.7.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.10.0.0/24 (Dir. :Up) Metric : 10 (I)
IP Prefix : 10.0.0.0/24 (Dir. :Up) Metric : 10 (I)
MT IPv6 Reach. :
MT ID : 2
IPv6 Prefix : 3ffe::101:100/120
Flags : Up Internal Metric : 10
IPv6 Prefix : 10::/64
Flags : Up Internal Metric : 10
I/f Addresses :
IP Address : 10.10.10.104
IP Address : 10.10.4.3
IP Address : 10.10.5.3
IP Address : 10.10.7.3
IP Address : 10.10.0.16
IP Address : 10.0.0.104
I/f Addresses IPv6 :
IPv6 Address : 3FFE::101:101
IPv6 Address : 10::104
TE IP Reach. :
IP Prefix : 10.10.10.104/32 (Dir. :Up) Metric : 0
IP Prefix : 10.10.4.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.10.5.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.10.7.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.10.0.0/24 (Dir. :Up) Metric : 10
IP Prefix : 10.0.0.0/24 (Dir. :Up) Metric : 10
Authentication :
Auth Type : MD5(54) (16 bytes)
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
...
ipv4-routing
ipv6-routing mt
multi-topology
ipv6-unicast
exit
...
----------------------------------------------
A:ALA-49>config>router>isis#
CLI syntax
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
Note: For point-to-point interfaces, only the values configured under level 1 are used regardless
of the operational level of the interface.
config>router# isis
config>router>isis# level 1
config>router>isis>level# wide-metrics-only
config>router>isis>level# exit
config>router>isis# level 2
config>router>isis>level# wide-metrics-only
config>router>isis>level# exit
config>router>isis# interface ALA-1-2
config>router>isis>if# level-capability level-2
config>router>isis>if# exit
config>router>isis# interface ALA-1-3
config>router>isis>if# level-capability level-1
config>router>isis>if# interface-type point-to-point
config>router>isis>if# exit
A:ALA-A>config>router>isis# info
----------------------------------------------
level-capability level-2
area-id 49.0180.0001
area-id 49.0180.0002
area-id 49.0180.0003
authentication-key "H5KBAWrAAQU" hash
authentication-type password
traffic-engineering
level 1
wide-metrics-only
exit
level 2
wide-metrics-only
exit
interface "system"
exit
interface "ALA-1-2"
level-capability level-2
exit
interface "ALA-1-3"
level-capability level-1
interface-type point-to-point
exit
interface "ALA-1-5"
level-capability level-1
interface-type point-to-point
exit
interface "to-103"
exit
----------------------------------------------
A:ALA-A>config>router>isis#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
The following example displays the command usage to configure a level 1 area.
A:ALA-A>config>router# isis
A:ALA-A>config>router>isis# area-id 47.0001
A:ALA-A>config>router>isis# level-capability level-1
A:ALA-A>config>router>isis# interface system
A:ALA-A>config>router>isis>if# exit
A:ALA-A>config>router>isis# interface A-B
A:ALA-A>config>router>isis>if# exit
A:ALA-A>config>router>isis# interface A-C
A:ALA-A>config>router>isis>if# exit
A:ALA-A>config>router>isis#
A:ALA-B>config>router# isis
A:ALA-B>config>router>isis# area-id 47.0001
A:ALA-B>config>router>isis# level-capability level-1
A:ALA-B>config>router>isis# interface system
A:ALA-B>config>router>isis>if# exit
A:ALA-B>config>router>isis# interface B-A
A:ALA-B>config>router>isis>if# exit
A:ALA-B>config>router>isis# interface B-C
A:ALA-B>config>router>isis>if# exit
A:ALA-B>config>router>isis#
A:ALA-C>config>router# isis
A:ALA-C>config>router>isis# area-id 47.0001
A:ALA-C>config>router>isis# level-capability level-1
A:ALA-C>config>router>isis# interface system
A:ALA-C>config>router>isis>if# exit
A:ALA-C>config>router>isis# interface "C-A"
A:ALA-C>config>router>isis>if# exit
A:ALA-C>config>router>isis# interface "C-B"
A:ALA-C>config>router>isis>if# exit
A:ALA-A>config>router>isis# info
----------------------------------------------
level-capability level-1
area-id 49.0180.0001
interface "system"
exit
interface "A-B"
exit
interface "A-C"
exit
----------------------------------------------
A:ALA-A>config>router>isis#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
A:ALA-B>config>router>isis# info
----------------------------------------------
level-capability level-1
area-id 49.0180.0001
interface "system"
exit
interface "B-A"
exit
interface "B-C"
exit
----------------------------------------------
A:ALA-B>config>router>isis#
A:ALA-C>config>router>isis# info
#------------------------------------------
echo "ISIS"
----------------------------------------------
level-capability level-1
area-id 49.0180.0001
interface "system"
exit
interface "C-A"
exit
interface "C-B"
exit
----------------------------------------------
A:ALA-C>config>router>isis#
The following example displays the command usage to configure a level 1/2 system.
A:ALA-A>config>router# isis
A:ALA-A>config>router>isis# level-capability level-1/2
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
config>router# isis
shutdown
config>router#
no isis
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
Example
A:ALA-A>config>router>isis# info
----------------------------------------------
area-id 49.0180.0001
area-id 49.0180.0002
area-id 49.0180.0003
authentication-key "//oZrvtvFPn06S42lRIJsE" hash
authentication-type password
no authentication-check
overload timeout 500 on-boot
level 1
wide-metrics-only
exit
level 2
wide-metrics-only
exit
interface "system"
exit
interface "ALA-1-2"
level-capability level-2
exit
interface "ALA-1-3"
level-capability level-1
interface-type point-to-point
exit
interface "ALA-1-5"
level-capability level-1
interface-type point-to-point
exit
interface "to-103"
exit
interface "A-B"
exit
interface "A-C"
exit
----------------------------------------------
A:ALA-A>config>router>isis#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
Example
config>router# isis
config>router>isis# interface ALA-1-3
config>router>isis>if# passive
config>router>isis>if# exit
config>router>isis# interface to-103
config>router>isis>if# hello-authentication-type message-digest
config>router>isis>if# hello-authentication-key secretkey
config>router>isis>if# exit
A:ALA-A>config>router>isis# info
----------------------------------------------
area-id 49.0180.0001
area-id 49.0180.0002
area-id 49.0180.0003
authentication-key "//oZrvtvFPn06S42lRIJsE" hash
authentication-type password
no authentication-check
overload timeout 500 on-boot
level 1
wide-metrics-only
exit
level 2
wide-metrics-only
exit
interface "system"
exit
interface "ALA-1-2"
level-capability level-2
exit
interface "ALA-1-3"
level-capability level-1
interface-type point-to-point
passive
exit
interface "ALA-1-5"
level-capability level-1
interface-type point-to-point
exit
interface "to-103"
hello-authentication-key "DvR3l264KQ6vXMTvbAZ1mE" hash
hello-authentication-type message-digest
exit
interface "A-B"
exit
----------------------------------------------
A:ALA-A>config>router>isis#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
To configure the use of an authentication keychain within IS-IS, use the following steps.
1. Configure an authentication keychain within the config>system>security context. The configured
keychain must include at least on valid key entry, using a valid authentication algorithm for the IS-IS
protocol.
2. Associate the configure authentication keychain with IS-IS. Authentication keychains can be used to
specify the authentication at the IS-IS global, and level context as well as for hello authentication at the
interface and interface-level context.
The association of the authentication keychain is established through the auth-keychain keychain-name
command at the global and level context. The hello authentication association is established through the
hello-auth-keychain keychain-name command.
For a key entry to be valid, it must include a valid key, the current system clock value must be within the
begin and end time of the key entry, and the algorithm specified in the key entry must be supported by the
IS-IS protocol.
The IS-IS protocol supports the following algorithms:
• clear text password (RFC 5304 and RFC 5310 formats)
• HMAC-MD5 (RFC 5304 and RFC 5310 formats)
• HMAC-SHA-1 (RFC 5310 format)
• HMAC-SHA-256 (RFC 5310 format)
The IS-IS key entry may also include the option parameter to determine how the IS-IS protocol encodes
the authentication signature. The value of basic results in the use of RFC 5304 format. The default or a
value of isis-enhanced results in using the RFC 5310 format.
The error handling is described below.
• If a keychain exists but there are no active key entries with an authentication type that is valid for
the associated protocol then inbound protocol packets are not authenticated and discarded and no
outbound protocol packets should be sent.
• If keychain exists, but the last key entry has expired, a log entry is raised indicating that all keychain
entries have expired. The IS-IS protocol requires that the protocol not revert to an unauthenticated state
and requires that the old key is not to be used, therefore, after the last key has expired, all traffic is
discarded.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
The following example shows the command usage to configure prefix list and policy statement parameters
in the config>router context.
A:ALA-A>config>router>policy-options# info
----------------------------------------------
prefix-list "loops"
prefix 10.1.1.0/24 longer
exit
policy-statement "leak"
entry 10
from
prefix-list "loop"
level 2
exit
to
level 1
exit
action accept
exit
exit
exit
----------------------------------------------
A:ALA-A>config>router>policy-options#
Next, apply the policy to leak routes from level 2 info level 1 systems on ALA-A.
config>router#isis
config>router>isis# export leak
A:ALA-A>config>router>isis# info
----------------------------------------------
area-id 49.0180.0001
area-id 49.0180.0002
area-id 49.0180.0003
authentication-key "//oZrvtvFPn06S42lRIJsE" hash
authentication-type password
no authentication-check
export "leak"
...
----------------------------------------------
A:ALA-A>config>router>isis#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
After the policy is applied, create a policy to redistribute external IS-IS routes from level 1 systems into the
level 2 backbone (see Redistributing external IS-IS routers). In the config>router context, configure the
following policy statement parameters:
config>router>policy-options# begin
..>policy-options# policy-statement "isis-ext"
..>policy-options>policy-statement# entry 10
..>policy-options>policy-statement>entry$ from
..>policy-options>policy-statement>entry>from$ external
..>policy-options>policy-statement>entry>from# exit
..>policy-options>policy-statement>entry# to
..>policy-options>policy-statement>entry>to$ level 2
..>policy-options>policy-statement>entry>to# exit
..>policy-options>policy-statement>entry# action accept
..>policy-options>policy-statement>entry>action# exit
..>policy-options>policy-statement>entry# exit
..>policy-options>policy-statement# exit
..>policy-options# commit
A:ALA-A>config>router>policy-options# info
----------------------------------------------
prefix-list "loops"
prefix 10.1.1.0/24 longer
exit
policy-statement "leak"
entry 10
from
prefix-list "loop"
level 2
exit
to
level 1
exit
action accept
exit
exit
exit
policy-statement "isis-ext"
entry 10
from
external
exit
to
level 2
exit
action accept
exit
exit
exit
----------------------------------------------
A:ALA-A>config>router>policy-options#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE IS-IS
22.2.R1
config>router>policy-options# info
----------------------------------------------
prefix-list "loops"
prefix 10.1.1.0/24 longer
exit
policy-statement "leak"
entry 10
from
prefix-list "loop"
level 2
exit
to
level 1
exit
action accept
exit
exit
exit
policy-statement "isis-ext"
entry 10
from
external
exit
to
level 2
exit
action accept
exit
exit
exit
----------------------------------------------
config>router>policy-options#
- all-l1isis 01-80-C2-00-00-14
You can also specify the MAC address for all L2 IS-IS routers by using the all-l2isis command.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
5 BGP
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
A confederation EBGP session is formed when the two BGP routers belong to different member AS of
the same confederation. More details about BGP confederations are provided in the section titled BGP
confederations.
SR OS supports both statically configured and dynamic (unconfigured) BGP sessions. Dynamic sessions
are supported by configuring one or more prefix commands in the dynamic-neighbor>match CLI context
of a BGP group. Statically configured BGP sessions are configured using the neighbor command. This
command accepts either an IPv4 or IPv6 address, which allows the session transport to be IPv4 or IPv6.
By default, the router is the active side of TCP connections to statically configured remote peers, meaning
that as soon as a session leaves the Idle state, the router attempts to set up an outgoing TCP connection
to the remote neighbor in addition to listening on TCP port 179 for an incoming connection from the peer.
If required, a statically configured BGP session can be configured for passive mode so that the router
only listens for an incoming connection and does not attempt to set up the outgoing connection. The router
always operates in passive mode with respect to its dynamic (unconfigured) sessions.
The source IP address used to set up the TCP connection to the statically configured or dynamic peer can
be configured explicitly using the local-address command. If a local-address is not configured then the
source IP address is determined as follows:
• if the neighbor’s IP address belongs to a local subnet the source IP address is this router’s IP address
on that subnet
• if the neighbor’s IP address does not belong to a local subnet the source IP address is this router’s
system IP address
In addition, it is possible to configure the local address with the name of the router interface. To configure
the BGP local address to use the router interface’s IP address information, the local-address command is
used in conjunction with the router interface name (ip-int-name) parameter.
Configuring the router interface as the local address is available in both the config>router>bgp>group
context and the config>router>bgp>group-neighbor context.
When the router interface is configured as the local address, BGP inherits the address from the interface
as follows:
• BGPv4 sessions
The primary IPv4 address configured on the interface is used as the local address.
• BGPv6 sessions
The primary IPv6 address configured on the interface is used as the local address.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
If the corresponding IPv4 or IPv6 address is not configured on the router interface, the BGP sessions that
have this interface set as the local address are kept down until an interface address is configured on the
router interface.
If the primary IPv4 or IPv6 address is changed on the router interface and that interface is being used
as the local address for BGP, then BGP bounces the link. This removes all routes advertised using the
previous address and start advertising those routes again using the newly configured IP address.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Note: Peer tracking should be used with caution. Peer tracking can tear a session down even
if the loss of connectivity turns out to be short-lived. For example, while the IGP protocol is re-
converging. Next-hop tracking, which is always enabled, handles such temporary connectivity
issues much more effectively.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
BGP HA refers to the capability of a router with redundant CPMs to keep established BGP sessions up
whenever a planned or unplanned CPM switchover occurs. A planned CPM switchover can occur during
In-Service Software Upgrade (ISSU). An unplanned CPM switchover can occur if there is an unexpected
failure of the primary CPM.
BGP HA is always enabled on routers with redundant CPMs; it cannot be disabled. BGP HA keeps the
standby CPM in-sync with the primary CPM, with respect to BGP and associated TCP state, so that the
standby CPM is ready to take over for the primary CPM at any time. The primary CPM is responsible for
building and sending the BGP messages to peers but the standby CPM reliably receives a copy of all
outgoing UPDATE messages so that it has a synchronized view of the RIB-OUT.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Note: If a second reset occurs before GR has successfully completed, the router always aborts
the GR helper process, regardless of the failure trigger.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
restart-time is signaled in the GR capability of the peer (but overridden, if necessary, by the locally-
configured helper-override-restart-time command).
LLGR-stale-time is signaled in the LLGR capability of the peer (but overridden, if necessary, by a locally-
configured helper-override-stale-time command).
While the restart-timer is running, the SR OS router acts in the normal GR helper role. When the restart-
timer elapses, the LLGR phase begins. When LLGR starts, the following tasks occur.
1. The LLGR-stale-time starts to count down.
2. Stale routes marked with the NO_LLGR community are immediately deleted.
3. Remaining stale routes are not preferred. The BGP best path selection algorithm is rerun with a new
first step that prefers valid, non-stale LLGR routes over any stale LLGR routes.
4. If a de-preferenced stale route remains, the best and valid NH-reachable path for the NLRI is re-
advertised, with an added LLGR_STALE community, to peers that signaled support for the LLGR
capability. The route may be withdrawn or re-advertised toward peers that do not support LLGR,
subject to the configuration of the advertise-stale-to-all-neighbors command and without-no-export
parameter.
LLGR ends for a particular AFI/SAFI when the LLGR-stale-time reaches zero. At that time, all remaining
stale routes of the AFI/SAFI are deleted. The LLGR-stale-time is not stopped by re-establishment of the
session with the failed peer; it continues until the EoR marker is received for the AFI/SAFI.
Stale routes may be deleted before the expiration of the LLGR-stale-time. If the session with the failed peer
comes back up and one of the following is true, then the stale routes should be deleted immediately.
• The GR or LLGR capability is missing.
• The AFI/SAFI is missing from the LLGR capability.
• The F bit is equal to 0 for the AFI/SAFI.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Note: IP packets sent to an IBGP peer are originated with an IP TTL value of 64. IP packets to
an EBGP peer are originated with an IP TTL value of 1, except if multihop is configured; in that
case, the TTL value is taken from the multihop command.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• mcast-ipv6
• flow-ipv4
• flow-ipv6
• label-ipv4
When a VPRN has a neighbor identified by an IPv6 address, and therefore the transport is IPv6 TCP, the
following MP-BGP address families are supported:
• ipv4
• ipv6
• mcast-ipv4
• mcast-ipv6
• flow-ipv6
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
A router becomes a route reflector whenever it has one or more client IBGP sessions. A client IBGP
session is created with the cluster command, which also indicates the cluster ID of the client. Typical
practice is to use the router ID as the cluster ID, but this is not necessary.
Basic route reflection operation (without Add-Path configured) can be summarized as follows.
• If the best and valid path for an NLRI is learned from a client and disable-client-reflect is not
configured then advertise that route to all clients, non-clients and EBGP peers (as allowed by policy). If
the client that advertised the best and valid path is a neighbor to which the split-horizon command (at
the bgp, group or neighbor level) applies then the route is not advertised back to the sending client. In
the route that is reflected to clients and non-clients:
– the route reflector adds an ORIGINATOR_ID attribute if it did not already exist; the ORIGINATOR_ID
indicates the BGP identifier (router ID) of the client that originated the route
– the route reflector prepends the cluster ID of the client that advertised the route and then the cluster
ID of the client receiving the route (if applicable) to the CLUSTER_LIST attribute, creating the
attribute; if it did not previously exist
• If the best and valid path for an NLRI is learned from a client and disable-client-reflect is configured
then advertise that route to all clients in other clusters, non-clients and EBGP peers (as allowed by
policy). In the route that is reflected to clients in other clusters and non-clients:
– the route reflector adds an ORIGINATOR_ID attribute if it did not already exist; the ORIGINATOR_ID
indicates the BGP identifier (router ID) of the client that originated the route
– the route reflector prepends the cluster ID of the client that advertised the route and then the cluster
ID of the client receiving the route (if applicable) to the CLUSTER_LIST attribute, creating the
attribute; if it did not previously exist
• If the best and valid path for an NLRI is learned from a non-client then advertise that route to all clients
and EBGP peers (as allowed by policy). In the route that is reflected to clients:
– the route reflector adds an ORIGINATOR_ID attribute if it did not already exist; the ORIGINATOR_ID
indicates the BGP identifier (router ID) of the non-client that originated the route
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
– the route reflector prepends the cluster ID of the client receiving the route to the CLUSTER_LIST
attribute, creating the attribute; if it did not previously exist
• If the best and valid path for an NLRI is learned from an EBGP peer then advertise that route to
all clients, non-clients and other EBGP peers (as allowed by policy). The ORIGINATOR_ID and
CLIUSTER_LIST attributes are not added to the route.
• If the best and valid path for an NLRI is locally originated by the RR (for example, it was learned through
means other than BGP), it advertises that route to all clients, non-clients and EBGP peers (as allowed
by policy). The ORIGINATOR_ID and CLUSTER_LIST attributes are not added to the route.
The ORIGINATOR_ID and CLUSTER_LIST attributes allow BGP to detect the looping of a route within the
AS. If any router receives a BGP route with an ORIGINATOR_ID attribute containing its own BGP identifier,
the route is considered invalid. In addition, if a route reflector receives a BGP route with a CLUSTER_LIST
attribute containing a locally configured cluster ID, the route is considered invalid. Invalid routes are not
installed in the route table and not advertised to other BGP peers.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
The minimum BGP message length is 19 bytes and the maximum is 4096 bytes. BGP messages appear
as a stream of bytes to the underlying TCP transport layer, and so there is no direct association between a
BGP message and a TCP segment. One TCP segment can include parts of one or more BGP messages.
Immediately after session setup, the initial value for the maximum TCP segment size that can be sent
toward a specific peer is the minimum of the following:
• the MSS option value in the TCP SYN received from the peer, when the connection was established
• the IP MTU of the initial outgoing interface used to route packets to the peer, minus 40 bytes (IPv4) or
minus 60 bytes (IPv6)
• the TCP MSS configuration value in the BGP configuration of the peer (if there is such a configuration
and it specifies a value other than ip-stack)
As time elapses, the maximum sending segment size can fall below the initial value if path MTU discovery
(PMTUD) is active on the session. PMTUD lowers the segment size when ICMP unreachable or packet-
too-big messages are received. These messages indicate that the IP MTU of the link could not forward the
unfragmentable packet and this IP MTU minus 40 (IPv4) or minus 60 (IPv6) bytes sets the new maximum
segment size value.
• BGP identifier
The router ID of the BGP speaker. In Open messages, the BGP Identifier comes from the router-id
configured under bgp; if that is not configured, then the router-id configured under config>router (or
config>service>vprn) is used and if that too is not configured then the system interface IPv4 address
is used.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Note: A change of the router ID in the config>router>bgp context causes all BGP sessions
to be reset immediately while other changes resulting in a new BGP identifier only take effect
after BGP is shutdown and re-enabled.
• Optional parameters
A list of optional parameters, each encoded as a TLV. The only optional parameter that has been
defined is the optional parameter. The optional parameter supports the process of BGP advertisement
(see BGP advertisement for more information). When a BGP router receives an Open message with an
unsupported optional parameter type it terminates the session. Unless disable-capability-negotiation
is configured, the router always sends an optional parameter in its Open message.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Note: Route refresh messages are not sent for VPN-IPv4 and VPN-IPv6 routes if mp-bgp-
keep is configured; in this situation received VPN-IP routes are kept in the RIB-IN regardless of
whether they match a VRF import policy or not.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
5.5.1 Origin
The ORIGN path attribute indicates the origin of the path information. There are three supported values:
• IGP (0)
• EGP (1)
• Incomplete (2)
When a router originates a VPN-IP prefix (from a non-BGP route), it sets the value of the origin attribute to
IGP. When a router originates an BGP route for an IP prefix by exporting a non-BGP route from the routing
table, it sets the value of the origin attribute to Incomplete. Route policies (BGP import and export) can be
used to change the origin value.
5.5.2 AS path
The AS_PATH attribute provides the list of Autonomous Systems through which the routing information
has passed. The AS_PATH attribute is composed of segments. There can be up to 4 different
types of segments in an AS_PATH attribute: AS_SET, AS_SEQUENCE, AS_CONFED_SET and
AS_CONFED_SEQUENCE. The AS_SET and AS_CONFED_SET segment types result from route
aggregation. AS_CONFED_SEQUENCE contains an ordered list of member AS through which the
route has passed inside a confederation. AS_SEQUENCE contains an ordered list of AS (including
confederation IDs) through which the route has passed on its way to the local AS/confederation.
The AS numbers in the AS_PATH attribute are all 2-byte values or all 4-byte values (if the 4-octet ASN
capability was announced by both peers).
A BGP router always prepends its AS number to the AS_PATH attribute when advertising a route to an
EBGP peer. The specific details for a 7450, 7750, or 7950 router are described below.
• When a route is advertised to an EBGP peer and the advertising router is not part of a confederation.
– The global AS (configured using the autonomous-system command) is prepended to the AS_PATH
if local-as is not configured.
– The local AS followed by the global AS are prepended to the AS_PATH if local-as is configured.
– Only the local AS is prepended to the AS_PATH if local-as no-prepend-global-as is configured.
– Some or all private and reserved AS numbers (64512 to 65535 and 4200000000 to 4294967295
inclusive) can be removed or replaced from the AS_PATH if the remove-private command is
configured.
• When a route is advertised to an EBGP peer outside a confederation.
– The confederation ID is prepended to the AS_PATH if local-as is not configured.
– The local AS followed by the confederation ID are prepended to the AS_PATH if local-as is
configured (the no-prepend-global-as option has no effect in this scenario).
– Member AS numbers are removed from the AS_PATH as described in the section titled BGP
confederations.
– Some or all private and reserved AS numbers (64512 to 65535 and 4200000000 to 4294967295
inclusive) can be removed or replaced from the AS_PATH if the remove-private command is
configured.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
5.5.2.1 AS override
The AS override feature can be used in VPRN scenarios where a customer is running BGP as the PE-CE
protocol and some or all of the CE locations are in the same Autonomous System (AS). With normal BGP,
two sites in the same AS would not be able to reach each other directly because there is an apparent loop
in the AS path.
When override is configured on a PE-CE EBGP session the PE rewrites the customer ASN in the AS path
with the VPRN AS number as the route is advertised to the CE.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• If there are any AS numbers in the AS_PATH attribute that cannot be represented using 2 bytes
(because they have a value greater than 65535) they are substituted with the special value 23456
(AS_TRANS) and an AS4_PATH attribute is added to the route if it is not already present. The
AS4_PATH attribute has the same encoding as the AS_PATH attribute that would be sent to a 4-octet
ASN capable router (that is, each AS number is encoded using 4 octets) but it does not carry segments
of type AS_CONFED_SEQUENCE or AS_CONFED_SET.
• If the AS number in the AGGREGATOR attribute cannot be represented using 2 bytes (because its
value is greater than 65535) it is substituted with the special value 23456 and as AS4_AGGREGATOR
attribute is added to the route if it is not already present. The AS4_AGGREGATOR is the same as the
AGGREGATOR attribute that would be sent to a 4-octet ASN capable router (that is, the AS number is
encoded using 4 octets).
When a 7450, 7750, or 7950 router receives a route with an AS4_PATH attribute it attempts to reconstruct
the full AS path from the AS4_PATH and AS_PATH attributes, regardless of whether disable-4byte-asn is
configured or not. The reconstructed path is the AS path displayed in BGP show commands. If the length
of the received AS4_PATH is N and the length of the received AS_PATH is N+t, then the reconstructed AS
path contains the t leading elements of the AS_PATH followed by all the elements in the AS4_PATH.
5.5.3 Next-hop
The NEXT_HOP attribute indicates the IPv4 address of the BGP router that is the next-hop to reach the
IPv4 prefixes in the NLRI field. If the Update message is advertising routes other than IPv4 unicast routes
the next-hop of these routes is encoded in the MP_REACH_NLRI attribute. For more details, see Multi-
protocol BGP attributes.
The rules for deciding what next-hop address types to accept in a received BGP route and what next-
hop address types to advertise as a BGP next-hop are address family dependent. The following sections
summarize the key details.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
one EBGP peer to be advertised to another EBGP that is in the same IP subnet with an unchanged BGP
next-hop.
When an IPv4 BGP route is re-advertised to an IBGP or confederation EBGP peer, the advertising router
does not modify the BGP next-hop unless one of the following applies.
• The BGP next-hop-self command is applied to the IBGP or confederation EBGP peer. This causes
next-hop-self to be applied to all IPv4 routes advertised to the peer, regardless of the peer type from
which they were received (IBGP, confed-EBGP, or EBGP).
• IPv4 routes are matched and accepted by a route policy entry, and this entry has a next-hop-self
action. This applies next-hop-self as described above to only those routes matched by the policy entry.
• IPv4 routes are matched and accepted by route policy entry, and this entry has a next-hop ip-address
action. This changes the BGP next-hop of only the matched routes to the ip-address, if the ip-address
is an IPv4 address or if the ip-address is an IPv6 address and the necessary conditions exist. The
advertise-ipv6-next-hops command is configured appropriately and the peer opened the session with
the correct RFC 5549 capability.
When an IPv4 BGP route is locally originated and advertised to an IBGP or confederation EBGP peer,
the BGP next-hop is, by default, copied from the next hop of the route that was imported into BGP, with
specified exceptions (for example, black-hole next-hop). When a static route with indirect next hop is re-
advertised as a BGP route, the BGP next-hop is a copy of the indirect address. However, with route table
import policies, BGP can be instructed to take the resolved next hop of the static route as the BGP next-
hop address.
Note: Configuring third-party-nexthop allows an IPv6 route received from one EBGP peer to be
advertised to another EBGP that is in the same IP subnet with an unchanged BGP next-hop.
When an IPv6 BGP route is re-advertised to an IBGP or confederation-EBGP peer, the advertising router
does not modify the BGP next-hop by default; however, this can be changed as follows.
• If the BGP next-hop-self command is applied to the IBGP peer or confederation-EBGP peer, then this
changes the BGP next-hop to the local-address used to setup the session (if the transport to the peer
is IPv6) or to an IPv4-compatible IPv6 address derived from the IPv4 local-address used to setup the
session (if the transport to the peer is IPv4). This command applies to all routes advertised to the peer,
regardless of the peer type from which they were received (IBGP, confed-EBGP, or EBGP).
• If IPv6 routes are matched and accepted by an export policy applied to an IBGP or confederation-EBGP
session, and the matching policy entry has a next-hop-self action, this changes the BGP next-hop
of only the matched routes to the local-address used to setup the session (if the transport to the peer
is IPv6) or to an IPv4-compatible IPv6 address derived from the IPv4 local-address used to setup the
session (if the transport to the peer is IPv4).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• If IPv6 routes are matched and accepted by an export policy applied to an IBGP or confederation-EBGP
session, and the matching policy entry has a next-hop <ip-address> action, this changes the BGP next-
hop of only the matched routes to <ip-address>, but only if <ip-address> is an IPv6 address. If <ip-
address> is an IPv4 address the matched routes are treated as though they were rejected by the policy
entry.
When an IPv6 BGP route is locally originated and advertised to an IBGP or confederation- EBGP peer,
the BGP next-hop is, by default, copied from the next-hop of the route that was imported into BGP, with
specified exceptions (for example, black-hole next-hop). When a static route with indirect next-hop is re-
advertised as a BGP route, the BGP next-hop is a copy of the indirect address, however with route-table-
import policies BGP can be instructed to take the resolved next-hop of the static route as the BGP next-hop
address.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
label swap behavior can be provided. Alternatively, the same behavior can be achieved by configuring
the enable-subconfed-vpn-forwarding command and setting the next-hop-self command toward the
targeted IBGP peer. In either case, next-hop-self results in one of the following outcomes.
• If the IBGP session receiving the reflected route uses IPv4 transport, the BGP next-hop is taken from
the value of the local address used to set up the session.
• If the IBGP session receiving the reflected route has opened an IPv6-transport session by advertising
an extended NH encoding capability with (NLRI AFI=1, NLRI SAFI=128, next-hop AFI=2) and, in the
configuration of the local router, the session is associated with an advertise-ipv6-next-hops vpn-
ipv4 command, then the BGP next-hop is set to the value of the IPv6 local address used to set up the
session. Otherwise, the BGP next-hop is set to the IPv4 address of the system interface.
When a VPN-IPv4 BGP route is reflected from one IBGP peer to another IBGP peer and enable-rr-vpn-
forwarding command is configured and the VPN-IPv4 route is matched and accepted by an export policy
entry with a next-hop <ip-address> action, this changes the BGP next-hop of the matched routes to
<ip-address>, except if <ip-address> is an IPv6 address and the receiving IBGP peer did not advertise
an extended NH encoding capability with (NLRI AFI=1, NLRI SAFI=128, next-hop AFI=2) or, in the
configuration of the local router, the session is not associated with an advertise-ipv6-next-hops vpn-ipv4
command. In this case, the route is treated as though it was rejected by the policy entry.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
When a VPN-IPv6 BGP route is reflected from one IBGP peer to another IBGP peer, the RR does not
modify the next-hop by default. However, if the next-hop-self command is applied to the IBGP peer
receiving the route and the enable-rr-vpn-forwarding command is configured, a next-hop-self command
and label swap behavior can be provided. Alternatively, the same behavior can be achieved by configuring
the enable-subconfed-vpn-forwarding command and setting the next-hop-self command toward the
targeted IBGP peer. In either case, the next-hop-self command results in one of the following outcomes.
• If the IBGP session receiving the reflected route uses IPv4 transport then the BGP next-hop is set to
the IPv4 local-address used to set up the session but encoded as an IPv4-mapped IPv6 address (for
example, with the IPv4 address in the least significant 32 bits of a ::FFFF/96 prefix).
• If the IBGP session receiving the reflected route uses IPv6 transport and it is associated with an
advertise-ipv6-next-hops vpn-ipv6 command, the BGP next-hop is set to the value of the IPv6 local
address used for set up of the session. Otherwise, the BGP next-hop is set to the IPv4 address of the
system interface encoded as an IPv4-mapped IPv6 address (for example, with the IPv4 address in the
least significant 32 bits of a ::FFFF/96 prefix).
When a VPN-IPv6 BGP route is reflected from one IBGP peer to another IBGP peer, enable-rr-vpn-
forwarding command is configured and the VPN-IPv6 route is matched and accepted by an export policy
entry with a next-hop <ip-address> action, this changes the BGP next-hop of the matched routes to <ip-
address> if it is specified as a 128-bit IPv6 address, or to an IPv4-mapped IPv6 address encoding <ip-
address> if it is specified as a 32-bit IPv4 address.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
the BGP next-hop is set to the value of the IPv6 local-address used for setup of the session. Otherwise,
the BGP next-hop is set to the IPv4 address of the system interface
When a label-IPv4 BGP route is reflected from one IBGP peer to another IBGP peer, the RR does not
modify the next-hop by default. However, if the next-hop-self command is applied to the IBGP peer
receiving the route, then this results in one of the following outcomes.
• If the IBGP session receiving the reflected route uses IPv4 transport, then the BGP next-hop is taken
from the value of the local-address used to setup the session.
• If the IBGP session receiving the reflected route opened an IPv6-transport session by advertising
an extended NH encoding capability with (NLRI AFI=1, NLRI SAFI=4, next-hop AFI=2) AND, in the
configuration of the local router, the session is associated with an advertise-ipv6-next-hops label-
ipv4 command then the BGP next-hop is set to the value of the IPv6 local-address used for setup of the
session. Otherwise, the BGP next-hop is set to the IPv4 address of the system interface.
When a label-IPv4 BGP route is reflected from one IBGP peer to another IBGP peer and the label-
IPv4 route is matched and accepted by an export policy entry with a next-hop <ip-address> action, this
changes the BGP next-hop of the matched routes to <ip-address>, except if <ip-address> is an IPv6
address and the receiving IBGP peer did not advertise an extended NH encoding capability with (NLRI
AFI=1, NLRI SAFI=128, next-hop AFI=2) or, in the configuration of the local router, the session is not
associated with an advertise-ipv6-next-hops label-ipv4 command. In this case, the route is treated as
though it was rejected by the policy entry.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• If the ES route next hop is unresolved, the PE that advertised the route is not considered as
candidate for Designated Forwarder (DF) election.
– The imported AD per-ES and AD per-EVI routes are always shown as resolved and valid,
irrespective of the next-hop resolution or the configuration of a next-hop-resolution vpn-family-
policy.
• With DF election, the router always considers the advertising PE a valid candidate, even if the AD
routes next hops are unresolved.
• However, if the AD per-EVI next hop is unresolved, EVPN traffic is not sent to the advertising PE.
This is true for EVPN VPWS or multi-homing aliasing or backup procedures.
• A matching tunnel-table entry can resolve the next-hop of an AD per-EVI route in an EVPN-MPLS
service. A route-table entry (other than a shortcut) can resolve the AD per-EVI route next-hop in
an EVPN-VXLAN service.
– For any other imported EVPN service route, including IP prefix, IPv6 prefix, MAC/IP, Inclusive
Multicast (IMET) and Selective Multicast (SMET) routes, the next hop is resolved as follows.
• In EVPN-MPLS services, the next hop is resolved to a tunnel based on the auto-bind-tunnel
configuration of the importing service.
• In EVPN-VXLAN services, the next hop is resolved to a route in the route-table. That route
cannot be a shortcut route.
• If the next-hop entry in the tunnel-table or route-table that resolves the EVPN service route is
rejected by the user-configured next-hop-resolution vpn-family-policy, the BGP next hop is
unresolved and all the EVPN routes with that next hop are considered invalid.
• The following procedures apply to the next-hop resolution of label-unicast IPv4 and label-unicast IPv6
routes.
– When a BGP-LU route is received with an IPv4-mapped IPv6 address as the next-hop, BGP next-
hop resolution is based on the embedded IPv4 address and this IPv4 address is matched to IPv4
routes or IPv4 tunnels, depending on the configuration. The IPv4-mapped IPv6 address is never
interpreted as an IPv6 address to be compared to IPv6 routes or IPv6 tunnels.
– If the BGP-LU route is received by a control-plane-only RR with the disable-route-table-install and
rr-use-route-table commands configured, the order of resolution is as follows:
• the local route
• the longest prefix-match static route, excluding default static routes
Use this route to resolve the BGP next-hop if it is a static route with blackhole next-hop. For other
types of static routes, use this route to resolve the next-hop only if allow-static is configured. If it
is another type of static route, use it to resolve the next-hop only if allow-static is configured.
• the longest prefix-match IGP route
– If a label-unicast IPv4 route or label-unicast IPv6 route with a label (other than explicit-null) is
received from an IBGP or EBGP peer and the router is not an RR with the rr-use-route-table
command configured, the order of resolution is as follows:
• the local route
• the longest prefix-match static route, excluding default static routes
Use this route to resolve the BGP next-hop if it is a static route with a blackhole next-hop. If it is
another type of static route, use it to resolve the next-hop only if allow-static is configured.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• a tunnel, based on the transport-tunnel resolution-filter options for family label-ipv4 or label-
ipv6 (depending on the situation); for more information, see Next-hop resolution of BGP labeled
routes to tunnels
– If a label-unicast IPv6 route with an IPv6 explicit-null label is received from an IBGP or EBGP peer
and the router is not an RR with the rr-use-route-table command configured, the order of resolution
is as follows:
• the local route
• the longest prefix-match static route, excluding default static routes
Use this route to resolve the BGP next-hop if it is a static route with a a blackhole next-hop. If it is
another type of static route, use it to resolve the next-hop only if allow-static is configured
• a tunnel, based on the transport-tunnel resolution-filter options for family label-ipv4; for more
information, see Next-hop resolution of BGP labeled routes to tunnels
• if configure>router>bgp>next-hop-resolution>labeled-routes>use-bgp-routes>label-ipv6-
explicit-null is enabled and if the longest prefix length route that matches the next-hop is a BGP
IPv4 unlabeled, BGP IPv6 unlabeled, or other 6PE route with an explicit-null label, then use that
route, subject to the following conditions:
the resolving route cannot be a leaked route
an unlabeled IPv4 route or IPv6 route is ineligible to resolve the next-hop of a label-unicast IPv6
route if the unlabeled route has any of its own BGP next-hops resolved by an IGP route or a
6over4 route
the label-unicast IPv6 route can be recursively resolved by other label-unicast IPv6 routes with
explicit-null so that the final route has up to four levels of recursion
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
This refers to LDP FEC prefixes imported into the tunnel table. For resolution purposes, BGP selects
the LDP FEC that is the longest-prefix-match (LPM) of the BGP next-hop address.
• rsvp
This refers to RSVP tunnels in tunnel-table. This option allows BGP to use the best metric RSVP LSP
to the address of the BGP next-hop. This address can correspond to the system interface or to another
loopback interface of the remote BGP router. In the case of multiple RSVP LSPs with the same lowest
metric, BGP selects the LSP with the lowest tunnel-id.
• sr-isis
This refers to segment routing tunnels (shortest path) to destinations reachable by the IS-IS protocol.
This option allows BGP to use the segment routing tunnel in tunnel-table submitted by the lowest
preference IS-IS instance or, in case of a tie, the lowest numbered IS-IS instance.
• sr-ospf
This refers to segment routing tunnels (shortest path) to destinations reachable by the OSPF protocol.
This option allows BGP to use the segment routing tunnel in the tunnel table submitted by the lowest
preference OSPF instance or (in case of a tie) the lowest numbered OSPF instance.
• sr-policy
This refers to segment routing policies that are statically configured in the local router or learned via
BGP routes (AFI 1/SAFI 73). For BGP to resolve the next-hop of an IPv4 route using an sr-policy the
highest numbered color-extended community attached to the IPv4 route must match the color of the SR
policy and if the CO bits of this color-extended community have the value 00 the BGP next-hop of the
route must exactly match the endpoint of the SR policy.
• sr-te
This refers to traffic engineered (TE) segment routing tunnels. This option allows BGP to use the best
metric SR-TE tunnel to the address of the BGP next-hop. In the case of multiple SR-TE tunnels with the
same lowest metric, BGP selects the tunnel with the lowest tunnel-id.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
This refers to IPv4 tunnels created by receiving BGP label-unicast IPv4 routes for /32 IPv4 prefixes.
• ldp
This refers to /32 and shorter length LDP FEC prefixes imported into the tunnel table. For resolution
purposes, BGP selects the LDP FEC that is the longest-prefix-match (LPM) of the BGP next-hop
address.
• rsvp
This refers to RSVP tunnels in tunnel-table. This option allows BGP to use the best metric RSVP LSP
to the address of the BGP next-hop. This address can correspond to the system interface or to another
loopback interface of the remote BGP router. In the case of multiple RSVP LSPs with the same lowest
metric, BGP selects the LSP with the lowest tunnel-id.
• sr-isis
This refers to segment routing tunnels (shortest path) to destinations reachable by the IS-IS protocol.
This option allows BGP to use the segment routing tunnel in tunnel-table submitted by the lowest
preference IS-IS instance or (in case of a tie) the lowest numbered IS-IS instance.
• sr-ospf
This refers to segment routing tunnels (shortest path) to destinations reachable by the OSPF protocol.
This option allows BGP to use the segment routing tunnel in tunnel-table submitted by the lowest
preference OSPF instance or (in case of a tie) the lowest numbered OSPF instance.
• sr-policy
This refers to segment routing policies that are statically configured in the local router or learned via
BGP routes (AFI 1/SAFI 73). For BGP to resolve the next-hop of an IPv4 route using an sr-policy the
highest numbered color-extended community attached to the IPv4 route must match the color of the SR
policy and if the CO bits of this color -extended community have the value 00 the BGP next-hop of the
route must exactly match the endpoint of the SR policy.
• sr-te
This refers to TE segment routing tunnels. This option allows BGP to use the best metric SR-TE tunnel
to the address of the BGP next-hop. In the case of multiple SR-TE tunnels with the same lowest metric,
BGP selects the tunnel with the lowest tunnel-id.
config>router>bgp>next-hop-res
labeled-routes
transport-tunnel
[no] family {label-ipv4|label-ipv6|vpn}
resolution {any | disabled | filter}
resolution-filter
[no] bgp
[no] ldp
[no] rsvp
[no] sr-isis
[no] sr-ospf
[no] sr-te
[no] udp
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
The transport-tunnel context provides separate control for the different types of BGP label routes: label-
IPv4, label-IPv6, and VPN routes (which includes both VPN-IPv4 and VPN-IPv6 routes). By default, all
labeled routes resolve to LDP (even if the preceding CLI commands are not configured in the system).
If the resolution option is set to disabled, the default binding to LDP tunnels resumes. If resolution is set
to any, the supported tunnel type selection is based on TTM preference. The order of preference of TTM
tunnels is: RSVP, SR-TE, LDP, segment routing OSPF, segment routing IS-IS, and UDP.
The rsvp option instructs BGP to search for the best metric RSVP LSP to the address of the BGP next-
hop. The address can correspond to the system interface or to another loopback used by the BGP instance
on the remote node. The LSP metric is provided by MPLS in the tunnel table. In the case of multiple RSVP
LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel ID.
The ldp option instructs BGP to search for an LDP LSP with a FEC prefix corresponding to the address of
the BGP next-hop.
The bgp option instructs BGP to search for a BGP tunnel in TTM with a prefix matching the address of the
BGP next-hop. A label-unicast IPv4 route cannot be resolved by another label-unicast IPv4 or IPv6 route. A
label-unicast IPv6 route cannot be resolved by another label-unicast IPv6 route, but it can be resolved by a
label-unicast IPv4 route.
When the sr-isis or sr-ospf option is enabled, an SR tunnel to the BGP next-hop is selected in the TTM
from the lowest preference IS-IS or OSPF instance. If many instances have the same lowest preference,
the lowest numbered IS-IS or OSPF instance is chosen.
The sr-te value launches a search for the best metric SR-TE LSP to the address of the BGP next-hop.
The LSP metric is provided by MPLS in the tunnel table. In the case of multiple SR-TE LSPs with the same
lowest metric, BGP selects the LSP with the lowest tunnel-id.
The udp value instructs BGP to look for an MPLSoUDP tunnel to the address of the BGP next-hop.
If one or more explicit tunnel types are specified using the resolution-filter option, then only these tunnel
types are selected again following the TTM preference. The resolution command must be set to filter to
activate the list of tunnel-types configured in resolution-filter.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
5.5.4 MED
The Multi-Exit Discriminator (MED) attribute is an optional attribute that can be added to routes advertised
to an EBGP peer to influence the flow of inbound traffic to the AS. The MED attribute carries a 32-bit metric
value. A lower metric is better than a higher metric when MED is compared by the BGP decision process.
Unless the always-compare-med command is configured MED is compared only if the routes come from
the same neighbor AS. By default, if a route is received without a MED attribute it is evaluated by the
BGP decision process as though it had a MED containing the value 0, but this can be changed so that a
missing MED attribute is handled the same as a MED with the maximum value. SR OS always removes
the received MED attribute when advertising the route to an EBGP peer.
Note: When BGP routes are leaked into a target BGP RIB, they are not grouped (in a
deterministic MED context) with routes learned by that target RIB, even if the neighbor AS
happens to be the same.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• The COMMUNITY attribute contains all of the communities from all of the contributing routes unless the
discard-component-communities option is configured for the aggregate route. It also contains the
communities associated directly with the aggregate route itself (up to 12 per aggregate route).
• No MED attribute is included by default.
Note: SR OS does not require all the contributing routes to have the same MED value.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
When a route carries this community, it indicates that the route should be installed into the FIB with a
blackhole next-hop.
Standard communities can be added to or removed from BGP routes using BGP import and export
policies. When a BGP route is locally originated by exporting a static or aggregate route into BGP, and
the static or aggregate route has one or more standard communities, these community values are
automatically added to the BGP route. This may affect the advertisement of the locally originated route if
one of the well-known communities is associated with the static or aggregate route.
To remove all the standard communities from all routes advertised to a BGP peer, use the disable-
communities standard command.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Note: While it may not make sense to add specific types of extended communities to routes of
certain address families, SR OS allows such actions.
To remove all the extended communities from all routes advertised to a BGP peer, use the disable-
communities extended command.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
To advertise reachable routes of a particular AFI/SAFI a BGP router includes a single MP_REACH_NLRI
attribute in the UPDATE message. The MP_REACH_NLRI attribute encodes the AFI, the SAFI, the BGP
next-hop and all the reachable NLRI. To withdraw routes of a particular AFI/SAFI a BGP router includes
a single MP_UNREACH_NLRI attribute in the UPDATE message. The MP_UNREACH_NLRI attribute
encodes the AFI, the SAFI and all the withdrawn NLRI. While it is valid to advertise and withdraw IPv4
unicast routes using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes, SR OS always uses the
IPv4 fields of the UPDATE message to convey reachable and unreachable IPv4 unicast routes.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Note: The import command can reference a policy before it has been created (as a policy-
statement).
When an IP route is rejected by an import policy it is still maintained in the RIB-IN so that a policy change
can be made later on without requiring the peer to re-send all its RIB-OUT routes. This is sometimes called
soft reconfiguration inbound and requires no special configuration in SR OS.
When a VPN route is rejected by an import policy or not imported by any services it is deleted from the
RIB-IN. For VPN-IPv4 and VPN-IPv6 routes this behavior can be changed by configuring the mp-bgp-
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
keep command; this option maintains rejected VPN-IP routes in the RIB-IN so that a Route Refresh
message does not have to be issued when there is an import policy change.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
9. Select the route with the shortest AS path. AS numbers in AS_CONFED_SEQ and
AS_CONFED_SET elements do not count toward the AS path length. This step is skipped if as-path-
ignore is configured for the address family.
10. Select the route with the lowest Origin (IGP<EGP<Incomplete).
11. Select the route with the lowest MED. Only compare MED for non-imported routes that have the same
neighbor AS by default. A missing MED attribute is considered equivalent to a MED value 0 by default.
Defaults can be changed by using the always-compare-med command.
12. Select the route with the lowest owner type (BGP-label < BGP < BGP-VPN).
13. Prefer routes learned from EBGP peers over routes learned from IBGP and confed-EBGP peers.
14. Select the route with the lowest route-table or tunnel-table cost to the NEXT_HOP. This step is
skipped if ignore-nh-metric is configured, or if the routes are associated with different RIBs. For VPN-
IP routes received by a router without any configured VPRN services, next-hop cost is determined
from the route-table cost.
15. Select the route with the lowest next-hop type. Resolutions made in the route table are preferred to
resolutions made in the tunnel-table. This step is skipped if ignore-nh-metric is configured, or if the
routes are associated with different RIBs.
16. Select the route received from the peer with the lowest router ID; this comes from the
ORIGINATOR_ID attribute (if present) or the BGP identifier of the peer (received in its OPEN
message). If ignore-router-id is configured, keep the current best path and skip the remaining steps.
17. Select the route with the shortest CLUSTER_LIST length.
18. Select the route received from the peer with the lowest IP address.
19. For VPN-IP routes imported into a VPRN, select the route with the lowest route-distinguisher value.
If a BGP RIB has multiple BGP paths for the same IPv4 or IPv6 prefix that qualify as the best path up to a
specific point in the comparison process, then a specified number of these multi-paths can be submitted
to the common IP route table. This is called BGP multi-path and must be explicitly enabled using one or
more commands in the multi-path context. These commands specify the maximum number of BGP paths,
including the overall best path, that each BGP RIB can submit to the route table for any particular IPv4
or IPv6 prefix. If ECMP, with a limit of n, is enabled in the base router instance, then up to n paths are
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
selected for installation in the IP FIB. In the data-path, traffic matching the IP route is load-shared across
the ECMP next hops based on a per-packet hash calculation.
By default, the hashing is not sticky, meaning that when one or more of the ECMP BGP next hops fail, all
traffic flows matching the route are potentially moved to new BGP next hops. If required, a BGP route can
be marked (using the sticky-ecmp action in route policies) for sticky ECMP behavior so that BGP next
hop failures are handled by moving only the affected traffic flows to the remaining next hops as evenly as
possible. If new ECMP BGP next hops become available for a marked BGP, then route flows are moved as
evenly as possible onto the resultant set of next hops.
Each sticky ECMP route uses 64 distribution buckets to apportion flows onto the available next hops.
Figure 22: Sticky ECMP flow distribution as next hops are removed part 1, Figure 23: Sticky ECMP flow
distribution as next hops are removed part 2, and Figure 24: Sticky ECMP flow distribution as next hops
are removed part 3 provide an example of the distribution of flows over multiple BGP next hops as next
hops are removed.
Figure 22: Sticky ECMP flow distribution as next hops are removed part 1
Figure 23: Sticky ECMP flow distribution as next hops are removed part 2
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Figure 24: Sticky ECMP flow distribution as next hops are removed part 3
Table 6: Sticky ECMP flow distribution as next hops are removed for 1.1.1.1/32 lists the sticky ECMP flow
distribution as next hops are removed for 1.1.1.1/32.
Table 6: Sticky ECMP flow distribution as next hops are removed for 1.1.1.1/32
00 1 00 1 00 1
01 2 01 2 01 1
02 3 02 1 02 1
03 1 03 1 03 1
04 2 04 2 04 1
05 3 05 2 05 1
06 1 06 1 06 1
07 2 07 2 07 1
08 3 08 1 08 1
09 1 09 1 09 1
10 2 10 2 10 1
11 3 11 2 11 1
12 1 12 1 12 1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
13 2 13 2 13 1
14 3 14 1 14 1
15 1 15 1 15 1
16 2 16 2 16 1
17 3 17 2 17 1
18 1 18 1 18 1
19 2 19 2 19 1
20 3 20 1 20 1
21 1 21 1 21 1
22 2 22 2 22 1
23 3 23 2 23 1
24 1 24 1 24 1
25 2 25 2 25 1
26 3 26 1 26 1
27 1 27 1 27 1
28 2 28 2 28 1
29 3 29 2 29 1
30 1 30 1 30 1
31 2 31 2 31 1
32 3 32 1 32 1
33 1 33 1 33 1
34 2 34 2 34 1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
35 3 35 2 35 1
36 1 36 1 36 1
37 2 37 2 37 1
38 3 38 1 38 1
39 1 39 1 39 1
40 2 40 2 40 1
41 3 41 2 41 1
42 1 42 1 42 1
43 2 43 2 43 1
44 3 44 1 44 1
45 1 45 1 45 1
46 2 46 2 46 1
47 3 47 2 47 1
48 1 48 1 48 1
49 2 49 2 49 1
50 3 50 1 50 1
51 1 51 1 51 1
52 2 52 2 52 1
53 3 53 2 53 1
54 1 54 1 54 1
55 2 55 2 55 1
56 3 56 1 56 1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
57 1 57 1 57 1
58 2 58 2 58 1
59 3 59 2 59 1
60 1 60 1 60 1
61 2 61 2 61 1
62 3 62 1 62 1
63 1 63 1 63 1
Figure 25: Sticky ECMP flow distribution as next hops are added part 1, Figure 26: Sticky ECMP flow
distribution as next hops are added part 2, and Figure 27: Sticky ECMP flow distribution as next hops are
added part 3 provide an example of the distribution of flows over multiple BGP next hops as next hops are
added.
Figure 25: Sticky ECMP flow distribution as next hops are added part 1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Figure 26: Sticky ECMP flow distribution as next hops are added part 2
Figure 27: Sticky ECMP flow distribution as next hops are added part 3
Table 7: Sticky ECMP flow distribution as next hops are added for 1.1.1.1/32 lists the sticky ECMP flow
distribution as next hops are added for 1.1.1.1/32.
Table 7: Sticky ECMP flow distribution as next hops are added for 1.1.1.1/32
00 1 00 1 00 1
01 1 01 2 01 2
02 1 02 1 02 3
03 1 03 2 03 2
04 1 04 1 04 1
05 1 05 2 05 3
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
06 1 06 1 06 1
07 1 07 2 07 2
08 1 08 1 08 3
09 1 09 2 09 2
10 1 10 1 10 1
11 1 11 2 11 3
12 1 12 1 12 1
13 1 13 2 13 2
14 1 14 1 14 3
15 1 15 2 15 2
16 1 16 1 16 1
17 1 17 2 17 3
18 1 18 1 18 1
19 1 19 2 19 2
20 1 20 1 20 3
21 1 21 2 21 2
22 1 22 1 22 1
23 1 23 2 23 3
24 1 24 1 24 1
25 1 25 2 25 2
26 1 26 1 26 3
27 1 27 2 27 2
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
28 1 28 1 28 1
29 1 29 2 29 3
30 1 30 1 30 1
31 1 31 2 31 2
32 1 32 1 32 3
33 1 33 2 33 2
34 1 34 1 34 1
35 1 35 2 35 3
36 1 36 1 36 1
37 1 37 2 37 2
38 1 38 1 38 3
39 1 39 2 39 2
40 1 40 1 40 1
41 1 41 2 41 3
42 1 42 1 42 1
43 1 43 2 43 2
44 1 44 1 44 3
45 1 45 2 45 2
46 1 46 1 46 1
47 1 47 2 47 3
48 1 48 1 48 1
49 1 49 2 49 2
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
50 1 50 1 50 3
51 1 51 2 51 2
52 1 52 1 52 1
53 1 53 2 53 3
54 1 54 1 54 1
55 1 55 2 55 2
56 1 56 1 56 3
57 1 57 2 57 2
58 1 58 1 58 1
59 1 59 2 59 3
60 1 60 1 60 1
61 1 61 2 61 2
62 1 62 1 62 3
63 1 63 2 63 2
A BGP route to an IPv4 or IPv6 prefix is a candidate for installation as an ECMP next hop only if it meets
all of the following criteria.
• The multi-path route must be the same type of route as the best path (same AFI/SAFI and, in some
cases, same next-hop resolution method).
• The multi-path route must be tied with the best path for all criteria of greater significance than next-hop
cost, except for criteria that are configured to be ignored.
• If the best path selection reaches the next-hop cost comparison, the multi-path route must have the
same next-hop cost as the best route unless the unequal-cost option is configured.
• The multi-path route must not have the same BGP next hop as the best path or any other multi-path
route.
• The multi-path route must not cause the ECMP limit of the routing instance to be exceeded (configured
using the ecmp command with a value in the range 1 to 64).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• The multi-path route must not cause the applicable max-paths limit to be exceeded. If the best path
is an EBGP learned route and the ebgp option is used, the ebgp-max-paths limit overrides the max-
paths limit. If the best path is an IBGP-learned route and the ibgp option is used, the ibgp-max-paths
limit overrides the max-paths limit. All path limits are configurable up to a maximum of 64. Multi-path is
disabled if the value is set to 1.
• The multi-path route must have the same neighbor AS in its AS path as the best path if the restrict
same-neighbor-as option is configured. By default, any path with the same AS path length as the best
path (regardless of neighbor AS) is eligible for multi-path.
• The route must have the same AS path as the best path if the restrict exact-as-path option is
configured. By default, any path with the same AS path length as the best path (regardless of the actual
AS numbers) is eligible for multi-path.
SR OS also supports IBGP multi-path. In some topologies, a BGP next hop is resolved by an IP route that
has multiple ECMP next hops. When ibgp-multipath is not configured, only one of the ECMP next hops
is programmed as the next hop of the BGP route in the IOM. When ibgp-multipath is configured, the IOM
attempts to use all the ECMP next hops of the resolving route in the forwarding state. Although the name of
the ibgp-multipath command implies that it is specific to IBGP-learned routes, this is not the case. It also
applies to routes learned from any multi-hop BGP session including routes learned from multi-hop EBGP
peers.
Be aware that multi-path and ibgp-multipath are not mutually exclusive and work together. The first
context enables ECMP load-sharing across different BGP next hops (corresponding to different BGP
routes) while the ibgp-multipath enables ECMP load-sharing across the next hops of IP routes that
resolve the BGP next hops.
Finally, ibgp-multipath does not control traffic load sharing toward a BGP next hop that is resolved by a
tunnel, as when dealing with BGP shortcuts or labeled routes (VPN-IP, label-IPv4, or label-IPv6). When a
BGP next hop is resolved by a tunnel that supports ECMP, the load-sharing of traffic across the ECMP next
hops of the tunnel is automatic.
SR OS supports direct resolution of a BGP next hop to multiple RSVP-TE or SR-TE tunnels. In addition,
a BGP next hop can be resolved by multiple LDP ECMP next hops that each correspond to a separate
LDP-over-RSVP or LDP-over-SRTE tunnel. It is also possible for a BGP next hop to be resolved by an IGP
shortcut route that has multiple RSVP-TE or SR-TE tunnels as its ECMP next hops.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
can be added to routes received from a directly connected (single hop) EBGP peer, potentially replacing
the received Extended Community. This is accomplished using the add-to-received-ebgp command,
which is available in group and neighbor configuration contexts.
When a route with a link-bandwidth extended community is advertised to an EBGP peer, the link-bandwidth
extended community is removed by default. However, transitivity across an AS boundary can be allowed
by configuring the send-to-ebgp command.
When a route with a link-bandwidth extended community is advertised to a peer using next-hop-self,
the Extended Community is usually removed if it was not added locally (that is, by policy or add-to-
received-ebgp command). However, in the special case that a route is readvertised (with next-hop-
self) toward a peer covered by the scope of an aggregate-used-paths command, and the re-advertising
router has installed multiple ECMP paths toward the destination each associated with a link-bandwidth
extended community, the route is readvertised with a link-bandwidth extended community encoding the
total bandwidth of all the used multi-paths.
The link-bandwidth extended community associated with a BGP route can be displayed using the show
router bgp routes command. For the bandwidth value, the system automatically converts the binary value
in the extended community to a decimal number in units of Mb/s (1 000 000 b/s).
Weighted ECMP across the BGP next-hops of an IP BGP route is supported in combination with ECMP at
the level of the route or tunnel that resolves one or more of the ECMP BGP next-hops. This ECMP at the
resolving level can also be weighted ECMP when the following conditions all apply:
• the BGP next-hop is resolved by an IP route (OSPF, IS-IS, or static) with MPLS LSP ECMP next-hops
• ibgp-multipath is configured under BGP
• config>router>weighted-ecmp is configured
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• The selective-label-ipv4-install command does not prevent the installation of the route.
If multipath and ECMP are configured so that they apply to label IPv4 routes, then a BGP tunnel can be
installed in the tunnel table with multiple ECMP next-hops, each one corresponding to a path through a
different BGP next-hop. The multipath selection process described in BGP route installation in the route
table also applies to this case.
IPv4 IPv4 route with next-hop A IPv4 route with next-hop B resolved Yes
resolved by an IPv4 route or any by an IPv4 route or any shortcut
shortcut tunnel tunnel
IPv4 Label-IPv4 route with next-hop A Label-IPv4 route with next-hop B Yes, but if the label-IPv4
resolved by any transport tunnel resolved by any transport tunnel routes are label-per-
prefix, the ingress card
must be IOM3 or better
for PIC
IPv4 Label-IPv4 route with next-hop A Label-IPv4 route with next-hop B Yes, but if the label-IPv4
resolved by a local route resolved by a local route routes are label-per-
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
IPv4 Label-IPv4 route with next-hop A Label-IPv4 route with next-hop B Yes, but if the label-IPv4
resolved by a static route resolved by a static route routes are label-per-
prefix, the ingress card
must be IOM3 or better
for PIC
IPv6 IPv6 route with next-hop A IPv6 route with next-hop B resolved Yes
resolved by an IPv6 route by an IPv6 route
IPv6 Label-IPv6 route with next-hop A Label-IPv6 route with next-hop B Yes, but if the label-IPv6
resolved by any transport tunnel resolved by any transport tunnel routes are label-per-
prefix, the ingress card
must be IOM3 or better
for PIC
IPv6 Label-IPv6 route with next-hop A Label-IPv6 route with next-hop B Yes, but if the label-IPv6
resolved by a local route resolved by a local route routes are label-per-
prefix, the ingress card
must be IOM3 or better
for PIC
IPv6 Label-IPv6 route with next-hop A Label-IPv6 route with next-hop B Yes, but if the label-IPv6
resolved by a static route resolved by a static route routes are label-per-
prefix, the ingress card
must be IOM3 or better
for PIC
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Different BGP routes for the same IP prefix can be associated with different QPPB information. If these
BGP routes are combined in support of ECMP or BGP fast reroute then the QPPB information becomes
next-hop specific. If these LOC-RIB routes are combined in support of ECMP or BGP fast reroute then
the QPPB information becomes next-hop specific. This means that in destination QPPB mode the QoS
assigned to a packet depends on the BGP next-hop that is selected for that particular packet by the ECMP
hash or fast reroute algorithm. In source QPPB mode the QoS assigned to a packet comes from the first
BGP next-hop of the IP route matching the source address.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
If the policy accounting is enabled on a spoke SDP or R-VPLS interface, all FPs in the system should have
a reservation for each of the above resources, otherwise the show router interface policy-accounting
command output reports that the statistics are possibly incomplete.
Through route policy or configuration mechanisms, a BGP or static route for an IP prefix can have a source
class index (1 to 255), a destination class index (1 to 255) or both. When an ingress packet on a policy
accounting-enabled interface [I1] is forwarded by the IOM and its destination address matches a BGP or
static route with a destination class index [D], and [D] is listed in the relevant policy accounting template,
then the packets-forwarded and IP-bytes-forwarded counters for [D] on interface [I1] are incremented
accordingly. If [D] is also associated with a policer (FP4 only) the packet is also subjected to rate limiting
as discussed above. The policer statistics displayed by the show router interface policy-accounting
command include Layer 2 encapsulation and is different from the destination-class byte-level statistics.
When an ingress packet on a policy accounting-enabled interface [I2] is forwarded by the IOM and its
source address matches a BGP or static route with a source class index [S], and [S] is listed in the relevant
policy accounting template, the packets-forwarded and IP-bytes-forwarded counters for [S] on interface [I2]
are incremented accordingly. Policing based on the source class is unsupported.
It is possible that different BGP or static routes for the same IP prefix (through different next hops) are
associated with different class information. If these routes are combined in support of ECMP or fast reroute
then the destination class of a packet depends on the next hop that is selected for that particular packet by
the ECMP hash or fast reroute algorithm. If the source address of a packet matches a route with multiple
next hops its source class is derived from the first next hop of the matching route.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• The FOM value at the last time of update can be displayed using the show router bgp damping detail
command. The time of last update can be up to 640 seconds ago; SR OS does not calculate the current
FOM every time the show command is entered.
• When the FOM reaches the suppress limit, which is 3000 by default, but can be changed to any value
between 1 and 20000 in a non-default damping profile, the route is suppressed, meaning it is not used
locally and not advertised to peers. The route remains suppressed until either the FOM exponentially
decays to a value less than or equal to the reuse threshold or the max-suppress time is reached.
By default, the reuse threshold is 750 and the max-suppress time is 60 minutes, but these can be
changed in a non-default damping profile: reuse can have a value between 1 and 20000 and max-
suppress can have a value between 1 and 720 minutes.
Note: The export command can reference a policy before it has been created (as a policy-
statement).
The most common uses for BGP export policies are as follows.
• To locally originate a BGP route by exporting (or redistributing) a non-BGP route that is installed in the
route table and actively used for forwarding. The non-BGP route is most frequently a direct, static or
aggregate route (exporting IGP routes into BGP is generally not recommended).
• To block the advertisement of specific BGP routes toward specific BGP peers. The routes may be
blocked on the basis of IP prefix, communities, and so on.
• To modify the attributes of BGP routes advertised to specific BGP peers. The following path attribute
modifications are possible using BGP export policies.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• MVPN-IPv6
In SR OS the send/receive capability for ORF type 3 is configurable (with the send-orf and accept-orf
commands) but the setting applies to all supported address families.
SR OS support for ORF type 3 allows a PE router that imports VPN routes with a particular set of Route
Target Extended Communities to indicate to a peer (for example a route reflector) that it only wants
to receive VPN routes that contain one or more of these Extended Communities. When the PE router
wants to inform its peer about a new RT Extended Community it sends a Route Refresh message to the
peer containing an ORF type 3 entry instructing the peer to add a permit entry for the 8-byte extended
community value. When the PE router wants to inform its peer about a RT Extended Community that is no
longer needed it sends a Route Refresh message to the peer containing an ORF type 3 entry instructing
the peer to remove the permit entry for the 8-byte extended community value.
In SR OS the type-3 ORF entries that are sent to a peer can be generated dynamically (if no Route Target
Extended Communities are specified with the send-orf command) or else specified statically. Dynamically
generated ORF entries are based on the route targets that are imported by all locally-configured VPRNs.
A router that has installed ORF entries received from a peer can still apply BGP export policies to the
session. If the evaluation of a BGP export policy results in a reject action for a VPN route that matches a
permit ORF entry the route is not advertised (that is, the export policy has the final word).
Note: The SR OS implementation of ORF filtering is very efficient. It takes less time to filter a
large number of VPN routes with ORF than it does to reject non-matching VPN routes using a
conventional BGP export policy.
Despite the advantages of ORF compared to manually configured BGP export policies a better technology,
when it comes to dynamic filtering based on Route Target Extended Communities, is RT Constraint. RT
Constraint is discussed further in the next section.
Note: RT-constrain and Extended Community-based ORF are similar to the extent that they both
allow a router to signal to a peer the Route Target Extended Communities they want to receive in
VPN routes from that peer. But RT-constrain has distinct advantages over Extended Community-
based ORF: it is more widely supported, it is simpler to configure, and its distribution scope is not
limited to a direct peer.
In SR OS the capability to exchange RTC routes is advertised when the route-target keyword is added to
the relevant family command. RT-constrain is supported on EBGP and IBGP sessions of the base router
instance. On any particular session either ORF or RT-constrain may be used but not both; if RT-constrain
is configured the ORF capability is not announced to the peer.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
When RT-constrain has been negotiated with one or more peers SR OS automatically originates and
advertises to these peers one /96 RTC route (the origin AS and Route Target Extended Community are
fully specified) for every route target imported by a locally-configured VPRN or BGP-based L2 VPN; this
includes MVPN-specific route targets.
SR OS also supports a group/neighbor level default-route-target command that causes routers to
generate and send a 0:0:0/0 default RTC route to one or more peers. Sending the default RTC route to a
peer conveys a request to receive all VPN routes from that peer. The default-route-target command is
typically configured on sessions that a route reflector has with its PE clients. A received default RTC route
is never propagated to other routers.
The advertisement of RTC routes by a route reflector follows special rules that are described in RFC 4684.
These rules are needed to ensure that RTC routes for the same NLRI that are originated by different PE
routers in the same Autonomous System are properly distributed within the AS.
When a BGP session comes up, and RT-constrain is enabled on the session (both peers advertised the
MP-BGP capability), routers delay sending any VPN-IPv4 and VPN-IPv6 routes until either the session has
been up for 60 seconds or the End-of-RIB marker is received for the RT-constrain address family. When
the VPN-IPv4 and VPN-IPv6 routes are sent they are filtered to include only those with a Route Target
Extended Community that matches an RTC route from the peer. VPN-IP routes matching an RTC route
originated in the local AS are advertised to any IBGP peer that advertises a valid path for the RTC NLRI.
In other words, route distribution is not constrained to only the IBGP peer advertising the best path. On the
other hand, VPN-IP routes matching an RTC route originated outside the local AS are only advertised to
the EBGP or IBGP peer that advertises the best path.
Note: SR OS does not support an equivalent of BGP-Multipath for RT-Constrain routes. There is
no way to distribute VPN routes across more than one ‛almost’ equal set of inter-AS paths.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• MCAST-VPN-IPv6
• MDT-SAFI
• MVPN-IPv4
• MVPN-IPv6
• VPN-IPv4
• VPN-IPv6
In many cases, the default MRAI is appropriate for all address families (or at least those not included in the
preceding list) when it applies to UPDATE messages that advertise reachable NLRI, but it is not the best
option for UPDATE messages that advertise unreachable NLRI (route withdrawals). Fast re-convergence
after some types of failures requires route withdrawals to propagate to other routers as quickly as possible
so that they can calculate and start using new best paths, which would be impeded by the effect of the
MRAI timer at each router hop. This is facilitated by the rapid-withdrawal configuration command.
When rapid-withdrawal is configured, UPDATE messages containing withdrawn NLRI are sent
immediately to a peer without waiting for the MRAI timer to expire. UPDATE messages containing
reachable NLRI continue to wait for the MRAI timer to expire, or for a rapid-update trigger, if it applies.
When rapid-withdrawal is enabled, it applies to all address families.
When there is a change to a labeled-unicast route that requires reprogramming of the label operations
in the dataplane, these IOM updates are not made until the changed route is advertised to a peer, which
depends on MRAI. Lowering the MRAI value or using rapid-update improves the speed of this operation.
5.6.3.5 Advertise-inactive
BGP does not allow a route to be advertised unless it is the best path in the RIB and an export policy
allows the advertisement.
In some cases, it may be useful to advertise the best BGP path to peers despite the fact that is inactive.
For example, because there are one or more preferred non-BGP routes to the same destination and one
of these other routes is the active route. One way SR OS supports this flexibility is using the advertise-
inactive command; other methods include best-external and add-paths.
When the BGP advertise-inactive command is configured so that it applies to a BGP session it has the
following effect on the IPv4, IPv6, mcast-ipv4, mcast-ipv6, label-IPv4 and label-IPv6 routes advertised to
that peer.
• If the active route for the IP prefix is a BGP route then that route is advertised.If the active route for
the IP prefix is a non-BGP route and there is at least one valid but inactive BGP route for the same
destination then the best of the inactive and valid BGP routes is advertised unless the non-BGP active
route is matched and accepted by an export policy applied to the session.
• If the active route for the IP prefix is a non-BGP route and there are no (valid) BGP routes for the same
destination then no route is advertised for the prefix unless the non-BGP active route is matched and
accepted by an export policy applied to the session.
5.6.3.6 Best-external
Best-external is a BGP enhancement that allows a BGP speaker to advertise to its IBGP peers its best
‟external” route for a prefix/NLRI when its best overall route for the prefix/NLRI is an ‟internal” route. This is
not possible in a normal BGP configuration because the base BGP specification prevents a BGP speaker
from advertising a non-best route for a destination.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
In specific topologies best-external can improve convergence times, reduce route oscillation and allow
better loadsharing. This is achieved because routers internal to the AS have knowledge of more exit paths
from the AS. Enabling add-paths on border routers of the AS can achieve a similar result but add-paths
introduces NLRI format changes that must be supported by BGP peers of the border router and therefore
has more interoperability constraints than best-external (which requires no messaging changes).
Best-external is supported in the base router BGP context. (A related feature is also supported in VPRNs;
consult the Services Guide for more details.) It is configured using the advertise-external command,
which provides IPv4, label-IPv4, IPv6, and label-IPv6 as options.
The advertisement rules when advertise-external is enabled can be summarized as follows.
• If a router has advertise-external enabled and its best overall route is a route from an IBGP peer
then this best route is advertised to EBGP and confed-EBGP peers, and the ‟best external” route is
advertised to IBGP peers. The ‟best external” route is the one found by running the BGP path selection
algorithm on all LOC-RIB paths except for those learned from the IBGP peers.
Note: A route reflector with advertise-external enabled does not include IBGP routes learned
from other clusters in its definition of ‛external’.
• If a router has advertise-external enabled and its best overall route is a route from an EBGP peer then
this best route is advertised to EBGP, confed-EBGP, and IBGP peers.
• If a router has advertise-external enabled and its best overall route is a route from a confed-EBGP
peer in member AS X then this best route is advertised to EBGP, IBGP peers and confed-EBGP
peers in all member AS except X and the ‟best external” route is advertised to confed-EBGP peers in
member AS X. In this case the ‟best external” route is the one found by running the BGP path selection
algorithm on all RIB-IN paths except for those learned from member AS X.
Note: If the best-external route is not the best overall route it is not installed in the forwarding
table and in some cases this can lead to a short-duration traffic loop after failure of the overall
best path.
5.6.3.7 Add-paths
Add-paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same
prefix/NLRI. Add-Paths provides a number of potential benefits, including reduced routing churn, faster
convergence, and better loadsharing.
For a router to receive multiple paths per NLRI from a peer, for a particular address family, the peer
must announce the BGP capability to send multiple paths for the address family and the local router
must announce the BGP capability to receive multiple paths for the address family. When the Add-Path
capability has been negotiated this way, all advertisements and withdrawals of NLRI by the peer must
include a path identifier. The path identifier has no significance to the receiving router. If the combination of
NLRI and path identifier in an advertisement from a peer is unique (does not match an existing route in the
RIB-IN from that peer) then the route is added to the RIB-IN. If the combination of NLRI and path identifier
in a received advertisement is the same as an existing route in the RIB-IN from the peer then the new route
replaces the existing one. If the combination of NLRI and path identifier in a received withdrawal matches
an existing route in the RIB-IN from the peer, then that route is removed from the RIB-IN.
An UPDATE message carrying an IPv4 NLRI with a path identifier is shown in Figure 28: BGP update
message with path identifier for IPv4 NLRI.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Figure 28: BGP update message with path identifier for IPv4 NLRI
Add-paths is only supported by the base router BGP instance and the EBGP and IBGP sessions it
forms with other peers capable of add-paths. The ability to send and receive multiple paths per prefix is
configurable per family, and supported for the following options:
• IPv4
• label-IPv4
• VPN-IPv4
• IPv6
• label-IPv6
• VPN-IPv6
• MCAST-VPN-IPv4
• MCAST-VPN-IPv6
• MVPN-IPv4
• MVPN-IPv6
• EVPN
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• The BGP route is a multipath (in other words, it is tied with the best path up to and including the NH-
cost comparison step of the decision process, skipping steps that do not apply).
• The BGP next-hop of the route is unique.
• The BGP route is not rejected by an export policy.
• The BGP route is not blocked by a split-horizon rule.
5.6.3.8 Split-horizon
Split-horizon refers to the action taken by a router to avoid advertising a route back to the peer from which
it was received. By default, SR OS applies split-horizon behavior only to routes received from IBGP non-
client peers, and split-horizon only works for routes to non-imported routes within a RIB. This split-horizon
functionality, which can never be disabled, prevents a route learned from a non-client IBGP peer to be
advertised to the sending peer or any other non-client peer.
To apply split-horizon behavior to routes learned from RR clients, confed-EBGP peers or (non-confed)
EBGP peers the split-horizon command must be configured in the appropriate contexts; it is supported at
the global BGP, group and neighbor levels. When split-horizon is enabled on these types of sessions,
it only prevents the advertisement of a route back to its originating peer; for example, SR OS does not
prevent the advertisement of a route learned from one EBGP peer back to a different EBGP peer in the
same neighbor AS.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
When periodic statistics are enabled, the router sends all the statistics as described in RFC 7854, section
4.8, with the exception of statistic number 13, ‟Number of duplicate update messages received”. The
supported statistics are listed in Table 9: Supported statistics .
Statistic Type
Note: Statistics 9 and 10 are per address family. The address family is specified as an AFI/
SAFI pair. Regardless of which families are configured for route-monitoring, a router reports the
statistics of all address families that were negotiated with the neighbor.
The values in these counters are the same values that can be seen in the
show>router>bgp>neighbor ip-address [detail] command in the CLI.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
source IP address, destination IP address, or TCP/UDP port number and indicates (through a community
attribute) an action to take on packets matching the flow. The primary application for FlowSpec is DDoS
mitigation.
FlowSpec is supported for both IPv4 and IPv6. To exchange IPv4 FlowSpec routes with a BGP peer the
flow-ipv4 keyword must be part of the family command that applies to the session and to exchange IPv6
FlowSpec routes with a BGP peer flow-ipv6 must be present in the family configuration.
The NLRI of an IPv4 flow route can contain one or more of the subcomponents shown in Table 10:
Subcomponents of IPv4 flow route NLRI.
IP Protocol [3] One or more (operator, value) pairs Partial. No support for multiple values
other than ‟TCP or UDP”.
2
One or more (operator, value) pairs Yes
Port [4]
ICMP Type [7] One or more (operator, value) pairs Partial. Only a single value is
supported.
ICMP Code [8] One or more (operator, value) pairs Partial. Only a single value is
supported.
3
One or more (operator, bitmask) pairs Yes
TCP Flags [9]
DSCP [11] One or more (operator, value) pairs Partial. Only a single value is
supported.
2 The Port [4] subcomponent specifies both source and destination ports.
3 The following restrictions apply:
• FP4-based platforms support multiple (operator, bitmask) pairs, provided a single TCP flag bit is
matched in each bitmask pair and the match bit is set to 0, resulting in an AND operation between the
TCP flags.
• Multiple TCP flags can be set in the same (operator, bitmask) pair, provided there is a single pair in the
NLRI component with match bit is set to 1 and not bit set to 0.
• FP2- and FP3-based platforms support SYN and ACK only.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Fragment [12] One or more (operator, bitmask) pairs Partial. No support for matching DF
bit, first-fragment or last-fragment.
The NLRI of an IPv6 flow route can contain one or more of the subcomponents shown in Table 11:
Subcomponents of IPv6 flow route NLRI.
Destination IPv6 Prefix [1] Prefix length, prefix offset, prefix Partial. No support for prefix offset.
Source IPv6 Prefix [2] Prefix length, prefix offset, prefix Partial. No support for prefix offset.
Next Header [3] One or more (operator, value) pairs Partial. Only a single value supported.
2
One or more (operator, value) pairs Yes
Port [4]
ICMP Type [7] One or more (operator, value) pairs Partial. Only a single value is
supported.
ICMP Code [8] One or more (operator, value) pairs Partial. Only a single value is
supported.
TCP Flags [9] One or more (operator, bitmask) pairs Partial. Only SYN and ACK flags can
be matched.
Traffic Class [11] One or more (operator, value) pairs Partial. Only a single value is
supported.
Fragment [11] One or more (operator, bitmask) pairs Partial. No support for matching Last
Fragment.
Flow Label [13] One or more (operator, value) pairs Partial. Only a single value is
supported.
Table 12: IPv4 FlowSpec actions summarizes the actions that may be associated with IPv4 flow-spec
routes. Table 13: IPv6 FlowSpec actions summarizes the actions that may be associated with IPv6 flow-
spec routes.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Redirect to LSP Extended community type 0x0900 Partial, only support for ID-
type 0x00 (localized ID)
Redirect to LSP Extended community type 0x0900 Partial, only support for ID-
type 0x00 (localized ID)
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
5.8.2.1 TTL propagation for RFC 3107 label route at ingress LER
For IPv4 and IPv6 packets forwarded using a RFC 3107 label route in the global routing instance, including
label-IPv6, the following command specified with the all value enables TTL propagation from the IP header
into all labels in the transport label stack:
• config router ttl-propagate label-route-local [none | all]
• config router ttl-propagate label-route-transit [none | all]
The none value reverts to the default mode which disables TTL propagation from the IP header to the
labels in the transport label stack.
These commands do not have a no version.
Note:
• The TTL of the IP packet is always propagated into the RFC 3107 label itself. The commands
only control the propagation into the transport labels, for example, the labels of the RSVP
or LDP LSP which the BGP label route resolves to and which are pushed on top of the BGP
label.
• If the BGP peer advertised the implicit-null label value for the BGP label route, the TTL
propagation does not follow the configuration described, but follows the configuration to which
the BGP label route resolves:
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
When an LSR swaps a label or stitches a label, it always writes the decremented TTL value into the
outgoing swapped or stitched label. What the above CLI controls is whether this decremented TTL value is
also propagated to the transport label stack pushed on top of the swapped or stitched label.
The none value reverts to the default mode which disables TTL propagation. This changes the existing
default behavior which propagates the TTL to the transport label stack. When a customer upgrades, the
new default becomes in effect. The above commands do not have a no version.
The following describes the behavior of LSR TTL propagation in a number of other use cases and indicates
if the above CLI command applies or not.
• When an LSR stitches an LDP label to a BGP label, the decremented TTL of the stitched label is
propagated or not to the LDP or RSVP transport labels as per the above configuration.
• When an LSR stitches a BGP label to an LDP label, the decremented TTL of the stitched label is
automatically propagated into the RSVP label if the outgoing LDP LSP is tunneled over RSVP. This
behavior is not controlled by the above CLI.
• When an LSR pops a BGP label and forwards the packet using an IGP route (IGP route to destination
of prefix wins over the BGP label route), it pushes an LDP label on the packet and the TTL behavior is
as described in the previous bullet when stitching from a BGP label to an LDP label.
• When an ingress Carrier Supporting Carrier (CsC) PE swaps the incoming EBGP label into a VPN-
IPv4 label. The reverse operation is performed by the egress CsC PE. In both cases, the decremented
TTL of the swapped label is or is not passed on to the LDP or RSVP transport labels as per the above
configuration.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
in the service provider network and retrieve digitally signed Route Origin Authorization (ROA) objects from
Global RPKI servers. The local cache servers cryptographically validate the ROAs before passing the
information along to the routers.
The algorithm used to determine the origin validation states of routes received over a session with enable-
origin-validation configured uses the following definitions:
• A route is matched by a VRP entry if all of the following occurs:
– the prefix bits in the route match the prefix bits in the VRP entry (up to its min prefix length
– the route prefix length is greater than or equal to the VRP entry min prefix length
– the route prefix length is less than or equal to the VRP entry max prefix length
– the origin AS of the route matches the origin AS of the VRP entry
• A route is covered by a VRP entry if all of the follow occurs:
– the prefix bits in the route match the prefix bits in the VRP entry (up to its min prefix length)
– the route prefix length is greater than or equal to the VRP entry min prefix length
– the VRP entry type is static-valid or dynamic
Using the above definitions, the origin validation state of a route is based on the following rules.
1. If a route is matched by at least one VRP entry, and the most specific of these matching entries includes
a static-invalid entry then the origin validation state is Invalid (2).
2. If a route is matched by at least one VRP entry, and the most specific of these matching entries does
not include a static-invalid entry then the origin validation state is Valid (0).
3. If a route is not matched by any VRP entry, but it is covered by at least one VRP entry then the origin
validation state is Invalid (2).
4. If a route is not covered by any VRP entry then the origin validation state is Not-Found (1).
Consider the following example. Suppose the Origin Validation database has the following entries:
10.1.0.0/16-32, origin AS=5, dynamic
10.1.1.0/24-32, origin AS=4, dynamic
10.0.0.0/8-32, origin AS=5, static invalid
10.1.1.0/24-32, origin AS=4, static invalid
In this case, the origin validation state of the following routes are as indicated:
10.1.0.0/16 with AS_PATH {…5}: Valid
10.1.1.0/24 with AS_PATH {…4}: Invalid
10.2.0.0/16 with AS_PATH {…5}: Invalid
10.2.0.0/16 with AS_PATH {…6}: Not-Found
The origin validation state of a route can affect its ranking in the BGP decision process. When origin-
invalid-unusable is configured, all routes that have an origin validation state of ‛Invalid’ are considered
unusable by the best path selection algorithm, that is, they cannot be used for forwarding and cannot be
advertised to peers.
If origin-invalid-unusable is not configured then routes with an origin validation state of ‛Invalid’ are
compared to other ‟usable” routes for the same prefix according to the BGP decision process.
When compare-origin-validation-state is configured a new step is added to the BGP decision process
after removal of invalid routes and before the comparison of local preference. The new step compares the
origin validation state, so that a route with a ‛Valid’ state is preferred over a route with a ‛Not-Found’ state,
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
and a route with a ‛Not-Found’ state is preferred over a route with an ‛Invalid’ state assuming that these
routes are considered ‛usable’. The new step is skipped if the compare-origin-validation-state command
is not configured.
Route policies can be used to attach an Origin Validation State extended community to a route received
from an EBGP peer to convey its origin validation state to IBGP peers and save them the effort of repeating
the Origin Validation database lookup. To add an Origin Validation State extended community encoding the
‛Valid’ result, the route policy should add a community list that contains a member in the format ext:4300:0.
To add an Origin Validation State extended community encoding the ‛Not-Found’ result, the route policy
should add a community list that contains a member in the format ext:4300:1. To add an Origin Validation
State extended community encoding the ‛Invalid’ result, the route policy should add a community list that
contains a member in the format ext:4300:2.
Note: Using a leak-import policy to change the BGP attributes of leaked routes (compared to
the original source copy) is not supported. The only attribute that can be changed is the RTM
preference.
In the target instance, leaked BGP routes are compared to other (leaked and non-leaked) BGP routes for
the same prefix based on the complete BGP decision process. Leaked routes do not have information
about the router ID and peer IP address of the original peer and use all-zero values for these properties.
BGP always tries to resolve the BGP next hop of a leaked route using the route and tunnel table of the
original (source) routing instance and this resolution information is carried with the leaked route, avoiding
the need to leak the resolving routes as well. If BGP cannot resolve the route or tunnel in the source
instance, the unresolved route cannot be leaked unless allow-unresolved-leaking is configured and
the source routing instance is the GRT. In this case, the importing VPRN tries to resolve the BGP next
hop of the leaked route by using its own route table (and according to its own BGP next-hop-resolution
configuration options).
If a target instance has BGP multipath and ECMP enabled and some of the equal-cost best paths for a
prefix are leaked routes, they can be used along with non-leaked best paths as ECMP next hops of the
route.
When BGP fast reroute is enabled in a target instance (for a particular IP prefix), BGP attempts to find a
qualifying backup path by considering both leaked and non-leaked BGP routes. The backup path criteria
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
are unchanged by this feature, that is, the backup path is the best remaining path after the primary paths
and all paths with the same BGP next hops as the primary paths have been removed.
A leaked BGP route can be advertised to direct BGP neighbors of the target routing instance.
The BGP next hop of a leaked route is automatically reset to itself whenever it is advertised to a peer of
the target instance. Normal route advertisement rules apply, meaning that by default, the leaked route is
advertised only if (in the target instance) it is the overall best path and is used as the active route to the
destination and is not blocked by the IBGP-to-IBGP split-horizon rule.
A BGP route resolved in the source routing instance and leaked into a VPRN can be exported from the
VPRN as a VPN-IPv4 or VPN-IPv6 route if it matches the VRF export policy. In this case, normal VPN
export rules apply, meaning that by default, the leaked route is exported only if (in the VPRN) it is the
overall best path and is used as the active route to the destination.
A BGP route that is unresolved in the GRT, leaked into a VPRN, and resolved by a BGP-VPN route in the
VPRN cannot be exported from the VPRN as a VPN-IPv4 or VPN-IPv6 route unless it matches the VRF
export policy and the VPRN is configured with the allow-bgp-vpn-export command.
Note: A leaked route cannot be exported as a VPN-IP route and then reimported into another
local VPRN.
Note: For the RR to compare two VPN routes (and therefore for ORR to apply), the routes must
contain the same RD and IP prefix information.
ORR locations are created when config>router>bgp>orr>location is configured. The RR can maintain
information for a maximum of 255 ORR locations. A primary IPv4 or primary IPv6 address is required for
each location; optionally, specify a secondary and tertiary IPv4 and IPv6 addresses for the location. The IP
addresses are used to find a node in the network topology that can serve as the root for SPF calculations.
The IP addresses must correspond to loopback or system IP addresses of routers that participate in
IGP protocols. The secondary and tertiary IP address parameters provide redundancy in case the node
selected to be root for the SPF calculations disappears.
The route reflector's TE database, populated with information from local IGP instances or BGP-LS NLRI, is
used to compute the SPF cost from each ORR location to IPv4 and IPv6 BGP next-hops in the candidate
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
set of best paths. The use of BGP-LS allows the route reflector to learn IGP topology information for OSPF
areas, IS-IS levels, and others in which the route reflector is not a direct participant.
To configure an ORR client, configure the cluster command for the BGP session to reference one of the
defined ORR locations. The association of a client with an ORR location is not automatic. Choose an ORR
location as close as possible to the client that is being configured. The allow-local-fallback option of the
cluster command affects RR behavior when no BGP routes are reachable from the ORR location of the
client. When allow-local-fallback is configured, the RR is allowed, in this circumstance only, to advertise
the best reachable BGP path from its own topology location. If allow-local-fallback is not configured and
this situation applies, then no route is advertised to the client.
Note: ORR is supported with add-paths; add-paths advertised to an ORR client are based on
ORR location.
5.8.7 BGP-LS
BGP-LS is a new BGP address family that is intended to distribute IGP topology information to external
servers such as Application Later Traffic Optimization (ALTO) or Path Computation Engines (PCE) servers.
These external traffic engineering databases can then use this information when calculating optimal paths.
BGP-LS provides external ALTO and PCE servers with topology information for a multi-area or multi-level
network. Through the use of one or two BGP-LS speakers per area or level, the external ALTO or PCE
servers can receive full topology information for the entire network. The BGP-LS information can also be
distributed through route reflectors supporting the BGP-LS to minimize the peering requirements.
Figure 29: Example BGP-LS network shows an example BGP-LS network.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
• Segment Routing:
– 1034 — SR Capabilities (only supported for IS-IS)
– 1035 — SR Algorithm (only supported for IS-IS)
Link Descriptors TLVs:
• 258 — Link Local/Remote Identifiers
• 259 — IPv4 interface address
• 260 — IPv4 neighbor address
Link Attributes TLVs:
• 1028 — IPv4 Router-ID of Local Node (only supported for IS-IS)
• 1088 — Administrative group (color)
• 1089 — Maximum link bandwidth
• 1090 — Max. reservable link bandwidth
• 1091 — Unreserved bandwidth
• 1092 — TE Default Metric
• 1095 — IGP Metric
• 1096 — Shared Risk Link Group
• Segment Routing:
– 1099 — Adjacency Segment Identifier
– 1100 — LAN Adjacency Segment Identifier
Prefix Descriptors TLVs:
• 264 — OSPF Route Type (only Intra-Area and Inter-Area)
• 265 — IP Reachability Information
Prefix Attributes TLVs:
• 1152 — IGP Flags (only D flag supported)
• 1155 — Prefix Metric
• Segment Routing:
– 1158 — Prefix SID
– 1159 — Range (prefix-SID and sub-TLV only)
– 1170 — IGP Prefix Attributes (only supported for OSPF)
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
this may not result in a per-prefix label advertisement. When a non-BGP route (for example, static route)
is requested to be advertised (advertise-inactive) with a Label Per Prefix (LPP) policy but it exists as
an active RTM route and as inactive BGP route, the system does not use the LPP but instead uses the
LPNH policy. Statistics are not counted for this prefix. An imported (local loopback) SR label route can
also be configured to use the ingress-statistics keyword by using a route table import policy under rib-
management (either label-ipv4 or label-ipv6).
Overall, BGP-LU statistics apply at the:
• PE and forwarding RR on egress
• ASBR on both ingress and egress
Note:
• Only host prefixes (/32 and /128) are supported on egress statistics.
• Host and non-host prefixes are supported on ingress statistics.
Control messages sent over the BGP-LU tunnel are accounted for in traffic statistics.
BGP-LU statistics are not supported for imported LDP routes (ldp-bgp stitching) or for VPN labels (for
example, inter-AS B or C).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
In this example, there are two IGP domains with eBGP running between R5 and R6, and between R5 and
R8. These adjacencies are not visible to R1, which is external to the IGP domain. At R5, separate peer
node SIDs are allocated for R6 and R8. The peer node SIDs are advertised to the Nokia NSP in BGP-
LS. This allows the NSP to compute a path across either the R5-R6 adjacency or the R5-R8 adjacency by
including the appropriate peer node SID in the path. In the preceding use case, the R5-R6 adjacency is
preferable. This peer node SID can be included in either the SR-ERO of an SR-TE LSP that is computed
by PCEP or the segment list of BGP SR policy that is programmed at R1. Traffic on this LSP or SR policy
is, therefore, steered across the required peering.
EPE is supported for BGP neighbors with either eBGP or iBGP sessions. SR peer node SIDs and peer
adjacency SIDs are supported. The SID labels are dynamically allocated from the local label space on the
node and advertised in BGP-LS using the encoding specified in section 4 of draft-ietf-idr-bgpls-segment-
routing-epe-19.
The peering node can behave as both an LSR and an LER for steering traffic toward the peering segment.
Both ILM and LTN entries are programmed for peer node SIDs and peer adjacency SIDs, with a label swap
to or push of an implicit null label.
Note:
• BGP EPE only supports neighbor nodes that are directly connected to the egress router (for
example, not indirectly through tunnels).
• BGP EPE SIDs cannot be used as the top SIDs on a tunnel originating at the ingress node to
the peering segment. Only IS-IS or OSPF SIDs can be used as the transport SID.
ECMP is supported by default if there are multiple peer adjacency SIDs. BGP only allocates peer
adjacency SIDs to the ECMP set of next hops toward the peer node. For non-ECMP next hops, only a peer
adjacency SID is allocated and it is advertised if all ECMP sets go down.
LSP ping and LSP trace echo requests are supported by including a label representing a peer node SID or
peer adjacency SID in a NIL FEC of the target FEC stack. An EPE router can validate and respond to an
LSP ping or trace echo request containing this FEC.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
configure>router>bgp
egress-peer-engineering {
admin-state {enable | disable}
}
When egress-peer-engineering is administratively enabled, BGP registers with SR and the router starts
advertising any peer node and peer adjacency SIDs in BGP-LS.
To allocate peer node and peer adjacency SIDs, use the following syntax to configure the egress-
engineering command and enable BGP-EPE for a BGP neighbor or group.
CLI syntax
configure>router>bgp
group
neighbor <a.b.c.d> {
egress-engineering {
admin-state {enable | disable}
}
configure>router>bgp
group
egress-engineering {
admin-state {enable | disable}
}
The BGP egress-engineering at the neighbor level overrides the group level configuration. When a
neighbor does not have an egress-engineering configuration context, the group configuration is inherited
in the following cases.
• If the group does not have an egress-engineering configuration, egress-engineering is disabled for
the neighbor.
• If the group has an egress-engineering configuration in the default disabled state, egress-
engineering is disabled for the neighbor.
• If the group has an enabled egress-engineering configuration, egress-engineering is enabled for the
neighbor.
When a neighbor has egress-engineering configured and in the default disabled state, egress-
engineering is disabled for the neighbor, irrespective of the disabled, enabled, or no-context configuration
at the group level. When a neighbor has egress-engineering configured and enabled, egress-
engineering is enabled for the neighbor, irrespective of the disabled, enabled, or no-context configuration
at the group level.
By default, enabling egress-engineering at the peer or group level causes SID values (MPLS labels) to
be dynamically allocated for the peer node segment and the peer adjacency segments. Although the labels
are assigned when the neighbor or group is configured, they are not programmed until the adjacency
comes up. Peer node segments are derived from the BGP next hops used to reach a specific peer. If the
node reboots, these dynamically allocated label values may change and are re-announced in BGP-LS.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
If a BGP neighbor goes down, the router advertises a delete for all SIDs associated with the neighbor and
deprograms them from the IOM. However, the label values for the SIDs are not released and the router re-
advertises the same values when the BGP neighbor comes back up.
If a BGP neighbor is deleted from the configuration or is shut down, or egress-engineering is disabled, the
router advertises a delete for all SIDs associated with the neighbor and deprograms them from the IOM.
The router also releases the label values for the SIDs.
Egress Peer Engineering (EPE) allows an ingress PE or source host in an Autonomous System (AS) to
use a specific egress peering router and a specific external interface or neighbor of that peering router to
reach IP destinations external to the AS.
The following solutions implement EPE:
• Use segment routing and BGP-LS to signal peer node SIDs and peer adjacency SIDs to a PCE or
controller that computes and programs the steering instructions that make use of these SIDs. For more
information, see BGP Egress Peer Engineering using BGP Link State.
• Use a distributed EPE solution relying on BGP Labeled Unicast (LU) routes and recursive BGP route
resolution. BGP EPE using LU does not depend on segment routing, BGP-LS, or a controller. It only
depends on the appropriate configuration in the EPE border routers and ingress PE routers. This is the
simpler solution and is described in what follows.
To enable an egress border router (with EPE peers) to support BGP-LU based EPE, use the egress-peer-
engineering-label-unicast command for the base router BGP groups and neighbors in the configure
router bgp group and configure router bgp group neighbor contexts so that all potential EPE peers are
covered. When this command is applied, BGP generates a labeled unicast route for the /32 or /128 prefix
that corresponds to each EPE peer. These routes can be advertised to other routers to recursively resolve
unlabeled BGP routes for AS external destinations. The BGP-LU EPE routes can resolve unlabeled BGP
routes only when the unlabeled BGP routes are advertised in the local AS with the next-hop unchanged. In
general, the unlabeled routes should be advertised in the local AS using add-paths or best-external so that
multiple exit paths are available to the route selection process in ingress PE routers.
The system generates an EPE route for a peer address when all the following conditions are met:
• The peer address is not an IPv6 link-local address.
• The peer session is up.
• The detected peer type is EBGP (and not IBGP or confederation-EBGP).
• The peer address is resolved by a direct interface route (that is, the peer is a single-hop connected
peer).
The system withdraws an EPE route if any of these conditions is no longer met; for example, the peer
session goes down. After the withdrawal reaches the ingress PE routers, the BGP route selection process
must select a different EPE exit point.
In line cards supporting FP3 or later FP technology, the label that is advertised with an EPE route is
programmed with an action that depends on the state of the interface toward the EPE peer:
• If the interface is up, the system forwards a packet received with the EPE label as a bottom-of-stack
label without IP header lookup (and with the EPE label removed) to the EPE peer.
• If the interface is down, the system forwards a packet received with the EPE label as a bottom-of-stack
label as an IP packet (with the EPE label removed, based on the IP FIB lookup).
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
These datapath optimizations enable fast reroute behavior (BGP FRR) when the interface toward an EPE
peer goes down. The BGP FRR behavior is only available with FP3 or later FP technology.
5.11.1 General
• Before BGP can be configured, the router ID and autonomous system should be configured.
• BGP must be added to the router configuration. There are no default BGP instances on a router.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
If SNMP is used to set a value of X to the MIB variable in Table 14: SR OS and IETF MIB variations , there
are three possible results:
Condition Result
X is within IETF MIB values and X is within SNMP set operation does not return an error
SR OS values MIB variable set to X
X is within IETF MIB values and X is SNMP set operation does not return an error
outside SR OS values MIB variable set to ‟nearest” SR OS supported value (for example,
SR OS range is 2 - 255 and X = 65535, MIB variable is set to 255)
Log message generated
X is outside IETF MIB values and X is SNMP set operation returns an error
outside SR OS values
When the value set using SNMP is within the IETF allowed values and outside the SR OS values as
specified in Table 14: SR OS and IETF MIB variations and Table 15: MIB variable with SNMP , a log
message is generated.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
The log messages that display are similar to the following log messages:
Sample Log Message for setting bgpPeerMinRouteAdvertisementInterval to 256
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Configured before Default accept Default accept Default accept Default accept
Release 19.5.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
ISSU to Release 19.5.R1 Default accept Default accept According to rows 1 According to rows 1
or higher 4 4
and 2 and 2
info
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
...
autonomous-system 200
confederation 300 members 200 400 500 600
router-id 10.10.10.103
#--------------------------------------------------
...
#--------------------------------------------------
echo "BGP Configuration"
#--------------------------------------------------
bgp
graceful-restart
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
exit
cluster 0.0.0.100
export "direct2bgp"
router-id 10.0.0.12
group "To_AS_10000"
connect-retry 20
hold-time 90
keepalive 30
local-preference 100
remove-private
peer-as 10000
neighbor 10.0.0.8
description "To_Router B - EBGP Peer"
connect-retry 20
hold-time 90
keepalive 30
local-address 10.0.0.12
passive
preference 99
peer-as 10000
exit
exit
group "To_AS_30000"
connect-retry 20
hold-time 90
keepalive 30
local-preference 100
remove-private
peer-as 30000
neighbor 10.0.3.10
description "To_Router C - EBGP Peer"
connect-retry 20
hold-time 90
keepalive 30
peer-as 30000
exit
exit
group "To_AS_40000"
connect-retry 20
hold-time 30
keepalive 30
local-preference 100
peer-as 65206
neighbor 10.0.0.15
description "To_Router E - Sub Confederation AS 65205"
connect-retry 20
hold-time 90
keepalive 30
local-address 10.0.0.12
peer-as 65205
exit
exit
exit
#--------------------------------------------------
....
A:ALA-48>config>router#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
The router series supports 4 bytes AS numbers by default. This means autonomous-system can have any
value from 1 to 4294967295. The following example displays autonomous system configuration command
usage.
Example
ALA-B>config>router# info
#------------------------------------------
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
# IP Configuration
#------------------------------------------
interface "system"
address 10.10.10.104/32
exit
interface "to-103"
address 10.0.0.104/24
port 1/1/1
exit
autonomous-system 100
#------------------------------------------
ALA-B>config>router#
ALA-B>config>router# info
----------------------------------------------
# IP Configuration
#------------------------------------------
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
interface "system"
address 10.10.10.104/32
exit
interface "to-103"
address 10.0.0.104/24
port 1/1/1
exit
autonomous-system 100
router-id 10.10.10.104
#------------------------------------------
...
ALA-B>config>router#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
The following configuration displays the minimum BGP configuration for routers in sub-
confederation AS 65001 described in Figure 32: Confederation network diagram example.
ALA-A
config router
autonomous-system 65001
confederation 100 members 65001 65002 65003
bgp
group confed1
peer-as 65001
neighbor 2.2.2.2
exit
neighbor 3.3.3.3
exit
neighbor 4.4.4.4
exit
exit
group external_confed
neighbor 5.5.5.5
peer-as 65002
exit
neighbor 9.9.9.9
peer-as 65003
exit
exit
exit
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
ALA-D
config router
autonomous-system 65001
confederation 100 members 65001 65002 65003
bgp
group confed1
peer-as 65001
neighbor 1.1.1.1
exit
neighbor 2.2.2.2
exit
neighbor 3.3.3.3
exit
exit
exit
exit
ROUTER 1
config router
autonomous-system 65003
confederation 100 members 65001 65002 65003
bgp
group confed1
peer-as 65001
neighbor 1.1.1.1
exit
neighbor 5.5.5.5
peer-as 65002
exit
exit
exit
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
The following configuration displays the minimum BGP configuration for routers in Cluster 1.1.1.1
described in Figure 33: Route reflection network diagram example.
ALA-A
config router bgp
group cluster1
peer-as 100
cluster 1.1.1.1
neighbor 2.2.2.2
exit
neighbor 3.3.3.3
exit
neighbor 4.4.4.4
exit
exit
group RRs
peer-as 100
neighbor 5.5.5.5
exit
neighbor 9.9.9.9
exit
exit
exit
ALA-B
config router bgp
group cluster1
peer-as 100
neighbor 1.1.1.1
exit
exit
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
ALA-C
config router bgp
group cluster1
peer-as 100
neighbor 1.1.1.1
exit
exit
exit
ALA-D
config router bgp
group cluster1
peer-as 100
neighbor 1.1.1.1
exit
exit
exit
ALA-B>config>router>bgp# info
----------------------------------------------
...
group "headquarters1"
description "HQ execs"
local-address 10.0.0.104
disable-communities standard extended
ttl-security 255
exit
exit
...
----------------------------------------------
ALA-B>config>router>bgp#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
ALA-B>config>router>bgp# info
----------------------------------------------
...
group "headquarters1"
description "HQ execs"
local-address 10.0.0.104
disable-communities standard extended
ttl-security 255
neighbor 10.0.0.5
passive
peer-as 300
exit
neighbor 10.0.0.106
peer-as 100
exit
neighbor 17.5.0.2
hold-time 90
keepalive 30
local-preference 170
peer-as 10701
exit
neighbor 17.5.1.2
hold-time 90
keepalive 30
local-preference 100
min-route-advertisement 30
preference 170
peer-as 10702
exit
exit
...
----------------------------------------------
ALA-B>config>router>bgp#
ALA-B>config>router>bgp# info
---------------------------------------------
cluster 0.0.0.100
group "Santa Clara"
local-address 10.0.0.103
neighbor 10.0.0.91
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
peer-as 100
exit
neighbor 10.0.0.92
peer-as 100
exit
neighbor 10.0.0.93
disable-client-reflect
peer-as 100
exit
exit
---------------------------------------------
ALA-B>config>router>bgp#
When 4-byte AS number support is not disabled on router, the confederation and any of its members
can be assigned an AS number in the range from 1 to 4294967295. The following example displays a
confederation configuration command usage.
Example
ALA-B>config>router# info
#------------------------------------------
# IP Configuration
#------------------------------------------
interface "system"
address 10.10.10.103/32
exit
interface "to-104"
shutdown
address 10.0.0.103/24
port 1/1/1
exit
autonomous-system 100
confederation 1000 members 100 200 300
router-id 10.10.10.103
#------------------------------------------
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
ALA-B>config>router#
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
This creates a BMP station named antwerp. The station name must be used when configuring BGP peers
to be monitored by this station. The name can also be used in the show>router>bmp CLI commands to
display associated information.
The next step is to configure how this station can be reached. To do this, the IP address of the Linux
station, or container, on which the BMP collector is run is required. Also, the TCP port number on which the
BMP station is listening is needed. BMP does not use a well-known port number.
• A network operator can pick any appropriate TCP port number.
• BMP sessions from an SR OS router can run over either TCP/IPv4 or TCP/IPv6.
The following is an IP address and port number configuration for a BMP station:
configure bmp
station antwerp create
connection
station-address 1.2.3.4 port 5000
exit
exit
exit
This creates a BMP station that can monitor one or more BGP peers.
Next, assign the BGP peers to be monitored.
• In BGP configuration mode, navigate to the monitor command, config>router>bgp>monitor. The
monitor command can be used at the BGP-instance level the group or neighbor levels.
• Configure up to eight station names that monitor these peers, config>router>bgp>monitor>station
name.
• Enable monitoring, config>router>bgp>monitor>no shutdown. On SR OS routers, both the BMP
protocol and each individual station are in a shutdown state by default. To allow BMP to start BMP
sessions, BMP and the station must be administratively enabled.
All peers in the BGP instance of the base router are now monitored by station antwerp. The router only
sends BMP peer-up and peer-down messages to the BMP station. Sending periodic statistics messages,
or reporting incoming BGP routes must be explicitly configured.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Because the AS number is defined in the config>router context, not in the BGP configuration context, the
BGP instance is not aware of the change. Re-examine the plan detailing the autonomous systems, the
SRs belonging to each group, group names, and peering connections. Changing an AS number on a router
could cause configuration inconsistencies if associated peer-as values are not also modified as required.
At the group and neighbor levels, BGP re-establishes the peer relationships with all peers in the group with
the new AS number.
Use the following CLI syntax to change an autonomous system number.
CLI syntax
CLI syntax
config>router# bgp
group name
neighbor ip-addr
peer-as asn
Example
This example displays the BGP configuration with the BGP router ID specified:
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Example
ALA-A>config>router# info
#------------------------------------------
# IP Configuration
#------------------------------------------
interface "system"
address 10.10.10.104/32
exit
interface "to-103"
address 10.0.0.104/24
port 1/1/1
exit
autonomous-system 100
router-id 10.10.10.104
#------------------------------------------
ALA-B>config>router#
config>router# bgp
group name
no neighbor ip-address
shutdown
no peer-as asn
shutdown
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE BGP
22.2.R1
Example
config>router# bgp
config>router>bgp# group headquarters1
config>router>bgp>group# neighbor 10.0.0.103
config>router>bgp>group>neighbor# shutdown
config>router>bgp>group>neighbor# exit
config>router>bgp>group# no neighbor 10.0.0.103
The following example displays the ‟headquarters1” configuration with the neighbor 10.0.0.103 removed.
ALA-B>config>router>bgp# info
----------------------------------------------
group "headquarters1"
description ‟HQ execs”
local-address 10.0.0.104
neighbor 10.0.0.5
passive
peer-as 300
exit
exit
----------------------------------------------
ALA-B>config>router>bgp#
config>router# bgp
no group name
shutdown
no neighbor ip-address
shutdown
shutdown
Example
config>router# bgp
config>router>bgp# group headquarters1
config>router>bgp>group# neighbor 10.0.0.105
config>router>bgp>group>neighbor# shutdown
config>router>bgp>group>neighbor# exit
config>router>bgp>group# neighbor 10.0.0.103
config>router>bgp>group# shutdown
config>router>bgp>group# exit
config>router>bgp# no group headquarters1
If you try to delete the group without shutting down the peer-group, the following message appears:
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
6 Route policies
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
that it is evaluated immediately before an existing named-entry entry1 this can be achieved using the
insert named-entry entry2 before entry1 command.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
• If the evaluation of a policy terminates with an action accept, action next-entry or action next-policy,
the result is TRUE. If the evaluation of a policy terminates with an action reject or action drop, then
the result is FALSE. If a route matches no entry in a policy and there is no specified default-action, the
implied default action is next-policy; if there is no next policy, this translates to the default action for the
protocol.
• When a route is evaluated against a policy contained in a logical expression, the route property
changes (such as MED, local preference, communities) made by the matching entry or default action
apply cumulatively to the route. The result of a cumulative change is that a policy evaluated later in the
logical expression (or later in the entire policy chain) may undo or reverse prior changes. A later policy
in the logical expression (or policy chain) may also match a route on the basis of route properties that
were modified by earlier policies.
When evaluation of the logical expression is complete, the final TRUE or FALSE result is translated back to
a traditional action. The FALSE value is translated to action reject; the TRUE value is translated to action
accept, action next-policy or action next-entry to match the action of the last policy that produced the TRUE
result.
Note: When subroutines are configured to reject routes, the accept action state can be used as a
possible configuration in the subroutine match criteria to return a true-match, and the reject action
state can be applied in the main policy entry that has called the subroutine.
If a match is not found during the evaluation of one or more routing policies, the final evaluation returns
the accept or the reject provided by the default behavior based on the policy type (import/export) and the
destination and/or source protocol.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
The two events that could trigger the route flapping algorithm are:
• Route flapping
If a route flap is detected within a configured maximum route flap history time, the route’s FoM is
initialized and the route is marked as a potentially unstable route. Every time a route flaps, the FoM is
increased and the route is suppressed if the FoM crosses the suppress threshold.
• Route reuse timer trigger
A suppressed route’s FoM decays exponentially. When it crosses the reuse threshold, the route is
eligible for advertisement if it is still reachable.
If the route continues to flap, the FoM, with respect to time scale, looks like a sawtooth waveform with the
exponential rise and decay of FoM. To control flapping, the following parameters can be configured:
• half-life
The half-life value is the time, expressed in minutes, required for a route to remain stable in order for
one half of the FoM value to be reduced. For example, if the half-life value is 6 (minutes) and the route
remains stable for 6 minutes, then the new FoM value is 3. After another 6 minutes passes and the
route remains stable, the new FoM value is 1.5.
• max-suppress
The maximum suppression time, expressed in minutes, is the maximum amount of time that a route can
remain suppressed.
• suppress
If the FoM value exceeds the configured integer value, the route is suppressed for use or inclusion in
advertisements.
• reuse
If the suppress value falls below the configured reuse value, then the route can be reused.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Operator Description
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Operator Description
\ An escape character to indicate that the following character is a match criteria and not a
grouping delimiter.
& Matches ‟:” between terms of a community string (applicable to extended communities origin,
target, bandwidth, ext only).
Examples of ‟target:”, ‟origin:” and ‟ext:” community strings are listed in Table 18: Community strings
examples .
Examples of AS path and community string regular expressions are listed in Table 19: AS path and
community regular expression examples .
AS path is 11 11 11
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
AS path is 11 22 33 11 22 33 11 22 33
One occurrence of the AS numbers 100 and 200, 100 200 33+ 100 200 33
followed by one or more occurrences of the number 33 100 200 33 33
100 200 33 33 33
100 200 33 33 33 … 33
Path of length one or two whose second AS number may . (11 | 22)? 100
be 11 or 22 200 11
300 22
Path whose first AS number is 100 and second AS 100 (11 | 22) .* 100 11
number is either 11 or 22 100 22 200 300
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Note: With the triggered policy enabled, deletion and re-addition of a peer after making changes
to export policy causes the new updates sent out to all peers.
The triggered policy is not honored if a new peer is added to BGP. An update with the old policy is sent to
the newly added peer. The new policy is not applied to the new peer until the peer is flapped.
With the triggered policy enabled, if a new BGP/static route comes in, the new addition or modification of
an export policy causes the updates to be sent out dynamically to all peers with the new/modified export
policy.
When multiple peers, such as P1, P2 and P3, share the same export policy, any modifications to the export
policy followed by clear soft on one of the peer P1s, send out routes to P1 only according to the newly
modified policy. Though routes with the newly modified policy are not sent to other peers (P2 and P3) as
there are no clear soft issues on these peers, RIB-OUT shows that the new routes with the modified policy
are sent to all the peers. RIB-IN on peers P2 and P3 are shown correctly.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Export Non-BGP route (static, OSPF, ISIS, and so on) Add MED attribute. Set value to M.
Export BGP route w/o MED Add MED attribute. Set value to D.
Export BGP route with MED (value A) Overwrite MED attribute with value D.
6.1.3.6 Route policies for BGP next-hop resolution and peer tracking
This feature adds the flexibility to attach a route policy to the BGP next-hop resolution process; it also
allows a route policy to be associated with the optional BGP peer-tracking function. BGP next-hop
resolution is a fundamental part of BGP protocol operation; it determines the best matching route (or
tunnel) for the BGP next-hop address and uses information about this resolving route in the best path
selection algorithm and to program the forwarding table. Attaching a policy to BGP next-hop resolution
provides more control over which IP routes in the routing table can become resolving routes. Similar
flexibility is also available for BGP peer-tracking, which is an optional feature that allows the session with
a BGP neighbor to be taken down if there is no IP route to the neighbor address or if the best matching IP
route is rejected by the policy.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Using a parameter based system allows an operator to have a single policy that is consistent across all
peers of a type, while retaining the flexibility to reference different policy functions (such as, prefixes,
prefix-lists, community lists) with unique names if required, by defining variables and the variable value.
This feature is able to inherit some of these variables directly from the routing process (for example,
‟@peerAS@” would be the configured BGP peer-AS).
Additionally, instead of policies being fixed and requiring many statements, the use of parameters and
variables may be passed to simplify policy configuration. This reduces the number of policies required on
a peering edge router with large numbers of peers where only small amounts of configuration changes
between peers, such as the ASN and prefix-list name.
The following two types of policy variables are supported.
• Global policy variables are configured using the global-variables command and can be referenced
from any policy. Use global policy variables when the variables are used by multiple policies.
• Local policy variables are configured using the policy-variables command in each policy, and can be
referenced in a sub-policy. Use local policy variables when the variables are specific to a policy and are
not used in any other policies.
Note: Local policy variables have precedence over global policy variables, if policy variables
have the same name.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Variables expansion can use two formats, with the variable name delimited by at-signs (@) at the
beginning and the end:
• standard variables must start and end with at-signs (@), for example: @variable@
• midstring variables must be enclosed with at-signs (@) and may be midstring, for example:
@variable@, start@variable@end, @variable@end, start@variable@
Table 21: Route policy variable support in policy parameters lists route policy variables supported in policy
parameters.
cluster-id No — — — —
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
path-type No — — — —
Note: Midstring variables are only supported in the object name. Standard variables are
supported in policy parameters inside as-path or as-path-group expression objects; for example:
as-path ‟as” expression ‟.{65001,@variable@}65022”.
For the definition of the variables, there are three different possible types:
• name name-string value value-string
• name name-string address ip-address
• name name-string number value-number
Depending on the parameter referenced, specify the correct type as follows:
• value-string: as-path, as-path-group, community, prefix-list, damping
• ip-address: next-hop
• value-number: aigp-metric, as-path-length, as-path-prepend, community-count, local-preference,
metric, origin, origin-validation, preference, tag, type
The logical flow of this is to configure a per-peer policy in which the variable names and values are
defined. Using Figure 38: Route policy parameterization using sub-policies as the example, the following
configuration would be applied:
prefix-list "pfx-as63535"
prefix 6.3.5.0/24 through 32
exit
prefix-list "pfx-as64535"
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
policy-statement "peer1"
entry 5
from
policy-variables
name "@cm-reject@" value "cm-as65535-rejects"
exit
policy "std-peering-inbound-drop"
exit
action reject
entry 10
from
policy-variables
name "@localcm@" value "cm-as65535"
name "@peer-as@" value "as65535"
name "@cm-highpref@" value "cm-as65535-highpref"
name "@peer-prefix@" value "pfx-as65535"
exit
policy "std-peering-inbound-main"
exit
action accept
exit
exit
exit
policy-statement "peer2"
entry 5
from
policy-variables
name "@cm-reject@" value "cm-as64535-rejects"
exit
policy "std-peering-inbound-drop"
exit
action reject
entry 10
from
policy-variables
name "@localcm@" value "cm-as64535"
name "@peer-as@" value "as64535"
name "@cm-highpref@" value "cm-as64535-highpref"
name "@peer-prefix@" value "pfx-as64535"
exit
policy "std-peering-inbound-main"
exit
action accept
exit
exit
exit
policy-statement "peer3"
entry 5
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
from
policy-variables
name "@cm-reject@" value "cm-as63535-rejects"
exit
policy "std-peering-inbound-drop"
exit
action reject
entry 10
from
policy-variables
name "@localcm@" value "cm-as63535"
name "@peer-as@" value "as63535"
name "@cm-highpref@" value "cm-as63535-highpref"
name "@peer-prefix@" value "pfx-as63535"
exit
policy "std-peering-inbound-main"
exit
action accept
exit
exit
exit
policy-statement "std-peering-inbound-drop"
default-action reject
entry 10
from
community "@cm-reject@"
exit
action accept
policy-statement "std-peering-inbound-main"
default-action reject
entry 10
from
prefix-list "@peer-prefix@"
as-path "@peer-as@"
exit
action accept
community add "@localcm@"
local-preference 400
exit
exit
entry 20
from
community "@cm-highpref@"
exit
action accept
community add "@localcm@"
local-preference 4000
exit
exit
exit
This configuration would take slightly different actions depending on the peer.
Peer 1
• Routes that have a community matching ‟cm-as65535-rejects” are dropped.
• Routes matching the prefix list ‟pfx-as65535” that originated in the peer AS=65535 are accepted with a
local preference of 400.
• Community ‟7750:65535” is added to accepted prefixes.
• As community-list ‟cm-65535-highpref” does not exist, no routes are modified with a local preference of
4000.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Peer 2
• Routes that have a community matching ‟cm-as64535-rejects” are dropped.
• Routes matching the prefix list ‟pfx-as65535” that originated in the peer AS=65535 are accepted with a
local preference of 400.
• Prefixes matching ‟cm-as64535-highpref” are set to a local-preference of 4000.
Peer 3
• As community-list ‟cm-as63535-rejects” does not exist, no routes are dropped by the first entry.
• Routes matching the prefix list ‟pfx-as63535” that originated in the peer AS=63535 are accepted with a
local preference of 400.
• Community ‟7750:63535” is added to accepted prefixes.
• As community-list ‟cm-63535-highpref” does not exist, no routes are modified with a local preference of
4000.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
6.3.1 General
When configuring policy statements, the policy statement name must be unique.
Note: The policy reference checks feature is available only in the classic CLI and not via
SNMP or model-driven interfaces. Model-driven interfaces and mixed management interface
configuration mode use strict policy reference checks starting in Release 16.0.R3, where the
checks cannot be disabled.
If a policy is referenced which has not yet been configured, and no policy-reference-checks is set, the
configuration line succeeds with the CLI message:
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
If a policy is referenced which has not yet been configured, and policy-reference-checks is set, the
configuration line errors and fails with the CLI message:
Policy reference checks are required in router configuration contexts that reference a policy name,
including the following:
• configure router bgp export
• configure router bgp group export
• configure router bgp group import
• configure router bgp group neighbor export
• configure router bgp group neighbor import
• configure router bgp import
• configure service vprn bgp export
• configure service vprn bgp group export
• configure service vprn bgp group import
• configure service vprn bgp group neighbor export
• configure service vprn bgp group neighbor import
• configure service vprn bgp import
• configure service vprn vrf-export
• configure service vprn vrf-import
Policy reference checks are required in policy configuration contexts that reference a policy element,
including the following:
• entry from flow-spec-dest prefix-list-name
• entry from flow-spec-source prefix-list-name
• entry from group-address prefix-list-name
• entry from host-ip prefix-list-name
• entry from neighbor {ip-address | prefix-list-name}
• entry from next-hop prefix-list-name
• entry from prefix-list name [name]
• entry from source-address prefix-list prefix-list-name
• entry to neighbor {ip-address | prefix-list-name}
• entry to prefix-list name [name]
• as-path
• as-path-group
• community
• damping
• policy statements used in sub-policies
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Before a route policy is applied, analyze the policy’s purpose and be aware of the results (and
consequences) when packets match the specified criteria and the associated actions and default actions, if
specified, are executed. Membership reports can be filtered based on a specific source address.
OSPF Not applicable. All OSPF routes • Internal routes: All OSPF routes
are accepted from OSPF are automatically advertised to all
neighbors and cannot be controlled neighbors.
via route policies. • External routes: By default, all
non-OSPF learned routes are not
advertised to OSPF neighbors.
IS-IS Not applicable. All IS-IS routes • Internal routes: All IS-IS routes
are accepted from IS-IS neighbors are automatically advertised to all
and cannot be controlled via route neighbors.
policies • External routes: By default, all non-IS-
IS learned routes are not advertised to
IS-IS peers.
RIP By default, all RIP-learned routes External routes: By default, all non-RIP
are accepted. learned routes are not advertised to RIP
peers.
BGP By default, all routes from BGP • Internal routes: By default, all active
peers are accepted and passed to BGP routes are advertised to BGP
the BGP route selection process. peers.
• External routes: By default, all non-
BGP learned routes are not advertised
to BGP peers.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Each route policy statement can have a default-action clause defined. If a default-action is defined for one
or more of the configured route policies, then the default actions should be handled in the following ways.
• The process stops when the first complete match is found and executes the action defined in the entry.
• If the packet does not match any of the entries, the system executes the default action specified in the
policy statement.
Figure 40: Route policy process example depicts an example of the route policy process.
Route policies can also match a specific route policy entry and continue to search for other entries within
either the same route policy or the next route policy by specifying the next-entry or next-policy option in
the entry’s action command. Policies can be constructed to support multiple states to the evaluation and
setting of various route attributes.
Figure 41: Next policy logic example depicts the next-policy and next-entry route processes.
For the default route policy actions, see Table 22: Default route policy actions.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
6.4.1.4 Damping
Damping initiates controls when routes flap. Route flapping can occur when an advertised route between
nodes alternates (flaps) back and forth between two paths because of network problems which cause
intermittent route failures. It is necessary to reduce the amount of routing state change updates propagated
to limit processing requirements. Thus, when a route flaps beyond a configured value (the suppress value),
then that route is removed from the routing tables and routing protocols until the value falls below the reuse
value.
A route can be suppressed according to the Figure of Merit (FoM) value. The FoM is a value that is added
to a route each time it flaps. A new route begins with an FoM value of 0.
Damping is optional. If damping is configured, the following parameter values must be explicitly specified
as there are no default values:
• suppress
• half-life
• reuse
• max-suppress
When a route's FoM value exceeds the suppress value, then the route is removed from the routing table.
The route is considered to be stable when the FoM drops below the reuse value by means of the specified
half-life parameter. The route is returned to the routing tables. When routes have higher FoM and half-life
values, they are suppressed for longer periods of time. Figure 42: Damping example depicts an example
of a flapping route, the suppress threshold, the half-life decay (time), and reuse threshold. The peaks
represent route flaps, the slopes represent half-life decay.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
A:ALA-B>config>router>policy-options# info
----------------------------------------------
community "all-types" members "5000:[1-6][1-9][0-9]"
community "all-normal" members "5000:[1-5][1-9][0-9]"
. . .
as-path "Outside madeup paths" ".* 5001 .*"
as-path "Outside Internet paths" ".* 5002 .*"
policy-statement "RejectOutsideASPaths"
entry 1
from
protocol bgpospf
as-path "Outside madeup paths"
exit
action reject
exit
exit
entry 2
from
protocol bgpospf
as-path "Outside Internet paths"
exit
action reject
exit
exit
entry 3
from
protocol ospf
exit
to
protocol bgpospf
exit
action reject
exit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
exit
entry 4
from
protocol isis
exit
to
protocol bgpospf
exit
action reject
exit
exit
default-action accept
exit
exit
policy-statement "aggregate-customer-peer-only"
entry 1
from
community "all-customer-announce"
exit
action accept
exit
exit
default-action reject
exit
exit
----------------------------------------------
A:ALA-B>config>router>policy-options#
Note: The MD-CLI has significant differences from the classic CLI for configuring route policy
components. In the MD-CLI, there is no separate transaction (begin or commit) for the policy
changes. Also, the MD-CLI supports policy statements with entry type named (see Policy
statements for information about policy statements).
config>router>policy-options
begin
policy-statement name
description text
The following error message displays when the you try to modify a policy options command without
entering begin first.
The following example displays policy statement configuration command usage. These commands are
configured in the config>router context.
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
Example:
config>router# policy-options
policy-options# begin
There are no default policy statement options. All parameters must be explicitly configured.
A:ALA-B>config>router>policy-options# info
#------------------------------------------
# Policy
#------------------------------------------
policy-options
begin
policy-statement "allow all"
description "General Policy"
...
exit
exit
----------------------------------------------
A:ALA-B>config>router>policy-options#
A:ALA-B>config>router>policy-options# info
----------------------------------------------
policy-statement "1"
default-action accept
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
A:ALA-B>config>router>policy-options# info
----------------------------------------------
policy-statement "1"
entry 1
to
neighbor 10.10.10.104
exit
action accept
exit
exit
entry 2
from
protocol ospf 1
exit
to
protocol ospf
neighbor 10.10.0.91
exit
action accept
exit
exit
default-action accept
. . .
exit
exit
The following example displays entry parameters and includes the default action parameters which were
displayed in the previous section.
A:ALA-B>config>router>policy-options# info
----------------------------------------------
policy-statement "1"
entry 1
to
protocol bgp
neighbor 10.10.10.104
exit
action accept
exit
exit
entry 2
from
protocol ospf 1
exit
to
protocol ospf
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
neighbor 10.10.0.91
exit
action accept
exit
exit
default-action accept
. . .
exit
exit
A:ALA-B>config>router>policy-options# info
----------------------------------------------
community "eastern" members "100:200"
community "western" members "100:300"
community "northern" members "100:400"
community "southern" members "100:500"
community "headquarters" members "100:1000"
policy-statement "1"
entry 1
to
protocol bgp
neighbor 10.10.10.104
exit
action accept
. . .
----------------------------------------------
A:ALA-B>config>router>policy-options#
*A:cses-A13>config>router>policy-options# info
----------------------------------------------
damping "damptest123"
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
half-life 15
max-suppress 60
reuse 750
suppress 1000
exit
----------------------------------------------
*A:cses-A13>config>router>policy-options#
A:ALA-B>config>router>policy-options# info
----------------------------------------------
prefix-list "western"
prefix 10.10.0.1/32 exact
prefix 10.10.0.2/32 exact
prefix 10.10.0.3/32 exact
prefix 10.10.0.4/32 exact
exit
damping "damptest123"
half-life 15
max-suppress 60
reuse 750
exit
----------------------------------------------
A:ALA-B>config>router>policy-options#
A:ALA-B>config>router>policy-options>policy-statement# info
----------------------------------------------
description "Level 1"
entry 1
to
protocol bgp
neighbor 10.10.10.104
exit
action accept
exit
exit
entry 2
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
from
protocol ospf
exit
to
protocol ospf
neighbor 10.10.0.91
exit
action accept
exit
exit
entry 4
description "new entry"
from
protocol isis
area 0.0.0.20
exit
action reject
exit
default-action accept
as-path add "test"
community add "365"
damping "flapper"
next-hop 10.10.10.104
exit
----------------------------------------------
config>router>policy-options
begin
commit
abort
policy-statement name
no entry entry-id
The following example displays the commands required to delete a policy statement entry.
Example
config>router>policy-options# begin
policy-options# policy-statement "1"
policy-options>policy-statement# no entry 4
policy-options>policy-statement# commit
config>router>policy-options
begin
commit
abort
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Route policies
22.2.R1
no policy-statement name
The following example displays the commands required to delete a policy statement.
Example
config>router>policy-options# begin
policy-options# no policy-statement 1
policy-options# commit
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 5549, Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop
RFC 5668, 4-Octet AS Specific BGP Extended Community
RFC 6286, Autonomous-System-Wide Unique BGP Identifier for BGP-4
RFC 6793, BGP Support for Four-Octet Autonomous System (AS) Number Space
RFC 6810, The Resource Public Key Infrastructure (RPKI) to Router Protocol
RFC 6811, Prefix Origin Validation
RFC 6996, Autonomous System (AS) Reservation for Private Use
RFC 7311, The Accumulated IGP Metric Attribute for BGP
RFC 7607, Codification of AS 0 Processing
RFC 7674, Clarification of the Flowspec Redirect Extended Community
RFC 7752, North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
RFC 7854, BGP Monitoring Protocol (BMP)
RFC 7911, Advertisement of Multiple Paths in BGP
RFC 7999, BLACKHOLE Community
RFC 8092, BGP Large Communities Attribute
RFC 8212, Default External BGP (EBGP) Route Propagation Behavior without Policies
RFC 8571, BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric
Extensions
RFC 8955, Dissemination of Flow Specification Rules
RFC 8956, Dissemination of Flow Specification Rules for IPv6
RFC 9086, Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress
Peer Engineering
7.5 Broadband Network Gateway (BNG) Control and User Plane Separation
(CUPS)
3GPP 23.007, Restoration procedures
3GPP 29.244, Interface between the Control Plane and the User Plane nodes
3GPP 29.281, General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)
BBF TR-459, Control and User Plane Separation for a Disaggregated BNG
RFC 8300, Network Service Header (NSH)
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 6712, Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management
Protocol (CMP)
RFC 7030, Enrollment over Secure Transport
RFC 7468, Textual Encodings of PKIX, PKCS, and CMS Structures
7.8 Ethernet
IEEE 802.1AB, Station and Media Access Control Connectivity Discovery
IEEE 802.1ad, Provider Bridges
IEEE 802.1ag, Connectivity Fault Management
IEEE 802.1ah, Provider Backbone Bridges
IEEE 802.1ak, Multiple Registration Protocol
IEEE 802.1aq, Shortest Path Bridging
IEEE 802.1ax, Link Aggregation
IEEE 802.1D, MAC Bridges
IEEE 802.1p, Traffic Class Expediting
IEEE 802.1Q, Virtual LANs
IEEE 802.1s, Multiple Spanning Trees
IEEE 802.1w, Rapid Reconfiguration of Spanning Tree
IEEE 802.1X, Port Based Network Access Control
IEEE 802.3ac, VLAN Tag
IEEE 802.3ad, Link Aggregation
IEEE 802.3ah, Ethernet in the First Mile
IEEE 802.3x, Ethernet Flow Control
ITU-T G.8031/Y.1342, Ethernet Linear Protection Switching
ITU-T G.8032/Y.1344, Ethernet Ring Protection Switching
ITU-T Y.1731, OAM functions and mechanisms for Ethernet based networks
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 3359, Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate
System
RFC 3719, Recommendations for Interoperable Networks using Intermediate System to Intermediate
System (IS-IS)
RFC 3787, Recommendations for Interoperable IP Networks using Intermediate System to Intermediate
System (IS-IS)
RFC 4971, Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router
Information
RFC 5120, M-ISIS: Multi Topology (MT) Routing in IS-IS
RFC 5130, A Policy Control Mechanism in IS-IS Using Administrative Tags
RFC 5301, Dynamic Hostname Exchange Mechanism for IS-IS
RFC 5302, Domain-wide Prefix Distribution with Two-Level IS-IS
RFC 5303, Three-Way Handshake for IS-IS Point-to-Point Adjacencies
RFC 5304, IS-IS Cryptographic Authentication
RFC 5305, IS-IS Extensions for Traffic Engineering TE
RFC 5306, Restart Signaling for IS-IS - helper mode
RFC 5307, IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
RFC 5308, Routing IPv6 with IS-IS
RFC 5309, Point-to-Point Operation over LAN in Link State Routing Protocols
RFC 5310, IS-IS Generic Cryptographic Authentication
RFC 6119, IPv6 Traffic Engineering in IS-IS
RFC 6213, IS-IS BFD-Enabled TLV
RFC 6232, Purge Originator Identification TLV for IS-IS
RFC 6233, IS-IS Registry Extension for Purges
RFC 6329, IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
RFC 7775, IS-IS Route Preference for Extended IP and IPv6 Reachability
RFC 7794, IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability
RFC 7987, IS-IS Minimum Remaining Lifetime
RFC 8202, IS-IS Multi-Instance - single topology
RFC 8570, IS-IS Traffic Engineering (TE) Metric Extensions - Min/Max Unidirectional Link Delay metric for
flex-algo
RFC 8919, IS-IS Application-Specific Link Attributes
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 5186, Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery
Version 2 (MLDv2) and Multicast Routing Protocol Interaction
RFC 5384, The Protocol Independent Multicast (PIM) Join Attribute Format
RFC 5496, The Reverse Path Forwarding (RPF) Vector TLV
RFC 6037, Cisco Systems' Solution for Multicast in MPLS/BGP IP VPNs
RFC 6512, Using Multipoint LDP When the Backbone Has No Route to the Root
RFC 6513, Multicast in MPLS/BGP IP VPNs
RFC 6514, BGP Encodings and Procedures for Multicast in MPLS/IP VPNs
RFC 6515, IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPNs
RFC 6516, IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast
Service Interface (S-PMSI) Join Messages
RFC 6625, Wildcards in Multicast VPN Auto-Discover Routes
RFC 6826, Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Path
RFC 7246, Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding
(VRF) Table Context
RFC 7385, IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points
RFC 7716, Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
RFC 7761, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
RFC 8279, Multicast Using Bit Index Explicit Replication (BIER)
RFC 8296, Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks -
MPLS encapsulation
RFC 8401, Bit Index Explicit Replication (BIER) Support via IS-IS
RFC 8444, OSPFv2 Extensions for Bit Index Explicit Replication (BIER)
RFC 8487, Mtrace Version 2: Traceroute Facility for IP Multicast
RFC 8534, Explicit Tracking with Wildcard Routes in Multicast VPN - (C-*,C-*) wildcard
RFC 8556, Multicast VPN Using Bit Index Explicit Replication (BIER)
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 - IPv6
RFC 5952, A Recommendation for IPv6 Address Text Representation
RFC 6092, Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service - Internet Control and Management, Upper-Layer Transport
Protocols, UDP Filters, IPsec and Internet Key Exchange (IKE), TCP Filters
RFC 6106, IPv6 Router Advertisement Options for DNS Configuration
RFC 6164, Using 127-Bit IPv6 Prefixes on Inter-Router Links
RFC 6437, IPv6 Flow Label Specification
RFC 6603, Prefix Exclude Option for DHCPv6-based Prefix Delegation
RFC 8021, Generation of IPv6 Atomic Fragments Considered Harmful
RFC 8200, Internet Protocol, Version 6 (IPv6) Specification
RFC 8201, Path MTU Discovery for IP version 6
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths
RFC 6512, Using Multipoint LDP When the Backbone Has No Route to the Root
RFC 6826, Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths
RFC 7032, LDP Downstream-on-Demand in Seamless MPLS
RFC 7473, Controlling State Advertisements of Non-negotiated LDP Applications
RFC 7552, Updates to LDP for IPv6
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
7.25 OpenFlow
TS-007 Version 1.3.1, OpenFlow Switch Specification - OpenFlow-hybrid switches
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 3906, Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels
RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels
RFC 4124, Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
RFC 4561, Definition of a Record Route Object (RRO) Node-Id Sub-Object
RFC 4875, Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)
RFC 4950, ICMP Extensions for Multiprotocol Label Switching
RFC 5151, Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions
RFC 5712, MPLS Traffic Engineering Soft Preemption
RFC 5817, Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
RFC 3417, Transport Mappings for the Simple Network Management Protocol (SNMP) - SNMP over UDP
over IPv4
RFC 3418, Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
RFC 3419, Textual Conventions for Transport Addresses
RFC 3498, Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic
Protection Switching (APS) Architectures
RFC 3584, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network
Management Framework
RFC 3592, Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Interface Type
RFC 3593, Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
RFC 3635, Definitions of Managed Objects for the Ethernet-like Interface Types
RFC 3637, Definitions of Managed Objects for the Ethernet WAN Interface Sublayer
RFC 3826, The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security
Model
RFC 3877, Alarm Management Information Base (MIB)
RFC 3895, Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types
RFC 3896, Definitions of Managed Objects for the DS3/E3 Interface Type
RFC 4001, Textual Conventions for Internet Network Addresses
RFC 4022, Management Information Base for the Transmission Control Protocol (TCP)
RFC 4113, Management Information Base for the User Datagram Protocol (UDP)
RFC 4220, Traffic Engineering Link Management Information Base
RFC 4273, Definitions of Managed Objects for BGP-4
RFC 4292, IP Forwarding Table MIB
RFC 4293, Management Information Base for the Internet Protocol (IP)
RFC 4631, Link Management Protocol (LMP) Management Information Base (MIB)
RFC 4878, Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM)
Functions on Ethernet-Like Interfaces
RFC 7420, Path Computation Element Communication Protocol (PCEP) Management Information Base
(MIB) Module
RFC 7630, HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3
SFLOW-MIB revision 200309240000Z, sFlowMIB
7.36 Timing
GR-1244-CORE Issue 3, Clocks for the Synchronized Network: Common Generic Criteria
GR-253-CORE Issue 3, SONET Transport Systems: Common Generic Criteria
IEEE 1588-2008, IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
ITU-T G.1020 Appendix I, Performance Parameter Definitions for Quality of Speech and other Voiceband
Applications Utilizing IP Networks - Mean Absolute Packet Delay Variation & Markov Models
ITU-T G.107, The E Model - A computational model for use in planning
ITU-T P.564, Conformance testing for voice over IP transmission quality assessment models
RFC 3550, RTP: A Transport Protocol for Real-Time Applications - Appendix A.8
RFC 4585, Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
AVPF)
RFC 4588, RTP Retransmission Payload Format
SPACER TEXT
UNICAST ROUTING PROTOCOLS GUIDE RELEASE Standards and protocol support
22.2.R1
SPACER TEXT
Customer document and product support
Customer documentation
Customer documentation welcome page
Technical support
Product support portal
Documentation feedback
Customer documentation feedback