Lab 1 - BGP Peering

Lab 1 - BGP Peering
This is your first lab. Please use ‘Lab 1 – BGP Peerings’ yaml file to start your CML environment. This
lab is based on your lecture covering BGP peering. In this lab, we would look at iBGP peering, eBGP
peering, eBGP multihop, authentication and updating the source.
Lab topology
Initially all devices have IP addresses as per the table below. However, no routing protocols have
been configured. Please have a look at the running configurations prior to your start.
Table for IP addresses
Device Interface IP address Device Interface IP address
R1 Loopback0 120.1.1.1/32 R4 Loopback0 120.1.4.1/32

Loopback1 120.1.2.1/32 G0/0 150.1.34.4/24
G0/0 150.1.12.1/24 G0/1 150.1.45.4/24
R2 Loopback0 120.2.1.1/32 R5 Loopback0 120.1.5.1/32

G0/0 150.1.12.2/24 G0/1 150.1.45.5/24
G0/1 150.1.23.2/24
R3 Loopback0 120.1.3.1/32
G0/0 150.1.34.3/24
G0/1 150.1.23.3/24
How to view running configurations: Show run
How to view interface ip address setup: Show ip interface brief
Task 1 – Create an iBGP peering
Create an iBGP peering between R3 G0/0 and R4 G0/0 interfaces. These are directly connected and
hence by giving ‘show ip route’ on each of these devices you should see that they are connected
routes.
To configure internal BGP, use the neighbor command and specify the common AS (Autonomous
System) number. Use AS number 100 in this case.
R3(config)#router bgp 100

R3(config-router)#neighbor 150.1.34.4 remote-as 100
R3(config-router)#exit

Give ‘Show ip bgp summary’ to see neighbor relationships formed.

BGP could form an internal BGP neighbor because they are directly connected and hence reachable.
To make things more clear, let us make a similar iBGP peering between R1 and R3.
First, we look at the routing table for R1
You will notice that R3’s local networks like 150.1.23.3 is not available and hence not reachable.
To make this reachable we can configure EIGRP or OSPF between R1, R2 and R3. These would be
networks 150.1.12.0/24 and 150.1.23.0/24. Please include the loopback networks as well.
R1(config)#router eigrp 20
R1(config-router)#network 120.1.1.0 0.0.0.255
Now you should see on R1 that R3’s 150.1.23.0/24 is now reachable. R3 can see 150.1.12.0/24 from
R1. Give ‘Show ip route eigrp’ so view the EIGRP routes that R1 and R3 have learnt.
Lets create an internal BGP peering between R1 and R3 that are not directly connected but
reachable by EIGRP.


Now you can check if the neighbor relationship has been established. Give the following command
to view the neighbor relationship.
Task 2 - Adding BGP Authentication for Peering

R1(config-router)#neighbor 150.1.23.3 password Entnet2

R3(config-router)#neighbor 150.1.12.1 password Entnet2
The following show command should show if the state has been ‘Established’.
If the password is incorrect or authentication has not been configured on either one end of the
peering, the output for peering should look like the figure below.
Please use the ‘clear ip bgp *’ command to speed up the updated bgp table.
Task 3 – eBGP Peering
Configure eBGP peering between R4 and R5 across the network between them 150.1.45.0/24. This is
directly connected network and can be seen under ‘Show ip route’. eBGP peering by default has a
Time To Live (TTL) of 1. This means that peering would only work over one hop length to another
router. Since these routers are directly connected, TTL of one should not be a concern at this stage.
On R5, lets use a different AS number to the rest of topology. Here we would use AS 200.

And on R4, we are doing add 150.1.45.0/24 to AS 100.

The above commands should now negotiate an external BGP session between R4 and R5. The figures
below should show the peering and their respective AS numbers.
Now if we add a network into R5 which has an eBGP neighbor peering with R4, you should see a new
BGP route installed into the routing table at R4. BGP can advertise a network for a peering by using
the network command. It is always recommended to include the subnet mask as well in the
advertisement for a more precise entry to be installed in the routing table. Lets use the loopback on
R5 for this task.

R5(config-router)#network 120.1.5.1 ?
backdoor Specify a BGP backdoor route
mask Network mask
route-map Route-map to modify the attributes
<cr>
R5(config-router)#network 120.1.5.1 mask ?

A.B.C.D Network mask
R5(config-router)#network 120.1.5.1 mask 255.255.255.255
This should now observe an installation of a new BGP entry in R4.

This is indexed with code ‘B’. Notice that the advertised distance is 20 as this is an eBGP network.
Challenge Question:
Add Loopback 1 on R1 into BGP AS 100 as a network advertisement. This should show up as an
internal route on R3. What is the Advertised Distance shown on R3’s routing table for Loopback 1’s
network from R1.
Answer: ________
Task 4 - eBGP Multihop
Similar to the iBGP peering previously installed between R1 and R3 that propagates over R2, as
multihop session for external BGP sessions can be configured. This is achieved by increasing the
default TTL value to a higher number.
To complete this task lets extend the EIGRP domain from R3 until R5 so that full convergence is
achieved.
Now R1 can see R5’s 150.1.45.0 network. Here in this task, we are going to create an eBGP peering
between R1 and R5. R1 is in AS 100 and R5 is AS 200. However, there are number of hops between
R1 and R5. Hence the default TTL of 1 is insufficient for the route to be installed in the routing table.
So in such a case the TTL value would need to be increased to value higher than that of the number
of hops to install a valid entry.
R5(config-router)#router bgp 200

R5(config-router)#neighbor 150.1.12.1 ebgp-multihop 4

R1(config-router)#neighbor 150.1.45.5 ebgp-multihop 4
Please note: Here it is important to have two commands. The first one is the neighbor peering
command for creating an eBGP session and the other is changing the default TTL from 1 to higher
value. R1 to R5 needs to have atleast 4 hops hence we use 4 here.
Challenge question : The eBGP multihop peering in R1 for 150.1.45.5 can been seen under ‘show ip
bgp summary’ but the route is not installed in the routing table. What could be the reason for this?
Answer: ____________________________________________________________________
Task 5 - Update Source
Finally, we look at updating the source for the peering. Earlier in this lab, you had configured an iBGP
peering between R1 and R3. If you go to R3 and give the command ‘Show tcp brief’, you will see the
peering to 150.1.12.1 as established state. Note here that R3 uses the 150.1.23.3 IP as the source to
maintain peering to 150.1.12.1.
In a case where there are multiple paths to reach the destination, creating a peering via a specific
interface’s IP can mean that if there is a failure alternative paths would fail to reach established
state. This is because BGP does several checks while creating a TCP session. One of which is ensuring
that the destination is sole responder to the peering request.
For example, if R1 was creating a peering with R3’s network 150.1.34.3, the response of the peering
requests would be sent via R3’s G0/1 interface which has the IP 150.1.23.3 as the point of exit. This
means the response was made on behalf of 150.1.34.3 and does not match the request. This would
lead to the peering not being able to reach an established state.
For such a scenario, we can use the update source command which ensures that responding
interface is updated to ensure the peering the successful.
It is also advantageous to use a loopback for peering, as all alternative paths can be considered
during a failure if update source command is introduced.
Lets create a peering between R1’s loopback0 and R2’s loopback0 with update source command.
Here the facilitating network would be 150.1.12.0/24 and the loopbacks are not directly connected
but reachable via EIGRP.

R1(config-router)#neighbor 120.2.1.1 update-source loopback0

R2(config-router)#neighbor 120.1.1.1 update-source loopback0
Here an iBGP peering is created over loopbacks and the source is updated to avoid the TCP from not
reaching an established state. By giving the command ‘show ip bgp summary’, you should now see a
new neighbor peering over the loopback0 interfaces.
This is the end of this lab. Having completed this lab you should now be able to complete the quiz
questions on GCU learn for this week.
Lab 2 – Route Reflector and Confederation
In this lab worksheet, there are three parts. All three parts have separate YAML files for your CML
setup. The first part you will learn on BGP route reflector behaviour, followed by clusters in route
reflectors and the final part you would learn about confederations.
PART A – BGP Route Reflectors
As the name suggests, BGP route reflectors reflect learnt routes to their adjacent neighbors. In order
to understand this further it is vital to be familiar with the general behaviour of iBGP. In the previous
lab, you did create iBGP peerings. The BGP split-horizon rule states that a BGP router that receives a
BGP route via an iBGP peering shall not advertise that route to another router that is an iBGP peer.
Two main reasons to why this rule exists is to avoid loops and stale routes.
However in some cases where the BGP AS is large, the solution to create individual iBGP peerings
can lead to a increase of TCP control plane overhead and may lead to the need for a mesh topology.
One of the effective solutions to this problem to have Route Reflectors. This is a BGP mechanism
which overrides the general behaviour of not sharing routes by BGP routers and shares routes to it
neighbors based on certain rules. We shall understand this better by this part of the lab.
Load the LAB 2a – Route Reflector.yaml file to complete this part of the lab.
Topology
Table of IP address
RR G0/1 150.10.1.2/24 R3 G0/0 150.30.1.1/24

