BGP

Table of Contents
BGP .............................................................................................................................................................. 6
Course Description...................................................................................................................................... 6
Course Highlights........................................................................................................................................ 6
Requirements............................................................................................................................................... 6
Course Schedule .......................................................................................................................................... 6
Introduction to BGP ...................................................................................................................................... 6
Why do we need BGP? .................................................................................................................................. 7
Autonomous Systems ................................................................................................................................... 9
BGP Advertisements ................................................................................................................................... 10
Default Route ...................................................................................................................................... 11
Partial Routing Updates ...................................................................................................................... 12
Full Internet Routing Table ................................................................................................................. 13
Path Vector ................................................................................................................................................. 13
BGP Route Selection ................................................................................................................................... 14
Conclusion ................................................................................................................................................... 15
Single/Dual Homed and Multi-homed Designs....................................................................................... 15
Single Homed............................................................................................................................................. 15
Dual Homed ............................................................................................................................................... 15
Single Multi-homed ................................................................................................................................... 16
Dual Multihomed ...................................................................................................................................... 17
Conclusion ................................................................................................................................................. 18
How to configure EBGP (External BGP)....................................................................................................... 18
EBGP Multihop ............................................................................................................................................ 21
Internal BGP (Border Gateway Protocol) explained ............................................................................. 26
Configuration ............................................................................................................................................ 29
Verification ................................................................................................................................................ 30
IBGP Neighbor Adjacencies .................................................................................................................... 38
How to Read the BGP Table ........................................................................................................................ 41
Configuration .............................................................................................................................................. 41
Reading the BGP Table ............................................................................................................................ 42
BGP Looking Glass Server....................................................................................................................... 44
How to advertise networks in BGP ......................................................................................................... 46
Network Command ................................................................................................................................... 47
Redistribution ............................................................................................................................................ 50
BGP Next Hop Self ....................................................................................................................................... 50
Configuration .............................................................................................................................................. 51
Advertise Network .............................................................................................................................. 52
Next Hop Self ...................................................................................................................................... 53
BGP Auto-Summary .................................................................................................................................... 55
Page 1 of 283
BGP Neighbor Adjacency States ............................................................................................................. 56
BGP Messages ........................................................................................................................................... 60
Open Message ............................................................................................................................................ 61
Update Message ......................................................................................................................................... 62
Keepalive Message .................................................................................................................................... 64
Notification Message ................................................................................................................................. 64
Troubleshooting BGP Neighbor Adjacency ........................................................................................... 66
BGP Interface Issues................................................................................................................................. 66
EBGP Requirements ................................................................................................................................. 67
BGP TCP Port Filtering ........................................................................................................................... 69
IBGP Update Source................................................................................................................................. 71
Troubleshooting BGP Route Advertisement .......................................................................................... 73
BGP Network Command.......................................................................................................................... 73
BGP Summarization ................................................................................................................................. 75
BGP Auto-Summary ................................................................................................................................. 76
BGP Route-Maps ...................................................................................................................................... 78
IBGP Split Horizon ................................................................................................................................... 80
BGP Next Hop ........................................................................................................................................... 81
BGP Attributes and Path Selection ............................................................................................................. 84
Attributes .................................................................................................................................................... 84
Weight ................................................................................................................................................. 85
Local Preference.................................................................................................................................. 85
Originate ............................................................................................................................................. 85
AS path length ..................................................................................................................................... 85
Origin code .......................................................................................................................................... 86
MED ..................................................................................................................................................... 86
eBGP path over iBGP path .................................................................................................................. 86
Shortest IGP path to BGP next hop ..................................................................................................... 86
Oldest Path .......................................................................................................................................... 86
Router ID ............................................................................................................................................. 86
Neighbor IP address ............................................................................................................................ 86
Path Selection ............................................................................................................................................. 86
How to Configure BGP Weight Attribute .............................................................................................. 87
How to Configure BGP Local Preference Attribute .............................................................................. 92
How to configure BGP AS Path Prepending .......................................................................................... 97
BGP Origin Code Attribute explained .................................................................................................... 99
How to configure BGP MED Attribute................................................................................................. 101
BGP Communities Explained ..................................................................................................................... 104
Configuration ............................................................................................................................................ 106
Page 2 of 283
BGP Configuration ............................................................................................................................. 107
ISP1 AS Path Prepend Configuration................................................................................................. 107
Customer BGP Community Configuration ........................................................................................ 108
Verification ................................................................................................................................................ 108
BGP Community No Advertise .................................................................................................................. 110
Configuration ............................................................................................................................................ 110
BGP Community No Export ....................................................................................................................... 114
Configuration ............................................................................................................................................ 115
Basic BGP Configuration.................................................................................................................... 115
BGP Community No-Export Configuration........................................................................................ 116
BGP Community Local AS .......................................................................................................................... 118
Configuration ............................................................................................................................................ 118
Local AS Community Configuration .................................................................................................. 124
BGP Regular Expressions Examples .......................................................................................................... 128
Characters ................................................................................................................................................. 128
Examples ................................................................................................................................................... 129
BGP Prevent Transit AS ........................................................................................................................ 129
Filter-list with AS PATH access-list ...................................................................................................... 131
No-Export Community .............................................................................................................................. 132
Prefix-List Filtering .................................................................................................................................... 134
Distribute-list Filtering .............................................................................................................................. 135
BGP IPv6 Route Filtering on Cisco IOS ...................................................................................................... 137
Configuration ............................................................................................................................................ 137
Prefix-List Filtering ............................................................................................................................ 138
Filter-List Filtering ............................................................................................................................. 139
Route-Map Filtering .......................................................................................................................... 140
Order of Operation ................................................................................................................................... 140
BGP AS Path Filter Example ................................................................................................................. 143
Only allow prefixes that originated from AS 3257 ............................................................................... 144
Only allow networks that passed through AS 3257 ............................................................................. 145
Deny prefixes that originated from AS 56203 and permit everything else ........................................ 145
Allow prefixes from AS 3257 and its directly connected ASes but deny the rest .............................. 146
BGP Extended Access-List Filtering ........................................................................................................... 147
Configuration ............................................................................................................................................ 148
Filter specific prefixes ....................................................................................................................... 149
Filter all 192.168.x.0 networks with a /24 prefix length ................................................................... 150
Filter all 10.x.x.0 networks with a /24 prefix length ......................................................................... 151
Filter all 10.x.x.x networks with a /25 prefix length.......................................................................... 152
Filter all 192.168.7.x networks with any prefix length ..................................................................... 153
Page 3 of 283
Filter anything with a /24 to /32 prefix length.................................................................................. 154
Filter anything with a /26 to /32 prefix length.................................................................................. 156
Filter 172.16.0.0 networks with a /27 to /32 prefix length .............................................................. 157
Conclusion ................................................................................................................................................. 158
BGP Peer Groups on Cisco IOS .................................................................................................................. 161
Configuration ............................................................................................................................................ 161
Without BGP Peer Group .................................................................................................................. 162
With BGP Peer Group........................................................................................................................ 163
BGP Route Reflector .............................................................................................................................. 165
Configuration .......................................................................................................................................... 167
Verification .............................................................................................................................................. 168
BGP Confederation Explained ................................................................................................................... 170
Configuration ............................................................................................................................................ 173
OSPF Configuration ........................................................................................................................... 173
BGP Confederation Configuration .................................................................................................... 173
Verification ................................................................................................................................................ 174
BGP Synchronization ................................................................................................................................. 179
OSPF Configuration ................................................................................................................................... 181
BGP Configuration ..................................................................................................................................... 181
BGP synchronization disabled ................................................................................................................... 182
BGP synchronization enabled ................................................................................................................... 183
BGP Backdoor Routes ............................................................................................................................... 186
OSPF Configuration ................................................................................................................................... 187
BGP Configuration ..................................................................................................................................... 188
BGP Backdoor Configuration..................................................................................................................... 188
Verification ................................................................................................................................................ 189
Multiprotocol BGP (MP-BGP) Configuration............................................................................................. 191
Configuration ............................................................................................................................................ 191
MP-BGP with IPv6 adjacency & IPv6 prefixes ................................................................................... 191
MP-BGP with IPv4 adjacency & IPv6 prefixes ................................................................................... 193
BGP Private and Public AS Range ........................................................................................................ 196
BGP Remove Private AS ............................................................................................................................ 197
Configuration ............................................................................................................................................ 198
Remove-Private-AS ........................................................................................................................... 199
Remove-Private-AS All ...................................................................................................................... 199
Remove-Private-AS All Replace ......................................................................................................... 201
BGP 4-Byte AS Number ............................................................................................................................. 202
Configuration ............................................................................................................................................ 203
4-byte AS support ............................................................................................................................. 203
Page 4 of 283
2-byte AS support ............................................................................................................................. 205
Conclusion ............................................................................................................................................... 207
BGP Soft Reconfiguration ...................................................................................................................... 207
Configuration .......................................................................................................................................... 209
BGP Route Refresh Capability .............................................................................................................. 212
Configuration .......................................................................................................................................... 213
MPLS Layer 3 VPN BGP Allow-AS-In .......................................................................................................... 216
Conclusion ................................................................................................................................................. 224
MPLS Layer 3 VPN BGP AS Override ......................................................................................................... 224
Conclusion ................................................................................................................................................. 233
BGP Aggregate AS-SET .............................................................................................................................. 233
Configuration ............................................................................................................................................ 233
Without AS-SET ................................................................................................................................. 235
With AS-SET....................................................................................................................................... 235
Conclusion ................................................................................................................................................. 236
BGP Multipath load sharing iBGP and eBGP ............................................................................................. 237
Configuration ............................................................................................................................................ 237
eBGP .................................................................................................................................................. 237
iBGP ................................................................................................................................................... 242
Conclusion ............................................................................................................................................... 246
BGP Next Hop Address Tracking ............................................................................................................... 246
Configuration ............................................................................................................................................ 246
Dampening ........................................................................................................................................ 251
Conclusion ................................................................................................................................................. 253
BGP Additional Paths............................................................................................................................. 254
Configuration .......................................................................................................................................... 255
Load Balancing .................................................................................................................................. 259
Sub-optimal Routing ......................................................................................................................... 259
BGP Additional Paths ........................................................................................................................ 260
Conclusion ................................................................................................................................................. 263
BGP PIC (Prefix Independent Convergence) Core & Edge ............................................................... 264
BGP PIC Core ............................................................................................................................................. 268
BGP PIC Edge ............................................................................................................................................. 273
Without BGP PIC Edge....................................................................................................................... 273
With BGP PIC Edge ............................................................................................................................ 276
Conclusion ............................................................................................................................................... 282
Page 5 of 283
BGP
Course Description
BGP (Border Gateway Protocol) is the routing protocol of the Internet, used to route traffic from one
autonomous system (AS) to another. It’s an important topic to understand if you work at an ISP or at a large
company that is connected to two or more ISPs. Unlike IGPs like OSPF or EIGRP, BGP uses a set of attributes
to determine the best path for each destination. There are a lot of options you can use to manipulate traffic
patterns.
Course Highlights
In this course you will learn:
 What BGP is.

 The difference between internal and external BGP.
 How to read the BGP table.
 How BGP uses different attributes instead of a metric to make routing decisions.
 What BGP communities are.
 How to filter BGP networks.
 Advanced topics like BGP peer groups, route reflectors and confederations.
 And many other topics…
Presented to you by instructor Rene Molenaar, CCIE #41726
Requirements
 CCNA R&S equivalent knowledge of how routers and routing protocols operate.
 Good understanding of IGPs like RIP, OSPF and EIGRP.
Course Schedule
 Unit 1: Introduction to BGP
 Unit 2: BGP Neighbor Adjacency
 Unit 3: BGP Attributes
 Unit 4: BGP Communities
 Unit 5: BGP Filtering
 Unit 6: Advanced BGP Features
 Unit 7: BGP Convergence
Introduction to BGP
This lesson will be interesting! BGP (Border Gateway Protocol) is the routing protocol that glues the Internet
together. I’m going to explain in which situations we need BGP and how it works.
Page 6 of 283
Before you continue reading I should tell you to “forget” everything you know about routing protocols like RIP,
OSPF and EIGRP so far…Those three routing protocols have one thing in common: they are all IGPs (Interior
Gateway Protocols). We only use them within our autonomous system but they are not scalable to use for a
network as large as the Internet.
RIP, OSPF and EIGRP are all different but they have one thing in common…they want to find the shortest path
to the destination. When we look at the Internet we don’t care as much as to find the shortest path, being able to
manipulate traffic paths is far more important. There is only one routing protocol we currently use on the
Internet which is BGP.
Why do we need BGP?

Let’s start by looking at some scenarios so you can understand why and when we need BGP:
Nowadays almost everything is connected to the Internet. In the picture above we have a customer network
connected to an ISP (Internet Service Provider). Our ISP is making sure we have Internet access. Our ISP has
given us a single public IP address we can use to access the Internet. To make sure everyone on our LAN at
the customer side can access the Internet we are using NAT/PAT (Network / Port address translation) to
translate our internal private IP addresses to this single public IP address. This scenario is excellent when you
only have clients that need Internet access. On our customer LAN we only need a default route pointing to the
ISP router and we are done. For this scenario we don’t need BGP…
Maybe the customer has a couple of servers that need to be reachable from the Internet…perhaps a mail- or
webserver. We could use port forwarding and forward the correct ports to these servers so we still only need a
single IP address. Another option would be to get more public IP addresses from our ISP and use these to
configure the different servers. For this scenario we still don’t need BGP…
Page 7 of 283
What if I want a bit more redundancy? Having a single point of failure isn’t a good idea. We could add another
router at the customer side and connect it to the ISP. You can use the primary link for all traffic and have
another link as the backup. We still don’t require BGP in this situation, it can be solved with default routing:
 Advertise a default route in your IGP on the primary customer router with a low metric.
 Advertise a default route in your IGP on the secondary customer router with a high metric.
