BGP Info

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 well 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:
Now you know about the different states, lets take a look at some Cisco BGP routers to see what it actually
looks like on two routers. Ill use the following topology for this:
Just two routers in two different autonomous systems. Before I configure BGP, lets enable a debug:
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
All of these BGP messages use a fixed-size header, it includes a type field that indicates what type of message it
is.
To explain these BGP messages I will show you some Wireshark captures. I will use the following topology for
this:
Open Message
Once two BGP routers have completed a TCP 3-way handshake they will attempt to establish a BGP session,
this is done using open messages. In the open message you will find some information about the BGP router,
these have to be negotiated and accepted by both routers before we can exchange any routing information. Here
are some of the items you will find in the open message:
Version: this includes the BGP version that the router is using. The current version of BGP is version 4
which is described in RFC 4271. Two BGP routers will try to negotiate a compatible version, when there
is a mismatch then there will be no BGP session.
My AS: this includes the AS number of the BGP router, the routers will have to agree on the AS
number(s) and it also defines if they will be running iBGP or eBGP.
Hold Time: if BGP doesnt 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 wont be a BGP session.
BGP Identifier: this is the local BGP router ID which is elected just like OSPF does:
o Use the router-ID that was configured manually with the bgp router-id command.
o Use the highest IP address on a loopback interface.
o Use the highest IP address on a physical interface.
Optional Parameters: here you will find some optional capabilities of the BGP router. This field has
been added so that new features could be added to BGP without having to create a new version.Things
you might find here are:
o support for MP-BGP (Multi Protocol BGP).
o support for Route Refresh.
o support for 4-octet AS numbers.
Heres an example of a wireshark capture of an open message between R1 and R2:
Above you can see the open message from R1 to R2. You can see the things that we discussed, the BGP version,
AS number, hold time, BGP ID and the optional parameters (MP-BGP and route refresh). The marker field on
top is used to indicate if we use MD5 authentication or not. When its filled with 1s then we are not using
authentication.
Update Message
Once two routers have become BGP neighbors, they can start exchanging routing information. This is done with
the update message. In the update message you will find information about the prefixes that are advertised.In
BGP language a prefix is referred to as NLRI (Network Layer Reachability Information). Here are some
of the things you will find in an update message:
Withdrawn Route Length: this field shows the length of the Withdrawn Routes field in bytes. When it is
set to 0, there are no routes withdrawn and the Withdrawn Routes field will not show up.
Withdrawn Routes: this field shows all the prefixes that should be removed from the BGP table.
Total Path Attribute Length: here you will find the total length of the Path Attributes field.
Path Attributes: the BGP attributes for the prefix are stored here, for example: origin, as_path, next_hop,
med, local preference, etc. These path attributes are stored in TLV-format (Type, Length, Value).
Each of the BGP attributes also has an attribute flag that tells the BGP router how to treat the attribute. Here
are the different bit flags:
Optional: when the attribute is well-known this bit is set to 0, when its optional it is set to 1.
Transitive: when an optional attribute is non-transitive this bit is set to 0, when it is transitive it is set to
1.
Partial: when an optional attribute is complete this bit is set to 0, when its partial it is set to 1.
Extended Length: when the attribute length is 1 octet it is set to 0, for 2 octets it is set to 1. This
extended length flag may only be used if the length of the attribute value is greater than 255 octets.
Lets take a look at an update message from R1:

R1(config)#router bgp 1
R1(config-router)#network 1.1.1.1 mask 255.255.255.255
Heres the capture:
Above you can see a update message from R1. No routes are withdrawn and there are a couple of BGP
attributes. You can see the ORIGIN, AS_PATH and MULTI_EXIT_DISC (MED). I also highlighted some of the
flags. The AS_PATH attribute is transitive while MULTI_EXIT_DISC is optional. At the bottom you can find
the NLRI information with our prefix.
Lets remove the network command for the loopback interface on R1 so that we can see a withdrawn in the
update message:
R1(config)#interface loopback 0
R1(config-if)#shutdown
Troubleshooting BGP Neighbor Adjacency

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

Heres the first topology:
Two BGP routers which are connected and configured for EBGP. Unfortunately we are seeing this when check
the BGP neighbor adjacency:
R1#show ip bgp summary
BGP router identifier 192.168.12.1, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor
V
AS MsgRcvd MsgSent
TblVer InQ OutQ Up/Down State/PfxRcd
192.168.12.2
4
2
8
8
0
0
0 00:00:06 Active
Neighbor
192.168.12.1
V
4
AS MsgRcvd MsgSent
1
8
8
TblVer
0
InQ OutQ Up/Down State/PfxRcd

0
0 00:00:59 Active
When two EBGP routers that are directly connected do not form a working BGP neighbor adjacency there could
be a number of things that are wrong:
Layer 2 down preventing us from reaching the other side.
Layer 3 issue: wrong IP address on one of the routers.
Access-list blocking TCP port 179 (BGP).
Wrong IP address configured for BGP neighbor router.
The IP addresses that were used for the neighbor adjacency look OK so something else might be the issue. Lets
try a quick ping:
R1#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
I can do a quick ping and Ill see that Im unable to reach the other side. Since layer 3 isnt working, lets take a
look at layer 1 and 2:
R1#show ip int brief
Interface
FastEthernet0/0
R2#show ip int brief
Interface
FastEthernet0/0
IP-Address
OK? Method Status
192.168.12.1
YES manual up up
IP-Address
192.168.12.2
Protocol
OK? Method Status

Protocol
YES manual administratively down down
Well check the interfaces and find out that someone left a shutdown command on the interfacelets fix it:
R2(config)#interface FastEthernet 0/0
R2(config-if)#no shutdown
After enabling the interface you should see this:

R1# %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up
R2# %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up
Thats what we like to see. Our BGP neighbor adjacency is established

Lesson learned: Make sure your interfaces are up and running.
EBGP Requirements
Same topology but another issue. The goal in this scenario is to establish the EBGP neighbor adjacency between
the IP addresses on the loopback interfaces.
Let me show you what the BGP configuration looks like:
R1#show run | section bgp
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
no auto-summary
router bgp 2
no synchronization
no auto-summary
Heres the BGP configuration, you can see that we are using the loopback interfaces to establish a BGP
neighbor adjacency. Theres no BGP neighbor adjacency:

Neighbor
V
AS MsgRcvd MsgSent
TblVer InQ OutQ Up/Down
2.2.2.2
4
2
0
0
0
0
0 never
State/PfxRcd
Idle
Neighbor
1.1.1.1
State/PfxRcd
Idle
V
4
AS MsgRcvd MsgSent
1
0
0
TblVer
0
InQ OutQ Up/Down