G0/2 150.20.1.2/24 Loopback0 120.3.1.1/32
G0/3 150.30.1.2/24
G0/4 150.40.1.2/24 R4 G0/0 150.40.1.1/24
G0/5 150.50.1.2/24 Loopback0 120.4.1.1/32
G0/6 150.60.1.2/24
R5 G0/0 150.50.1.1/24
R1 G0/0 150.10.1.1/24 Loopback0 120.5.1.1/32
Loopback0 120.1.1.1/32
R6 G0/0 150.60.1.1/24
R2 G0/0 150.20.1.1/24 Loopback0 120.6.1.1/32
Loopback0 120.2.1.1/32
In this lab, there are 7 routers in which the router RR is connected to all other six routers in star
format. Router RR, R1, R2, R3 and R4 would belong to AS 100. Please note that this has not being
configured yet. R5 would be in AS 200 and R6 would be in AS 300.
According to the default behaviour of BGP, in this case with RR, any routes received from other
routers will not be passed on to the remaining routers. This is the BGP split horizon rule.
Here we would use Router RR as the route reflector router which will share routes based on how the
reflector is setup. Here we have R5 and R6 going to form eBGP peerings with RR and R1, R2, R3 and
R4 going to have iBGP peerings.
Unlike in Lab 1, we are not going to start by using EIGRP just yet, as all devices are connected to RR
router and hence would appear as directly connected for RR and show up on the routing table. We
can see this by giving ‘show ip route’ on RR.
As mentioned earlier, BGP has not been configured yet and none of the loopbacks for the routers
have been propagated. Let’s start by setting up RR, R1, R2, R3 and R4 with BGP 100. Create iBGP
peerings between R1, R2, R3 and R4 to RR. Advertise the loopback0 for R1, R2, R3 and R4.




Give the command ‘logging console’ in config mode to see parser notifications.
RR(config)#logging console
RR(config)#router bgp 100

RR(config-router)#neighbor 150.10.1.1 remote-as 100
RR(config-router)#exit
This should bring up the adjacency between R1, R2, R3 and R4 with RR. Give the following command
to see BGP routes learnt by RR.
However, although R1 has advertised the loopback 0 network to RR router, RR route has not
propagated this information on to other routers. For example, if you look at R3’s routing table, there
are no BGP routes learnt. If there was a direct peering between R1 and R3 then the loopback
networks would have been shared but this would need a full mesh peering for all routers to know all
loopback networks.
Let us now enable route reflector on RR router. Note there is no need of any configuration on R1,
R2, R3 and R4. In this lab, we would setup R3 and R4 as route reflector clients. R1 and R2 would not
be clients.

RR(config-router)#neighbor 150.30.1.1 route-reflector-client
%BGP-5-ADJCHANGE: neighbor 150.30.1.1 Down RR client config change

%BGP_SESSION-5-ADJCHANGE: neighbor 150.30.1.1 IPv4 Unicast topology base removed from
session RR client config change
%BGP-5-ADJCHANGE: neighbor 150.30.1.1 Up
RR(config-router)#neighbor 150.40.1.1 route-reflector-client

RR(config-router)#
%BGP-5-ADJCHANGE: neighbor 150.40.1.1 Down RR client config change

%BGP_SESSION-5-ADJCHANGE: neighbor 150.40.1.1 IPv4 Unicast topology base removed from
session RR client config change
%BGP-5-ADJCHANGE: neighbor 150.40.1.1 Up
RR(config-router)#exit
RR(config)#
At this stage, if you view the advertisement from R3 to RR for the 120.3.1.1 as shown in the show
command below you notice the show command now includes ‘Received from RR-Client’ for R3’s
loopback network but not for R1’s loopback network.
RR#sh ip bgp 120.3.1.1 255.255.255.255