This will make sure that your IGP sends all traffic using the primary link. Once the link fails your IGP will
make sure all traffic is sent down the backup link. Let me ask you something to think about…can we do any
load balancing across those two links? It’ll be difficult right?
Your IGP will send all traffic down the primary link and nothing down the backup link unless there is a failure.
You could advertise a default route with the same metric but you’d still have something like a 50/50% load
share. What if I wanted to send 80% of the outgoing traffic on the primary link and 20% down the backup link?
That’s not going to happen here but with BGP it’s possible.
This scenario is a bit more interesting. Instead of being connected to a single ISP we now have two different
ISPs. For redundancy reasons it’s important to have two different ISPs, in case one fails you will always have a
backup ISP to use. What about our Customer network? We still have two servers that need to be reachable from
the Internet.
Page 8 of 283
In my previous examples we got public IP addresses from our ISP. Now I’m connected to two different ISPs so
what public IP addresses should I use? From ISP1 or ISP2? If we use public IP addresses from ISP1 (or ISP2)
then these servers will be unreachable once the ISP has connectivity issues.
Instead of using public IP addresses from the ISP we will get our own public IP addresses.The IP address space
is maintained by IANA (Internet Assigned Numbers Authority – http://www.iana.org/ ). IANA is assigning IP
address space to a number of large Regional Internet Registries like RIPE or ARIN. Each of these assign IP
address space to ISPs or large organizations.
When we receive our public IP address space then we will advertise this to our ISPs. Advertising is done with a
routing protocol and that will be BGP.
If you are interested here’s an overview of the IPv4 space that has been allocated by IANA:
IANA IPv4 address space
Autonomous Systems
Besides getting public IP address space we also have to think about an AS (Autonomous System):
An AS is a collection of networks under a single administrative domain. The Internet is nothing more but a
bunch of autonomous systems that are connected to each other. Within an autonomous system we use an IGP
like OSPF or EIGRP.
For routing between the different autonomous systems we use an EGP (external gateway protocol). The only
EGP we use nowadays is BGP.
How do we get an autonomous system number? Just like public IP address space you’ll need to register one.
Page 9 of 283
Autonomous system numbers are 16-bit which means we have 65535 numbers to choose from. Just like private
and public IP addresses, we have a range of public and private AS numbers.
Range 1 – 64511 are globally unique AS numbers and range 64512 – 65535 are private autonomous system
numbers.
If you are interested, see if you can find the AS number of your ISP:
UltraTools AS Information Lookup
BGP has two flavors:
 External BGP: used between autonomous systems

 Internal BGP: used within the autonomous system.
External BGP is to exchange routing information between the different autonomous systems. In this lesson I
explain why we need internal BGP. I would recommend to read it after finishing this lesson and learning about
external BGP first.
BGP Advertisements
You now have an idea of why we require BGP and what autonomous systems are. The Internet is a big place, as
I am writing this there are more than 500.000 prefixes in a complete Internet routing table. If you are curious,
you can find the size of the Internet routing table here:
CIDR Report
On the internet there are a number of looking glass servers. These are routers that have public view access and
you can use them to look at the Internet routing table. If you want to see what it looks like check out:
Looking glass servers
Scroll down all the way to “Category 2 – IPv4 and IPv6 BGP Route Servers by region (TELNET access)”. You
can telnet to these devices and use show ip route and show ip bgp to check the BGP or routing table.
When we run BGP, does this mean we have to learn more than 500.000 prefixes? It depends…let’s look at
some examples:
Page 10 of 283
Above in our picture our customer network has an autonomous system number (AS 1) and some IP address
space (10.0.0.0 /8), let’s pretend that these are public IP addresses. We are connected to two different ISPs and
you can see their AS number (AS2 and AS3) and IP address space (20.0.0.0/8 and 30.0.0.0/8). We can reach the
rest of the internet through both ISPs.
We can use BGP to advertise our address space to the ISPs but what are the ISPS going to advertise to our
customer through BGP? There are a number of options:
 They advertise only a default route.

 They advertise a default route and a partial routing table.
 They advertise the full Internet routing table.
Let’s walk through these three options![teaser]
Default Route
Page 11 of 283
Receiving a default route requires the fewest resources on your routers since you only have a single entry to
reach any external network. The customer router will advertise its 10.0.0.0 /8 network to both ISPs which will
advertise it to any other AS they are connected to and we will use a default route to reach anything on the
Internet. The downside of this configuration is that our customer network doesn’t know what is behind ISP1 and
ISP2. We have connectivity because of the default routes but this can lead to sub-optimal routing. If we only
have the default routes then we will send all traffic to one of the ISPs.
Here’s what could happen if you only use default routes:
Our customer network only received a default route from both ISPs and we have chosen to use the default route
of ISP1 to send all our outgoing traffic to. This means that whenever we send traffic meant for 30.0.0.0 /8
(ISP2) it’s going to be sent to ISP1 and then to ISP2. It’s not a problem but it’s not optimal.
Partial Routing Updates
Page 12 of 283
We can also receive a partial routing table plus a default route. This partial update might include all the IP
address space that the ISPs have assigned to their customers.
Just like in real life…the more you know the better off you are (unless you believe ignorance is bliss). In the
world of routing having more routing information means you can make better routing decisions. We’ll have less
sub-optimal routing problems than when we only have the default route.
Full Internet Routing Table
The last option that we have is that we receive the full Internet routing table from both ISPs. This requires more
resources but we’ll be able to make the best routing decisions.
Path Vector
BGP is called a path vector routing protocol. What does this mean? Take a look at this image:
Page 13 of 283
We have 4 autonomous systems and we are running BGP to exchange routing information. In AS 1 we have
network 1.1.1.0 /24 and this is advertised to AS 2, AS 3 and AS 4.
If we would look at the BGP table of the router in AS4 then we will see network 1.1.1.0 /24 but it also stores the
path we have to get through in order to get there. It will store the prefix but also the paths it has to cross in
order to get to 1.1.1.0 /24. Here’s an example of a real BGP router:
route-views.optus.net.au>show ip bgp
BGP table version is 128380331, local router ID is 203.202.125.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path

* 1.0.0.0/24 202.160.242.71 0 7473 15169 i
The output above is from one of the BGP looking glass servers.
By using the show ip bgp command I can look at the BGP table and we see this router knows about network
1.0.0.0 /24. The next-hop IP address is 202.160.242.71. At the end of the line you see path with the numbers
7473 15169. These are the autonomous systems we have to get through in order to get to this network.
BGP Route Selection

What all IGPs have in common is that all of them want to find the shortest path to the destination. BGP works
differently, since autonomous systems belong to different ISPs or organizations we want to be able to
selectively influence our routing. Take a look at this example:
BGP allows us to use routing policies at the autonomous system level. In the picture above I have 9 autonomous
systems and in AS 9 we have network 192.168.9.0 /24. If we look at AS 1 then we have a lot of different paths
we can take to reach network 192.168.9.0 /24 in AS 9.
Page 14 of 283
Does this mean the network administrator at AS 1 can choose the path we are going to use? Not really because
of the following reasons:
 You can choose the exit path…AS1 can send traffic to AS 2 or AS4 but you don’t make routing decisions for other
autonomous systems.
 Each autonomous system will only advertise the best path to your autonomous system. AS 1 will only learn
about the best path from AS 2 and AS 4 unless their best path fails…only then you will learn about the second
best path.
BGP uses a set of BGP attributes to select a path, these are covered in other lessons.
Conclusion
Hopefully this lesson has been helpful to understand the basics of BGP and why we use it. In other lessons we
will take a closer look at the configuration of external and internal BGP and also how the BGP path selection
works.
Single/Dual Homed and Multi-homed Designs

When talking about ISPS, BGP, and connections, sometimes you will hear terminology like “single homed”,
“dual homed”,”single multi-homed” or “dual multi-homed”. These are different design topologies where we
describe how a customer is connected (using BGP) to one or more ISPs.
Let’s take a look at some examples.
Single Homed
The single homed design means you have a single connection to a single ISP. With this design, you don’t need
BGP since there is only one exit path in your network. You might as well just use a static default route that
points to the ISP.
The advantage of a single-homed link is that it’s cost effective, the disadvantage is that you don’t have any
redundancy. Your link is a single point of failure but so is using a single ISP.
Dual Homed
The dual homed connection adds some redundancy. You are still only connected to a single ISP, but you use
two links instead of one. There are some variations for this design. Here’s the first one:
Page 15 of 283
With this design, we use a single router on both ends, but we do have redundant links.
To increase redundancy, we can add a second router:
In the example above, the ISP has a second router. We also could have used a second router at the customer’s
side and a single router at the ISP. For even more redundancy, add a second router at both sides:
The example above offers the most redundancy when you are connected to a single ISP. We have two links and
two routers on both ends. One disadvantage of this design is that we are still using a single ISP.
Single Multi-homed
Multihomed means we are connected to at least two different ISPs. The most simple design looks like this:
Page 16 of 283
Above you see that we have a single router at the customer, connected to two different ISPs. The single point of
failure in this design is that you only have one router at the customer. When it fails, you won’t be able to
connect to any ISP. We can improve this by adding a second router:
This is a pretty good design, we only use single links, but we are connected to two different ISPs using different
routers.
Dual Multihomed
The dual multihomed designs means we are connected to two different ISPs, and we use redundant links. There
are some variations, here’s the first one:
Page 17 of 283
Above you can see that we are connected to two different ISPs, using one router and two links to each ISP. We
have redundant ISPs and links, but the router is still a single point of failure. We can improve this by adding a
second router:
The design above is better; it has two customer routers. One disadvantage, however, is that once one of your
router fails, you will lose the connection to one of the ISPs. Using the same number of routers and links, the
following design might be better:
This design has redundant ISPs, routers, and links. Both customer routers are connected to both ISPs. This
design does offer the highest redundancy but it’s also an expensive option.
Conclusion
You have now learned what the different (BGP) connection options to an ISP are:
 Single homed: you are connected to a single ISP using a single link.
 Dual homed: you are connected to a single ISP using dual links.
 Single multi-homed: you are connected to two ISPs using single links.
 Dual multi-homed: you are connected to two ISPs using dual links.
How to configure EBGP (External BGP)

In this lesson I will show you how to configure EBGP (External BGP) and how to advertise networks. I will be
using the following topology:
Page 18 of 283
Let’s start with a simple topology. Just two routers and two autonomous systems. Each router has a network on
a loopback interface which we are going to advertise in BGP.
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
Use the router bgp command with the AS number to start BGP. Neighbors are not configured automatically
this is something you’ll have to do yourself with the neighbor x.x.x.x remote-as command. This is how we
configure external BGP.
R1# %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up

If everything goes ok you should see a message that we have a new BGP neighbor adjacency.
R1(config-router)#neighbor 192.168.12.2 password MYPASS
R2(config-router)#neighbor 192.168.12.1 password MYPASS
If you like you can enable MD5 authentication by using the neighbor password command. Your router will
calculate a MD5 digest of every TCP segment that is being sent.
R1#show ip bgp summary

BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.12.2 4 2 10 10 1 0 0 00:07:12 0

192.168.12.1 4 1 11 11 1 0 0 00:08:33 0
Show ip bgp summary is an excellent command to check if you have BGP neighbors. You also see how many
prefixes you received from each neighbor.
[teaser]
R1(config-router)#network 1.1.1.0 mask 255.255.255.0
Page 19 of 283
Let’s advertise the loopback interface by using the network command. If you want to advertise something with
BGP you need to make sure you type the exact subnet mask for the network you want to advertise. If I would
type network 1.0.0.0 mask 255.0.0.0 on R1 it will not work since this entry is not in the routing table.
R1#show ip bgp
r RIB-failure, S Stale

*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 2.2.2.0/24 192.168.12.2 0 0 2 i
Use show ip bgp to look at the BGP database. You can see that R1 has learned about network 2.2.2.0 /24 and
the next hop IP address is 192.168.12.2. It also shows the path information. You can see that network 2.2.2.0
/24 is from AS 2.
R2#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
R2 learned about network 1.1.1.0/24 with a next hop IP address of 192.168.12.1.
R1#show ip route bgp

2.0.0.0/24 is subnetted, 1 subnets
B 2.2.2.0 [20/0] via 192.168.12.2, 00:16:13
B 1.1.1.0 [20/0] via 192.168.12.1, 00:16:59
In the routing table we can find an entry for BGP with an administrative distance of 20 for external BGP.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
interface Loopback 0
ip address 1.1.1.1 255.255.255.0
!
interface fastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
neighbor 192.168.12.2 remote-as 2
neighbor 192.168.12.2 password MYPASS
network 1.1.1.0 mask 255.255.255.0
Page 20 of 283
!
end
hostname R2
!
ip address 2.2.2.2 255.255.255.0
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
neighbor 192.168.12.1 password MYPASS
network 2.2.2.0 mask 255.255.255.0
!
end
EBGP Multihop
eBGP (external BGP) by default requires two Cisco IOS routers to be directly connected to each other in order
to establish a neighbor adjacency. This is because eBGP routers use a TTL of one for their BGP packets. When
the BGP neighbor is more than one hop away, the TTL will decrement to 0 and it will be discarded.
When these two routers are not directly connected then we can still make it work but we’ll have to use
multihop. This requirement does not apply to internal BGP.
Here’s an example:
Above we will try to configure eBGP between R1 and R3. Since R2 is in the middle, these routers are more
than one hop away from each other. Let’s take a look at the configuration:
R1(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2

R3(config)#ip route 192.168.12.1 255.255.255.255 192.168.23.2
First I will create some static routes so that R1 and R3 are able to reach each other. Now we can configure
eBGP:
Page 21 of 283
Even though this configuration is correct, BGP will not even try to establish a eBGP neighbor adjacency. BGP
knows that since these routers are on different subnets, they are not directly connected. We can verify this with
the following command:
R1#show ip bgp neighbors | include External

External BGP neighbor not directly connected.
R3#show ip bgp neighbors | include External
External BGP neighbor not directly connected.
Just for fun, let’s disable this check so that R1 and R3 try to become eBGP neighbors. We can do that like this:
R1(config-router)#neighbor 192.168.23.3 disable-connected-check

R3(config-router)#neighbor 192.168.12.1 disable-connected-check
Our routers will now try to become eBGP neighbors even though they are not directly connected. Here’s what
happens now:
The wireshark capture above shows us that R1 is trying to connect to R3. As you can see the TTL is 1. Once R2
receives this packet it will decrement the TTL by 1 and drop it:
Page 22 of 283
Above you can see that R2 is dropping this packet since the TTL is exceeded. It will send an ICMP time-to-live
exceeded message to R1. Our BGP routers will show a message like this:
R1#
BGP: 192.168.23.3 open failed: Connection timed out; remote host not responding, open
active delayed 27593ms (35000ms max, 28% jitter)
This is R1 telling us that it couldn’t connect to R3. To fix this issue, we’ll tell eBGP to increase the TTL. First
let’s enable the directly connected check again:
R1(config-router)#no neighbor 192.168.23.3 disable-connected-check

R3(config-router)#no neighbor 192.168.12.1 disable-connected-check
And now we will increase the TTL:
R1(config-router)#neighbor 192.168.23.3 ebgp-multihop 2

Use the ebgp-multihop command to increase the TTL. Using a value of 2 is enough in our example. R2 will
receive a packet with a TTL of 2, decrements it by 1 and forwards it to R3. We can verify this change by
looking at the show ip bgp neighbors command:
R1 & R3
#show ip bgp neighbors | include External
External BGP neighbor may be up to 2 hops away.
Page 23 of 283
R1 and R3 both agree that the BGP neighbor could be 2 hops away. Here’s what the BGP packet looks like in
wireshark:
This capture shows us the TTL of 2. After a few seconds, our routers will become eBGP neighbors:
R1#
%BGP-5-ADJCHANGE: neighbor 192.168.23.3 Up
R3#
That’s it, problem solved!
hostname R1
!
ip address 192.168.12.1 255.255.255.0
!
ip route 192.168.23.3 255.255.255.255 192.168.12.2
!
router bgp 1
neighbor 192.168.23.3 ebgp-multihop 2
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
end
hostname R3
!
ip address 192.168.23.3 255.255.255.0
!
ip route 192.168.12.1 255.255.255.255 192.168.23.2
!
Page 24 of 283
router bgp 3
!
end
Even though R1 and R3 are now neighbors, having a non-BGP in router in between R1 and R3 is a bad idea. R1
and R3 might exchange prefixes through BGP but once packets reach R2, it will have no clue where to forward
these packets to…
Now you understand how eBGP multihop works, let’s take a look at a more useful scenario:
Above we have two routers…R1 and R2. They are directly connected but we have two links in between them
and we would like to use these for load balancing. Instead of using the IP addresses on these FastEthernet
interfaces for the eBGP neighbor adjacency we will use the IP addresses on the loopback interfaces for this.
Let’s take a look at the configuration:[teaser]
R1(config)#ip route 2.2.2.0 255.255.255.0 192.168.12.2

R1(config)#ip route 2.2.2.0 255.255.255.0 192.168.21.2
R2(config)#ip route 1.1.1.0 255.255.255.0 192.168.12.1
R2(config)#ip route 1.1.1.0 255.255.255.0 192.168.21.1
On each router we will configure two static routes, this allows us to use load balancing to reach the loopback
interfaces. Now we can configure eBGP:
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
Besides configuring the TTL to 2 with the ebgp-multihop command we also have to use the update-source
command to tell the routers to use the IP address on their loopback interface as the source IP address for the
eBGP neighbor adjacency. After a few seconds, these routers will become neighbors:
R1#
R2#
Thanks to our static routes, we will use load balancing between the two routers:
R1#show ip route static

Page 25 of 283
S 2.2.2.0 [1/0] via 192.168.21.2
[1/0] via 192.168.12.2
R2#show ip route static
S 1.1.1.0 [1/0] via 192.168.21.1
[1/0] via 192.168.12.1
hostname R1
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.21.1 255.255.255.0
!
ip route 2.2.2.0 255.255.255.0 192.168.12.2
ip route 2.2.2.0 255.255.255.0 192.168.21.2
!
router bgp 1
neighbor 2.2.2.2 update-source loopback 0
!
end
hostname R2
!
ip address 2.2.2.2 255.255.255.0
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.21.2 255.255.255.0
!
ip route 1.1.1.0 255.255.255.0 192.168.12.1
ip route 1.1.1.0 255.255.255.0 192.168.21.1
!
router bgp 2
!
end
Internal BGP (Border Gateway Protocol) explained

In this tutorial we’ll take a look at IBGP (Internal BGP). Students who are new to BGP often wonder why we
have “external” and “internal” BGP. I’m not going to show you just a couple of quick commands but we’ll take
a close look at IBGP and its configuration.
Let’s start with an example topology and I’ll explain a couple of things:
Page 26 of 283
Above you see 3 autonomous systems and 5 routers. When AS1 wants to reach AS3 we have to cross AS2, this
makes AS2 our transit AS. This is a typical scenario where AS1 and AS3 are customers and AS2 is the ISP.
In our scenario, AS1 has a loopback interface with network 1.1.1.0 /24 and AS3 wants to reach this network.
This means we’ll have to advertise this network through BGP. Here’s what it looks like:
Page 27 of 283
So what is going on here? Let me explain it step-by-step:
1. We need EBGP between AS1 and AS2 because these are two different autonomous systems. This allows
us to advertise a prefix on R1 in BGP so that AS2 can learn it.
2. We also need EBGP between AS2 and AS3 so that R5 can learn prefixes through BGP.
3. We need to get the prefix that R2 learned from R1 somehow to R5. We do this by configuring IBGP
between R2 and R4, this allows R4 to advertise it to R5.
So that’s the first reason why we need IBGP…so you can advertise a prefix from one autonomous system to
another. You might have a few questions after reading this:
1. Why don’t we use OSPF (or EIGRP) on AS2 instead and redistribute the prefix on R2 from BGP into
OSPF and on R4 from OSPF back into BGP?
2. Doesn’t IBGP have to be directly connected?
3. How are R2 and R4 able to reach each other through IBGP if we don’t have any routing protocol within
AS2?
4. What about R3? do we need IBGP?
These are some of the questions I get all the time from students who are learning BGP, here are the answers:
1. Technically this is possible…we can run OSPF (or EIGRP) within AS2 and use redistribution between
BGP and OSPF. In my example R1 will only have a single prefix so it’s no problem but what if R1 had
a full internet routing table? (over 500.000 prefixes since 2014). IGPs like OSPF or EIGRP are not able
to handle that many prefixes so you’ll need BGP for this.
Page 28 of 283
2. IBGP does not have to be directly connected, this might be a little confusing when you only know about
OSPF or EIGRP since they always form adjacencies on directly connected links.
3. They are not! This is why we need an IGP within the AS. Since R2 and R4 are not directly connected
we’ll configure an IGP so that they can reach each other.
4. I’ll give you the answer to this question in a bit…I want to show you what will go wrong if we don’t
configure R3
Enough reading for now, let’s get our hands dirty with some configuration. We’ll start with BGP between
R1/R2, R2/R4 and R4/5 like I just described.
Configuration
First we’ll configure R1 and R2. I am also advertising a prefix (on a loopback interface) in BGP:

That’s easy enough, just a few commands. Our next step will be to configure IBGP between R2 and R4…what
IP addresses are we going to use for this? Let’s look at our options:
R2#show ip interface brief

Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.12.2 YES NVRAM up up
R4#show ip interface brief
I can use any of these IP addresses but we need connectivity. That’s why we need an IGP like we talked about
earlier. So which IP addresses will we select? In this particular scenario it really doesn’t matter since there is
only 1 path between R2 and R4. What if we had multiple paths between R2 and R4?
When there are multiple paths it’s better to use a loopback interface with an IP address and to advertise that
into your IGP. We will use the loopback interface as the source for our BGP session. Why?
A physical interface can go down which means the IP address on the interface is no longer reachable. A
loopback interface will never go down unless the router crashes or when you “shut” it. This is why it’s best
practice to use loopback interfaces when configuring IBGP.
I’ll add a loopback interface on R2 and R4 and use these for IBGP, first we’ll have to configure an IGP (I’ll use
OSPF) to advertise them:
R2(config)#interface loopback 0
R2(config-if)#ip address 2.2.2.2 255.255.255.0
That takes care of the loopback interfaces, now we can enable OSPF:
Page 29 of 283
R2(config)#router ospf 1
R2(config-router)#network 192.168.23.0 0.0.0.255 area 0
Excellent, R2 and R4 will now be able to reach each others loopback interfaces. It’s not a bad idea to test this
though:
R2#ping 4.4.4.4 source 2.2.2.2
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/52/60 ms
Alright we are now prepared for IBGP between R2 and R4. Here’s what it looks like:
This takes care of our IBGP session. Note that we have to use the update-source command to specify that we
will use the loopback interfaces as the source for the IBGP session.
Last but not least, let’s configure EBGP between R4 and R5:
Great, that takes care of that. Whenever you configure BGP you will see a message on the console that shows
you that the neighbor adjacency has been established. You can also check it with the show ip bgp summary
command.
Verification
If everything went OK, all routers should have learned about the 1.1.1.0 /24 prefix that I advertised on R1. Let’s
see if that is true:
First we’ll check R1:
R1#show ip bgp
Page 30 of 283

*> 1.1.1.0/24 0.0.0.0 0 32768 i
You can see that it is in the BGP table. This means that I succesfully used the network command to advertise
into BGP. The next hop is 0.0.0.0 since it originated on this router. If you don’t see anything here then normally
there are two reasons for this:
[teaser]
 You can’t advertise something in BGP that is not in your routing table, make sure the interface is up/up.
 You typed an incorrect subnet mask when you used the network command (has to be exact match!).
Let’s see what R2 thinks about this:
R2#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
That’s looking good too. R2 knows about our prefix, you can see that the next hop is the IP address of R1. If
you take a closer look you can see the > symbol in front of the prefix, this means that the router selected this
entry as the best one and that it installed it in the routing table. Let’s check R4, it should receive this
information from R2:
R4#show ip bgp

* i1.1.1.0/24 192.168.12.1 0 100 0 1 i
R4 learned about the prefix but there’s something going on here…there is no > symbol before the prefix so R4
didn’t install this in the routing table. Can you tell why this is happening? Take a close look at the next
hop…I’ll give you the answer in a sec, let’s check R5 first:
R5#show ip bgp
There’s nothing in R5…that’s because R4 is having some issues, look closely:

* i1.1.1.0/24 192.168.12.1 0 100 0 1 i
Does R4 have any idea how to reach the next hop? BGP doesn’t change the next hop IP address by default
so this can cause some issues. Let’s verify if R4 knows how to reach the next hop:
Page 31 of 283
R4#show ip route 192.168.12.1
% Network not in table
No next hop, so we can’t install the prefix from BGP into the routing table…how are we going to fix this? As
always there are multiple options:
 Advertise network 192.168.12.0 /24 in a routing protocol (IGP or BGP).

 Change the next hop IP address with the next-hop-self command.
I’ll change the next hop IP address since it’s a good practice, here’s how it works:
R2(config-router)#neighbor 4.4.4.4 next-hop-self
I’m doing this on both R2 and R4. For this scenario I don’t have to do it but if I would advertise something on
R5 then R2 would have the same problem as R4. Take a look again R4 to see the changes:
R4#show ip bgp

*>i1.1.1.0/24 2.2.2.2 0 100 0 1 i
Excellent…two important changes here. First of all you see the > symbol which means R4 was able to install
this prefix in the routing table. Secondly, the next hop IP address has been changed to something R4 knows (the
loopback interface of R2).
Since R4 is now able to install it in the routing table, it can advertise the prefix to R5:
R5#show ip bgp

*> 1.1.1.0/24 192.168.45.4 0 2 1 i
R5 has learned about the prefix…so far so good, you can see that it’s in the routing table:

B 1.1.1.0 [20/0] via 192.168.45.4, 00:02:08
That’s looking good. So are we done? Is there connectivity? Let’s find out:
R5#ping 1.1.1.1

Page 32 of 283
.....
Success rate is 0 percent (0/5)
Uh-oh…something went wrong. This is often a very frustrating moment for many BGP students, they see
something in the routing table but it doesn’t work. What is going on here?
Let’s do a quick trace from R5 to see how far we can get to R1:
R5#traceroute 1.1.1.1

Tracing the route to 1.1.1.1
1 192.168.45.4 52 msec 16 msec 32 msec

2 * * *
3 * * *
So our IP packet reaches R4 but after that it went somewhere into oblivion. R4 is not the problem so we’ll have
to check the next device in the path towards R1, that’s R3.
R3 is an interesting router since it doesn’t run BGP, only OSPF. Let’s check R3:

There’s our problem, R3 receives an IP packet with destination 1.1.1.1 but has no clue where to send it so it will
be dropped. How do we fix this?
Once again, you could redistribute BGP into OSPF but that’s a bad idea…1 prefix could work but an entire
internet routing table…not gonna happen!
This is why you need IBGP on all your routers in your transit AS. We need to configure IBGP on R3 so it
learns about our 1.1.1.0 /24 prefix and it will know how to reach the destination.
Just like R2 and R4, I’ll use a loopback interface on R3 as the source of our IBGP session.
I will configure IBGP between R2/R3 and R3/R4. Let’s create a loopback, advertise it in OSPF and configure
BGP:
That takes care of R3, now we’ll configure R2 and R4 to peer with R3:
Page 33 of 283
This will establish IBGP between R2/R3 and R3/R4. Take a look at the BGP table of R3:
R3#show ip bgp

*>i1.1.1.0/24 2.2.2.2 0 100 0 1 i
Very nice…R3 now knows how to reach the 1.1.1.0 /24 network so it’s no longer the problem. Can R5 finally
reach R1? Let’s find out:
R5#ping 1.1.1.1

.....
It still doesn’t work, this is where the frustration turns into a BGP hate rage (just kidding hehe). I’ll show you
what the problem is here…
It’s a good idea to check some of the routers that are closer to R1, see if they are able to ping 1.1.1.1. Let’s start
with R2:
R2#ping 1.1.1.1

!!!!!
No problem for R2, what about R3?
R3#ping 1.1.1.1

.....
R3 is unable to reach R1…interesting! Previously we checked the BGP and routing table of R3 and it has all
information required to reach R1. What could go wrong here? The problem is not R3 but it’s R1..take a look
here:
Page 34 of 283
R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0

C 1.1.1.0 is directly connected, Loopback0
This is all that R1 has in its routing table. What happens is that R1 receives an IP packet from R3 that looks like
this:
 Source IP address: 192.168.23.3

 Destination IP address: 1.1.1.1
When R1 wants to reply to 192.168.23.3 it has no clue where to send it…it’s not in its routing table! If you want
you can verify this with a debug:
R1#debug ip packet
IP packet debugging is on
This will show us what happens when R1 receives the IP packet. Don’t do this on a production router as it will
produce way too much debug information:
R1#
IP: s=1.1.1.1 (local), d=192.168.23.3, len 100, unroutable
R1 says it’s unroutable, the destination is unknown. To fix this problem we have to advertise some additional
networks. I don’t really care about R3 being able to reach R1 but I do want R5 to reach R1.
What we’ll do is advertise the 192.168.45.0 /24 prefix into BGP, we can do this on R4 or R5:
Let’s see if R1 learns this prefix:
R1#show ip bgp

*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 192.168.45.0 192.168.12.2 0 2 3 i
It’s in the BGP table and also in the routing table:

Page 35 of 283
B 192.168.45.0/24 [20/0] via 192.168.12.2, 00:00:50
Let’s try a ping:
R5#ping 1.1.1.1

!!!!!
Finally! it’s working! If you also want to ping R1 from any of the other routers then you need to make sure R1
knows where to send the return traffic.
hostname R1
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
network 2.2.2.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 3.3.3.3 next-hop-self
!
end
Page 36 of 283
hostname R3
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 3.3.3.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
ip address 192.168.45.4 255.255.255.0
!
router ospf 1
network 4.4.4.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname R5
!
ip cef
!
ip address 192.168.45.5 255.255.255.0
Page 37 of 283
!
router bgp 3
network 192.168.45.0 mask 255.255.255.0
!
end
Are we done now? Almost…there’s one more thing I want to learn you about the IBGP neighbor adjacencies…
IBGP Neighbor Adjacencies

Right now our routers within AS2 are configured like this:
This is called full-mesh IBGP. All routers within AS 2 are neighbors with each other. Do we really need the
IBGP peering between R2 and R4? Let’s find out what happens when I remove it…
R2(config-router)#no neighbor 4.4.4.4
R4(config-router)#no neighbor 2.2.2.2
Just to visualize it, our picture now looks like this:
Page 38 of 283
Let’s check out the BGP table of R3 to see what it has:
R3#show ip bgp

*>i1.1.1.0/24 2.2.2.2 0 100 0 1 i
*>i192.168.45.0 4.4.4.4 0 100 0 3 i
R3 learned about 1.1.1.0 /24 from R2 and 192.168.45.0 /24 from R4. This is good, these are prefixes that we
advertised before. Now look at R2:
R2#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
R2 only knows about 1.1.1.0 /24, it didn’t learn about 192.168.45.0 /24 from R3. What about R4?
R4#show ip bgp

r> 192.168.45.0 192.168.45.5 0 0 3 i
R4 only learned about 192.168.45.0 /24 from R5, we don’t see 1.1.1.0 /24 here.
The problem here is that IBGP does not advertise prefixes from one IBGP neighbor to another IBGP
neighbor. This is called BGP split horizon.
There is a good reason why IBGP works like this…
Between different ASes, BGP uses the AS_PATH attribute to avoid routing loops. A prefix will not be accepted
by a BGP router if it sees its own AS number in it…plain and simple. However, within the autonomous system
the AS number does not change so we can’t use this loop prevention mechanism.
Without BGP split horizon, a route could be advertised like this:
Page 39 of 283
R1 could receive an update about a prefix that it originated itself…not a good idea. With BGP split horizon this
can’t occur:
R2 will never forward the IBGP prefixes that it learns from R1 towards R3. This means that all your IBGP
routers have to become neighbors with all other IBGP routers (full-mesh!). If you have a lot of IBGP
routers then this can be a lot of work, the number of required adjacencies is:
X*(X-1)/2
So with 10 IBGP routers you will need to configure 45 IBGP neighbor adjacencies. There are two techniques to
reduce this number:
 BGP Route Reflectors

 BGP Confederations
I will explain both in other tutorials in the future! This is the end of the IBGP explanation, I hope you enjoyed it
and learned a thing or two. If you have any questions feel free to leave a comment!
Page 40 of 283
How to Read the BGP Table
All prefixes that BGP learns are stored in the BGP table. In this lesson we’ll take a look at this table and you
will learn how to read it. We’ll start with a simple topology and finish with a quick peek at a full Internet
routing table.
Configuration
Here’s the topology we will use. 4 routers, each in a different autonomous system:
Want to take a look for yourself? Here you will find the startup configuration of each device.
hostname R1
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
Page 41 of 283
router bgp 2
!
end
hostname R3
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router bgp 3
!
end
hostname R4
!
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
router bgp 4
network 4.4.4.4 mask 255.255.255.255
!
end
The BGP configurations are pretty straight-forward, we are using eBGP here. Note that R4 advertises a network
(loopback interface) in BGP.
Reading the BGP Table

Let’s take a look at the BGP tables. We’ll start with R4:
R4#show ip bgp

*> 4.4.4.4/32 0.0.0.0 0 32768 i
Ok so what do we see here? Let’s start with the items I highlighted in red first. This router has network
4.4.4.4/32 in its BGP table and in front of the network there’s the *> symbol:
 The * means that this is a valid route and that BGP is able to use it.
Page 42 of 283
 The > means that this entry has been selected as the best path.
The next hop is 0.0.0.0. The next hop of 0.0.0.0 means that this network originated on this router, that makes
sense since I used the network command on R4 to advertise this network into BGP.
Further to the right you see metric, local preference and weight. These are the BGP attributes that are used to
select the best path.
Path will show the AS path, there’s nothing there since this network was advertised in BGP on this router. On
the other routers you’ll see something here.
The ‘i’ is the origin code and indicates that this network was advertised into BGP using the network command,
the table says it refers to IGP but it doesn’t have anything to do with “interior gateway protocols”. When you
redistribute something into BGP it will show up with the ? symbol. You will never see the ‘e’ symbol, this
refers to EGP (Exterior Gateway Protocol) which is the predecessor of BGP.
Some of the other things you see here is the BGP table version, every time the best path changes this number
will increase. You can see the BGP router ID of this router and there are some other status codes:
 supressed: BGP knows the network but won’t advertise it, this can occur when the network is part of a
summary.
 damped: BGP doesn’t advertise this network because it was flapping too often (network appears,
disapears, appears, etc.) so it got a penalty.
 history: BGP learned this network but doesn’t have a valid route at the moment.
 RIB-failure: BGP learned this network but didn’t install it in the routing table. This occurs when
another routing protocol with a lower administrative distance also learned it.
 stale: this is used for non-stop forwarding, this entry has to be refreshed when the remote BGP neighbor
has returned.
Let’s look at the BGP tables of the other routers, we’ll continue with R2:
R2#show ip bgp

*> 4.4.4.4/32 192.168.24.4 0 0 4 i
The output of R2 is similar to what we have seen on R4 but there are two important differences. The first one is
the next hop, R2 learned about this network from 192.168.24.4. The second thing is the AS path, it’s showing
AS 4.
Let’s check R1:[teaser]
R1#show ip bgp
Page 43 of 283
* 4.4.4.4/32 192.168.13.3 0 3 4 i
*> 192.168.12.2 0 2 4 i
This output is even more interesting, this router has learned about our network from R2 and R3. Both entries are
valid, they have * in front of them. BGP selected the path through R2 as the best path, you can see the > in front
of this entry.You can also see the AS paths to reach this network.
The best path can be found in the routing table:

B 4.4.4.4 [20/0] via 192.168.12.2, 00:25:51
If you want you can take a closer look at one of the entries in the BGP table, this is useful when you have a lot
of networks:
R1#show ip bgp 4.4.4.4

BGP routing table entry for 4.4.4.4/32, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
1
3 4
192.168.13.3 from 192.168.13.3 (192.168.34.3)
Origin IGP, localpref 100, valid, external
2 4
192.168.12.2 from 192.168.12.2 (192.168.24.2)
Origin IGP, localpref 100, valid, external, best
The information you see above tells us that we have two paths for this network, the second one has been
selected as the best path. Last but not least, let’s take a look at R3:
R3#show ip bgp

* 4.4.4.4/32 192.168.13.1 0 1 2 4 i
*> 192.168.34.4 0 0 4 i
Above you can see that R3 has two entries, it can use R1 or R4 to reach 4.4.4.4/32.
BGP Looking Glass Server

You now have an idea how to read the BGP table, let’s take a look at an actual BGP table that is used on the
Internet. We can use a looking glass server for this. These routers provide read-only access so you can take a
look at their BGP tables. I’ll use the route-views.optus.net.au server for this.
route-views.optus.net.au>show ip bgp summary

Page 44 of 283
539211 network entries using 69019008 bytes of memory
2321994 path entries using 120743688 bytes of memory
200268/89271 BGP path/bestpath attribute entries using 24833232 bytes of memory
78014 BGP AS-PATH entries using 3503222 bytes of memory
3793 BGP community entries using 321910 bytes of memory
18 BGP extended community entries using 448 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 218421508 total bytes of memory
Dampening enabled. 557 history paths, 440 dampened paths
BGP activity 3726941/3187730 prefixes, 16191208/13869214 paths, scan interval 60 secs

192.65.89.161 4 7474 1318568 910036 244799121 0 0 41w2d 21006
202.139.124.130 4 7474 1306375 910020 244799121 0 0 41w2d 21024
202.160.242.71 4 7473 0 0 1 0 0 never Active
203.13.132.29 4 7474 2107424 910019 244799121 0 0 41w2d 20649
203.13.132.35 4 7474 59948648 910162 244799121 0 0 41w2d 538696
203.13.132.37 4 7474 1571073 601855 244799121 0 0 27w2d 20651
203.13.132.41 4 7474 2254818 910043 244799121 0 0 41w2d 20649
203.13.132.47 4 7474 46416 19778 244799121 0 0 6d07h 20649
203.13.132.49 4 7474 2260238 910030 244799121 0 0 41w2d 20649
203.13.132.51 4 7474 2296993 910146 244799121 0 0 41w2d 20649
203.13.132.53 4 7474 59909540 910088 244799121 0 0 41w2d 538696
203.202.143.3 4 7474 0 0 1 0 0 never Idle (Admin)
203.202.143.33 4 7474 34662511 910049 244799121 0 0 41w2d 539054
203.202.143.34 4 7474 33523616 910040 244799121 0 0 41w2d 539065
This router has over 500.000 networks and knows about more than 2.000.000 paths for these networks. It is
connected to 14 neighbors (2 are down) and here’s what the BGP table looks like:
route-views.optus.net.au>show ip bgp

* 1.0.0.0/24 203.13.132.47 0 7474 15169 i
* 203.13.132.37 0 7474 15169 i
* 192.65.89.161 1 0 7474 15169 i
* 203.202.143.34 0 7474 15169 i
*> 203.202.143.33 0 7474 15169 i
* 203.13.132.49 0 7474 15169 i
* 202.139.124.130 1 0 7474 15169 i
* 203.13.132.51 0 7474 15169 i
* 203.13.132.53 0 7474 15169 i
* 203.13.132.41 0 7474 15169 i
* 203.13.132.35 0 7474 15169 i
* 203.13.132.29 0 7474 15169 i
* 1.0.4.0/24 203.13.132.47 10 0 7474 4826 56203 i
* 203.13.132.37 10 0 7474 4826 56203 i
* 203.202.143.34 0 7474 4826 56203 i
*> 203.202.143.33 0 7474 4826 56203 i
* 203.13.132.49 10 0 7474 4826 56203 i
* 192.65.89.161 1 0 7474 4826 56203 i
* 203.13.132.51 1 0 7474 4826 56203 i
* 202.139.124.130 1 0 7474 4826 56203 i
Page 45 of 283
* 203.13.132.53 1 0 7474 4826 56203 i
* 203.13.132.41 1 0 7474 4826 56203 i
* 203.13.132.35 1 0 7474 4826 56203 i
* 203.13.132.29 1 0 7474 4826 56203 i
You can keep pressing enter, this BGP table is very long. I’m only showing the first two networks. As you can
see this router has network 1.0.0.0/24 in its BGP table and knows about 12 different paths to get there. It
decided to use 203.202.143.33 as the next hop.
It also learned about network 1.0.4.0/24 and is using 203.202.143.33 as the next hop.
This router probably knows about a couple of networks with issues, a fun way to find these is by searching in
the BGP table and excluding everything that starts with a *. This removes all the valid networks from the BGP
table:
route-views.optus.net.au>show ip bgp | exclude *


d 2.93.235.0/24 203.202.143.33 0 7474 7473 3549 701 703 702
3216 8402 ?
d 203.202.143.34 0 7474 7473 3549 701 703 702
3216 8402 ?
d 203.13.132.35 1 0 7474 7473 3549 701 703 702
3216 8402 ?
d 203.13.132.53 1 0 7474 7473 3549 701 703 702
3216 8402 ?
h 203.13.132.53 1 0 7474 7473 1299 6453 4755
45820 45117 i
h 203.13.132.35 1 0 7474 7473 1299 6453 4755
45820 45117 i
h 31.131.7.0/24 203.202.143.33 0 7474 7473 1299 46786 5577 i
h 203.202.143.34 0 7474 7473 1299 46786 5577 i
h 203.13.132.53 1 0 7474 7473 1299 46786 5577 i
h 203.13.132.35 1 0 7474 7473 1299 46786 5577 i
I’m using the exclude command to filter every line that has a * in it. I have to use the symbol in front of it since
the * is a wildcard for regular expressions.
Above you can see two networks with issues. The first one (2.93.235.0/24) has a d in front of it which means
it’s dampened. The second network 31.131.7.0/24 has a h in front of it that indicates that it’s a history entry.
That’s all I have for now about the BGP table, I hope this has been useful to understand how to read it. It might
be a fun idea to play with one of the looking glass servers yourself!
How to advertise networks in BGP

In this lesson we’ll take a look how you can advertise networks in BGP. There are two methods how we can do
this:
Page 46 of 283
 Network command
 Redistribution
Just like our IGPs we can use the network command to advertise something or we can redistribute networks into
BGP. There’s one big difference though, the network command for BGP behaves differently.
When you use any of the IGPs (RIP, OSPF or EIGRP) then the network command is used to activate the IGP on
all interfaces that fall within the range of the network command.
BGP doesn’t care about interfaces, it doesn’t even look at them. When we use the network command in BGP
then BGP will only look at the routing table. When it finds the network that matches the network command, it
will install it in the BGP table.
Let me show you some examples to explain what I’m talking about. We will use the following two routers:
R1 and R2 are in different autonomous systems so we use eBGP. Here is the BGP configuration:
R1#show running-config | section bgp

router bgp 1
router bgp 2
Nothing special here, just plain eBGP between R1 and R2. Let’s advertise some networks in BGP…
Network Command
Let’s create a loopback interface with a network and advertise it in BGP:
Above we have created a loopback interface with network 1.1.1.0 /24, this is what we will advertise in BGP.
Since we created a loopback interface, this network will be directly connected for R1:

Routing entry for 1.1.1.0/24
Page 47 of 283
Known via "connected", distance 0, metric 0 (connected, via interface)
Advertised by bgp 1
Routing Descriptor Blocks:
* directly connected, via Loopback1
Route metric is 0, traffic share count is 1
Since it’s in the routing table, BGP will be able to install this network in the BGP table:
R1#show ip bgp
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-
Filter

*> 1.1.1.0/24 0.0.0.0 0 32768 i
Since R1 has it in its BGP table it will be able to advertise it to R2:

Paths: (1 available, best #1, table default)
Not advertised to any peer
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Origin IGP, metric 0, localpref 100, valid, external, best
That’s all there is to it. Just use the network command to put the networks you want in the BGP table. One thing
you have to be aware of is that you have to use the exact network and subnet mask for the network
command. Let me give you an example:
I created a loopback interface with network 11.11.11.11 /32. BGP uses the network command to advertise
11.11.11.0 /24. This network will never be placed in the BGP table since the subnet mask doesn’t match:
R1#show ip bgp 11.11.11.11

Be aware of this. Make sure you type the exact network address and subnet mask when advertising something
in BGP. Let’s fix this:
R1(config-router)#no network 11.11.11.0 mask 255.255.255.0
With the correct network command, BGP will be able to advertise this network in the BGP table:
R1#show ip bgp 11.11.11.11

Page 48 of 283
1
Local
0.0.0.0 from 0.0.0.0 (192.168.12.1)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
And because R1 has it in its BGP table, R2 will be able to learn it:
R2#show ip bgp | begin Network

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 11.11.11.11/32 192.168.12.1 0 0 1 i
Alright so far so good. What if we want to advertise a network that we don’t have? Let’s say that I want to
advertise network 1.0.0.0 /8 in BGP. We won’t be able to advertise this network in BGP if it’s not in the routing
table. To achieve this, we’ll put this network in our routing table:[teaser]
R1(config)#ip route 1.0.0.0 255.0.0.0 null 0
This can be done with a static route that points to the null interface, everything you send to the null interface
will be discarded. Using a static route like this is also called a discard route.
Network 1.0.0.0 /8 is now in the routing table:

Routing entry for 1.0.0.0/8, 3 known subnets
Attached (3 connections)
Variably subnetted with 3 masks
S 1.0.0.0/8 is directly connected, Null0
C 1.1.1.0/24 is directly connected, Loopback1
L 1.1.1.1/32 is directly connected, Loopback1
This allows BGP to advertise it:
Take a look at the BGP table of R1 and R2:

1
Local
0.0.0.0 from 0.0.0.0 (192.168.12.1)
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Page 49 of 283
R1 was able to install network 1.0.0.0 /8 in its BGP table and advertises it to R2.
Redistribution
Instead of using the network command we can also redistribute something into BGP. To demonstrate this I will
create a new loopback interface, advertise it in OSPF and then redistribute it into BGP:
R1(config-if)#exit
R1(config-router)#redistribute ospf 1
I created a loopback with network 111.111.111.0 /24, advertised it in OSPF and redistributed it into BGP. Let’s
check the BGP table:

*> 1.0.0.0 0.0.0.0 0 32768 i
*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 11.11.11.11/32 0.0.0.0 0 32768 i
*> 111.111.111.0/24 0.0.0.0 0 32768 ?
*> 1.0.0.0 192.168.12.1 0 0 1 i
*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 11.11.11.11/32 192.168.12.1 0 0 1 i
*> 111.111.111.0/24 192.168.12.1 0 0 1 ?
There we go, R1 placed the network in its BGP table and was able to advertise it to R2.
I hope this lesson has been useful to understand how to advertise something in BGP, if you have any question
feel free to leave a comment!
BGP Next Hop Self

One potential issue with iBGP is that it doesn’t change the next hop IP address. Sometimes this can cause
reachability issues. Let’s look at an example:
Page 50 of 283
Above we have R1 and R2 in AS 12 running iBGP. R3 is in AS 3 and we use eBGP between R2 and R3. Once
we advertise network 3.3.3.0 /24 on R3 in BGP then R2 will learn this prefix and stores it in its BGP table, the
next hop IP adress will be 192.168.23.3.
Once R1 learns about prefix 3.3.3.0 /24 then the next hop IP address will remain 192.168.23.3. When R1
doesn’t know how to reach this IP address then it will fail to install 3.3.3.0 /24 in its routing table.
Let’s take a look at the configuration, I’ll show you two methods how we can deal with this issue.
Configuration
Here’s the BGP configuraton that we will use:
The configuration is pretty straight forward. We use iBGP between R1/R2 and eBGP between R2/R3. On R3
we advertised 3.3.3.0 /24 in BGP. Let’s take a look at the BGP tables:
R2#show ip bgp

*> 3.3.3.0/24 192.168.23.3 0 0 3 i
R2 has installed 3.3.3.0 /24 in its BGP table and it is a valid route, the next hop is 192.168.23.3. Let’s check R1:
R1#show ip bgp
Page 51 of 283

* i3.3.3.0/24 192.168.23.3 0 100 0 3 i
R1 learns the prefix but it’s unable to install it in the routing table:
The problem here is that the next hop IP address is 192.168.23.3. Does R1 have any clue how to reach this
address?
R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
R1 doesn’t know so it’s impossible to install 3.3.3.0 /24 in the routing table. How can we fix this? I’ll show you
two different methods.
Advertise Network
The first solution is simple, we can advertise the network in iBGP (or an IGP if you use one) so that R1 is able
to reach the next hop. Let’s advertise 192.168.23.0 /24 in BGP:
Now take a look at R1:
R1#show ip bgp

*>i3.3.3.0/24 192.168.23.3 0 100 0 3 i
*>i192.168.23.0 192.168.12.2 0 100 0 i
R1 learns about 192.168.23.0 /24 so now it knows how to reach the next hop for 3.3.3.0 /24. It can now install
this network in the routing table:
Page 52 of 283
B 3.3.3.0 [200/0] via 192.168.23.3, 00:16:20
B 192.168.23.0/24 [200/0] via 192.168.12.2, 00:16:25
hostname R1
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 12
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.1 255.255.255.0
!
router bgp 12
network 192.168.23.0 mask 255.255.255.0
!
end
hostname R3
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 3
network 3.3.3.0 mask 255.255.255.0
!
end
This will work but there is another solution that is easier. Let’s clean up before we continue:
R2(config-router)#no network 192.168.23.0 mask 255.255.255.0
Now we can try something else…[teaser]
Next Hop Self
Instead of advertising the network in between R2 and R3 we can configure R2 so that it will change the next
hop IP address to it’s own address:
Page 53 of 283
From now on, when R2 advertises something to R1 then it will include it’s own IP address as the next hop.
Let’s verify this:
R1#show ip bgp

*>i3.3.3.0/24 192.168.12.2 0 100 0 3 i
Above you can see that R1 learns 3.3.3.0 /24 with 192.168.12.2 as the next hop. Since this is directly connected,
we can use this information:

B 3.3.3.0 [200/0] via 192.168.12.2, 00:00:33
R1 has installed it in its routing table, problem solved!
hostname R1
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 12
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.1 255.255.255.0
!
router bgp 12
!
end
hostname R3
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 3
network 3.3.3.0 mask 255.255.255.0
!
end
Page 54 of 283
BGP Auto-Summary
In a previous lesson I explained how the BGP network command works. When we enable auto-summary for
BGP, the way the network command works changes slightly.
Normally when you advertise a network in BGP you have to type in the exact network and subnet mask that
you want to advertise or it won’t be placed in the BGP table.
With auto-summary enabled, you can advertise a classful network and you don’t have to add the mask
parameter. BGP will automatically advertise the classful network if you have the classful network or a subnet
of this network in your routing table. Let me give you an example to explain what I’m talking about. I’ll use
these two routers:
These routers are configured for eBGP, there’s a loopback interface on R1 with network 1.1.1.1 /32. Here’s the
configuration:
R1#show run | section bgp

router bgp 1
router bgp 2
The configuration is straight-forward, we only configured eBGP, no networks have been advertised and auto-
summary is disabled. Let’s see if we can advertise classful network 1.0.0.0/8:
R1(config-router)#network 1.0.0.0
Note that I didn’t specify a subnet mask with the mask parameter. Take a look at the BGP table now:

As expected there is nothing in the BGP table since we require the exact network and subnet mask. Let’s enable
auto-summary now so you can see the difference:
R1(config-router)#auto-summary
Page 55 of 283
After enabling auto-summary things will change. Take a look at the BGP table of R1:[teaser]

1
Local
0.0.0.0 from 0.0.0.0 (192.168.12.1)
R1 now has an entry for classful network 1.0.0.0/8. It was able to install this in its BGP table because auto-
summary is enabled and we have 1.1.1.1/32 in our routing table. This network will also be advertised to R2:
R2#show ip bgp
Filter

*> 1.0.0.0 192.168.12.1 0 0 1 i
That’s all there is to it.
hostname R1
!
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.0.0.0
auto-summary
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
!
end
BGP Neighbor Adjacency States
Page 56 of 283
Just like OSPF or EIGRP, BGP establishes a neighbor adjacency with other BGP routers before they exchange
any routing information. Unlike other routing protocols however, BGP does not use broadcast or multicast to
“discover” other BGP neighbors.
Neighbors have to be configured manually and BGP uses TCP port 179 for the connection.
In this lesson we’ll take a close look at the different “states” when two BGP routers try to become neighbors.
Here they are:
1. Idle:This is the first state where BGP waits for a “start event”. The start event occurs when someone
configures a new BGP neighbor or when we reset an established BGP peering. After the start event,
BGP will initialize some resources, resets a ConnectRetry timer and initiates a TCP connection to the
remote BGP neighbor. It will also start listening for a connection in case the remote BGP neighbor tries
to establish a connection. When successful, BGP moves to the Connect state. When it fails, it will
remain in the Idle state.
2. Connect: BGP is waiting for the TCP three-way handshake to complete. When it is successful, it will
continue to the OpenSent state. In case it fails, we continue to the Active state. If the ConnectRetry timer
expires then we will remain in this state. The ConnectRetry timer will be reset and BGP will try a new
TCP three-way handshake. If anything else happens (for example resetting BGP) then we move back to
the Idle state.
3. Active: BGP will try another TCP three-way handshake to establish a connection with the remote BGP
neighbor. If it is successful, it will move to the OpenSent state. If the ConnectRetry timer expires then
we move back to the Connect state. BGP will also keep listening for incoming connections in case the
remote BGP neighbor tries to establish a connection. Other events can cause the router to go back to the
Idle state (resetting BGP for example).
4. OpenSent: In this state BGP will be waiting for an Open message from the remote BGP neighbor. The
Open message will be checked for errors, if something is wrong (incorrect version numbers, wrong AS
number, etc.) then BGP will respond with a Notification message and jumps back to the Idle state. This
is also the moment where BGP decides whether we use EBGP or IBGP (since we check the AS
number). If everything is OK then BGP starts sending keepalive messages and resets its keepalive timer.
At this moment, the hold time is negotiated (lowest value is picked) between the two BGP routers. In
case the TCP session fails, BGP will jump back to the Active state. When any other errors occur
(expiration of hold timer), BGP will send a notification message with the error code and jumps back to
the Idle state. In case someone resets the BGP process, we also jump back to the Idle state.
5. OpenConfirm: BGP waits for a keepalive message from the remote BGP neighbor. When we receive
the keepalive, we can move to the established state and the neighbor adjacency will be completed. When
this occurs, it will reset the hold timer. If we receive a notification message from the remote BGP
neighbor then we fall back to the Idle state. BGP will keep sending keepalive messages.
6. Established: The BGP neighbor adjacency is complete and the BGP routers will send update packets to
exchange routing information. Every time we receive a keepalive or update message, the hold timer will
be resetted. In case we receive a notification message we will jump back to the Idle state.
This whole process of becoming BGP neighbors can be visualized, this might be a bit easier then just reading
about it. The official name of a “diagram” that shows the different states and we can move from one state to
another is called a FSM (Finite State Machine). For BGP, it looks like this:
Page 57 of 283
Now you know about the different states, let’s take a look at some Cisco BGP routers to see what it actually
looks like on two routers. I’ll use the following topology for this:
Just two routers in two different autonomous systems. Before I configure BGP, let’s enable a debug:
[teaser]
R1, R2 #debug ip bgp

BGP debugging is on for address family: IPv4 Unicast
This will give us everything…
As soon as I do this you will see some debugging;
R1#
BGP: 192.168.12.2 active went from Idle to Active
BGP: 192.168.12.2 open active, local address 192.168.12.1
BGP: 192.168.12.2 open failed: Connection refused by remote host
Page 58 of 283
BGP: 192.168.12.2 Active open failed - tcb is not available, open active delayed 9216ms
(35000ms max, 60% jitter)
BGP: ses global 192.168.12.2 (0x4B43F3FC:0) act Reset (Active open failed).
BGP: 192.168.12.2 active went from Active to Idle
BGP: nbr global 192.168.12.2 Active open failed - open timer running
As soon as I configure BGP on R1 it will try to connect to R2. You can see the debug says that the state moves
from Idle to Active (it doesn’t show the Connect state in the debug). When it fails, it falls back to the Idle state.
Now let’s configure BGP on R2 as well so we can see a successful progress through the states:
Now look at the debug on R1:
R1#
BGP: 192.168.12.2 active went from Idle to Active
BGP: ses global 192.168.12.2 (0x4B43F3FC:0) act Adding topology IPv4 Unicast:base
BGP: ses global 192.168.12.2 (0x4B43F3FC:0) act Send OPEN
BGP: 192.168.12.2 active went from Active to OpenSent
BGP: 192.168.12.2 active sending OPEN, version 4, my as: 1, holdtime 180 seconds, ID
C0A80C01
BGP: 192.168.12.2 active rcv message type 1, length (excl. header) 34
BGP: ses global 192.168.12.2 (0x4B43F3FC:0) act Receive OPEN
BGP: 192.168.12.2 active rcv OPEN, version 4, holdtime 180 seconds
BGP: 192.168.12.2 active rcv OPEN w/ OPTION parameter len: 24
BGP: 192.168.12.2 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 192.168.12.2 active OPEN has CAPABILITY code: 1, length 4
BGP: 192.168.12.2 active OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 192.168.12.2 active OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 192.168.12.2 active OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 192.168.12.2 active OPEN has 4-byte ASN CAP for: 2
BGP: nbr global 192.168.12.2 neighbor does not have IPv4 MDT topology activated
BGP: 192.168.12.2 active rcvd OPEN w/ remote AS 2, 4-byte remote AS 2
BGP: 192.168.12.2 active went from OpenSent to OpenConfirm
BGP: 192.168.12.2 active went from OpenConfirm to Established
BGP: ses global 192.168.12.2 (0x4B43F3FC:1) act Assigned ID
BGP: ses global 192.168.12.2 (0x4B43F3FC:1) Up
Above you can see that the BGP state moves from Idle to Active and then to OpenSent. Some Open messages
are sent and received, the BGP routers are exchanging some of their capabilities. From there we move to the
OpenConfirm and Established state. Finally you see the BGP neighbor as up. On R2 we see something similar:
R2#
BGP: 192.168.12.1 passive open to 192.168.12.2
BGP: 192.168.12.1 passive went from Idle to Connect
BGP: ses global 192.168.12.1 (0x4B269374:0) pas Setting open delay timer to 60 seconds.
BGP: ses global 192.168.12.1 (0x4B269374:0) pas read request no-op
BGP: 192.168.12.1 passive rcv message type 1, length (excl. header) 34
Page 59 of 283
BGP: ses global 192.168.12.1 (0x4B269374:0) pas Receive OPEN
BGP: 192.168.12.1 passive rcv OPEN, version 4, holdtime 180 seconds
BGP: 192.168.12.1 passive rcv OPEN w/ OPTION parameter len: 24
BGP: 192.168.12.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 192.168.12.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 192.168.12.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 192.168.12.1 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 192.168.12.1 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 192.168.12.1 passive OPEN has 4-byte ASN CAP for: 1
BGP: nbr global 192.168.12.1 neighbor does not have IPv4 MDT topology activated
BGP: 192.168.12.1 passive rcvd OPEN w/ remote AS 1, 4-byte remote AS 1
BGP: ses global 192.168.12.1 (0x4B269374:0) pas Adding topology IPv4 Unicast:base
BGP: ses global 192.168.12.1 (0x4B269374:0) pas Send OPEN
BGP: 192.168.12.1 passive went from Connect to OpenSent
BGP: 192.168.12.1 passive sending OPEN, version 4, my as: 2, holdtime 180 seconds, ID
C0A80C02
BGP: 192.168.12.1 passive went from OpenSent to OpenConfirm
BGP: 192.168.12.1 passive went from OpenConfirm to Established
BGP: ses global 192.168.12.1 (0x4B269374:1) pas Assigned ID
BGP: nbr global 192.168.12.1 Stop Active Open timer as all topologies are allocated
BGP: ses global 192.168.12.1 (0x4B269374:1) Up
The output of these debug messages are nice and easy to read. If for some reason your neighbor adjacency
doesn’t appear, these debugs can be helpful to solve the problem.
hostname R1
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
!
end
BGP Messages
Page 60 of 283
BGP uses a variety of messages for establishing the connection, exchanging routing information, checking if the
remote BGP neighbor is still there and/or notifying the remote side if any errors occur.
To do all of this, BGP uses 4 messages:
 Open Message
 Update Message
 Keepalive Message
 Notification Message
All of these BGP messages use a fixed-size header, it includes a type field that indicates what type of message it
is.
To explain these BGP messages I will show you some Wireshark captures. I will use the following topology for
this:
Open Message
Once two BGP routers have completed a TCP 3-way handshake they will attempt to establish a BGP session,
this is done using open messages. In the open message you will find some information about the BGP router,
these have to be negotiated and accepted by both routers before we can exchange any routing information. Here
are some of the items you will find in the open message:
 Version: this includes the BGP version that the router is using. The current version of BGP is version 4
which is described in RFC 4271. Two BGP routers will try to negotiate a compatible version, when
there is a mismatch then there will be no BGP session.
 My AS: this includes the AS number of the BGP router, the routers will have to agree on the AS
number(s) and it also defines if they will be running iBGP or eBGP.
 Hold Time: if BGP doesn’t receive any keepalive or update messages from the other side for the
duration of the hold time then it will declare the other side ‘dead’ and it will tear down the BGP session.
By default the hold time is set to 180 seconds on Cisco IOS routers, the keepalive message is sent every
60 seconds. BGP routers will use the lowest configured hold down timer.
 BGP Identifier: this is the local BGP router ID which is elected just like OSPF does:
o Use the router-ID that was configured manually with the bgp router-id command.
o Use the highest IP address on a loopback interface.
o Use the highest IP address on a physical interface.
 Optional Parameters: here you will find some optional capabilities of the BGP router. This field has
been added so that new features could be added to BGP without having to create a new version.Things
you might find here are:
Page 61 of 283
o support for MP-BGP (Multi Protocol BGP).
o support for Route Refresh.
o support for 4-octet AS numbers.
Here’s an example of a wireshark capture of an open message between R1 and R2:
Above you can see the open message from R1 to R2. You can see the things that we discussed, the BGP
version, AS number, hold time, BGP ID and the optional parameters (MP-BGP and route refresh). The marker
field on top is used to indicate if we use MD5 authentication or not. When it’s filled with 1’s then we are not
using authentication.
Update Message
Once two routers have become BGP neighbors, they can start exchanging routing information. This is done with
the update message. In the update message you will find information about the prefixes that are advertised.In
“BGP language” a prefix is referred to as NLRI (Network Layer Reachability Information). Here are some
of the things you will find in an update message:
 Withdrawn Route Length: this field shows the length of the Withdrawn Routes field in bytes. When it is
set to 0, there are no routes withdrawn and the Withdrawn Routes field will not show up.
 Withdrawn Routes: this field shows all the prefixes that should be removed from the BGP table.
 Total Path Attribute Length: here you will find the total length of the Path Attributes field.
 Path Attributes: the BGP attributes for the prefix are stored here, for example: origin, as_path, next_hop,
med, local preference, etc. These path attributes are stored in TLV-format (Type, Length, Value).
Each of the BGP attributes also has an attribute flag that tells the BGP router how to treat the attribute. Here
are the different bit flags:
Page 62 of 283
 Optional: when the attribute is well-known this bit is set to 0, when its optional it is set to 1.
 Transitive: when an optional attribute is non-transitive this bit is set to 0, when it is transitive it is set to
1.
 Partial: when an optional attribute is complete this bit is set to 0, when it’s partial it is set to 1.
 Extended Length: when the attribute length is 1 octet it is set to 0, for 2 octets it is set to 1. This
extended length flag may only be used if the length of the attribute value is greater than 255 octets.
Let’s take a look at an update message from R1:
Here’s the capture:
Above you can see a update message from R1. No routes are withdrawn and there are a couple of BGP
attributes. You can see the ORIGIN, AS_PATH and MULTI_EXIT_DISC (MED). I also highlighted some of
Page 63 of 283
the flags. The AS_PATH attribute is transitive while MULTI_EXIT_DISC is optional. At the bottom you can
find the NLRI information with our prefix.
Let’s remove the network command for the loopback interface on R1 so that we can see a withdrawn in the
update message:
R1(config-if)#shutdown
Here’s the capture:[teaser]
Here you can see the withdrawn routes length which is 5 bytes. In the Withdrawn Routes field we see our
1.1.1.1 /32 prefix that should be removed.
Keepalive Message
When there are no routes to be advertised or withdrawn, there’s not much our BGP neighbors have to share with
each other. To make sure the other side is “still there” we use these periodic keepalive messages. By default,
BGP sends 19 byte long keepalive messages every 60 seconds. When a remote BGP neighbor misses three
keepalives (3 x 60 = 180 seconds, the value of the hold time) it will flush the routes from the BGP neighbor.
Here’s a capture of a keepalive message:
The keepalive message is really simple, it’s just a basic header with the length (19 bytes) and the type.
Notification Message
Page 64 of 283
The notification message is used when an error occurs which will result in termination of the BGP neighbor
adjacency. When something goes wrong, the notification message will be sent and the session will be
terminated.
The TCP session will be cleared, all entries from this BGP neighbor will be removed from the BGP table and
update messages with route withdrawals will be sent to other BGP neighbors.
There is a list with BGP error codes and each error code has a sub-type. Here are some examples:
 Message header error

 Open message error
 Update message error
For each of those there is a subtype that explains the exact error. For example for the open message here are
some of the subtypes:
 Unsupported version number

 Bad peer AS
 Bad BGP identifier
 Unsupported optional parameter
 Unacceptable hold time
The list with all error codes and their subtypes is quite large. If you want to see all of them, take a look at this
list from IANA.
Let me show you an example of a notification message, we’ll do something that BGP doesn’t like:
R2(config)#no router bgp 2

By changing the AS number on one of the routers we will have a mismatch. Here’s the wireshark capture:
R1 is sending R2 a notification message with a major error “open message error” and the minor error code
(subtype) is bad peer AS.
Wireshark Capture eBGP Neighbor Adjacency
Page 65 of 283
These are the messages that BGP uses, I hope this lesson has been useful to you…if you have any questions,
just leave a comment!
Troubleshooting BGP Neighbor Adjacency

BGP is a complex routing protocol and there are quite some things that could go possibly wrong. Besides being
complex it’s also completely different compared to our IGPs (OSPF and EIGRP). In this lesson we’ll start with
troubleshooting BGP neighbor adjacencies. Once the neighbor adjacency is working, you can focus on
troubleshooting missing route advertisements.
Key to troubleshooting BGP is understanding how BGP forms a neighbor adjacency. If you are unsure how this
process works exactly you might want to check my lesson about BGP states first before you continue. Having
said that, let’s look at some scenarios.
BGP Interface Issues

Here’s the first topology:
Two BGP routers which are connected and configured for EBGP. Unfortunately we are seeing this when check
the BGP neighbor adjacency:


192.168.12.2 4 2 8 8 0 0 0 00:00:06 Active

192.168.12.1 4 1 8 8 0 0 0 00:00:59 Active
When two EBGP routers that are directly connected do not form a working BGP neighbor adjacency there
could be a number of things that are wrong:
 Layer 2 down preventing us from reaching the other side.

 Layer 3 issue: wrong IP address on one of the routers.
 Access-list blocking TCP port 179 (BGP).
 Wrong IP address configured for BGP neighbor router.
Page 66 of 283
The IP addresses that were used for the neighbor adjacency look OK so something else might be the issue. Let’s
try a quick ping:
R1#ping 192.168.12.2

.....
I can do a quick ping and I’ll see that I’m unable to reach the other side. Since layer 3 isn’t working, let’s take a
look at layer 1 and 2:
R1#show ip int brief

FastEthernet0/0 192.168.12.1 YES manual up up
R2#show ip int brief
FastEthernet0/0 192.168.12.2 YES manual administratively down down
We’ll check the interfaces and find out that someone left a shutdown command on the interface…let’s fix it:
R2(config)#interface FastEthernet 0/0

R2(config-if)#no shutdown
After enabling the interface you should see this:

That’s what we like to see. Our BGP neighbor adjacency is established…
Lesson learned: Make sure your interfaces are up and running.
EBGP Requirements
Same topology but another issue. The goal in this scenario is to establish the EBGP neighbor adjacency between
the IP addresses on the loopback interfaces.
Let me show you what the BGP configuration looks like:

router bgp 1
no synchronization
Page 67 of 283
no auto-summary
router bgp 2
no synchronization
no auto-summary
Here’s the BGP configuration, you can see that we are using the loopback interfaces to establish a BGP
neighbor adjacency. There’s no BGP neighbor adjacency:


2.2.2.2 4 2 0 0 0 0 0 never Idle

1.1.1.1 4 1 0 0 0 0 0 never Idle
Both routers show their BGP neighbor as idle. There are a number of things we have to check here:
 Is the IP address of the BGP neighbor reachable? We are not using the directly connected links so we
might have routing issues.
 The TTL of IP packets that we use for external BGP is 1. This works for directly connected networks
but if it’s not directly connected we need to change this behavior.
 By default BGP will source its updates from the IP address that is closest to the BGP neighbor. In our
example that’s the FastEthernet interface. This is something we’ll have to change.
Let’s check if the IP address of the remote neighbor is reachable, take a look at the routing tables:
R1#show ip route

R2#show ip route
Both routers only know about their directly connected networks. In order to reach each other’s loopback
interfaces we’ll use static routing:
R1(config)#ip route 2.2.2.2 255.255.255.255 192.168.12.2

R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
Two static routes should do the job. Let’s give it a try:
R1#ping 2.2.2.2 source loopback 0
Page 68 of 283
!!!!!
Sending a ping to IP address 2.2.2.2 and sourcing it from my own loopback interface proves that both routers
know how to reach each other’s loopback interface. Since we don’t use the directly connected interfaces for the
peering, we also have to increase the TTL:

The ebgp-multihop command changes the TTL to 2. Now take a look at a debug:
R2#debug ip bgp
BGPNSF state: 1.1.1.1 went from nsf_not_active to nsf_not_active

BGP: 1.1.1.1 went from Active to Idle
BGP: 1.1.1.1 went from Idle to Active
BGP: 1.1.1.1 open active delayed 31810ms (35000ms max, 28% jitter)
BGP: 1.1.1.1 open failed: Connection refused by remote host, open active delayed 34480ms
We can enable a debug to see the progress. You can clearly see that R2 is using IP address 192.168.12.2 and
that R1 is refusing the connection. This is because we use the wrong source IP address. We have to tell BGP to
use another IP address:

Use the update-source command to change the source IP address for the BGP updates. After making these
changes, the problem should be fixed:
R1#
R2#
There goes! A working BGP neighbor adjacency.
Lesson learned: BGP routers don’t have to establish a neighbor adjacency using the directly connected
interfaces. Make sure the BGP routers can reach each other, that BGP packets are sourced from the
correct interface and in case of EBGP don’t forget to use the multihop command.
BGP TCP Port Filtering

Let’s take a look at an IBGP issue:
Page 69 of 283
Two routers in the same AS and here’s the configuration:

router bgp 1
no synchronization
no auto-summary
router bgp 1
no synchronization
no auto-summary
Plain and simple. The routers use the directly connected IP addresses for the BGP neighbor adjacency. Let’see
if we have neighbors:[teaser]


192.168.12.2 4 1 46 46 0 0 0 00:05:24 Active

192.168.12.1 4 1 46 46 0 0 0 00:05:30 Active
Too bad…we are not becoming neighbors. What could possibly be wrong? We are using the directly connected
interfaces so there’s not that much that could go wrong except for L2/L2 issues. Let’s try a simple ping:
R1#ping 192.168.12.2

!!!!!
Sending a ping from one router to the other proves that L2 and L3 are working fine. What about L4? We could
have issues with the transport layer. Let’s give it a try:
R1#telnet 192.168.12.2 179

Trying 192.168.12.2, 179 ...
% Destination unreachable; gateway or host down
Page 70 of 283
R2#telnet 192.168.12.1 179
Trying 192.168.12.1, 179 ...
I’m unable to connect to TCP port 179 from both routers. This should ring a bell, maybe something is blocking
BGP ?
R1#show ip interface fastEthernet 0/0 | include access

Outgoing access list is not set
Inbound access list is not set
R2#show ip interface fastEthernet 0/0 | include access
Outgoing access list is not set
Inbound access list is 100
Dang! It’s the security team…let’s take a closer look:
R2#show ip access-lists
Extended IP access list 100
10 deny tcp any eq bgp any (293 matches)
15 deny tcp any any eq bgp (153 matches)
20 permit ip any any (109 matches)
Someone decided it was a good idea to “secure” BGP and block it with an access-list. Let’s get rid of it:
R2(config)#interface fastEthernet 0/0

R2(config-if)#no ip access-group 100 in
Once I do this, everything is working again:

That’s what we are looking for!
Lesson learned: Don’t block BGP TCP port 179.
IBGP Update Source
Next IBGP issue. This one is similar to the EBGP situation I showed you before…we are using the loopback
interfaces to establish the BGP neighbor adjacency, here are the configurations:
R1#show run | section router bgp

router bgp 1
no synchronization
Page 71 of 283
no auto-summary
router bgp 1
no synchronization
no auto-summary
Nothing special, IBGP and we are using the loopback interfaces for the neighbor adjacency. There are no
neighbors though:
R1#show ip bgp summary | begin Neighbor

2.2.2.2 4 1 0 0 0 0 0 never Active
1.1.1.1 4 1 0 0 0 0 0 never Active
No luck here…no neighbors.
Let’s first check if the routers can reach each other’s loopback interfaces:
R1#show ip route

R2#show ip route

A quick look at the routing table shows us that this is not the case. We could fix this with a static route or an
IGP. Normally we use an IGP for IBGP to advertise the loopback interfaces, let’s use OSPF:
Smashing in the correct OSPF commands should do the job! Let’s try a quick ping:
R1#ping 2.2.2.2 source loopback 0

!!!!!
Reachability is no issue anymore. So do we have neighbors now?
Page 72 of 283
2.2.2.2 4 1 0 0 0 0 0 never Active
1.1.1.1 4 1 0 0 0 0 0 never Active
Still no BGP neighbor adjacency though…let’s try a debug:
R1#debug ip bgp
R2#debug ip bgp
A debug shows up that the connection is refused and it also shows us the local IP address that is used for BGP.
Seems someone forgot to add the update-source command so let’s fix it!
Just like EBGP we have to set the correct source for our BGP packets. After a few seconds you’ll see this:
R1# BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

R2# BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
Problem solved! The only difference with EBGP is that we don’t have to change the TTL with the ebgp-
multihop command.
Lesson learned: Its common practice to configure IBGP between loopback interfaces. Make sure these
loopbacks are reachable and that the BGP updates are sourced from the loopback interface.
These are the most common issues why BGP doesn’t form a neighbor adjacency. The routers are now up and
running so we can continue to troubleshoot (missing) route advertisements.
Troubleshooting BGP Route Advertisement

Once your BGP neighbor adjacency is up and running then you can try to troubleshoot issues with route
advertisements. In a previous lesson I explained how to fix BGP neighbor adjacencies, this time we’ll focus on
route advertisements. Let’s look at some examples!
BGP Network Command

Let’s start with an EBGP scenario:
Page 73 of 283
R1 and R2 are in different autonomous systems. We are trying to advertise network 1.1.1.0 /24 from R1 to R2
but it’s not showing up on R2. Here are the configurations:

no synchronization
network 1.1.1.0
no auto-summary
router bgp 2
no synchronization
no auto-summary
At first sight there seems to be nothing wrong here. Let’s see if R2 learned anything:


192.168.12.1 4 1 4 4 1 0 0 00:01:26 0
However R2 didn’t learn any prefixes from R1. Perhaps we have a filter?
R1#show ip protocols | include filter

Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maybe there’s a distribute-list but that’s not the case here. Let’s check the network commands on R1:

router bgp 1
no synchronization
network 1.1.1.0
no auto-summary
The problem is the network command, it works differently for BGP vs our IGPs. If we configure a network
command for BGP it has to be an exact match. In this case I forgot to add the subnet mask…let’s fix it:
Page 74 of 283
I have to make sure I type the correct subnet mask. Now check R2 again:

192.168.12.1 4 1 9 8 2 0 0 00:05:15 1
B 1.1.1.0 [20/0] via 192.168.12.1, 00:01:08
Now you can see we learned the prefix and R2 installs it in the routing table…problem solved!
Lesson learned: Type in the exact correct subnet mask…BGP is picky!
BGP Summarization
Let’s move onto the next scenario.
The network engineer from AS1 wants to advertise a summary to AS 2. The network engineer from AS 2 is
complaining however that he’s not receiving anything…let’s find out what is going wrong! Here are the
configurations:

router bgp 1
no synchronization
aggregate-address 172.16.0.0 255.255.0.0
no auto-summary
router bgp 2
no synchronization
no auto-summary
You can see the aggregate-address command on R1 for network 172.16.0.0 /16. Did R2 receive anything?

192.168.12.1 4 1 21 19 3 0 0 00:16:21 0
Page 75 of 283
Too bad…no prefixes have been received by R2. There are two things I could check here:
 See if a distribute-list is blocking prefixes inbound like I did in the previous example.
 See what R1 has in its routing table (can’t advertise what I don’t have!).
Let’s start with the routing table of R1 since I think by now you know what a distribute-list looks like..
R1#show ip route

There’s nothing here that looks even close to 172.16.0.0 /16. If we want to advertise a summary we have to put
something in the routing table of R1 first. Let me show you the different options:
R1(config-if)#exit
This is option 1: I’ll create a loopback interface and configure an IP address that falls within the range of the
aggregate-address command. The summary can now be advertised to R2:

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
B 172.16.0.0/24 [20/0] via 192.168.12.1, 00:01:25
B 172.16.0.0/16 [20/0] via 192.168.12.1, 00:01:25
Now we see the summary in the routing table of R2. By default it will still advertise the other prefixes. If you
don’t want this you need to use the aggregate-address summary-only command!
Let me show you option 2 of advertising the summary:

First we’ll put the 172.16.0.0 /16 network in the routing table by creating a static route and pointing it to the
null0 interface. Secondly I’ll use a network command for BGP to advertise this network. The result will be this:

B 172.16.0.0/16 [20/0] via 192.168.12.1, 00:00:45
Now it shows up on R2! Problem solved!
Lesson learned: You can’t advertise what you don’t have. Create a static route and point it to the null0
interface or create a loopback interface that has a prefix that falls within the summary address range.
BGP Auto-Summary
Page 76 of 283
Next problem coming up, this is the topology:
Onto the next scenario. You are working as a network engineer for AS 1 and one day you get a phone call from
the network engineer at AS 2 asking you why you are advertising a summary for 1.0.0.0 /8. You have no idea
what the hell he is talking about so you decide to do some research. Here’s what we see on R2:

B 1.0.0.0/8 [20/0] via 192.168.12.1, 00:02:15
This is what the network engineer on R2 is seeing. Let’s check why R1 is advertising this:

1
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
We can see that we have network 1.0.0.0 /8 in the BGP table of R1. Let’s check its routing table:

Routing entry for 1.0.0.0/24, 1 known subnets
Attached (1 connections)
Redistributing via bgp 1
Advertised by bgp 1
Network 1.1.1.0 /24 is configured on the loopback interface but it’s in the BGP table as 1.0.0.0 /8. This could
mean only 1 thing….summarization. Take a look below:
R1#show ip protocols
Routing Protocol is "bgp 1"
IGP synchronization is disabled
Automatic route summarization is enabled
A quick look at show ip protocols reveals that automatic summarization is enabled. Let’s disable it:
R1(config-router)#no auto-summary
We’ll disable it on R1 so R2 learns the subnet:

Page 77 of 283
B 1.1.1.0 [20/0] via 192.168.12.1, 00:00:20
Now we see 1.1.1.0 /24 on R2…problem solved!
Lesson learned: If you see classful networks in your BGP table you might have auto-summary enabled.
Some of the problems I’ve been showing you could be resolved easily by just looking and/or comparing the
output of a “show run”. This might be true but keep in mind that you don’t always have access to all BGP
routers in the network so maybe there’s no way to compare configurations. There could be a switch or another
router in between the devices you are trying to troubleshooting that are causing issues. Using the appropriate
show and debug commands will show you exactly what your router is doing and what it is advertising to other
routers.
BGP Route-Maps
Same topology, different problem:
The people from AS 2 are complaining that they are not receiving anything from AS 1. To keep it interesting
I’m not going to show you the configurations…

192.168.12.1 4 1 51 48 1 0 0 00:08:51 0
For starters, we can see that R2 is not receiving any prefixes. Do we have any filters?

I can also verify that R1 doesn’t have any distribute-lists. Let’s check if R1 has 1.1.1.0 /24 in its BGP table:

Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
I can confirm that R1 does have network 1.1.1.0 /24 in its routing table so why is it not advertising this to R2?
Page 78 of 283
Let’s see if R1 has configured anything special for its neighbor R2:
R1#show ip bgp neighbors 192.168.12.2

BGP neighbor is 192.168.12.2, remote AS 2, external link
BGP version 4, remote router ID 192.168.12.2
BGP state = Established, up for 00:03:34
Last read 00:00:33, last write 00:00:33, hold time is 180, keepalive interval is 60
seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 11 11
Notifications: 0 0
Updates: 7 0
Keepalives: 85 86
Route Refresh: 0 0
Total: 103 97
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast

BGP table version 3, neighbor version 3/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Outbound path policy configured
Route map for outgoing advertisements is NEIGHBORS
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
I will use the show ip bgp neighbors command to see detailed information of R2. We can see that a route-map
has been applied to R2 and it’s called “NEIGHBORS”. Keep in mind that besides distribute-lists we can use
also use route-maps for BGP filtering. Let’s check it out:
R1# show route-map

route-map NEIGHBORS, permit, sequence 10
Match clauses:
ip address prefix-lists: PREFIXES
Set clauses:
Policy routing matches: 0 packets, 0 bytes
There’s only a match statement for prefix-list “PREFIXES”. Take a look:
R1#show ip prefix-list
ip prefix-list PREFIXES: 1 entries
seq 5 deny 1.1.1.0/24
There’s our troublemaker…its denying network 1.1.1.0 /24! Let’s get rid of this route-map:
Page 79 of 283
R1(config-router)#no neighbor 192.168.12.2 route-map NEIGHBORS out
That should take care of our problem…

B 1.1.1.0 [20/0] via 192.168.12.1, 00:00:03
And finally R2 has learned about this prefix…problem solved!
Lesson learned: Make sure there are no route-maps blocking the advertisement of prefixes.
IBGP Split Horizon

Here’s a new topology:
R1 is advertising network 1.1.1.0 /24 but R3 is not learning this prefix. Here are the configurations:

router bgp 1
no synchronization
network 1.1.1.0 mask 255.255.255.0
no auto-summary
router bgp 1
no synchronization
no auto-summary
router bgp 1
no synchronization
no auto-summary
The neighbor adjacencies have been configured,R1 is advertising network 1.1.1.0 /24. Let’s see if R2 and/or R3
have learned about it:[teaser]

B 1.1.1.0 [200/0] via 192.168.12.1, 00:00:23
Page 80 of 283
We can see network 1.1.1.0 /24 in the routing table of R2 but it’s not showing up on R3.
Technically there is no problem. If you look closely at the BGP configuration of all three routers you can see
there is only a BGP neighbor adjacency between R1 & R2 and between R2 & R3. Because of IBGP split
horizon R2 does not forward network 1.1.1.0 /24 towards R3. In order to fix this we need to configure R1 and
R3 to become neighbors. To accomplish this, R1 and R3 should be able to reach each other. I’ll keep it simple
and use a static route for this:
R1(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2

R3(config)#ip route 192.168.12.1 255.255.255.255 192.168.23.2
If I’m going to configure the BGP neighbor adjacency between R1 and R3 I’ll need to make sure they can reach
each other. I can use a static route or an IGP…to keep things easy I’ll use a static route this time. Now let’s
configure IBGP between R1 and R3:
That should work, take a look at R3:

B 1.1.1.0 [200/0] via 192.168.12.1, 00:00:08
And R3 has access to network 1.1.1.0 /24!
Lesson learned: IBGP neighbor adjacencies have to be full mesh! Another solution would be by using a
route-reflector or confederation.
BGP Next Hop
R3 is advertising network 3.3.3.0 /24 through EBGP and R2 installs it in the routing table. R1 however doesn’t
have this network in its routing table. Here are the configurations:

router bgp 1
no synchronization
Page 81 of 283
no auto-summary
router bgp 1
no synchronization
no auto-summary
router bgp 2
no synchronization
network 3.3.3.0 mask 255.255.255.0
no auto-summary
Here are the configurations. To keep things easy I’m using the physical interface IP addresses to configure the
BGP neighbor adjacencies. Let’s see if R2 learns about 3.3.3.0 /24:

B 3.3.3.0 [20/0] via 192.168.23.3, 00:09:37
We can verify that network 3.3.3.0 /24 is in the routing table of R2. What about R1?
There’s nothing in the routing table of R1 however. The first thing we should check is if it’s the BGP table or
not:
R1#show ip bgp

* i3.3.3.0/24 192.168.23.3 0 100 0 2 i
We can see it’s in the BGP table and the * indicates that this is a valid route. However I don’t see the > symbol
which indicates the best path. For some reason BGP is unable to install this entry in the routing table. Take a
close look at the next hop IP address (192.168.23.3). Is this IP address reachable?

R1 has no idea how to reach 192.168.23.3 so our next hop is unreachable. There are 2 ways how we can deal
with this issue:
 Use a static route or routing protocol to make this next hop IP address reachable.
 Change the next hop IP address.
We’ll change the next hop IP address since I think you’ve seen enough static routes and routing protocols so
far:
Page 82 of 283
This command will change the next hop IP address to the IP address of R2. Check out the changes on R1:
R1#show ip bgp

*>i3.3.3.0/24 192.168.12.2 0 100 0 2 i
You can see the > symbol that indicates that this path has been selected as the best one. The next hop IP address
is now 192.168.12.2.

B 3.3.3.0 [200/0] via 192.168.12.2, 00:10:52
Hooray! It’s in the routing table now. Are we done now? If my goal was to make this show up in the routing
table then we are now finished…there’s another issue however:
R1#ping 3.3.3.3

.....
My ping is unsuccessful. R1 and R2 both have network 3.3.3.0 /24 in their routing table so we know that they
know where to forward the IP packets to. Let’s take a look at R3:
R3#show ip route

R3 will receive an IP packet with destination 3.3.3.3 and source 192.168.12.1. You can see in the routing table
that it has no idea where to send IP packets meant for 192.168.12.1. Let’s change that:
We’ll advertise network 192.168.12.0 /24 on R2. Now R3 knows how to reach it:

B 192.168.12.0/24 [20/0] via 192.168.23.2, 00:00:33
Let’s try that ping from R1 again:
R1#ping 3.3.3.3
Page 83 of 283
!!!!!
Problem solved!
Lesson learned: Make sure the next hop IP address is reachable so routes can be installed in the routing
table and that all required networks are reachable.
BGP Attributes and Path Selection

BGP (Border Gateway Protocol) routers usually receive multiple paths to the same destination. Like how our
IGPs (RIP, EIGRP, OSPF) work, we need to select the best path to each destination.
IGPs select the path with the lowest metric. For example:
 RIP selects the path with the lowest hop count.

 OSPF selects the path with the lowest cost.
 EIGRP selects the path with the highest bandwidth and lowest delay (unless you change the K values).
BGP however, selects the best path based on a list of attributes. On the Internet, it’s more important that you
have granular control over how you forward your traffic and to which autonomous systems instead of just going
for the shortest path based on a metric.
Let’s look at a quick example. Below I have the output of the BGP table of a looking glass server:
oute-views.optus.net.au>show ip bgp

* 1.0.0.0/24 203.202.143.34 0 7474 4826 13335 i
* 192.65.89.161 1 0 7474 4826 13335 i
* 202.139.124.130 1 0 7474 4826 13335 i
* 203.13.132.7 10 0 7474 4826 13335 i
*> 203.202.143.33 0 7474 4826 13335 i
This BGP router has 5 paths for network 1.0.0.0/24. Look at the > symbol at the bottom left. The > symbol
means that BGP has selected this path as the best path. This path will be installed in the routing table.
Out of all those 5 paths, why did BGP select this path as the best path?
Attributes
This path was selected based on the following attributes:
Page 84 of 283
Priority Attribute
1 Weight
2 Local Preference
3 Originate
4 AS path length
5 Origin code
6 MED
7 eBGP path over iBGP path
8 Shortest IGP path to BGP next hop
9 Oldest path
10 Router ID
11 Neighbor IP address
Let me give you a quick overview of each attribute. We will cover these in other lessons in detail.
Weight
Prefer the path with the highest weight. This is a value that is local to the router and it’s Cisco proprietary. The
default value is 0 for all routes that are not originated by the local router. You can learn how it works in the
BGP weight attribute lesson.
Local Preference
The local preference is used within an autonomous system and exchanged between iBGP routers. We prefer the
path with the highest local preference. The default value is 100. To learn more, take a look at the BGP local
preference attribute lesson.
Originate
Prefer the path that the local router originated. In the BGP table, you will see next hop 0.0.0.0. You can get a
path in the BGP table through the BGP network command, aggregation, or redistribution. A BGP router will
prefer routes that it installed into BGP itself over a route that another router installed in BGP.
AS path length
Prefer the path with the shortest AS path length. For example, AS path 1 2 3 is preferred over AS path 1 2 3 4
5. You can learn more about AS path length here.
Page 85 of 283
Origin code
Prefer the lowest origin code. There are three origin codes:
 IGP
 EGP
 INCOMPLETE
IGP is lower than EGP and EGP is lower than INCOMPLETE. You can learn how it works in the origin code
lesson.
MED
Prefer the path with the lowest MED. The MED is exchanged between autonomous systems. For a detailed
explanation, take a look at the MED lesson.
eBGP path over iBGP path
Prefer eBGP (external BGP) over iBGP (internal BGP) paths.
Shortest IGP path to BGP next hop
Prefer the path within the autonomous system with the lowest IGP metric to the BGP next hop.
Oldest Path
Prefer the path that we received first, in other words, the oldest path.
Router ID
Prefer the path with the lowest BGP neighbor router ID. The router ID is based on the highest IP address. If
you have a loopback interface, then the IP address on the loopback will be used. The router ID can also be
manually configured.
Neighbor IP address
Prefer the path with the lowest neighbor IP address. If you have two eBGP routers and two links in between
then the router ID will be the same. In this case, the neighbor IP address is the tiebreaker.
Path Selection
When BGP has multiple paths to a destination they are stored in the BGP table. All paths are in the BGP table
but only one gets installed in the routing table.
Which path do we select? We start at the top of the list with BGP attributes and work our way to the bottom:
1. We start with weight because it’s at the top of the BGP attributes list. We now have two options:
Page 86 of 283
1. If one path has a better weight then we select this path as the best path.
2. If the weight is equal, we move down to the next attribute.
2. The next attribute is local preference. Once again, we have two options:
1. If one path has a better local preference then we select this path as the best path.
2. If the local preference is equal, we move down to the next attribute.
3. We work our way down this attribute list until we have a tiebreaker to select the best path. If all paths have the
same BGP attributes, then we end up with the neighbor IP address.
There are some exceptions to the BGP path selection process when you use (advanced) BGP features like
confederations, route reflectors, or multipath. Cisco has a detailed list with the BGP best path selection algorithm.
I hope this lesson has been useful to understand how BGP selects the best path.
How to Configure BGP Weight Attribute

Weight is a Cisco proprietary BGP attributes that can be used to select a certain path. Here’s what you need to
know about weight:
 Weight is the first BGP attribute in the list.

 Cisco proprietary so you won’t find it on other vendor routers.
 Weight is not exchanged between BGP routers.
 Weight is only local on the router.
 The path with the highest weight is preferred.
Let me give you an example for BGP weight:
R1 in AS 1 can reach AS 3 through AS 2 or AS 4. If we want to ensure AS 2 is always used as the best path you
can change the weight. In my example, the weight for the path to AS 2 is set to 500 and higher than the weight
of 400 for AS 4. Let’s see what this looks like on real Cisco routers, this is the topology that I will use:
Page 87 of 283
Above we have a simple scenario with two autonomous systems. R2 and R3 both have network 2.2.2.0/24
configured on their loopback0 interface and I’ll advertise that in BGP.
Above you’ll find the configuration for BGP, now let’s take a detailed look at R1:
R1#show ip bgp

*> 2.2.2.0/24 192.168.12.2 0 0 2 i
* 192.168.13.3 0 0 2 i
Page 88 of 283
Router R1 decided to use 192.168.12.2 as the next hop. All the BGP attributes are the same so it came down to
the router ID to select a winner. Now let’s change this behavior using the weight attribute…
R1(config-router)#neighbor 192.168.13.3 weight 500
You can configure weight per neighbor using the weight command. All prefixes from this neighbor will have a
weight of 500.
[teaser]
R1#clear ip bgp *
Sometimes BGP behaves like an oil tanker so to speed things up in your lab, reset it.
R1#show ip bgp

* 2.2.2.0/24 192.168.12.2 0 0 2 i
*> 192.168.13.3 0 500 2 i
Now you can see that 192.168.13.3 has been selected as the next hop because the weight is now 500.
What if I want to set the weight to 500 for just a couple of prefixes from AS 2?
I’ll create a new loopback interface on router R2 and R3 and I’ll advertise network 22.22.22.0/24 in BGP.
Here’s what router R1 now looks like:
R1#show ip bgp

* 2.2.2.0/24 192.168.12.2 0 0 2 i
*> 192.168.13.3 0 500 2 i
*> 22.22.22.0/24 192.168.13.3 0 500 2 i
* 192.168.12.2 0 0 2 i
Page 89 of 283
As you can see above router R1 will use 192.168.13.3 as the next hop for both prefixes. What if I want to
change the weight for just 1 prefix? Route-maps to the rescue!
R1(config-router)#no neighbor 192.168.13.3 weight 500
First we’ll get rid of the command above.
R1(config)#route-map SETWEIGHT permit 10

R1(config-route-map)#match ip address 1
R1(config-route-map)#set weight 400
R1(config-route-map)#exit
R1(config)#route-map SETWEIGHT permit 20
R1(config-route-map)#set weight 0
R1(config)#access-list 1 permit 22.22.22.0 0.0.0.255
Here’s the route-map that I will use. If the prefixes match access-list 1 we will set the weight to 400.
R1(config-router)#neighbor 192.168.13.3 route-map SETWEIGHT in
To complete the configuration we have to apply it to our neighbor in AS 2. Using a route-map gives you a lot of
control!
R1#clear ip bgp *
This will speed things up…
R1#show ip bgp

* 2.2.2.0/24 192.168.13.3 0 0 2 i
*> 192.168.12.2 0 0 2 i
*> 22.22.22.0/24 192.168.13.3 0 400 2 i
* 192.168.12.2 0 0 2 i
See how the weight changed for network 22.22.22.0/24 ? Use route-maps to influence the BGP attributes per
neighbor/prefix.
hostname R1
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
Page 90 of 283
neighbor 192.168.13.3 route-map SETWEIGHT in
!
route-map SETWEIGHT permit 10
match ip address 1
set weight 400
!
route-map SETWEIGHT permit 20
set weight 0
!
access-list 1 permit 22.22.22.0 0.0.0.255
!
end
hostname R2
!
ip address 2.2.2.2 255.255.255.0
!
ip address 22.22.22.22 255.255.255.0
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router bgp 2
network 2.2.2.0 mask 255.255.255.0
network 22.22.22.0 mask 255.255.255.0
!
end
hostname R3
!
ip address 2.2.2.2 255.255.255.0
!
interface loopback 1
ip address 22.22.22.22 255.255.255.0
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 2
network 2.2.2.0 mask 255.255.255.0
network 22.22.22.0 mask 255.255.255.0
!
end
Page 91 of 283
How to Configure BGP Local Preference Attribute
BGP attribute local preference is the second BGP attribute and it can be used to choose the exit path for an
autonomous system. Here are the details:
 Local preference is the second BGP attribute.

 You can use local preference to choose the outbound external BGP path.
 Local preference is sent to all internal BGP routers in your autonomous system.
 Not exchanged between external BGP routers.
 Local preference is a well-known and discretionary BGP attribute.
 Default value is 100.
 The path with the highest local preference is preferred
Let me show you an example:
You can use local preference to configure your autonomous system to select a certain exit point. Instead of
configuring weight on each router you can use local preference because it is exchanged on all internal BGP
routers. By increasing the local preference to 800 we can make AS 1 send all traffic towards AS 2.
A well-known discretionary BGP attribute must be recognized by all BGP routers per RFC but its presence in
a BGP update is optional.
Now let me show you how to configure local preference, here is the topology that we will use:
Page 92 of 283
In the picture above we have two autonomous systems. R1 will advertise network 1.1.1.0/24 towards AS 2 and
R4 will have to make a choice when it wants to reach this network. It can go through router R2 or R3, we’ll see
how local preference influence this.
This is the configuration of R4, nothing spectacular here.
I’ll configure OSPF within AS2 to prepare it for IBGP.
R3(config-router)#neighbor 2.2.2.2 update-source loopback0
Page 93 of 283
And above you can see the BGP configurations.
Now let’s find out what path R4 will use to reach network 1.1.1.0/24:
[teaser]
R4#show ip bgp

* i1.1.1.0/24 3.3.3.3 0 100 0 1 i
*>i 2.2.2.2 0 100 0 1 i
All attributes are the same so it’s the router ID that makes the decision. All traffic is sent to R2 right now. Let’s
play with the local preference…
R3(config-router)#bgp default local-preference 600
The default local preference is 100 and you can change it if you like with the bgp default local-preference
command.
R4#show ip bgp

*>i1.1.1.0/24 3.3.3.3 0 600 0 1 i
* i 2.2.2.2 0 100 0 1 i
Now we see that R4 prefers to send traffic to network 1.1.1.0/24 towards R3 because the local preference is 600
> 100.
Of course we can accomplish the same thing with a route-map, here’s how:
Page 94 of 283
R3(config-router)#no bgp default local-preference 600
Let’s clean up first…
R3(config)#route-map LOCALPREF permit 10

R3(config-route-map)#set local-preference 700
R3(config-router)#neighbor 192.168.13.1 route-map LOCALPREF in
Route-maps are a more flexible solution. If you don’t use a match statement in a route-map then everything is
matched by default. You can use it to set the local preference to another value. Don’t forget to activate the
route-map by binding it to a BGP neighbor.
R4#show ip bgp

*>i1.1.1.0/24 3.3.3.3 0 700 0 1 i
* i 2.2.2.2 0 100 0 1 i
And as you can see above the local preference has changed.
hostname R4
!
ip address 4.4.4.4 255.255.255.0
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
network 192.168.24.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
network 4.4.4.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname R1
!
ip address 192.168.12.1 255.255.255.0
!
Page 95 of 283
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
!
end
hostname R2
!
ip address 2.2.2.2 255.255.255.0
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 192.168.24.0 0.0.0.255 area 0
network 2.2.2.0 0.0.0.255 area 0
!
router bgp 2
neighbor 3.3.3.3 update-source loopback0
!
end
hostname R3
!
ip address 3.3.3.3 255.255.255.0
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 192.168.34.0 0.0.0.255 area 0
network 3.3.3.0 0.0.0.255 area 0
!
router bgp 2
neighbor 192.168.13.1 route-map LOCALPREF in
!
route-map LOCALPREF permit 10
set local-preference 700
!
end
Page 96 of 283
How to configure BGP AS Path Prepending
The fourth BGP attribute is called AS Path:
 BGP prefers the shortest AS path to get to a destination. Less is more!

 We can manipulate this by using AS path prepending.
Let me show you an example:
In my example AS 1 wants to make sure traffic enters the autonomous system through R2. We can add our own
autonomous system number multiple times so the as-path becomes longer. Since BGP prefers a shorter AS path
we can influence our routing. This is called AS path prepending. Let’s see what this looks like on Cisco
routers, this is the topology that I will use:
Page 97 of 283
Above we have 3 routers. R1 and R3 are both in AS 1 advertising the same network (1.1.1.0/24) to R2. We can
use AS Path prepending to make R2 prefer a certain path.
[teaser]
R1(config-router)#bgp router-id 1.1.1.1
First, we’ll configure BGP between the three routers.
And we’ll advertise both networks in BGP.
R2#show ip bgp

* 1.1.1.0/24 192.168.23.3 0 0 1 i
*> 192.168.12.1 0 0 1 i
In the table above you can see that it prefers 192.168.12.1 as its path. Let’s change the AS path so that we’ll use
192.168.23.3 as the preferred path.
R1(config)#route-map PREPEND permit 10

R1(config-route-map)#set as-path prepend 1 1 1 1 1
R1(config-router)#neighbor 192.168.12.2 route-map PREPEND out
Here’s an example for you. First, create a route-map and use set as-path prepend to add your own AS number
multiple times.
Don’t forget to add the route-map to your BGP neighbor configuration and since you are sending this to your
remote neighbor it should be outbound!
R2#show ip bgp

*> 1.1.1.0/24 192.168.23.3 0 0 1 i
Page 98 of 283
* 192.168.12.1 0 0 1 1 1 1 1 1 i
Now we see that 192.168.23.3 is the next hop IP address that we use. You can also see that the AS Path has
become longer for the second entry.
hostname R1
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
bgp router-id 1.1.1.1
network 1.1.1.0 mask 255.255.255.0
neighbor 192.168.12.2 route-map PREPEND out
!
route-map PREPEND permit 10
set as-path prepend 1 1 1 1 1
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router bgp 2
!
end
hostname R3
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
!
end
BGP Origin Code Attribute explained

The BGP Origin Code is one of the attributes that is used for path selection. There are three origin codes that the
BGP table can show:
Page 99 of 283
 IGP (shows up as i)
 EGP (shows up as e)
 Incomplete (shows up as ?)
You will see IGP when you use the network command for BGP. It means you advertised the network yourself
in BGP. EGP is historical and you won’t see it in the BGP table anymore. EGP is an old routing protocol we
don’t use it anymore. Incomplete means you have redistributed something into BGP. Here’s a demonstration:
Above you can see the topology that I will use. R1 and R3 are in AS1 and connected to R2 in AS2. Both routers
have a loopback0 interface with network 1.1.1.0/24 configured on it.
First we’ll configure BGP. Next step is to get network 1.1.1.0/24 in the BGP table:
R3(config-router)#redistribute connected
On R1 I’ll advertise network 1.1.1.0/24 in BGP with the network command, on R3 we’ll redistribute it. Let’s
see what R2 thinks of this…
[teaser]
R2#show ip bgp
Page 100 of 283

* 1.1.1.0/24 192.168.23.3 0 0 1 ?
*> 192.168.12.1 0 0 1 i
In the output above you can see that R2 learned both networks through BGP. There’s one small difference
however. The first entry shows a ? symbol and the second entry shows an ‘i’.
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router bgp 2
!
end
hostname R1
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
!
end
hostname R3
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 1
redistribute connected
!
end
How to configure BGP MED Attribute

MED (or metric) is the sixth BGP attribute:
 MED can be used to advertise to your neighbors how they should enter your AS.
Page 101 of 283
 MED is exchanged between autonomous systems.
 The lowest MED is the preferred path.
 MED is propagated to all routers within the neighbor AS but not passed along any other autonomous
systems.
Let’s look at an example:
MED (also called metric) is exchanged between autonomous systems and you can use it to let the other AS
know which path they should use to enter your AS. R2 is sending a MED of 200 towards AS 3. R3 is sending a
MED of 300 to AS 3. AS 3 will prefer the lower metric and send all traffic for AS 1 through R2. Let me show
you how to configure this on a Cisco router:
Above we have two autonomous systems. R1 and R3 will both advertise network 1.1.1.0 /24 in BGP. We can
use MED to tell AS 2 which path to use to reach this network.
Page 102 of 283
This is the BGP configuration, nothing special so far.
R2#show ip bgp

* 1.1.1.0/24 192.168.23.3 0 0 1 i
*> 192.168.12.1 0 0 1 i
You have seen the example above before. R2 prefers the path through 192.168.12.1. Note that the metric
(MED) is 0. Let’s play with the MED now:
[teaser]
R1(config)#route-map MED permit 10

R1(config-route-map)#set metric 700
R1(config-router)#neighbor 192.168.12.2 route-map MED out
R3(config)#route-map MED permit 10
R3(config-router)#neighbor 192.168.23.2 route-map MED out
I’ll use route-maps so that R1 advertises everything with a med of 700 and R3 will advertise everything with a
med of 500.
R2#show ip bgp

* 1.1.1.0/24 192.168.12.1 700 0 1 i
*> 192.168.23.3 500 0 1 i
You can see R2 prefers the path through 192.168.23.3 because the med is lower. That’s all there is to it.
Page 103 of 283

hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router bgp 2
!
end
hostname R1
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
neighbor 192.168.12.2 route-map MED out
!
route-map MED permit 10
set metric 700
!
end
hostname R3
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
neighbor 192.168.23.2 route-map MED out
!
route-map MED permit 10
set metric 500
!
end
BGP Communities Explained

A BGP community is bit of “extra information” that you can add to one of more prefixes which is advertised to
BGP neighbors. This extra information can be used for things like traffic engineering or dynamic routing
policies. There are 4 well known BGP communities that you can use or you can pick a numeric value that you
can use for your own policies.
Here are the 4 well known BGP communities:

Page 104 of 283
 Internet: advertise the prefix to all BGP neighbors.
 No-Advertise: don’t advertise the prefix to any BGP neighbors.
 No-Export: don’t advertise the prefix to any eBGP neighbors.
 Local-AS: don’t advertise the prefix outside of the sub-AS (this one is used for BGP confederations).
Once you finish reading this lesson, click on one of the links above to learn more about these well known BGP
communities. I explained each of them in a separate lesson.
Why do we call them communities? A community is a group of prefixes that should be treated the same way.
For example maybe you have 100 prefixes that require the same local preference or weight. You could match
all prefixes using an access-list or prefix-list but using BGP communities is more convenient.
Instead of manually selecting the prefixes, an ISP could instruct its customers to tag prefixes with a certain BGP
community. When the customer does this, their prefixes get a certain treatment.
To give you an idea, here are some examples that I found from Level 3 (large ISP in the US):
--------------------------------------------------------
customer traffic engineering communities - Prepending
--------------------------------------------------------
65001:0 - prepend once to all peers
65001:XXX - prepend once at peerings to AS XXX
65002:0 - prepend twice to all peers
65002:XXX - prepend twice at peerings to AS XXX
65003:0 - prepend 3x to all peers
65003:XXX - prepend 3x at peerings to AS XXX
65004:0 - prepend 4x to all peers
65004:XXX - prepend 4x at peerings to AS XXX
--------------------------------------------------------
customer traffic engineering communities - Regional
--------------------------------------------------------
Will only work for regional peers
64980:0 - announce to customers but not to EU peers
64981:0 - prepend once to all EU peers
64982:0 - prepend twice to all EU peers
64983:0 - prepend 3x to all EU peers
64984:0 - prepend 4x to all EU peers
--------------------------------------------------------
customer traffic engineering communities - LocalPref
--------------------------------------------------------
3356:70 - set local preference to 70
This list might not be up-to-date anymore but it gives you an impression of how BGP communities are used. If
a customer of Level 3 tags their prefixes with 3356:90 then they will set the local preference to 90. If you tag
them with 64983:0 then they will prepend the AS number three times to all their BGP neighbors in Europe.
These BGP communities are 32-bit values that are divided in two sections. For labs you can pick whatever
values you like but normally the first 16 bits are used to indicate the AS number that originates the community,
the next 16 bits are assigned by the AS. For example, Level 3 uses these communities:
--------------------------------------------------------
customer traffic engineering communities - LocalPref
Page 105 of 283
--------------------------------------------------------
The first 16 bits is their AS number (3356) and the next 16 bits (70, 80 and 90) corresponds with the local
preference value. On their routers they configured a policy that sets the local preference to these values if they
receive prefixes with these BGP communities.
Nowadays we also use extended communities which are 8 octets. These are used often for MPLS VPN which
we will discuss in another lesson. Let’s take a look at a configuration example so you can see how to implement
BGP communities.
Configuration
For this example I will use the following topology:
On the left side we have a customer router that is connected to ISP1. This ISP is connected to ISP2 and ISP3.
Let’s imagine that ISP2 is somewhere in Europe and that ISP1 has a policy that they will prepend their AS
number four times to BGP neighbors in Europe whenever a customer adds BGP community value 64984:0 to
their prefixes.
Page 106 of 283

Let’s see how we can configure this on the ISP1 and customer router.
BGP Configuration
Here is the BGP configuration, it’s straight-forward eBGP:
Customer#show running-config | section bgp

router bgp 10
no synchronization
network 10.10.10.10 mask 255.255.255.255
no auto-summary
ISP1#show running-config | section bgp
router bgp 1
no synchronization
no auto-summary
router bgp 2
no synchronization
no auto-summary
router bgp 3
no synchronization
no auto-summary
Let’s see if ISP1 has learned any prefixes from the customer router:
ISP1#show ip bgp 10.10.10.10

Flag: 0x820
1
10
192.168.10.10 from 192.168.10.10 (192.168.10.10)
ISP1 has learned the network on the loopback interface of the customer router. Right now we don’t have any
BGP communities. Let’s start with the configuration of ISP1…
ISP1 AS Path Prepend Configuration
First we will create a community list that matches the community- value:[teaser]
ISP1(config)#ip community-list 1 permit 64984:0
Page 107 of 283

The community-list is similar to an access-list or prefix-list but only used for BGP communities. Our next step
is to create a route-map that will prepend the AS path whenever we see this value:
ISP1(config)#route-map PREPEND_EU permit 10

ISP1(config-route-map)#match community 1
ISP1(config-route-map)#set as prepend 1 1 1 1
ISP1(config-route-map)#exit
ISP1(config)#route-map PREPEND_EU permit 20
This route-map matches on community-list 1 and prepends the AS path four times. Let’s attach it outbound to
ISP2:
ISP1(config)#router bgp 1
ISP1(config-router)#neighbor 192.168.12.2 route-map PREPEND_EU out
This takes care of the configuration of ISP1. Let’s configure our customer router to send the BGP community
with its prefix advertisement now…
Customer BGP Community Configuration
On our customer router we will use a prefix-list to match the network on the loopback interface:
Customer(config)#ip prefix-list LOOPBACK permit 10.10.10.10/32
And we’ll use a route-map to set the BGP community:
Customer(config)#route-map SET_COMMUNITY permit 10

Customer(config-route-map)#match ip address prefix-list LOOPBACK
Customer(config-route-map)#set community 64984:0
Customer(config-route-map)#exit
Customer(config)#route-map SET_COMMUNITY permit 20
Everything that matches the prefix-list will have a community value of 64984:0. Now we have to activate this
route-map:
Customer(config)#router bgp 10
Customer(config-router)#neighbor 192.168.10.1 route-map SET_COMMUNITY out
Customer(config-router)#neighbor 192.168.10.1 send-community
Take a close look at the second command, we have to use the neighbor send-community command because
the router doesn’t automatically send BGP communities to its neighbors. Everything is in place, let’s verify our
work…
Verification
To speed things up I will reset BGP:
Customer#clear ip bgp *
Now take look at ISP1 to see if it received the BGP community:
Page 108 of 283

1 2
10
192.168.10.10 from 192.168.10.10 (10.10.10.10)
Community: 4258791424
This looks interesting, it did receive our community value but it’s showing it as a big 32-bit decimal number.
There’s a command on Cisco IOS that lets you choose between this output and the output with two 16-bit
values. Let’s change it:
ISP1(config)#ip bgp-community new-format
Use the ip bgp community new-format command and it will now look like this:

1 2
10
192.168.10.10 from 192.168.10.10 (10.10.10.10)
Community: 64984:0
That’s better…now let’s see if ISP1 has prepended the AS Path:
ISP2#show ip bgp

*> 10.10.10.10/32 192.168.12.1 0 1 1 1 1 1 10 i
ISP3#show ip bgp

*> 10.10.10.10/32 192.168.13.1 0 1 10 i
Great! Just like expected, the ISP1 router has prepended the AS path when it advertised the prefix to ISP2. Next
time our customer wants something prepended, they only have to set the correct community value.
I hope this example has been useful to understand what BGP communities are about and how to implement
them. Of course we still have our well known communities:
 Internet
 No-Advertise
Page 109 of 283
 No-Export
 Local-AS
BGP Community No Advertise

The BGP No Advertise community is one of the four well known communities. If you have no idea what BGP
communities are about, I would suggest to check the introduction lesson first. That’s where you will learn about
the basics of BGP communities.
When you add the no-advertise community to a prefix then the receiving BGP router will use and store the
prefix in its BGP table but it won’t advertise the prefix to any other neighbors.
Let’s look at an example, this is the topology I will use:
Above you can see R1 with a loopback interface that has network 1.1.1.1 /32. We will advertise this network in
BGP towards R2 with the no advertise community set. As a result, R2 will not advertise it to R3 (eBGP) or R4
(iBGP).
Configuration
Here’s the basic BGP configuration in case you want to try this example yourself.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/1
Page 110 of 283

ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.1 mask 255.255.255.255
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
router bgp 24
!
end
hostname R3
!
ip cef
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 3
!
end
hostname R4
!
ip cef
!
ip address 192.168.24.4 255.255.255.0
!
router bgp 24
!
end
Let’s see if R2, R3 and R4 have learned our prefix:
R2#show ip bgp | include 1.1.1.1

*> 1.1.1.1/32 192.168.12.1 0 0 1 i
Page 111 of 283
*> 1.1.1.1/32 192.168.23.2 0 24 1 i
* i1.1.1.1/32 192.168.24.2 0 100 0 1 i
It’s in the BGP table of these routers. Now let’s configure R1 to add the no advertise community:
R1(config-router)#neighbor 192.168.12.2 send-community
First we have to tell R1 to send BGP communities, by default this is disabled. Now we can create a route-map
that sets the community value:
R1(config)#route-map NO_ADVERTISE permit 10

R1(config-route-map)#set community no-advertise
This route-map doesn’t have any match statements so it will set the no advertise community to all prefixes.
Let’s activate it:[teaser]
R1(config-router)#neighbor 192.168.12.2 route-map NO_ADVERTISE out
The route-map is now activated on R1 for everything that is advertises to R2.
In this example I set the BGP community outbound on R1. It’s also possible to configure it inbound on R2.
Before we reset BGP to activate our changes, let’s take a closer look at the BGP table:

Flag: 0x820
1 2
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Above you see the BGP table entry for 1.1.1.1/32 without any community information. Let’s reset BGP so you
can see the difference:
R2#clear ip bgp *
Now you will see this:

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Flag: 0x820
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Community: no-advertise
Page 112 of 283

R2 learned the prefix and you can see the no-advertise community. As a result, it will no longer advertise this
prefix to R3 or R4:
R2#show ip bgp neighbors 192.168.24.4 advertised-routes
Total number of prefixes 0

The advertised-routes parameter is a great way to see what you are advertising on your routers. Another option
would be to check the BGP table of R3 and R4 directly:

There’s nothing there…mission accomplished.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 send-community
neighbor 192.168.12.2 route-map NO_ADVERTISE out
!
route-map NO_ADVERTISE permit 10
set community no-advertise
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
router bgp 24
Page 113 of 283

!
end
hostname R3
!
ip cef
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 3
!
end
hostname R4
!
ip cef
!
ip address 192.168.24.4 255.255.255.0
!
router bgp 24
!
end
Make sure you also check out the other two BGP communities:
 No Export
 Local AS
BGP Community No Export

The well known BGP community no export tells BGP neighbors to advertise a prefix only to iBGP neighbors.
If you are not sure what BGP communities are and how they work then I advise you to read my introduction to
BGP communities first before you continue. Having said that, let’s take a look at a configuration example.
Here’s the topology we will use:
Page 114 of 283

Above we see R1 with network 1.1.1.1/32 on a loopback interface. It will advertise this prefix with the no
export community set. As a result, R2 will install it in its BGP table and advertises it to R4 (iBGP). It will not
be advertised to R3 since this is a eBGP session.
Configuration
Basic BGP Configuration
Here’s the BGP configuration in case you want to try this example yourself:

router bgp 1
no synchronization
network 1.1.1.1 mask 255.255.255.255
no auto-summary
router bgp 24
no synchronization
no auto-summary
router bgp 3
no synchronization
no auto-summary
router bgp 24
no synchronization
Page 115 of 283
no auto-summary
By default BGP does not send any communities. All routers will learn about 1.1.1.1/32:

*> 1.1.1.1/32 192.168.12.1 0 0 1 i
*> 1.1.1.1/32 192.168.23.2 0 24 1 i
* i1.1.1.1/32 192.168.12.1 0 100 0 1 i
BGP Community No-Export Configuration
Let’s configure our BGP community. First we have to tell R1 to send communities:
Now we can create a route-map that sets the BGP community to no-export and we attach it to our neighbor
R2:[teaser]
R1(config)#route-map NO_EXPORT permit 10

R1(config-route-map)#set community no-export
R1(config-router)#neighbor 192.168.12.2 route-map NO_EXPORT out
Before we reset the BGP session, take a look at the BGP table of R2:

Flag: 0x820
1 2
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Above you don’t see any BGP community information. Let’s reset BGP so that you can see the difference:
R2#clear ip bgp *
Here’s what the BGP table of R2 looks like now:

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP
peer)
Flag: 0x820
2
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Page 116 of 283
Community: no-export
You can see that this prefix is tagged with the no export community. R2 no longer advertises it to eBGP
neighbors. Let’s verify this:

R3 doesn’t have this prefix anymore, R4 does:

Flag: 0x820
1
192.168.24.2 from 192.168.24.2 (192.168.24.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
That’s all there is to it. Set the no export community and your prefix will not be advertised to eBGP neighbors.
hostname R1
!
ip cef
!
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
no synchronization
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 route-map NO_EXPORT out
no auto-summary
!
route-map NO_EXPORT permit 10
set community no-export
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
Page 117 of 283

ip address 192.168.24.2 255.255.255.0
!
router bgp 24
no synchronization
no auto-summary
!
end
hostname R3
!
ip cef
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 3
no synchronization
no auto-summary
!
end
hostname R4
!
ip cef
!
ip address 172.16.1.1 255.255.255.0
!
router bgp 24
no synchronization
no auto-summary
!
end
Make sure you also check the other well known BGP communities:
 No-Advertise
 Local AS
BGP Community Local AS

The local AS community is a well known BGP community and can be used for BGP confederations. It’s
basically the same as the no export community but this one works for within the sub-AS of a confederation.
Prefixes that are tagged are only advertised to other neighbors in the same sub-AS, not to other sub-AS’es or
eBGP routers.
Configuration
Page 118 of 283
To demonstrate this I will use the following topology:
Page 119 of 283

Page 120 of 283
AS 2345 has 4 routers and 2 sub-AS’es. We will advertise a prefix from R1 to AS 2345 so you can see what
happens with and without the use of the local AS community. Let’s look at the configuration…
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.1 mask 255.255.255.255
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.24.0 0.0.0.255 area 0
!
router bgp 23
bgp confederation identifier 2345
bgp confederation peers 45
!
end
hostname R3
!
ip cef
!
Page 121 of 283
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.36.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.35.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.36.0 0.0.0.255 area 0
!
router bgp 23
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.45.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 45
!
end
hostname R5
Page 122 of 283
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.35.5 255.255.255.0
!
ip address 192.168.45.5 255.255.255.0
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 45
!
end
hostname R6
!
ip cef
!
ip address 192.168.36.6 255.255.255.0
!
router bgp 6
!
end
R1 advertises prefix 1.1.1.1/32 in BGP, let’s see if our routers have learned this:
R2#show ip bgp | begin 1.1.1.1

*> 1.1.1.1/32 192.168.12.1 0 0 1 i
*>i1.1.1.1/32 192.168.12.1 0 100 0 1 i
* i1.1.1.1/32 192.168.12.1 0 100 0 (23) 1 i
*> 192.168.12.1 0 100 0 (23) 1 i
* i1.1.1.1/32 192.168.12.1 0 100 0 (23) 1 i
*> 192.168.12.1 0 100 0 (23) 1 i
*> 1.1.1.1/32 192.168.36.3 0 2345 1 i
All routers know about this prefix. Time to activate the local AS community…
Page 123 of 283

Local AS Community Configuration
We will create a route-map on R2 that sets the local AS community on all prefixes that it receives from R1:
R2(config)#route-map LOCAL_AS permit 10

R2(config-route-map)#set community local-AS
R2(config-router)#neighbor 192.168.12.1 route-map LOCAL_AS in
R2 sets the community so make sure that it advertises it to R3. Before we reset BGP, take a look at the BGP
table of R2:[teaser]

2 3
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Above you can see the output without any communities. Let’s reset BGP now:
R2#clear ip bgp *
Here’s what it looks like now:

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised outside
local AS)
Flag: 0x820
3
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
Community: local-AS
Above you can see that this prefix has the local AS community. It will not be advertised outside of our sub-AS.
So which of our routers still has it?

*>i1.1.1.1/32 192.168.12.1 0 100 0 1 i
Only R3 has the prefix now since it’s in the same sub-AS as R2. Another good method to verify this is by using
checking what prefixes are advertised by R2 and R3:
Page 124 of 283

*> 1.1.1.1/32 192.168.12.1 0 0 1 i
Above you can see that R2 advertises 1.1.1.1/32 to R3, it doesn’t advertise it to R4 anymore:
We can also check this on R3:

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised outside
local AS)
Flag: 0x820
1
192.168.12.1 (metric 20) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Community: local-AS
R3 sees the local AS community so it doesn’t advertise this prefix to R5 or R6:

That’s all there is to it. Make sure you also check the other well known BGP communities:
 No-Advertise
 No-Export
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
Page 125 of 283

router bgp 1
network 1.1.1.1 mask 255.255.255.255
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.24.0 0.0.0.255 area 0
!
router bgp 23
neighbor 192.168.12.1 route-map LOCAL_AS in
!
route-map LOCAL_AS permit 10
set community local-AS
!
end
hostname R3
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.36.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.35.3 255.255.255.0
Page 126 of 283
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.36.0 0.0.0.255 area 0
!
router bgp 23
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.45.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 45
!
end
hostname R5
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.35.5 255.255.255.0
!
ip address 192.168.45.5 255.255.255.0
Page 127 of 283
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 45
!
end
hostname R6
!
ip cef
!
ip address 192.168.36.6 255.255.255.0
!
router bgp 6
!
end
BGP Regular Expressions Examples

Regular Expressions are used often for BGP route manipulation or filtering. In this lesson we’ll take a look at
some useful regular expressions. First let’s take a look at the different characters that we can use:
Characters
? repeats the previous character one or zero times.
* repeats the previous character zero or many times.
+ repeats the previous character one or more times.
^ matches the beginning of a string.
$ matches the end of a string.
[] is a range.
_ matches the space between AS numbers or the end of the AS PATH list.
\\ is an escape character. You’ll need this for BGP confederations.
Page 128 of 283

Examples
^$ matches an empty AS PATH so it will match all prefixes from the local AS.
^51_ matches prefixes from AS 51 that is directly connected to our AS.
_51_ matches prefixes that transit AS 51.
_51$ matches prefixes that originated in AS 51, the $ ensures that it’s the beginning of the AS PATH.
^([0-9]+)_51 matches prefixes from AS 51 where AS 51 is behind one of our directly connected AS’es.
^51_([0-9]+) matches prefixes from the clients of directly connected AS 51.
^(51_)+([0- matches prefixes from the clients of directly connected AS 51, where AS 51 might be doing AS PATH
9]+) prepending.
^51_([0- matches prefixes from the clients of directly connected AS 51, where the clients might be doing AS
9]+_)+ PATH prepending.
^\65200\) matches prefixed from confederation peer 65200.
If you need some practice for these, I would suggest to use a BGP looking glass server.
Got some more useful BGP regular expressions? Please let me know!
BGP Prevent Transit AS

By default BGP will advertise all prefixes to EBGP (External BGP) neighbors. This means that if you are multi-
homed (connected to two or more ISPs) that you might become a transit AS. Let me show you an example:
R1 is connected to ISP1 and ISP2 and each router is in a different AS (Autonomous System). Since R1 is multi-
homed it’s possible that the ISPs will use R1 to reach each other. In order to prevent this we’ll have to ensure
that R1 only advertises prefixes from its own autonomous system.
Page 129 of 283

As far as I know there are 4 methods how you can prevent becoming a transit AS:
 Filter-list with AS PATH access-list.

 No-Export Community.
 Prefix-list Filtering
 Distribute-list Filtering
Prefix-lists or distribute-lists will work but it’s not a very scalable solution if you have thousands of prefixes in
your BGP table. The filter-list and no-export community work very well since you only have to configure them
once and it will not matter if new prefixes show up. First we’ll configure BGP on each router:
ISP1(config-router)#neighbor 192.168.12.1 remote-as 1
ISP2(config-router)#neighbor 192.168.13.1 remote-as 1
The commands above will configure EBGP (External BGP) between R1 – ISP1 and R1 – ISP2. To make sure
we have something to look at, I’ll advertise the loopback interfaces in BGP on each router:
ISP1(config-router)#network 2.2.2.0 mask 255.255.255.0
ISP2(config-router)#network 3.3.3.0 mask 255.255.255.0
With the networks advertised, let’s take a look at the BGP table of ISP1 and ISP2 to see what they have learned:
ISP1#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
*> 3.3.3.0/24 192.168.12.1 0 1 3 i
ISP2#show ip bgp

*> 1.1.1.0/24 192.168.13.1 0 0 1 i
*> 2.2.2.0/24 192.168.13.1 0 1 2 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
The ISP routers have learned about each other networks and they will use R1 as the next hop. We now have
everything in place to play with the different filtering techniques.
Page 130 of 283

Filter-list with AS PATH access-list
Using an filter-list with the AS PATH access-list is probably the most convenient solution. It will ensure that
you will always only advertise prefixes from your own autonomous system. Here’s how to do it:
R1(config)#ip as-path access-list 1 permit ^$
R1(config-router)#neighbor 192.168.12.2 filter-list 1 out

R1(config-router)#neighbor 192.168.13.3 filter-list 1 out
The ^$ regular expression ensures that we will only advertise locally originated prefixes. We’ll have to apply
this filter to both ISPs.
Keep in mind that BGP is slow…if you are doing labs, it’s best to speed things up with clear ip bgp *
Let’s verify our configuration:
R1#show ip bgp

*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 2.2.2.0/24 192.168.12.2 0 0 2 i
*> 3.3.3.0/24 192.168.13.3 0 0 3 i
R1 still knows about the prefixes from the ISP routers. What about ISP1 and ISP2?
ISP1#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
ISP2#show ip bgp

*> 1.1.1.0/24 192.168.13.1 0 0 1 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
ISP1 and ISP2 only know about the 1.1.1.0 /24 network. Excellent, we are no longer a transit AS!
hostname ISP1
!
Page 131 of 283
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
network 2.2.2.0 mask 255.255.255.0
!
end
hostname ISP2
!
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.13.3 255.255.255.0
!
router bgp 3
network 3.3.3.0 mask 255.255.255.0
!
end
hostname R1
!
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
neighbor 192.168.12.2 filter-list 1 out
neighbor 192.168.13.3 filter-list 1 out
!
ip as-path access-list 1 permit ^$
!
end
On to the next method…
No-Export Community
Using the no-export community will also work pretty well. We will configure R1 so that prefixes from the ISP
routers will be tagged with the no-export community. This ensures that the prefixes from those routers will be
known within AS 1 but won’t be advertised to other routers.
R1(config)#route-map NO-EXPORT
R1(config-route-map)#set community no-export
Page 132 of 283

R1(config-router)#neighbor 192.168.12.2 route-map NO-EXPORT in
R1(config-router)#neighbor 192.168.13.3 route-map NO-EXPORT in
I’m only using one router in AS 1, if you have other routers and are running IBGP (Internal BGP) then don’t forget to send
communities to those routers with the neighbor <ip> send-community command.
Let’s see what ISP1 and ISP2 think about our configuration:
ISP1#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
ISP2#show ip bgp

*> 1.1.1.0/24 192.168.13.1 0 0 1 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
They only know about network 1.1.1.0 /24.
hostname ISP1
!
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
network 2.2.2.0 mask 255.255.255.0
!
end
hostname ISP2
!
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.13.3 255.255.255.0
!
router bgp 3
network 3.3.3.0 mask 255.255.255.0
!
end
hostname R1
Page 133 of 283
!
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
neighbor 192.168.12.2 route-map NO-EXPORT in
neighbor 192.168.13.3 route-map NO-EXPORT in
!
route-map NO-EXPORT
set community no-export
!
end
Onto the next method!
Prefix-List Filtering
Using a prefix-list we can determine what prefixes are advertised to our BGP neighbors. This works fine but it’s
not a good solution to prevent becoming a transit AS. Each time you add new prefixes you’ll have to
reconfigure the prefix-list. Anyway let me show you how it works:
R1(config)#ip prefix-list NO-TRANSIT permit 1.1.1.0/24
R1(config-router)#neighbor 192.168.12.2 prefix-list NO-TRANSIT out

R1(config-router)#neighbor 192.168.13.3 prefix-list NO-TRANSIT out
The prefix-list above will only advertise 1.1.1.0 /24 to the ISP routers. Let’s verify the configuration:
[teaser]
ISP1#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
ISP2#show ip bgp

*> 1.1.1.0/24 192.168.13.1 0 0 1 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
Page 134 of 283
The prefix-list is working as it should.
hostname ISP1
!
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
network 2.2.2.0 mask 255.255.255.0
!
end
hostname ISP2
!
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.13.3 255.255.255.0
!
router bgp 3
network 3.3.3.0 mask 255.255.255.0
!
end
hostname R1
!
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
neighbor 192.168.12.2 prefix-list NO-TRANSIT out
neighbor 192.168.13.3 prefix-list NO-TRANSIT out
!
ip prefix-list NO-TRANSIT permit 1.1.1.0/24
!
end
Onto the last exercise!
Distribute-list Filtering
This method is similar to using the prefix-list but this time we’ll use an access-list.
Page 135 of 283
R1(config)#ip access-list standard NO-TRANSIT
R1(config-std-nacl)#permit 1.1.1.0 0.0.0.255
R1(config-router)#neighbor 192.168.12.2 distribute-list NO-TRANSIT out

R1(config-router)#neighbor 192.168.13.3 distribute-list NO-TRANSIT out
Time to check the ISPs:
ISP1#show ip bgp

*> 1.1.1.0/24 192.168.12.1 0 0 1 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
ISP2#show ip bgp

*> 1.1.1.0/24 192.168.13.1 0 0 1 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
That’s all there is to it.
hostname ISP1
!
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
network 2.2.2.0 mask 255.255.255.0
!
end
hostname ISP2
!
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.13.3 255.255.255.0
!
router bgp 3
network 3.3.3.0 mask 255.255.255.0
!
end
hostname R1
Page 136 of 283

!
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
neighbor 192.168.12.2 distribute-list NO-TRANSIT out
neighbor 192.168.13.3 distribute-list NO-TRANSIT out
!
ip access-list standard NO-TRANSIT
permit 1.1.1.0 0.0.0.255
!
end
BGP IPv6 Route Filtering on Cisco IOS

Filtering IPv6 routes in BGP is similar to IPv4 filtering. There are 3 methods we can use:
 Prefix-list
 Filter-list
 Route-map
Each of these can be applied in- or outbound. I’ll explain how you can use these for filtering, this is the
topology I will use:
R1 and R2 are using IPv6 addresses and will use MP-BGP so that R1 can advertise some prefixes on its
loopback interfaces. All prefixes on the loopback interfaces are /64 subnets while loopback3 has a /96 subnet.
Configuration
Let’s start with a basic MP-BGP configuration so that R1 and R2 become eBGP neighbors:
R1 & R2#
(config)ipv6 unicast-routing
Page 137 of 283
R1(config-router)#neighbor 2001:db8:0:12::2 remote-as 2
R1(config-router)#address-family ipv6
R1(config-router-af)#neighbor 2001:db8:0:12::2 activate
R1(config-router-af)#network 2001:db8:0:1::/64
Let’s check if R2 has learned all prefixes:
R2#show ipv6 route bgp | begin 2001

B 2001:DB8:0:1::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:11::/64 [20/0]
B 2001:DB8:0:111::/64 [20/0]
B 2001:DB8:0:1111::/96 [20/0]
There we go, everything is in the routing table. Now we can play with some of the filtering options…
Prefix-List Filtering
Let’s start with the prefix-list. R1 is advertising one /96 subnet. Let’s see if we can configure R2 to filter this
network:
R2(config)#ipv6 prefix-list SMALL_NETWORKS permit 2001::/16 le 64
This prefix-list checks the entire 2001::/16 range and permits subnets with a /64 or larger. Anything smaller will
be denied. Let’s activate it:
R2(config-router-af)#neighbor 2001:db8:0:12::1 prefix-list SMALL_NETWORKS in
We activate the prefix-list inbound on R2 for everything that we receive from R1. Let’s reset BGP to speed
things up:
R2#clear ip bgp *
Let’s check R2 to see if our prefix is gone:

B 2001:DB8:0:1::/64 [20/0]
B 2001:DB8:0:11::/64 [20/0]
Page 138 of 283

B 2001:DB8:0:111::/64 [20/0]
Great, it has been filtered succesfully!
Filter-List Filtering
Let’s try the filter-list. We can use this to filter prefixes from certain autonomous systems. Everything that R1 is
advertising only has AS 1 in the AS path, I’ll configure AS prepending so we have something to play with:
R1(config)#ipv6 prefix-list FIRST_LOOPBACK permit 2001:db8:0:1::/64

R1(config-route-map)#match ipv6 address prefix-list FIRST_LOOPBACK
R1(config-route-map)#set as-path prepend 11
R1(config-router-af)#neighbor 2001:db8:0:12::2 route-map PREPEND out
The above configuration will make sure that whenever R1 advertises 2001:db8:0:1::/64 it will add AS 11 to the
AS path. Let’s verify this:
R2#show ip bgp all


Filter

*> 2001:DB8:0:1::/64
2001:DB8:0:12::1
0 0 1 11 i
*> 2001:DB8:0:11::/64
2001:DB8:0:12::1
0 0 1 i
*> 2001:DB8:0:111::/64
2001:DB8:0:12::1
0 0 1 i
For address family: IPv4 Multicast
Above you can see that 2001:DB8:0:1::/64 now has AS 11 in its AS path. Let’s configure a filter-list on R2 to
get rid of this network:
R2(config)#ip as-path access-list 11 permit ^1$
Page 139 of 283
R2(config-router-af)#neighbor 2001:db8:0:12::1 filter-list 11 in
R2#clear ip bgp *
The as-path access-list above only permits prefixes from AS1, nothing else. We attach it inbound to everything
we receive from R1. This is the result:

B 2001:DB8:0:11::/64 [20/0]
B 2001:DB8:0:111::/64 [20/0]
It’s gone from the routing table, mission accomplished.
Route-Map Filtering
Route-maps are really useful and can be used to match on many different things. I’ll use an IPv6 access-list in a
route-map to filter 2001:DB8:0:11::/64:[teaser]
R2(config)#ipv6 access-list THIRD_LOOPBACK

R2(config-ipv6-acl)#permit 2001:db8:0:11::/64 any
R2(config)#route-map MY_FILTER deny 10

R2(config-route-map)#match ipv6 address THIRD_LOOPBACK
R2(config)#route-map MY_FILTER permit 20
R2(config-router-af)#neighbor 2001:db8:0:12::1 route-map MY_FILTER in
R2#clear ip bgp *
The configuration above has an access-list called “THIRD_LOOPBACK” that matches 2001:DB8:0:11::/64 and
is denied in the route-map called “MY_FILTER”. Last but not least, we apply it inbound on R2. Here’s the
result:
R2#show ipv6 access-list

IPv6 access list THIRD_LOOPBACK
permit ipv6 2001:DB8:0:11::/64 any (1 match) sequence 10
B 2001:DB8:0:111::/64 [20/0]
The access-list tells us that it has a match and you can see it’s gone from the routing table.
Order of Operation
You have now seen how you can use a prefix-list, filter-list and route-map to filter IPv6 prefixes. You can apply
all of these at the same time if you want, I didn’t remove any of my previous configurations when I was writing
this lesson. Take a look at R2:
R2#show run | sec address-family ipv6

Page 140 of 283
address-family ipv6
neighbor 2001:DB8:0:12::1 activate
neighbor 2001:DB8:0:12::1 prefix-list SMALL_NETWORKS in
neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
neighbor 2001:DB8:0:12::1 filter-list 11 in
On a production network you probably won’t use all of these at the same time. The route-map is a popular
choice since you can use it for pretty much anything, filtering and doing things like prepending the AS path.
If you do activate all of these at the same time then you might want to know in what order the router will
process these filtering techniques. Here they are:
Inbound:
 Route-map
 Filter-List
 Prefix-List
Outbound:
 Prefix-List
 Filter-List
 Route-Map
Why do we care about this? Imagine you have an inbound route-map and prefix-list. If you permitted a prefix in
the prefix-list but denied it in the route-map then you will never see the prefix in your BGP table since the
route-map is processed before the prefix-list.
For outbound filtering it’s the other way around. If you permit something in the route-map but denied it in a
filter-list then it will never be advertised…the filter-list is processed before the route-map for outbound updates.
Don’t make it too hard for yourself…it’s best to stick to using the route-map only since you can attach prefix-
lists and as-path access-lists to it.
hostname R1
!
ipv6 unicast-routing
!
ipv6 address 2001:DB8:0:12::1/64
!
interface Loopback0
ipv6 address 2001:DB8:0:1::1/64
!
interface Loopback1
ipv6 address 2001:DB8:0:11::1/64
!
interface Loopback2
ipv6 address 2001:DB8:0:111::1/64
!
interface Loopback3
Page 141 of 283

ipv6 address 2001:DB8:0:1111::1/64
!
router bgp 1
neighbor 2001:DB8:0:12::2 remote-as 2
!
address-family ipv4
neighbor 2001:DB8:0:12::2 route-map PREPEND out
exit-address-family
!
address-family ipv6
network 2001:DB8:0:1::/64
network 2001:DB8:0:11::/64
network 2001:DB8:0:111::/64
network 2001:DB8:0:1111::/96
neighbor 2001:DB8:0:12::2 route-map PREPEND out
exit-address-family
!
ipv6 prefix-list FIRST_LOOPBACK permit 2001:db8:0:1::/64
match ipv6 address prefix-list FIRST_LOOPBACK
set as-path prepend 11
!
end
hostname R2
!
!
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
!
address-family ipv4
no neighbor 2001:DB8:0:12::1 activate
exit-address-family
!
address-family ipv6
neighbor 2001:DB8:0:12::1 prefix-list SMALL_NETWORKS in
neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
neighbor 2001:DB8:0:12::1 filter-list 11 in
exit-address-family
!
ipv6 prefix-list SMALL_NETWORKS permit 2001::/16 le 64
!
ip as-path access-list 11 permit ^1$
!
ipv6 access-list THIRD_LOOPBACK
permit 2001:db8:0:11::/64 any
!
route-map MY_FILTER deny 10
match ipv6 address THIRD_LOOPBACK
Page 142 of 283
route-map MY_FILTER permit 20
!
end
BGP AS Path Filter Example

In this tutorial we’ll take a look at BGP AS path filtering. Using the AS path filter we can permit or deny
prefixes from certain autonomous systems. You can use this for things like:
 Accept only prefixes from directly connected autonomous systems

 Accept only prefixes from directly connected autonomous systems AND one autonomous system behind
the first one.
 Deny certain transit autonomous systems
 And more
To create rules like the examples above we need a flexible way so that we can “match” on certain autonomous
systems. This can be done with regular expressions. If you have no clue how regular expressions work then
please read my regexp tutorial first.
Having said that, let’s look at some examples. I will use a BGP looking glass server for this.
A looking glass server is a router on the Internet that has a (full) internet routing table. You can use telnet to one
and use show commands to view the BGP table. It’s a great way to practice regular expressions since there’s
plenty of prefixes to play with.
You can find a looking glass server on BGP4.as, I picked one that is close to me:
route-server.tinet.net
Once I connect to it through telnet this is what I see:
+--------------------------------------------------------------------+
| |
| GTT Route Monitor - AS3257 |
| |
| This system is solely for internet operational purposes. Any |
| misuse is strictly prohibited. All connections to this router |
| are logged. |
| |
| This server provides a view on the Tinet legacy routing table |
| that is used in Frankfurt/Germany. If you are interested in |
| other regions of the backbone check out http://www.as3257.net/ |
| |
| Please report problems to noc@gtt.net |
| |
+--------------------------------------------------------------------+
route-server.as3257.net>
Let’s see what we find in the BGP table:
Page 143 of 283

route-server.as3257.net>show ip bgp
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

*> 1.0.0.0/24 213.200.64.93 0 0 3257 15169 i
*> 1.0.4.0/24 213.200.64.93 0 0 3257 6453 7545 56203 i
*> 1.0.5.0/24 213.200.64.93 0 0 3257 6453 7545 56203 i
*> 1.0.6.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
*> 1.0.7.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
*> 1.0.20.0/23 213.200.64.93 1551 0 3257 2516 2519 i
*> 1.0.22.0/23 213.200.64.93 1551 0 3257 2516 2519 i
*> 1.0.24.0/23 213.200.64.93 1551 0 3257 2516 2519 i
*> 1.0.26.0/23 213.200.64.93 1551 0 3257 2516 2519 i
*> 1.0.28.0/22 213.200.64.93 1551 0 3257 2516 2519 i
*> 1.0.38.0/24 213.200.64.93 815 0 3257 9304 24155 i
*> 1.0.41.0/24 213.200.64.93 815 0 3257 9304 24155 i
*> 1.0.43.0/24 213.200.64.93 815 0 3257 9304 24155 i
*> 1.0.46.0/24 213.200.64.93 815 0 3257 9304 24155 i
*> 1.0.48.0/24 213.200.64.93 815 0 3257 9304 24155 i
*> 1.0.64.0/18 213.200.64.93 1551 0 3257 2516 7670 18144 i
*> 1.0.128.0/18 213.200.64.93 0 0 3257 174 38040 9737 i
*> 1.0.128.0/17 213.200.64.93 0 0 3257 38040 9737 9737 i
*> 1.0.129.0/24 213.200.64.93 0 0 3257 4651 9737 9737 23969 i
*> 1.0.130.0/24 213.200.64.93 0 0 3257 6453 4651 9737 9737
9737 23969 i
*> 1.0.131.0/24 213.200.64.93 0 0 3257 6453 4651 9737 9737
9737 23969 i
*> 1.0.142.0/23 213.200.64.93 0 0 3257 6453 4651 9737 9737
9737 23969 i
*> 1.0.160.0/19 213.200.64.93 18 0 3257 2914 38040 9737 i
*> 1.0.192.0/21 213.200.64.93 0 0 3257 6453 4651 9737 9737
9737 23969 i
Plenty of prefixes to play with…let’s try a couple of examples now shall we?
Only allow prefixes that originated from AS 3257

This example will only accept prefixes that originated in AS 3257, all the other prefixes won’t be permitted:
route-server.as3257.net>show ip bgp regexp ^3257$


*> 2.16.0.0/23 213.200.64.93 154 0 3257 i
*> 2.16.4.0/24 213.200.64.93 230 0 3257 i
*> 2.16.5.0/24 213.200.64.93 230 0 3257 i
*> 2.16.34.0/24 213.200.64.93 80 0 3257 i
Let me explain the regular expression that I used here. The ^ symbol means that this is the beginning of the
string and the $ matches the end of the string. We put 3257 in between so only “3257” matches. If you want to
configure this filter on a Cisco IOS router you can do this with the as-path access-list command:
Page 144 of 283

ip as-path access-list 1 permit ^3257$
route-map AS_PATH_FILTER permit 10

match as-path 1
router bgp 1
neighbor 213.200.64.93 route-map AS_PATH_FILTER in
The as-path access-list works like the normal access-lists, there is a hidden “deny any” at the bottom. First we
create the as-path access-list and then attach it to a route-map. In the BGP configuration you can attach the
route-map to one of your BGP neighbors.
Let’s look at another example…
Only allow networks that passed through AS 3257

We only want to see prefixes that passed through AS 3257, here’s how:
route-server.as3257.net>show ip bgp regexp _3257_


*> 1.0.0.0/24 213.200.64.93 0 0 3257 15169 i
*> 1.0.4.0/24 213.200.64.93 0 0 3257 6453 7545 56203 i
*> 1.0.5.0/24 213.200.64.93 0 0 3257 6453 7545 56203 i
*> 1.0.6.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
*> 1.0.7.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
*> 1.0.20.0/23 213.200.64.93 1551 0 3257 2516 2519 i
The regular expression starts and ends with a _ . This matches the space between the AS path numbers. I’m not
using a ^or $ to indicate the start and end of the string so there can be as many autonomous systems as we want,
as long as it passed through AS 3257 it will match. Here’s what it looks like on a router:
ip as-path access-list 1 permit _3257_

match as-path 1
router bgp 1
I got a few more examples…
Deny prefixes that originated from AS 56203 and permit everything

else
This one might be useful if you want to block prefixes that originated in a particular AS:
[teaser]
Page 145 of 283
route-server.as3257.net>show ip bgp regexp _56203$

*> 1.0.4.0/24 213.200.64.93 0 0 3257 6453 7545 56203 i
*> 1.0.5.0/24 213.200.64.93 0 0 3257 6453 7545 56203 i
*> 1.0.6.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
*> 1.0.7.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
*> 103.2.178.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
*> 103.2.179.0/24 213.200.64.93 0 0 3257 174 4826 38803 56203 i
The first AS is always on the right side, so in order to match this we end the string with a $ and put the AS
number just in front of it. The _ will match the space in front of the AS number. On a router it will look like
this:
ip as-path access-list 1 deny _56203$

ip as-path access-list 1 permit .*

match as-path 1
router bgp 1
First we use a deny statement to block the AS number and then we use a permit .* to allow everything else. The
. (dot) matches anything and the * (wildcard) means “repeat the previous character zero or many times”. This
will permit everything.
The next one is a bit more complicated…
Allow prefixes from AS 3257 and its directly connected ASes but deny
the rest
This one lets us accept all prefixes from AS 3257 and the directly connected autonomous systems of AS 3257:
route-server.as3257.net>show ip bgp regexp ^3257_[0-9]*$


*> 1.0.0.0/24 213.200.64.93 0 0 3257 15169 i
*> 1.1.1.0/24 213.200.64.93 0 0 3257 15169 i
*> 1.2.3.0/24 213.200.64.93 0 0 3257 15169 i
*> 1.9.0.0/16 213.200.64.93 135 0 3257 4788 i
*> 1.9.52.0/24 213.200.64.93 170 0 3257 4788 ?
We start with the ^3257 so that we only accept prefixes from AS 3257. The _ will match on the space and the
[0-9] will match on any character between 0 and 9. The * means that we repeat the last character (0-9). This
Page 146 of 283

means that AS1 would match, but also AS123 or AS12345, etc. The $ at the end will make sure that only 1
autonomous system behind AS 3257 is allowed.
Here’s what this one looks like on a router:
ip as-path access-list 1 permit ^3257_[0-9]*$

match as-path 1
router bgp 1
BGP Extended Access-List Filtering

Nowadays we use prefix-lists to filter BGP prefixes. Prefix-lists are very convenient since they allow you to
specify a network address with a specific prefix length or a range of prefix lengths. Back in the days, before
prefix-lists existed on Cisco IOS you had to use extended access-lists for this.
You really don’t want to use these anymore since the prefix-list does the same thing and the configuration is
much easier. However, when you face a CCIE lab it might be possible that a task requires you to filter certain
prefixes but you are not allowed to use the prefix-list. The extended access-list will be your only option then…
Having said that, let’s take a look how extended access-list filtering works. The “behavior” of the extended
access-list is different compared to when you use it for filtering IP packets.
When you use IP as the protocol, here’s what the extended access-list normally looks like:
Above you see the source address with the source wildcard bits and the destination address with destination
wildcard bits. Now forget what you have seen above, this is how the extended access-list works for BGP
filtering:
Let me explain these fields:
 The first field is for the network address, for example 10.0.0.0.
 The second field is used to define what part of the network address to check. For example, when we specify
10.0.0.0 then we use wildcard bits to tell the router if we want to look for 10.0.0.0, 10.0.0.x, 10.0.x.x or 10.x.x.x.
 The subnet mask and its wildcard bits are used to define the prefix length, we can use this to tell the router to
look for /24, /25, /26 or a range like /24 to /32.
Page 147 of 283

Using the extended access-list for BGP filtering is something that is best explained with some examples. I’ll use
two routers and some prefixes and we’ll walk through some different filtering examples.
Configuration
I will use the following two routers for this:
R2 has a bunch of loopback interfaces with different networks, we’ll use these to play with filtering.
Here’s what R2 advertises to R1:

Filter

*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 0.0.0.0 0 32768 i
*> 30.0.0.0 0.0.0.0 0 32768 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
*> 172.16.7.0/29 0.0.0.0 0 32768 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
Page 148 of 283
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
Let’s start with some simple examples…
Filter specific prefixes
Let’s say that we to filter some specific prefixes, let’s pick:
 20.0.0.0 /8
 172.16.0.0 /24
 192.168.1.0 /24
Here’s what the access-list will look like:
R1(config)#access-list 100 permit ip 20.0.0.0 0.0.0.0 255.0.0.0 0.0.0.0

R1(config-router)#distribute-list 100 in
R1#clear ip bgp *
Before we check the result, let me explain the access-list:
 In the first entry we want an exact match for “20.0.0.0” so we use network 20.0.0.0 with wildcard 0.0.0.0. The
prefix-length has to be exactly /8 so we use subnet mask 255.0.0.0 with wildcard 0.0.0.0.
 In the second entry we want an exact match for “172.16.0.0” so we use network 172.16.0.0 with wildcard
0.0.0.0. The prefix-length has to be exactly /24 so we use subnet mask 255.255.255.0 with wildcard 0.0.0.0.
 In the last entry we want an exact match for “192.168.1.0” so we use network 192.168.1.0 with wildcard 0.0.0.0.
The prefix-length has to be exactly /24 so we use subnet mask 255.255.255.0 with wildcard 0.0.0.0.
Let’s see what we get:
R1#show ip bgp
Filter

r> 20.0.0.0 192.168.12.2 0 0 2 i
r> 172.16.0.0/24 192.168.12.2 0 0 2 i
r> 192.168.1.0 192.168.12.2 0 0 2 i
Page 149 of 283

Great, we only see our three specific prefixes.
In my BGP table, you can see R1 is unable to install these prefixes because of a RIB-failure. This seems to occur because
the router refuses to use the next hop IP address unless you permit it. I couldn’t find anything about this in the Cisco
documentation but you can solve it by adding this statement to access-list 100: permit ip host 192.168.12.2
any
One little “extra” that the access-list offers us that the prefix-list doesn’t is that it shows matches:
R1#show access-lists 100

Extended IP access list 100
10 permit ip host 20.0.0.0 host 255.0.0.0 (2 matches)
20 permit ip host 172.16.0.0 host 255.255.255.0 (1 match)
30 permit ip host 192.168.1.0 host 255.255.255.0 (2 matches)
Let’s try something else now!
Filter all 192.168.x.0 networks with a /24 prefix length
Let’s say that we want to filter all networks in the 192.168.x.0 range that have a /24 prefix length. R2 is
currently advertising these networks:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 192.168.

*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
We only want to see 192.168.0.0 /24, 192.168.1.0 /24 and 192.168.12.0 /24 on R1. Here’s the access-list we
will create:
R1#clear ip bgp *
Let me explain the access-list:
 The network address we want to check is 192.168.0.0.

 The wildcard is 0.0.255.0 which means the 1st, 2nd and 4th octet have to match. We don’t care about the 3rd
octet.
 The subnet mask is 255.255.255.0 and this has to match exactly which is why we use a 0.0.0.0 wildcard.
Page 150 of 283
Here’s the result:
R1#show ip bgp
Filter

r> 192.168.0.0 192.168.12.2 0 0 2 i
r> 192.168.1.0 192.168.12.2 0 0 2 i
r> 192.168.12.0 192.168.12.2 0 0 2 i
Great, these are the only 192.168.x.0 /24 networks that we have. Time for the next example…
Filter all 10.x.x.0 networks with a /24 prefix length
This one is similar to the previous example but this time we check the 10.x.x.0 range. Here are the networks that
R2 is advertising:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 10.

*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
Let’s build an access-list:
R1#clear ip bgp *
 The network we want to check is 10.0.0.0 but we only care about the 1st and 4th octet, the 2nd and 3rd octet
can be everything so we use wildcard 0.255.255.0.
 We want all networks with a /24 prefix length so we use 255.255.255.0 as the subnet mask. This has to be an
exact match so we use 0.0.0.0 as the wildcard.
Here’s what we get:
R1#show ip bgp
Page 151 of 283

Filter

r> 10.0.0.0/24 192.168.12.2 0 0 2 i
r> 10.1.0.0/24 192.168.12.2 0 0 2 i
r> 10.2.0.0/24 192.168.12.2 0 0 2 i
r> 10.8.1.0/24 192.168.12.2 0 0 2 i
r> 10.8.2.0/24 192.168.12.2 0 0 2 i
Great, these are all networks in the 10.x.x.0 range with a /24 prefix length. Let’s try something else…
Filter all 10.x.x.x networks with a /25 prefix length
This time I want to see all networks in the 10.x.x.x range with a /25 prefix length. Here are all 10.x.x.x networks
that R2 is advertising again:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 10.

*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
Here’s the access-list:
R1#clear ip bgp *
 We want to check the 10.0.0.0 network but we don’t care about the 2nd, 3th or 4th octet. That’s why we use a
0.255.255.255 wildcard.
 The subnet mask is 255.255.255.128 which equals /25. It has to be an exact match so we use wildcard 0.0.0.0.
Here’s what you will find:
R1#show ip bgp
Page 152 of 283

Filter

r> 10.3.0.0/25 192.168.12.2 0 0 2 i
r> 10.3.0.128/25 192.168.12.2 0 0 2 i
r> 10.4.0.0/25 192.168.12.2 0 0 2 i
r> 10.4.0.128/25 192.168.12.2 0 0 2 i
Excellent, these are all 10.x.x.x networks with a /25 prefix length.
Filter all 192.168.7.x networks with any prefix length
This example will be a bit different. This time I want to filter all networks that start with 192.168.7.x but I don’t
care about the prefix length. We are talking about the following prefixes:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | incl 192.168.7

*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
Here’s the access-list:
R1#clear ip bgp *
Let me walk you through the access-list:
 We are looking for network 192.168.7.0 but we only want to check the first three octets, that’s why we use
wildcard 0.0.0.255.
 We don’t care about the prefix length, it should be at least a /24 since we are looking at the 192.168.7.x range
but it doesn’t matter if it’s a /25, /26, etc. This is why we use subnet mask 255.255.255.0 with wildcard
0.0.0.255. It means that we don’t care about the prefix length in the 4th octet.
Here’s the result:
R1#show ip bgp
Filter

r> 192.168.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.7.8/29 192.168.12.2 0 0 2 i
r> 192.168.7.16/29 192.168.12.2 0 0 2 i
r> 192.168.7.24/30 192.168.12.2 0 0 2 i
Page 153 of 283
R1 will only have these networks in its BGP table now, everything else will be filtered.
Filter anything with a /24 to /32 prefix length
Time for something different, we don’t care about the network address but we only want to see networks with a
prefix length between /24 and /32. Let’s take a look again what R2 is advertising to us:

Filter

*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 0.0.0.0 0 32768 i
*> 30.0.0.0 0.0.0.0 0 32768 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
*> 172.16.7.0/29 0.0.0.0 0 32768 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
We have a big list with prefixes, most of them have a prefix length that is larger than /24. We do have 20.0.0.0
/8 and 30.0.0.0 /8 that will be gone when we create this filter. Time to find out:[teaser]

Page 154 of 283
R1#clear ip bgp *
Here’s how the access-list works:
 We don’t care about the network so the network address is 0.0.0.0 with wildcard 255.255.255.255.
 We want all prefixes with a prefix length of at least /24, that’s why we pick a subnet mask of 255.255.255.0 and
a wildcard of 0.0.0.255. This means we don’t care about the 4th octet so it will match everything from /24 to
/32.
Let’s find out if it works:
R1#show ip bgp
Filter

r> 10.0.0.0/24 192.168.12.2 0 0 2 i
r> 10.1.0.0/24 192.168.12.2 0 0 2 i
r> 10.2.0.0/24 192.168.12.2 0 0 2 i
r> 10.3.0.0/25 192.168.12.2 0 0 2 i
r> 10.3.0.128/25 192.168.12.2 0 0 2 i
r> 10.4.0.0/25 192.168.12.2 0 0 2 i
r> 10.4.0.128/25 192.168.12.2 0 0 2 i
r> 10.5.0.0/26 192.168.12.2 0 0 2 i
r> 10.6.0.0/27 192.168.12.2 0 0 2 i
r> 10.7.0.0/28 192.168.12.2 0 0 2 i
r> 10.8.1.0/24 192.168.12.2 0 0 2 i
r> 10.8.2.0/24 192.168.12.2 0 0 2 i
r> 172.16.0.0/24 192.168.12.2 0 0 2 i
r> 172.16.1.0/24 192.168.12.2 0 0 2 i
r> 172.16.2.0/25 192.168.12.2 0 0 2 i
r> 172.16.3.0/25 192.168.12.2 0 0 2 i
r> 172.16.4.0/26 192.168.12.2 0 0 2 i
r> 172.16.5.0/27 192.168.12.2 0 0 2 i
r> 172.16.6.0/28 192.168.12.2 0 0 2 i
r> 172.16.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.0.0 192.168.12.2 0 0 2 i
r> 192.168.1.0 192.168.12.2 0 0 2 i
r> 192.168.2.0/25 192.168.12.2 0 0 2 i
r> 192.168.3.0/25 192.168.12.2 0 0 2 i
r> 192.168.4.0/26 192.168.12.2 0 0 2 i
r> 192.168.5.0/27 192.168.12.2 0 0 2 i
r> 192.168.6.0/28 192.168.12.2 0 0 2 i
r> 192.168.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.7.8/29 192.168.12.2 0 0 2 i
r> 192.168.7.16/29 192.168.12.2 0 0 2 i
r> 192.168.7.24/30 192.168.12.2 0 0 2 i
r> 192.168.12.0 192.168.12.2 0 0 2 i
Page 155 of 283

Our 20.0.0.0 /8 and 30.0.0.0 /8 prefixes are now gone from the BGP table, everything you see above has at least
a /24 prefix length.
Filter anything with a /26 to /32 prefix length
This example is exactly the same as the previous example but this time the prefix length has to be at least a /26.
Here’s the list with advertised prefixes from R2 again:

Filter

*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 0.0.0.0 0 32768 i
*> 30.0.0.0 0.0.0.0 0 32768 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
*> 172.16.7.0/29 0.0.0.0 0 32768 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
Time to clean up that BGP table. Here’s the access-list we need:
Page 156 of 283

R1#clear ip bgp *
 We don’t care about the network address so we use 0.0.0.0 as the network address with wildcard
255.255.255.255.
 The prefix length has to be at least /26, that’s a 255.255.255.192 subnet mask.
 We want to match all prefixes from /26 to /32, by using this wildcard we tell the router that the last four bits
have to match, we don’t care about the first four bits. This will match subnet mask 255.255.255.192,
255.255.255.224, 255.255.255.240, 255.255.255.248, 255.255.255.252, 255.255.255.254 and 255.255.255.255
(everything from /26 to /32).
Here’s the end result:
R1#show ip bgp
Filter

r> 10.5.0.0/26 192.168.12.2 0 0 2 i
r> 10.6.0.0/27 192.168.12.2 0 0 2 i
r> 10.7.0.0/28 192.168.12.2 0 0 2 i
r> 172.16.4.0/26 192.168.12.2 0 0 2 i
r> 172.16.5.0/27 192.168.12.2 0 0 2 i
r> 172.16.6.0/28 192.168.12.2 0 0 2 i
r> 172.16.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.4.0/26 192.168.12.2 0 0 2 i
r> 192.168.5.0/27 192.168.12.2 0 0 2 i
r> 192.168.6.0/28 192.168.12.2 0 0 2 i
r> 192.168.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.7.8/29 192.168.12.2 0 0 2 i
r> 192.168.7.16/29 192.168.12.2 0 0 2 i
r> 192.168.7.24/30 192.168.12.2 0 0 2 i
Above you can see that all prefixes below /26 have disappeared.
Filter 172.16.0.0 networks with a /27 to /32 prefix length
This example will be similar to the previous one with the exception that we will check a specific network range.
Here are all networks in the 172.16.x.x range that R2 offers us:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 172.16.

*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
Page 157 of 283
*> 172.16.7.0/29 0.0.0.0 0 32768 i
Let’s see if we can filter these…
R1(config)#$access-list 107 permit ip 172.16.0.0 0.0.255.255 255.255.255.224 0.0.0.31
R1#clear ip bgp *
 We want to check network 172.16.0.0 but we don’t care about the 3rd or 4th octet so we use wildcard
0.0.255.255.
 The prefix length should be at least /27 so we use a subnet mask of 255.255.255.224.
 We want to match all subnet masks from /27 to /32 so we use a wildcard of 0.0.0.31. This means the first three
octets have to match and the last four bits of the 4th octet. This will allow subnet mask 255.255.255.192,
255.255.255.224, 255.255.255.240, 255.255.255.248, 255.255.255.252, 255.255.255.254 and 255.255.255.255.
Here’s the end result:
R1#show ip bgp
Filter

r> 172.16.5.0/27 192.168.12.2 0 0 2 i
r> 172.16.6.0/28 192.168.12.2 0 0 2 i
r> 172.16.7.0/29 192.168.12.2 0 0 2 i
Great, we only have a few 172.16.x.x networks with a /27 prefix length or larger.
Conclusion
You have now seen quite some examples of how you can use BGP filtering with extended access-lists. This can
be pretty annoying and it’s much easier to use prefix-lists instead. However if you are not allowed to use them,
you now know how to filter with extended access-lists.
hostname R1
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
router bgp 1
Page 158 of 283
distribute-list 107 in
!
access-list 100 permit ip host 20.0.0.0 host 255.0.0.0
access-list 101 permit ip 192.168.0.0 0.0.255.0 host 255.255.255.0
access-list 104 permit ip 192.168.7.0 0.0.0.255 255.255.255.0 0.0.0.255
access-list 105 permit ip any 255.255.255.0 0.0.0.255
access-list 106 permit ip any 255.255.255.192 0.0.0.63
access-list 107 permit ip 172.16.0.0 0.0.255.255 255.255.255.224 0.0.0.31
!
end
hostname R2
!
interface Loopback0
ip address 10.0.0.1 255.255.255.0
!
interface Loopback1
ip address 10.1.0.1 255.255.255.0
!
interface Loopback2
ip address 10.2.0.1 255.255.255.0
!
interface Loopback3
ip address 10.3.0.1 255.255.255.128
!
interface Loopback4
ip address 10.3.0.129 255.255.255.128
!
interface Loopback5
ip address 10.4.0.1 255.255.255.128
!
interface Loopback6
ip address 10.4.0.129 255.255.255.128
!
interface Loopback7
ip address 10.5.0.1 255.255.255.192
!
interface Loopback8
ip address 10.6.0.1 255.255.255.224
!
interface Loopback9
ip address 10.7.0.1 255.255.255.240
!
interface Loopback10
ip address 10.8.1.1 255.255.255.0
!
ip address 10.8.2.1 255.255.255.0
!
ip address 20.0.0.1 255.0.0.0
!
ip address 30.0.0.1 255.0.0.0
!
Page 159 of 283
ip address 172.16.0.1 255.255.255.0
!
ip address 172.16.1.1 255.255.255.0
!
ip address 172.16.2.1 255.255.255.128
!
ip address 172.16.3.1 255.255.255.128
!
ip address 172.16.4.1 255.255.255.192
!
ip address 172.16.5.1 255.255.255.224
!
ip address 172.16.6.1 255.255.255.240
!
ip address 172.16.7.1 255.255.255.248
!
ip address 192.168.0.1 255.255.255.0
!
ip address 192.168.1.1 255.255.255.0
!
ip address 192.168.2.1 255.255.255.128
!
ip address 192.168.3.1 255.255.255.128
!
ip address 192.168.4.1 255.255.255.192
!
ip address 192.168.5.1 255.255.255.224
!
ip address 192.168.6.1 255.255.255.240
!
ip address 192.168.7.1 255.255.255.248
!
ip address 192.168.7.9 255.255.255.248
!
ip address 192.168.7.17 255.255.255.248
!
ip address 192.168.7.25 255.255.255.252
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
Page 160 of 283
!
router bgp 2
network 10.0.0.0 mask 255.255.255.0
network 10.1.0.0 mask 255.255.255.0
network 10.2.0.0 mask 255.255.255.0
network 10.3.0.0 mask 255.255.255.128
network 10.3.0.128 mask 255.255.255.128
network 10.4.0.0 mask 255.255.255.128
network 10.4.0.128 mask 255.255.255.128
network 10.5.0.0 mask 255.255.255.192
network 10.6.0.0 mask 255.255.255.224
network 10.7.0.0 mask 255.255.255.240
network 10.8.0.0 mask 255.255.255.224
network 10.8.1.0 mask 255.255.255.0
network 10.8.2.0 mask 255.255.255.0
network 20.0.0.0
network 30.0.0.0
network 172.16.0.0 mask 255.255.255.0
network 172.16.1.0 mask 255.255.255.0
network 172.16.2.0 mask 255.255.255.128
network 172.16.3.0 mask 255.255.255.128
network 172.16.4.0 mask 255.255.255.192
network 172.16.5.0 mask 255.255.255.224
network 172.16.6.0 mask 255.255.255.240
network 172.16.7.0 mask 255.255.255.248
network 192.168.0.0
network 192.168.1.0
network 192.168.2.0 mask 255.255.255.128
network 192.168.3.0 mask 255.255.255.128
network 192.168.4.0 mask 255.255.255.192
network 192.168.5.0 mask 255.255.255.224
network 192.168.6.0 mask 255.255.255.240
network 192.168.7.0 mask 255.255.255.248
network 192.168.7.8 mask 255.255.255.248
network 192.168.7.16 mask 255.255.255.248
network 192.168.7.24 mask 255.255.255.252
network 192.168.12.0
!
end
BGP Peer Groups on Cisco IOS

When you configure BGP on a router it’s possible that some of the BGP neighbors share the exact same
configuration. This can be annoying since you have to type in the exact same commands for each of these
neighbors. Also, when BGP prepares updates it does this separately for each neighbor. This means that it has to
use CPU resources to prepare the update for each neighbor.
To simplify the configuration of BGP and to reduce the number of updates BGP has to create, we can use peer
groups. We can add neighbors to a peer group and then apply all our configurations to the peer group. BGP will
prepare the updates for the peer group which requires less CPU resources than preparing them for each neighbor
separately.
Configuration
Page 161 of 283
Let’s take a look at two examples so you can see the difference between using peer groups or not. I’ll use the
following topology to demonstrate this:
Above we have 4 routers in different autonomous systems. R1 is connected to R2, R3 and R4. Let’s say that we
have the following requirements for these eBGP neighbors:
 Use eBGP multihop and source updates from the loopback interface.
 Set the default metric (MED) to 2323.
Let’s start with the example without the peer group…
I am using loopback interfaces for the neighbor adjacency so don’t forget to add some static routes:
R1(config)#ip route 2.2.2.2 255.255.255.255 192.168.12.2

R1(config)#ip route 3.3.3.3 255.255.255.255 192.168.13.3
R1(config)#ip route 4.4.4.4 255.255.255.255 192.168.14.4
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
R3(config)#ip route 1.1.1.1 255.255.255.255 192.168.13.1
R4(config)#ip route 1.1.1.1 255.255.255.255 192.168.14.1
And here s the route-map to set the MED:
R1(config)#route-map SET_MED permit 10

Without BGP Peer Group
Here’s what our BGP configuration on R1 would look like:
Page 162 of 283

R1(config-router)#neighbor 2.2.2.2 route-map SET_MED out
In the configuration of R1 above the only difference is the AS number for each neighbor. The update-source,
ebgp-multihop and route-map are the same. This works but we have to repeat the same commands over and
over again.
With BGP Peer Group
Let’s simplify the configuration of R1 with our peer group. I will start with a fresh BGP configuration on R1.
First we have to configure the AS number for each eBGP neighbor separately:
Now we can create the peer group. If you look at the neighbor command you will see some options:
R1(config-router)#neighbor ?
A.B.C.D Neighbor address
WORD Neighbor tag
X:X:X:X::X Neighbor IPv6 address
We can specify an IPv4 or IPv6 address for the neighbor or we can use a tag. That’s what we need to use for the
peer group, let’s try that:[teaser]
R1(config-router)#neighbor R2_R3_R4 peer-group
I’ll call my peer group R2_R3_R4. The next step is to add my neighbors to this peer group:
R1(config-router)#neighbor 2.2.2.2 peer-group R2_R3_R4

That’s all you have to configure. Everything else you want to configure can be applied to the peer group instead
of applying it to the neighbor directly:
R1(config-router)#neighbor R2_R3_R4 update-source loopback 0

R1(config-router)#neighbor R2_R3_R4 ebgp-multihop 2
R1(config-router)#neighbor R2_R3_R4 route-map SET_MED out
Page 163 of 283

That’s all there is to it. These three commands are now applied to R2, R3 and R4 thanks to our peer group. This
saves us some typing and copy/pasting and the router will require less CPU cycles for its BGP updates.
hostname R1
!
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
ip address 192.168.14.1 255.255.255.0
!
router bgp 1
neighbor R2_R3_R4 peer-group
neighbor 2.2.2.2 peer-group R2_R3_R4
neighbor R2_R3_R4 update-source loopback 0
neighbor R2_R3_R4 ebgp-multihop 2
neighbor R2_R3_R4 route-map SET_MED out
!
route-map SET_MED permit 10
set metric 2323
end
hostname R2
!
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
!
end
hostname R3
!
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.13.3 255.255.255.0
!
router bgp 3
Page 164 of 283
!
end
hostname R4
!
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.14.4 255.255.255.0
!
router bgp 4
!
end
BGP Route Reflector

Route reflectors (RR) are one method to get rid of the full-mesh of IBGP peers in your network. The other
method is BGP confederations.
The route reflector allows all IBGP speakers within your autonomous network to learn about the available
routes without introducing loops. Let me show you an example picture:
Above we have a network with 6 IBGP routers. Using the full mesh formula we can calculate the number of
IBGP peerings:
N(N-1)/2
So that will be:
6(6-1=5) / 2 = 15 IBGP peerings.
Page 165 of 283

When we use a route reflector our network could look like this:
We still have 6 routers but each router only has an IBGP peering with the route reflector on top. When one of
those IBGP routes advertises a route to the route reflector, it will be “reflected” to all other IBGP routers:
This simplifies our IBGP configuration a lot but there’s also a downside. What if the route reflector crashes?
It’s a single point of failure when it comes to IBGP peerings. Of course there’s a solution to this, we can have
multiple route reflectors in our network. I’ll give you some examples later.
The route reflector can have three type of peerings:
 EBGP neighbor
 IBGP client neighbor
 IBGP non-client neighbor
Page 166 of 283

When you configure a route reflector you have to tell the router whether the other IBGP router is a client or
non-client. A client is an IBGP router that the route reflector will “reflect” routes to, the non-client is just a
regular IBGP neighbor.
When a route reflector forwards a route, there are a couple of rules:
1. A route learned from an EBGP neighbor can be forwarded to another EBGP neighbor, a client and non-
client.
2. A route learned from a client can be forwarded to another EBGP neighbor, client and non-client.
3. A route learned from a non-client can be forwarded to another EBGP neighbor and client, but not to a
non-client.
The third rule makes sense, this is our normal IBGP split horizon behavior.
Now you have an idea what the route reflector is about, let’s take a look at some configurations.
Configuration
We’ll use a simple example, 3 IBGP routers with a single route reflector:
In this example we have 3 IBGP routers. With normal IBGP rules, when R2 receives a route from R1 it will not
be forwarded to R3 (IBGP split horizon). We will configure R2 as the route reflector to get around this. Let’s
configure R1 and R3 first:

The configuration of R1 and R3 is exactly the same as a normal IBGP peering. Only the configuration on the
route reflector is special:

R2(config-router)#neighbor 192.168.12.1 route-reflector-client

R2(config-router)#neighbor 192.168.23.3 route-reflector-client
Here’s the magic…when we configure the route reflector we have to specify its clients. In this case, R1 and R3.
In my topology I have added a loopback interface on R1, let’s advertise that in BGP to see what it looks like on
R2 and R3:
Page 167 of 283
That’s all we have to configure. Let’s use some show commands to verify our work.
Verification
First we’ll look at R2, see if it learned anything:

Flag: 0x820
1
Local, (Received from a RR-client)
192.168.12.1 from 192.168.12.1 (192.168.12.1)
R2 shows us that this route was received from a route reflector client. Did it advertise anything to R3? Let’s
find out:


*>i1.1.1.1/32 192.168.12.1 0 100 0 i
So what do we see here? Let me explain…
[teaser]
Excellent, the 1.1.1.1/32 route was advertised to R3. Let’s see what R3 thinks of this:

Paths: (1 available, no best path)
Local
192.168.12.1 (inaccessible) from 192.168.23.2 (192.168.23.2)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 192.168.12.1, Cluster list: 192.168.23.2
R3 has learned about this route from R2 and there are two important new fields that you can see here:
 Originator
 Cluster List
This information was added by R2 but for what reason?
Page 168 of 283

The IBGP split horizon rule was created to prevent loops, since our route reflector violates this rule we have to
think of a new rule for loop prevention. That’s where these two items are used for:
The originator ID is set by the route reflector, you can see that this is the IP address of R1. When an IBGP
router receives a route with its own originator ID, it will not accept the route. Just like with OSPF or EIGRP,
it’s important that each BGP router has a unique router ID.
The other thing called Cluster list is the router ID of the route reflector. When we talk about a cluster, we refer
to a route reflector and its clients. Let me give you an example of a larger topology with multiple route
reflectors:
In this topology we have 3 route reflectors, each serves 2 IBGP neighbors. Between the route reflectors we still
have to configure full mesh IBGP. It’s possible that a route loops between these route reflectors so when a
route reflector sees its own cluster ID, it will drop the route.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 123
network 1.1.1.1 mask 255.255.255.255
!
end
Page 169 of 283
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router bgp 123
neighbor 192.168.12.1 route-reflector-client
!
end
hostname R3
!
ip cef
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 123
!
end
BGP Confederation Explained

In this tutorial we’ll take a look at the BGP Confederation. As you might know, IBGP requires a full mesh of
peerings which can become an administrative nightmare. If you don’t know why we need a full mesh, I
recommend to start reading my IBGP tutorial first.
To reduce the number of IBGP peerings there are two techniques:
 Confederations
 Route Reflector
Let’s talk about confederations, look at the picture below:
Page 170 of 283

Above we have AS 1 with 6 routers running IBGP. The number of IBGP peerings can be calculated with the
full mesh formula:
N(N-1)/2
So in our case that’s:
6 * (6-1 = 5) / 2 = 15 IBGP peerings.
A BGP confederation divides our AS into sub-ASes to reduce the number of required IBGP peerings. Within a
sub-AS we still require full-mesh IBGP but between these sub-ASes we use something that looks like EBGP
but behaves like IBGP (called confederation BGP) . Here’s an example of what a BGP confederation could look
like:
By dividing our main AS into two sub-ASes we reduced the number of IBGP peerings from 15 to 8.
Page 171 of 283
Within the sub-AS we still have the full-mesh IBGP requirement. Between sub-ASes it’s just like EBGP, it’s up
to you how many peerings you want. The outside world will never see your sub-AS numbers, they will only see
the main AS number.
Since the sub-AS numbers are not seen outside of your network you will often see private AS numbers used for
the sub-ASes (64512 – 65535) but you can pick any number you like.
You should now have an idea what BGP confederations are like, let’s look at the configuration so I can add
some more details. I’ll use the following topology:
Above we have AS 2 which is divided into two sub-ASes, AS 24 and AS 35. There’s also AS 1 on top that we
can use to see how the outside world sees our confederation.
Let’s look at the configuration shall we?

Page 172 of 283
Configuration
Just like any other IBGP configuration it’s best practice to use loopback interfaces for the BGP sesssions. For
this reason I created a loopback interface on all routers within AS 2 and I’ll use OSPF to advertise them.
OSPF Configuration
Now we can worry about the BGP confederation configuration. I’ll explain all the different steps…
BGP Confederation Configuration
Let’s start with R2:
R2(config-router)#bgp confederation identifier 2
R2(config-router)#bgp confederation peers 35
The configuration of R2 requires some explanation. First of all, when you start the BGP process you have to use
the AS number of the sub-AS. Secondly, you have to use the bgp confederation identifier command to tell
BGP what the main AS number is.
We also have to configure all other sub-AS numbers with the bgp confederation peers command, in this case
that’s only AS 35. R4 is in the same sub-as so you can configure this neighbor just like any other IBGP
neighbor. R3 is a bit different though…since it’s in another sub-AS we have to use the same rules as EBGP, that
means configuring multihop if you are using loopbacks.
Let’s take a look at R3:
Page 173 of 283
The configuration of R3 is similar to R2. We configure it to use AS 35 while the main AS is 2. Our only sub-AS
peer is 24 and we have two neighbors…one IBGP neighbor and one “EBGP” (confederation BGP) neighbor.
R4 and R5 look pretty much the same:
That takes care of configuring the neighbors. The more interesting part is of course using some show commands
to see the differences with normal IBGP and EBGP. Let’s get going…
Verification
To have something we can look at I will create a loopback interface on R5 and advertise a network in BGP:
Let’s advertise it in BGP:
Let’s look at R3 first, this router is in the same sub-AS as R5:
R3#show ip bgp 55.55.55.55

Flag: 0x820
2
Local
5.5.5.5 (metric 2) from 5.5.5.5 (5.5.5.5)
Page 174 of 283

This entry looks pretty much the same as normal IBGP but there’s one important difference…
[teaser]
The route is tagged with confed-internal which means that it came from an IBGP router within the same sub-
AS. Let’s check R2 now:
R2#show ip bgp 55.55.55.55

Flag: 0x820
2
(35)
5.5.5.5 (metric 3) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
BGP confederations use a new BGP attribute called AS_CONFED_SET. This “confederation set” prepends the
list with the sub-ASes. Above you can see (35) which means that this route came from another sub-AS (35).
Prepending occured when R3 sent the update to R2.
When this route is sent to another AS, all the sub-AS numbers will be removed. Let’s see how that works…I
didn’t configure EBGP between R1 and R2 yet so let’s do that now:
Let’s see what R1 in AS 1 thinks of the 55.55.55.55/32 route:
R1#show ip bgp 55.55.55.55

Flag: 0x820
2
192.168.12.2 from 192.168.12.2 (2.2.2.2)
R1 only sees AS 2 so all the sub-AS magic remains within the BGP confederation. Pretty neat right? Let’s try
one more thing…I’ll advertise something on R1 so our confederation can learn about it. I’ll create a loopback
and advertise it in BGP:
There’s one more thing we have to do…since the next hop doesn’t change with BGP, our routers will not know
how to reach 192.168.12.1 (R1). I’ll fix this by advertising the 192.168.12.0 /24 network in BGP:
Page 175 of 283

Now let’s take a look at R2:
R2#show ip bgp 11.11.11.11

Flag: 0x820
1 2
1
192.168.12.1 from 192.168.12.1 (192.168.12.1)
This is just plain EBGP information, nothing special. Let’s look at R4 which is in the same sub-AS:
R4#show ip bgp 11.11.11.11

Flag: 0x820
1
1
192.168.12.1 (metric 2) from 2.2.2.2 (2.2.2.2)
R4 sees the route and recognizes it as “confed-internal”. Let’s check R3 which is a bit more interesting:
R3#show ip bgp 11.11.11.11

1
(24) 1
192.168.12.1 (metric 2) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
R3 is in a different sub-AS than R2, you can see that it says confed-external. Something important to note is that
the next hop IP address didn’t change. When you use regular EBGP, a router changes the next hop IP address
of a route to its own IP address when it sends the route to another EBGP router.
The sub-AS number from R2 has been prepended, the AS path is now (24) 1.
If you have played with BGP and regular expressions before, see if you can create some that match on the sub-AS
values…nice exercise!
Let’s check the last router, R5:
R5#show ip bgp 11.11.11.11

2
(24) 1
192.168.12.1 (metric 3) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, confed-external
(24) 1
Page 176 of 283
192.168.12.1 (metric 3) from 3.3.3.3 (3.3.3.3)
R5 has two options, it learns about this route from R3 (confed-internal) or R4 (confed-external). It selected the
internal path as the best one.
That’s all I have about BGP confederations for now. I hope this has been helpful to you, if you still have any
questions feel free to leave a comment.
hostname R1
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 1
network 11.11.11.11 mask 255.255.255.255
!
end
hostname R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
ip address 192.168.24.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.24.0 0.0.0.255 area 0
!
router bgp 24
Page 177 of 283
network 192.168.12.0
!
end
hostname R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
media-type rj45
!
ip address 192.168.35.3 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
!
router bgp 35
!
end
hostname R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
duplex auto
speed auto
media-type rj45
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
media-type rj45
!
Page 178 of 283
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 24
!
end
hostname R5
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Loopback5
ip address 55.55.55.55 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
media-type rj45
!
ip address 192.168.35.5 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 35
network 55.55.55.55 mask 255.255.255.255
!
end
BGP Synchronization
Page 179 of 283

This tutorial explains the BGP synchronization rule. To understand what this is all about, make sure you
understand why we need IBGP first. If you are a little fuzzy about IBGP, BGP split horizon and why we need
IBGP full mesh adjacencies then please read my IBGP tutorial first. Having said that, let’s look at the
synchronization rule.
BGP synchronization is an old rule from the days where we didn’t run IBGP on all routers within a transit
AS. In short, BGP will not advertise something that it learns from an IBGP neighbor to an EBGP neighbor if the
prefix can’t be validated in its IGP.
It’s best explained with an example, take a look below:
Above we see 5 routers and 3 autonomous systems. When we want to get from R1 to R5 we’ll have to cross
AS2, this makes AS2 our transit AS.
EBGP has been configured between R1/R2 and also between R4/R5. IBGP is configured between R2/R4 and
R3 on top doesn’t run BGP at all.
The routers within AS2 are configured with OSPF, this is required since R2/R4 have to be able to reach each
other to establish the IBGP session.
R1 will advertise a prefix in BGP, AS2 and AS3 will learn about this prefix…
Let me show you the configurations. We’ll use the topology from above but I added some IP addresses to it:
Page 180 of 283

OSPF Configuration
The OSPF configuration is really straight-forward. R2 and R4 have a loopback interface that is used for the
IBGP peering which is advertised in OSPF:
R2#
router ospf 1
network 2.2.2.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
R3#
router ospf 1
network 3.3.3.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
R4#
router ospf 1
network 4.4.4.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
Let me also show you the BGP configuration…
BGP Configuration
The configuration of R1 is simple, it’s configured to run EBGP with R2 and it advertises network 1.1.1.0 /24
into BGP:
R1#
Page 181 of 283
router bgp 1
no synchronization
network 1.1.1.0 mask 255.255.255.0
no auto-summary
R2 runs EBGP with R1 and IBGP with R4:
R2#
router bgp 2
no synchronization
no auto-summary
R4 is similar to R2:
R4#
router bgp 2
no synchronization
no auto-summary
And finally R5, it only runs EBGP with R4:
R5#show run | b router bgp

router bgp 3
no synchronization
no auto-summary
By default, BGP synchronization is disabled. You can see the no synchronization command in the
configurations of the routers above. Let’s take a “before” and “after” look..
BGP synchronization disabled

We’ll take a look at R4 and R5, see if they learned about the 1.1.1.0 /24 network which is advertised on R1 and
forwarded by R2 through IBGP:
R4#show ip bgp

Page 182 of 283
*>i1.1.1.0/24 2.2.2.2 0 100 0 1 i
R4 knows about this prefix and installed it…what about R5?
R5#show ip bgp

*> 1.1.1.0/24 192.168.45.4 0 2 1 i
Great, R5 also knows about this network. The problem in this scenario however is that we will never get any IP
packets from AS3 to AS1 since R3 doesn’t run BGP…it will never learn about network 1.1.1.0 /24 so whenever
R4 forwards something, it will be dropped. Take a look at R3 here:

To synchronization rule was created to prevent this problem. Let’s find out how it works…
BGP synchronization enabled

Let me show you what happens when we enable it, you have to do this on the border routers (R2 and R4):
R2(config-router)#synchronization
R4(config-router)#synchronization
Take a look again at R4:
R4#show ip bgp

* i1.1.1.0/24 2.2.2.2 0 100 0 1 i
R4 sees the network in its BGP table but refuses to install it.
[teaser]
This is because the synchronization rule states that the prefix has to be in its IGP before it can advertise it to an
EBGP neighbor. Since R4 can’t install it, R5 will never learn about it:
R5#show ip bgp
So to fix this, you can either disable synchronization OR redistribute the prefix into your IGP (OSPF in our
case). Let’s do that:
Page 183 of 283
R2(config-router)#redistribute bgp 2 route-map PREFIX subnets
R2(config)#route-map PREFIX permit 10

R2(config-route-map)#match ip address 1
R2(config)#access-list 1 permit 1.1.1.0 0.0.0.255
I am using a route-map to redistribute only this particular prefix, you don’t have to but you don’t want to
accidently redistribute your entire BGP table into OSPF.
Because of the redistribution, R3 knows how to reach network 1.1.1.0 /24:

Known via "ospf 1", distance 110, metric 1
Tag 1, type extern 2, forward metric 1
Last update from 192.168.23.2 on FastEthernet0/0, 00:00:41 ago
* 192.168.23.2, from 2.2.2.2, 00:00:41 ago, via FastEthernet0/0
Route tag 1
According to the BGP synchronization rule, we are now allowed to advertise it to our EBGP neighbor. Take a
look at R4:
R4#show ip bgp

r>i 1.1.1.0/24 2.2.2.2 0 100 0 1 i
R4 selected this one as the best one. the “r” in front is there because this router will install the OSPF (AD 110)
entry for 1.1.1.0 /24 instead of the IBGP (AD 200) route. What about R5?
R5#show ip bgp

*> 1.1.1.0/24 192.168.45.4 0 2 1 i
R5 once again learned the prefix from R4.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
Page 184 of 283
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.0 mask 255.255.255.0
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
redistribute bgp 2 subnets route-map PREFIX
network 2.2.2.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 2
synchronization
!
access-list 1 permit 1.1.1.0 0.0.0.255
!
route-map PREFIX permit 10
match ip address 1
!
end
hostname R3
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 3.3.3.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname R4
!
Page 185 of 283
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
network 4.4.4.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 2
synchronization
!
end
hostname R5
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.0
!
router bgp 3
!
end
BGP Backdoor Routes

When your router learns about a prefix through EBGP and an IGP (RIP, OSPF or EIGRP) then it will always
prefer the external BGP route. EBGP uses an administrative distance of 20 so it’s preferred over OSPF (110),
RIP (120) or EIGRP (90).
This can introduce a problem, let me show you a scenario:
Page 186 of 283

Above you see 3 routers, R1,R2 and R3. Imagine R1 and R2 are two sites from a customer and R3 is the ISP
router.
R1 and R2 have a fast “backdoor” link and OSPF is configured to exchange some prefixes between the two
sites. To illustrate this I have added a loopback interface on these two routers.
R1 and R2 are also configured to use EBGP with R3, they advertise the same prefixes as they do in OSPF. This
introduces a problem:
Above you see that R1 learns about the 2.2.2.2 /32 prefix through BGP (R3) and OSPF (R2). Since EBGP has a
lower (thus better) AD it will install this path in its routing table. The same thing applies to R2 for the 1.1.1.1
/32 prefix.
Let’s take a look at this scenario on our routers, I’ll configure OSPF and BGP and you will learn how to fix this
problem.
OSPF Configuration
Page 187 of 283
First we’ll configure R1 and R2 to run OSPF. I’ll advertise their loopback interfaces:
Nothing special here, just a basic OSPF configuration. Here’s what the routing table of R1 and R2 looks like
now:
R1#show ip route ospf | include 2.2

O 2.2.2.2 [110/2] via 192.168.12.2, 00:00:12, FastEthernet0/0
R2#show ip route ospf | include 1.1
They learned about each others prefixes, great! Our next move is configuring BGP…
BGP Configuration
R1 and R2 will both peer with R3 and I’ll advertise their loopback interfaces in BGP:

Just a plain and simple BGP configuration. Now look again at the routing table of R1 and R2:
R1#show ip route | incl 2.2

B 2.2.2.2 [20/0] via 192.168.13.3, 00:00:45
B 1.1.1.1 [20/0] via 192.168.23.3, 00:01:23
R1 and R2 will now use R3 to reach each others loopback interfaces. This happens because the AD of EBGP is
20 while OSPF has an AD of 110. As a result, OSPF is removed from the routing table. So how do we fix this?
You could change the administrative distance manually but this tutorial is about the “backdoor” feature so let’s
see how it works.
BGP Backdoor Configuration

We have to configure the network that we want to use our “backdoor” for, here’s what it looks like:
R1(config-router)#network 2.2.2.2 mask 255.255.255.255 backdoor

R2(config-router)#network 1.1.1.1 mask 255.255.255.255 backdoor
You use the network command but add the backdoor keyword at the end.
Page 188 of 283

Verification
Let’s see what changed:


Great! Our routers now prefer the OSPF routes again. The prefixes are still in BGP as you can see here:
R1#show ip bgp
Filter

*> 1.1.1.1/32 0.0.0.0 0 32768 i
r> 2.2.2.2/32 192.168.13.3 0 3 2 i
R2#show ip bgp
Filter

r> 1.1.1.1/32 192.168.23.3 0 3 1 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
This is a good thing. When the backdoor link fails we can still use the information from BGP, let’s simulate
that:
[teaser]

Shutting the interface will cause the OSPF adjacency to drop. Here’s what the routing tables look like when that
happens:

B 2.2.2.2 [200/0] via 192.168.13.3, 00:00:28
B 1.1.1.1 [200/0] via 192.168.23.3, 00:00:10
Excellent we now have our BGP information in the routing table. This output also reveals how the backdoor
command really works…if you look closely you can see that it changed the AD from 20 to 200.
hostname R1
Page 189 of 283

!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
router bgp 1
network 1.1.1.1 mask 255.255.255.255
network 2.2.2.2 mask 255.255.255.255 backdoor
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
network 2.2.2.2 0.0.0.0 area 0
!
router bgp 2
network 2.2.2.2 mask 255.255.255.255
network 1.1.1.1 mask 255.255.255.255 backdoor
!
end
hostname R3
!
ip cef
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 3
Page 190 of 283
!
end
Multiprotocol BGP (MP-BGP) Configuration

The normal version of BGP (Border Gateway Protocol) only supported IPv4 unicast prefixes. Nowadays we use
MP-BGP (Multiprotocol BGP) which supports different addresses:
 IPv4 unicast
 IPv4 multicast
 IPv6 unicast
 IPv6 multicast
MP-BGP is also used for MPLS VPN where we use MP-BGP to exchange the VPN labels. For each different
“address” type, MP-BGP uses a different address family.
To allow these new addresses, MBGP has some new features that the old BGP doesn’t have:
 Address Family Identifier (AFI): specifies the address family.

 Subsequent Address Family Identifier (SAFI): Has additional information for some address families.
 Multiprotocol Reachable Network Layer Reachability Information (MP_UNREACH_NLRI): This is an attribute
used to transport networks that are unreachable.
 BGP Capabilities Advertisement: This is used by a BGP router to announce to the other BGP router what
capabilities it supports. MP-BGP and BGP-4 are compatible, the BGP-4 router can ignore the messages that it
doesn’t understand.
Since MP-BGP supports IPv4 and IPv6 we have a couple of options. MP-BGP routers can become neighbors
using IPv4 addresses and exchange IPv6 prefixes or the other way around. Let’s take a look at some
configuration examples…
Configuration
MP-BGP with IPv6 adjacency & IPv6 prefixes
Let’s start with a simple example where we use IPv6 for the neighbor adjacency and exchange some IPv6
prefixes. Here’s the topology I will use:
Page 191 of 283

Here’s the configuration of R1:
R1(config-router-af)#no neighbor 2001:db8:0:12::2 activate
R1(config-router-af)#exit
R1(config-router-af)#network 2001:db8::1/128
In the configuration above we first specify the remote neighbor. The address-family command is used to change
the IPv4 or IPv6 settings. I disable the IPv4 address-family and enabled IPv6. Last but not least, we advertised
the prefix on the loopback interface. The configuration of R2 looks similar:
R2(config-router-af)#no neighbor 2001:db8:0:12::1 activate
R2(config-router-af)#exit
After awhile the neighbor adjacency will appear:
R1#
%BGP-5-ADJCHANGE: neighbor 2001:DB8:0:123::2 Up
Now let’s check the routing tables:
R1#show ipv6 route bgp

IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
B 2001:DB8::2/128 [20/0]
via FE80::217:5AFF:FEED:7AF0, FastEthernet0/0
R2#show ipv6 route bgp
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
B 2001:DB8::1/128 [20/0]
The routers learned each others prefixes…great! This example was pretty straight-forward but you have now
learned how MP-BGP uses different address families.
Page 192 of 283
hostname R1
!
ipv6 enable
ipv6 address 2001:DB8::1/128
!
ipv6 enable
ipv6 address 2001:DB8:0:12::1/64
!
router bgp 1
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8::1/128
exit-address-family
!
end
hostname R2
!
ipv6 enable
!
ipv6 enable
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8::2/128
exit-address-family
!
end
MP-BGP with IPv4 adjacency & IPv6 prefixes
let’s look at a more complex example, the routers will become neighbors through IPv4 but will exchange IPv6
prefixes. I’ll use the same topology but with an IPv4 subnet in between:
Page 193 of 283

Here’s the configuration:
Now we can configure the address-family for IPv6 unicast:
R1(config-router-af)#neighbor 192.168.12.2 activate
R2(config-router-af)#neighbor 192.168.12.1 activate
Once we enter the address-family IPv6 configuration there are two things we have to configure. The prefix has
to be advertised and we need to specify the neighbor. The prefixes on the loopback interface should now be
advertised. Let’s check it out:
R1#show ip bgp ipv6 unicast

Filter

*> 2001:DB8::1/128 :: 0 32768 i
* 2001:DB8::2/128 ::FFFF:192.168.12.2
0 0 2 i
R2#show ip bgp ipv6 unicast
Filter

* 2001:DB8::1/128 ::FFFF:192.168.12.1
0 0 1 i
*> 2001:DB8::2/128 :: 0 32768 i
Page 194 of 283

As you can see the routers have learned about each others prefixes. There’s one problem though…we were able
to exchange IPv6 prefixes but we only use IPv4 between R1 and R2, there is no valid next hop address that we
can use.
To fix this, we need to use some IPv6 addresses that we can use as the next hop. We’ll have to configure a
prefix between R1 and R2 for this:[teaser]

R1(config-if)#ipv6 address 2001:db8:0:12::1/64
R2(config-if)#ipv6 address 2001:db8:0:12::2/64
Now we have IPv6 addresses that we can use as the next hop. We are using IPv4 for the neighbor peering so the
next hop doesn’t change automatically. We’ll have to use a route-map for this:
R1(config)#route-map IPV6_NEXT_HOP permit 10

R1(config-route-map)#set ipv6 next-hop 2001:db8:0:12::2
R1(config-router-af)#neighbor 192.168.12.2 route-map IPV6_NEXT_HOP in
R2(config)#route-map IPV6_NEXT_HOP permit 10
R2(config-route-map)#set ipv6 next-hop 2001:db8:0:12::1
R2(config-router-af)#neighbor 192.168.12.1 route-map IPV6_NEXT_HOP in
Both routers now change the next hop IPv6 address of incoming prefixes. Let’s reset BGP:
R1#clear ip bgp *
Take a look now:
R1#show ip bgp ipv6 unicast | begin 2001

*> 2001:DB8::1/128 :: 0 32768 i
*> 2001:DB8::2/128 2001:DB8:0:12::2
R2#show ip bgp ipv6 unicast | begin 2001
*> 2001:DB8::1/128 2001:DB8:0:12::1
The next hop IPv6 addresses are now reachable so they can be installed in the routing table. The downside of
this solution is that we had to fix the next hop ourselves, the advantage however is that we have a single BGP
neighbor adjacency that can be used for the exchange of IPv4 and IPv6 prefixes.
hostname R1
!
!
!
ipv6 enable
ip address 192.168.12.1 255.255.255.0
ipv6 address 2001:DB8:0:12::1/64
Page 195 of 283
!
router bgp 1
address-family ipv6
network 2001:db8::1/128
neighbor 192.168.12.2 activate
neighbor 192.168.12.2 route-map IPV6_NEXT_HOP in
!
route-map IPV6_NEXT_HOP permit 10
set ipv6 next-hop 2001:DB8:0:12::2
!
end
hostname R2
!
!
!
ipv6 enable
ip address 192.168.12.2 255.255.255.0
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
address-family ipv6
network 2001:DB8::2/128
neighbor 192.168.12.1 route-map IPV6_NEXT_HOP in
!
route-map IPV6_NEXT_HOP permit 10
set ipv6 next-hop 2001:db8:0:12::1
!
end
BGP Private and Public AS Range

Just like IP addresses, ASNs (Autonomous System Numbers) have to be unique on the Internet. The main
reason for this is that BGP uses the AS number for its loop prevention mechanism. When BGP learns about a
route that has its own AS number in its path then it will be discarded.
Here’s an example:
Page 196 of 283

Above we have three routers, R1 and R3 are using the same AS number. Once R1 sends an update, R2 will
accept it but R3 will not since the AS number is the same.
To prevent the above from happening, IANA is in control of the AS numbers (similar to public IP addresses). If
you want an AS number for the Internet then you’ll have to request one. They started with 16-bit AS numbers
(also called 2-octet AS numbers) that were assigned like this:
 0: reserved.
 1-64.495: public AS numbers.
 64.496 – 64.511 – reserved to use in documentation.
 64.512 – 65.534 – private AS numbers.
 65.535 – reserved.
The 1-64.495 public AS range is pretty small so there are similar issues to the IPv4 public IP addresses, there
aren’t enough numbers. Right now (May 2015) there are only 199 AS numbers left that could be assigned. You
can see the current status of available AS numbers here.
To get more AS numbers, an extension has been created that supports 32-bit AS numbers (also called 4-octet
AS numbers). This means we have about 4.294.967.296 AS numbers that we can use.
When you request an AS number you’ll have to justify why you need a public AS number. For some
organizations, using a private AS number should also be a solution.
Private AS numbers can be used when you are connected to a single AS that uses a public AS number. Here’s
an example:[teaser]
R1 is behind R2 and using private AS number 64512. R2 is using public AS number AS 2. In the BGP table of
R2 we will find the AS number of R1 but once it advertises something to AS3, it will remove the private AS
number.
Another example where we can use private AS numbers are BGP confederations. Within the confederation we
can use private AS numbers, to the outside world we use a public AS number.
Removing the private AS numbers is a bit similar to NAT where we hide private IP addresses behind one or
more public IP addresses.
BGP Remove Private AS
Page 197 of 283

Private range AS numbers (64512 – 65535) should not be used on the Internet since they are not unique like
public AS numbers.
Sometimes, private AS numbers are used for customer networks that are behind a single ISP. The advantage of
doing this is that we will save some public AS numbers, the disadvantage is that if you ever plan to connect to
another ISP, you should switch to a public AS number.
When the ISP forwards prefixes that it learns from the private AS, it will remove the private AS number
before it forwards the prefix to other autonomous systems.
Cisco IOS routers support the remove-private-as command to achieve this. There are some restrictions
however:
 You can only use this for eBGP neighbors.

 The private AS numbers are removed from outbound updates.
 You can only have private AS numbers in the AS path, if you have a mix of public and private AS numbers then
the router won’t remove anything (there’s a solution for this though that I will demonstrate).
 If the AS path contains the AS number of the eBGP neighbor then it won’t be removed.
 If there are confederations, BGP only removes private AS numbers after the confederation part in the AS path.
Let’s take a look at the configuration!
Configuration
I will use the following 3 routers for this:
R1 is in a private AS while R2 and R3 use public AS numbers. We’ll advertise the loopback interface on R1 in
eBGP so that R2 and R3 can learn it. Here’s the BGP configuration of these routers:

router bgp 64512
network 1.1.1.1 mask 255.255.255.255
router bgp 2
router bgp 3
Page 198 of 283

Remove-Private-AS
Let’s take a look at R2 and R3, they should have learned about 1.1.1.1/32:
R2#show ip bgp
Filter

*> 1.1.1.1/32 192.168.12.1 0 0 64512 i
R3#show ip bgp
Filter

*> 1.1.1.1/32 192.168.23.2 0 2 64512 i
In the AS path we see AS 2 and 64512, this is as expected. Now let’s configure R2 to remove the private AS
number:
R2(config-router)#neighbor 192.168.23.3 remove-private-as
We use the remove-private-as command for this. Let’s clear BGP to speed things up:
R2#clear ip bgp *
Now take a look at the BGP table of R3:
R3#show ip bgp
Filter

*> 1.1.1.1/32 192.168.23.2 0 2 i
It’s only showing AS 2 in the AS path now, the private AS number has been removed. That’s easy enough,
there are a few other things we can try however…
Remove-Private-AS All
Removing the private AS number(s) will only work if there are no public AS numbers in the AS path. To
demonstrate this I will add extra AS numbers on the update from R1:[teaser]
Page 199 of 283

R1(config)#route-map AS_PREPEND permit 10
R1(config-route-map)#set as-path prepend 1 64513 11 64514 111
I used a mix of public and private AS numbers. Let’s add these to the updates to R2:

R1(config-router)#neighbor 192.168.12.2 route-map AS_PREPEND out
Let’s reset R2 to speed things up and check the BGP table of R2 and R3:
R2#clear ip bgp *
R2#show ip bgp
Filter

*> 1.1.1.1/32 192.168.12.1 0 0 64512 1 64513 11 64514 111 i
R3#show ip bgp
Filter

*> 1.1.1.1/32 192.168.23.2 0 2 64512 1 64513 11 64514 111
i
As you can see above, the AS path didn’t change. No private AS numbers have been removed because there are
some public AS numbers in the AS path. Cisco IOS sees this as a misconfiguration so it won’t do anything. We
can change this behavior though:
R2(config-router)#neighbor 192.168.23.3 remove-private-as all
R2#clear ip bgp *
IOS 15.1T and later support the all parameter. This will remove all private AS numbers, no matter what else
there is in the AS path. Let’s take another look at R3:
R3#show ip bgp
Filter

*> 1.1.1.1/32 192.168.23.2 0 2 1 11 111 i
All private AS numbers are now gone from the BGP table, only public AS numbers remain.
Page 200 of 283

Remove-Private-AS All Replace
In the previous example we removed all private AS numbers, it’s also possible to replace them with our local
AS number. Here’s how:
R2(config-router)#neighbor 192.168.23.3 remove-private-as all replace-as
R2#clear ip bgp *
Add the replace-as parameter behind the remove-private-as all command and that’s it. Here’s what the BGP
table of R3 looks like now:
R3#show ip bgp
Filter

*> 1.1.1.1/32 192.168.23.2 0 2 2 1 2 11 2 111 i
As you can see all private AS numbers have been replaced by AS 2. That’s all there is to it!
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 64512
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 route-map AS_PREPEND out
!
route-map AS_PREPEND permit 10
set as-path prepend 1 64513 11 64514 111
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
Page 201 of 283

router bgp 2
neighbor 192.168.23.3 remove-private-as all replace-as
!
end
hostname R3
!
ip cef
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 3
!
end
BGP 4-Byte AS Number

Before January 2009, we only had 2 byte AS numbers in the range of 1-65535. 1024 of those (64512-65534) are
reserved for private AS numbers.
Similar to IPv4, we started running out of AS numbers so IANA increased the AS numbers by introducing 4-
byte AS numbers in the range of 65536 to 4294967295.
There are three ways to write down these new 4-byte AS numbers:
 Asplain
 Asdot
 Asdot+
Asplain is the most simple to understand, these are just regular decimal numbers. For example, AS number
545435, 4294937295, 4254967294, 2294967295, etc. These numbers are simple to understand but prone to
errors. It’s easy to make a configuration mistake or misread a number in the BGP table.
Asdot represents AS numbers less than 65536 using the asplain notation and AS numbers above 65536 with the
asdot+ notation.
Asdot+ breaks the AS number in two 16-bit parts, a high-order value, and a low-order value, separated by
a dot. All older AS numbers can fit in the second part where the first part is set to 0. For example:
 AS 6541 becomes 0.6541

 AS 54233 becomes 0.54233
 AS 544 becomes 0.544
For AS numbers above 65535, we use the next high order bit value and start counting again at 0. For example:
Page 202 of 283

These numbers are easier to read but harder to calculate than the asplain numbers, it’s also a bit trickier to create
regular expressions.
If you want to convert an asplain AS number to an asdot+ AS number, you take the asplain number and see how
many times you can divide it by 65536. This is the integer that we use for the high order bit value.
Then, you take the asplain number and deduct (65536 * the integer) to get your low order bit value. In other
words, this is the formula:
integer (high order bit value) = asplain / 65536

remainder (low order bit value) = asplain - (integer * 65536)
asdot value = integer.remainder
Here are two examples:
#AS 5434995
5434995 / 65536 = 82
5434995 - (82 * 65536) = 61043
asdot = 82.6104
#AS 1499547
1499547 / 65536 = 22
1499547 - (22 * 65536) = 57755
asdot = 22.57755
Once you understand how the conversion is done, you can use the APNIC asplain to asdot calculator to convert
this automatically and make your life a bit easier.
BGP speakers that support 4-byte AS numbers advertise this via BGP capability negotiation and there is
backward compatibility. When a “new” router talks to an “old” router (one that only supports 2-byte AS
numbers), it can use a reserved AS number (23456) called AS_TRANS instead of its 4-byte AS number. I’ll
show you how this works in the configuration.
Configuration
Cisco routers support the asplain and asdot representations. The configuration is pretty straightforward and I’ll
show you two scenarios:
 Two routers that both have 4-byte AS support.

 Two routers where one router only has 2-byte AS support.
4-byte AS support
We have two routers:
Page 203 of 283

Both routers support 4-byte AS numbers. You can see this when you configure the AS number:
R1(config)#router bgp ?
<1-4294967295> Autonomous system number
<1.0-XX.YY> Autonomous system number
As you can see, this IOS router supports asplain and asdot numbers. Let’s pick asplain and establish a BGP
neighbor adjacency:

You can see the asplain AS numbers in all bgp show commands:


192.168.12.2 4 12000012 5 5 1 0 0 00:01:02 0
If you want, you can change the representation to the asdot format:
R1(config-router)#bgp asnotation ?
dot asdot notation
Let’s change it:
R1(config-router)#bgp asnotation dot
You will now see the asdot format in all show commands:

BGP router identifier 192.168.12.1, local AS number 183.6924

192.168.12.2 4 183.6924 6 6 1 0 0 00:02:38 0
AS 12000012 now shows up as AS 183.6924.
Page 204 of 283

hostname R1
!
ip cef
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 183.6924
bgp asnotation dot
neighbor 192.168.12.2 remote-as 183.6924
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 12000012
!
end
2-byte AS support
Let’s use two routers. R1 only supports 2-byte AS numbers, R2 supports 4-byte AS numbers:
R1 has no clue what an AS number above 65535 is:[teaser]
R1(config)#router bgp ?
<1-65535> Autonomous system number
What value do we enter for R2 here? R2 is in AS 22222222 but we can’t configure that number. We need to use
the reserved AS number (AS_TRANS) here:
On R2, we configure the actual AS number:

Page 205 of 283

Here’s a capture of the neighbor adjacency. You can see that R2 adds the 4-byte AS number capability in its
OPEN message:
BGP 4-byte AS number capability
Once the neighbor adjacency is established, R2 uses AS 23456 when talking with R1:


192.168.12.2 4 23456 2 2 0 0 0 00:00:11 0

192.168.12.1 4 1 2 2 1 0 0 00:00:25 0
Above, you can see that R1 thinks R2 is in AS 23456.
hostname R1
!
ip cef
!
Page 206 of 283
ip address 192.168.5.5 255.255.255.0
!
router bgp 1
no auto-summary
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 22222222
no auto-summary
!
end
Conclusion
You have now learned about BGP 4-byte AS numbers:
 2 byte (octet) AS numbers only offer 65535 AS numbers

 4-byte AS numbers offer AS numbers in the range of 65536 – 4294967295
 These are three ways to write the new AS numbers:
o asplain: the entire decimal value (eg AS 3498577)
o asdot+ two 16-bit values, separated by a dot.
o asdot: uses asplain for AS numbers below 65536 and asdot+ for AS numbers above 65535.
 Cisco IOS routers support asplain and asdot.
 The two are compatible thanks to the reserved AS_TRANS number 23456 that “new” routers can use to
talk to “old” routers.
 Routers use 4-byte capability parameter to figure out of they support this or not.
BGP Soft Reconfiguration

When we change the BGP routing policy (changing the attributes or adding filters) we need to reset the BGP
session before the new policy takes effect. This is no problem in a lab but it’s something you don’t want to do in
a production network. In fact, there are 3 methods how you can refresh your BGP policies:
 Hard reset
 Dynamic Soft Reset (route refresh)
 Soft reset with pre-stored information
The hard reset is the most simple method (clear ip bgp command). It kills the TCP session with your BGP
neighbor which forces it to restart and as a result you’ll receive all prefixes from your neighbor again. It works,
but it’s cruel…
Dynamic soft reset is the most preferred method, it requires the route refresh capability. Simply said, this
feature lets your router request its BGP neighbor to send its prefixes again.
Page 207 of 283
Routers that don’t support the route refresh capability will have to use the soft reset option. That’s what this
tutorial is about. You can read about dynamic soft reset / route refresh in my other tutorial.
Normally I talk about “prefixes” or “routes” but technically the information that BGP exchanges in update
messages is called NLRI (Network Layer Reachability Information). The NLRI field contains the prefixes
and length.
The soft reset option uses “pre-stored” information. Basically when we receive prefixes from a BGP neighbor
we will store this information in a new table and we don’t make any changes to it. Our router will then apply its
inbound BGP policy to this table and stores the end result as the BGP table.
Since you are now storing another table for each neighbor instead of one BGP table you will have some
overhead, your router will require more memory. This is especially true when you enable soft reset for all your
BGP neighbors…keep this in mind before you configure this.
The tables that I’m talking about have some special names, let me show you a picture and explain this a bit
more:
On the left side we see a table called adj-RIB-in. This is the unedited routing information from a BGP
neighbor. There’s a separate table for each BGP neighbor that you peer with. We apply our inbound BGP policy
to this information and the result is a table called the loc-RIB, this is the actual BGP table.
BGP will select the best path from the BGP table and the router will install this in the routing table. Also, the
best paths can be advertised to other BGP neighbors. We can apply an outbound BGP policy to outbound
updates and when this is done we have a table called adj-RIB-out (per neighbor). The adj-RIB-in table is
actually stored in memory for each neighbor, the adj-RIB-out table not.
Now you have an idea about the different tables and how soft reconfiguration works, let’s take a look at this on
some BGP routers.
Page 208 of 283

Configuration
To demonstrate the soft reset we only need two routers. R1 has two loopback interfaces so that we have a
couple of networks to advertise:
First we will configure BGP between the two routers:
Nothing special here, we run EBGP and R1 advertises its two loopback interfaces. By default the soft reset
option is disabled, let’s configure it on R2:
R2(config-router)#neighbor 192.168.12.1 soft-reconfiguration inbound
The soft-reconfiguration inbound command tells R2 to save the routing information from R1 unmodified in
the adj-RIB-in table. It will then apply the inbound BGP policy and store the information in the BGP table.
Let’s take a look at these tables, a good way to do this is by changing some of the BGP attributes. I’ll change
the local preference for the prefixes we receive from R1:
R2(config)#route-map LOCALPREF permit 10

R2(config-route-map)#set local-preference 200
R2(config-route-map)#router bgp 2
R2(config-router)#neighbor 192.168.12.1 route-map LOCALPREF in
This will set the local preference to 200 for all incoming prefixes from R1. Instead of clearing the TCP session,
we’ll do a soft reset:
R2#clear ip bgp 192.168.12.1 soft in
Use the soft in parameter to do a soft reset. Now look at the BGP table first:
R2#show ip bgp
Page 209 of 283
Filter

*> 1.1.1.1/32 192.168.12.1 0 200 0 1 i
*> 11.11.11.11/32 192.168.12.1 0 200 0 1 i
The BGP table (loc-RIB) was modified as expected, now take a look at the adj-RIB-in table:
R2#show ip bgp neighbors 192.168.12.1 received-routes

Filter

* 1.1.1.1/32 192.168.12.1 0 0 1 i
* 11.11.11.11/32 192.168.12.1 0 0 1 i
Above you see the raw routing information from R1 before we applied the inbound BGP policy. You can see
that no changes were made to the local preference of my prefixes.
Another nice experiment is to filter some of the prefixes:
R2(config)#access-list 1 permit host 1.1.1.1

R2(config-router)#neighbor 192.168.12.1 distribute-list 1 in
I’ll use a distribute-list so that 11.11.11.11 /32 is not allowed anymore. Before I do another soft reset I’ll enable
a debug, this allows you to see what the router is doing with the BGP updates:
[teaser]
R2#debug ip bgp updates

BGP updates debugging is on for address family: IPv4 Unicast
Let’s do the soft reset:
R2#clear ip bgp 192.168.12.1 soft in
Here’s what you will see:
R2#
BGP(0): start inbound soft reconfiguration for
BGP(0): process 1.1.1.1/32, next hop 192.168.12.1, metric 0 from 192.168.12.1
BGP(0): process 11.11.11.11/32, next hop 192.168.12.1, metric 0 from 192.168.12.1
BGP(0): Prefix 11.11.11.11/32 rejected by inbound distribute/prefix-list.
BGP(0): update denied
BGP(0): complete inbound soft reconfiguration, ran for 0ms
Page 210 of 283

The router starts the soft reconfiguration, rejects the 11.11.11.11 /32 prefix and completes the soft
reconfiguration. Take a look at the BGP table:
R2#show ip bgp
Filter

*> 1.1.1.1/32 192.168.12.1 0 200 0 1 i
As expected it’s gone but you will still find it in the adj-RIB-in table:
R2#show ip bgp neighbors 192.168.12.1 received-routes

Filter

* 1.1.1.1/32 192.168.12.1 0 0 1 i
* 11.11.11.11/32 192.168.12.1 0 0 1 i
Those are two good examples that show the difference between the adj-RIB-in and Loc-RIB tables. Of course
we can also view the adj-RIB-out table, I’ll show you an example of R1:

Filter

*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 11.11.11.11/32 0.0.0.0 0 32768 i
Use the show ip bgp neighbors advertised-routes command to view the adj-RIB-out table. These are all the
prefixes that you advertise to each BGP neighbor.
hostname R1
!
ip address 1.1.1.1 255.255.255.255
!
ip address 11.11.11.11 255.255.255.255
Page 211 of 283

!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.1 mask 255.255.255.255
network 11.11.11.11 mask 255.255.255.255
neighbor 192.168.12.1 distribute-list 1 in
!
access-list 1 permit host 1.1.1.1
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
neighbor 192.168.12.1 soft-reconfiguration inbound
neighbor 192.168.12.1 route-map LOCALPREF in
!
route-map LOCALPREF permit 10
set local-preference 200
!
end
BGP Route Refresh Capability

A long time ago there was no method to dynamically request a re-advertisement of the prefixes of one of your
BGP neighbors. When you change your policy, somehow you have to compare all the prefixes from your BGP
neighbor against your new policy.
To solve this problem, the soft reconfiguration method was created which stores an unmodified version of the
prefixes from your BGP neighbor. This works but you’ll need additional memory since you are saving an
additional table for each BGP neighbor. Since 2000 we also have the route refresh capability, simply said…your
router will ask its BGP neighbor to re-send its prefixes.
Here are the 3 options that we have to refresh our BGP table when our policy changes:
 Hard reset
 Soft reconfiguration
 Route refresh capability
The hard reset is the most simple method (clear ip bgp command). It kills the TCP session with your BGP
neighbor which forces it to restart and as a result you’ll receive all prefixes from your neighbor again. It works
but will interrupt your network, not a good idea.
The soft reconfiguration will store everything that you receive from a BGP neighbor in a separate table before
applying the policy. I explain this in my soft reconfiguration tutorial. This works but it’s not very efficient.
Page 212 of 283

Your router will store an entire table for each BGP neighbor with the unmodified prefixes, you’ll need extra
memory.
Route refresh capability is the most preferred method…when you change your BGP policy you just send a
message to your BGP neighbor and it will re-send you all its prefixes, there will be no disruption at all.
In this tutorial we’ll look at the route refresh capability, it’s described in RFC 2918 and supported on most
routers.
Configuration
I will use two routers for this, R1 and R2. I have added two loopback interfaces on R1 so that we have
something to advertise:
Let’s start with a default BGP configuration:
Route refresh is enabled by default, you can verify this by using the following show command:
R1#show ip bgp neighbors 192.168.12.2 | begin capabilities

Neighbor capabilities:
Route refresh: advertised and received(new)
This router can do a route refresh for inbound prefixes (what you learn from you BGP neighbor) or outbound
(the prefixes that you send to them). On my IOS 15.x router you see “(new)” which means this router supports
the RFC 2918 version of route refresh. Some older IOS versions might show (“old & new”) which means they
also support a version of route refresh that Cisco implemented before the RFC was created.
Let’s see if R2 learned those prefixes on the loopback interfaces:
R2#show ip bgp
Filter
Page 213 of 283

*> 1.1.1.1/32 192.168.12.1 0 0 1 i
*> 11.11.11.11/32 192.168.12.1 0 0 1 i
That’s looking good. Now I will create a route-map that changes one of the BGP attributes. This means the
router will have to update its BGP table somehow:
R2(config)#route-map METRIC permit 10

R2(config-router)#neighbor 192.168.12.1 route-map METRIC in
This route-map will set the metric to 222 for all prefixes that we receive from R1. Let’s look at he BGP table
again:
R2#show ip bgp
Filter

*> 1.1.1.1/32 192.168.12.1 0 0 1 i
*> 11.11.11.11/32 192.168.12.1 0 0 1 i
As you can see nothing has changed yet. We’ll use the route refresh method to fix this but before I do so, let’s
enable a debug so you can see in realtime what is going on:
R1 & R2#debug ip bgp

I’ll enable the debug on both routers, now we can do a reset:
R2#clear ip bgp 192.168.12.1 ?

all All address families
flap-statistics Clear flap statistic
in Soft reconfig inbound updates
ipv4 Address family
ipv6 Address family
l2vpn Address family
nsap Address family
out Soft reconfig outbound updates
rtfilter Address family
slow Forcefully clear slow-peer status and move it to original
update group
soft Soft reconfig inbound and outbound updates
topology Routing topology instance
vpnv4 Address family
vpnv6 Address family
<cr>
You can choose between inbound, outbound or both. Let’s do inbound:

[teaser]
Page 214 of 283
R2#clear ip bgp 192.168.12.1 in
You will see the following message on R2:
R2#
BGP: 192.168.12.1 sending REFRESH_REQ(5) for afi/safi: 1/1
R2 is sending a refresh request to R1, let’s see what R1 thinks of this:
R1#
BGP: 192.168.12.2 rcvd REFRESH_REQ for afi/safi: 1/1
Now look at the BGP table of R2 again:
R2#show ip bgp
Filter

*> 1.1.1.1/32 192.168.12.1 222 0 1 i
*> 11.11.11.11/32 192.168.12.1 222 0 1 i
Very nice, the metric has been updated and we didn’t clear the BGP session…mission accomplished!
When you enable soft reconfiguration, your router will no longer send a route refresh update request to its BGP
neighbor but it will use the routing information that it stored for this neighbor.
hostname R1
!
ip address 1.1.1.1 255.255.255.255
!
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 1
network 1.1.1.1 mask 255.255.255.255
network 11.11.11.11 mask 255.255.255.255
!
end
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
Page 215 of 283
neighbor 192.168.12.1 route-map METRIC in
!
route-map METRIC permit 10
set metric 222
!
end
MPLS Layer 3 VPN BGP Allow-AS-In

External BGP uses a simple loop prevention mechanism: when you see your own AS number in the AS path,
we don’t accept the prefix. There are some scenarios where this might be an issue. Take a look at the following
topology:
Above we have a MPLS VPN network where the customer is using the same AS number (12) on both sites.
CE1 and CE2 will be unable to learn each others prefixes since they are using the same AS number.
Let’s see if this is true, here are the configurations of all routers if you want to test this yourself:
Here you will find the startup configurations of each device.

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
Page 216 of 283
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
route-target export 1:1
route-target import 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip vrf forwarding CUSTOMER
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
no neighbor 4.4.4.4 activate
exit-address-family
!
address-family vpnv4
neighbor 4.4.4.4 send-community extended
exit-address-family
!
address-family ipv4 vrf CUSTOMER
exit-address-family
!
end
hostname P
!
interface Loopback0
Page 217 of 283
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
Page 218 of 283
exit-address-family
!
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
!
end
Each CE router has a loopback interface that was advertised in BGP (1.1.1.1/32 and 5.5.5.5/32). The first thing
to check is to see if the PE routers have learned the prefixes from our CE routers:
PE1#show ip bgp vpnv4 all

Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*> 1.1.1.1/32 192.168.12.1 0 0 12 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i

*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
*> 5.5.5.5/32 192.168.45.5 0 0 12 i
Above you can see that both PE routers have a VPN route for these prefixes. Did they advertise these prefixes
to our CE routers?
PE1#show ip bgp vpnv4 all neighbors 192.168.12.1 advertised-routes

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
RPKI validation codes: V valid, I invalid, N Not found

*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i
Page 219 of 283


*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
No issues there, our PE routers are advertising these prefixes to the CE routers. Let’s see what we find in the
BGP tables of the CE routers:
CE1#show ip bgp

*> 1.1.1.1/32 0.0.0.0 0 32768 i
CE2#show ip bgp

*> 5.5.5.5/32 0.0.0.0 0 32768 i
The CE routers only have their own prefixes in their BGP tables. Why did they refuse the updates from the PE
routers? Time for a debug:
CE1#debug ip bgp all updates

BGP updates debugging is on for all address families
Let’s reset the BGP neighbor adjacency:
CE1#clear ip bgp *
Here’s what you will see on the CE1 router:
CE1# BGP(0): 192.168.12.2 rcv UPDATE about 5.5.5.5/32 -- DENIED due to: AS-PATH contains
our own AS;
As expected, the CE1 router denies the update since it sees its own AS number in the AS path. If we don’t want
to change our AS numbers then there’s two ways to deal with this:
 Use Allow-AS in to overrule the loop prevention mechanism of external BGP.

 Use AS override to change the AS number on the PE routers.
This lesson is about allow-AS in so that’s what we will do this time:[teaser]
CE1(config)#router bgp 12
CE1(config-router)#neighbor 192.168.12.2 allowas-in
Page 220 of 283

CE1 is now configured to allow prefixes with its own AS number from the PE1 router. If you left the debug
enabled then you will see this:
CE1#
BGP(0): Revise route installing 1 of 1 routes for 5.5.5.5/32 -> 192.168.12.2(global) to
main IP table
That should take care of our problem. Let’s see if the prefix has been installed:
CE1#show ip route 5.5.5.5

Known via "bgp 12", distance 20, metric 0
Tag 234, type external
Last update from 192.168.12.2 00:01:13 ago
* 192.168.12.2, from 192.168.12.2, 00:01:13 ago
AS Hops 2
Route tag 234
MPLS label: none
There we go, it’s in the routing table. Don’t forget to configure the same change on CE2:
CE2(config)#router bgp 12
CE2(config-router)#neighbor 192.168.45.4 allowas-in
CE2 should now accept 1.1.1.1/32:
CE2#show ip route 1.1.1.1

Known via "bgp 12", distance 20, metric 0
Tag 234, type external
* 192.168.45.4, from 192.168.45.4, 00:00:45 ago
AS Hops 2
Route tag 234
MPLS label: none
That’s looking good. One final check left, let’s see if there is connectivity between 1.1.1.1 and 5.5.5.5:
CE1#ping 5.5.5.5 source loopback 0

!!!!!
Excellent it’s working.
Want to take a look at the complete configurations yourself?
Page 221 of 283

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 allowas-in
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
Page 222 of 283
exit-address-family
!
end
hostname P
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
Page 223 of 283
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
neighbor 192.168.45.4 allowas-in
!
end
Conclusion
The allow-AS command is a simple trick to overrule the loop prevention mechanism of external BGP. In this
example it’s safe to disable it since CE1 and CE2 are stub routers, they only have one exit path through the PE
routers. This solution allowed us to solve the problem on the CE routers. We can also fix it by making a change
on the PE routers, I’ll show you how to do this in the AS override lesson.
When your customer sites are multihomed or have a backdoor link between them then you have to be careful as
this solution can introduce loops. The BGP SoO (Site of Origin) communitry attribute is then used as a loop
prevention mechanism. This is something we will cover in another lesson.
MPLS Layer 3 VPN BGP AS Override

BGP has a simple loop prevention mechanism for external BGP. When you see your own AS number in the AS
path, we do not accept the prefix. This mechanism is fine for Internet routing but there are some other scenarios
where this might be an issue. Take a look at the following topology:
Page 224 of 283

Above we have a small MPLS VPN network with two customer sites. The customer is using the same AS
number (12) for both sites. When CE1 or CE2 receive an update from each other they will not accept it since
their own AS number will be in the AS path.
Let’s find out if this is true. Here are the configurations of all routers:

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
Page 225 of 283
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname P
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
Page 226 of 283
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
Page 227 of 283
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
!
end
Let’s find out what is going on. First we’ll check if the PE routers have a VPN route for the prefixes from the
CE routers:

*> 1.1.1.1/32 192.168.12.1 0 0 12 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i

*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
*> 5.5.5.5/32 192.168.45.5 0 0 12 i
The PE routers have an entry for the loopback interfaces of the CE routers. Are they advertising these to the CE
routers?


*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i


*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
Page 228 of 283

The PE routers are advertising these to the CE routers. Let’s check the CE routers:
CE1#show ip bgp

*> 1.1.1.1/32 0.0.0.0 0 32768 i
CE2#show ip bgp

*> 5.5.5.5/32 0.0.0.0 0 32768 i
There’s nothing there…they only have the prefix on their own loopback interface in the BGP table. Let’s enable
a debug on CE1 to figure out why it’s not accepting anything from PE1:
CE1#debug ip bgp all updates

BGP updates debugging is on for all address families
Let’s reset the neighbor adjacency:
CE1#clear ip bgp *
Here’s what you will see:
CE1#
BGP(0): 192.168.12.2 rcv UPDATE about 5.5.5.5/32 -- DENIED due to: AS-PATH contains our
own AS;
No surprises here…CE1 is denying the update since it sees its own AS number in the AS path. If we want to
keep the same AS number on CE1 and CE2 then there are two possible solutions for this issue:
 Allow-AS in: this can be configured on the CE routers which tells them to accept prefixes with their
own AS number in the AS path.
 AS override: this can be configured on the PE routers, the AS number will be replaced with the AS
number from the service provider.
This lesson is about AS override so that’s what we will do. Let’s configure the PE routers:[teaser]
PE1(config)#router bgp 234

PE1(config-router)#address-family ipv4 vrf CUSTOMER
PE1(config-router-af)#neighbor 192.168.12.1 as-override
PE2(config-router)#address-family ipv4 vrf CUSTOMER
PE2(config-router-af)#neighbor 192.168.45.5 as-override
To speed things up, let’s clear the BGP neighbor adjacencies on the PE routers:
PE1 & PE2#clear ip bgp *
Let’s take another look at the CE routers:
CE1#show ip bgp 5.5.5.5

Page 229 of 283
Refresh Epoch 1
234 234
192.168.12.2 from 192.168.12.2 (2.2.2.2)
rx pathid: 0, tx pathid: 0x0
CE2#show ip bgp 1.1.1.1
Refresh Epoch 1
234 234
192.168.45.4 from 192.168.45.4 (4.4.4.4)
rx pathid: 0, tx pathid: 0x0
The CE routers have now learned each others prefixes. If you take a closer look, you can see that AS number 12
has been replaced with AS number 234.
One final check, let’s see if there is connectivity between 1.1.1.1 and 5.5.5.5:
CE1#ping 5.5.5.5 source loopback 0

!!!!!
Excellent this is working! Want to take a look at these configurations yourself?

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
Page 230 of 283

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
neighbor 192.168.12.1 as-override
exit-address-family
!
end
hostname P
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
Page 231 of 283
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
neighbor 192.168.45.5 as-override
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
Page 232 of 283
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
!
end
Conclusion
AS override is a simple technique to change the AS number of updates that you advertise to your external BGP
neighbors. Another solution is allow AS in but this is configured on the CE routers. Since we are “overruling”
the external BGP loop prevention mechanism you have to make sure that you have a loop-free topology.
In this scenario there are no issues since the CE routers are stubs, they only have one exit path. When your
customer sites are multihomed or have a backdoor link then you need to use the BGP SoO (Site of Origin)
community to ensure you have a loop free topology. This is something we’ll cover in another lesson.
BGP Aggregate AS-SET

When you use the BGP aggregate-address command on Cisco IOS without any parameters, then all information
of individual route attributes such as AS_PATH is lost.
This can cause issues since the AS_PATH is used for loop prevention. For example, it’s possible that an AS
installs a summary that it shouldn’t. With the AS-SET parameter, you can optionally include AS information in
the summary. In this lesson, I’ll show you how to do this.
Configuration
Here is the topology we’ll use:
Page 233 of 283

We have four routers, all in a different AS. R2 and R3 have a loopback with an IP address that are advertised in
BGP. R1 will send an aggregate to R4.
hostname R1
!
ip cef
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
ip address 192.168.14.1 255.255.255.0
!
router bgp 1
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 172.16.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
router bgp 2
network 172.16.2.2 mask 255.255.255.255
!
end
hostname R3
!
ip cef
!
interface Loopback0
ip address 172.16.3.3 255.255.255.255
!
ip address 192.168.13.3 255.255.255.0
!
router bgp 3
network 172.16.3.3 mask 255.255.255.255
!
end
hostname R4
!
ip cef
!
Page 234 of 283
ip address 192.168.14.4 255.255.255.0
!
router bgp 4
!
end
Right now, there is no aggregate so R4 sees two separate prefixes with the correct AS path information:
R4#show ip bgp
t secondary path,

*> 172.16.2.2/32 192.168.14.1 0 1 2 i
*> 172.16.3.3/32 192.168.14.1 0 1 3 i
Each prefix has the correct AS path.
Without AS-SET
Let’s create a summary/aggregate. We’ll start without the AS-SET parameter so that we have a before and after
example:
R1(config-router)#aggregate-address 172.16.0.0 255.255.0.0 summary-only
Here’s what we get on R4:
R4#show ip bgp
t secondary path,

*> 172.16.0.0 192.168.14.1 0 0 1 i
We see the 172.16.0.0/16 prefix but all AS path information is lost. This prefix seems to come from AS 1 only.
If R4 was connected to R2 or R3 then those routers would install this prefix without hesitation since they don’t
see their own AS number in the summary route. This could cause routing loops.
With AS-SET
Let’s add the as-set parameter on R1 now:

Page 235 of 283
R1(config-router)#aggregate-address 172.16.0.0 255.255.0.0 summary-only as-set
Here’s what we get on R4:[teaser]
R4#show ip bgp
t secondary path,

*> 172.16.0.0 192.168.14.1 0 0 1 {2,3} i
We now see the AS path information in the aggregate. This helps against routing loops as it shows the AS
numbers in the aggregate. If R2 or R3 would somehow receive this aggregate, they would not accept it since
they see their own AS number.
So, should we always use AS-SET? Maybe, there is a downside to using this. Whenever there is a change in the
aggregate, an update will be sent by R1. For example, let’s shut the loopback on R3:
R3(config)#interface Loopback 0
The summary on R4 now looks like this:
R4#show ip bgp
t secondary path,

*> 172.16.0.0 192.168.14.1 0 0 1 2 i
Information about AS 3 has been removed. It’s interesting to see that this router does now show 1 {2} but just 1
2.
If you have an aggregate that covers hundreds or thousands of prefixes then a change in your aggregate is likely.
If you have a flapping network somewhere, it’s possible that your aggregate keeps getting updated.
Conclusion
You have now learned how you can include AS path information in aggregates (summaries) with the AS-SET
parameter. This helps to prevent routing loops in case the aggregate somehow makes it back to one of the ASes
where one of the prefixes that fall within the range of your aggregate originated from.
Page 236 of 283

The disadvantage of AS-SET is that by including AS path information, it’s possible that your aggregate gets
updated whenever there is a change. With a flapping network somehow, this could mean that your aggregate
keeps getting updated over and over again.
BGP Multipath load sharing iBGP and eBGP

Unlike most routing protocols, BGP only selects a single best path for each prefix. It doesn’t do ECMP (Equal
Cost Multi-Path Routing) by default but it is possible to enable this.
In order for BGP to use the second path, the following attributes have to match:
 Weight
 Local Preference
 AS Path (both AS number and AS path length)
 Origin code
 MED
 IGP metric
Also, the next hop address for each path must be different. This comes into play when you are multihomed to
the same router.
In this lesson, I’ll show you how to configure eBGP and iBGP to use more than one path.
Configuration
We’ll start with two eBGP scenarios.
eBGP
When it comes to eBGP, there are two options:
 Multiple paths to the same AS.

 Multiple paths to different ASes.
Same AS
Let’s look at a scenario where we have two paths to the same AS. Here’s the topology:
Page 237 of 283

R1 is in AS 1 and connected to R2/R3 in AS23. R1 will have paths to get to 192.168.23.0/24.
hostname R1
!
ip cef
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router bgp 23
network 192.168.23.0 mask 255.255.255.0
!
end
hostname R3
!
ip cef
!
Page 238 of 283

ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router bgp 23
!
end
Here’s the BGP table of R1:
R1#show ip bgp
t secondary path,

* 192.168.23.0 192.168.13.3 0 23 i
*> 192.168.12.2 0 0 23 i
R1 has two equal paths but decided to install the path to R2. We can enable load balancing with the maximum-
paths command:
R1(config-router)#maximum-paths 2
Let’s take another look at the BGP table:
R1#show ip bgp
t secondary path,

*m 192.168.23.0 192.168.13.3 0 23 i
*> 192.168.12.2 0 0 23 i
Now we have two entries. Note the “m” that stands for multipath. Both paths are installed in the routing table:
B 192.168.23.0/24 [20/0] via 192.168.13.3, 00:13:02

[20/0] via 192.168.12.2, 00:13:02
That’s looking good.

Page 239 of 283
Different AS
Let’s look at another eBGP scenario. This time, we have multiple AS numbers:
R1 can go through AS 3 or AS 2 to get to 4.4.4.4/32 in AS 4.
hostname R1
!
ip cef
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
router bgp 2
!
end
hostname R3
!
Page 240 of 283
ip cef
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router bgp 3
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
router bgp 4
network 4.4.4.4 mask 255.255.255.255
!
end
Here’s the BGP table of R1:
R1#show ip bgp
t secondary path,

* 4.4.4.4/32 192.168.13.3 0 3 4 i
*> 192.168.12.2 0 2 4 i
R1 has installed R2 as its next hop address. Let’s see if we can change that:
R1(config-router)#maximum-paths 2
This command alone, however, doesn’t help:
R1#show ip bgp
*Mar 21 11:10:13.118: %SYS-5-CONFIG_I: Configured from console by console
Page 241 of 283

t secondary path,

* 4.4.4.4/32 192.168.13.3 0 3 4 i
*> 192.168.12.2 0 2 4 i
The problem here is that we have two different AS numbers, AS 2 and AS 3. We can tell BGP to “relax” its
requirement of having the same AS path numbers and AS path length to only checking the AS path length. This
can be done with the following hidden command:[teaser]
R1(config-router)#bgp bestpath as-path multipath-relax
Here’s how this command affects R1:
R1#show ip bgp
t secondary path,

*m 4.4.4.4/32 192.168.13.3 0 3 4 i
*> 192.168.12.2 0 2 4 i
We now see the “m” so we know R1 uses R3 as well. We can confirm this by looking at the routing table:
R1#show ip route 4.4.4.4 | include from

* 192.168.13.3, from 192.168.13.3, 00:00:55 ago
192.168.12.2, from 192.168.12.2, 00:00:55 ago
That’s all we have for eBGP.
iBGP
What about iBGP? Let’s take a look at the following topology:
Page 242 of 283

R1, R2, and R3 are in AS 123 while R4 is in AS 4. R1 can use either R2 or R3 to get to 4.4.4.4/32.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.123.1 255.255.255.0
!
no ip address
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.123.0 0.0.0.255 area 0
!
router bgp 123
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.123.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
Page 243 of 283
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.123.0 0.0.0.255 area 0
!
router bgp 123
network 192.168.24.0
network 192.168.123.0
!
end
hostname R3
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.123.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.123.0 0.0.0.255 area 0
!
router bgp 123
network 192.168.34.0
network 192.168.123.0
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
router bgp 4
network 4.4.4.4 mask 255.255.255.255
!
end
Page 244 of 283
Let’s have a look at the BGP table:
R1#show ip bgp
t secondary path,

*>i 4.4.4.4/32 192.168.24.4 0 100 0 4 i
* i 192.168.34.4 0 100 0 4 i
*>i 192.168.24.0 2.2.2.2 0 100 0 i
*>i 192.168.34.0 3.3.3.3 0 100 0 i
r i 192.168.123.0 3.3.3.3 0 100 0 i
r>i 2.2.2.2 0 100 0 i
R1 has two options to get to 4.4.4.4/32 but is using only one entry. We can change this with the maximum-paths
command but you need to add the ibgp parameter:

R1(config-router)#maximum-paths ibgp 2
Let’s take another look:
R1#show ip bgp
t secondary path,

*>i 4.4.4.4/32 192.168.24.4 0 100 0 4 i
*mi 192.168.34.4 0 100 0 4 i
*>i 192.168.24.0 2.2.2.2 0 100 0 i
*>i 192.168.34.0 3.3.3.3 0 100 0 i
rmi 192.168.123.0 3.3.3.3 0 100 0 i
r>i 2.2.2.2 0 100 0 i
That’s looking better. Let’s check the routing table:

B 4.4.4.4 [200/0] via 192.168.34.4, 00:00:37
[200/0] via 192.168.24.4, 00:00:37
B 192.168.24.0/24 [200/0] via 2.2.2.2, 00:26:11
B 192.168.34.0/24 [200/0] via 3.3.3.3, 00:26:18
Looking good, we have two entries on R1 in the routing table.
Page 245 of 283

Conclusion
You have now learned how to enable ECMP (Equal-Cost Multi-Path Routing) for BGP.
 All BGP attributes have to be the same for different paths, except for the next hop address.
 You can enable load balancing with the maximum-paths command.
 When you use eBGP with different AS numbers, you need to add the hidden bgp bestpath as-path
multipath-relax command
 When you use iBGP, make sure you add the ibgp parameter to the maximum-paths command
BGP Next Hop Address Tracking

For each route in the BGP table, the next hop has to exist and has to be reachable. If not, the route can’t be used.
BGP uses a scanner that checks all routes in the BGP table every 60 seconds. The BGP scanner does best path
calculation, checks the next hop addresses, and if the next hops are reachable.
60 seconds is a long time. When something happens with a next hop during the 60 seconds between two scans,
we have to wait for the next scan to start before problems are resolved. Meanwhile, we can have black holes
and/or routing loops.
BGP next hop tracking is a feature that reduces the BGP convergence time by monitoring BGP next hop address
changes in the routing table. It’s event-based because it detects changes in the routing table. When it detects a
change, it schedules a next hop scan to adjust the next hop in the BGP table.
After detecting a change, the next hop scan has a default delay of 5 seconds. Next hop tracking also supports
dampening penalties. This increases the delay of the next hop scan for next hop addresses that keep changing in
the routing table.
In this lesson, I’ll show you what the BGP next hop scanner looks like and how dampening works.
Configuration
We use the following topology:
Page 246 of 283

We have three routers in AS 123 running iBGP. Each router has a loopback interface with an IP address that we
advertise in OSPF. Those IP addresses are used by IGP as the next hop addresses. In between R2 and R3, we
have the 192.168.23.0/24 network that we will advertise in BGP.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.123.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.123.0 0.0.0.255 area 0
!
router bgp 123
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.123.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
Page 247 of 283
router ospf 1
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 192.168.123.0 0.0.0.255 area 0
!
router bgp 123
network 192.168.23.0
!
end
hostname R3
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.123.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 192.168.123.0 0.0.0.255 area 0
!
router bgp 123
network 192.168.23.0
!
end
As explained earlier, BGP has a scanner that runs every 60 seconds. If you have never seen it before, it’s
interesting to take a look at. You can see that it runs every 60 seconds if you enable the following debug:
R1#debug ip bgp
You will see the following messages:
R1#
*Apr 9 09:56:53.743: BGP: topo global:IPv4 Unicast:base Scanning routing tables
*Apr 9 09:56:53.744: BGP: topo global:IPv4 Multicast:base Scanning routing tables
*Apr 9 09:56:53.746: BGP: topo global:L2VPN E-VPN:base Scanning routing tables
*Apr 9 09:56:53.747: BGP: topo global:MVPNv4 Unicast:base Scanning routing tables
*Apr 9 09:57:53.754: BGP: topo global:IPv4 Unicast:base Scanning routing tables

*Apr 9 09:57:53.757: BGP: topo global:IPv4 Multicast:base Scanning routing tables
*Apr 9 09:57:53.758: BGP: topo global:L2VPN E-VPN:base Scanning routing tables
*Apr 9 09:57:53.759: BGP: topo global:MVPNv4 Unicast:base Scanning routing tables
Page 248 of 283
I left the timestamps so that you can see it runs every 60 seconds. The BGP scanner is a bit too slow to rely on
for next hop changes. Let’s see how next hop tracking works!
Next hop tracking is enabled by default so it’s not something we have to configure. You can see the two
commands here:
R1#show run all | include nexthop trigger

bgp nexthop trigger enable
bgp nexthop trigger delay 5
You can disable it by adding no to the first command. The only value we can change is the delay for when the
next hop scanner starts (5 seconds).
We want to see next hop tracking in action so let’s enable the following two debugs:
R1#debug ip routing
IP routing debugging is on
R1#debug ip bgp events nexthop

BGP nexthop events debugging is on
The first debug is useful to see changes to the routing table. The second debug shows what next hop tracking
will do.
Here’s the current BGP table:
R1#show ip bgp
t secondary path,

* i 192.168.23.0 2.2.2.2 0 100 0 i
*>i 3.3.3.3 0 100 0 i
The 192.168.23.0/24 network is advertised by both R2 and R3 but we use the path through R3. Let’s shut the
loopback interface of R3 to see what happens:
Here’s what we get:
R1#
RT: del 3.3.3.3 via 192.168.123.3, ospf metric [110/2]
RT: delete subnet route to 3.3.3.3/32
EvD: accum. penalty decayed to 0 after 67 second(s)
BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:19, 19000 , scheduling
nexthop scan in 5 secs
BGP: BGP Event nhop timer
Page 249 of 283
BGP: tbl IPv4 Unicast:base Nexthop walk
BGP(IPv4 Unicast): CHANGED Path metric 0 Path aigp-metric 0 nexthop: 3.3.3.3
RT: updating bgp 192.168.23.0/24 (0x0) :
via 2.2.2.2 0 1048577
RT: closer admin distance for 192.168.23.0, flushing 1 routes

RT: add 192.168.23.0/24 via 2.2.2.2, bgp metric [200/0]
As soon as OSPF figures out that 3.3.3.3/32 is gone, the route is deleted from the routing table. Immediately
after the OSPF event, you can see that BGP schedules the next hop scanner in 5 seconds.
Once those 5 seconds have expired, it changes the next hop address to 2.2.2.2 (R2) and adds this change to the
routing table. This process is much faster than the BGP scanner that runs every 60 seconds.
Here’s what the BGP table now looks like:
R1#show ip bgp
t secondary path,

*>i 192.168.23.0 2.2.2.2 0 100 0 i
* i 3.3.3.3 0 100 0 i
As you can see above, we now use 2.2.2.2 to get to 192.168.23.0/24.
We still see 3.3.3.3 as a next hop in the BGP table. That’s because the BGP hold-down timer hasn’t expired yet.
We can also verify this in the routing table:

Known via "bgp 123", distance 200, metric 0, type internal
* 2.2.2.2, from 2.2.2.2, 00:00:32 ago
AS Hops 0
MPLS label: none
Let’s try one more thing. Let’s shut the loopback 0 interface of R2 so that next hop address 2.2.2.2 is invalid.
Here’s the BGP table right now:
R1#show ip bgp
t secondary path,
Page 250 of 283

*>i 192.168.23.0 2.2.2.2 0 100 0 i
Let’s shut the loopback 0 interface of R2:
Take a look at the new debug messages:
R1#
BGP(IPv4 Unicast): CHANGED Path metric 0 Path aigp-metric 0 nexthop: 2.2.2.2
RT: del 192.168.23.0 via 2.2.2.2, bgp metric [200/0]
RT: delete network route to 192.168.23.0/24
OSPF detects the change and 2.2.2.2/32 is deleted from the routing table. Right after, BGP schedules a next hop
scan in 5 seconds and when the timer expires, it deletes the 192.168.23.0/24 route from the routing table.
Here’s what our BGP table looks like now:
R1#show ip bgp
t secondary path,

* i 192.168.23.0 2.2.2.2 0 100 0 i
The entry is still there because our iBGP hold-down timer hasn’t expired yet but the network is no longer
installed. We can verify this by checking the routing table:

Dampening
You have now seen how next hop tracking is scheduled and runs after 5 seconds. What if we have a flapping
network that causes the next hop to change over and over again? Right now, that means that the BGP table gets
updated after 5 seconds over and over again.
Page 251 of 283

To prevent this from happening, next hop tracking supports dampening.
Each time a next hop changes, a value of 500 is added to the penalty. When the penalty is below 950, the next
hop scanner is scheduled in 5 seconds. This is what we just witnessed.[teaser]
When the penalty is above 950, the next hop scanner is scheduled to when the penalty decreases to 100 or
below.
The penalty decreases by half every 8 seconds. If the current penalty is 2000 then 8 seconds later, it will be
1000. Another 8 seconds later, it will be 500. These parameters cannot be configured.
We can test dampening by changing the next hop in the routing table over and over again. You could
shut/unshut the loopback 0 interfaces of R2 or R3 a couple of times but then you need to wait until OSPF
converges.
I’m going to add and remove a static route on R1 a couple of times. This is the quickest method to change the
routing table and trigger next hop tracking.
I still have my debugs enabled but I will disable debug IP routing:
R1#no debug ip routing

IP routing debugging is off
Now I add and remove the following static route for next hop 2.2.2.2 a couple of times after another:

R1(config)#no ip route 2.2.2.2 255.255.255.255 null 0
Now take a look at the debug:
R1#
The first time, our next hop scanner is scheduled in 5 seconds. This is normal. The next hop keeps “flapping”
and we get the following debug messages:
R1#
BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:25, 25000 , timer already
running
running

Above, you see the current penalty values (first 353, then 853) but nothing happens. This is because the next
hop scanner has already been scheduled. Once those 5 seconds have expired, it runs.
Page 252 of 283

The next hop keeps flapping so the penalty keeps increasing:
R1#
Above, you see that the penalty was 956 and a bit later, the next hop scanner is scheduled to run in 31 seconds.
That’s when the penalty is supposed to have a value of 100.
The next hop keeps flapping and we see the following debug messages:
R1#EvD: accum. penalty decayed to 944 after 5 second(s)

running
running

running

running
BGP(0): IPv4 Unicast::base nexthop modified, reuse

running

running
running
Above, you can see that the penalty keeps increasing but nothing happens. We already scheduled the next hop
scanner so right now, the penalty increased but that’s it.
Once those 31 seconds expire, the scanner runs:
R1#
If the network keeps flapping, the penalty will rise higher and higher, and the next hop scanner will be delayed
even more.
Conclusion
Page 253 of 283

You have now learned how BGP next hop tracking works.
 BGP has a BPG scanner which checks next hops and next hop reachability every 60 seconds.
 When a next hop changes or fails in between two runs of the BGP scanner then we can have temporarily black
holes or routing loops.
 Next hop tracking increases BGP convergence time by checking changes to next hops in the routing table.
 When a change is detected, the BGP next hop scanner is scheduled to run in 5 seconds. You can change this
value.
 Next hop tracking supports dampening:
o Flapping networks get a penalty of 500 each time they flap.
o The penalty is reduced by half every 8 seconds.
o When the penalty is below 950, the next hop scanner is scheduled with the default value (5 seconds).
o When the penalty is above 950, the next hop scanner is scheduled to run when the penalty has a value
of 100.
BGP Additional Paths

BGP routers only advertise the best path to their neighbors. When a better path is found, it replaces the current
path. Advertising a path and replacing it with a new path is called an implicit withdraw.
Since we only advertise the best path, a lot of other possible paths are unknown to some of the routers. We call
this path hiding.
Path hiding has a couple of disadvantages:
 You can’t use BGP multipath

 Possible sub-optimal routing
 MED oscillation
 Next hop failure means BGP has to reconverge before traffic can be forwarded again
With the BGP additional paths feature, BGP advertises multiple paths for the same prefix so we have path
diversity instead of path hiding. Additional paths is an extension to BGP and it adds a unique path identifier to
each path. The path ID is similar to how the RD (Route Distinguisher) works in MPLS VPN, except the path
IDs can be used in any BGP address family.
This feature can only be used for iBGP and there are three steps to take to implement it:
1. Configure your routers so they can send and/or receive additional paths.
2. Configure a global selection criterion on the router to define which additional candidate paths should
be selected next to the best path.
3. To each neighbor, advertise a set or sets of additional paths that we selected as candidate paths.
For the additional path selection, there are three options:
 Best N: this is the best path and the second best path(s). The second best path(s) is chosen by
eliminating the (next) best path and then selecting the next best path.
 Group-best: the set of paths that are the best paths from each AS. This is best explained with a quick
example:
Page 254 of 283
o AS 1 advertises three paths for prefix 1.1.1.1/32:
 One with next hop 192.168.1.1
o We choose the best path from each AS and that becomes our set. This could be:
 1.1.1.1/32 with next hop 192.168.1.1
 2.2.2.2/32 with next hop 192.168.2.1
 3.3.3.3/32 with next hop 192.168.3.1
 All: all paths that have a unique next hop can be used as an additional path.
Let’s take a look at the additional paths feature in action.
Configuration
We’ll use the following topology:
We have five routers in AS 12345 where R2 is the RR (Route Reflector). R6 has a loopback interface with
prefix 6.6.6.6/32 that is advertised in BGP.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
Page 255 of 283
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.13.0 0.0.0.255 area 0
!
router bgp 12345
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.24.0 0.0.0.255 area 0
!
router bgp 12345
!
end
hostname R3
!
ip cef
!
Page 256 of 283
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.35.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.13.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
!
router bgp 12345
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.46.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 12345
!
end
hostname R5
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
Page 257 of 283
ip address 192.168.45.5 255.255.255.0
!
ip address 192.168.35.5 255.255.255.0
!
ip address 192.168.56.5 255.255.255.0
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 12345
!
end
hostname R6
!
ip cef
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 192.168.46.6 255.255.255.0
!
ip address 192.168.56.6 255.255.255.0
!
router bgp 6
network 6.6.6.6 mask 255.255.255.255
!
end
Let’s see what we have. R4 and R5 have learned about 6.6.6.6/32 from R6:

*> 6.6.6.6/32 192.168.46.6 0 0 6 i
*> 6.6.6.6/32 192.168.56.6 0 0 6 i
* i 4.4.4.4 0 100 0 6 i
R4 and R5 advertise 6.6.6.6/32 to R2, our route reflector:

* i 6.6.6.6/32 5.5.5.5 0 100 0 6 i
*>i 4.4.4.4 0 100 0 6 i
Page 258 of 283

R2 has both paths in its BGP table but installs the path to R4. It only advertises this best path to its clients. Let’s
look at two scenarios where this might be an issue.
Load Balancing
Let’s take a look at R1:

*>i 6.6.6.6/32 4.4.4.4 0 100 0 6 i
Since R2 only advertises its best path, R1 only knows about the path through R4. How is the next hop resolved?
Let’s have a look:

Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 192.168.12.2 on GigabitEthernet0/1, 01:15:01 ago
* 192.168.12.2, from 4.4.4.4, 01:15:01 ago, via GigabitEthernet0/1
4.4.4.4 resolves to R2 so R1 will never use the path through R3. Because R2 is “hiding” the path, we have two
disadvantages here:
 There is no load balancing, R1 could have used R3 to get to 6.6.6.6/32.

 When next hop 4.4.4.4 fails, BGP has to reconverge before traffic can resume.
Sub-optimal Routing
Let’s check R3:

*>i 6.6.6.6/32 4.4.4.4 0 100 0 6 i
R3 also uses 4.4.4.4 as the next hop to get to 6.6.6.6. How does 4.4.4.4 get resolved?
R3#show ip route 4.4.4.4 | include via

192.168.35.5, from 4.4.4.4, 01:13:48 ago, via GigabitEthernet0/3
R3 uses two different paths to get to 4.4.4.4/32, we can go through R2 or R5. The path through R2 is not the
most optimal path since it’s one more hop compared to the path through R5.
Also, when 4.4.4.4 fails, BGP has to reconverge. What we have seen so far is just the way it is; this is how BGP
works. Can we improve it though?[teaser]
Page 259 of 283

BGP Additional Paths
Let’s enable the additional-paths feature. I’ll start with R2. Let’s take a look at the command:

R2(config-router-af)#bgp additional-paths ?
install Additional paths to install into RIB
receive Receive additional paths from neighbors
select Selection criteria to pick the paths
send Send additional paths to neighbors
We enable this for the address-family, IPv4 in our case. There are a couple of options. Let’s start by enabling
the extension itself:
R2(config-router-af)#neighbor 1.1.1.1 additional-paths ?

disable Disable additional paths for this neighbor
receive Receive additional paths from neighbors
send Send additional paths to this neighbor
For each neighbor, you can define if you want to send and/or receive additional paths. I’ll configure R2 to send
additional paths to both R1 and R3:
R2(config-router-af)#neighbor 1.1.1.1 additional-paths send

R2(config-router-af)#neighbor 3.3.3.3 additional-paths send
The next thing to do is configure R2 how to globally select additional paths with the bgp additional-paths
select command:
R2(config-router-af)#bgp additional-paths select ?

all Select all available paths
backup Select backup path
best Select best N paths
best-external Select best-external path
group-best Select group-best path
We’ll keep it simple and tell R2 to use all available paths as additional paths:
R2(config-router-af)#bgp additional-paths select all
After entering this command, there is a change in the BGP table:
R2#show ip bgp
t secondary path,

* ia 6.6.6.6/32 5.5.5.5 0 100 0 6 i
*>i 4.4.4.4 0 100 0 6 i
Page 260 of 283

Note the a for an additional path. This does not affect the routing table and/or forwarding table for R2:

B 6.6.6.6 [200/0] via 4.4.4.4, 00:01:0
We still see only a single route here. Nothing gets installed. We are almost there, the last thing to do on R2 is
tell it which additional paths (that we previously selected globally) we want to advertise to our neighbors:
R2(config-router-af)#neighbor 1.1.1.1 advertise additional-paths ?

all Select all available paths
best Select best N paths
group-best Select group-best paths
Above, you can see that we only have three options here. Let’s keep it simple and configure R2 to advertise all
additional paths:
R2(config-router-af)#neighbor 1.1.1.1 advertise additional-paths all

R2(config-router-af)#neighbor 3.3.3.3 advertise additional-paths all
That’s all we have to do on R2.
R1 and R3 have to be configured to receive the additional paths:
R1 & R3
(config)#router bgp 12345
(config-router)#neighbor 2.2.2.2 additional-paths receive
Let’s take a look at R1 again:
R1#show ip bgp

*>i 6.6.6.6/32 4.4.4.4 0 100 0 6 i
* i 5.5.5.5 0 100 0 6 i
R1 has now two options so that tells us that R2 advertises two paths. R1 has selected 4.4.4.4 as the next hop but
we could use 5.5.5.5 as well. Let’s take a closer look at the BGP table for prefix 6.6.6.6/32:

Refresh Epoch 1
6
4.4.4.4 (metric 3) from 2.2.2.2 (2.2.2.2)
rx pathid: 0x0, tx pathid: 0x0
Refresh Epoch 1
6
5.5.5.5 (metric 3) from 2.2.2.2 (2.2.2.2)
Page 261 of 283

rx pathid: 0x1, tx pathid: 0
Above, you can see the received path ID. These are two different values which make each path unique. You
now could configure R1 to use multipath so that it used both paths, not a bad idea but since I already did this in
the multipath lesson, we’ll try something else here. Let’s configure the path through R3 as a backup path.
How and why to use backup paths in BGP is explained in detail in the BGP PIC (Prefix Independent Convergence lesson).
Two commands are needed, first the bgp additional-paths select all command to tell R1 which additional paths
to use and the second command to actually install the additional path:

R1(config-router-af)#bgp additional-paths install
Let’s check the BGP table again:

Additional-path-install
Path not advertised to any peer
Refresh Epoch 1
6
4.4.4.4 (metric 3) from 2.2.2.2 (2.2.2.2)
Refresh Epoch 1
6
5.5.5.5 (metric 3) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, backup/repair, all
Above, we see that the second path is now a backup/repair path. We can also verify this in the CEF table:
R1#show ip cef 6.6.6.6 detail

6.6.6.6/32, epoch 0, flags [rib only nolabel, rib defined all labels]
recursive via 4.4.4.4
nexthop 192.168.12.2 GigabitEthernet0/1
recursive via 5.5.5.5, repair
This is very nice. When our next hop 4.4.4.4 fails, we can install 5.5.5.5 right away without having to wait for
BGP to reconverge.
What about R3? Let’s have a look:
R3#show ip bgp
Page 262 of 283

* i 6.6.6.6/32 4.4.4.4 0 100 0 6 i
*>i 5.5.5.5 0 100 0 6 i
Because R3 has received the additional path, it’s now able to make better choices. It installed 5.5.5.5 as the next
hop.
It’s not a bad idea to configure R3 to use the other path as a backup/repair path:

R3(config-router-af)#bgp additional-paths install
Let’s take a quick look at the BGP and CEF table:

Refresh Epoch 2
6, (Received from a RR-client)
4.4.4.4 (metric 3) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, backup/repair, all
Refresh Epoch 2
6, (Received from a RR-client)
5.5.5.5 (metric 2) from 2.2.2.2 (2.2.2.2)
R3#show ip cef 6.6.6.6 detail
That’s looking good, R5 is now our best path and R4 is our backup path.
Conclusion
You have now learned about BGP additional paths:
 BGP only advertises the best path to neighbors, when a better path is found, it advertises the new path and
replaces the old one. This is called implicit withdrawing.
 Not advertising all paths is also called path hiding.
 Path hiding has some disadvantages:
o Can’t use BGP multipath
o The possibility of sub-optimal routing
Page 263 of 283

o MED oscillation
o Next hop failure means BGP has to reconverge
 BGP additional paths let you advertise additional paths next to the best path.
 This leads to path diversity instead of path hiding.
 Each path gets a unique path identifier.
 BGP additional paths are only available to iBGP.
 There are three things needed for additional paths:
o Configure the router to send and/or receive additional paths.
o Configure a global selection criterion for additional paths.
o To each neighbor, advertise a set or sets of additional paths that we selected as candidate paths.
 There are three options for additional paths selection:
o Best N
o Group Best
o All
BGP PIC (Prefix Independent Convergence) Core &

Edge
PIC (Prefix Independent Convergence) is a feature to decrease the data plane convergence time. There are two
flavors:
 BGP PIC Core: decreases convergence time when a core router fails and your IGP has to find a new
best path to your PE router.
 BGP PIC Edge: decreases convergence time when a PE router fails and BGP has to switch to a
different PE router.
PIC is best explained by showing it in action. We’ll use the following topology:
Above, we have a small provider network in AS 2 with routers running iBGP. P2 is our route reflector in this
network. We have two customers, CE1 and CE2. CE2 is advertising two prefixes in BGP. Within AS 2, we use
OSPF as the IGP. I increased the cost on the interfaces of the P2 router so that P1 is the preferred path.
hostname CE1
!
ip cef
!
Page 264 of 283
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 8.8.8.8 255.255.255.255
!
interface Loopback1
ip address 88.88.88.88 255.255.255.255
!
ip address 192.168.68.8 255.255.255.0
!
ip address 192.168.78.8 255.255.255.0
!
router bgp 8
network 8.8.8.8 mask 255.255.255.255
network 88.88.88.88 mask 255.255.255.255
!
end
hostname P1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.46.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
ip address 192.168.47.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
network 192.168.46.0 0.0.0.255 area 0
Page 265 of 283
network 192.168.47.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname P2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.35.5 255.255.255.0
!
ip address 192.168.57.5 255.255.255.0
!
ip address 192.168.25.5 255.255.255.0
!
ip address 192.168.56.5 255.255.255.0
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.25.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.56.0 0.0.0.255 area 0
network 192.168.57.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname PE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
Page 266 of 283
ip address 192.168.24.2 255.255.255.0
!
ip address 192.168.25.2 255.255.255.0
!
ip address 192.168.12.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.25.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname PE2
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.35.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
ip address 192.168.13.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname PE3
!
ip cef
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 192.168.46.6 255.255.255.0
!
Page 267 of 283
ip address 192.168.56.6 255.255.255.0
!
ip address 192.168.68.6 255.255.255.0
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0
network 192.168.46.0 0.0.0.255 area 0
network 192.168.56.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname PE4
!
ip cef
!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
ip address 192.168.57.7 255.255.255.0
!
ip address 192.168.47.7 255.255.255.0
!
ip address 192.168.78.7 255.255.255.0
!
router ospf 1
network 7.7.7.7 0.0.0.0 area 0
network 192.168.47.0 0.0.0.255 area 0
network 192.168.57.0 0.0.0.255 area 0
!
router bgp 2
!
end
BGP PIC Core

PIC core helps to speed up convergence when there is a failure in the core of your network and the BGP next
hop does not change.
Let’s have a look at PE1:
PE1#show ip bgp
Page 268 of 283
t secondary path,

*>i 8.8.8.8/32 6.6.6.6 0 100 0 8 i
*>i 88.88.88.88/32 6.6.6.6 0 100 0 8 i
Let’s focus on 8.8.8.8/32 and 88.88.88.88/32. These two prefixes were advertised by CE2 and PE1 learned them
from P2 (our route reflector). The next hop for both prefixes is 6.6.6.6. When PE1 wants to reach CE2, our
traffic path looks like this:
How does 6.6.6.6 get resolved? Let’s have a look:
PE1#show ip route 6.6.6.6

We learn about 6.6.6.6 through OSPF and to get to this next hop, we use next hop 192.168.24.4 through
interface GigabitEthernet0/1. This is what gets installed in the FIB (CEF table):
PE1#show ip cef 6.6.6.6

6.6.6.6/32
What about those two prefixes? This is how they show up in the FIB:
PE1#show ip cef | include 8.8

8.8.8.8/32 192.168.24.4 GigabitEthernet0/1
Here’s a quick summary of the recursive routing we saw:
 BGP: to get to 8.8.8.8/32 and 88.88.88.88/32 we use next hop 6.6.6.6.

Page 269 of 283
 IGP: to get to 6.6.6.6/32 we use next hop 192.168.24.4 with interface GigabitEthernet0/1.
 FIB:
o 8.8.8.8/32 via 192.168.24.4 interface GigabitEthernet0/1
o 88.88.88.88/32 via 192.168.24.4 interface GigabitEthernet0/1
For each prefix you have learned, you find an entry like this in the FIB. We only have two prefixes but if you
learned a million prefix through BGP, you’ll see them here.
Disaster strikes our provider and suddenly P1 fails:
How does this impact PE1 and how it gets to CE2?
Let’s find out! To see what happens in real-time, I’ll create an access-list that matches the next hop (6.6.6.6)
and our two prefixes (8.8.8.8/32 and 88.88.88.88/32). We attach the access-list to a debug:
PE1(config)#access-list 1 permit host 6.6.6.6

PE1#debug ip routing 1
IP routing debugging is on for access list 1
Let’s shut all interfaces of P1 now:
P1(config)#interface range GigabitEthernet 0/1 - 4

P1(config-if-range)#shutdown
Now it’s up to OSPF to figure out that P1 is gone and find a new path to 6.6.6.6:
PE1#
RT: updating ospf 6.6.6.6/32 (0x0) :
via 192.168.25.5 Gi0/2 0 1048578

RT: add 6.6.6.6/32 via 192.168.25.5, ospf metric [110/4]
RT: updating bgp 8.8.8.8/32 (0x0) :
via 6.6.6.6 0 1048577

RT: updating bgp 88.88.88.88/32 (0x0) :
via 6.6.6.6 0 1048577
Page 270 of 283

We see that OSPF reconverges and installs 192.168.25.5 (P2) as the new next hop to get to 6.6.6.6/32. BGP is
also updated. Let’s take a look at the BGP table:
PE1#show ip bgp
t secondary path,

*>i 8.8.8.8/32 6.6.6.6 0 100 0 8 i
*>i 88.88.88.88/32 6.6.6.6 0 100 0 8 i
Nothing changed in the BGP table, this makes sense since our next hop did not change. Only the path to get to
the next hop. Let’s take a look at OSPF:

We see that OSPF now uses 192.168.25.5 (P2) to get to 6.6.6.6/32 via the GigabitEthernet0/2 interface. Let’s
take a look at the FIB for our next hop:

6.6.6.6/32
Above, we see the new next hop for 6.6.6.6/32 and interface in the FIB. Let’s take a look at the FIB entries for
our two prefixes:

The FIB entries for our two prefixes has changed as well to reflect the new next hop and outgoing interface.
Think about this for a second…
Our router had to figure out a new path to get to 6.6.6.6/32 and update all entries in the FIB that used the old
next hop (192.168.24.4) to the new next hop (192.168.25.5). With two prefixes, this is a piece of cake but what
if we have one million prefixes in our FIB? They all have to get updated one-by-one and this takes a LONG
time (minutes).
The problem here is how our FIB works. We use what we call a “flat” or “flattened” FIB structure:[teaser]
Page 271 of 283

With a flat FIB, there is a one-to-one relationship between the prefix and the next hop / outgoing interface.
When the next hop changes, the router walks through each prefix in the FIB to update the next hop. This is a
time-consuming process that requires a lot of CPU cycles.
To improve this, we use a different structure for our FIB, called the hierarchical FIB:
Instead of a flat table, we use a hierarchical table where we also store the BGP next hops and the IGP next
hops separately.
This has a huge advantage: when the IGP next hop changes, only the part of the FIB that is affected has to
change:
We change the pointer from the BGP path list from “PE3 via 192.168.24.4” to “PE3 via 192.168.25.5” and
that’s it! We don’t have to touch the BGP prefixes or BGP path list since those did not change! That’s why we
call it “prefix independent”.
Page 272 of 283

With something like a million prefixes, this makes the difference between a convergence time of minutes to less
than 200 ms. The convergence time depends on how fast your IGP converges to find the new next hop. Some
other advantages are:
 Reduced FIB memory requirements since a lot of information is shared.

 Fewer CPU cycles needed because we don’t have to flatten all BGP prefixes when the IGP next hop changes.
The hierarchical FIB is supported on pretty much any Cisco platform. On Cisco IOS XR and NX-OS, it is the
default. On Cisco IOS, we can enable it with a simple command:
PE1, PE2, PE3 & PE4

(config)#cef table output-chain build favor convergence-speed
It’s only a single command to enable the hierarchical FIB and PIC core but if you want to use this, it doesn’t
end here. Since this relies on your IGP convergence time, there are some things you need to implement to speed
up your convergence times like:
 tuning your IGP timers

 implementing something like BFD or FRR
Before we continue with PIC edge, let’s restore P1:
P1(config-if-range)#no shutdown
BGP PIC Edge

BGP PIC core helps when there is an issue in the core. What if one of your PE routers fails or a link between a
PE and CE router?
When that happens, BGP has to reconverge and switch from one PE router to another PE router.
I’ll show you a “before” and “after” scenario of PIC edge from PE1’s perspective when PE3 fails. We use the
exact same topology that we started with.
Without BGP PIC Edge
Let’s take a look at the BGP table of PE1:
PE1#show ip bgp

*>i 8.8.8.8/32 6.6.6.6 0 100 0 8 i
*>i 88.88.88.88/32 6.6.6.6 0 100 0 8 i
We see the 8.8.8.8/32 and 88.88.88.88/32 prefix that both use next hop 6.6.6.6 (PE3). Let’s check the OSPF
routing table:

Page 273 of 283
To get to 6.6.6.6/32, we use next hop 192.168.24.4. This gets installed in the FIB:

6.6.6.6/32
And this is how our prefixes look in the FIB:

PE1 uses the path through P1 to get to P3:
Disaster strikes again…our provider recovered from the P1 failure but now their PE3 router fails:
On PE1, I enable this debug again:
PE1#debug ip routing 1
IP routing debugging is on for access list 1
And to simulate the PE3 failure, we’ll shut down all its interfaces:
PE3(config)#interface range GigabitEthernet 0/1 - 3

PE3(config-if-range)#shutdown
Page 274 of 283

Here’s what we see on PE1:
PE1#
via 7.7.7.7 0 1048577

RT: updating bgp 88.88.88.88/32 (0x0) :
via 7.7.7.7 0 1048577

via 7.7.7.7 0 1048577

RT: updating bgp 88.88.88.88/32 (0x0) :
via 7.7.7.7 0 1048577

OSPF figures out that 6.6.6.6/32 is gone so it gets removed from the routing table. BGP reconverges and figures
out that 7.7.7.7 (PE4) is the new next hop.
Let’s take a look at the updated BGP table:
PE1#show ip bgp

*>i 8.8.8.8/32 7.7.7.7 0 100 0 8 i
*>i 88.88.88.88/32 7.7.7.7 0 100 0 8 i
We see that BGP now uses 7.7.7.7 as the next hop. How does it get resolved?

To get to 7.7.7.7/32 we have to go to 192.168.24.4 (P1) with outgoing interface GigabitEthernet0/1. Here’s how
this gets installed in the FIB:

7.7.7.7/32
Page 275 of 283

This is all looking good but it’s a pretty slow process. BGP has to reconverge since the path through PE3 no
longer exists. It will take some time before P2 (the route reflector) figures out that PE3 is gone and advertises
the new path through PE4 (7.7.7.7) to PE1.
Let’s see how we can improve this. Let’s recover PE3 before we continue:
PE3(config)#interface range GigabitEthernet 0/1 - 3

PE3(config-if-range)#no shutdown
With BGP PIC Edge
We can configure BGP to pre-install a backup next hop. To do that, we need a second next hop. That’s a
problem right now. P2 is our route reflector and has two paths:
P2#show ip bgp

*>i 8.8.8.8/32 6.6.6.6 0 100 0 8 i
* i 7.7.7.7 0 100 0 8 i
*>i 88.88.88.88/32 6.6.6.6 0 100 0 8 i
* i 7.7.7.7 0 100 0 8 i
BGP only advertises the best path so that’s why PE1 only has an entry through PE3 to get to these prefixes. We
can change this behavior with the BGP additional paths feature. Let’s enable this on P2 and PE1 so that PE1
receives two paths.
P2 has to send additional paths:
P2(config)#router bgp 2
P2(config-router)#address-family ipv4
P2(config-router-af)#bgp additional-paths select all
P2(config-router-af)#neighbor 2.2.2.2 additional-paths send
P2(config-router-af)#neighbor 2.2.2.2 advertise additional-paths all
And PE1 needs to receive them:
PE1(config-router)#address-family ipv4
PE1(config-router-af)#neighbor 5.5.5.5 additional-paths receive
Now let’s take a look at PE1:
PE1#show ip bgp

*>i 8.8.8.8/32 6.6.6.6 0 100 0 8 i
* i 7.7.7.7 0 100 0 8 i
*>i 88.88.88.88/32 6.6.6.6 0 100 0 8 i
* i 7.7.7.7 0 100 0 8 i
Page 276 of 283

Very nice, we see two paths…one through PE3 and the other one through PE4. Only the path through PE3 is
installed though:
PE1#show ip bgp 8.8.8.8

2
Refresh Epoch 1
8
6.6.6.6 (metric 3) from 5.5.5.5 (5.5.5.5)
Refresh Epoch 1
8
7.7.7.7 (metric 3) from 5.5.5.5 (5.5.5.5)
We can change this with the bgp additional-paths command. Let’s configure PE1 to install the second path
as a backup:
PE1(config-router)#address-family ipv4
PE1(config-router-af)#bgp additional-paths install
Let’s check the BGP table again:
PE1#show ip bgp
t secondary path,

*>i 8.8.8.8/32 6.6.6.6 0 100 0 8 i
*bi 7.7.7.7 0 100 0 8 i
*>i 88.88.88.88/32 6.6.6.6 0 100 0 8 i
*bi 7.7.7.7 0 100 0 8 i
Note the b that stands for backup path. You can also see this if you take a closer look at a single prefix:
PE1#show ip bgp 8.8.8.8

2
Refresh Epoch 1
8
6.6.6.6 (metric 3) from 5.5.5.5 (5.5.5.5)
Page 277 of 283
Refresh Epoch 1
8
7.7.7.7 (metric 3) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, backup/repair
This entry gets installed in the FIB right away. Take a look here:
PE1#show ip cef 8.8.8.8 detail

Once the primary next hop (6.6.6.6) fails, we can forward to the backup (7.7.7.7) right away!
hostname CE1
!
ip cef
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.13.1 255.255.255.0
!
router bgp 1
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 8.8.8.8 255.255.255.255
!
interface Loopback1
ip address 88.88.88.88 255.255.255.255
!
ip address 192.168.68.8 255.255.255.0
!
ip address 192.168.78.8 255.255.255.0
!
router bgp 8
network 8.8.8.8 mask 255.255.255.255
network 88.88.88.88 mask 255.255.255.255
Page 278 of 283

!
end
hostname P1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.24.4 255.255.255.0
!
ip address 192.168.46.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
ip address 192.168.47.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
network 192.168.46.0 0.0.0.255 area 0
network 192.168.47.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname P2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.35.5 255.255.255.0
ip ospf cost 2
!
ip address 192.168.57.5 255.255.255.0
ip ospf cost 2
!
ip address 192.168.25.5 255.255.255.0
ip ospf cost 2
!
ip address 192.168.56.5 255.255.255.0
ip ospf cost 2
!
Page 279 of 283
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.25.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
network 192.168.56.0 0.0.0.255 area 0
network 192.168.57.0 0.0.0.255 area 0
!
router bgp 2
!
address-family ipv4
bgp additional-paths select all
neighbor 2.2.2.2 additional-paths send
neighbor 2.2.2.2 advertise additional-paths all
exit-address-family
!
end
hostname PE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.24.2 255.255.255.0
!
ip address 192.168.25.2 255.255.255.0
!
ip address 192.168.12.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.25.0 0.0.0.255 area 0
!
router bgp 2
Page 280 of 283
!
address-family ipv4
bgp additional-paths install
neighbor 5.5.5.5 additional-paths receive
exit-address-family
!
end
hostname PE2
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.35.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
ip address 192.168.13.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
network 192.168.35.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname PE3
!
ip cef
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 192.168.46.6 255.255.255.0
!
ip address 192.168.56.6 255.255.255.0
!
ip address 192.168.68.6 255.255.255.0
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0
network 192.168.46.0 0.0.0.255 area 0
Page 281 of 283
network 192.168.56.0 0.0.0.255 area 0
!
router bgp 2
!
end
hostname PE4
!
ip cef
!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
ip address 192.168.57.7 255.255.255.0
!
ip address 192.168.47.7 255.255.255.0
!
ip address 192.168.78.7 255.255.255.0
!
router ospf 1
network 7.7.7.7 0.0.0.0 area 0
network 192.168.47.0 0.0.0.255 area 0
network 192.168.57.0 0.0.0.255 area 0
!
router bgp 2
!
end
Conclusion
You have now learned what BGP PIC (Prefix Independent Convergence) is.
 BGP PIC (Prefix Independent Convergence) helps to decrease the data plane convergence time.
 There are two flavors:
o BGP PIC Core:
 helps when a core router fails, the BGP next hop does not change and your IGP has to
find a new path.
 BGP prefixes are installed in a flat FIB with the recursed next hop and outgoing interface.
When the next hop changes, the router has to go through all prefixes one-by-one in the
FIB and change the next hop.
 A hierarchical FIB stores the BGP and IGP path list. When an IGP next hop changes, you
don’t have to re-flatten the entire table again. This decreases convergence time in the data
plane.
Page 282 of 283
o BGP PIC Edge:
 helps when a PE router fails and BGP has to find a new next hop.
 BGP can pre-install a backup next hop for another BGP path in the FIB.
 When using iBGP and a route reflector, you’ll need to use the BGP additional paths
feature.
Page 283 of 283

BGP

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

BGP

Caricato da

Copyright:

Formati disponibili

Table of Contents

 What BGP is.

Presented to you by instructor Rene Molenaar, CCIE #41726

Why do we need BGP?

IANA IPv4 address space

UltraTools AS Information Lookup

BGP has two flavors:

 External BGP: used between autonomous systems

Looking glass servers

 They advertise only a default route.

Let’s walk through these three options![teaser]

Here’s what could happen if you only use default routes:

Partial Routing Updates

Full Internet Routing Table

Network Next Hop Metric LocPrf Weight Path

BGP Route Selection

Single/Dual Homed and Multi-homed Designs

Let’s take a look at some examples.

To increase redundancy, we can add a second router:

How to configure EBGP (External BGP)

R1# %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up

R1#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

R2 learned about network 1.1.1.0/24 with a next hop IP address of 192.168.12.1.

R1#show ip route bgp

R1(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2

R1#show ip bgp neighbors | include External

R1(config-router)#neighbor 192.168.23.3 disable-connected-check

R1(config-router)#no neighbor 192.168.23.3 disable-connected-check

And now we will increase the TTL:

R1(config-router)#neighbor 192.168.23.3 ebgp-multihop 2

That’s it, problem solved!

R1(config)#ip route 2.2.2.0 255.255.255.0 192.168.12.2

R1#show ip route static

Internal BGP (Border Gateway Protocol) explained

R1(config-router)#neighbor 192.168.12.2 remote-as 2

R2#show ip interface brief

R2#ping 4.4.4.4 source 2.2.2.2

Type escape sequence to abort.

First we’ll check R1:

Network Next Hop Metric LocPrf Weight Path

Let’s see what R2 thinks about this:

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

There’s nothing in R5…that’s because R4 is having some issues, look closely:

Network Next Hop Metric LocPrf Weight Path

 Advertise network 192.168.12.0 /24 in a routing protocol (IGP or BGP).

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

R5#show ip route bgp

Type escape sequence to abort.

Type escape sequence to abort.

1 192.168.45.4 52 msec 16 msec 32 msec

R3#show ip route 1.1.1.0

Network Next Hop Metric LocPrf Weight Path

Type escape sequence to abort.

Type escape sequence to abort.

No problem for R2, what about R3?

Type escape sequence to abort.

Gateway of last resort is not set