Introduction to BGP

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.

Autonomous Systems
An AS is a collection of networks under a single administrative domain.
How do we get an autonomous system number? Just like public IP address space you’ll
need to register one.

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.

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.
Short for Internal BGP (Border Gateway Protocol), iBGP is the protocol used between the
routers in the same autonomous system (AS). IBGP is used to provide information to your
internal routers.

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:
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.
Default Route

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.
Partial Routing Updates

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?
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:

A path vector protocol is a network routing protocol which maintains the path information that gets
updated dynamically.
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.

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.

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:

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
R2(config)#router bgp 2
R2(config-router)#neighbor 192.168.12.1 remote-as 1

R1(config)#router bgp 1
R1(config-router)#network 1.1.1.0 mask 255.255.255.0
R2(config)#router bgp 2
R2(config-router)#network 2.2.2.0 mask 255.255.255.0

For Authentication using MD5 Command:

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 password MYPASS
R2(config)#router bgp 2
R2(config-router)#neighbor 192.168.12.1 password MYPASS

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:

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.23.3 remote-as 3
R3(config)#router bgp 3
R3(config-router)#neighbor 192.168.12.1 remote-as 1
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.

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

R3(config-router)#neighbor 192.168.12.1 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.

Internal BGP (Border Gateway Protocol)

explained
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R1(config-router)#network 1.1.1.0 mask 255.255.255.0
R2(config-router)#neighbor 192.168.12.1 remote-as 1
R2(config)#interface loopback 0
R2(config-if)#ip address 2.2.2.2 255.255.255.0

R2(config)#router ospf 1
R2(config-router)#network 192.168.23.0 0.0.0.255 area 0
R2(config-router)#network 2.2.2.0 0.0.0.255 area 0
R2(config)#router bgp 2
R2(config-router)#neighbor 4.4.4.4 remote-as 2
R2(config-router)#neighbor 4.4.4.4 update-source loopback 0
R2(config)#router bgp 2
R2(config-router)#neighbor 4.4.4.4 next-hop-self
R2(config)#router bgp 2
R2(config-router)#neighbor 3.3.3.3 remote-as 2
R2(config-router)#neighbor 3.3.3.3 update-source loopback 0
R2(config-router)#neighbor 3.3.3.3 next-hop-self

R4(config)#interface loopback 0
R4(config-if)#ip address 4.4.4.4 255.255.255.0
R4(config)#router ospf 1
R4(config-router)#network 192.168.34.0 0.0.0.255 area 0
R4(config-router)#network 4.4.4.0 0.0.0.255 area 0
R4(config)#router bgp 2
R4(config-router)#neighbor 2.2.2.2 remote-as 2
R4(config-router)#neighbor 2.2.2.2 update-source loopback 0
R4(config)#router bgp 2
R4(config-router)#neighbor 192.168.45.5 remote-as 3
R4(config)#router bgp 2
R4(config-router)#neighbor 2.2.2.2 next-hop-self
R4(config)#router bgp 2
R4(config-router)#neighbor 3.3.3.3 remote-as 2
R4(config-router)#neighbor 3.3.3.3 update-source loopback 0
R4(config-router)#neighbor 3.3.3.3 next-hop-self
R3(config)#router ospf 1
R3(config-router)#network 192.168.23.0 0.0.0.255 area 0
R3(config-router)#network 192.168.34.0 0.0.0.255 area 0
R3(config)#interface loopback 0
R3(config-if)#ip address 3.3.3.3 255.255.255.0
R3(config)#router ospf 1
R3(config-router)#network 3.3.3.0 0.0.0.255 area 0
R3(config)#router bgp 2
R3(config-router)#neighbor 2.2.2.2 remote-as 2
R3(config-router)#neighbor 2.2.2.2 update-source loopback 0
R3(config-router)#neighbor 4.4.4.4 remote-as 2
R3(config-router)#neighbor 4.4.4.4 update-source loopback 0

R5(config)#router bgp 3
R5(config-router)#neighbor 192.168.45.4 remote-as 2

R5(config)#router bgp 3
R5(config-router)#network 192.168.45.0 mask 255.255.255.0

How to Read the BGP Table

R4#show ip bgp
BGP table version is 2, local router ID is 192.168.34.4
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 Network Next Hop Metric LocPrf Weight Path
*> 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.
 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.

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.

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:

 Network command
 Redistribution

Note:

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:

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:
R1#show ip route 1.0.0.0
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

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)#interface loopback 3
R1(config-if)#ip address 111.111.111.111 255.255.255.0
R1(config-if)#exit

R1(config)#router ospf 1
R1(config-router)#network 111.111.111.0 0.0.0.255 area 0

R1(config)#router bgp 1
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:

