Project: MAN-E VNPT Hanoi Expansion 2017

Module 7:
Implementing BGP in the Service Provider Network

1
Agenda

• Introduction BGP Routing

• Implementing Basic BGP
• Introducing Route Map and Route
Policy Language
• BGP Route Selection
• BGP Route Reflector and
Confederation
• Improving BGP Convergence

2
Objectives

Introduction BGP Routing

3
Objectives
– Describe BGP terminology
– Describe autonomous systems in BGP networks
– Describe BGP routing between autonomous systems
– Describe BGP path vectors
– Describe BGP routing policies
– Describe features of BGP
– Describe the tables used by a router to store BGP
information
– Describe the four BGP message types
– Describe the multiprotocol extensions add to BGP to
support IPv6
– Describe MPLS VPNs
BGP Terminology
– Autonomous system: A collection of networks under a
single administrative domain
– Interdomain routing: Routing between the customer and
the service provider
– Internal routing: Uses IGP protocol (RIP, OSPF, IS-IS,
and so on) to exchange routing information inside the
autonomous system
– External routing: Uses EGP protocol (BGP) to exchange
routes between autonomous systems
– Two BGP implementations:
• Internal BGP (IBGP): When BGP is used inside an AS
• External BGP (EBGP): When BGP is used between autonomous systems

IBGP
AS 65001 EBGP 10.1.1.1 10.1.1.2
AS 65002
192.168.1.1 192.168.1.2
Autonomous System
–An autonomous system (AS) is a collection of networks under
a single technical administration.
• 16-bit numbers (as of January 2009, 32-bit numbers are available)
• Ranging from 1 to 65535
• Private AS: 64512–65535

–The IANA allocates AS numbers.

–IGPs operate within an AS.
–BGP is used between autonomous systems.
AS 65010 AS 65020
BGP
BGP Routing Between Autonomous Systems
– BGP is used to provide an interdomain routing system.
– BGP guarantees the exchange of loop-free routing information.
– BGP works differently than IGPs.
• BGP is a policy-based routing protocol.
• BGP controls traffic flow using multiple BGP path attributes.

AS 65020

BGP BGP
AS 65010 AS 65040

BGP

AS 65030
BGP BGP
Path Vector Functionality
–BGP announces this information:
• Paths (set of AS numbers)
• Networks that are reachable at the end of the path

–The path is described by using attributes.

–The administrator can define data flow through autonomous
systems.
Path advertised:
65020 65040 65050

AS 65010 AS 65020 AS 65040 AS 65050

BGP Routing Policies
–BGP can support any policy conforming to the hop-by-hop
(AS-by-AS) routing paradigm.

AS 65010 AS 65020 AS 65040 AS 65050

Features of BGP
BGP is a path vector protocol with the following properties:
–Reliable updates: BGP runs on top of TCP (port 179)
–Incremental, triggered updates only
–Periodic keepalive messages to verify TCP connectivity
–Rich metrics (called path vectors or attributes)
–Designed to scale to huge internetworks
AS 65010 AS 65020
BGP
BGP Databases

AS 65010 AS 65020
BGP

BGP neighbor table

List of BGP neighbors

• A list of all networks learned from

each BGP neighbor.
• Multiple paths to same destination BGP table
network can be present.
• Each path is associated with BGP
attributes.

List of best paths to destination IP routing table

networks is used to forward traffic.
BGP Message Types
BGP defines the following message types:
–Open
• Includes hold time and BGP router ID

–Keepalive
–Update
• Information for one path only (could be to multiple networks)
• Includes path attributes and networks

–Notification
• When an error is detected
• BGP connection closed after message is sent
Multiprotocol Extensions for BGP4
–BGP originally designed for IPv4:
• Carries IPv4 prefix reachability information
• Uses IPv4 for transport

–Multiprotocol extensions for BGP4:

• Enables other protocols besides IPv4
• New identifier for the address family
• Most often used in MPLS networks for MPLS VPN

–IPv6-specific extensions:
• Scoped addresses: NEXT_HOP contains a global IPv6 address and potentially a link-local address.
• NEXT_HOP and NLRI are expressed as IPv6 addresses and prefixes in the multiprotocol attributes.

–Still uses TCP for transport:

• TCP can run over IPv4, transporting IPv6 information.
• TCP can run natively over IPv6.
MPLS VPN Overview
–The customer routers are connected to the service provider
PE routers. It is used to connect multiple customer locations
via the common Layer 3 infrastructure of a service provider.
• A special VPN can be used to provide Internet connectivity.
• Routing used can be static or dynamic, depending on the service provider.

Company A Internet
Site 1
MPLS VPN
PE
PE

P
IGP PE PE

Company A Company A
IGP
Site 2 Site 3
IGP
Summary
–BGP is the external routing protocol used between
autonomous systems.
–Autonomous system is a collection of networks under a single
administration and is represented by 16-bit or 32-bit number.
–Forwarding is based on policies and not on best path. BGP
routers exchange network reachability information, called
path vectors, which are made up of path attributes.
–BGP announces set of AS numbers and netwroks that are
reachable at the end of the path. The path is described by
attributes.
–BGP router can advertise to neighboring autonomous
systems only those routes that it actually uses.
Summary (Cont.)
–BGP routers establish a TCP session and then exchange
routing tables. After that, BGP peers send only incremental
triggered updates.
–BGP uses three databases: neighbor table, BGP table, and
routing table.
–The four BGP message types are open, keepalive, update,
and notification.
–BGP4, with multiprotocol extensions, enables the use of
many address families. Address families define the type of
addressews being carried.
–MPLS VPNs are used by customers with multiple locations
that do not want to use expensive Layer 2 technologies.
Objectives

Implementing Basic BGP

17
Objectives
– Describe planning for BGP deployments
– Describe the basic configuration steps for EBGP
– Describe how networks are advertised in BGP networks
– Describe the basic configuration steps for IBGP
– Describe full-mesh IBGP networks
– Describe how to shut down a BGP neighbor
– Describe next-hop behavior in BGP
– Describe the BGP next hop self feature
– Describe configuration template support in Cisco IOS XR Software
– Describe the BGP neighbor states
– Describe BGP neighbor authentication
– Describe clearing the BGP session
Objectives (Cont.)
– Describe how to monitor BGP routes
– Describe the importance of the BGP path attributes in the path selection
– Describe the BGP weight attribute
– Describe the BGP local preference attribute
– Describe the BGP AS path attribute
– Describe the BGP multi-exit discriminator attribute
Planning for BGP
– Define network requirements.
– Define internal connectivity.
– Define external connectivity to service provider.
– Gather required parameters.
AS numbers?

Neighbor IP address?

BGP AS 64501 BGP AS 64500

IBGP EBGP IBGP

Networks to be advertised?
Configure Basic EBGP
router bgp 64500
1. Define the BGP address-family ipv4 unicast
process. !
neighbor 192.168.101.11
2. Establish an EBGP remote-as 64501
router bgp 64501
neighbor relationship.
neighbor 192.168.101.10 remote-as 64500 address-family ipv4 unicast

BGP AS 64501 BGP AS 64500

EBGP
192.168.101.11
192.168.101.10

RP/0/RSP0/CPU0:PE1#show bgp summary

BGP router identifier 10.1.1.1, local AS number 64500
< text omitted >
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 5 5 5 5 5 5

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

192.168.101.11 0 64501 4302 3909 5 0 0 2d16h 0
Advertise Networks route-policy pass
pass
– Two options Route policy end-policy
!
• Configure the local networks to router bgp 64500
be advertised, and include address-family ipv4 unicast
them in BGP.
network 10.1.1.1/32
• Use redistribution from IGP to !
BGP. 3. Advertise the neighbor 192.168.101.11
networks. remote-as 64501
address-family ipv4 unicast
router bgp 64501 route-policy pass in
Apply Route policy route-policy pass out
network 10.1.10.1 mask 255.255.255.255

BGP AS 64501 BGP AS 64500

EBGP
10.1.10.1/32 10.1.1.1/32
192.168.101.11
192.168.101.10

RP/0/RSP0/CPU0:PE1#show bgp
< text omitted >
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.1/32 0.0.0.0 0 32768 i
*> 10.1.10.1/32 192.168.101.11 0 0 64501 i

Processed 2 prefixes, 2 paths

Configure Basic IBGP
IBGP neighbor
router bgp 64500
neighbor 10.0.1.1
router bgp 64501 remote-as 64500
neighbor 10.1.10.2 remote-as 64501 update-source Loopback0
neighbor 10.1.10.2 update-source Loopback0 address-family ipv4 unicast

Use Loopback 0
BGP AS 64501 for IBGP peering. BGP AS 64500

IBGP IBGP
192.168.101.11
192.168.101.10
Lo0 Lo0 Lo0 Lo0
10.1.10.2 10.1.10.1 10.1.1.1 10.0.1.1

RP/0/RSP0/CPU0:PE1#show bgp summary

BGP router identifier 10.1.1.1, local AS number 64500
< text omitted >
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 7 7 7 7 7 7

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

10.0.1.1 0 64500 2 2 0 0 0 00:00:04 0
192.168.101.11 0 64501 4377 3977 7 0 0 2d17h 1
Full-Mesh IBGP
router bgp 64501 router bgp 64501
neighbor 10.0.1.2 neighbor 10.0.1.1
remote-as 64501 remote-as 64501
update-source Loopback0 update-source Loopback0
address-family ipv4 unicast address-family ipv4 unicast
neighbor 10.0.1.3 neighbor 10.0.1.3
remote-as 64501 remote-as 64501
update-source Loopback0 update-source Loopback0
address-family ipv4 unicast address-family ipv4 unicast

BGP AS 64501
IBGP
Lo0 Lo0
10.0.1.1 10.0.1.2

Lo0
10.0.1.3

router bgp 64501

neighbor 10.0.1.1 remote-as 64501
neighbor 10.0.1.1 update-source Loopback0
neighbor 10.0.1.2 remote-as 64501
neighbor 10.0.1.2 update-source Loopback0
BGP Support for IPv6
To exchange IPv6 routes router bgp 64500
router bgp 64501 neighbor 192.168.101.11
neighbor 192.168.101.10 remote-as 64500 remote-as 64501
address-family ipv6 unicast address-family ipv4 unicast
neighbor 192.168.101.10 activate address-family ipv6 unicast

BGP AS 64501 BGP AS 64500

EBGP
192.168.101.11
192.168.101.10
IPv4 and IPv6 networks IPv4 and IPv6 networks

IPv6 neighbor router bgp 64500

router bgp 64501 neighbor 2001:db8:192:168:101::11
neighbor 2001:db8:192:168:101::10 remote-as 64500 remote-as 64501
address-family ipv6 unicast address-family ipv6 unicast
neighbor 2001:db8:192:168:101::10 activate

BGP AS 64501 BGP AS 64500