BGP routing table entry for 120.3.1.1/32, version 4
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3 4
Refresh Epoch 1
Local, (Received from a RR-client)
150.30.1.1 from 150.30.1.1 (120.3.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
There is another important note here. Routes are sent to the Route reflector router from other
routers without an awareness of networks being further forwarded on. All routes when forwarded
would need the next hop to be updated but for Route reflectors this is not the case. If we look at the
BGP neighbors command for R3’s peering, you will notice that the next hop field is not updated.
This means that if the next hop is not reachable, these routes will not a valid/ reachable routes.
If you go to R3 and see the routing table, you should not be able to see any BGP routes yet. This is
because the next hop is still not unknown.
In this lab, we simply make all routers aware of the 150.0.0.0/8 supernetwork via EIGRP. Please
repeat the following commands on all routers including R5 and R6.
R3(config-router)#no auto-summary
Now look at the BGP routing tables for R1, R2, R3 and R4. You may recall that R3 and R4 are route
reflector clients but R1 and R2 are not. Routing advertisements sent from the route reflector must
conform to the following three rules:
Routes learned from EBGP peers can be sent to other EBGP peers, clients, and non-clients.
Routes learned from client peers can be sent to EBGP peers, other client peers, and non-clients.
Routes learned from non-client peers can be sent to EBGP peers, and client peers, but not other
non-clients.
This would mean that R3’s loopback is shared with other client members like R4 and non-client
members like R1 and R2. However, R1’s routes are not shared with R2 and vise-versa as they are
both non-clients to RR router.
Sharing eBGP routes
We can now enable R5 in BGP AS 200, R6 under BGP AS 300 and create eBGP peerings to RR router.
RR being the route reflectors will share any routes learnt from an eBGP neighbor to its clients, non-
clients and even other eBGP neighbors.



After adjacency has been built, you can see that R5 is now aware of the loopback from all other
routers.
This is the end to Part 2a of the lab. To summarise, routes learned from eBGP peers can be sent to
other eBGP peers, clients, and non-clients. Routes learned from client peers can be sent to eBGP
peers, other client peers, and non-clients. Routes learned from non-client peers can be sent to eBGP
peers, and client peers, but not other non-clients.
Part 2b – Route Reflection with Clusters
Clusters are used in large scale BGP AS where there are a number of route reflectors. For the
purpose of understanding clusters, a small topology with two route reflector clusters are considered.
Topology
IP Addressing Table
R1 G0/0 150.15.1.1/24 R4 G0/3 150.34.1.4/24

G0/1 150.12.1.1/24 Loopback0 120.4.1.1/32
Loopback0 120.1.1.1/32
R5 G0/0 150.15.1.5/24
R2 G0/1 150.12.1.2/24 G0/1 150.35.1.5/24
G0/2 150.23.1.2/24 Loopback0 120.5.1.1/32
Loopback0 120.2.1.1/32 Loopback1 120.5.2.1/32
R3 G0/1 150.35.1.3/24
G0/2 150.23.1.3/24
G0/3 150.34.1.3/24
Loopback0 120.3.1.1/32
Load the ‘LAB 2b – Route Reflection with Clusters.yaml’ file to complete this part of the lab.
Here R1, R2, R3 and R4 belong to AS 100. R5 is in AS 200 and would need to have eBGP peerings to
R3 and R1. However, in this part of the lab we are going to have two Route reflectors here. R2 is a
route reflector with R1 as a client and R3 is a route reflector with R4 as a client.
Once you have imported the lab and started all the devices you would notice that all devices have ip
addresses for interfaces and loopbacks configured as well as EIGRP for reachability.
Create the following BGP peerings. If you are unsure please refer the Appendix A for this lab at the
end.
• Configure R5 in AS 200 with eBGP peerings to G0/0 of R1 and G0/1 of R3. R1 and R3 would
be in AS 100. Advertise using network statements Loopback0 and Loopback1 for R5.
• Configure R1,R2,R3 and R4 into AS 100. Create iBGP peerings between R1 and R2, R2 and R3,
R3 and R4. Advertise their respective Loopback0 in BGP.
• Configure eBGP peerings on R1 back to R5 and R3 back to R5.
Once you have completed this, you will notice that R5 is sending Loopback0 and 1 networks into R1
and R3. However, R1 has it in the routing table but R3 does not. This is because when you have two
or more entry or exit points for an AS; which in this case is two entry/exits from AS100 to AS200.
Then the lowest router ID is picked for the routes to be installed. The router ID for R1 is 120.1.1.1
and for R3 it is 120.3.1.1.
Looking at the BGP summary table for R5, the state for 150.35.1.3 remains at idle.
Creating Route reflectors
Let us now create two route reflector groups. Let R2 and R3 be route reflectors where R1 is a client
for R2 and R4 is a client for R3. This means that R2 and R3 are route reflectors but act as non-clients
to each other.
Since there are two clusters, you would create cluster IDs for R2 and R3. To make things simple, use
2.2.2.2 for R2 and 3.3.3.3 for R3. Let us start with R2 first.

R2(config-router)#bgp cluster-id 2.2.2.2
R2(config-router)#neighbor 150.12.1.1 route-reflector-client
At this point, without configuring R3 if you look at R3’s routing table you will see the following.
This is because as we saw in Part2a of this lab, route reflectors will send advertisements to non-
clients (in this case R3) of routes learnt from a client (in this case R1).
However, if you look at the specifics of the route that is propagated from R2 of R5’s loopbacks, you
will notice that there is a new field now called Originator and Cluster List (2nd last line in the figure
below). However, R4 will not have these routes from R3 due to BGP split horizon rule.
It says that the advertisement came from 120.1.1.1 from the cluster which has an ID of 2.2.2.2. We
had configured 2.2.2.2 for R2.
Let us now configure R3 with cluster ID and also set R4 as its client.

R3(config-router)#bgp cluster-id 3.3.3.3
R3(config-router)#neighbor 150.34.1.4 route-reflector-client
Now R3 would have reflected the routes learnt from R2 on to R4. Here routes learnt from one route
reflector is sent to another route reflector group. So lets look at R4 routing table.
Route 120.5.1.1 and 120.5.2.1 are now installed. However, from Part2a we know that the next hop
value is not updated during the route reflection process. R3 had a cluster id pointing to 2.2.2.2 but
R4 is not connected directly and is no aware of 2.2.2.2.
If we look at specifics for the R5’s loopbacks on R4, you will see the cluster list is now updated to
include a path; which in this case is 3.3.3.3 followed by 2.2.2.2. This is read from left to right.
If you try to ping the network 120.5.1.1 on R4 it would be reachable. This is because it does a
recursive lookup on the routing table. If the lookup was to fail due to IGP failure (EIGRP in this case)
then it will not be indicated as best route. The word ‘best’ is listed in the above image as the last
word on the 3rd last line.
Part 2c – Confederations
Defined in RFC 5065, Autonomous System Confederations for BGP, confederations, like route
reflectors, are used to reduce the need for fully meshed iBGP peerings in large-scale deployments. In
confederation, a public AS is split into smaller Sub Autonomous Systems (Sub-ASs), which exhibit a
hybrid behavior of both iBGP and EBGP. Inside a Sub-AS, the requirement for either fully meshed
iBGP peerings or route reflection still applies, but between Sub-ASs, EBGP advertisement rules apply.
Topology
Load the YAML file named ‘Part 2c-Confederations.yaml’. Once you have imported this file and
booted all devices you will notice that all routers are configured with IP address and loopbacks
similar to the previous Part (2b). However, in the lab we would have R5 in AS 10 and R6 in AS 30. R1,
R2, R3 and R4 would be primarily in AS 20. When using confederations, the primary AS is split into
smaller internal sub-ASs which in this case is AS21 and AS22. Although normally it is common to see
Sub-AS numbers being private numbers it is not necessary to have them. These numbers are
unknown to other external AS.
Here would have R1 and R2 be in AS21 and R3 and R4 in AS22. These routers are configured using
sub-AS numbers and not the Primary AS number. The primary AS number is setup as the bgp
confederation identifier. It is also important to note that each confederation router needs to be
configured with the confederation identifier as well as confederation peers which are other sub-AS
numbers that it needs to be aware of.
Let us start with R1 –
R1(config)#router bgp 21 // router AS is set to sub-AS

R1(config-router)#bgp confederation identifier 20 // the primary AS is set here
R1(config-router)#bgp confederation peer 22 // List the other sub-ASs as peers
R1(config-router)#neighbor 150.15.1.5 remote-as 10 // eBGP peering is done as normal
R1(config-router)#neighbor 150.12.1.2 remote-as 21 //iBGP is hybrid here with a peer
Similarly we configure R2 as part of the same confederation.
R2(config)#Router bgp 21
R2(config-router)#bgp confederation identifier 20
R2(config-router)#bgp confederation peer 22
R2 has not created an adjacency with R1. The loopback networks have now propagated. Giving
‘show ip route bgp’ should display this.
When looking at the specifics for the learnt network, you will see it is recognised that it has learnt
this from an internal confederation setup. On the 2nd last line you can see confed-internal.
Now let’s configure R3 and R4 that belong to confederation AS 22. R4 would have an external
peering to R6 as well.
R3 has now learnt R1 and R2’s loopback networks. R3 should show that it has learnt this via an
external confederation as it belongs to a sub-AS 21. Hence it is noted as confed-external.
Let us now configure R4.
However R4 has learnt this via R3 which is on the same sub-AS so it will show as confed-internal.
On R4 if you look at the AS path of the learnt route it will also show sub-AS in brackets. Look at the
image below.
At this point the AS 20 is now complete with two internal sub-ASs 21 and 22. Let us now complete
eBGP peerings on R5 and R6. Include the loopback networks for these as well.
Once they have converged. Have a look at the bgp table on R6 and compare that with R4.
Notice the use of brackets under path for routes learnt via confederation sub-AS. However from the
perspective of an external AS, routes have simply transited the primary AS and is not aware of
confederation setup. Have a look on R6 for R5 AS10 routes. It shows that it originated from AS10 and
then went to AS20 before reaching R6 which is in AS30.
Appendix A
Here are the configs for creating BGP peerings for Part2B.
R1
neighbor 150.15.1.5 remote-as 200

network 120.1.1.1 mask 255.255.255.255
exit
R2
router bgp 100

network 120.2.1.1 mask 255.255.255.255
exit
R3
router bgp 100

network 120.3.1.1 mask 255.255.255.255
exit
R4
router bgp 100

network 120.4.1.1 mask 255.255.255.255
exit
R5
router bgp 200

network 120.5.1.1 mask 255.255.255.255
network 120.5.2.1 mask 255.255.255.255
exit
Lab 3 – BGP Best Path 1 (Weight, Local Preference and AS Path)
In this lab worksheet, there are three BGP attributes we would look at. These attributes are Weight,
Local Preference and AS Path which will be used to manipulate the best path BGP would install into
the routing table.
Topology
Please note the YAML file named ‘Lab 3 - BGP Best Path 1.yaml’ needs to be imported to complete
this lab. Please note that the G0/2 interface is shutdown in this initial file for the first part of this lab.
Table of IP addresses
R1 G0/0 150.14.1.1/24 R4 G0/0 150.14.1.4/24

G0/1 150.12.1.1/24 G0/1 150.34.1.4/24
Loopback0 1.1.1.1/32 G0/2 150.46.1.4/24
Loopback0 4.4.4.4/32
R2 G0/0 150.23.1.2/24
G0/1 150.12.1.2/24 R5 G0/0 150.56.1.5/24
Loopback0 2.2.2.2/32 G0/2 150.35.1.5/24
Loopback0 5.5.5.5/32
R3 G0/0 150.23.1.3/24
G0/1 150.34.1.3/24 R6 G0/0 150.56.1.6/24
G0/2 150.35.1.3/24 G0/3 150.46.1.6/24
Let us start with preparing the lab by creating BGP peerings for each link you see on the topology.
Create R6 is a router reflector for R4 and R5. The AS numbers are as per the topology diagram. Refer
to Appendix A on the last page if you are unsure or would simply like to check your answers.
BGP Weight
Once you have the peerings all setup, go to AS 40 on R4. Let us first look at the BGP table.
There are a few things to note here. Looking at the route learnt for R1’s loopback 1.1.1.1/32, we can
see that it has been learnt via two paths. The first path has the next hop via 150.34.1.3 which is via
R3 and the other path has the next hop as 150.14.1.1 which is via R1. However, for the path via R3,
under the Path field (right) it says it has taken the path ’30 20 10 i’ which means that it has transited
AS 30 which has got it from AS 20 and that was learnt from AS 10 from; where it initially originated
from. Whereas the other path on the 2nd line shows that it came from ’10 i’ which came straight
from R1.
Notice that the 2nd path has an index *> which means it is a valid path and also the best path. Only
the best paths are candidates to be installed into the routing table. The reason this is the case is
because by default, BGP uses the shortest AS PATH to be installed as best paths.
There is a column here named Weight (2nd from the left) and it is all marked as zero to start with. For
locally owned routes the default value is 32768. You can observe this for the loopback 4.4.4.4/32
network.
Weight is Cisco-specific and is not transported along with BGP prefixes/updates. This attribute is
configured locally on the router, using the command neighbor <IP_Address> weight 1-65535. Thus, if
there are two equal prefixes with different weights, the one with the highest weight is preferred.
In this case, R4 has two paths to reach R1. Note as mentioned at the start the link from R5 to R3 is
shutdown for now. As Weight is a local attribute, let us use this attribute to manipulate R4 to choose
the path via R3 rather than R1 which is currently chosen as the best path.
This can be set up in two ways, one being the neighbor command and the other using a route map.
Let us simply add a weight using the neighbor command for the current best path to see its usage.
Note this will not make a change as it is considered the best path already.
R4(config-router)#neighbor 150.14.1.1 weight 100
Clear the BGP table by using the following command to observe a quick update.
R4#clear ip bgp * soft
‘Show ip bgp’ should now show that the weight of 100 has been applied to the current route.
Let us now manipulate R4 in using R3 which has the long path to reach R1 as the Best path with a
higher weight by using a route map.
Create a list of routes that is of interest. Here we are only considering 1.1.1.1/32.
R4(config)#access-list 1 permit 1.1.1.1 /32
Apply that to the route map and set the weight.
R4(config)#route-map SET_WEIGHT
R4(config-route-map)# match ip address 1
R4(config-route-map)# set weight 200
R4(config-route-map)#exit
Apply the route map to the neighbor statement in the IN direction. This is because you are wanting
the weights to be applied as advertisements that are coming into the router for the network 1.1.1.1
via the chosen neighbor.
R4(config-route-map)#router bgp 40
R4(config-router)# neighbor 150.34.1.3 route-map SET_WEIGHT in
Clear the BGP table by using the following command to observe a quick update and give ‘show ip
bgp’
Notice that the BEST index marked with > is now given the 1st path with longer AS path.
BGP Local Preference
The previous attribute weight was mainly used when there are two or more paths that exist for a
local router. This is not propagated within the AS as well. Local preference is a well known
discretionary attribute and is propagated through the AS. Higher the value is preferred.
For local routes the default local preference within the AS is 100. You can observe this from the
previous ‘show ip bgp’ from R4.
Routes from R5 and R6 which are from the same AS 40 have a local preference installed.
Remember that R6 has route reflector clients set up for R4 and R5. Enable G0/2 on R5.
R5(config)#int g0/2
R5(config-if)#no shutdown
This would bring the adjacency to R3 up.
If you now go to R6 and check the paths to 1.1.1.1 from R6, you will see the following.
The best path marked with > is via 150.34.1.3 with is via R4. The local preference is the same. So let
us manipulate this by changing the local preference for AS 40 to choose R5 as the best path.
Similar to the previous attribute, create an access list that has the network of interest and apply that
to a route map where you can change the local preference. Use the route map on the next hop
neighbor R3.
R5(config)# access-list 1 permit 1.1.1.1 /32
R5(config)#route-map SET_LP
R5(config-route-map)# set local-preference 200
R5(config-router)# neighbor 150.35.1.3 route-map SET_LP in
Clear the BGP session for a quicker update and have a look at R6 again.
You can see that that best path has now changed to via R5 from R6 and the local preference has
propagated throughout the AS 40.
Challenge question
At this point go to R4. Look at the following show commands. Why is it that R4 has chosen R3 to get
to R1 rather than R5 even though the local preference of 200 is via R5?
Answer: ________________________________________________________________________
_______________________________________________________________________________
AS Path Prepending
As we noted at the start of this lab, the shortest path that has the lowest number of transiting AS is
the preferred. So it is possible to inject AS numbers into the advertisement to increase the length of
the AS path that in turn influence the best path selection.
We look at a simple example here. Looking at R2 the AS path to reach 5.5.5.5/32 is as follows. Give
‘Show ip bgp’ to see this. The best path is via 150.23.1.3 which has a path of AS 30, AS 40 via R3. The
other path is via 150.12.1.1 which is via R1.
Let us prepend AS 20 which R2 is part of into the advertisement sent to R3 to increase the length of
the path field. The procedure to do this is similar to the attributes above.
R2(config)#route-map ASP_R5
R2(config-route-map)# set as-path prepend 20 20
R2(config-router)# neighbor 150.23.1.3 route-map ASP_R5 out
We use out here so that is it propagated to R3. Give the clear command on R2 and wait a few
seconds. Look at R2’s bgp table.
The best path has now changed. Wondering where the ’20 20’ went? Have a look at R3’s BGP table.
This is the end of the lab. Please remember to complete the quiz questions on GCU learn.
Appendix A
R1
logging console
router bgp 10
network 1.1.1.1 mask 255.255.255.255
exit
R2
logging console
router bgp 20
network 2.2.2.2 mask 255.255.255.255
exit
R3
logging console
router bgp 30
network 3.3.3.3 mask 255.255.255.255
exit
R4
logging console
router bgp 40
network 4.4.4.4 mask 255.255.255.255
exit
R5
logging console
router bgp 40
network 5.5.5.5 mask 255.255.255.255
exit
R6
logging console
router bgp 40
neighbor 150.46.1.4 route-reflector-client
neighbor 150.56.1.5 route-reflector-client
network 6.6.6.6 mask 255.255.255.255
exit
Lab 4 – BGP Best Path 2
In this lab worksheet, we would build upon the previous lab and look at origin codes, next hop self,
MED and eBGP over iBGP in the selection process.
Topology
Please note the YAML file named ‘Lab 4 - BGP Best Path 2.yaml’ needs to be imported to complete
this lab. All devices have their IP address configured.
Table of IP address
R1 G0/0 150.12.1.1/24 R3 G0/0 150.34.1.3/24

G0/1 150.13.1.1/24 G0/1 150.13.1.3/24
R2 G0/0 150.12.1.2/24 R4 G0/0 150.34.1.4/24

G0/1 150.24.1.2/24 G0/1 150.24.1.4/24
BGP Peerings
R1 and R2 are in AS 10, R3 is in AS 20 and R4 is in AS 30. Based on the knowledge you have gained
from previous labs, create BGP peerings for each of the links as per the table above. Advertise the
loopback 0 for each router into BGP. Once you have competed this verify your answers with
appendix A.
Next hop self
R1 and R2 belong to the same AS. However, R1 can see 3.3.3.3/32 network from R3 via it’s external
neighbor peering to R3 but R2 sees the same network but prefers to go via R4. The figure below
shows both the paths for 3.3.3.3/32.
However, the recursive lookup to 150.13.1.3 which comes from an advertisement from R1 is not
reachable. Try a ping test to verify.
This may not be ideal in some cases as the AS would use various exit points to each the same
destination. If we want R1 to be the path that R2 exits for 3.3.3.3/32 then a next hop self can be
used to update the next hop field to R1 for R2. This makes the external next hop be replaced by a
locally reachable exit point.
R1(config-router)#neighbor 150.12.1.2 next-hop-self

Now you can see that the next hop value has changed to R1 for R2 to reach 3.3.3.3/32 and is being
marked as the best path.
Origin
The origin codes in BGP are looked at to decide the path to a destination when the weight, local
preference, Shortest AS Path length in the context of comparison forms a tie. It also checks that the
AIGP and locally originated path is the same. There are 3 origin codes as you can see from the show
command above from the previous section.
Origin codes: i - IGP, e - EGP, ? – incomplete.
The code ‘e’ is currently not seen often and it is hidden in the CISCO IOS as well. As you can see in
most of the ‘Show ip bgp’ outputs the ‘i’ is seen at the end of every network. This is because this is
locally or internally learnt via BGP advertisement. The ‘?’ incomplete field is displayed with the
network that cannot be locally verified and the source is less believable. This can be seen for all
redistributed routes into BGP.
Let’s create an EIGRP session in BGP AS 10. Lets use EIGRP AS 20 for this and share the 150.12.1.0/24
network. We shall create a new loopback 1 in R2 with the ip address 20.20.20.20/32 and advertise
that into EIGRP.
Please note: EIGRP AS is not the same as BGP AS. Hence creating AS 20 for EIGRP will not have an
affect on BGP AS 20 run on R3.
R2(config)#interface loopback1
R2(config-if)#ip add 20.20.20.20 255.255.255.255
R2(config-if)#no shut
Let us now take the 20.20.20.20/32 network that is advertised by EIGRP and redistribute that into
BGP AS 10 at R2.
R2(config-router)#redistribute eigrp 20
If you now go to R2’s BGP table, you will see that the 20.20.20.20/32 is injected into BGP and a local
internal weight of 32768 is inserted but the origin field is now marked as ‘?’. You can see the same in
R1 as well.
Multi-exit Discriminator (MED)
MED is a BGP attribute that is optional and non-transitive. On CISCO devices it is marked as metric.
The default value is 0. MED is only considered if there is tie between the various paths concerned up
until origin attribute.
Here is the BGP best path selection order:
✓ Weight
✓ Local preference
✓ Local originated (network statement, redistribution, or aggregation)
✓ AIGP
✓ Shortest AS_Path
✓ Origin type
✓ Lowest MED
✓ eBGP over iBGP
✓ Lowest IGP next hop
✓ If both paths are external (eBGP), prefer the first (oldest)
✓ Prefer the route that comes from the BGP peer with the lower RID
✓ Prefer the route with the minimum cluster list length
✓ Prefer the path that comes from the lowest neighbor address
To understand this better, lets say that R3 has a preference between AS 10 and AS 30 to exit. That
being R3 prefers exit via R4 which is AS 30. You can use the weight command to achieve this.
Challenge yourself and introduce a weight for 150 toward R4 from R3. Verify your answer by
checking appendix B.
Aiming at 1.1.1.1/32 ideally we would like return traffic to also come via R1-R2-R4. However, if you
go to R1 and check for 3.3.3.3/24 the best path is via 150.13.1.3 as next hop. This is because the AS-
path is shorter when compared to going via R2 and then to R4. If we go to R3, the best path is via R1.
MED is only considered if the AS Path length is the same, given that weight and local preference are
a tie.
There are two solutions to this part - One is to use AS-prepend as you did in the last lab or ask BGP
to ignore looking at AS Path length (not support on CML for the selected router type). Please use AS-
prepend to equal the length AS path length for R1. You can apply this from R3. Try this yourself and
check you answer with appendix C. You should see an output like below once completed.
R1 shows an alternative path to 3.3.3.3/32 via 150.24.1.4 which is inaccessible. What is the remedy
for this? (hint: a similar case has been seen in this lab).
Answer: ________________________________________________________________________
Please note: MED is applied in the out direction and only affects the adjacent AS. So if we apply MED
out to R1 from AS 20 on R3 it would reflect on AS 10 and not propagate to AS 30 from there.
Let us apply MED to R3 out toward R1 for all routes with a metric of 300. For MED, lower the better
and the default is 0. So we are trying to make the direct link less desirable so that R1 would go via R2
and then to R4.
Note: We cannot apply another route map to the same neighbor in the out direction. So simply add
metric to the route map that you created for AS-prepend. As per appendix C, I had used a route-map
named ASP.
R3(config-router)#route-map ASP
R3(config-route-map)#set metric 300
R3(config-route-map)#do clear ip bgp * soft
So the route-map in the out direction toward R1 from R3 would have two tasks; one to add AS
prepend with 20 and the other to set a metric of 300.
If we look at R2’s BGP table, we can see that the R4 is now preferred out to reach R3.
Always compare MED
At this point if we go to R1 and check if it uses R2 or R3; it will show R3. Your BGP table should show
one of the following outputs depending on if you have applied next hop self on R2 for 150.12.1.1
neighbor or not.
Or
Why is 150.13.1.3 being used? This is because for MED internal BGP routes are only considered by
default. Because this is not an internal route, BGP goes to the next stage of the best path selection
process where externally learnt routes have precedence over internal routes. This is why you see the
output as follows which means it has ignored MED and gone to the next stage.
We can force BGP to consider MED for all learnt routes (internal and external) and then make the
decision. In order to do this, we have to set the always compare MED on all routers within the AS
concerned. Here it is to do with R1 and R2 in AS 10.
R1(config-router)#bgp always-compare-med
Check the output again to see that the output has now changed to take the internal path to R2.
This is the end of the lab. Please remember to complete the quiz questions on GCU learn.
Appendix A
R1
logging console
router bgp 10
network 1.1.1.1 mask 255.255.255.255
exit
R2
logging console
router bgp 10
network 2.2.2.2 mask 255.255.255.255
exit
R3
logging console
router bgp 20
network 3.3.3.3 mask 255.255.255.255
exit
R4
logging console
router bgp 30
network 4.4.4.4 mask 255.255.255.255
exit
Appendix B
R3(config-if)#router bgp 20
R3(config-router)#neighbor 150.34.1.4 weight 150
R3(config-router)#do clear ip bgp * soft
Appendix C
R3(config)#route-map ASP
R3(config-route-map)#set as-path prepend 20
R3(config-router)#neighbor 150.13.1.1 route-map ASP out
Before
After
Lab 5 – BGP Aggregation
In this lab, we look at BGP aggregation and its different forms. It is similar to summarization, but BGP
does not act the same way with aggregation as you see in IGP summarization. It is important to
understand aggregation, as if done effectively, it can have a positive impact on the size of the BGP
table. It is paramount that BGP routers run with the smallest routing table possible for mainly
performance reasons.
Topology
Load the ‘LAB 5 – BGP aggregation.yaml’ file on your CML environment. There is also a similar file
with BGP peerings configured.
IP addressing table
Device Interface IP address
R1 G0/0 150.12.1.1/24
R2 G0/0 150.12.1.2/24
G0/1 150.23.1.2/24
R2 G0/0 150.34.1.3/24
G0/1 150.23.1.3/24
R4 G0/0 150.34.1.4/24
Aggregation
BGP can aggregate addresses when configured manually but will also advertise the original longer
prefix advertisements along with the summarised version. It is important to understand that when a
route path is looked up against the routing table the entry with the longest prefix match is chosen.
However, it is also vital to keep the number of routes to a minimum to ensure proper performance
of BGP.
Let us start by creating 4 loopbacks on R1 and R4 as per the table below. Ensure that BGP is
configured as per the topology and each physical link has a BGP peering. You can also choose to the
start the lab with the version that has the initial peering and loopbacks configured.
Device Interface IP address
R1 Loopback 1 10.10.0.1/32
Loopback 2 10.10.1.1/32
Loopback 3 10.10.2.1/32
Loopback 4 10.10.3.1/32
R4 Loopback 1 40.10.0.1/32
Loopback 2 40.10.1.1/32
Loopback 3 40.10.2.1/32
Loopback 4 40.10.3.1/32
Advertise the loopbacks into BGP using the network commands. Ensure you use a mask of
255.255.255.255 for your commands. Refer appendix A to check your configurations.
R1 and R2 are in AS 10. Check the BGP table on R3 and R2 to see the loopbacks from R1 being
advertised.
Let us now aggregate the 10.10 networks into a single advertisement on R2. The first two octets
have the same number which is 10. The 3rd octet for the four networks has 0,1,2,3. The binary
notation is presented below
Position 27 26 2 5 24 23 22 21 20
0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 1
2 0 0 0 0 0 0 1 0
3 0 0 0 0 0 0 1 1
Only the last two bits are different so the summary address would take a mask of /22 or
255.255.252.0
Use the following commands to create an aggregation.

R2(config-router)#aggregate-address 10.10.0.0 255.255.252.0
On R3, you should now see the following BGP table.
Notice that the summary entry 10.10.0.0/22 co-exists with more precise entries like 10.10.0.1/32.
Looking more in detail you will see that a new attribute ‘atomic-aggregate’ has also been inserted.
Summary only
If you would like only the 10.10.0.0/22 entry to be advertised and would not like the more precise
routes to be seen, then a summary only entry can be given to supress the /32 routes. Go to R2 and
insert the summary only keyword at the end of the previous command.
R2(config-router)#aggregate-address 10.10.0.0 255.255.252.0 summary-only
Suppressing networks
One of the other options for BGP aggregation is suppressing and un-supressing networks. Let us
suppress all but one network one R2 to see how this function behaves. This is particularly useful if
the network needs to be used for path manipulation or for best path selection at a different part of
the network.
Let us suppress the 10.10.1.1/32 network and let the other networks through. For this you would
need to first clear the summary-only command
R2(config-router)#no aggregate-address 10.10.0.0 255.255.252.0 summary-only
The network of interest is 10.10.1.1/32, so define a prefix list permit (to say you are interested in)
with this network.
R2(config)#ip prefix-list A permit 10.10.1.1/32
Then tie this prefix list to a route-map which you would use with your suppress statement. Suppress-
maps are used to create this function but they are based on route maps.
R2(config)#route-map SM permit 10
R2(config-route-map)# match ip address prefix-list A
R2(config-router)# aggregate-address 10.10.0.0 255.255.252.0 suppress-map SM
Look at the BGP table on R3 to see the outcome. 10.10.1.1/32 is not being advertised now.
Have a look at R2’s BGP table. You will see and indicator ‘s’ to state that is suspended for the
10.10.1.1/32 network.
However, in cases where it is easier to create a list of networks that needs to be advertised rather
than suppressed then you can use the un-suppress function. The way this is implemented is slightly
different to the previous case.
First, on R2 remove the last suppress-map command.
R2(config-router)#no aggregate-address 10.10.0.0 255.255.252.0 suppress-map SM
Lets say we only want to see the 10.10.1.1/32 network along with the summary advertisement.
Advertise the summary only command first.
We already have a prefix list A that is stating an interest in 10.10.1.1/32 network. We also have a
route map SM that is matching this prefix list A. So, we can use the same for the unsuppress-map.
However, the implementation done on the neighbor command.
R2(config-router)#neighbor 150.23.1.3 unsuppress-map SM
This will take a few seconds to update on R3. Give a soft clear command to speed up the update.
It is important to note that unsuppressed routes would still show up as suppressed on the BGP table
on R2. This is mainly because the summary-only command would suppress the /32 networks first
and the unsuppress-map works more like leaking out an advertisement like leak-maps do for IGP.
AS path information
Lets turn our attention to R4 and R1 now. R4 is advertising 4 loopback networks. R1 has received
these from R2. R1 has no eBGP peering with the rest of the network but has an iBGP peering with
R2.
Considering this, let us advertise a summary-only aggregation on R2 for R4’s loopbacks.
Challenge: Try to create this by yourself. If you are not sure have a look at the summary-only part of
this lab. Refer to appendix B to check you answer.
Have a look at R1’s BGP table now.
You may have noticed that summary address only is present but it is without the AS path
information.
It is important to remember that aggregation hides information previously found in the specific
prefixes. This includes all attributes, such as NEXT_HOP, AS_PATH, and so on. The new prefix
appears to be originated from within the local AS where aggregation is performed. This causes no
problems if all specific prefixes belong to the local AS. However, when you summarize prefixes
learned from other ASs, information hiding may result in the following dangerous consequences:
➢ Suboptimal routing, caused by loss of path information, such as AS_PATH, MED and so on.
➢ Routing loops, because removing the AS_PATH attribute and replacing it with an empty list
prevents the BGP loop-detection mechanism from working properly.
The second issue is more dangerous. To prevent it, it is possible to insert a special new member into
the AS_PATH of the newly created summary prefix. This element is called AS_SET and contains the
AS numbers found in all AS_PATHs of the specific prefixes. This list of AS numbers is unordered,
unlike the regular AS_SEQUENCE element. Its only use is for routing loop prevention; when BGP
receives a prefix, it scans the AS_PATH attribute. If the local AS number is found in any of the AS_SET
or AS_SEQUENCE elements, the prefix is dropped.
By default, the aggregated address in BGP will not include the AS-Set information. To force the use
of this information, specify the as-set option.
R2(config-router)#aggregate-address 40.10.0.0 255.255.252.0 summary-only as-set
This will now include the AS-Path information. A similar function is available for confederations AS-
Path within a primary AS.
This is the end of the lab. Please try the challenge lab if you haven’t already done for this week.
Appendix A
R1
interface Loopback0
ip address 10.10.0.1 255.255.255.255
!
interface Loopback1
ip address 10.10.1.1 255.255.255.255
!
interface Loopback2
ip address 10.10.2.1 255.255.255.255
!
interface Loopback3
ip address 10.10.3.1 255.255.255.255
!
router bgp 10
network 10.10.0.1 mask 255.255.255.255
network 10.10.1.1 mask 255.255.255.255
network 10.10.2.1 mask 255.255.255.255
network 10.10.3.1 mask 255.255.255.255
R2
router bgp 10
R3
router bgp 20
R4
interface Loopback0
ip address 40.10.0.1 255.255.255.255
!
interface Loopback1
ip address 40.10.1.1 255.255.255.255
!
interface Loopback2
ip address 40.10.2.1 255.255.255.255
!
interface Loopback3
ip address 40.10.3.1 255.255.255.255
!
router bgp 30
network 40.10.0.1 mask 255.255.255.255
network 40.10.1.1 mask 255.255.255.255
network 40.10.2.1 mask 255.255.255.255
network 40.10.3.1 mask 255.255.255.255
Appendix B
Lab 6 – BGP Community
In this lab we will look at BGP community attribute which is a well-known transitive but optional
attribute. There are various options that we would look at that determine how far routes must be
tagged across the network.
Topology
In this topology the centre of focus is AS 20. There are three autonomous systems 10, 30, 40 that
have loopbacks that we will use to learn how the community attribute functions.
Use the “Lab 6 - BGP community.yaml” file to import the topology. Alternatively, you can use the
peerings version of this lab that has BGP set up.
IP Addressing table
Device Interface IP Address Device Interface IP Address
R1 G0/2 150.12.1.1/24 R4 G0/0 150.24.1.4/24

Loopback0 1.1.1.1/32 G0/1 150.46.1.4/24
Loopback1 1.1.2.2/32 G0/2 150.34.1.4/24
R2 G0/0 150.23.1.2/24 R5 G0/1 150.35.1.5/24

G0/1 150.24.1.2/24 Loopback0 5.5.5.5/32
G0/2 150.12.1.2/24
R6 G0/1 150.46.1.6/24
R3 G0/0 150.23.1.3/24 Loopback0 6.6.6.6/32
G0/1 150.35.1.3/24
G0/2 150.34.1.3/24
Enable BGP peerings for all links shown in the topology. Check appendix A to compare your answers.
Advertise the loopbacks for R1, R5 and R6 into BGP using the network commands. Ensure you use a
mask of 255.255.255.255 for your commands. Refer appendix A to check your configurations.
No-advertise
BGP community attribute functions by adding a tag to the outbound advertisements. There are two
formats that are widely used. The classic format ranges from 1 to 4294967595 which is a 32 bit
format. The new format is 16:16 a bit format where the first 16 bits is generally used for defining the
source autonomous system and the second 16 bits is the tag value. This is mostly a visual
representation, and the new format must be enabled for the administrator to view it as a 16:16
format.
When A tag value is used, this is classed as a user defined setting. There are four commonly used
pre-set community settings which are Internet, local AS, no advertise and no export.
Also, it is important to note that by default the community attribute is not sent along with the
advertisement. In order to enable this the following command has to be used.
Neighbor <ip address> send-community
Let us start by looking at the no-advertise option. This option lets a router to send out a community
tag but request the receiver not to pass it on to its neighbours. R1 as two loopbacks 1.1.1.1/32 and
1.1.2.2/32. Let us use 1.1.1.1/32 to be see the no-advertise option.
First, define the network of interest in an access-list on R1.
R1(config)#access-list 1 per 1.1.1.1 /32
Next, create a route map to assign a community attribute to this network.
R1(config)#route-map A per 10
R1(config-route-map)#match ip add 1
R1(config-route-map)#set community ?
<1-4294967295> community number
aa:nn community number in aa:nn format
gshut Graceful Shutdown (well-known community)
internet Internet (well-known community)
local-AS Do not send outside local AS (well-known community)
no-advertise Do not advertise to any peer (well-known community)
no-export Do not export to next AS (well-known community)
none No community attribute
R1(config-route-map)#set community no-advertise

It is important to note that an implicit deny statement is added at the end of every route map.
Hence in order for R1 to send out the rest of the networks as is, a blank permit statement is used.
R1(config-route-map)#route-map A permit 30
Apply this route-map A to R1’s eBGP peering to R2.
R1(config-router)#neighbor 150.12.1.2 route-map A out
It is applied to the advertisements going from R1 to R2 hence it is setup as out on R1.
At this point, if you check on R2 by giving ‘show ip bgp 1.1.1.1’, you will not see the community tag.
This is because by default sending community information is disabled. You can enable it by the
following command.
R1(config-router)#neighbor 150.12.1.2 send-community
Give the soft clear command to speed up the refresh of the BGP table on R2.
You should now see as highlighted the community attribute stating that it should not advertise to
other peers. There are two things to note here. Firstly, without the send-community being enabled
to R3 and R4, R2 will not send any community information (if any) and secondly even if you enable
this, R2 has a no-advertise setting from R1 requesting R2 not to pass it on to other peers. Check on
R4 to see if the 1.1.1.1/32 is available. As it is set to no-advertise this should not be shown, as
follows.
User-defined setting
Let us consider the 2nd loopback on R1 for this task. This is the loopback1 with ip address 1.1.2.2/32.
Create an access list to define the network of interest.
Add to the previous route-map by using a sequence number between 11 and 29 to slot the rule in
between the one already configured in the previous task.
R1(config)#route-map A per 20
R1(config-route-map)#match ip add 2
R1(config-route-map)#set community 10:50
The route-map and the send-community option are already applied in the previous task, so this does
not need to be repeated.
At this point if you look at the route 1.1.2.2/32 on R2 you will see that the community identifier is
655410 and not in the new format 10:50.
To view this in the new format give the following command in config mode.
R2(config)#ip bgp new-format
Now check the network again on the BGP table and you should see the community field being
updated to the new format.
To send the community update to R2’s peers use the following commands.
Check R4 to see the community information.
No-export
R4 will pass the 1.1.2.2/32 information on the external peer R6. You can check this on R6.
If you do not want the tagged route to leave the current AS, then a no-export option can be used to
limit it to within the current AS. In order to action this, let us match the community value on R2 and
convert this to a pre-defined setting called no-export.
You can use community values as is in SET commands but not in MATCH commands. For matching
you would need to create a community list defining all the values of interest. We have only one
which is 10:50.
R2(config)#ip community-list 1 permit 10:50
Let us create a route-map to match the above community list and set it to no-export.
R2(config)#route-map B per 10
R2(config-route-map)#match community 1
R2(config-route-map)#set community no-export
R2(config)#route-map B per 50
R2(config-route-map)#ex
R2(config-router)#neighbor 150.24.1.4 route-map B out
After doing a soft clearing on R4’s BGP table, check R4 for 1.1.2.2 network.
After which check on R6 for 1.1.2.2.
Challenge Question: If you look at R3 and R5 you will notice that there is no change to 1.1.2.2/32
network and does not contain the community setting on no-export. Why?
Answer: _____________________________________________________________________
Local-AS
The local AS feature is commonly used with BGP confederations where a defined private AS can be
within another AS. When used without confederations it would be like no-export.
Let us consider the loopback from R5. In order to match all networks, there is no need to use a
match statement as in it absence it would mean match all.
R5(config)#route-map C per 10
R5(config-route-map)#set community 5
R5(config-router)#neighbor 150.35.1.3 route-map C out
Have a look for 5.5.5.5 on R3.
To restrict tags with 5 within the local AS use the local-as option.
R3(config)#ip community-list 2 permit 5

R3(config)#route-map D per 10
R3(config-route-map)#match community 2
R3(config-route-map)#set community local-AS
R3(config-route-map)#route-map D per 50
R3(config-router)#neighbor 150.23.1.2 route-map D out
R3(config-router)#neighbor 150.34.1.4 route-map D out
R3(config-router)#
R3(config-router)#do clear ip bgp * soft
R1 should now not have a copy of 5.5.5.5.
In this example we do not use confederations. Why don’t you challenge yourself by creating your
own confederation scenario and try out community local-as. You can alternatively choose to repeat
the confederation lab and add this feature to see its output.
Appendix A
R1
router bgp 10
network 1.1.1.1 mask 255.255.255.255
network 1.1.2.2 mask 255.255.255.255
R2
router bgp 20
R3
router bgp 20
R4
router bgp 20
R5
router bgp 30
network 5.5.5.5 mask 255.255.255.255
R6
router bgp 40
network 6.6.6.6 mask 255.255.255.255
Lab 7 – BGP Route Filtering
In this lab, we would look at various route filtering techniques.
Topology
Please use the Lab 7 - BGP Route Filtering.yaml file to do this lab. The topology is preconfigured with
IP address and some BGP peerings.
AS Path regular expressions
For AS path filter a few commonly used expressions are used.
Expression Meaning
.* Anything
^$ Locally originated routes
^10_ Learned from AS 10
_10$ Originated from AS 10
_10_ Should have transited AS 10
You will see more of these used as you progress with the lab.
Local AS
R4, R5 and R6 belong to AS 100. However this AS has two links to R3 via R4 and R6 which would like
to maintain a different (or most commonly an old) AS number. Here that AS number is 40 for R3.
Peering are setup on R3 pointing to R4 and R6 with remote-as set as 40.
However, R4 and R6 have no peerings setup to R3. Peerings have been setup to R5 using AS 100. R5
is a router reflector as well. Below is what R5’s router configurations look like.
If the AS 100 has to be presented to R3 with a local-as number 40 then R6 and R4 would need to
create an ebgp relationship with R3 using the following commands.

R6(config-router)#neighbor 150.36.1.3 local-as 40
Configure R4 similarly.

R4(config-router)#neighbor 150.34.1.3 local-as 40
You will now see that R3 has BGP adjacency with R6 and R4. If you go to R5 now you will see that the
BGP table is now updated with routes from R3 and that the AS path for foreign routes would include
the AS path 40 as seen below.
Since routes originate from AS100, these will be advertise with the AS100 and AS40 on to other
routers. If you go to R2 and use the filter with the regular expression 100$ to show all routes learnt
that is sourced from AS100, you should see the following.
If you do not want R5 which is in AS 100 to see that the AS path information for ebgp routes have
the local-as 40 in it then you can give the following command on R6 and R4
R6(config-router)#neighbor 150.36.1.3 local-as 40 no-prepend
R4(config-router)#neighbor 150.34.1.3 local-as 40 no-prepend
The BGP table on R5 should now be updated without the AS40 in it. You can also use the regular
expression when searching – R5#sh ip bgp regexp ^40 to see if there is any routes with the AS paths
that start with 40. Note this is only for internal AS updates and not for outbound routes. R3, R1 and
R2 will still see routes that originate from AS100 with the number 100 and 40 in the AS path.
Conditional Advertisement
Conditional advertisement allows the BGP speaker to advertise a set of BGP prefixes to a peer only if
certain other prefixes are present or not present in the local BGP table. Thus, the existence (or non-
existence) of those “trigger” prefixes is used as a condition to advertise selected prefixes to a peer.
Conditional advertisements are helpful in situations with multiple uplinks to different ASs.
Let us consider a scenario such that if R3 does not have any reachability to 2.2.2.2/32 then R3 should
not advertise any routes that is sourced from AS100 to R1.
Check the BGP table on R3.

And the BGP table on R1 looks like this
The network 2.2.2.2/32 is sourced from AS20. Using a conditional advertisement let us create a
route filter. This requires two route maps – an advertise map which lists the prefixes that would be
published if the condition is met and an exist or non-exist condition map.
Here the advertise map would list all routes that is sourced from AS100 to be advertised to R1. And
the exist map would check if any route 2.2.2.2/32 is installed in the BGP table.
First let us create the advertise map. Here an as-path access list is used to select all interest routes
with an AS path that is sourced from 100. Configure the following commands on R3.
R3(config)#ip as-path access-list 1 permit 100$
R3(config)#route-map ADVERTISE_MAP permit 10

R3(config-route-map)#match as-path 1
The create a route map to match the network that needs to exist.
R3(config)#ip prefix-list R2 permit 2.2.2.2/32

R3(config)#route-map EXIST_MAP permit 10
R3(config-route-map)#match ip address prefix-list R2
Now apply this as follows to the neighbor peering to R1.

R3(config-router)#neighbor 150.13.1.1 advertise-map ADVERTISE_MAP exist-map EXIST_MAP
To check shut down loopback 0 on R2. This should take out 2.2.2.2/32 from R2’s advertisement to
R3, and then R3 would remove the entry in its routing table which is against the condition of the
EXIST_MAP. This will in turn remove all advertisements from R6 and R4 being sent to R1.
Once verified, give no shutdown on R2’s loopback0 interface and see the routes on R1 been
populated back from AS 100.
Inject Map
Conditional Route Injection (CRI) is special feature that allows a BGP speaker to “de-aggregate” a
particular prefix. As you know, aggregation is critical to large-scale routing for reducing routing table
size and increasing stability. CRI operation is the opposite of aggregation, and its purpose is to create
specific prefixes at the administrator’s discretion. This may be useful for optimizing routing by
advertising some specific subnets of the aggregate across a certain path. CRI is similar to the BGP
unsuppress-map feature, but it will work on any router, not just the one originating the aggregate
prefix. However, because of the lack of information about the prefixes that were summarized, you
must explicitly set the prefixes to be injected into the BGP table.
To configure CRI, you need two route-maps. The first route-map specifies the prefixes to be injected
into the BGP table by means of the set ip address prefix-list <MAP1> command. The le and ge
keywords in the prefix-list entries are ignored. In addition to setting the prefixes, you may also set
other BGP attributes, such as Weight, Local Preference, Origin, Metric, Community list, and so on.
The AS_PATH attribute is reset to an empty list, to reflect the fact that prefixes were originated in
the local AS. By default, the new prefixes don’t have a Local Preference value assigned and the
Weight attribute is reset to zero (unlike 32768 for locally originated prefixes). This could be changed
by setting these values manually.
The second route-map defines the conditions that must be met for the new prefixes to be injected.
This route-map must have two match statements. The first statement is match ip address prefix-list
<MAP2> , and it matches the prefix list defining the aggregated prefix. The second statement is
match ip route-source prefix-list <NAME> . This prefix-list should match the IP address of the BGP
peer that advertised the aggregate to the local router. Remember that this is NOT the NEXT_HOP
attribute of the aggregate prefix. It is the IP address used to establish the BGP session with a peer
that sent the update to the local system. The two route-maps are then used as follows:
route bgp <AS#>

bgp inject-map <MAP1> exist-map <MAP2>
The result is that prefixes matching MAP1 are injected in the local BGP table if the conditions
specified by MAP2 have been met.
In this section, we are going to use loopbacks 10,11,12,13 from R1 and send out an aggregate
advertisement. R3 on receiving this aggregate advertisement would inject a route equivalent to
loopback 11’s address on R1 that is 1.10.1.0/24.
Create an aggregate summary of the loopbacks 10,11,12,13 on R1 and advertise them.
R6 should now have received a new entry of 1.10.0.0/22 via R3. Please use a soft clear to update the
table if you see any non-aggregated routes as well.
First, let us create a list to what we would like to inject

R3(config)#ip prefix-list INJECT_PREFIX permit 1.10.1.0/24
R3(config)#route-map INJECT_MAP permit 10

R3(config-route-map)#set ip address prefix-list INJECT_PREFIX
R3(config-route-map)#set origin igp
Next let us create a map to match the aggregation that R3 needs to look out for. You can get this
from the BGP table.
R3(config)#ip prefix-list AGGREGATE permit 1.10.0.0/22
R3(config)#ip prefix-list ROUTE_SOURCE permit 150.13.1.1/32
R3(config-route-map)#route-map EXIST_MAP1 permit 10

R3(config-route-map)#match ip address prefix-list AGGREGATE
R3(config-route-map)#match ip route-source prefix-list ROUTE_SOURCE
R3(config-route-map)#ex
Finally apply these two maps into BGP on R3.

R3(config-router)#bgp inject-map INJECT_MAP exist-map EXIST_MAP1
After a soft clear, you should now see on R6 a route injection as follows.
Maximum Prefix
Filtering based on maximum-prefix number is an important BGP security feature. The number of BGP
prefixes on the Internet is many hundreds of thousands. It is possible to overwhelm a BGP speaker’s
table by injecting too many prefixes and putting too much stress on the router’s CPU or memory.
We can see this action in very small numbers with R2. R2 has loopbacks 10,11,12 and 13. Advertise
these loopbacks into BGP AS 20. Remember R2 has loopback 0 as well.
Let us limit the number of advertise routes from R2 to be a maximum of 4 with a warning if it goes
over 3 and a restart of the peering if it goes over 4 for 1 minute.
R3(config-router)#neighbor 150.23.1.2 maximum-prefix 4 ?rou
<1-100> Threshold value (%) at which to generate a warning msg
restart Restart bgp connection after limit is exceeded
warning-only Only give warning message when limit is exceeded
<cr>
R3(config-router)#neighbor 150.23.1.2 maximum-prefix 4 75 restart 1
Slowing start adding the loopbacks on R2 to see this feature in action. When reaching 4 routes the
following message should appear
%BGP-4-MAXPFX: Number of prefixes received from 150.23.1.2 (afi 0) reaches 4, max 4
And if you add one more the peer should be reset for a minute. In that time you would need to
remove one loopback else it would reset again.

Lab 1 - BGP Peering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lab 1 - BGP Peering

Uploaded by

Copyright:

Available Formats

Lab 1 - BGP Peering

Table for IP addresses

Device Interface IP address Device Interface IP address

R1 Loopback0 120.1.1.1/32 R4 Loopback0 120.1.4.1/32

R2 Loopback0 120.2.1.1/32 R5 Loopback0 120.1.5.1/32

How to view interface ip address setup: Show ip interface brief

Task 1 – Create an iBGP peering

R3(config)#router bgp 100

R4(config)#router bgp 100

Give ‘Show ip bgp summary’ to see neighbor relationships formed.

First, we look at the routing table for R1

R1(config)#router bgp 100

R3(config)#router bgp 100

R1(config)#router bgp 100

R3(config)#router bgp 100

Task 3 – eBGP Peering

R5(config)#router bgp 200

And on R4, we are doing add 150.1.45.0/24 to AS 100.

R5(config)#router bgp 200

R5(config-router)#network 120.1.5.1 mask ?

R5(config-router)#network 120.1.5.1 mask 255.255.255.255

This should now observe an installation of a new BGP entry in R4.

Task 4 - eBGP Multihop

R5(config-router)#router bgp 200

R1(config-router)#router bgp 100

Task 5 - Update Source

R1(config)#router bgp 100

R2(config)#router bgp 100

PART A – BGP Route Reflectors

RR G0/1 150.10.1.2/24 R3 G0/0 150.30.1.1/24

R1(config)#router bgp 100

R2(config)#router bgp 100

R3(config)#router bgp 100

R4(config)#router bgp 100

RR(config)#router bgp 100

RR(config)#router bgp 100

%BGP-5-ADJCHANGE: neighbor 150.30.1.1 Down RR client config change

RR(config-router)#neighbor 150.40.1.1 route-reflector-client

%BGP-5-ADJCHANGE: neighbor 150.40.1.1 Down RR client config change

RR#sh ip bgp 120.3.1.1 255.255.255.255

RR(config)#router bgp 100

R5(config)#router bgp 200

R6(config)#router bgp 300

Device Interface IP address Device Interface IP address

R1 G0/0 150.15.1.1/24 R4 G0/3 150.34.1.4/24

R2(config)#router bgp 100

R3(config)#router bgp 100

Let us start with R1 –

R1(config)#router bgp 21 // router AS is set to sub-AS

Similarly we configure R2 as part of the same confederation.

Let us now configure R4.

neighbor 150.15.1.5 remote-as 200

router bgp 100

router bgp 100

router bgp 100

router bgp 200

R1 G0/0 150.14.1.1/24 R4 G0/0 150.14.1.4/24

R4#clear ip bgp * soft

R4(config)#access-list 1 permit 1.1.1.1 /32

Apply that to the route map and set the weight.

R4#clear ip bgp * soft

This would bring the adjacency to R3 up.

R5(config)# access-list 1 permit 1.1.1.1 /32