Introduction

This Blog Covers the basic tutorial and configuration of BGP protocol.

The Border Gateway Protocol is the routing protocol which actually powers the internet. It makes the routing possible between different Autonomous systems.

Topology Used

We will going to use below Topology to start with. We will enhance the below topology as per the configuration scenario or concepts to be demonstrated.

Software Used : GNS3

Devices : All routers are Cisco C7200 Routers. These are dynamips devices, so you can setup this lab on M-series Apple Laptops.

Configuration : Each C7200 Device need 512MB of RAM.

Scope of this Blog

This blog covers only the configuration and Message details to implement and demonstrate BGP concepts.

BGP Neighborship

eBGP and iBGP

Route Distribution

Underlying IGP

Route-Reflector

Self-Next-Hop

BGP Path Attributes

BGP Path Attribute - Weight

BGP Path Attribute - Local Preference

BGP Path Attribute - AS Path length

BGP Path Attribute - AS Path Prepend

We Configured Local preference on R3 for incoming route 66.0.0.0/8 to 200. So, R3 becomes the exit point to subnet 66.0.0.0/8 within AS1. But this makes routing paths asymmetric. ICMP echo request issued from R1 to 66.0.0.1 takes the path R1 —> R2 —> R3 —> R7 —> R5 —> R6 (shown in RED Arrows). Whereas , returned ICMP reply from R6 to R1 takes the path R6 —> R5 —> R2 —> R1 (shown in BLUE Arrows).

R1#traceroute 66.0.0.1 source 11.0.0.1

Type escape sequence to abort.

Tracing the route to 66.0.0.1

VRF info: (vrf in name/id, vrf out name/id)

  1 1.2.0.2 16 msec 20 msec 16 msec

  2 2.3.0.2 40 msec 28 msec 20 msec

  3 3.7.0.2 40 msec 40 msec 40 msec

  4 5.7.0.1 52 msec 48 msec 52 msec

  5 5.6.0.2 60 msec 72 msec 60 msec

R6#traceroute 11.0.0.1 source 66.0.0.1

Type escape sequence to abort.

Tracing the route to 11.0.0.1

VRF info: (vrf in name/id, vrf out name/id)

  1 5.6.0.1 16 msec 12 msec 16 msec

  2 5.7.0.2 20 msec 16 msec 20 msec

  3 3.7.0.1 32 msec 36 msec 32 msec

  4 2.3.0.1 40 msec 40 msec 40 msec

  5 1.2.0.1 60 msec 60 msec 60 msec

Type error fix in above image , it is 66.0.0.1 instead of 16.0.0.1 .

In order to control the incoming traffic, we will use AS path prepend attribute on R2. We want inbound traffic destined to 11.0.0.0./8 and entering into AS1 via speaker node R2 must enter into AS1 via speaker node R3. It means, R3 must be preferred over R2 as the route advertiser of 11.0.0.0/8 by remote ASs. To achieve this, we let R2 advertise the bgp route 11.0.0.0/8 with lengtheir AS-path by preprending self AS 1 in route advertisement.

R2(config)#access-list 22 permit 11.0.0.0 0.255.255.255

R2(config)#route-map as-prep permit 1

R2(config-route-map)#match ip address 22

R2(config-route-map)#set as-path prepend 1 1

R2(config)#neighbor 5.5.5.5 route-map as-prep out

With above AS-PATH prepend config in place, Remote AS prefer R3 over R2 as preferred nexthop for destination 11.0.0.0/8. Therefore, return traffic from R6 to R1 now take path R6 —> R5 —> R7 —> R3 —> R2 —> R1. In other words, Routing paths between subnets 11.0.0.0/8 and 66.0.0.0/8 is now symmetric. AS-Path prepend attribute is mandatory (since AS-path is always advertised) and transitive.

Route 11.0.0.0/8 status on R5.

R5#show ip bgp 11.0.0.0/8

BGP routing table entry for 11.0.0.0/8, version 5

Paths: (2 available, best #1, table default)

  Advertised to update-groups:

     1          2         

  Refresh Epoch 1

  3 1

    7.7.7.7 (metric 20) from 7.7.7.7 (7.7.7.7). <<< this nexthop is preferred over 2.2.2.2 because of less number of hops in AS-path length which is just 3,1 as opposed to 1,1,1 .

      Origin IGP, localpref 100, valid, external, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 2

  1 1 1

    2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)

      Origin IGP, localpref 100, valid, external

      rx pathid: 0, tx pathid: 0