EBGP
2001:db8:192:168:101::11
2001:db8:192:168:101::10
IPv4 and IPv6 networks IPv4 and IPv6 networks
Shutting Down a BGP Neighbor
Shut down BGP
neighbor relationship.
router bgp 64500
router bgp 64501 neighbor 192.168.101.11
neighbor 192.168.101.10 shutdown shutdown

BGP AS 64501 BGP AS 64500

Shutdown (EBGP)
192.168.101.11
192.168.101.10

RP/0/RSP0/CPU0:PE1#show bgp summary

BGP router identifier 10.1.1.1, local AS number 64500
< text omitted >
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
192.168.101.11 0 64501 4406 4007 0 0 0 00:06:10 Idle (Admin)
Next-Hop Behavior

BGP AS 64501 BGP AS 64500

EBGP
IBGP IBGP
192.168.101.11
192.168.101.10
Lo0 Lo0 Lo0 Lo0
10.1.10.2 10.1.10.1 10.1.1.1 10.0.1.1

Route sent with next-hop

192.168.101.11 Route sent with next-hop
192.168.101.11

IBGP does not

modify next hop.
BGP Next Hop Self
Forces all updates for IBGP neighbor to be advertised
with this router as the next hop—the same IP address
router bgp 64500
as for the source of the BGP packet.
neighbor 10.0.1.1
router bgp 64501 address-family ipv4 unicast
neighbor 10.1.10.2 next-hop-self next-hop-self

BGP AS 64501 BGP AS 64500

EBGP
IBGP IBGP
192.168.101.11
192.168.101.10
Lo0 Lo0 Lo0 Lo0
10.1.10.2 10.1.10.1 10.1.1.1 10.0.1.1

Route sent with next-hop Route sent with next-hop

192.168.101.11 10.1.1.1

IBGP modifies
next hop.

Route sent with next-hop Route sent with next-hop

10.1.10.1 192.168.101.10
Configuration Templates
Cisco IOS XR
The af-group is used to group address family-specific neighbor commands within an IPv4, IPv6, or VPNv4,
address family.
router bgp 1
af-group afmcast1 address-family ipv4
Define address family group.
multicast
The session-group allows you to create a session group from which neighbors can inherit address family-
independent configuration.
router bgp 1
Define session group.
session-group session1

The neighbor-group helps you apply the same configuration to one or more neighbors.

router bgp 1
neighbor-group nbrgroup1
Define neighbor group.
!
router bgp 1
neighbor-group nbrgroup1 Use neighbor group.
address-family ipv4 unicast

Cisco IOS/IOS XE
The BGP peer group groups BGP neighbors who share the same policies.

router bgp 1 Define peer group.

neighbor peer-group-name peer-group
BGP States
When establishing a BGP session, BGP goes through
the following states:
1. Idle: The router is searching the routing table to see
whether a route exists to reach the neighbor.
2. Connect: The router found a route to the neighbor and has
completed the three-way TCP handshake.
3. Open sent: The open message is sent, with the parameters
for the BGP session.
4. Open confirm: The router received an agreement on the
parameters for establishing a session.
• Alternatively, the router goes into the active state if there
is no response to the open message.
5. Established: Peering is established; routing begins.
BGP Established and Idle States
– Idle: The router cannot find the address of the neighbor in the routing
table.
• Solution: Check for an IGP problem. Is the neighbor announcing
the route?
– Established: This is the proper state for BGP operations.
A number in the state column
RP/0/RSP0/CPU0:PE1#show bgp summary indicating the number of routes
BGP router identifier 10.1.1.1, local AS number 64500 learned from this neighbor.
< text omitted >
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 7 7 7 7 7 7

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

10.0.1.1 0 64500 355 343 36 0 0 00:16:28 4
192.168.101.11 0 64501 4444 4051 36 0 0 00:16:18 1

RP/0/RSP0/CPU0:PE1#show bgp neighbor

< text omitted >
BGP neighbor is 192.168.101.11
Remote AS 64501, local AS 64500, external link
Remote router ID 10.1.10.1
BGP state = Established, up for 00:16:18
Last read 00:00:49, Last read before reset 00:16:52
Hold time is 180, keepalive interval is 60 seconds
Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
< text omitted >
BGP Active State
Active: The router has sent an open packet and is
waiting for a response.
–The state may cycle between active and idle.
–The neighbor may not know how to get back to
this router due to the following reasons:
• There is no route to the source IP address of the BGP open packet.
• The neighbor is peering with the wrong address.
• There is no neighbor statement for this router.
• The AS number is misconfigured. Active does not mean that BGP
peering is established.

RP/0/RSP0/CPU0:PE1#show bgp summary

BGP router identifier 10.1.1.1, local AS number 64500
< text omitted >
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.0.1.1 0 64500 0 343 0 0 0 00:00:00 Active
BGP Neighbor Authentication
BGP neighbor
authentication
router bgp 64500
router bgp 64501 neighbor 192.168.101.11
neighbor 192.168.101.10 password cisco password encrypted cisco

BGP AS 64501 BGP AS 64500

EBGP
192.168.101.11
192.168.101.10

– BGP authentication uses MD5.

– Configure a key—password; the router generates a
message digest (is sent), or hash, of the key (is not sent)
and the message.
– The router generates and checks the MD5 digest of every
segment that is sent on the TCP connection.
– The router authenticates the source of each routing update
packet that it receives.
Clearing the BGP Session
– When policies change, the change takes effect immediately.
– The next time that a prefix or path is advertised or received,
the new policy is used. This can take a long time for all
networks.
– You must trigger an update for immediate action.
Hard reset
clear bgp *

Soft reset Soft reconfiguration feature or

clear bgp ipv4 unicast 192.168.101.11 soft out ROUTE_REFRESH capability is
not required.
clear bgp ipv4 unicast 192.168.101.11 soft in

Soft reconfiguration feature or

ROUTE_REFRESH capability is
EBGP required.

RP/0/RSP0/CPU0:PE1#show bgp neighbor 192.168.101.11 | include Route refresh

Route refresh: advertised and received
Route refresh request: received 2, sent 1
Monitoring BGP Routes
BGP Filters BGP Filters

BGP Table

Incoming BGP Outgoing BGP

neighbor neighbor

show bgp

show bgp neighbor IP-address advertised

show bgp neighbor IP-address routes

show bgp neighbor IP-address received

Only available when inbound soft

reconfiguration is active
BGP Path Selection
– The BGP table can have several paths for each network to
choose from.
– BGP is not designed to perform load balancing:
• Paths are chosen because of policy.
• Paths are not chosen based upon bandwidth.
– The BGP selection process eliminates any multiple paths
until a single best path remains.

All IBGP and EBGP routes Best path selected

Routing
BGP path table
BGP Table selection
Route Selection Decision Process
•Consider only (synchronized) routes with no AS loops and a valid next hop. The next steps
in the evaluation process are:

1. Prefer the highest weight (local to router).

2. Prefer the highest local preference (global within AS).
Prefer the route originated by the local router (next hop =
3.
0.0.0.0).
4. Prefer the shortest AS path.
5. Prefer the lowest origin code (IGP < EGP < incomplete).
Prefer the lowest MED (exchanged between autonomous
6.
systems).
7. Prefer the EBGP path over the IBGP path.
8. Prefer the path through the closest IGP neighbor.
9. Prefer the oldest route for EBGP paths.
10. Prefer the path with the lowest neighbor BGP router ID.
11. Prefer the path with the lowest neighbor IP address.
BGP Weight
–Weight is an attribute that is proprietary to Cisco.
–Weight is not sent to any BGP neighbors.
–It is local to the router only.
–Paths with the highest weight value are preferred.
AS 65010 AS 65020 AS 65030
172.20.0.0

R4 R3 R2

Weight = 150 Weight = 200

R1

AS 65040
BGP Local Preference
– Used to select the outbound EBGP path
– Sent to IBGP neighbors only (and only within the AS)
– Stripped in the outgoing EBGP updates except in the EBGP updates
with confederation peers
– Local preference attribute is well known and discretionary
– Default value = 100
– Paths with highest local preference value are preferred
AS 65010 AS 65020 AS 65030
172.16.0.0

R4

LP = 200
Traffic
AS 65040 AS 65050 R1 needs to
go to
AS 65010
R2
LP = 150 R3
BGP AS Path
–Fourth BGP path selection criteria
–Prefer shorter AS paths (only length is compared)
–Influences the inbound path selection in a
multihomed AS
–Manual manipulation of AS path length—AS path
prepending
–AS path prepending specified per neighbor by
complex criteria
BGP Multi-Exit Discriminator
–The paths with the lowest MED (also called the metric) value
are the most desirable.
–MED is used to advertise an exit path to be used by EBGP
neighbors to reach networks owned by this AS.
–The MED attribute is optional and nontransitive.

AS 65010
172.20.0.0

R2
R3
MED = 150

MED = 200
AS 65020
172.16.0.0
R1
R1
Summary
– For a BGP configuration, the following must be defined: BGP
requirements, BGP parameters, and connectivity.
– Basic EBGP configuration requires three main steps: define the
BGP process, establish the neighbor relationship, and advertise
the networks into BGP.
– Networks can be advertised into BGP using the network command
or by redistribution.
– It is recommended to use Loopback interfaces when establishing
IBGP sessions.
– Full-mesh IBGP is required because of the split horizon rule.
– To exchange IPv6 networks over BGP, you have to activate a
neighbor for IPv6 address family.
– You can use the shutdown command to manually shut down a
BGP neighbor.
Summary (Cont.)
– By default, next-hop over EBGP session is IP address of a router
that is sending the update. Next-hop over IBGP session is as
advertised by EBGP, and should not change.
– You can use the next-hop-self command to change the default
next-hop behavior.
– You can use configuration templates to group configuration that
can be applied to several BGP neighbors.
– When establishing a BGP session, the BGP goes through the
following states: idle, connect, open sent, open confirm, and
established.
– BGP supports MD5 authentication to authenticate each received
routing packet.
– You should trigger a BGP update by resetting a BGP session
when you change routing policy.
Summary (Cont.)
– Use various show commands to verify BGP operations.
– After BGP receives updates about multiple destinations from
different autonomous systems, it follows a multiple-step process
for selecting the best route to reach a destination; the best route is
a candidate for the routing table.
– Weight is Cisco‘s proprietary attribute that is configured locally on
a router and is not propagated to any other routers.
– Local preference is a well-known discretionary attribute that
provides information to routers in the AS about the path that is
preferred for exiting the AS.
– AS path length is the fourth path selection criteria. The shortest AS
path is preferred.
– MED is an indication to EBGP neighbors about the preferred path
into an AS.
Objectives

Introducing Route Maps and

Routing Policy Language

