Hello,
Today I want to share with you one of the posts from my website http://laguiadelnetworking.com regarding Communities ( An introduction and a lab scenario).
Hope you like it
We are going to be talking in several posts about some of the most useful features that BGP provide us to manipulate the routing table of the devices and today it's time to talk about the BGP communities.
I think of the BGP communities as an equivalent of a route-tag but way more powerful (On Steroids).
I mean we could use it just as a flag to be added to a prefix in order to be identified on all of the devices BUT note the key difference is there are some well known communities that will do something more powerful than what a simple tag does.
The BGP attribute value is a 32-bit value that can be split into 2 portions where the first 2 bytes represent the AS number and the last 2 bytes represent something defined by the user.
Now you can represent the community into 3 different formats:
- Decimal (123456)
- Hex (Ox13ab)
- AA:NN
We mentioned that there are some BGP communities that by default will do something unique, these are defined on RFC 1997 and they are:
A) NO-EXPORT:This community it's used on a BGP topology when you do not want to export certain prefixes to an EBGP neighbor.
- Prefixes with this community will get to iBGP neighbors
- Prefixes with this community will not make it to the eBGP neighbors.
B) NO-ADVERTISE:This community it's used when you do not want to advertise "X" prefix to ANY neighbors.
- Prefixes tagged with this community will not make it to both iBGP and eBGP neighbors.
C) NO-ADVERTISE-SUBCONFED:This community it's used when you want to filter prefixes within a confederation (We will talk about BGP confederations on future tutorials).
- Only useful within confederations.
Now that we know about what communities do let's focus on how to apply them.Scenario 1 : The NO-EXPORT Communities:
- We have 1 router in AS 100, 3 routers in AS 200 and 1 router in ASA 300.
- The NO-EXPORT lab goal is that AS 200 cannot be used to route traffic between AS 100 and AS 300 and backwards.
So basically the Autonomous System 200 cannot be used as a transit AS for communication between AS 100-300 and 300-100.Let's make it happen!Notes:A) The following will be the neighbor relationships
- R1-R2
- R2-R3
- R3-R5
- R5-R6
B) Initial IP and BGP configuration has been done.
- R3 is working as a Route Reflector router where R2 and R5 are their clients.
Here is the configuration from R2-R3-R5
R2
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.10.0
network 192.168.20.0
neighbor 192.168.10.1 remote-as 100
neighbor 192.168.20.3 remote-as 200
no auto-summary
R3
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.20.0
network 192.168.30.0
neighbor 192.168.20.2 remote-as 200
neighbor 192.168.20.2 route-reflector-client
neighbor 192.168.30.5 remote-as 200
neighbor 192.168.30.5 route-reflector-client
no auto-summary
R5
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.30.0
network 192.168.40.0
neighbor 192.168.30.3 remote-as 200
neighbor 192.168.40.6 remote-as 300
no auto-summary
With that configuration AS 100 and AS 300 can see each other
R6
R6#sh ip bgp
BGP table version is 11, local router ID is 192.168.40.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/24 192.168.40.5 0 200 100 i
*> 10.10.1.0/24 192.168.40.5 0 200 100 i
*> 10.10.2.0/24 192.168.40.5 0 200 100 i
*> 20.0.0.0/24 0.0.0.0 0 32768 i
*> 20.0.1.0/24 0.0.0.0 0 32768 i
*> 20.0.2.0/24 0.0.0.0 0 32768 i
*> 192.168.10.0 192.168.40.5 0 200 i
*> 192.168.20.0 192.168.40.5 0 200 i
*> 192.168.30.0 192.168.40.5 0 0 200 i
* 192.168.40.0 192.168.40.5 0 0 200 i
*> 0.0.0.0 0 32768 i
R1
R1#sh ip bgp
BGP table version is 15, local router ID is 10.10.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/24 0.0.0.0 0 32768 i
*> 10.10.1.0/24 0.0.0.0 0 32768 i
*> 10.10.2.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0/24 192.168.10.2 0 200 300 i
*> 20.0.1.0/24 192.168.10.2 0 200 300 i
*> 20.0.2.0/24 192.168.10.2 0 200 300 i
*> 192.168.10.0 0.0.0.0 0 32768 i
* 192.168.10.2 0 0 200 i
*> 192.168.20.0 192.168.10.2 0 0 200 i
*> 192.168.30.0 192.168.10.2 0 200 i
*> 192.168.40.0 192.168.10.2 0 200 i
Let's focus in our lab task:
Autonomous System 200 cannot be used as a transit AS for communication between AS 100-300 and 300-100
First of all enable the routers that will use communities to use the community format of XX:XX as the default is to use a decimal value.
R2(config)#ip bgp-community new-format
R3(config)#ip bgp-community new-format
R5(config)#ip bgp-community new-format
Now let's configure the respective border routers (R2 and R5) to flag all the prefixes coming from R1 and R6 respective in such a way that they leave AS 200.
R2
route-map NO_EXPORT
set community no-export
exit
router bgp 200
neighbor 192.168.10.1 route-map NO_EXPORT in
R5
route-map NO_EXPORT
set community no-export
exit
router bgp 200
neighbor 192.168.40.6 route-map NO_EXPORT in
Last but not least we need to configure all of the devices inside AS 200 to propagate those communities to their iBGP neighbors.
R2
router bgp 200
neighbor 192.168.20.3 send-community
R3
router bgp 200
neighbor 192.168.20.2 send-community
neighbor 192.168.30.5 send-community
R5
router bgp 200
neighbor 192.168.30.3 send-community
That should do it!
Let's see what the BGP table of devices on AS 100 and 300 look like:
R1
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
B 192.168.30.0/24 [20/0] via 192.168.10.2, 00:00:36
C 192.168.10.0/24 is directly connected, Ethernet0
B 192.168.40.0/24 [20/0] via 192.168.10.2, 00:00:36
B 192.168.20.0/24 [20/0] via 192.168.10.2, 00:00:36
10.0.0.0/24 is subnetted, 3 subnets
C 10.10.0.0 is directly connected, Loopback0
C 10.10.1.0 is directly connected, Loopback1
C 10.10.2.0 is directly connected, Loopback2
R6
R6#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
B 192.168.30.0/24 [20/0] via 192.168.40.5, 00:04:59
20.0.0.0/24 is subnetted, 3 subnets
C 20.0.0.0 is directly connected, Loopback0
C 20.0.1.0 is directly connected, Loopback1
C 20.0.2.0 is directly connected, Loopback2
B 192.168.10.0/24 [20/0] via 192.168.40.5, 00:04:59
C 192.168.40.0/24 is directly connected, FastEthernet0
B 192.168.20.0/24 [20/0] via 192.168.40.5, 00:04:59
Mission Accomplished!!!
If you want to check the devices in between you can use the command:
show ip bgp x.x.x.x (Where x.x.x.x is a subnet being tagged with the respective community)
R3
R3#sh ip bgp 20.0.0.0
BGP routing table entry for 20.0.0.0/24, version 53
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to update-groups:
1
300, (Received from a RR-client)
192.168.40.6 from 192.168.30.5 (192.168.40.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: no-export
On a future post we will discuss the BGP NO_ADVERTISE community.
Have a good one,
Jcarvaja