R1#show ip bgp | begin Network

Network Next Hop Metric LocPrf Weight Path
*> 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 ?

BGP Next Hop Self

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:
R1(config)#router bgp 12
R1(config-router)#neighbor 192.168.12.2 remote-as 12
R2(config)#router bgp 12
R2(config-router)#neighbor 192.168.12.1 remote-as 12
R2(config-router)#neighbor 192.168.23.3 remote-as 3
R3(config)#router bgp 3
R3(config-router)#neighbor 192.168.23.2 remote-as 12
R3(config-router)#network 3.3.3.0 mask 255.255.255.0

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
BGP table version is 2, local router ID is 192.168.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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
BGP table version is 1, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* i3.3.3.0/24 192.168.23.3 0 100 0 3 i

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:

R2(config)#router bgp 12
R2(config-router)#network 192.168.23.0 mask 255.255.255.0

Now take a look at R1:

R1#show ip bgp
BGP table version is 3, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>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:

This will work but there is another solution that is easier. Let’s clean up before we continue:

R2(config)#router bgp 12
R2(config-router)#no network 192.168.23.0 mask 255.255.255.0

Now we can try something else…

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:

R2(config)#router bgp 12
R2(config-router)#neighbor 192.168.12.1 next-hop-self
R1#show ip bgp
BGP table version is 6, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i3.3.3.0/24 192.168.12.2 0 100 0 3 i

BGP Auto-Summary
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.

R1(config)#router bgp 1
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:

R1#show ip bgp 1.0.0.0

% Network not in table

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 bgp 1
R1(config-router)#auto-summary

After enabling auto-summary things will change. Take a look at the BGP table of R1:

R1#show ip bgp 1.0.0.0

BGP routing table entry for 1.0.0.0/8, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
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

Chapter 2
BGP Neighbor Adjacency States
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.

BGP Messages

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

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. 

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).

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.

Notification Message
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.

Chapter 3 BGP Attributes

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.
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:

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 weight 500

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.

R2(config)#router bgp 2
R2(config-router)#bgp default local-preference 800

Or we can use on route-map:

R3(config)#route-map LOCALPREF permit 10
R3(config-route-map)#set local-preference 700

R3(config)#router bgp 2
R3(config-router)#neighbor 192.168.13.1 route-map LOCALPREF in

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:

R1(config)#route-map PREPEND permit 10

R1(config-route-map)#set as-path prepend 1 1 1 1 1
R1(config-route-map)#exit
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 route-map PREPEND out

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:

 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.

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.
 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.

R2(config)#route-map MED permit 10

R2(config-route-map)#set metric 200
R2(config-route-map)#exit

R2(config)#router bgp 1
R2(config-router)#neighbor 192.168.12.2 route-map MED out
R3(config)#route-map MED permit 10
R3(config-route-map)#set metric 300
R3(config-route-map)#exit

R3(config)#router bgp 1
R3(config-router)#neighbor 192.168.23.2 route-map MED out

Chapter 4
BGP Communities
The BGP community attribute is a numerical value that can be assigned to a specific prefix and
advertised to other neighbors. When the neighbor receives the prefix it will examine
the community value and take proper action whether it is filtering or modifying other attributes.

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:

 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).
BGP Community No Advertise
The BGP No Advertise community is one of the four well known 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 (iBGP) or R4 (eBGP).

R1(config)#route-map NO_ADVERTISE permit 10

R1(config-route-map)#set community no-advertise

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 send-community

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 route-map NO_ADVERTISE out

BGP Community No Export

The well known BGP community no export tells BGP neighbors to advertise a
prefix only to iBGP neighbors
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.

R1(config)#route-map NO_EXPORT permit 10

R1(config-route-map)#set community no-export
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 send-community
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 route-map NO_EXPORT out

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.
To demonstrate this I will use the following topology:
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…
R2(config)#route-map LOCAL_AS permit 10
R2(config-route-map)#set community local-AS

R2(config)#router bgp 23
R2(config-router)#neighbor 192.168.12.1 route-map LOCAL_AS in
R2(config-router)#neighbor 3.3.3.3 send-community

Chapter 5 BGP Filtering

BGP Regular Expressions Examples
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.

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.

matches prefixes that originated in AS 51, the $ ensures that it’s the
 _51$
beginning of the AS PATH.

matches prefixes from AS 51 where AS 51 is behind one of our directly

 ^([0-9]+)_51
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
9]+) might be doing AS PATH prepending.

 ^51_([0-9]+_) matches prefixes from the clients of directly connected AS 51, where the
+ clients might be doing AS PATH prepending.

^\65200\) matches prefixed from confederation peer 65200.

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.

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. 