45
Objectives
– Provide an overview of route maps
– Describe route maps processing when processing a routing update
– Describe route maps syntax
– Provide a route map example
– Describe the characteristics of RPL
– Provide an RPL example
– Describe RPL pass and drop actions
– Describe RPL conditions
– Describe RPL operators
– Describe RPL boolean operators
– Describe how to nest statements in RPL
– Describe how to set attributes and parameters in RPL
– Describe how to set BGP attributes and parameters using RPL
Objectives (Cont.)
– Show an example of setting BGP attributes and parameters using RPL
– Describe how to set OSPF and IS-IS parameters using RPL
– Describe how to use parameterization in RPL
– Describe how to apply routing policies
– Describe how to maintain routing policies
– Describe value sets that can be used in RPL
– Describe AS path sets
– Describe standard community sets
– Describe prefix sets
– Describe how to monitor routing policies
– Describe how to test routing policies
– Describe how to translate route maps to routing policies
Route Maps Overview
–Route maps are a simple language to support complex
routing policies, in addition to filtering.
–Route maps are uniquely identified by a case-sensitive name.
–Each route map consists of one or more statements.
–Each statement contains zero or more match commands.
–Each statement contains zero or more set commands used to
modify routing updates.
–Route maps are available in Cisco IOS/IOS XE Software.
(Cisco IOS XR Software uses the Routing Policy Language.)
Route Map Processing for Routing Update
Route Map
Statement 10
Yes Yes No
Update Match? Permit Set Send Update

No Yes
No Drop Set

Statement 20
Yes Yes No
Match? Permit Set Send

No Yes
No Drop Set

Statement N
Yes Yes No
Match? Permit Set Send

No Yes
No Implicit drop Drop Set
Route Maps Syntax
•Additional route-map options:
– The continue command can be used to jump to another statement
instead of exiting.
– Policy lists can be used to modularize and group match statements.

route-map Policy1 permit 10 route-map Policy2 permit 10

match condition match policy-list Policy3
continue 40
!
route-map Policy1 permit 20
…
! route-map Policy3 permit 10
route-map Policy1 permit 40 …
… route-map Policy3 permit 20
! …
route-map Policy1 permit 1000 route-map Policy3 permit 30
Route Maps Syntax (Cont.)
– Each route map is identified using a case-sensitive name.
– Each route map can have one or more ordered statements identified using the
sequence number.
– Each route-map statement can filter updates using permit or deny options.
– Each statement processes updates matched by the match command
– Each statement can optionally modify or set parameters in an update.
– Match conditions of the same type are evaluated using a logical OR operator;
match conditions of different types are evaluated using a logical AND operator.
Router(config)#
route-map map-tag [permit | deny] [sequence-number]
match condition
match condition
set parameter value
set parameter value
Example: Route Maps
–Preferred paths for route-map Policy1 permit 10
match ip address prefix-list PL1
specific prefixes set local-preference 200

–Backup paths for !

route-map Policy1 permit 20
specific prefixes match ip address prefix-list PL2
set local-preference 50
–Preferred paths for !
prefixes based on AS route-map Policy1 permit 30

path match as-path APACL1

set local-preference 200

–Backup paths for !

route-map Policy1 permit 40
prefixes based on AS match as-path APACL2
path set local-preference 50
!
–Explicit permit at the route-map Policy1 permit 1000

end
Example: Route Maps (Cont.)
–The first route-map
statement processes
routes matched by
prefix list PL1 or PL2 route-map Policy1 permit 10
match ip address prefix-list PL1 PL2
and AS path access match as-path APACL1
list APACL1. set local-preference 200
set metric 1000
–These routes are !

assigned local route-map Policy1 permit 1000

preference 100 and

MED 1000.
–All other routes are
passed unchanged.
Routing Policy Language
–RPL replaces route maps in Cisco IOS XR Software.
–RPL is a simple, yet powerful language, designed to process
routing updates.
–RPL addresses the deficiencies of route maps in Cisco
IOS/IOS XE Software:
• Better modularity
• Better reusability
• Parameterization
• Nesting of policies and conditions
• Powerful match options
• Reusable value sets
RPL Modularity
–Each routing policy is identified by a case-sensitive name.
–Entire policy is defined between route-policy and end-policy
commands.
–Main RPL functions:
• Filtering of updates (pass and drop commands)
• Modification of attributes (set commands) Implicitly permit all routes by
Permit all routes. setting at least one attribute.

route-policy PermitAll route-policy LP100

pass set local-preference 100
end-policy end-policy
RPL Example
• EBGP
–Note: Cisco IOS XR Permit all routes to
EBGP peers.
Software does not
automatically send route-policy PermitAll
pass
BGP updates to end-policy

external peers. !
router bgp 1
–A routing policy is neighbor 1.2.3.4
remote-as 64111
required to forward address-family ipv4 unicast
updates. route-policy PermitAll out
!
!
!
RPL Pass and Drop Actions
– Using the explicit pass
command continues the route-policy DropOrPass1
Drop!
end-policy
processing of route policy.
– Using the explicit drop route-policy DropOrPass2
pass Pass!
command stops end-policy
processing of route policy.
route-policy DropOrPass3
– The default action is drop. drop Drop!
end-policy
– If any modification is
applied to a route (e.g. route-policy DropOrPass4
Pass!
set med 100
set), it is an implicit pass. end-policy

route-policy DropOrPass5
pass Drop!
drop
pass
end-policy
RPL Conditions
–RPL uses various match options for conditional update
processing.
–Condition syntax: route-policy SetLP
if med eq 10 then
if attribute operator value then set local-preference 200
elseif med eq 20 then
… do something … set local-preference 150
else
elseif attr operator value then set local-preference 50
endif
… do something else … end-policy

else
… do something else …
endif
RPL Operators
Comparing attributes against values supports these operators:
• eq : An attribute numerically equal to specified value
• le : An attribute numerically lower than or equal to a specified value
• ge : An attribute numerically greater than or equal to a specified value
• is : An attribute equal to a specified value
• in : An attribute contained in a value set
• Many other attribute-specific options
route-policy SetLP
if med le 19 then
set local-preference 200
Simple elseif med eq 20 then
conditions set local-preference 150
elseif med ge 21 then
set local-preference 50
endif
end-policy
RPL Boolean Operators
–Multiple match options can be combined using Boolean
operators:
• and : both conditions must match
• or : at least one condition must match
• not : negate the following condition
Using composite
conditions

route-policy SetLP
if med eq 10 and not local-preference eq 100 then
set local-preference 200
elseif med eq 20 or local-preference eq 200 then
set local-preference 150
else
set local-preference 150
endif
end-policy
RPL Boolean Operators (Cont.)
–Multiple match options can be combined using Boolean
operators:
• not : highest precedence
• and : higher precedence than or, lower than not
• or : lowest precedence

–Influence precedence by grouping using parentheses.

if med eq 10 and not local-preference eq 100 or med eq 50 then

vs.
if med eq 10 and (not local-preference eq 100 or med eq 50) then
vs.
if med eq 10 and not (local-preference eq 100 or med eq 50) then
RPL Nesting
–Two types of nesting are supported:
• “if” statement within another “if” statement
• A routing policy within another routing policy

–Multiple levels of nesting are supported.

Nested “if” statements Nested policies

route-policy SetC route-policy SetC

if med eq 10 then if local-preference eq 100 then
if local-preference eq 100 then set community (1:10) additive
set community (1:10) additive endif
endif end-policy
endif
end-policy route-policy MatchMED
if med eq 10 then
apply SetC
endif
end-policy
RPL Setting Attributes and Parameters
– Use the set command to assign values to attributes and
parameters.
– Note: All set statements are processed when the processing of
policy completes (e.g. matching on a previously set attribute is not
possible).
Original update
route-policy SetLP MED= 10 LP=100 Weight=0
Match
if med eq 10 then 1
set local-preference 200
endif
Match
if local-preference eq 100 then 2 Set
set weight 100
Set
endif 3
if local-preference eq 200 then No match!
set weight 200
endif
end-policy 4 MED= 10 LP=200 Weight=100
Modified update
RPL Setting Attributes and Parameters (Cont.)
–Note: Last set wins when multiple sets are evaluated for a
unique parameter.

MED = 10 LP = 100 Original update

route-policy SetLP
set local-preference 100
set local-preference 200
set local-preference 300
end-policy

MED = 10 LP = 300 Modified update

RPL Setting Attributes and Parameters (Cont.)
–Note: All set commands are evaluated in the same order for
nonunique attributes and operations.

Original update Original update

AS Path: 10 20 30 Community: 1:10, 1:20

route-policy Prepend route-policy SetComm

prepend as-path 40 2 set community (1:100) additive
prepend as-path 40 3 set community (1:200) additive
end-policy end-policy

AS Path: 40 40 40 40 40 10 20 30 Community: 1:10, 1:20, 1:100, 1:200

Modified update Modified update
RPL Setting BGP Attributes and Parameters
• Standard BGP community attribute:
set community (value [value2 …]) [additive]

• Extended BGP community attribute:

set extcommunity (value [value2 …]) [additive]

• BGP dampening parameters:

set dampening [halflife value] [max-suppres value] [reuse value] [suppress value]

• Local preference attribute:

set local-preference value

• MED attribute:
set med {[+|-]value | igp-cost | max-reachable}
RPL Setting BGP Attributes and Parameters (Cont.)
• Delete standard BGP community attributes:
• delete community {all | [not] in community-set}

• Delete extended BGP community attributes:

• delete extcommunity rt {all | [not] in extcomm-set}

• Prepend AS path:
• prepend as-path {AS | most-recent} [count]

• Replace a sequence of AS numbers with local AS:

• replace as-path {private-as | ‘AS1 AS2 …’}

• Suppress route if aggregated:

• suppress-route

• Unsuppress route if aggregated:

• unsuppress-route
Example: Setting BGP Attributes and Parameters
Route Flap Dampening
2200 points
2000 Suppress Limit

1100 points
1000

750 Reuse Limit

Forget Limit

t
Halve
Time

dampened

flap flap flap

Example: Setting BGP Attributes and Parameters
Conditional BGP Dampening
Conditional BGP dampening, where smaller prefixes
are more aggressively punished than larger prefixes

router bgp 1
address-family ipv4 unicast
bgp dampening route-policy BDamp
!
!
route-policy BDamp
if destination in (0.0.0.0/0 ge 25) then
set dampening max-suppress 30 halflife 10 reuse 750 suppress 1000
elseif destination in (0.0.0.0/0 ge 21) then
set dampening max-suppress 15 halflife 7 reuse 750 suppress 2000
elseif destination in (0.0.0.0/0 ge 17) then
set dampening max-suppress 10 halflife 5 reuse 750 suppress 3000
else
set dampening max-suppress 5 halflife 3 reuse 750 suppress 4000
endif
end-policy
RPL Setting OSPF and IS-IS Parameters
• OSPF metric type:
• set metric-type {type-1 | type-2]

• OSPF metric:
• set ospf-metric value

• IS-IS metric type:

• set metric-type {external | internal}

• IS-IS metric type:

• set isis-metric value

• IS-IS level for redistributed routes:

• set level {level-1 | level-2 | level-1-2}
RPL Parameterization
• RPL supports two types of parameters:
–Global parameters:
• Defined globally using the policy-global command
• Available for use in all routing policies

–Parameters passed to a nested routing policy:

• Defined when creating a routing policy
• Available in match and set statements within a policy or when calling another nested routing
policy
RPL Global Parameters
–Parameters are defined using the policy-global command,
and are separated by commas.
–Values are defined within single quotes.
–Parameters are referenced by prepending the $ sign to the
name of the parameter.
Defining global variables Using global variables

policy-global route-policy SetMED

# Global variables if as-path originates-from ’$AS’ then
AS '65001', set med $DefMED
Lo0 '10.1.2.3', endif
EBGP1 '192.168.1.1', end-policy
EBGP2 '192.168.2.1',
DefWeight '0',
DefLP '100',
DefMED '0'
end-global
RPL Passed Parameters
–Declare parameters when creating a routing policy.
–Nesting policies with parameters allows for greater
modularization and optimization of policies.
Policy using passed Using a nested policy and
parameters passing parameters to it

route-policy SetMED($med, $as) route-policy ProcessUpdates

if as-path originates-from '$as' then if as-path neighbor-is '100' then
set med $med apply SetMED(50,100)
else elseif as-path neighbor-is '200' then
set med max-reachable apply SetMED(150,200)
endif endif
end-policy end-policy
! !
Applying Routing Policies
–Design a routing policy.
–Configure the policy.
–Test the policy by using show commands.
–Apply the policy if it is correct.
–Use routing policies in many places (attach points):
• Routing updates (e.g. BGP, OSPF, EIGRP, IS-IS, RIP)
• Route origination (e.g. redistribution, network commands)
• Route insertion into routing table
• show commands to filter output
Applying Routing Policies (Cont.)
• Attach Points
OSPF Database BGP Table
Redistribution
default orig. network
area in neighbor in & out
aggregation
area out default orig.
show bgp
IS-IS Database dampening
retain RT clear dampening
default orig.
allocate label debug update
Import filter EXEC
EIGRP Database
default in/out Export tagging Table-policy Table-policy
filter in/out
filter intf. in/out VRF IPv4 IPv6
Routing Routing
RIP Database table table

default orig.
Static routes
filter in/out
filter intf. in/out Connected routes
Applying Routing Policies (Cont.)
• Validity Checking
–RPL validity checking is done in two phases:
• Syntax checking and value checking are performed during policy configuration.
RP/0/RP1/CPU0:CRS(config-rpl)#set med 289314790283408912634789
^
% Invalid input detected at '^' marker.

• Applicability of a policy for a given attach point is checked during configuration

commit.
RP/0/RP1/CPU0:CRS(config-bgp-af)#commit
% Failed to commit one or more configuration items during an atomic operation, no
changes have been made. Please use 'show configuration failed' to view the errors
RP/0/RP1/CPU0:CRS(config)# show config failed
!! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS
router bgp 1
address-family ipv4 unicast
redistribute connected route-policy t9
!!% Could not find entry in list: Policy [t9] uses the 'ospf-metric' attribute.
There is no 'ospf-metric' attribute at the BGP redistribution-dflt attach point.
Maintaining Routing Policies
– Trying to edit an existing routing policy through configuration-mode
CLI will result in the policy being rewritten:
RP/0/RP1/CPU0:CRS(config)#route-policy R1
% WARNING: Policy object 'route-policy R1' exists! Reconfiguring it via CLI
will replace current definition. Use 'abort' to cancel.
RP/0/RP1/CPU0:CRS(config-rpl)# abort

– Use EXEC-mode editor instead.

– Three editors are available:
• GNU Nano
• Emacs
• VIM
– Modify the policy, and complete the process:
• Save changes.
• Exit editor.
• Commit changes.
Maintaining Routing Policies (Cont.)
• Using an Editor
–An editor can be used for routing policies and sets.
RP/0/RP1/CPU0:CRS#edit ?
as-path-set edit an as-path-set
community-set edit a community-set
extcommunity-set edit an extended-community-set
policy-global edit policy-global definitions
prefix-set edit a prefix-set
rd-set edit a rd-set
route-policy edit a route-policy

–Invoke the desired editor.

RP/0/RP1/CPU0:CRS#edit route-policy RP1 ?
emacs to use Micro Emacs editor
inline to use command line
nano to use nano editor
vim to use Vim editor
<cr>
Value Sets
•RPL can match attributes against a set of multiple values:
– Inline sets using parentheses for one-time use as-path-set
– Named value sets for reusability community-set
extcommunity-set
•Value sets: prefix-set
– AS path in AS path set rd-set

– Standard community in community set

– Extended community in extcommunity set
– Prefix in prefix set Named value set
– Route distinguisher in route distinguisher set
xy-set set-name
Inline value set value,
value2
route-policy RP end-set
if attribute in (value, value2, …) !
then route-policy RP
set local-preference 200 if attr in set-name then
endif set local-preference 200
end-policy endif
end-policy
AS Path Sets
–Define an AS-path set using the as-path-set command.
–Use one or more comma-separated ios-regex commands to
define regular expression that define set membership.
–Use the in operator in routing policy to test for membership of
AS path in AS path set.
Match prefixes originating in Use an AS path set in a policy to match
defined autonomous systems. prefixes based on AS path attribute.

as-path-set PreferredOriginators route-policy RP

ios-regex ’_10$’, if as-path in PreferredOriginators then
ios-regex ’_20$’, set local-preference 200
ios-regex ’_30$’, endif
ios-regex ’_40$’ end-policy
end-set
AS Path Sets (Cont.)

Predefined matching criteria Description