0
0 never
Both routers show their BGP neighbor as idle. There are a number of things we have to check here:
Is the IP address of the BGP neighbor reachable? We are not using the directly connected links so we
might have routing issues.
The TTL of IP packets that we use for external BGP is 1. This works for directly connected networks but
if its not directly connected we need to change this behavior.
By default BGP will source its updates from the IP address that is closest to the BGP neighbor. In our
example thats the FastEthernet interface. This is something well have to change.
Lets check if the IP address of the remote neighbor is reachable, take a look at the routing tables:
R1#show ip route
C
192.168.12.0/24 is directly connected, FastEthernet0/0
R2#show ip route
C
Both routers only know about their directly connected networks. In order to reach each others loopback
interfaces well use static routing:
R1(config)#ip route 2.2.2.2 255.255.255.255 192.168.12.2
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
Two static routes should do the job. Lets give it a try:

R1#ping 2.2.2.2 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Sending a ping to IP address 2.2.2.2 and sourcing it from my own loopback interface proves that both routers
know how to reach each others loopback interface. Since we dont use the directly connected interfaces for the
peering, we also have to increase the TTL:
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
The ebgp-multihop command changes the TTL to 2. Now take a look at a debug:
R2#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
BGPNSF state: 1.1.1.1 went from nsf_not_active to nsf_not_active
BGP: 1.1.1.1 went from Active to Idle
BGP: 1.1.1.1 went from Idle to Active
BGP: 1.1.1.1 open active delayed 31810ms (35000ms max, 28% jitter)
BGP: 1.1.1.1 open active, local address 192.168.12.2
BGP: 1.1.1.1 open failed: Connection refused by remote host, open active delayed 34480ms
(35000ms max, 28% jitter)
We can enable a debug to see the progress. You can clearly see that R2 is using IP address 192.168.12.2 and that
R1 is refusing the connection. This is because we use the wrong source IP address. We have to tell BGP to use
another IP address:
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R2(config-router)#neighbor 1.1.1.1 update-source loopback 0
Use the update-source command to change the source IP address for the BGP updates. After making these
changes, the problem should be fixed:
R1#
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
R2#
%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
There goes! A working BGP neighbor adjacency.

Lesson learned: BGP routers dont have to establish a neighbor adjacency using the directly connected
interfaces. Make sure the BGP routers can reach each other, that BGP packets are sourced from the
correct interface and in case of EBGP dont forget to use the multihop command.
Troubleshooting BGP Route Advertisement
Once your BGP neighbor adjacency is up and running then you can try to troubleshoot issues with route
advertisements. In a previous lesson I explained how to fix BGP neighbor adjacencies, this time well focus on
route advertisements. Lets look at some examples!
BGP Network Command

Lets start with an EBGP scenario:
R1 and R2 are in different autonomous systems. We are trying to advertise network 1.1.1.0 /24 from R1 to R2
but its not showing up on R2. Here are the configurations:
no synchronization
network 1.1.1.0
no auto-summary
router bgp 2
no synchronization
no auto-summary
At first sight there seems to be nothing wrong here. Lets see if R2 learned anything:
Neighbor
V
192.168.12.1 4
AS MsgRcvd MsgSent
1
4
4
TblVer
1

0
0 00:01:26
0
However R2 didnt learn any prefixes from R1. Perhaps we have a filter?
R1#show ip
Outgoing
Incoming
R2#show ip
Outgoing
Incoming
protocols | include filter

update filter list for all
protocols | include filter
interfaces is not set

Maybe theres a distribute-list but thats not the case here. Lets check the network commands on R1:
R1#show run | section router bgp
router bgp 1
no synchronization
network 1.1.1.0
no auto-summary
The problem is the network command, it works differently for BGP vs our IGPs. If we configure a network
command for BGP it has to be an exact match. In this case I forgot to add the subnet masklets fix it:
I have to make sure I type the correct subnet mask. Now check R2 again:
R2#show ip bgp summary | begin Neighbor
Neighbor
V
AS MsgRcvd MsgSent
TblVer InQ OutQ Up/Down State/PfxRcd
192.168.12.1 4
1
9
8
2
0
0 00:05:15
1
R2#show ip route bgp
1.0.0.0/24 is subnetted, 1 subnets
B
1.1.1.0 [20/0] via 192.168.12.1, 00:01:08
Now you can see we learned the prefix and R2 installs it in the routing tableproblem solved!
Lesson learned: Type in the exact correct subnet maskBGP is picky!
BGP Summarization
Lets move onto the next scenario.
The network engineer from AS1 wants to advertise a summary to AS 2. The network engineer from AS 2 is
complaining however that hes not receiving anythinglets find out what is going wrong! Here are the
configurations:
router bgp 1
no synchronization
aggregate-address 172.16.0.0 255.255.0.0
no auto-summary
router bgp 2
no synchronization
no auto-summary
You can see the aggregate-address command on R1 for network 172.16.0.0 /16. Did R2 receive anything?
Neighbor
V
AS MsgRcvd MsgSent
TblVer
192.168.12.1 4
1
21
19
3

0
0 00:16:21
0
Too badno prefixes have been received by R2. There are two things I could check here:
See if a distribute-list is blocking prefixes inbound like I did in the previous example.
See what R1 has in its routing table (cant advertise what I dont have!).
Lets start with the routing table of R1 since I think by now you know what a distribute-list looks like..
R1#show ip route
C
C

1.1.1.0 is directly connected, Loopback0
Theres nothing here that looks even close to 172.16.0.0 /16. If we want to advertise a summary we have to put
something in the routing table of R1 first. Let me show you the different options:
R1(config)#interface loopback 0
R1(config-if)#ip address 172.16.0.1 255.255.255.0
R1(config-if)#exit
This is option 1: Ill create a loopback interface and configure an IP address that falls within the range of the
aggregate-address command. The summary can now be advertised to R2:
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
B
172.16.0.0/24 [20/0] via 192.168.12.1, 00:01:25
B
172.16.0.0/16 [20/0] via 192.168.12.1, 00:01:25
Now we see the summary in the routing table of R2. By default it will still advertise the other prefixes. If you
dont want this you need to use the aggregate-address summary-only command!
Let me show you option 2 of advertising the summary:
R1(config)#ip route 172.16.0.0 255.255.0.0 null 0
First well put the 172.16.0.0 /16 network in the routing table by creating a static route and pointing it to the
null0 interface. Secondly Ill use a network command for BGP to advertise this network. The result will be this:
B
172.16.0.0/16 [20/0] via 192.168.12.1, 00:00:45
Now it shows up on R2! Problem solved!
Lesson learned: You cant advertise what you dont have. Create a static route and point it to the null0
interface or create a loopback interface that has a prefix that falls within the summary address range.
BGP Auto-Summary
Next problem coming up, this is the topology:
Onto the next scenario. You are working as a network engineer for AS 1 and one day you get a phone call from
the network engineer at AS 2 asking you why you are advertising a summary for 1.0.0.0 /8. You have no idea
what the hell he is talking about so you decide to do some research. Heres what we see on R2:
B
1.0.0.0/8 [20/0] via 192.168.12.1, 00:02:15
This is what the network engineer on R2 is seeing. Lets check why R1 is advertising this:
R1#show ip bgp 1.0.0.0
BGP routing table entry for 1.0.0.0/8, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
We can see that we have network 1.0.0.0 /8 in the BGP table of R1. Lets check its routing table:
R1#show ip route 1.0.0.0
Routing entry for 1.0.0.0/24, 1 known subnets
Attached (1 connections)
Redistributing via bgp 1
Advertised by bgp 1
C
1.1.1.0 is directly connected, Loopback0
Network 1.1.1.0 /24 is configured on the loopback interface but its in the BGP table as 1.0.0.0 /8. This could
mean only 1 thing.summarization. Take a look below:
R1#show ip protocols
Routing Protocol is "bgp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is enabled
A quick look at show ip protocols reveals that automatic summarization is enabled. Lets disable it:
R1(config-router)#no auto-summary
Well disable it on R1 so R2 learns the subnet:

B
1.1.1.0 [20/0] via 192.168.12.1, 00:00:20
Now we see 1.1.1.0 /24 on R2problem solved!

Lesson learned: If you see classful networks in your BGP table you might have auto-summary enabled.
Some of the problems Ive been showing you could be resolved easily by just looking and/or comparing the
output of a show run. This might be true but keep in mind that you dont always have access to all BGP
routers in the network so maybe theres no way to compare configurations. There could be a switch or another
router in between the devices you are trying to troubleshooting that are causing issues. Using the appropriate
show and debug commands will show you exactly what your router is doing and what it is advertising to other
routers.
BGP Route-Maps
Same topology, different problem:
The people from AS 2 are complaining that they are not receiving anything from AS 1. To keep it interesting
Im not going to show you the configurations
Neighbor
V
AS MsgRcvd MsgSent
TblVer
192.168.12.1 4
1
51
48
1

0
0 00:08:51
0
For starters, we can see that R2 is not receiving any prefixes. Do we have any filters?
R1#show ip protocols | include filter
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
I can also verify that R1 doesnt have any distribute-lists. Lets check if R1 has 1.1.1.0 /24 in its BGP table:
R1#show ip bgp 1.1.1.0
Not advertised to any peer
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
I can confirm that R1 does have network 1.1.1.0 /24 in its routing table so why is it not advertising this to R2?
Lets see if R1 has configured anything special for its neighbor R2:
R1#show ip bgp neighbors 192.168.12.2
BGP neighbor is 192.168.12.2, remote AS 2, external link
BGP version 4, remote router ID 192.168.12.2
BGP state = Established, up for 00:03:34
Last read 00:00:33, last write 00:00:33, hold time is 180, keepalive interval is 60
seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent
Rcvd
Opens:
11
11
Notifications:
0
0
Updates:
7
0
Keepalives:
85
86
Route Refresh:
0
0
Total:
103
97
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 3, neighbor version 3/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Outbound path policy configured
Route map for outgoing advertisements is NEIGHBORS
Sent
Rcvd
Prefix activity:
------Prefixes Current:
0
0
Prefixes Total:
0
0
Implicit Withdraw:
0
0
Explicit Withdraw:
0
0
Used as bestpath:
n/a
0
Used as multipath:
n/a
0
I will use the show ip bgp neighbors command to see detailed information of R2. We can see that a route-map
has been applied to R2 and its called NEIGHBORS. Keep in mind that besides distribute-lists we can use
also use route-maps for BGP filtering. Lets check it out:
R1# show route-map
route-map NEIGHBORS, permit, sequence 10
Match clauses:
ip address prefix-lists: PREFIXES
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Theres only a match statement for prefix-list PREFIXES. Take a look:

R1#show ip prefix-list
ip prefix-list PREFIXES: 1 entries
seq 5 deny 1.1.1.0/24
Theres our troublemakerits denying network 1.1.1.0 /24! Lets get rid of this route-map:
R1(config-router)#no neighbor 192.168.12.2 route-map NEIGHBORS out
That should take care of our problem

B
1.1.1.0 [20/0] via 192.168.12.1, 00:00:03
And finally R2 has learned about this prefixproblem solved!

Lesson learned: Make sure there are no route-maps blocking the advertisement of prefixes.
IBGP Split Horizon

Heres a new topology:
R1 is advertising network 1.1.1.0 /24 but R3 is not learning this prefix. Here are the configurations:
router bgp 1
no synchronization
network 1.1.1.0 mask 255.255.255.0
no auto-summary
router bgp 1
no synchronization
no auto-summary
router bgp 1
no synchronization
no auto-summary
The neighbor adjacencies have been configured,R1 is advertising network 1.1.1.0 /24. Lets see if R2 and/or R3
have learned about it:
We're Sorry, Full Content Access is
BGP TCP Port Filtering

Lets take a look at an IBGP issue:
Two routers in the same AS and heres the configuration:

router bgp 1
no synchronization
no auto-summary
router bgp 1
no synchronization
no auto-summary
Plain and simple. The routers use the directly connected IP addresses for the BGP neighbor adjacency. Letsee if
we have neighbors:
We're Sorry, Full Content Acces
How to Configure BGP Weight Attribute

Weight is a Cisco proprietary BGP attributes that can be used to select a certain path. Heres what you need to
know about weight:
Weight is the first BGP attribute in the list.
Cisco proprietary so you wont find it on other vendor routers.
Weight is not exchanged between BGP routers.
Weight is only local on the router.
The path with the highest weight is preferred.
Let me give you an example for BGP weight:
R1 in AS 1 can reach AS 3 through AS 2 or AS 4. If we want to ensure AS 2 is always used as the best path you
can change the weight. In my example the weight for the path to AS 2 is set to 500 and higher than the weight
of 400 for AS 4. Lets see what this looks like on real Cisco routers, this is the topology that I will use:
Above we have a simple scenario with two autonomous systems. R2 and R3 both have network 2.2.2.0/24
configured on their loopback0 interface and Ill advertise that in BGP.
R1(config-router)#neighbor 192.168.12.2 remote-as 2
Above youll find the configuration for BGP, now lets take a detailed look at R1:
R1#show ip bgp
BGP table version is 2, local router ID is 192.168.13.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
*> 2.2.2.0/24
*
Next Hop
192.168.12.2
192.168.13.3
Metric LocPrf Weight Path

0
0 2 i
0
0 2 i
Router R1 decided to use 192.168.12.2 as the next hop. All the BGP attributes are the same so it came down to
the router ID to select a winner. Now lets change this behavior using the weight attribute
R1(config-router)#neighbor 192.168.13.3 weight 500
You can configure weight per neighbor using the weight command. All prefixes from this neighbor will have a
weight of 500.
How to Configure BGP Local Preference Attribute