Filter-list with AS PATH access-list

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.
No-Export Community

R1(config)#route-map NO-EXPORT
R1(config-route-map)#set community no-export

R1(config)#router bgp 1
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.

ISP1#show ip bgp
BGP table version is 11, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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

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:

ISP1#show ip bgp
BGP table version is 17, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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

Distribute-list Filtering
This method is similar to using the prefix-list but this time we’ll use an access-list.

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
BGP table version is 23, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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

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
R1(config)#router bgp 1
R1(config-router)#bgp router-id 1.1.1.1
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
R1(config-router-af)#network 2001:db8:0:11::/64
R1(config-router-af)#network 2001:db8:0:111::/64
R1(config-router-af)#network 2001:db8:0:1111::/96
R2(config)#router bgp 2
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#neighbor 2001:db8:0:12::1 remote-as 1
R2(config-router)#address-family ipv6
R2(config-router-af)#neighbor 2001:db8:0:12::1 activate

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]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:111::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:1111::/96 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/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 bgp 2
R2(config-router)#address-family ipv6
R2(config-router-af)#neighbor 2001:db8:0:12::1 prefix-list
SMALL_NETWORKS in

Let’s check R2 to see if our prefix is gone:

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]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:111::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0

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 PREPEND permit 10

R1(config-route-map)#match ipv6 address prefix-list FIRST_LOOPBACK
R1(config-route-map)#set as-path prepend 11
R1(config)#route-map PREPEND permit 20
R1(config)#router bgp 1
R1(config-router)#address-family ipv6
R1(config-router-af)#neighbor 2001:db8:0:12::2 route-map PREPEND
out

BGP AS Path Filter Example

 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
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$

BGP table version is 4492538, local router ID is 213.200.87.253
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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:
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 remote-as 3257
neighbor 213.200.64.93 route-map AS_PATH_FILTER in
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_

BGP table version is 4492787, local router ID is 213.200.87.253
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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_

route-map AS_PATH_FILTER permit 10

match as-path 1

router bgp 1
neighbor 213.200.64.93 remote-as 3257
neighbor 213.200.64.93 route-map AS_PATH_FILTER in

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:
route-server.as3257.net>show ip bgp regexp _56203$
BGP table version is 4493689, local router ID is 213.200.87.253
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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 .*

route-map AS_PATH_FILTER permit 10

match as-path 1

router bgp 1
neighbor 213.200.64.93 remote-as 3257
neighbor 213.200.64.93 route-map AS_PATH_FILTER in

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]*$

BGP table version is 4493802, local router ID is 213.200.87.253
Status codes: s suppressed, d damped, h history, * valid, > best, i
- internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 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 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]*$

route-map AS_PATH_FILTER permit 10

match as-path 1

router bgp 1
neighbor 213.200.64.93 remote-as 3257
neighbor 213.200.64.93 route-map AS_PATH_FILTER in
That’s it for now! I hope these examples are helpful to understand regular expressions a bit
more and how to configure the as-path access-list on a Cisco IOS router. If you have any
questions, feel free to ask.

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.

Without BGP Peer Group

Here’s what our BGP configuration on R1 would look like:

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 2
R1(config-router)#neighbor 3.3.3.3 remote-as 3
R1(config-router)#neighbor 4.4.4.4 remote-as 4
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R1(config-router)#neighbor 3.3.3.3 update-source loopback 0
R1(config-router)#neighbor 4.4.4.4 update-source loopback 0
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R1(config-router)#neighbor 3.3.3.3 ebgp-multihop 2
R1(config-router)#neighbor 4.4.4.4 ebgp-multihop 2

With BGP Peer Group

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 2
R1(config-router)#neighbor 3.3.3.3 remote-as 3
R1(config-router)#neighbor 4.4.4.4 remote-as 4
R1(config-router)#neighbor R2_R3_R4 peer-group
R1(config-router)#neighbor 2.2.2.2 peer-group R2_R3_R4
R1(config-router)#neighbor 3.3.3.3 peer-group R2_R3_R4
R1(config-router)#neighbor 4.4.4.4 peer-group R2_R3_R4
R1(config-router)#neighbor R2_R3_R4 update-source loopback 0
R1(config-router)#neighbor R2_R3_R4 ebgp-multihop 2

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.

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:

RR:
router bgp 1
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 remote-as 1
neighbor 192.168.12.2 route-reflector-client
neighbor 192.168.13.3 remote-as 1
neighbor 192.168.13.3 route-reflector-client
neighbor 192.168.14.4 remote-as 1
neighbor 192.168.14.4 route-reflector-client
neighbor 192.168.15.5 remote-as 1
neighbor 192.168.15.5 route-reflector-client

Route Reflector with Cluster-id