is-local matches any prefix with an empty AS path attribute
(equals regular expression '^$‘)

neighbor-is path matches based on first ASN in the AS Path

attribute (equals regular expression '^path_‘)

originates-from path matches based on last ASN in the AS Path attribute

(equals regular expression '_path$')

passes-through ASN matches based on ASN anywhere in the AS Path

(equals regular expression '_path_‘)

length len matches AS paths based on number of ASNs in the

path
unique-length len matches AS paths based on number of unique
ASNs in the path
AS Path Set Examples

Using built-in AS-Path Equivalent regular

match options expressions

route-policy RP route-policy RP
if as-path is-local then if as-path in (ios-regex '^$')
set local-preference 200 then
endif set local-preference 200
if as-path neighbor-is '20' endif
then if as-path in (ios-regex '^20_')
set local-preference 190 then
endif set local-preference 190
if as-path originates-from '20' endif
then if as-path in (ios-regex '_20$')
set local-preference 180 then
endif set local-preference 180
if as-path passes-through '20' endif
then if as-path in (ios-regex '_20_')
set local-preference 170 then
endif set local-preference 170
end-policy endif
end-policy
Standard Community Sets
–Define a standard community set using the community-set
command.
–Use one or more comma-separated match options:
• ios-regex commands to define regular expressions that define set membership
• numbered membership matching
• membership matching using well-known standard communities

–Use the matches-any operator to match routes that have at

least one community in the community set.
–Use the matches-every operator in routing policy to match
routes that have all communities in the community set.
Standard Community Set RegExp Matching
–Use one or more comma-separated ios-regex commands to
define regular expressions that define set membership.
Setting Local Preference
based on community
matching using regular
expressions

community-set ImpComms community-set ImpComms

ios-regex ’123:10..’, ios-regex ’123:[12]0..’,
ios-regex ’123:20..’ end-set
end-set

route-policy Comm2LP
if community matches-any ImpComms then
set local-preference 200
endif
end-policy
Standard Community Set Numbered Matching
•Use numbered matching:
–AS:num
–AS:[range] Setting Local Preference
based on numbered
–AS:* community matching

community-set ImpComms
123:1010
123:[2000..2099]
999:*
end-set
!
route-policy Comm2LP
if community matches-any ImpComms then
set local-preference 200
endif
end-policy
Standard Community Set Named Matching
•Use identifiers for well-known communities:
– Internet : Match all communities.
– local-as :Keep tagged prefixes in the local AS.
– no-advertise :Prevent tagged prefixes from being advertised to any peer.
– no-export :Prevent tagged prefixes from being announced to EBGP peers.

Prevent sending of core Delete all communities

subnets to external peers. on incoming updates.

router bgp 1 route-policy DeleteAllComms

address-family ipv4 unicast delete community in (internet)
redistribute connected route-policy end-policy
NoExport !
! router bgp 1
route-policy NoExport neighbor 1.2.3.4
set community no-export address-family ipv4 unicast
! route-policy DeleteAllComms in
!
Prefix Sets
–Used to match prefixes in routing protocol updates:
Prefix[/length [{le | ge | eq} mask-len]]
Various prefix sets Various prefix sets

prefix-set PrivatePrefixes prefix-set DefaultRoute

10.0.0.0/8 le 32, 0.0.0.0/0
172.16.0.0/12 le 32, end-set
192.168.0.0/16 le 32 !
end-set prefix-set AllPrefixes
! 0.0.0.0/0 le 32
prefix-set CoreLoopbacks end-set
172.16.1.0/24 eq 32 !
end-set prefix-set SmallPrefixes
! 0.0.0.0/0 ge 24
prefix-set HostRoutes end-set
0.0.0.0/0 eq 32 !
end-set prefix-set
SmallPrefixesExceptHostRoutes
0.0.0.0/0 ge 24 le 31
end-set
Monitoring Routing Policies
–Use the show rpl route-policy [policy-name] [detail]
commands to display the policies.
–Detailed output also displays all referenced objects (e.g. sets
and nested route policies). Display a policy and all
other associated objects.

RP/0/RP1/CPU0:CRS# show rpl route-policy MgmtRTExport detail

extcommunity-set rt MgmtRT
23456:100,
23456:200
end-set
!
prefix-set MgmtLoopbacks
10.1.1.0/24 le 32
end-set
!
route-policy MgmtRTExport
if destination in MgmtLoopbacks then
set extcommunity rt MgmtRT
endif
end-policy
!
Determining Attach Points
–Use the show rpl route-policy policy-name attachpoints
commands to list the attach points of the policy.
–Detailed output also displays all referenced objects (e.g. sets
and nested route policies).
Display attach points
for a routing policy.

RP/0/RSP0/CPU0:PE1#show rpl route-policy pass attachpoints

Thu Nov 17 19:50:52.025 UTC

BGP Attachpoint: Neighbor

Neighbor/Group type afi/safi in/out vrf name

--------------------------------------------------------------------------------
192.168.101.11 -- IPv4/uni in default
192.168.101.11 -- IPv4/uni out default
Testing Routing Policies
– Some policies can be tested (e.g. outbound BGP filter).
– Use the show bgp route-policy policy-name command to list BGP
entries permitted by the policy.
– Note: Attributes modified by the policy are not displayed.
Test a new policy to
filter outgoing updates.

RP/0/RP1/CPU0:CRS# show bgp route-policy FilterOut

BGP router identifier 0.0.0.0, local AS number 1
BGP generic scan interval 60 secs
BGP table state: Active
BGP main routing table version 30
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.4.100.0/30 0.0.0.0 0 200 32768 ?

Processed 1 prefixes, 1 paths

RP/0/RP1/CPU0:CRS#
Translating Route Maps to Routing Policies
–When you migrate from Cisco IOS/IOS XE Software to Cisco
IOS XR Software, use the following guidelines to translate
route maps to policies:
• Each numbered entry is one if statement.
• Each match option is one condition:
– Match conditions of the same type should be joined using the OR logical operator.
– Match conditions of different types should be joined using the AND logical operator.
– Use parentheses to maintain proper precedence.
Translating Route Maps to Routing Policies (Cont.)
route-map RM permit 10
match ip address prefix-list PL1 Sample route map
set local-preference 200
!
route-map RM permit 20
match ip address prefix-list PL2
set local-preference 150
!

Translated routing
policy

route-policy RP
if destination in PL-Set1 then
set local-preference 200
elseif destination in PL-Set2 then
set local-preference 150
endif
end-policy
Summary
– Route maps are a simple language to support complex routing policies.
– A route map is processed in a top-down fashion.
– Route maps support modularity and reusability.
– There is implicit deny at the end of a route map.
– The RPL is a newer mechanism that was introduced into Cisco IOS XR
Software as a replacement and improvement upon the route maps.
– In Cisco IOS XR Software, BGP updates are not forwarded to an external
neighbor unless an outbound policy is attached to the neighbor.
– Set action in a route policy also implicitly allows an update.
– RPL uses conditional statement syntax that is found in many programming
languages.
– RPL conditions can use a variety of operators, such as eq, le, ge and others.
– You can use boolean operators to create complex compound conditions.
Summary (Cont.)
– You can nest one routing policy inside another to achieve modularity and
reusability.
– You can use the set RPL action to modify attributes.
– You can use RPL to manipulate BGP attributes.
– BGP route flap dampening is a feature designed to make BGP more stable
and scalable by punishing routes that flap.
– You can use RPL to change OSPF or IS-IS parameters.
– In order to make policies modular and reusable, you can use parameters in
place of fixed values when calling nested policies.
– You can apply routing policies to many attach points, such as redistribution
between any pair of routing protocols.
– Editing a routing policy requires the use of one of three available editors.
– Value sets are objects that are used to modularize routing policies. Various
types of sets exist for different types of parameters and attributes.
Summary (Cont.)
– AS path set can contain one or more regular expressions which describe a set
of AS paths.
– You can use community sets to group multiple BGP communities.
– You can use a prefix set to match routes based on prefix-list-like criteria.
– You can use the show rpl command to display a policy configuration, including
all the dependencies.
– Policies can be combined with the show bgp command to display only those
BGP entries that are permitted by the policy.
– When you translate route maps to routing policies it is important to understand
the relationship between multiple conditions in a single route map statement.
Objectives

BGP Route Selection

96
Objectives
– Describe the use of BGP weights to influence the BGP route selection
process
– Describe how to configure per-neighbor weights
– Describe how to change BGP weights using RPLs or Route Maps
– Describe the order of operation in setting BGP weights
– Describe how the BGP local preference attribute influences BGP route
selection
– Describe how to change the local preference
– Describe how to monitor the local preference values
– Describe the function of AS path prepending and how you can use it to
facilitate proper return path selection
– Describe design considerations for implementing AS path prepending
– Describe how to configure AS path prepending
Objectives (Cont.)
– Describe how to monitor AS path prepending
– Describe how AS path prepending can impact AS path filtering
– Describe how MED can be used to facilitate proper return path selection
– Describe how to change the MED
– Describe how to monitor MED values
– Describe how BGP communities facilitate proper return path selection
– Describe how to configure BGP Communities
– Describe BGP named community lists
– Describe the use of sequenced entries in extended community lists
– Describe how to set attributes based on community values
– Describe how to monitor BGP community values
– Show examples of using BG communities
Influencing BGP Route Selection
Outbound Traffic
–BGP routing policy can be specified by using:
• Weight: provides local routing policy (within a router)
• Local preference: provides AS-wide routing policy

–BGP weights are specified per neighbor.

• Default weight
• AS path-based weight
• Complex criteria with RPLs or route maps
Configuring Per-Neighbor Weights
• All routes from the BGP neighbor get the specified weight.
• BGP routes with a higher weight are preferred.
router bgp SP1-AS
neighbor SP3-AS
Routes received from a primary BGP address-family ipv4 unicast
neighbor should be preferred over routes weight 150
received from a backup BGP neighbor. neighbor SP4-AS
address-family ipv4 unicast
weight 100
router bgp Customer-AS
neighbor Primary-SP weight 150
neighbor Backup-SP weight 100
SP1 SP3
Customer

SP2
SP4
Changing Weights with RPLs or Route Maps
– Weights can be set with RPLs (Cisco IOS XR) or route maps
(Cisco IOS/IOS XE) in complex scenarios.
– Routes can be matched on any combination of prefix lists, AS
path filters, or other BGP attributes.
route-policy from_SP3 route-policy from_SP4
set weight 150 set weight 100 router bgp SP1-AS
end-policy end-policy neighbor SP3-AS
address-family ipv4 unicast
route-map from_SP1 route-map from_SP2 route-policy from_SP3 in
set weight 150 set weight 100 neighbor SP4-AS
address-family ipv4 unicast
route-policy from_SP4 in
router bgp Customer-AS
neighbor Primary-SP route-map from_SP1 in
neighbor Backup-SP route-map from_SP2 in SP1 SP3

Customer

SP2 SP4
BGP Weight Attachment Points
BGP Local Preference
– You can use local preference to ensure AS-wide route selection
policy.
– Any BGP router can set local preference when it is processing
incoming route updates, doing redistribution, or sending
outgoing route updates.
– Local preference is used to select routes with equal weight.
– Local preference is stripped in outgoing EBGP updates, except
in EBGP updates with confederation peers.
BGP Local Preference (Cont.)
–Local preference is the second highest attribute in the BGP
route selection sequence.
–Remember the BGP route selection rules:
• Highest weight preferred (local to router)
• Highest local preference preferred (global within AS)
• Other BGP route selection rules

–Weights configured on a router override local preference

settings.
–To ensure consistent AS-wide route selection:
• Do not change local preference within the AS.
• Do not use BGP weights.
Changing Local Preference
• A default local preference value is applied to all routes
that do not have local preference set (EBGP routes).
• The default value of local preference is 100, allowing
you to specify more desirable or less desirable routers.
Changes the default LP
router bgp SP1-AS
Changes per neighbor LP bgp default local-preference 150

route-policy from_SP3 router bgp SP1-AS

set local-preference 150 neighbor SP3-AS
end-policy address-family ipv4 unicast
route-policy from_SP3 in
router bgp Customer-AS
bgp default local-preference 150
SP1 SP3

Customer

SP4
SP2
Monitoring Local Preference
RP/0/RSP0/CPU0:PE1#show bgp
< text omitted > Nondefault LP is
Origin codes: i - IGP, e - EGP, ? - incomplete displayed.
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.1/32 0.0.0.0 0 32768 i LP from the IBGP
*> 10.1.10.1/32 192.168.101.11 0 0 64501 i
peer is displayed.
*>i10.2.1.1/32 10.2.1.1 0 100 0 i
*>i10.2.10.1/32 10.2.1.1 0 100 0 64502 i
< text omitted >

RP/0/RSP0/CPU0:PE1#show bgp 10.1.10.1/32

< text omitted >
Paths: (1 available, best #1) LP is always
Advertised to peers (in unique update groups):
displayed.
10.0.1.1
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
10.0.1.1
64501
192.168.101.11 from 192.168.101.11 (10.1.10.1)
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 9

Customer SP1
Return Path Selection in a Multihomed AS
– Requirement: The return traffic to the customer must
arrive over the highest-speed access link.
– Result: The return traffic flows over the path with the
shortest AS path length.
Proper Return Path Selection
• Q: How do you select the proper return path from AS 387?
• A: Use local preference in AS 387.
• Q: Will the administrator of AS 387 configure it?
• A: Unlikely.
AS Path Prepending
–BGP route selection uses these criteria:
• Prefer largest weight.
• Prefer largest local preference.
• Prefer routes that the router originated.
• Prefer shorter AS paths.
• Use other route selection rules.
–Manipulating the outgoing AS path length (called AS path
prepending) could result in proper return path selection.
–The AS path should be extended with multiple copies of the
AS number of the sender.
–AS path prepending is used to achieve these goals:
• Ensure proper return path selection.
• Distribute the return traffic load for multihomed customers.
AS Path Prepending (Cont.)
–Result: The return traffic flows over the desired return path.
AS Path Prepending
Design Considerations
– There is no exact mechanism to calculate the required prepended
AS path length.
– If a primary and backup scenario is desired, consider this strategy:
• Use a long prepended AS path over the backup link to ensure that the primary AS path
will always be shorter.
• A long backup AS path consumes memory on every Internet router.
• Experiment with various AS path lengths until the backup link
is idle.
• Add a few more AS numbers for additional security (unexpected changes in the
Internet).
– If traffic load distribution is desired, consider this strategy:
• Start with a short prepended AS path, monitor the link use, and extend the prepended
path length as needed.
• Continuously monitor the link use and change the prepended
AS path length if required.
Configuring AS Path Prepending
Prepends the specified AS
number sequence to the routes route-policy to_SP4
prepend as-path 10 2
matched by the RPL entry
router bgp 10
route-map to_SP2 permit neighbor SP4
set as-path prepend 99 99 address-family ipv4 unicast
route-policy to_SP4 out
router bgp Customer-AS
neighbor SP2 route-map to_SP2 out
SP1 (AS 10) SP3 (AS 30)
Customer (AS 99)

AS numbers prepended to the

AS path from the BGP table

SP4 (AS 40)

SP2 (AS 20)
Monitoring AS Path Prepending
–AS path prepending cannot be monitored or debugged on the
sending router.
• debug bgp (debug ip bgp) updates displays the BGP entry prior to RPL or route map processing.
• show policy-map (show route-map) does not display how many routes have matched a RPL or route
map entry.

–The results of AS path prepending can be observed on the

receiving router.
AS Path Filtering Concerns: AS Path Prepending
Service providers usually use AS
path filters to control incoming BGP
updates from their customers.
To support AS path
prepending, service providers
should implement regular
expression variables to
create a uniform AS path filter
for all customers.

^([0-9]+)(_\1)*$

The incoming AS path filters

of the service provider need
to be modified to support AS
path prepending.
Selecting the Proper Return Path
– You can use the MED to influence path selection in a neighbor
AS.
– An AS can specify its preferred entry point by using the MED in
outgoing EBGP updates.
How can you make sure that the
return traffic takes the right path?
MED Propagation in a BGP Network
Changing the MED
• The MED is copied from the IGP cost in the router that sources the route (via the network
command or through route redistribution).
• You can change the MED value for redistributed routes with the default-metric command.

router bgp SP1-AS

Changes the default MED default-metric value

router bgp SP1-AS

Changes per neighbor MED neighbor SP3-AS
address-family ipv4 unicast
route-policy from_SP3 out
router bgp Customer-AS
default-metric value
SP1 SP3
Customer
Advanced MED Configuration
Cisco IOS/IOS XE Cisco IOS XR
By default, the MED is considered only during the
selection of routes from the same AS. bgp always-compare- bgp bestpath
The MED is also considered for routes coming med med always
from a different AS.
If the MED is not attached to a BGP route, it is
bgp bestpath
interpreted as value 0, and thus as the best bgp bestpath med
med missing-as-
metric. A missing MED is interpreted as infinity missing-med-worst
worst
(worst).
By default, the MED is considered only during the
selection of routes from the same AS, which does
not include intraconfederation autonomous bgp bestpath med bgp bestpath
systems. confed med confed
Allow routers to compare paths learned from
confederation peers.

bgp deterministic-
Changes the BGP route selection procedure to a
med default
deterministic but slower one.
Monitoring the MED
RP/0/RSP0/CPU0:PE1#show bgp
< text omitted > MED is displayed as metric.
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.1/32 0.0.0.0 0 32768 i
*> 10.1.10.1/32 192.168.101.11 0 0 64501 i
*>i10.2.1.1/32 10.2.1.1 0 100 0 i
*>i10.2.10.1/32 10.2.1.1 0 100 0 64502 i
< text omitted >
RP/0/RSP0/CPU0:PE1#show bgp 10.1.10.1/32
< text omitted > MED is displayed only for those
Paths: (1 available, best #1) routes that contain a MED
Advertised to peers (in unique update groups): attribute.
10.0.1.1
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
10.0.1.1
64501
192.168.101.11 from 192.168.101.11 (10.1.10.1)
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 9

Customer SP1
Both the original and the
modified routes are
displayed when inbound
soft reconfiguration is
configured.
BGP Communities Overview
–BGP communities are a means of tagging routes to ensure a
consistent filtering or route selection policy.
–The community attribute is a transitive optional attribute. Its
value is a 32-bit number (range 0 to 4,294,967,200).
–The standards define several filtering-oriented communities:
• no-advertise: Do not advertise routes to any peer.
• no-export: Do not advertise routes to real EBGP peers.
• local-as: Do not advertise routes to any EBGP peers.
• internet: Advertise this route to the Internet community.

–A 32-bit community value is split into two parts:

• High-order 16 bits contain the AS number of the AS that defines the community meaning.
• Low-order 16 bits have local significance.
Using Communities
–Define administrative policy goals:
• Solve asymmetrical customer routing problems.

–Design filters and route selection policy to achieve

administrative goals:
• Set local preference of customer routes to 50 for customers using the backup service provider.

–Define communities that signal individual goals:

• Community 387:17 is used to indicate that the local preference of the route should be lowered to 50.

–Configure route tagging on entry points, or let BGP neighbors

tag the routes.
–Configure community distribution.
–Configure route filters and route selection parameters, based
on communities.
Configuring BGP Communities
• Use these procedures to configure BGP communities:
–Configure route tagging with BGP communities.
–Configure BGP community propagation.
–Define BGP community access lists (community lists) to
match BGP communities.
–Configure RPLs or route maps that match on community lists
and filter routes, or set other BGP attributes.
–Apply RPLs or route maps to incoming or outgoing updates.
Configuring Route Tagging with
BGP Communities
Configuring Community Propagation:
Cisco IOS/IOS XE

By default, communities are

stripped in outgoing BGP
updates. Manually configure
community propagation.
Defining BGP Community Lists: Cisco IOS/IOS XE
BGP Named Community Lists
–Naming allows the network operator to assign meaningful
names to community lists, and increases the number of
community lists that can be configured.
–Named community lists can be configured with regular
expressions and with numbered community lists.
–There is no limitation on the number of community attributes
that can be configured for a named community list.
–The number of community lists that can be configured by a
network operator increases, because there is no limitation on
the number of named community lists that can be configured.
BGP Support for Sequenced Entries in Extended
Community Lists
–Allows automatic sequencing of individual entries in BGP
extended community lists
–Provides the ability to remove or resequence extended
community list entries without deleting the entire existing
extended community list
–Configures sequence numbers for extended community list
entries
–Resequences the existing sequence numbers for extended
community list entries
–Configures an extended community list to use default values
Matching BGP Communities
Monitoring Communities
– Communities are displayed in a show bgp prefix printout.
– Communities are not displayed in debugging outputs.
– Routes in the BGP table that are tagged with a set of communities, or
routes matching a community list, can be displayed.
RP/0/RSP0/CPU0:PE5#show bgp 10.5.10.1/32
< text omitted >
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.1
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.1
64505
192.168.105.51 from 192.168.105.51 (10.5.100.1)
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 66
Community: 1:100

RP/0/RSP0/CPU0:PE5# show bgp route-policy com1

< text omitted >
Network Next Hop Metric LocPrf Weight Path
*> 10.5.10.1/32 192.168.105.51 0 0 64505 i
* 10.5.100.1/32 192.168.105.51 0 0 64505 i
Example 1: Standard Community Set
! route-policy Comm2ActionIn router bgp 23456
community-set Primary if community matches-any Primary then neighbor 200.1.1.1
23456:200 set local-preference 200 remote-as 64511 1
end-set endif address-family ipv4 unicast
! ! route-policy Comm2ActionIn in
community-set Backup if community matches-any Backup then
23456:50 set local-preference 50
end-set endif router bgp 23456
! ! neighbor 200.2.2.2
community-set 1Prep end-policy remote-as 64123 2
23456:1 ! address-family ipv4 unicast
end-set route-policy Comm2ActionOut route-policy Comm2ActionOut out
! if community matches-any 1Prep then
community-set 2Preps prepend as-path 23456 1
23456:2 endif Customer can signal ISP using
end-set ! communities:
! if community matches-any 2Preps then
community-set 3Preps prepend as-path 23456 2 23456:200  LP 200
23456:3 endif 23456:50  LP 50
end-set !
! if community matches-any 3Preps then
23456:1  AS prepended once
prepend as-path 23456 3 23456:2  AS prepended twice
endif 23456:3  AS prepended three times
end-policy

AS 23456 Prepend
AS 64511 Communities Communities AS 64123
(Customer) Local Preference (Peering
1 2
Service
(Service Provider)
Provider)
Example 2: Standard Community Set
Filter routes are based
on standard community
attributes, using simple
numbered matching.

community-set ImpComms
BGP Update 23456:10
NLRI: 10.1.1.0/24 end-set
!
Next-hop: 192.168.1.1
route-policy RP1 
Origin: igp if community matches-any ImpComms then
AS Path: 10 20 30 pass
Community: endif
23456:10 end-policy
!
23456:20
23456:30
route-policy RP2 
if community matches-every ImpComms then
pass
endif
end-policy
!
Example 3: Standard Community Set
Filter routes are based
on standard
community attributes,
using range matching.

community-set ImpComms
BGP Update 23456:999,
NLRI: 10.1.1.0/24 23456:[10..30]
end-set
Next-hop: 192.168.1.1
!
Origin: igp route-policy RP1 
AS Path: 10 20 30 if community matches-any ImpComms then
Community: pass
23456:10 endif
end-policy
23456:20
!
23456:30 route-policy RP2 
if community matches-every ImpComms then
pass
endif
end-policy
!
Example 4: Standard Community Set
Filter routes, based on
standard community
attributes, using
regular expressions.

community-set ImpComms
BGP Update ios-regex ‘23456:999',
NLRI: 10.1.1.0/24 ios-regex '23456:[1-3]0'
end-set
Next-hop: 192.168.1.1
!
Origin: igp route-policy RP1 
AS Path: 10 20 30 if community matches-any ImpComms then
Community: pass
23456:10 endif
end-policy
23456:20
!
23456:30 route-policy RP2 
if community matches-every ImpComms then
pass
endif
end-policy
!
Example 5: Standard Community Set
–On incoming updates, delete all communities that have no
meaning in your AS 23456.
Original BGP Update
NLRI: 10.1.1.0/24
Next-hop: 192.168.1.1 New BGP Update
Delete unused
Origin: igp extended community NLRI: 10.1.1.0/24
AS Path: 10 20 30 attributes. Next-hop: 192.168.1.1
Community: Origin: igp
23456:10 community-set AllMyCommunities
AS Path: 10 20 30
23456:20 23456:*
end-set Community:
23456:30 23456:10
!
64111:12 route-policy RP1 23456:20
64222:33 delete community not in 23456:30
AllMyCommunities
end-policy
!
Example 6: Standard Community Set
–On outgoing updates, delete all communities that have no
meaning in peering AS 64111.
Original BGP Update
NLRI: 10.1.1.0/24
Next-hop: 192.168.1.1 New BGP Update
Delete extended
Origin: igp community attributes NLRI: 10.1.1.0/24
AS Path: 10 20 30 not used in peering AS. Next-hop: 192.168.1.1
Community: Origin: igp
23456:10 route-policy RP
AS Path: 10 20 30
23456:20 delete community not in
(peeras:*) Community:
23456:30 64111:12
end-policy
64111:12 !
64222:33
Example 7: Standard Community Set
–Delete all communities except well-known communities (e.g.
no-export, no-advertise, local-as)
Original BGP Update
NLRI: 10.1.1.0/24
Next-hop: 192.168.1.1 New BGP Update
Delete all communities
Origin: igp except well-known NLRI: 10.1.1.0/24
AS Path: 10 20 30 communities. Next-hop: 192.168.1.1
Community: Origin: igp
no-export route-policy RP
AS Path: 10 20 30
23456:20 delete community all
end-policy Community:
23456:30 no-export
!
64111:12
64222:33
Summary
– BGP weights can be used to influence the BGP route selection process.
– Weight can be configured on a BGP session and is applied to incoming
BGP updates.
– Weight can be changed using route maps or RPL.
– Weight setting is applicable only on incoming routes because a router
never propagates the weight attribute to its neighbors.
– Local preference is similar to the weight attribute in that you can use
both to influence BGP path selection, but it differs from the BGP weight
attribute in that weight is local to the specific router on which it is
configured.
– Local preference is set to 100 by default and can be changed using
route maps and RPL.
– You can determine local preference of a route by examining the BGP
table.
Summary (Cont.)
– You can use AS path prepending to influence incoming path selection.
– AS path prepending is performed on outgoing EBGP updates over the
nondesired return path, or the path where the traffic load should be reduced.
– You can configure AS path prepending using route maps or RPL.
– When you are monitoring AS path prepending, the router doing the prepending
is not the proper point to observe the results of the AS path prepend operation.
– Service providers should take into account possible AS path prepending done
by customers when designing AS path filters.
– The MED is a “weak” parameter in the route selection process; it is used only if
weight, local preference, AS path, and origin code are equal. By default, the
MED is compared only for paths that were received from the same AS.
– You can use the RPL or a route map to set the MED on incoming or outgoing
updates.
Summary (Cont.)
– You can determine MED of a route by examining the BGP table.
– BGP communities are a means of tagging routes to ensure consistent filtering
or routing policy.
– You can use the BGP community attribute to create an AS-wide routing policy
or to provide services to neighboring autonomous systems.
– The BGP named community lists feature allows the network operator to assign
meaningful names to community lists.
– BGP support for sequenced entries allows automatic sequencing of individual
entries in BGP extended community lists.
– You can use the RPL or route maps to match routes that carry specific BGP
communities.
– You can use the show bgp prefix command to examine BGP communities
that the route is tagged with.
– You can use BGP communities to allow customers to signal preference of a
specific path to the SP. SP than performs route manipulation based on
received communities.
Objectives

BGP Route Reflector & Confederation

140
Objectives
–Explain the need for BGP route reflectors in BGP transit core
networks and how route reflectors modify traditional IBGP
split-horizon rules
–List the network design rules for implementing BGP route
reflectors
–Describe configuration of route reflectors in the service
provider network
–Describe the need for BGP confederations in BGP transit
backbones and basic design rules that network designers
should follow when planning a transit AS for BGP
confederations
IBGP Scalability Issues

SP

IBGP
IBGP

• IBGP requires a full mesh between all BGP-speaking routers:

– Large number of TCP sessions
– Unnecessary duplicate routing traffic
– Configuration overhead
• Solutions:
– Route reflectors modify IBGP split-horizon rules
– BGP confederations modify IBGP AS path processing
BGP Split-Horizon Rule
Route
Reflector
IBGP

IBGP
Client

IBGP

IBGP
Client

IBGP
Client

–Classic IBGP: • Route reflector can propagate

IBGP routes to other IBGP peers.
• IBGP routes are not propagated to
other IBGP peers. • Full mesh of IBGP peers is not
–Full mesh of IBGP required.
peers is therefore • Route reflector-based network
includes route reflectors and
required. clients.
Route Reflector Split-Horizon Rule
3. Routes received from
nonclients are sent to EBGP
Route peers and clients only
Reflector

IBGP IBGP

Client
EBGP Peer

IBGP
2. Routes received from a client
are propagated to all other peers

Route
EBGP Route Reflector

Client
EBGP Peer Client
1. Routes received from
EBGP peers are propagated
to all internal peers

Regular IBGP
RR-Client IBGP
Route Reflector Split-Horizon Rule
(Cont.)
1. Routes received from
EBGP peers are propagated
Route to all internal peers
Reflector

IBGP IBGP EBGP Route

Client
EBGP Peer

IBGP
2. Routes received from
nonclients are sent to EBGP
peers and clients only

Route
EBGP Route Reflector

Client
EBGP Peer Client
3. Routes received from
IBGP peer are sent to EBGP
peers

Regular IBGP
RR-Client IBGP
Route Reflector Split-Horizon Rule (Cont.)
Type of Receiving Router Incoming Update From Is Forwarded To
Classic (nonclient) EBGP peer All peers (IBGP and EBGP)
IBGP peer EBGP peers
Route reflector EBGP peer All peers (IBGP and EBGP)
Nonclient IBGP peer EBGP peers and clients
Client IBGP peer All peers but the sender
Client EBGP peer All peers (IBGP and EBGP)
IBGP peer EBGP peers
Redundant Route Reflectors
Route
Reflector

Client
EBGP Peer

Single Point of Failure

Route
Reflector

EBGP Peer Client Client

Regular IBGP
RR-Client IBGP

– Clients that have an IBGP session with only one route

reflector will not be able to send any BGP updates if the
route reflector fails.
– Clients should establish an IBGP session with at least two
route reflectors using different physical connections.
Redundant Route Reflectors (Cont.)
Route
Reflector

Client

IBGP
EBGP Peer
The redundant route reflector
might introduce a loop.

Route
EBGP Route Reflector

EBGP Peer Client Client

Regular IBGP
RR-Client IBGP

– Redundant reflectors solve the high-availability

requirement.
– The concept of clusters is introduced to prevent IBGP
routing loops between route reflectors.
Route Reflector Clusters
Route Route is not reflected because the
Reflector cluster ID is already in the cluster list.

IBGP

Client

IBGP
EBGP Peer

Route
EBGP Route Reflector

EBGP Peer Client Client

Regular IBGP
RR-Client IBGP

– A group of redundant route reflectors and their clients form a cluster.

– Each cluster must have a unique cluster ID.
– Each time a route is reflected, the cluster ID is added to the cluster-list
BGP attribute.
– The route that already contains the local cluster ID in the cluster list is
not reflected.
Additional Loop-Prevention Mechanism
–Every time a route is reflected, the router ID of the originating
IBGP router is stored in the originator-ID BGP attribute.
–A router receiving an IBGP route with the originator ID set to
its own
router ID ignores that route.
–The BGP path selection procedure is modified to take into
account both the cluster list and the originator ID.
Network Design with Route Reflectors

Client Reflector EBGP Peer

Classic BGP Router

Nonredundant Cluster
Redundant Cluster
Reflector Reflector
Regular IBGP
RR-Client IBGP

EBGP Peer Client Client Client EBGP Peer

– Route reflector rules divide a transit AS into smaller areas

(called clusters).
– Each cluster contains route reflectors and route reflector clients.
– Routers that do not support route reflector functionality act as a
one-router cluster or as a route reflector client. These routers
have to be fully meshed with route reflectors from all clusters.
Potential Network Issues
Potential problems that can occur when you deviate from
the route reflector network design rules.
• Issue: • Result:
– Clients do not have sessions with – Clients will not receive all IBGP
all reflectors in a cluster. routes.
– Clients have sessions with – Clients will receive duplicate
reflectors in several clusters. copies of the same route.
– Clients have IBGP sessions with – Clients will receive duplicate
other clients. copies of the same route.
Hierarchical Route Reflectors
–In very large networks, a single layer of route reflectors might
not be enough.
–A hierarchy of route reflectors can be established.
• A route reflector can be a client of another route reflector.
• The hierarchy can be as deep as needed.
Hierarchical Route Reflectors (Cont.)
Client Client
Cluster 27 EBGP Peer

Reflector Reflector
Router is a
reflector in cluster
22 and client is in Cluster 10
cluster 27

Reflector/ Reflector/ Reflector/

Cluster 12 Client Client Client

EBGP Peer Client Client Client Client Client EBGP Peer

Regular IBGP
RR-Client IBGP
Route Reflector Backbone Migration
–Divide the AS into areas (clusters).
• Assign a cluster ID to each area.

–On route reflectors, retain only IBGP sessions with clients in

their cluster and with other route reflectors.
• Configure the cluster ID on every route reflector.
• Configure clients on every route reflector.

– On route reflector clients, retain only IBGP sessions with

route reflectors in their cluster.
Configuration
Reflector Reflector

10.0.0.1 10.0.0.2
SP
AS 123
209.165.201.128/28

Customer Client Client Client

AS 234
10.0.0.3 10.0.0.4 10.0.0.5
Configure a Configure a
router bgp 123 router bgp 123 cluster ID
bgp cluster-id 17 cluster ID bgp cluster-id 17
neighbor 10.0.0.3 remote-as 123 neighbor 10.0.0.3
neighbor 10.0.0.3 route-reflector-client remote-as 123
neighbor 10.0.0.2 remote-as 123 address-family ipv4 unicast Specify the
route-reflector-client neighbor as
Specify the neighbor 10.0.0.1 a client
neighbor as remote-as 123
address-family ipv4 unicast
a client
Verification
RP/0/RSP0/CPU0:P# show bgp neighbors 10.0.0.3

BGP neighbor is 10.0.0.3

Remote AS 64500, local AS 64500, internal link
Remote router ID 10.0.0.3
Cluster ID 17
BGP state = Established, up for 00:00:07
<…output omitted…>
For Address Family: IPv4 Unicast
BGP neighbor version 17
Update group: 0.1 Filter-group: 0.1 No Refresh request being processed
Route-Reflector Client
NEXT_HOP is always this router
<…output omitted…>

• Displays information about the BGP session with the neighbor

Verification (Cont.)

RP/0/RSP0/CPU0:P# show bgp 209.165.201.128

BGP routing table entry for 209.165.201.128/28
<…output omitted…>
234, (Received from a RR-client)
10.0.0.3 (metric 2) from 10.0.0.3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 3

• Displays routes received from the client as seen on the reflector

RP/0/RSP0/CPU0:PE# show bgp 209.165.201.128
BGP routing table entry for 209.165.201.128/28
<…output omitted…>
234
10.0.0.1 (metric 2) from 10.0.0.1(10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, internal
Received Path ID 0, Local Path ID 0, version 0
Originator: 10.0.0.1, Cluster list: 0.0.0.17

• Displays reflected routes as seen on the client

BGP Confederations
Real EBGP
Session

EBGP Peer

65001
SP 65002 Intraconfederation
AS 123 EBGP Session

IBGP Session

65003 65004
EBGP Peer

– Splitting the AS into smaller autonomous systems would reduce

the number of BGP sessions, but extra AS numbers are not
available.
– Confederations enable internal AS numbers to be hidden and
announce only one (external) AS number to EBGP neighbors.
– Inside a confederation, full-mesh IBGP is required.
AS Path Propagation Within BGP Confederation
–IBGP session:
• The AS path is not changed.

–Intraconfederation EBGP session:

• The intraconfederation AS number is prepended to the AS path.
• The intraconfederation AS path is encoded as a separate segment of the AS path.
• The intraconfederation AS path is displayed in parentheses when you are using show commands.
• A router that does not support BGP confederations will reject an AS path with unknown segment type.

–EBGP session with external peer:

• Intraconfederation AS numbers are removed from the AS path.
• The external AS number is prepended to the AS path.
AS Path Propagation Example

Network X

X 234 X (65001) 234

Customer
AS 234

65001
SP 65002
AS 123

Customer 1
65003 65004 AS 345
X 123 234
Intraconfederation EBGP Session Properties
–Behaves like EBGP session during session establishment:
• The EBGP neighbor has to be directly connected, or you have to configure EBGP multihop on the
neighbor.

–Behaves like IBGP session when propagating routing

updates:
• The local preference, MED, and next-hop attributes are retained.
• The whole confederation can run one IGP, providing optimal routing based on the next-hop attribute in
the BGP routing table.
Summary
–IBGP requires full mesh because of the split-horizon rule.
–Route reflectors modify IBGP split-horizon rules and do not
require full-mesh IBGP. Route reflectors should be always
designed redundantly.
–To implement route reflectors, on route reflectors, retain only
IBGP sessions with other route reflectors and clients in their
cluster. On clients, retain only IBGP sessions with route
reflectors in their cluster.
–BGP confederations divide the AS into several smaller
autonomous systems and change AS path processing.
Further Reading
• BGP Peer Group
• Limit BGP Prefixes
• BGP Dampening
• BFD for BGP
• BGP PIC
• Fine Tuning BGP Timers and Intervals
• Distributed BGP
• PMTU Discovery for BGP
• BGP Next-hop Trigger Delay …

164
Objectives

Improving BGP Convergence

165
Objectives
–Describe the purpose and operation of BGP route dampening
–Describe features that are used to improve convergence in
BGP networks
–Describe BGP timers and intervals
BGP Route Dampening
–Designed to reduce router processing load caused by
unstable routes
–Minimizes the amount of BGP update processing in the
Internet by suppressing unstable (flapping) routes
–Does not suppress routes that occasionally flap
–Suppresses routes that are likely to flap in the future, based
on the history of their behavior
Route-Dampening Operation

– Each time an EBGP route flaps, it gets 1000 penalty points.

– The penalty placed on a route decays according to the exponential
decay algorithm.
– When the penalty exceeds the suppress limit, the route is dampened
(no longer used or propagated to other neighbors).
– A penalty is applied to the individual path in the BGP table, not to the
IP prefix.
Route-Dampening Operation (Cont.)

– A route is never dampened for longer than the maximum suppression

time limit.
– An unreachable route with a flap history is put in the history state—it
stays in the BGP table, but only to maintain the flap history.
– A dampened route is propagated when the penalty drops below the
reuse limit.
– The flap history is forgotten when the penalty drops below half of the
reuse limit.
Configuring BGP Route Dampening
–Configured globally.
–BGP dampening parameters:
• half-life: Decay time in which the penalty is halved
• suppress: Value when the route starts dampening
• reuse: Value when the dampened route is reused
• max-suppress-time: Maximum time to suppress the route

–Default values that are used by most SPs:

• half-life: 15 minutes
• suppress: 2000
• reuse: 750
• max-suppress-time: 60 minutes (4x half-life)

–Can also be enabled selectively using route policy or route

map.
Configuration

SP
Customer 1 Customer 2
AS 123
209.165.201.144/28

router bgp 123 route-policy BGP_DAMP

bgp dampening 10 1000 3000 40 if destination in (209.165.201.144/28) then
set dampening halflife 10 suppress 3000
reuse 1000 max-suppress 40
Enable BGP dampening endif
for all IPv4 routes end-policy
Create a route policy to match
! only specific routes and set
router bgp 123 dampening parameters
address-family ipv4 unicast
bgp dampening route-policy BGP_DAMP

Enable selective BGP

dampening
Verification
RP/0/RSP0/CPU0:PE1# show bgp 209.165.201.144/28
<…output omitted…>
234, (suppressed due to dampening)
209.165.201.144 from 192.168.105.51 (10.5.100.1)
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Dampinfo: penalty 3620, flapped 4 times in 00:04:14, reuse in 00:27:00
half life 00:10:00, suppress value 3000, reuse value 1000
Maximum suppress time 00:40:00

• Displays a BGP route

RP/0/RSP0/CPU0:PE1# show bgp dampened-paths
<…output omitted…>
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network From Reuse Path
*d 209.165.201.144/28 192.168.105.51 00:28:10 64505 i

• Displays dampened BGP routes

Verification (Cont.)
RP/0/RSP0/CPU0:PE1#
debug bgp [address-family] dampening
• Displays the BGP dampening events
RP/0/RSP0/CPU0:PE1#
show [address-family] bgp flap-statistics
• Displays flap statistics for all routes with dampening history
RP/0/RSP0/CPU0:PE1#
clear bgp [address-family] dampening [ip-address/prefix]
• Releases all the dampened routes or just the specified network
RP/0/RSP0/CPU0:PE1#
clear bgp [address-family] flap-statistics [ip-
address/prefix]
• Clears BGP flap statistics for all routes or just the specified network
BGP Convergence
–As the number of routes in the Internet routing
table grows, the time it takes for BGP to converge
increases.
–The Internet currently contains more than
300,000 prefixes.
–Network convergence times can range from 10
minutes to more than one hour.
–BGP is considered converged when:
• All routes have been accepted.
• All routes have been installed in the routing table.
• The input queue and output queue for all peers is 0.
BGP Processes
• BGP consists of several processes:
Process Description Interval

BGP open Performs BGP peer establishment. At initialization, when

establishing a TCP
connection with a BGP
peer.
BGP I/O Handles queuing and processing of BGP packets As BGP control packets
(updates and keepalives). are received.
BGP scanner Walks the BGP table and confirms reachability of Every 60 seconds.
the next hops. BGP scanner also checks
conditional advertisement to determine whether or
not BGP should advertise condition prefixes.
Performs route dampening.
BGP router Calculates the best BGP path and processes any Once per second and
route changes. It also sends and receives routes, when adding, removing,
establishes peers, and interacts with the routing or soft-reconfiguring a
information base. BGP peer.
CPU Effects of BGP Processes
–BGP scanner process:
• High CPU utilization stemming from the BGP scanner process can be expected for short durations on a
router carrying a large Internet routing table.
• While the BGP scanner runs, low-priority processes need to wait a longer time to access the CPU.

–BGP router process:

• The BGP router process runs about once per second to check for work.
• The BGP router consumes all free CPU cycles.
Improving BGP Convergence
• You can reduce BGP convergence time and high CPU
utilization caused by BGP processes in the following ways:
–Implement distributed BGP:
• Reduces CPU utilization and increases stability.

–Implement BFD:
• Reduces BGP convergence by fast detection of neighbor failure.

–Implement BGP PIC:

• Reduces convergence by storing BGP backup/alternate path in RIB and FIB.

–Enable the path MTU feature:

• Improves efficiency by dynamically determining the largest MTU that you can use without creating
packets that need to be fragmented.

–Increase interface input queues:

• Improves convergence by reducing dropped TCP ACKs.
Distributed BGP
• Supported on Cisco IOS XR Software only
• Distributed BGP splits BGP functionality into three process types with several
instances:
• BGP process manager (one instance)
• brIB process (one instance per address family)
• BGP speaker process (up to 15 instances)

• Used to reduce the impact that a fault in one address family has on another
address family
• Has to be enabled
PMTU Discovery
• Used to automatically determine TCP MSS used for TCP connections from
a router
• Default TCP MSS value for BGP is 536 bytes
• Small TCP MSS affects BGP convergence:
• Higher TCP MSS can improve BGP convergence
Increasing Input Queue Depth
–Available on Cisco IOS and IOS XE Software only.
–Input queue on an interface specifies how many packets can
be queued before dropping the packets.
–BGP routers with several peers might experience packet
drops on an interface due to a large number of TCP ACK
segments.
–The default input hold queue is platform-dependent.
–A length of 1000 will normally resolve problems caused by
input queue drops of TCP ACKs.
Configuration

Enables PMTU
SP
discovery AS 123 Enables PMTU
discovery
ip tcp path-mtu-discovery
! tcp path-mtu-discovery
interface GigabitEthernet0/0/0
hold-queue 1000 in

router bgp 123

Increases input distributed speaker 1 Enables a distributed
hold queue distributed speaker 2 speaker process
neighbor 10.0.101.1
speaker-id 1
neighbor 10.0.102.1
speaker-id 2 Allocates a speaker
process to a neighbor
Verification
RP/0/RSP0/CPU0:P# show bgp process
BGP Process Information:
BGP is operating in DISTRIBUTED mode
Autonomous System number format: ASPLAIN
Autonomous System: 64500
Router ID: 10.5.1.1
Default Cluster ID: 10.5.1.1
Fast external fallover enabled
Neighbor logging is enabled
Enforce first AS enabled
Default local preference: 100
Default keepalive: 60
Update delay: 120
Generic scan interval: 60
<…output omitted…>

• Displays BGP process information

Verification
PE1#show ip bgp neighbors | include Datagrams
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):

• Displays BGP neighbor information, including TCP MSS

PE1#show interface GigabitEthernet0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
Hardware is ASR1001, address is e8b7.48fb.7100 (bia e8b7.48fb.7100)
Internet address is 192.168.106.60/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not supported
Full Duplex, 100Mbps, link type is auto, media type is T
output flow-control is on, input flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:13, output hang never
Last clearing of "show interface" counters never
Input queue: 0/1000/0/0 (size/max/drops/flushes); Total output drops: 0
<…output omitted…>

• Displays interface information, including input queue depth

BGP Prefix Independent Convergence

SP
Customer CE1 PE1 Internet
AS 123

CE2
PE2

–PIC enhances BGP convergence, regardless of

number of BGP prefixes.
–PIC stores BGP backup/alternate path for each
prefix in BGP, RIB, and FIB tables.
–When the primary goes down, CEF quickly
selects different egress port for affected
destination.
BGP PIC Configuration

SP
Customer CE1 PE1 AS 123

CE2
PE2
router bgp 234 route-policy ALL
address-family ipv4 unicast pass
bgp additional-paths install end-policy
address-family ipv6 unicast !
bgp additional-paths install router bgp 234
address-family ipv4 unicast
additional-paths selection route-policy ALL
Enable BGP PIC address-family ipv6 unicast
additional-paths selection route-policy ALL

Enable BGP PIC

Bidirectional Forwarding Detection for
BGP
– Extremely lightweight hello protocol that uses UDP
to test bidirectional communication
– Used to detect failures in the forwarding path
between two adjacent routers
– Millisecond resolution of forwarding plane failure
– Relies on routing protocols to detect neighbors

BFD Control Packets

Echo Packets
R1 R2
BFD Operation
–Routing protocol (BFD client) bootstraps BFD to create BFD
session to a neighbor:
• BFD client receives link status change notification.
• Receive and transmit intervals are negotiated and configurable.

–Two systems agree on a method to detect failure.

–In case of failure, BFD notifies BFD client:
• BFD
R1client independently decides on action. R2
BGP BGP Neighbors BFD

BFD BFD Neighbors BFD

BGP Bootstraps BFD

BFD Configuration

SP
AS 123

interface GigabitEthernet0/0/0
bfd interval 100 min_rx 100 multiplier 3 router bgp 123
! bfd minimum-interval 100
router bgp 123 bfd multiplier 3
neighbor 10.0.0.6 fall-over bfd Enable BFD on neighbor 10.0.101.1
an interface bfd fast-detect

Enable BFD
support for BGP Enable BFD
support for BGP
Project: MAN-E VNPT Hanoi Expansion 2017

THANK YOU FOR LISTENING !

189