BGP attribute local preference is the second BGP attribute and it can be used to choose the exit path for an
autonomous system. Here are the details:
Local preference is the second BGP attribute.
You can use local preference to choose the outbound external BGP path.
Local preference is sent to all internal BGP routers in your autonomous system.
Not exchanged between external BGP routers.
Local preference is a well-known and discretionary BGP attribute.
Default value is 100.
The path with the highest local preference is preferred
Let me show you an example:
You can use local preference to configure your autonomous system to select a certain exit point. Instead of
configuring weight on each router you can use local preference because it is exchanged on all internal BGP
routers. By increasing the local preference to 800 we can make AS 1 send all traffic towards AS 2.
A well-known discretionary BGP attribute must be recognized by all BGP routers per RFC but its presence in
a BGP update is optional.
Now let me show you how to configure local preference, here is the topology that we will use:
In the picture above we have two autonomous systems. Router James will advertise network 1.1.1.0/24 towards
AS 2 and router Jack will have to make a choice when it wants to reach this network. It can go through router
Jim or John, well see how local preference influence this.
James(config)#router bgp 1
James(config-router)#neighbor 192.168.12.2 remote-as 2
James(config-router)#neighbor 192.168.13.3 remote-as 2
James(config-router)#network 1.1.1.0 mask 255.255.255.0
This is the configuration of router Jack, nothing spectacular here.

Jim(config)#interface loopback 0
Jim(config-if)#ip address 2.2.2.2 255.255.255.0
Jim(config)#router ospf 1
Jim(config-router)#network 192.168.24.0 0.0.0.255 area 0
Jim(config-router)#network 2.2.2.0 0.0.0.255 area 0

John(config)#interface loopback 0
John(config-if)#ip address 3.3.3.3 255.255.255.0
John(config)#router ospf 1
John(config-router)#network 192.168.34.0 0.0.0.255
John(config-router)#network 3.3.3.0 0.0.0.255 area
Jack(config)#interface loopback 0
Jack(config-if)#ip address 4.4.4.4 255.255.255.0
Jack(config)#router ospf 1
Jack(config-router)#network 192.168.24.0 0.0.0.255
Jack(config-router)#network 192.168.34.0 0.0.0.255
Jack(config-router)#network 4.4.4.0 0.0.0.255 area
area 0
0
area 0
area 0
0
Ill configure OSPF within AS2 to prepare it for IBGP.

John(config)#router bgp 2
John(config-router)#neighbor 192.168.13.1 remote-as 1
John(config-router)#neighbor 2.2.2.2 update-source loopback0
John(config-router)#neighbor 4.4.4.4 update-source loopback0
John(config-router)#neighbor 4.4.4.4 next-hop-self
Jim(config)#router bgp 2
Jim(config-router)#neighbor 192.168.12.1 remote-as 1
Jim(config-router)#neighbor 3.3.3.3 update-source loopback0
Jim(config-router)#neighbor 4.4.4.4 update-source loopback0
Jim(config-router)#neighbor 4.4.4.4 next-hop-self
Jack(config)#router bgp 2
Jack(config-router)#neighbor 2.2.2.2 remote-as 2
Jack(config-router)#neighbor 2.2.2.2 update-source loopback 0
Jack(config-router)#neighbor 3.3.3.3 update-source loopback 0
And above you can see the BGP configurations.

Now lets find out what path router Jack will use to reach network 1.1.1.0/24:
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 router Jacob. 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. Lets see what this looks like on
Cisco routers, this is the topology that I will use:
Above we have 3 routers. Router Jim and John are both in AS 1 advertising the same network (1.1.1.0/24) to
router Jack. We can use AS Path prepending to make router Jack prefer a certain path.
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 wont see it in the BGP table anymore. EGP is an old routing protocol we
dont use it anymore. Incomplete means you have redistributed something into BGP. Heres a demonstration:
Above you can see the topology that I will use. Router Jim and John are in AS1 and connected to router Jack in
AS2. Both routers have a loopback0 interface with network 1.1.1.0/24 configured on it.
First well configure BGP. Next step is to get network 1.1.1.0/24 in the BGP table:
Jim(config-router)#network 1.1.1.0 mask 255.255.255.0
John(config-router)#redistribute connected
On router Jim Ill advertise network 1.1.1.0/24 in BGP with the network command, on router John well
redistribute it. Lets see what router Jack thinks of this
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.
Lets 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. Router Julian is sending a MED of 200 towards AS 3.
Router Jacob is sending a MED of 300 to AS 3. AS 3 will prefer the lower metric and send all traffic for AS 1
through AS 1. Let me show you how to configure this on a Cisco router:
Above we have two autonomous systems. Router Jim and John will both advertise network 1.1.1.0 /24 in BGP.
We can use MED to tell AS 1 which path to use to reach this network.
Jim(config-router)#network 1.1.1.0 mask 255.255.255.0
John(config-router)#network 1.1.1.0 mask 255.255.255.0
This is the BGP configuration, nothing special so far.

Jack#show ip bgp
Network
* 1.1.1.0/24
*>
Next Hop
192.168.23.3
192.168.12.1

0
0 1 i
0
0 1 i
You have seen the example above before. Router Jack prefers the path through 192.168.12.1. Note that the
metric (MED) is 0. Lets play with the MED now:
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: dont advertise the prefix to any BGP neighbors.
No-Export: dont advertise the prefix to any eBGP neighbors.
Local-AS: dont advertise the prefix outside of the sub-AS (this one is used for BGP confederations).
Once you finish reading this lesson, click on one of the links above to learn more about these well known BGP
communities. I explained each of them in a separate lesson.
Why do we call them communities? A community is a group of prefixes that should be treated the same way.
For example maybe you have 100 prefixes that require the same local preference or weight. You could match all
prefixes using an access-list or prefix-list but using BGP communities is more convenient.
Instead of manually selecting the prefixes, an ISP could instruct its customers to tag prefixes with a certain BGP
community. When the customer does this, their prefixes get a certain treatment.
To give you an idea, here are some examples that I found from Level 3 (large ISP in the US):
-------------------------------------------------------customer traffic engineering communities - Prepending
-------------------------------------------------------65001:0
- prepend once to all peers
65001:XXX - prepend once at peerings to AS XXX
65002:0
- prepend twice to all peers
65002:XXX - prepend twice at peerings to AS XXX
65003:0
- prepend 3x to all peers
65003:XXX - prepend 3x
at peerings to AS XXX
65004:0
- prepend 4x to all peers
65004:XXX - prepend 4x
at peerings to AS XXX
-------------------------------------------------------customer traffic engineering communities - Regional
-------------------------------------------------------Will only work for regional peers
64980:0
- announce to customers but not to EU peers
64981:0
- prepend once to all EU peers
64982:0
- prepend twice to all EU peers
64983:0
- prepend 3x
to all EU peers
64984:0
- prepend 4x
to all EU peers
-------------------------------------------------------customer traffic engineering communities - LocalPref
-------------------------------------------------------3356:70
- set local preference to 70
3356:80
3356:90
This list might not be up-to-date anymore but it gives you an impression of how BGP communities are used. If a
customer of Level 3 tags their prefixes with 3356:90 then they will set the local preference to 90. If you tag
them with 64983:0 then they will prepend the AS number three times to all their BGP neighbors in Europe.
These BGP communities are 32-bit values that are divided in two sections. For labs you can pick whatever
values you like but normally the first 16 bits are used to indicate the AS number that originates the community,
the next 16 bits are assigned by the AS. For example, Level 3 uses these communities:
-------------------------------------------------------customer traffic engineering communities - LocalPref
-------------------------------------------------------3356:70
3356:80
3356:90
The first 16 bits is their AS number (3356) and the next 16 bits (70, 80 and 90) corresponds with the local
preference value. On their routers they configured a policy that sets the local preference to these values if they
receive prefixes with these BGP communities.
Nowadays we also use extended communities which are 8 octets. These are used often for MPLS VPN which
we will discuss in another lesson. Lets take a look at a configuration example so you can see how to implement
BGP communities.
Configuration
For this example I will use the following topology:
On the left side we have a customer router that is connected to ISP1. This ISP is connected to ISP2 and ISP3.
Lets imagine that ISP2 is somewhere in Europe and that ISP1 has a policy that they will prepend their AS
number four times to BGP neighbors in Europe whenever a customer adds BGP community value 64984:0 to
their prefixes.
Lets see how we can configure this on the ISP1 and customer router.
BGP Configuration
Here is the BGP configuration, its straight-forward eBGP:
Customer#show running-config | section bgp
router bgp 10
no synchronization
network 10.10.10.10 mask 255.255.255.255
no auto-summary
ISP1#show running-config | section bgp
router bgp 1
no synchronization
no auto-summary
router bgp 2
no synchronization
no auto-summary
router bgp 3
no synchronization
no auto-summary
Lets see if ISP1 has learned any prefixes from the customer router:
ISP1#show ip bgp 10.10.10.10
Flag: 0x820
Advertised to update-groups:
1
10
192.168.10.10 from 192.168.10.10 (192.168.10.10)
Origin IGP, metric 0, localpref 100, valid, external, best
ISP1 has learned the network on the loopback interface of the customer router. Right now we dont have any
BGP communities. Lets start with the configuration of ISP1
ISP1 AS Path Prepend Configuration

