You can use community as a flag in order to mark a route. Upstream routers will use these flags to define routing policy. In the schema below, you can image that AS 100 is a customer site and AS 200 is a service provider. We have negotiated with the provider that:
- Traffic destined to routes with a community 100 have to pass by R3
- Traffic destined to routes with a community 200 have to pass by R2
In order to realize this, R1 marks routes with a community field, R2 and R3 modify the local_pref to follow the rules aboves.
In our case:
- Lo1 will be 'marked' with a community 200:100 by R1
- Lo2 will be 'marked' with a community 200:200 by R1
- Route with a community 200:100 will have a local_pref of 1000 (R3).
- Route with a community 200:200 will have a local_pref of 500 (R2).
Configuration
R1:
interface Loopback1
ip address 172.16.1.1 255.255.255.0
!
interface Loopback2
ip address 172.16.2.1 255.255.255.0
!
router bgp 100
bgp log-neighbor-changes
network 172.16.1.0 mask 255.255.255.0
network 172.16.2.0 mask 255.255.255.0
neighbor 10.1.1.2 remote-as 200
neighbor 10.1.1.2 send-community
neighbor 10.1.1.2 route-map Peer-R2 out
neighbor 10.1.2.3 remote-as 200
neighbor 10.1.2.3 send-community
neighbor 10.1.2.3 route-map Peer-R3 out
!
ip access-list standard LO1
permit 172.16.1.0 0.0.0.255
ip access-list standard LO2
permit 172.16.2.0 0.0.0.255
!
route-map Peer-R3 permit 10
match ip address LO2
set community 200:200
route-map Peer-R3 permit 15
match ip address LO1
set community 200:100
!
route-map Peer-R3 permit 20
!
route-map Peer-R2 permit 10
match ip address LO1
set community 200:100
!
route-map Peer-R2 permit 15
match ip address LO2
set community 200:200
!
route-map Peer-R2 permit 20
R2:
router bgp 200
bgp log-neighbor-changes
neighbor 10.1.1.1 remote-as 100
neighbor 10.1.1.1 next-hop-self
neighbor 10.1.1.1 route-map Peer-R1 in
neighbor 20.1.1.3 remote-as 200
neighbor 20.1.1.3 next-hop-self
neighbor 20.1.2.4 remote-as 200
neighbor 20.1.2.4 next-hop-self
!
ip bgp-community new-format
ip community-list 1 permit 200:200
!
route-map Peer-R1 permit 10
match community 1
set local-preference 500
!
route-map Peer-R1 permit 20
R3:
router bgp 200
bgp log-neighbor-changes
neighbor 10.1.2.1 remote-as 100
neighbor 10.1.2.1 route-map Peer-R1 in
neighbor 20.1.1.2 remote-as 200
neighbor 20.1.1.2 next-hop-self
neighbor 20.1.3.4 remote-as 200
neighbor 20.1.3.4 next-hop-self
!
ip forward-protocol nd
!
ip bgp-community new-format
ip community-list 1 permit 200:100
!
route-map Peer-R1 permit 10
match community 1
set local-preference 1000
!
route-map Peer-R1 permit 20
Validation
Check that routes are flags on R2:
R2#sho ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 6
Paths: (2 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
100
20.1.1.3 from 20.1.1.3 (20.1.3.3)
Origin IGP, metric 0, localpref 1000, valid, internal, best
Refresh Epoch 1
100
10.1.1.1 from 10.1.1.1 (172.16.2.1)
Origin IGP, metric 0, localpref 100, valid, external
Community: 200:100
R2#sho ip bgp 172.16.2.0
BGP routing table entry for 172.16.2.0/24, version 3
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
100
10.1.1.1 from 10.1.1.1 (172.16.2.1)
Origin IGP, metric 0, localpref 500, valid, external, best
Community: 200:200
Check policies applied by R2 and R3 on R4:
R4#sho ip bgp
BGP table version is 9, local router ID is 20.1.3.4
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
*>i 172.16.1.0/24 20.1.3.3 0 1000 0 100 i
*>i 172.16.2.0/24 20.1.2.2 0 500 0 100 i
