Contents

Unit 1: Introduction to BGP................................................................................................................3

Internal BGP (Border Gateway Protocol) explained..................................................................3

How to advertise networks in BGP................................................................................................5

BGP Next Hop Self............................................................................................................................5

BGP Auto-Summary...........................................................................................................................9

Unit 2: BGP Neighbor Adjacency......................................................................................................12

BGP Neighbor Adjacency States....................................................................................................12

BGP Messages.....................................................................................................................................14

Unit 3: BGP Attribute.......................................................................................................................15

BGP Attributes and Path Selection.............................................................................................15

Attributes...........................................................................................................................................16

Weight..................................................................................................................................................17

Local Preference.................................................................................................................................18

Originate..............................................................................................................................................18

AS path length..................................................................................................................................19

BGP Origin Code Attribute explained..........................................................................................19

MED......................................................................................................................................................19

eBGP path over iBGP path............................................................................................................20

Shortest IGP path to BGP next hop..........................................................................................20

Oldest Path........................................................................................................................................20

Router ID............................................................................................................................................20

Neighbor IP address..........................................................................................................................20

Path Selection....................................................................................................................................21

Unit 4: BGP Communities..................................................................................................................21

BGP Communities Explained...........................................................................................................21

 BGP Community No Advertise......................................................................................................22

BGP Community No Export...........................................................................................................22

BGP Community Local AS..............................................................................................................23

Unit 5: BGP Filtering..........................................................................................................................24

BGP Regular Expressions Examples...............................................................................................24

BGP Prevent Transit AS.................................................................................................................26

Filter-list with AS PATH access-list........................................................................................27

No-Export Community.................................................................................................................27

Prefix-List Filtering......................................................................................................................28

Distribute-list Filtering................................................................................................................28

BGP AS Path Filter Example.........................................................................................................29

Only allow prefixes that originated from AS 3257............................................................29

Only allow networks that passed through AS 3257...........................................................30

Deny prefixes that originated from AS 56203 and permit everything else................31

Allow prefixes from AS 3257 and its directly connected ASes but deny the rest...33

BGP Extended Access-List Filtering.............................................................................................34

Filter all 192.168.x.0 networks with a /24 prefix length................................................39

Filter all 10.x.x.0 networks with a /24 prefix length.......................................................41

Filter all 10.x.x.x networks with a /25 prefix length........................................................43

Filter all 192.168.7.x networks with any prefix length.....................................................45

Filter anything with a /24 to /32 prefix length................................................................46

Filter anything with a /26 to /32 prefix length................................................................50

Filter 172.16.0.0 networks with a /27 to /32 prefix length.........................................54

Unit 1: Introduction to BGP
BGP (External BGP):
External Border Gateway Protocol (eBGP) is a BGP term or process used when
referring to BGP peers or neighbors that are in a different Autonomous System
and Number (ASN).
In other words, eBGP is used to exchange route information between different
autonomous systems.

Internal BGP (Border Gateway Protocol) explained

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

How to advertise networks in BGP

There are two methods how we can do this:

 Network command
 Redistribution

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

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 learns the prefix but it’s unable to install it in the routing table:

R1#show ip route bgp

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

C 192.168.12.0/24 is directly connected, FastEthernet0/0

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:

R1#show ip route bgp

3.0.0.0/24 is subnetted, 1 subnets
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
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

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

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:

R1#show ip route bgp

3.0.0.0/24 is subnetted, 1 subnets
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!

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

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

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
BGP table version is 2, local router ID is 192.168.12.2
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, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.0.0.0 192.168.12.1 0 0 1 i
Unit 2: BGP Neighbor Adjacency

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

BGP Messages

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. Here are some of the items you will find in the open
message:
  Version: this includes the BGP version that the router is using.
 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. Both routers have to agree on the hold time or there won’t be
a BGP session.
Update Message

Once two routers have become BGP neighbors, they can start exchanging routing
information. This is done with the update message.

Keepalive Message

When a router has no UPDATE messages to send, it periodically

sends KEEPALIVE messages, which, well, keep the BGP session alive.
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.

Unit 3: BGP Attribute

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.

Attributes

This path was selected based on the following attributes:

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

Weight

Weight is a Cisco proprietary BGP attributes that can be used to select a

certain path. ... Weight is not exchanged between BGP routers. Weight is only
local on the router. The path with the highest weight is preferred.
Local Preference

BGP attribute local preference is the second BGP attribute and it can be used