First we will create a community list that matches the community- value:
BGP Community No Advertise

The BGP No Advertise community is one of the four well known communities. If you have no idea what BGP
communities are about, I would suggest to check the introduction lesson first. Thats where you will learn about
the basics of BGP communities.
When you add the no-advertise community to a prefix then the receiving BGP router will use and store the
prefix in its BGP table but it wont advertise the prefix to any other neighbors.
Lets 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).
Configuration
Heres the basic BGP configuration in case you want to try this example yourself:
R1#show running-config | section bgp
router bgp 1
no synchronization
network 1.1.1.1 mask 255.255.255.255
no auto-summary
router bgp 24
no synchronization
neighbor 192.168.24.4 next-hop-self
no auto-summary
router bgp 3
no synchronization

no auto-summary
router bgp 24
no synchronization
no auto-summary
Lets see if R2, R3 and R4 have learned our prefix:

R2#show ip bgp | include 1.1.1.1
*> 1.1.1.1/32
192.168.12.1
*> 1.1.1.1/32
192.168.23.2
* i1.1.1.1/32
192.168.12.1
0 1 i
0 24 1 i
100
0 1 i
Its in the BGP table of these routers. Now lets configure R1 to add the no advertise community:
R1(config-router)#neighbor 192.168.12.2 send-community
First we have to tell R1 to send BGP communities, by default this is disabled. Now we can create a route-map
that sets the community value:
R1(config)#route-map NO_ADVERTISE permit 10
R1(config-route-map)#set community no-advertise
This route-map doesnt have any match statements so it will set the no advertise community to all prefixes.
Lets activate it:
BGP Community No Export

The well known BGP community no export tells BGP neighbors to advertise a prefix only to iBGP neighbors.
If you are not sure what BGP communities are and how they work then I advise you to read my introduction to
BGP communities first before you continue. Having said that, lets take a look at a configuration example.
Heres the topology we will use:
Above we see R1 with network 1.1.1.1/32 on a loopback interface. It will advertise this prefix with the no
export community set. As a result, R2 will install it in its BGP table and advertises it to R4 (iBGP). It will not be
advertised to R3 since this is a eBGP session.
Configuration
Basic BGP Configuration
Heres the BGP configuration in case you want to try this example yourself:
router bgp 1
no synchronization
network 1.1.1.1 mask 255.255.255.255
no auto-summary
router bgp 24
no synchronization
neighbor 192.168.24.4 next-hop-self
no auto-summary
router bgp 3
no synchronization
no auto-summary
router bgp 24
no synchronization
no auto-summary
By default BGP does not send any communities. All routers will learn about 1.1.1.1/32:
*> 1.1.1.1/32
192.168.12.1
*> 1.1.1.1/32
192.168.23.2
* i1.1.1.1/32
192.168.12.1
0 1 i
0 24 1 i
100
0 1 i
BGP Community No-Export Configuration

Lets configure our BGP community. First we have to tell R1 to send communities:
Now we can create a route-map that sets the BGP community to no-export and we attach it to our neighbor R2:
BGP Community Local AS

The local AS community is a well known BGP community and can be used for BGP confederations. Its
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-ASes or
eBGP routers.
To demonstrate this I will use the following topology:
AS 2345 has 4 routers and 2 sub-ASes. 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. Lets look at the configuration
Configuration
BGP Configuration
Below you will find the BGP configuration for all these routers. Within AS 2345 I have used OSPF so that these
routers can use their loopback interfaces for BGP.
router bgp 1
no synchronization
network 1.1.1.1 mask 255.255.255.255
no auto-summary
router bgp 23
no synchronization
bgp confederation identifier 2345
bgp confederation peers 45
neighbor 3.3.3.3 update-source Loopback0
neighbor 4.4.4.4 ebgp-multihop 2
no auto-summary
router bgp 23
no synchronization
no auto-summary
router bgp 45
no synchronization
no auto-summary
router bgp 45
no synchronization

no auto-summary
router bgp 6
no synchronization
no auto-summary
R1 has advertised prefix 1.1.1.1/32 in BGP, lets see if our routers have learned this:
R2#show ip bgp
*> 1.1.1.1/32
R3#show ip bgp
*>i1.1.1.1/32
R4#show ip bgp
* i1.1.1.1/32
*>
R5#show ip bgp
* i1.1.1.1/32
*>
R6#show ip bgp
*> 1.1.1.1/32
| begin 1.1.1.1
192.168.12.1
| begin 1.1.1.1
192.168.12.1
| begin 1.1.1.1
192.168.12.1
192.168.12.1
| begin 1.1.1.1
192.168.12.1
192.168.12.1
| begin 1.1.1.1
192.168.36.3
0 1 i
100
0 1 i
0
0
100
100
0 (23) 1 i
0 (23) 1 i
0
0
100
100
0 (23) 1 i
0 (23) 1 i
0 2345 1 i
All router know about this prefix. Time to activate the local AS community
Local AS Community Configuration