Traceroute output on R6 destined to 11.0.0.01

R6#traceroute 11.0.0.1 source 66.0.0.1

Type escape sequence to abort.

Tracing the route to 11.0.0.1

VRF info: (vrf in name/id, vrf out name/id)

  1 5.6.0.1 16 msec 12 msec 16 msec

  2 5.7.0.2 20 msec 16 msec 20 msec

  3 3.7.0.1 32 msec 36 msec 32 msec

  4 2.3.0.1 40 msec 40 msec 40 msec

  5 1.2.0.1 60 msec 60 msec 60 msec

BGP Path Attribute - MED ( Multi Exit Discriminator )

MED is another optional non-transitive bgp path attribute which participates in route selection process by BGP. We achieve symmetric routing between subnets 11.0.0.0/8 and 66.0.0.0/8 using bgp as-path prepend path attribute in the previous section. We will now achieve the same using MED. Note that, Cisco calls MED simply as Metric. Higher the MED value, the less preferred the route is by bgp. Note that, MED is interpreted only by EBGPs.

Also, in the previous section, We Configured Local preference on R3 for incoming route 66.0.0.0/8 to 200. So, R3 becomes the exit point to subnet 66.0.0.0/8 with in AS1. ICMP echo request issued from R1 to 66.0.0.1 takes the path R1 —> R2 —> R3 —> R7 —> R5 —> R6 (shown in RED Arrows). Let this config continue to exist.

So, let R2 advertise the route 11.0.0.0/8 with MED value 100 ( default is 0 ) to neighbour 5.5.5.5 . Let us remove the as-path prepend config for this route which we did in the previous section.

R2(config)#route-map as-prep 1

R2(config-route-map)#no set as-path prepend 1 1

R2(config-route-map)#set metric 100

R2#clear ip bgp 5.5.5.5 soft

Checking the status of route 11.0.0.0/8 on R5 after the above config

R5#show ip bgp 11.0.0.0

BGP routing table entry for 11.0.0.0/8, version 25