R5:
router bgp 65000
bgp cluster-id 3.3.3.3
network 5.5.5.5 mask 255.255.255.255
neighbor 1.1.1.1 remote-as 65000
neighbor 3.3.3.7 remote-as 65000
neighbor 192.168.14.6 remote-as 65000
neighbor 192.168.15.4 remote-as 65000
R6:
network 6.6.6.6 mask 255.255.255.255
neighbor 192.168.14.5 remote-as 65000

BGP Confederation Explained

To reduce the number of IBGP peerings there are two techniques:

 Confederations
 Route Reflector

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.

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

R2(config)#router ospf 1
R2(config-router)#network 192.168.23.0 0.0.0.255 area 0
R2(config-router)#network 192.168.24.0 0.0.0.255 area 0
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0
R3(config)#router ospf 1
R3(config-router)#network 192.168.23.0 0.0.0.255 area 0
R3(config-router)#network 192.168.35.0 0.0.0.255 area 0
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
R4(config)#router ospf 1
R4(config-router)#network 192.168.24.0 0.0.0.255 area 0
R4(config-router)#network 192.168.45.0 0.0.0.255 area 0
R4(config-router)#network 4.4.4.4 0.0.0.0 area 0
R5(config)#router ospf 1
R5(config-router)#network 192.168.35.0 0.0.0.255 area 0
R5(config-router)#network 192.168.45.0 0.0.0.255 area 0
R5(config-router)#network 5.5.5.5 0.0.0.0 area 0
R2(config)#router bgp 24
R2(config-router)#bgp confederation identifier 2
R2(config-router)#bgp confederation peers 35
R2(config-router)#neighbor 4.4.4.4 remote-as 24
R2(config-router)#neighbor 4.4.4.4 update-source loopback 0
R2(config-router)#neighbor 3.3.3.3 remote-as 35
R2(config-router)#neighbor 3.3.3.3 update-source loopback 0
R2(config-router)#neighbor 3.3.3.3 ebgp-multihop 2
R3(config)#router bgp 35
R3(config-router)#bgp confederation identifier 2
R3(config-router)#bgp confederation peers 24
R3(config-router)#neighbor 2.2.2.2 remote-as 24
R3(config-router)#neighbor 2.2.2.2 update-source loopback 0
R3(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R3(config-router)#neighbor 5.5.5.5 remote-as 35
R3(config-router)#neighbor 5.5.5.5 update-source loopback 0
R4(config)#router bgp 24
R4(config-router)#bgp confederation identifier 2
R4(config-router)#bgp confederation peers 35
R4(config-router)#neighbor 2.2.2.2 remote-as 24
R4(config-router)#neighbor 2.2.2.2 update-source loopback 0
R4(config-router)#neighbor 5.5.5.5 remote-as 35
R4(config-router)#neighbor 5.5.5.5 update-source loopback 0
R4(config-router)#neighbor 5.5.5.5 ebgp-multihop 2
R5(config)#router bgp 35
R5(config-router)#bgp confederation identifier 2
R5(config-router)#bgp confederation peers 24
R5(config-router)#neighbor 4.4.4.4 remote-as 24
R5(config-router)#neighbor 4.4.4.4 update-source loopback 0
R5(config-router)#neighbor 4.4.4.4 ebgp-multihop 2
R5(config-router)#neighbor 3.3.3.3 remote-as 35
R5(config-router)#neighbor 3.3.3.3 update-source loopback 0

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R2(config)#router bgp 24
R2(config-router)#neighbor 192.168.12.1 remote-as 1

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:

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.

R1(config)#router ospf 1
R1(config-router)#network 192.168.12.0 0.0.0.255 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R2(config)#router ospf 1
R2(config-router)#network 192.168.12.0 0.0.0.255 area 0
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0

R1(config-router)#neighbor 192.168.13.3 remote-as 3

R1(config-router)#network 1.1.1.1 mask 255.255.255.255
R2(config-router)#neighbor 192.168.23.3 remote-as 3
R2(config-router)#network 2.2.2.2 mask 255.255.255.255
R3(config)#router bgp 3
R3(config-router)#neighbor 192.168.13.1 remote-as 1
R3(config-router)#neighbor 192.168.23.2 remote-as 2

R1#show ip route | incl 2.2

B 2.2.2.2 [20/0] via 192.168.13.3, 00:00:45
R2#show ip route | incl 1.1
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

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
R1#show ip route | incl 2.2
O 2.2.2.2 [110/2] via 192.168.12.2, 00:00:42,
FastEthernet0/0

R2#show ip route | incl 1.1

O 1.1.1.1 [110/2] via 192.168.12.1, 00:00:28,
FastEthernet0/0