We will create a route-map on R2 that sets the local AS community on all prefixes that it receives from R1:
R2(config)#route-map LOCAL_AS permit 10
R2(config-route-map)#set community local-AS
R2(config-router)#neighbor 192.168.12.1 route-map LOCAL_AS in
R2 sets the community so make sure that it advertises it to R3. Before we reset BGP, take a look at the BGP
table of R2:
BGP Regular Expressions Examples

Regular Expressions are used often for BGP route manipulation or filtering. In this lesson well take a look at
some useful regular expressions. First lets 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. Youll need this for BGP confederations.
Examples
^$
^51_
_51_
_51$
^([0-9]+)_51
^51_([0-9]+)
^(51_)+([09]+)
^51_([0-9]+_)
+
^\65200\)
matches an empty AS PATH so it will match all prefixes from the local AS.
matches prefixes from AS 51 that is directly connected to our AS.
matches prefixes that transit AS 51.
matches prefixes that originated in AS 51, the $ ensures that its the beginning of the AS PATH.
matches prefixes from AS 51 where AS 51 is behind one of our directly connected ASes.
matches prefixes from the clients of directly connected AS 51.
matches prefixes from the clients of directly connected AS 51, where AS 51 might be doing AS
PATH prepending.
matches prefixes from the clients of directly connected AS 51, where the clients might be
doing AS PATH prepending.
matches prefixed from confederation peer 65200.
If you need some practice for these, I would suggest to use a BGP looking glass server.
BGP Prevent Transit AS
By default BGP will advertise all prefixes to EBGP (External BGP) neighbors. This means that if you are multihomed (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 multihomed its possible that the ISPs will use R1 to reach each other. In order to prevent this well 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 its not a very scalable solution if you have thousands of prefixes in
your BGP table. The filter-list and no-export community work very well since you only have to configure them
once and it will not matter if new prefixes show up. First well configure BGP on each router:
ISP1(config)#router bgp 2
ISP1(config-router)#neighbor 192.168.12.1 remote-as 1
ISP2(config-router)#neighbor 192.168.13.1 remote-as 1
The commands above will configure EBGP (External BGP) between R1 ISP1 and R1 ISP2. To make sure
we have something to look at, Ill advertise the loopback interfaces in BGP on each router:
ISP1(config-router)#network 2.2.2.0 mask 255.255.255.0
ISP2(config-router)#network 3.3.3.0 mask 255.255.255.0
With the networks advertised, lets take a look at the BGP table of ISP1 and ISP2 to see what they have learned:
ISP1#show ip bgp
Network
Next Hop
*> 1.1.1.0/24
192.168.12.1
0
0 1 i
*> 2.2.2.0/24
0.0.0.0
0
32768 i
*> 3.3.3.0/24
192.168.12.1
0 1 3 i
ISP2#show ip bgp
Network
*> 1.1.1.0/24
*> 2.2.2.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
192.168.13.1
0.0.0.0

0
0 1 i
0 1 2 i
0
32768 i
The ISP routers have learned about each other networks and they will use R1 as the next hop. We now have
everything in place to play with the different filtering techniques.
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. Heres how to do it:
R1(config)#ip as-path access-list 1 permit ^$
R1(config-router)#neighbor 192.168.12.2 filter-list 1 out
R1(config-router)#neighbor 192.168.13.3 filter-list 1 out
The ^$ regular expression ensures that we will only advertise locally originated prefixes. Well have to apply
this filter to both ISPs.
Keep in mind that BGP is slowif you are doing labs, its best to speed things up with clear ip bgp *
Lets verify our configuration:
R1#show ip bgp
Network
*> 1.1.1.0/24
*> 2.2.2.0/24
*> 3.3.3.0/24
Next Hop
0.0.0.0
192.168.12.2
192.168.13.3

0
32768 i
0
0 2 i
0
0 3 i
R1 still knows about the prefixes from the ISP routers. What about ISP1 and ISP2?
ISP1#show ip bgp

Network
Next Hop
*> 1.1.1.0/24
192.168.12.1
0
0 1 i
*> 2.2.2.0/24
0.0.0.0
0
32768 i
ISP2#show ip bgp
Network
*> 1.1.1.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
0.0.0.0

0
0 1 i
0
32768 i
ISP1 and ISP2 only know about the 1.1.1.0 /24 network. Excellent, we are no longer a transit AS!
Want to take a look for yourself? Here you will find the configuration of each device.
On to the next method
No-Export Community
Using the no-export community will also work pretty well. We will configure R1 so that prefixes from the ISP
routers will be tagged with the no-export community. This ensures that the prefixes from those routers will be
known within AS 1 but wont be advertised to other routers.
R1(config)#route-map NO-EXPORT
R1(config-route-map)#set community no-export
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
Im only using one router in AS 1, if you have other routers and are running IBGP (Internal BGP) then dont
forget to send communities to those routers with the neighbor <ip> send-community command.
Lets see what ISP1 and ISP2 think about our configuration:
ISP1#show ip bgp
Network
Next Hop
*> 1.1.1.0/24
192.168.12.1
0
0 1 i
*> 2.2.2.0/24
0.0.0.0
0
32768 i
ISP2#show ip bgp
Network
*> 1.1.1.0/24
*> 3.3.3.0/24
Next Hop
192.168.13.1
0.0.0.0

0
0 1 i
0
32768 i
They only know about network 1.1.1.0 /24.

Want to take a look for yourself? Here you will find the configuration of each device.
Onto the next method!
Prefix-List Filtering
Using a prefix-list we can determine what prefixes are advertised to our BGP neighbors. This works fine but its
not a good solution to prevent becoming a transit AS. Each time you add new prefixes youll 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. Lets verify the configuration:
BGP AS Path Filter Example

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

route-server.as3257.net>show ip bgp

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Network
*> 1.0.0.0/24
*> 1.0.4.0/24
*> 1.0.5.0/24
*> 1.0.6.0/24
*> 1.0.7.0/24
*> 1.0.20.0/23
*> 1.0.22.0/23
*> 1.0.24.0/23
*> 1.0.26.0/23
*> 1.0.28.0/22
*> 1.0.38.0/24
*> 1.0.41.0/24
*> 1.0.43.0/24
*> 1.0.46.0/24
*> 1.0.48.0/24
*> 1.0.64.0/18
*> 1.0.128.0/18
*> 1.0.128.0/17
*> 1.0.129.0/24
*> 1.0.130.0/24
23969 i
*> 1.0.131.0/24
23969 i
*> 1.0.142.0/23
23969 i
*> 1.0.160.0/19
*> 1.0.192.0/21
23969 i
Next Hop
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93

0
0 3257 15169 i
0
0 3257 6453 7545 56203 i
0
0 3257 6453 7545 56203 i
0
0 3257 174 4826 38803 56203 i
0
0 3257 174 4826 38803 56203 i
1551
0 3257 2516 2519 i
1551
0 3257 2516 2519 i
1551
0 3257 2516 2519 i
1551
0 3257 2516 2519 i
1551
0 3257 2516 2519 i
815
0 3257 9304 24155 i
815
0 3257 9304 24155 i
815
0 3257 9304 24155 i
815
0 3257 9304 24155 i
815
0 3257 9304 24155 i
1551
0 3257 2516 7670 18144 i
0
0 3257 174 38040 9737 i
0
0 3257 38040 9737 9737 i
0
0 3257 4651 9737 9737 23969 i
0
0 3257 6453 4651 9737 9737 9737
213.200.64.93
0 3257 6453 4651 9737 9737 9737
213.200.64.93
0 3257 6453 4651 9737 9737 9737
213.200.64.93
213.200.64.93
18
0
0 3257 2914 38040 9737 i

0 3257 6453 4651 9737 9737 9737
Plenty of prefixes to play withlets try a couple of examples now shall we?
Only allow prefixes that originated from AS 3257

This example will only accept prefixes that originated in AS 3257, all the other prefixes wont be permitted:
route-server.as3257.net>show ip bgp regexp ^3257$
*>
*>
*>
*>
Network
2.16.0.0/23
2.16.4.0/24
2.16.5.0/24
2.16.34.0/24
Next Hop
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93

154
0 3257 i
230
0 3257 i
230
0 3257 i
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 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.
Lets look at another example
Only allow networks that passed through AS 3257

We only want to see prefixes that passed through AS 3257, heres how:
route-server.as3257.net>show ip bgp regexp _3257_
*>
*>
*>
*>
*>
*>
Network
1.0.0.0/24
1.0.4.0/24
1.0.5.0/24
1.0.6.0/24
1.0.7.0/24
1.0.20.0/23
Next Hop
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93
213.200.64.93

0
0 3257 15169 i
0
0 3257 6453 7545 56203 i
0
0 3257 6453 7545 56203 i
0
0 3257 174 4826 38803 56203 i
0
0 3257 174 4826 38803 56203 i
1551
0 3257 2516 2519 i
The regular expression starts and ends with a _ . This matches the space between the AS path numbers. Im 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. Heres 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 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:
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 dont 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, lets 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, heres 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. Ill use
two routers and some prefixes and well 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, well use these to play with filtering.
Heres what R2 advertises to R1:

R2#show ip bgp neighbors 192.168.12.1 advertised-routes
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RTFilter
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
Network
10.0.0.0/24
10.1.0.0/24
10.2.0.0/24
10.3.0.0/25
10.3.0.128/25
10.4.0.0/25
10.4.0.128/25
10.5.0.0/26
10.6.0.0/27
10.7.0.0/28
10.8.1.0/24
10.8.2.0/24
20.0.0.0
30.0.0.0
172.16.0.0/24
172.16.1.0/24
172.16.2.0/25
172.16.3.0/25
172.16.4.0/26
172.16.5.0/27
172.16.6.0/28
172.16.7.0/29
192.168.0.0
192.168.1.0
Next Hop
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0

0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
192.168.2.0/25
192.168.3.0/25
192.168.4.0/26
192.168.5.0/27
192.168.6.0/28
192.168.7.0/29
192.168.7.8/29
192.168.7.16/29
192.168.7.24/30
192.168.12.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0
0
0
0
0
0
0
0
0
0
32768
32768
32768
32768
32768
32768
32768
32768
32768
32768
i
i
i
i
i
i
i
i
i
i
Total number of prefixes 34
Lets start with some simple examples
Filter specific prefixes

Lets say that we to filter some specific prefixes, lets pick:
20.0.0.0 /8
172.16.0.0 /24
192.168.1.0 /24
Heres what the access-list will look like:

R1(config)#access-list 100 permit ip 20.0.0.0 0.0.0.0 255.0.0.0 0.0.0.0
R1(config-router)#distribute-list 100 in
R1#clear ip bgp *
Before we check the result, let me explain the access-list:
In the first entry we want an exact match for 20.0.0.0 so we use network 20.0.0.0 with wildcard
0.0.0.0. The prefix-length has to be exactly /8 so we use subnet mask 255.0.0.0 with wildcard 0.0.0.0.
In the second entry we want an exact match for 172.16.0.0 so we use network 172.16.0.0 with
wildcard 0.0.0.0. The prefix-length has to be exactly /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.
Lets see what we get:

R1#show ip bgp

Network
r> 20.0.0.0
r> 172.16.0.0/24
r> 192.168.1.0
Next Hop
192.168.12.2
192.168.12.2
192.168.12.2

0
0 2 i
0
0 2 i
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
doesnt 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)
Lets try something else now!
Filter all 192.168.x.0 networks with a /24 prefix length