Paths: (2 available, best #2, table default)

Advertised to update-groups:

1 2

Refresh Epoch 3

3 1

7.7.7.7 (metric 20) from 7.7.7.7 (7.7.7.7)

Origin IGP, localpref 100, valid, external

rx pathid: 0, tx pathid: 0

Refresh Epoch 5

1

2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 100, localpref 100, valid, external, best

rx pathid: 0, tx pathid: 0x0

The best path selection for route 11.0.0.0/8 is still via 2.2.22 despite the fact that 2.2.2.2 advertised the route with a higher metric. There are two reasons for this :

1. eBGP neighbours, by default, ignore the MED values of the route. So, here, R5 is not even considering MED value of 100 for the route 11.0.0.0/8 as advertised by R2.

2. Router R5 is receiving the route 11.0.0.0/8 with an AS-path length of 1 from R2, hence, nexthop 2.2.2.2 is the preferred nexthop.

We want R5 to choose 7.7.7.7 ( R7 ) as a preferred next-hop for route 11.0.0.0/8. So, we need to disable on R5 the ability to select routes based on AS-path length. On top of that, R5 must consider MED as an attribute for path selection despite being eBGP neighbour of R2. We can achieve this using the below config on R5 :

R5(config)#router bgp 2

R5(config-router)#bgp bestpath as-path ignore

R5(config-router)#bgp always-compare-med

R2#clear ip bgp * soft

Note that the above configuration is with in AS level, so they take effect for all bgp neighbours.

Checking the status of route 11.0.0.0/8 on R5 after above config

R5#show ip bgp 11.0.0.0

BGP routing table entry for 11.0.0.0/8, version 33

Paths: (2 available, best #1, table default)

Advertised to update-groups:

1 2

Refresh Epoch 4

3 1

7.7.7.7 (metric 20) from 7.7.7.7 (7.7.7.7)

Origin IGP, localpref 100, valid, external, best. <<< preferred path

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 6

1

2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 100, localpref 100, valid, external

rx pathid: 0, tx pathid: 0

You can see, that 7.7.7.7 is now the preferred nexthop for route 11.0.0.0/8 on R5. Now the paths between subnets 11.0.0.0/8 and 66.0.0.0/8 are symmetric once again.

But the disadvantage of this method of establishing the symmetric BGP paths is that one needs to modify the BGP path selection criteria on remote AS also, unlike the previous case where admin only has to reconfigure local AS ( R2 ) only using as-path prepend config.

Route Summarization

Route summarization is the process in which the BGP protocol aggregates/summarizes the advertised individual routes and advertises one subnet on its behalf. For example, if BGP on R6 advertises routes 6.6.1.0/24, 6.6.2.0/24, 6.6.3.0/34, 6.6.4.0/24, and 6.6.5.0/24, the BGP can choose to promote one single route, 6.6.0.0/22, on behalf of these five routes. Here, 6.6.0.0/22 is called an aggregated or summarized route.

Route summarisation helps with fewer updates, reducing update size, and reducing the size of the BGP routing table to be maintained.

Local Route Summarisation

Local Route Summarization is done by the router which is originating the routes into BGP domain.

Let us begin with advertising some more routes into BGP on router R6.

R6(config)#interface loopback 2

R6(config-if)#no shut

R6(config-if)#ip address 6.6.2.1 255.255.255.0

R6(config)#interface loopback 3

R6(config-if)#no shut

R6(config-if)#ip address 6.6.3.1 255.255.255.0

R6(config)#interface loopback 4

R6(config-if)#no shut

R6(config-if)#ip address 6.6.4.1 255.255.255.0

R6(config)#interface loopback 5

R6(config-if)#no shut

R6(config-if)#ip address 6.6.5.1 255.255.255.0

Now, let us redistribute the routes configured on interfaces lo-2 to lo-5 into bgp. For that we need a route-map.

R6(config)#access-list 60 permit 6.6.0.0 0.0.255.255

R6(config)#route-map lo-advt

R6(config-route-map)#match ip address lo-advt

Now, Configure redistribution into BGP.

R6(config)#router bgp 2

R6(config-router)#redistribute connected route-map lo-advt

R6#clear ip bgp * soft

Verify, that routes are advertised into BGP.

R6#show ip bgp

BGP table version is 15, local router ID is 6.6.6.6

....

Network Next Hop Metric LocPrf Weight Path

*> 5.6.0.0/24 0.0.0.0 0 32768 ?

*> 6.6.2.0/24 0.0.0.0 0 32768 ? << Redistributed route

*> 6.6.3.0/24 0.0.0.0 0 32768 ? << Redistributed route

*> 6.6.4.0/24 0.0.0.0 0 32768 ? << Redistributed route

*> 6.6.5.0/24 0.0.0.0 0 32768 ? << Redistributed route

*> 6.6.6.6/32 0.0.0.0 0 32768 ?

*>i 11.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 22.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 33.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 44.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 55.0.0.0 5.5.5.5 0 100 0 i

*> 66.0.0.0 0.0.0.0 0 32768 i

*>i 77.0.0.0 7.7.7.7 0 100 0 3 i

*>i 88.0.0.0 7.7.7.7 0 100 0 3 i

Routes 6.6.X.0/24 are successfully redistributed across AS1, AS2 and AS3. On R1, when these routes are viewed in bgp routing table, they are shown as external routes ( lines ending with ? )

R1#show ip bgp

BGP table version is 42, local router ID is 1.1.1.1

. . .

Network Next Hop Metric LocPrf Weight Path

*>i 5.6.0.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.2.0/24 5.5.5.5 0 100 0 2 ? << Redistributed route, Not originated in bgp

*>i 6.6.3.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.4.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.5.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.6.6/32 5.5.5.5 0 100 0 2 ?

*> 11.0.0.0 0.0.0.0 0 32768 i

Now, Let us summarize these routes.

R6(config)#router bgp 2

R6(config-router)#aggregate-address 6.6.0.0 255.255.248.0

R6#clear ip bgp * soft

Great, now check BGP routing table.

R6#show ip bgp

BGP table version is 16, local router ID is 6.6.6.6

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

*> 5.6.0.0/24 0.0.0.0 0 32768 ?

*> 6.6.0.0/21 0.0.0.0 32768 i <<< Summarised route.

*> 6.6.2.0/24 0.0.0.0 0 32768 ?

*> 6.6.3.0/24 0.0.0.0 0 32768 ?

*> 6.6.4.0/24 0.0.0.0 0 32768 ?

*> 6.6.5.0/24 0.0.0.0 0 32768 ?

*> 6.6.6.6/32 0.0.0.0 0 32768 ?

*>i 11.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 22.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 33.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 44.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 55.0.0.0 5.5.5.5 0 100 0 i

*> 66.0.0.0 0.0.0.0 0 32768 i

*>i 77.0.0.0 7.7.7.7 0 100 0 3 i

*>i 88.0.0.0 7.7.7.7 0 100 0 3 i

We can see, along with redistributed individual routes, summarized routes is also being advertised now. Note that summarized routes is advertised as internal bgp route (lines ending with i ) as against individual prefixes which are advertised as redistributed routes ( lines ending with ? )

If we don’t want to advertise the individual routes, then reconfigure as below :

R6(config)#router bgp 2

R6(config-router)#aggregate-address 6.6.0.0 255.255.248.0 summary-only

R6#clear ip bgp * soft

R6#show ip bgp

. . .

Network Next Hop Metric LocPrf Weight Path

*> 5.6.0.0/24 0.0.0.0 0 32768 ?

*> 6.6.0.0/21 0.0.0.0 32768 i << Summarized Route

s> 6.6.2.0/24 0.0.0.0 0 32768 ? << Suppressed Route

s> 6.6.3.0/24 0.0.0.0 0 32768 ? << Suppressed Route

s> 6.6.4.0/24 0.0.0.0 0 32768 ? << Suppressed Route

s> 6.6.5.0/24 0.0.0.0 0 32768 ? << Suppressed Route

s> 6.6.6.6/32 0.0.0.0 0 32768 ? << Suppressed Route

*>i 11.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 22.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 33.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 44.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 55.0.0.0 5.5.5.5 0 100 0 i

*> 66.0.0.0 0.0.0.0 0 32768 i

*>i 77.0.0.0 7.7.7.7 0 100 0 3 i

*>i 88.0.0.0 7.7.7.7 0 100 0 3 i

The Summarized route then propagates as usual across AS using usual BGP path selection algorithm as shown in the diagram below.

Remote Route Summarisation

A BGP router in one AS could summarise the routes advertised by a BGP router in another AS altogether. This is called Remote route summarisation. When a BGP router summarizes the remotely learnt routes, it tends to destroy the AS path list from the routes. Here, we continue with the previous configuration.

Let us undo aggregate-address configuration on R6, so that it advertises individual prefixes again without any summarisation.

show ip bgp output after removing the said configuration on R6.

R6#show ip bgp

. . .

Network Next Hop Metric LocPrf Weight Path

*> 5.6.0.0/24 0.0.0.0 0 32768 ?

*> 6.6.2.0/24 0.0.0.0 0 32768 ?

*> 6.6.3.0/24 0.0.0.0 0 32768 ?

*> 6.6.4.0/24 0.0.0.0 0 32768 ?

*> 6.6.5.0/24 0.0.0.0 0 32768 ?

*> 6.6.6.6/32 0.0.0.0 0 32768 ?

*>i 11.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 22.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 33.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 44.0.0.0 7.7.7.7 0 100 0 3 1 i

*>i 55.0.0.0 5.5.5.5 0 100 0 i

*> 66.0.0.0 0.0.0.0 0 32768 i

*>i 77.0.0.0 7.7.7.7 0 100 0 3 i

*>i 88.0.0.0 7.7.7.7 0 100 0 3 i

These routes are received by Router R2 which is in AS1. Current state of bgp routing table on R2 is :

R2#show ip bgp

. . .

Network Next Hop Metric LocPrf Weight Path

*> 5.6.0.0/24 5.5.5.5 0 2 ?

*> 6.6.2.0/24 5.5.5.5 0 2 ?

*> 6.6.3.0/24 5.5.5.5 0 2 ?

*> 6.6.4.0/24 5.5.5.5 0 2 ?

*> 6.6.5.0/24 5.5.5.5 0 2 ?

*> 6.6.6.6/32 5.5.5.5 0 2 ?

*>i 11.0.0.0 1.1.1.1 0 100 0 i

*> 22.0.0.0 0.0.0.0 0 32768 i

*>i 33.0.0.0 3.3.3.3 0 100 0 i

*>i 44.0.0.0 4.4.4.4 0 100 0 i

*> 55.0.0.0 5.5.5.5 0 0 2 i

*>i 66.0.0.0 7.7.7.7 0 200 0 3 2 i

* 5.5.5.5 0 2 i

*> 77.0.0.0 5.5.5.5 0 2 3 i

*> 88.0.0.0 5.5.5.5 0 2 3 i

Now, let We want to summarize 6.6.xx series routes on R2. On Router R2 we will configure :

R2(config-router)#aggregate-address 6.6.0.0 255.255.248.0 as-set summary-only

as-set option allows Router R2 to advertise the summarize routes while preserving AS-Path information in the advertised routes. If this option is not present, R2 will advertise summarizes routes without AS-Path information ( as if R2 is the originator of the routes )

You can see in the diagram below, the individual routes advertised by R6 (in pink star) are learnt by R2 by BGP path selection process. R2 Summarize them (Black Star) and advertise only the summarized route while not propagating the individual routes because we used the summary-only option in the configuration above.

Checking the output on R1 :

R1#show ip bgp

. . .

*>i 5.6.0.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.0.0/21 2.2.2.2 0 100 0 2 ? <<< Summarized route, containing original AS-PATH info as well.

*> 11.0.0.0 0.0.0.0 0 32768 i

*>i 22.0.0.0 2.2.2.2 0 100 0 i

*>i 33.0.0.0 3.3.3.3 0 100 0 i

*>i 44.0.0.0 4.4.4.4 0 100 0 i

*>i 55.0.0.0 5.5.5.5 0 100 0 2 i

*>i 66.0.0.0 7.7.7.7 0 200 0 3 2 i

*>i 77.0.0.0 5.5.5.5 0 100 0 2 3 i

*>i 88.0.0.0 5.5.5.5 0 100 0 2 3 i

*> 99.0.0.0 8.8.8.8 0 0 4 i

Checking the same summarized route on R8 :

R8#show ip bgp

. . .

*> 5.6.0.0/24 1.1.1.1 0 1 2 ?

*> 6.6.0.0/21 1.1.1.1 0 1 2 ? <<< AS-PATH info is updated as usual.

*> 11.0.0.0 1.1.1.1 0 0 1 i

*> 22.0.0.0 1.1.1.1 0 1 i

*> 33.0.0.0 1.1.1.1 0 1 i

*> 44.0.0.0 1.1.1.1 0 1 i

*> 55.0.0.0 1.1.1.1 0 1 2 i

*> 66.0.0.0 1.1.1.1 0 1 3 2 i

*> 77.0.0.0 1.1.1.1 0 1 2 3 i

*> 88.0.0.0 1.1.1.1 0 1 2 3 i

*> 99.0.0.0 0.0.0.0 0 32768 i

On R8, you can try ping R6’s 6.6.2.1 address which falls in the range of summarized route using ping 6.6.2.1 source 99.0.0.1 ( Src and Dst must be BGP advertised routes )

R8#ping 6.6.2.1 source 99.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 6.6.2.1, timeout is 2 seconds:

Packet sent with a source address of 99.0.0.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 56/63/76 ms

Selective Route Advertisement

Route Oscillation

Route Oscillation is one of the anomalies that BGP suffers while calculating the best routes received from Neighbours. This anomaly leads to BGP neighbors to get into an infinite loop of exchanging the route with each other, because each nbr thinks he has the best version of the routes.
Consider the diagram below. Consider some Route R is distributed by R6 with default parameters. R3 recvs this route from R2 with AS-path as 1, 2 (Blue Arrows) whereas R7 recvs the same route from R5 with AS-path list as 2,3 (Green Arrows).

Since, R3 and R7 are ebg nbrs, they will exchange the route R with each other. Problem here is , when R3 recvs the route R from R7 then Route’s R AS-path as recvd by R3 from R7 would be 1,3,7 which is longer path as compared to AS-path list which R3 already has (1, 2) when it had recvd the route from R2.

Same is true for when R7 recvs the route R from R3 then Route’s R AS-path as recvd by R7 from R3 would be 3,1,2 which is longer path as compared to AS-path list which R7 already has (3, 2) when it had recvd the route from R5.

Thus, R3 and R7 thinks it has a better version of the route R, and therefore choose to advertise to other ebg neighbor. This Repeats for forever (Red Arrows) and we call it as Route Oscillating between ebgp peers. This problem is mitigated by a process called Route Dampening.

BGP Communities

BGP achieves route tagging using BGP communities. BGP communities are non-transitive optional attributes by default. Any BGP router can mark a set of routes in incoming and outgoing routing updates or when doing redistribution with the BGP community tag. BGP communities play a role in influencing the BGP path selection algorithm or BGP filtering. By default, BGP communities are stripped in outgoing BGP updates.

BGP Community Types

Well-Known Community types - Predefined, well-known with a defined behaviour.

Own-Communities - User Defined

Well-known Community Types

There are four well-known community types as listed below :

Own-Community types

• 32-bit integer

• new format : [AS number (16 bits) : tag value (16bits) ]

• old format: just a plane 32-bit non-negative integer

• A BGP route can be tagged with multiple community values.

LAB: Configuring Well-Known Communities

In this lab we will demonstrate the Well Community - no-export and no-advertise.

No-Advertise Community

Use Case : In certain scenario, We want the routes to not propagate any further in bgp domain. Using the no-advertise community tag offers granular control over route propagation, enhancing security, compliance, and network stability, especially in complex, multi-tiered, or compliance-driven network environments.

Continue to use our topology, once again shown below :

Router R8 advertises its LAN network 99.0.0.0/8 to Router R1 which in turn advertises it all the way to R6 and R7 which are in AS 2 and 3 respectively. We want to restrict the distribution span of this network only to Router R1. That means, Router R1 once recvs the route 99.0.0.0/8 from R8, would not advertise it any further to any of its bgp peer.

There are two ways to apply the community here :

1. Either R8 advertise the route 99.0.0.0.0/8 with the community tag no-advertise to nbr R1.

2. R8 advertises the route 99.0.0.0.0/8 as normal but R1 when recvs it apply the community no-advertise on it.

Depending on the use-case or network manageability, any one of the above methods can be used.

Let’s discuss case 1 first where R8 advertise the route 99.0.0.0.0/8 with a community tag no-advertise to nbr R1.

R8(config)#access-list 80 permit 99.0.0.0 0.255.255.255

R8(config)#route-map advt-99-0-0-0-with-community permit 1

R8(config-route-map)#match ip address 80

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

R8(config-router)#neighbor 1.1.1.1 route-map advt-99-0-0-0-with-community out

R8(config-router)#neighbor 1.1.1.1 send-community

R8#clear ip bgp * soft

The result of the above config is: R1 would not advertise the network 99.0.0.0/8 any further.

R8#show ip bgp 99.0.0.0/8

BGP routing table entry for 99.0.0.0/8, version 2

Paths: (1 available, best #1, table default)

Advertised to update-groups:

3

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (8.8.8.8)

Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best

rx pathid: 0, tx pathid: 0x0

R2#show ip bgp 99.0.0.0/8

% Network not in table

Now, let us try case 2, where R8 advertise the route 99.0.0.0.0/8 as normal but R1 when received apply the community no-advertise on it. I have undone the config we did on R8 for case 1.

This time we need to configure R1 only.

R1(config)#access-list 11 permit 99.0.0.0 0.255.255.255

R1(config)#route-map rt-9-0-0-0-0-apply-no-adv-community permit 1

R1(config-route-map)#match ip address 11

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

R1(config-router)#neighbor 8.8.8.8 route-map rt-9-0-0-0-0-apply-no-adv-community in

R1#clear ip bgp * soft

The overall result is the same, Router R1 having recvd the route 99.0.0.0/8 from R8 without any community, applies the community tag no-advertise on it, and then process the route as per the bgp processing path selection algorithm, respecting the community and not advertising the route any further.

R2#show ip bgp 99.0.0.0/8

% Network not in table

I have undone this config for the next section.

No-Export Community

To start with the problem statement, we want route 99.0.0.0/8 should not leak out of AS 1. It must be confined to within AS 1 boundaries. We can see, BGO router R2 and R3 are the ones that have ebgp neighbours and can advertise 99.0.0.0/8 out of local AS. In fact currently, they do.

R2#show ip bgp neighbors 5.5.5.5 advertised-routes | inc 99.0.0.0

*>i 99.0.0.0 8.8.8.8 0 100 0 4 I

R3#show ip bgp neighbors 7.7.7.7 advertised-routes | include 99.0.0.0

*>i 99.0.0.0 8.8.8.8 0 100 0 4 i

Using no-export community we can restrict route 99.0.0.0/8 from being advertised outside of AS1.

Since R1 is the one that introduces the route 99.0.0.0/8 into AS 1, let us configure to advertise the route to its nbr R2 with no-export community. (An alternate method would be to configure Router R2 to stamp the incoming route 99.0.0.0/8 from R1 with no-export community tag ).

R1(config)#access-list 11 permit 99.0.0.0 0.255.255.255

R1(config)#route-map advt-99-0-0-0-no-export permit 1

R1(config-route-map)#match ip address 11

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

R1(config-router)#neighbor 2.2.2.2 route-map advt-99-0-0-0-no-export out

R1(config-router)#neighbor 2.2.2.2 send-community

R1#clear ip bgp 2.2.2.2 soft

The effect of this configuration is that, R2 no not advertise the route 99.0.0.0/8 to ebgp nbr 5.5.5.5 but continues to advertise the route to igp nbr R3. As we know, community-tags are non-transitive by default, therefore, R3 recvs the route from R2 without any community tag. Hence, it still advertises the route to ebgp nbr R7. Therefore, we need to prevent R3 from advertising the route 99.0.0.0/8 to its ebgp nbr(s). We can simply achieve this by configuring R2 to send community value along with the route to R3.

R2(config-router)#neighbor 3.3.3.3 send-community

Now, checking if R3 is advertising the route to its nbr R7.

R3#show ip bgp neighbors 7.7.7.7 advertised-routes | include 99.0.0.0

R3#

The above configuration will affect all routes being advertised by R2 to R3. To limit the effect only to said route, instead of configuring on R2 we can configure in-dirn route-map on R3 instead. Let us try that after undoing the above configuration.

R3(config)#access-list 34 permit 99.0.0.0 0.255.255.255

R3(config)#route-map recv-99-0-0-0-no-export permit 1

R3(config-route-map)#match ip address 34

R3(config-route-map)#set community no-export

R3(config-router)#neighbor 2.2.2.2 route-map recv-99-0-0-0-no-export in

R3#clear ip bgp 2.2.2.2 soft

Thats it, let us verify again.

R3#show ip bgp neighbors 7.7.7.7 advertised-routes | include 99.0.0.0

<no output>

R3#show ip bgp

. . .

*> 33.0.0.0 0.0.0.0 0 32768 i

*> 66.0.0.0 7.7.7.7 200 0 3 2 i

*>i 99.0.0.0 8.8.8.8 0 100 0 4 i << R3 is receiving the route from R2 but not advertising it to R7.

R4 continues to recv route 99.0.0.0/8 implying distribution of the route within AS1 is not impacted.

R4#show ip bgp | include 99.0.0.0

*>i 99.0.0.0 8.8.8.8 0 100 0 4 i

Community-List

Community list is a configuration construct, very similar to access-list. Though access-list in most cases are used to select/filter routes based on a prefix value, ip community list do the same but based on community value tagged with the route.

For example :

ip community-list 10 permit/deny 2:10

Above is a community list which will permit/deny all prefixes which are tagged with community value 2:10. We can then use this ip community-list in route-maps, just like we use access-list in route-maps.

LAB on Community List

We are already advertising the below routes from router R6 :

R6#show ip bgp

. . .

*> 6.6.2.0/24 0.0.0.0 0 32768 ?

*> 6.6.3.0/24 0.0.0.0 0 32768 ?

*> 6.6.4.0/24 0.0.0.0 0 32768 ?

*> 6.6.5.0/24 0.0.0.0 0 32768 ?

. . .

Pls remove any route summarization configuration from R2 from prev lab.

Our Goal is to make :

R2 the exit point in AS 1 for traffic destined to route 6.6.2.0/24 and 6.6.3.0/24

R3 the exit point in AS 1 for traffic destined to route 6.6.4.0/24 and 6.6.5.0/24

Currently, for all these routes, exit point is R2 only.

R2#show ip bgp

. . .

*> 6.6.2.0/24 5.5.5.5 0 2 ?

*> 6.6.3.0/24 5.5.5.5 0 2 ?

*> 6.6.4.0/24 5.5.5.5 0 2 ?

*> 6.6.5.0/24 5.5.5.5 0 2 ?

. . .

R2#show ip route | inc 5.5.5.5/32

O E2 5.5.5.5/32 [110/20] via 2.5.0.2, 00:38:03, FastEthernet4/0

R3#show ip bgp

. . .

*>i 6.6.2.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.3.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.4.0/24 5.5.5.5 0 100 0 2 ?

*>i 6.6.5.0/24 5.5.5.5 0 100 0 2 ?

. . .

R3#show ip route | inc 5.5.5.5/32

O E2 5.5.5.5/32 [110/20] via 2.3.0.1, 00:37:24, FastEthernet1/0

Below Diagram shows the exit point for traffic destined to the above routes from AS1. The traffic flow is shown in blue arrows.

The below diagram shows the desired traffic flow we want to achieve. We will use a community list to achieve this. Using the community list we enforce bgp path selection policies on a route based on the community tag rather than default, prefix value.

To start with, First R6 need to advertise these routes with community tags as below :

6.6.2.0/24 & 6.6.3.0/34 — Community tag 2:10

6.6.4.0/24 & 6.6.5.0/34 — Community tag 2:20

Configure the access list to group the routes into two parts.

R6(config)#access-list 61 permit 6.6.2.0 0.0.0.255

R6(config)#access-list 61 permit 6.6.3.0 0.0.0.255

R6(config)#access-list 62 permit 6.6.4.0 0.0.0.255

R6(config)#access-list 62 permit 6.6.5.0 0.0.0.255

Configure Route-map to stamp the routes with community tags.

R6(config)#route-map apply-comm-10 permit 1

R6(config-route-map)#match ip address 61

R6(config-route-map)#set community 2:10

R6(config)#route-map apply-comm-10 permit 2

R6(config-route-map)#match ip address 62

R6(config-route-map)#set community 2:20

R6(config)#route-map apply-comm-10 permit 3

R6(config-router)#neighbor 5.5.5.5 route-map apply-comm-10 out

R6(config-router)#neighbor 5.5.5.5 send-community

R6#clear ip bgp * soft

Verify on Router R5 that the routes are successfully tagged with the community values.

R5#show ip bgp 6.6.2.0/24

BGP routing table entry for 6.6.2.0/24, version 22

Paths: (1 available, best #1, table default)

Advertised to update-groups:

1

Refresh Epoch 2

Local

6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Community: 2:10 <<<

rx pathid: 0, tx pathid: 0x0

R5#show ip bgp 6.6.3.0/24

BGP routing table entry for 6.6.3.0/24, version 23

Paths: (1 available, best #1, table default)

Advertised to update-groups:

1

Refresh Epoch 2

Local

6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Community: 2:10 <<<

rx pathid: 0, tx pathid: 0x0

R5#show ip bgp 6.6.4.0/24

BGP routing table entry for 6.6.4.0/24, version 20

Paths: (1 available, best #1, table default)

Advertised to update-groups:

1

Refresh Epoch 2

Local

6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Community: 2:20 <<<

rx pathid: 0, tx pathid: 0x0

R5#show ip bgp 6.6.5.0/24

BGP routing table entry for 6.6.5.0/24, version 21

Paths: (1 available, best #1, table default)

Advertised to update-groups:

1

Refresh Epoch 2

Local

6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Community: 2:20 <<<

rx pathid: 0, tx pathid: 0x0

Since, Community values are non-transitive, R5 will not propagate community values to its nbrs. Therefore send-community needs to be configured on R5. So, is required on R7 also.

R5(config-router)#neighbor 2.2.2.2 send-community

R5(config-router)#neighbor 7.7.7.7 send-community

R5#clear ip bgp * soft

R7(config-router)#neighbor 3.3.3.3 send-community

R7#clear ip bgp * soft

Hence, we should able to advertise routes with desired community values on R6 and able to propagate these routes with community values to border routers of AS1 ( R2 and R3 ). Lets check the status of routes on R2 and R3.

In the above output, R2 is receiving the routes from R5 with the community values, but R3 routes still have no community values. The reason here is that, the best routes recvd by R3 is via R2 rather than R7 as per AS-path list attribute. Hence, R2 while advertising the routes to R3 chopped of community values. To overcome this, we need to configure send-community on R2 one more time towards nbr 3.3.3.3.

R2(config-router)#neighbor 3.3.3.3 send-community

R2#clear ip bgp 3.3.3.3 soft

Once again checking the routes status on R2 and R3 now.

Now, these routes are received by R2 and R3 which are in AS1. R2 must set local preference to 200 for route 6.6.2.0/24 and 6.6.3.0/24 in order to be chosen as the exit point only for these routes. R3 must set local preference to 200 for routes 6.6.4.0/24 and 6.6.5.0/24 in order to be chosen as the exit point only for these routes.

now we will configure ip community list on R2 and R3 to achieve the above requirement.

R2(config)#ip community-list 20 permit 2:10

R2(config)#route-map community-list-set-local-pref permit 1

R2(config-route-map)#match community 20

R2(config-route-map)#set local-preference 200

R2(config)#route-map community-list-set-local-pref permit 2

R3(config)#ip community-list 30 permit 2:20

R3(config)#route-map community-list-set-local-pref permit 1

R3(config-route-map)#match community 30

R3(config-route-map)#set local-preference 200

R3(config)#route-map community-list-set-local-pref permit 2