to choose the exit path for an autonomous system. ... Not exchanged between
external BGP routers.

We prefer the path with the highest local preference. The default value is 100.

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

The fourth BGP attribute is called AS Path:

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.

 BGP prefers the shortest AS path to get to a destination. Less is more!

 We can manipulate this by using AS path prepending.
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 ?)

MED

 MED (or metric) is the sixth BGP attribute:

 Prefer the path with the lowest MED. The MED is exchanged between
autonomous systems.

 MED can be used to advertise to your neighbors how they should enter

your AS.
 MED is propagated to all routers within the neighbor AS but not passed
along any other autonomous systems.
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:
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.

Unit 4: BGP Communities

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

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

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.

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…

Unit 5: BGP Filtering

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.

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

 _51$
the beginning of the AS PATH.
 matches prefixes from AS 51 where AS 51 is behind one of our
 ^([0-9]+)_51
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,

9]+) where AS 51 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

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

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

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.

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

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

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

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

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

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

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.

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

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

R2#show ip bgp neighbors 192.168.12.1 advertised-routes

BGP table version is 35, local router ID is 192.168.7.25
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, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

Total number of prefixes 34

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)#access-list 100 permit ip 172.16.0.0 0.0.0.0 255.255.255.0 0.0.0.0
R1(config)#access-list 100 permit ip 192.168.1.0 0.0.0.0 255.255.255.0 0.0.0.0

R1(config)#router bgp 1
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 /16 so we use subnet mask 255.255.0.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
BGP table version is 4, 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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

Great, we only see our three specific prefixes. 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.

BGP table version is 36, local router ID is 192.168.7.17
*> 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(config)#access-list 101 permit ip 192.168.0.0 0.0.255.0 255.255.255.0

0.0.0.0

R1(config)#router bgp 1
R1(config-router)#distribute-list 101 in

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.
Here’s the result:
R1#show ip bgp
BGP table version is 4, 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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

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(config)#access-list 102 permit ip 10.0.0.0 0.255.255.0 255.255.255.0

0.0.0.0

R1(config)#router bgp 1
R1(config-router)#distribute-list 102 in

R1#clear ip bgp *

Let me explain the access-list:

 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
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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

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(config)#access-list 103 permit ip 10.0.0.0 0.255.255.255 255.255.255.128

0.0.0.0
R1(config)#router bgp 1
R1(config-router)#distribute-list 103 in

R1#clear ip bgp *

Let me explain the access-list:

 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
BGP table version is 5, 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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

BGP table version is 36, local router ID is 192.168.7.17
*> 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(config)#access-list 104 permit ip 192.168.7.0 0.0.0.255 255.255.255.0

0.0.0.255

R1(config)#router bgp 1
R1(config-router)#distribute-list 104 in

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
BGP table version is 5, 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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

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:

R2#show ip bgp neighbors 192.168.12.1 advertised-routes

BGP table version is 35, local router ID is 192.168.7.25
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, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
 Network Next Hop Metric LocPrf Weight Path
*> 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
Network Next Hop Metric LocPrf Weight Path
*> 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

Total number of prefixes 34

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:

R1(config)#access-list 105 permit ip 0.0.0.0 255.255.255.255 255.255.255.0

0.0.0.255

R1(config)#router bgp 1
R1(config-router)#distribute-list 105 in

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
BGP table version is 33, 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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

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:

R2#show ip bgp neighbors 192.168.12.1 advertised-routes

BGP table version is 35, local router ID is 192.168.7.25
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, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
 Network Next Hop Metric LocPrf Weight Path
*> 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

Total number of prefixes 34

Time to clean up that BGP table. Here’s the access-list we need:

R1(config)#access-list 106 permit ip 0.0.0.0 255.255.255.255 255.255.255.192

0.0.0.63

R1(config)#router bgp 1
R1(config-router)#distribute-list 106 in

R1#clear ip bgp *

Here’s how the access-list works:

 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
BGP table version is 15, 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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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

R1(config-router)#distribute-list 107 in

R1#clear ip bgp *

Here’s how the access-list works:

 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
BGP table version is 4, 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, m multipath, b backup-path, x best-external, f
RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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.
Unit 6: Advanced BGP Features

BGP Peer Groups

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.

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:

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

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.

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

 Confederations
 Route Reflector
Let’s talk about confederations, look at the picture below:

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

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.

Multiprotocol BGP (MP-BGP) Configuration