Lets say that we want to filter all networks in the 192.168.x.0 range that have a /24 prefix length. R2 is
currently advertising these networks:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 192.168.
*> 192.168.0.0
0.0.0.0
0
32768 i
*> 192.168.1.0
0.0.0.0
0
32768 i
*> 192.168.2.0/25
0.0.0.0
0
32768 i
*> 192.168.3.0/25
0.0.0.0
0
32768 i
*> 192.168.4.0/26
0.0.0.0
0
32768 i
*> 192.168.5.0/27
0.0.0.0
0
32768 i
*> 192.168.6.0/28
0.0.0.0
0
32768 i
*> 192.168.7.0/29
0.0.0.0
0
32768 i
*> 192.168.7.8/29
0.0.0.0
0
32768 i
*> 192.168.7.16/29 0.0.0.0
0
32768 i
*> 192.168.7.24/30 0.0.0.0
0
32768 i
*> 192.168.12.0
0.0.0.0
0
32768 i
We only want to see 192.168.0.0 /24, 192.168.1.0 /24 and 192.168.12.0 /24 on R1. Heres the access-list we will
create:
R1#clear ip bgp *
Let me explain the access-list:
The network address we want to check is 192.168.0.0.
The wildcard is 0.0.255.0 which means the 1st, 2nd and 4th octet have to match. We dont 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.
Heres the result:

R1#show ip bgp
Network
r> 192.168.0.0
r> 192.168.1.0
r> 192.168.12.0
Next Hop
192.168.12.2
192.168.12.2
192.168.12.2

0
0 2 i
0
0 2 i
0
0 2 i
Great, these are the only 192.168.x.0 /24 networks that we have. Time for the next example
Filter all 10.x.x.0 networks with a /24 prefix length

This one is similar to the previous example but this time we check the 10.x.x.0 range. Here are the networks that
R2 is advertising:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 10.
*> 10.0.0.0/24
0.0.0.0
0
32768 i
*> 10.1.0.0/24
0.0.0.0
0
32768 i
*> 10.2.0.0/24
0.0.0.0
0
32768 i
*> 10.3.0.0/25
0.0.0.0
0
32768 i
*> 10.3.0.128/25
0.0.0.0
0
32768 i
*> 10.4.0.0/25
0.0.0.0
0
32768 i
*> 10.4.0.128/25
0.0.0.0
0
32768 i
*> 10.5.0.0/26
0.0.0.0
0
32768 i
*> 10.6.0.0/27
0.0.0.0
0
32768 i
*> 10.7.0.0/28
0.0.0.0
0
32768 i
*> 10.8.1.0/24
0.0.0.0
0
32768 i
*> 10.8.2.0/24
0.0.0.0
0
32768 i
Lets build an access-list:

R1#clear ip bgp *
The network we want to check is 10.0.0.0 but we only care about the 1st and 4th octet, the 2nd and 3rd
octet can be everything so we use wildcard 0.255.255.0.
We want all networks with a /24 prefix length so we use 255.255.255.0 as the subnet mask. This has to
be an exact match so we use 0.0.0.0 as the wildcard.
Heres what we get:
R1#show ip bgp
r>
r>
r>
r>
r>
Network
10.0.0.0/24
10.1.0.0/24
10.2.0.0/24
10.8.1.0/24
10.8.2.0/24
Next Hop
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2

0
0 2 i
0
0 2 i
0
0 2 i
0
0 2 i
0
0 2 i
Great, these are all networks in the 10.x.x.0 range with a /24 prefix length. Lets try something else
Filter all 10.x.x.x networks with a /25 prefix length

This time I want to see all networks in the 10.x.x.x range with a /25 prefix length. Here are all 10.x.x.x networks
that R2 is advertising again:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 10.
*> 10.0.0.0/24
0.0.0.0
0
32768 i
*> 10.1.0.0/24
0.0.0.0
0
32768 i
*> 10.2.0.0/24
0.0.0.0
0
32768 i
*> 10.3.0.0/25
0.0.0.0
0
32768 i
*> 10.3.0.128/25
0.0.0.0
0
32768 i
*> 10.4.0.0/25
0.0.0.0
0
32768 i
*> 10.4.0.128/25
0.0.0.0
0
32768 i
*> 10.5.0.0/26
0.0.0.0
0
32768 i
*> 10.6.0.0/27
0.0.0.0
0
32768 i
*> 10.7.0.0/28
0.0.0.0
0
32768 i
*> 10.8.1.0/24
0.0.0.0
0
32768 i
*> 10.8.2.0/24
0.0.0.0
0
32768 i
Heres the access-list:

R1#clear ip bgp *
We want to check the 10.0.0.0 network but we dont care about the 2nd, 3th or 4th octet. Thats 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.
Heres what you will find:

R1#show ip bgp

r>
r>
r>
r>
Network
10.3.0.0/25
10.3.0.128/25
10.4.0.0/25
10.4.0.128/25
Next Hop
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2

0
0 2 i
0
0 2 i
0
0 2 i
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 dont
care about the prefix length. We are talking about the following prefixes:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | incl 192.168.7
*> 192.168.7.0/29
0.0.0.0
0
32768 i
*> 192.168.7.8/29
0.0.0.0
0
32768 i
*> 192.168.7.16/29 0.0.0.0
0
32768 i
*> 192.168.7.24/30 0.0.0.0
0
32768 i
Heres the access-list:

R1#clear ip bgp *
Let me walk you through the access-list:
We are looking for network 192.168.7.0 but we only want to check the first three octets, thats why we
use wildcard 0.0.0.255.
We dont 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 doesnt matter if its 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 dont care about the prefix length in the 4th octet.
Heres the result:

R1#show ip bgp
r>
r>
r>
r>
Network
192.168.7.0/29
192.168.7.8/29
192.168.7.16/29
192.168.7.24/30
Next Hop
192.168.12.2
192.168.12.2
192.168.12.2
192.168.12.2

0
0 2 i
0
0 2 i
0
0 2 i
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 dont care about the network address but we only want to see networks with a
prefix length between /24 and /32. Lets take a look again what R2 is advertising to us:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
*>
Network
10.0.0.0/24
10.1.0.0/24
10.2.0.0/24
10.3.0.0/25
10.3.0.128/25
10.4.0.0/25
10.4.0.128/25
10.5.0.0/26
10.6.0.0/27
10.7.0.0/28
10.8.1.0/24
10.8.2.0/24
20.0.0.0
30.0.0.0
172.16.0.0/24
Network
172.16.1.0/24
172.16.2.0/25
172.16.3.0/25
172.16.4.0/26
172.16.5.0/27
172.16.6.0/28
172.16.7.0/29
192.168.0.0
192.168.1.0
192.168.2.0/25
192.168.3.0/25
192.168.4.0/26
192.168.5.0/27
192.168.6.0/28
192.168.7.0/29
192.168.7.8/29
192.168.7.16/29
192.168.7.24/30
192.168.12.0
Next Hop
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
Next Hop
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0

0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
0
32768 i
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:

BGP Info

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

BGP Info

Diunggah oleh

Hak Cipta:

Format Tersedia

BGP Neighbor Adjacency States

Heres an example of a wireshark capture of an open message between R1 and R2:

Lets take a look at an update message from R1:

Heres the capture:

Troubleshooting BGP Neighbor Adjacency

BGP Interface Issues

InQ OutQ Up/Down State/PfxRcd

Layer 2 down preventing us from reaching the other side.

Layer 3 issue: wrong IP address on one of the routers.

Access-list blocking TCP port 179 (BGP).

Wrong IP address configured for BGP neighbor router.

OK? Method Status

After enabling the interface you should see this:

Thats what we like to see. Our BGP neighbor adjacency is established

R1#show ip bgp summary

InQ OutQ Up/Down

192.168.12.0/24 is directly connected, FastEthernet0/0

Two static routes should do the job. Lets give it a try:

There goes! A working BGP neighbor adjacency.

Troubleshooting BGP Route Advertisement

BGP Network Command

InQ OutQ Up/Down State/PfxRcd

protocols | include filter

interfaces is not set

InQ OutQ Up/Down State/PfxRcd

192.168.12.0/24 is directly connected, FastEthernet0/0

Now it shows up on R2! Problem solved!

1.1.1.0 is directly connected, Loopback0

Well disable it on R1 so R2 learns the subnet:

Now we see 1.1.1.0 /24 on R2problem solved!

InQ OutQ Up/Down State/PfxRcd

Theres only a match statement for prefix-list PREFIXES. Take a look:

That should take care of our problem

And finally R2 has learned about this prefixproblem solved!

IBGP Split Horizon

BGP TCP Port Filtering

Two routers in the same AS and heres the configuration:

How to Configure BGP Weight Attribute

Weight is the first BGP attribute in the list.

Cisco proprietary so you wont find it on other vendor routers.

Weight is not exchanged between BGP routers.

Weight is only local on the router.

The path with the highest weight is preferred.

Let me give you an example for BGP weight:

Metric LocPrf Weight Path

How to Configure BGP Local Preference Attribute

Local preference is the second BGP attribute.

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:

This is the configuration of router Jack, nothing spectacular here.

Jim(config-router)#network 2.2.2.0 0.0.0.255 area 0

Ill configure OSPF within AS2 to prepare it for IBGP.

And above you can see the BGP configurations.

How to configure BGP AS Path Prepending

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:

BGP Origin Code Attribute explained

How to configure BGP MED Attribute

MED is exchanged between autonomous systems.

The lowest MED is the preferred path.