Provider Communities
Topology: bgp-mh-iol
configure replace unix:init.cfgAll links are in the format 100.X.Y.X/24.
For example, the link between R4 and R7 is 100.4.7.0/24.
Lo0 is X.X.X.X/32 and is used for iBGP
Lo1 is <AS>.0.0.X/32 and is used as a public IP address that is pingable. The public Lo1 addresses are aggregated into a /8 at each edge router.
eBGP and iBGP is fully preconfigured.
Configure communities in AS20 to accomplish the following:
AS10 is an upstream provider, AS40 is a transit peer, and AS50 is a customer. Only advertise customer and local routes to transit peers and providers. Do not let transit routes leak to upstream providers, and upstream routes leak to transit providers.
Allow AS50 to control their inbound traffic using the following table:
Community
Action
20:80
LP=80
20:90
LP=90
20:110
LP=110
20:120
LP=120
20:1
Prepend AS20 one additional time on advertisements to upstreams
20:2
Prepend AS20 two additional times on advertisements to upstreams
20:3
Prepend AS20 three additional times on advertisements to upstreams
Answer
#R2, R4, R5
ip bgp-community new-format
!
ip community-list standard LP_80 permit 20:80
ip community-list standard LP_90 permit 20:90
ip community-list standard LP_110 permit 20:110
ip community-list standard LP_120 permit 20:120
ip community-list standard PREPEND_1 permit 20:1
ip community-list standard PREPEND_2 permit 20:2
ip community-list standard PREPEND_3 permit 20:3
ip community-list standard LOCAL_PREFIXES permit 20:1000
ip community-list standard CUSTOMER_PREFIXES permit 20:2000
ip community-list standard TRANSIT_PREFIXES permit 20:3000
!
route-map LOCAL_PREFIX
set community 20:1000
!
router bgp 20
template peer-policy IBGP
send-community
exit-peer-policy
!
address-family ipv4
network 20.0.0.0 route-map LOCAL_PREFIX
#R2
route-map TRANSIT_PEER_INBOUND
set community 20:3000
!
route-map TRANSIT_PEER_OUTBOUND
match community LOCAL_PREFIXES
!
route-map TRANSIT_PEER_OUTBOUND permit 20
match community CUSTOMER_PREFIXES
!
route-map UPSTREAM_INBOUND
set community 20:3000
!
route-map UPSTREAM_OUTBOUND deny 10
match community TRANSIT_PREFIXES
!
route-map UPSTREAM_OUTBOUND permit 20
match community PREPEND_1
set as-path prepend 20
!
route-map UPSTREAM_OUTBOUND permit 30
match community PREPEND_2
set as-path prepend 20 20
!
route-map UPSTREAM_OUTBOUND permit 40
match community PREPEND_3
set as-path prepend 20 20 20
!
route-map UPSTREAM_OUTBOUND permit 1000
!
router bgp 20
address-family ipv4
neighbor 100.1.2.1 route-map UPSTREAM_INBOUND in
neighbor 100.1.2.1 route-map UPSTREAM_OUTBOUND out
neighbor 100.2.10.10 route-map TRANSIT_PEER_INBOUND in
neighbor 100.2.10.10 route-map TRANSIT_PEER_OUTBOUND out
#R4, R5
route-map CUSTOMER_INBOUND
match community LP_80
set local-pref 80
continue 1000
!
route-map CUSTOMER_INBOUND permit 20
match community LP_90
set local-pref 90
continue 1000
!
route-map CUSTOMER_INBOUND permit 30
match community LP_110
set local-pref 110
continue 1000
!
route-map CUSTOMER_INBOUND permit 40
match community LP_120
set local-pref 120
continue 1000
!
route-map CUSTOMER_INBOUND permit 1000
set community 20:2000 additive
#R4
router bgp 20
add ipv4
neighbor 100.4.7.7 route-map CUSTOMER_INBOUND in
#R5
router bgp 20
add ipv4
neighbor 100.5.8.8 route-map CUSTOMER_INBOUND inExplanation
Using communities for routing policies can produce route-maps that become quite complex. This lab solution uses the following communities within AS20:
Community
Action/Purpose
20:80
LP=80
20:90
LP=90
20:110
LP=110
20:120
LP=120
20:1
Prepend AS20 one additional time on advertisements to upstreams
20:2
Prepend AS20 two additional times on advertisements to upstreams
20:3
Prepend AS20 three additional times on advertisements to upstreams
20:1000
Locally injected prefixes
20:2000
Customer learned prefixes
20:3000
Transit learned prefixes (these should never be advertised to another transit provider)
First a series of community lists are defined on all routers in AS20 that identify each of these communities.
Next, we configure the local AS20 prefix to be injected with the 20:1000 community.
route-map LOCAL_PREFIX
set community 20:1000
!
router bgp 20
address-family ipv4
network 20.0.0.0 route-map LOCAL_PREFIXNext we configure policies for the transit peer (R10). Only customer and local prefixes should be advertised. The instructions say to only prepend customer routes to upstream providers, so we don’t have to worry about prepending towards transit peers. Routes received inbound from the peer are tagged with 20:3000.
#R2
route-map TRANSIT_PEER_INBOUND
set community 20:3000
!
route-map TRANSIT_PEER_OUTBOUND
match community LOCAL_PREFIXES
!
route-map TRANSIT_PEER_OUTBOUND permit 20
match community CUSTOMER_PREFIXES
!
router bgp 20
address-family ipv4
neighbor 100.2.10.10 route-map TRANSIT_PEER_INBOUND in
neighbor 100.2.10.10 route-map TRANSIT_PEER_OUTBOUND outThe upstream peer is a little more complex, because we must advertise only customer and local prefixes, but also prepend the announcement depending on a customer-received community. The solution in this lab is to deny the transit prefixes (20:3000) which will only end up allowing customer and local prefixes. Then an individual sequence is used for each AS path prepend.
#R2
route-map UPSTREAM_INBOUND
set community 20:3000
!
route-map UPSTREAM_OUTBOUND deny 10
match community TRANSIT_PREFIXES
!
route-map UPSTREAM_OUTBOUND permit 20
match community PREPEND_1
set as-path prepend 20
!
route-map UPSTREAM_OUTBOUND permit 30
match community PREPEND_2
set as-path prepend 20 20
!
route-map UPSTREAM_OUTBOUND permit 40
match community PREPEND_3
set as-path prepend 20 20 20
!
route-map UPSTREAM_OUTBOUND permit 1000
!
router bgp 20
address-family ipv4
neighbor 100.1.2.1 route-map UPSTREAM_INBOUND in
neighbor 100.1.2.1 route-map UPSTREAM_OUTBOUND outR4 and R5 need to have an inbound customer route-map that tags the received routes with 20:2000 and allows the customer to set local pref. The continue statement is used in this solution, which always tags the customer route with 20:2000, no matter which local pref is assigned. The additive keyword is used to retain any communities that are attached by the customer, such as AS path prepending communities.
route-map CUSTOMER_INBOUND
match community LP_80
set local-pref 80
continue 1000
!
route-map CUSTOMER_INBOUND permit 20
match community LP_90
set local-pref 90
continue 1000
!
route-map CUSTOMER_INBOUND permit 30
match community LP_110
set local-pref 110
continue 1000
!
route-map CUSTOMER_INBOUND permit 40
match community LP_120
set local-pref 120
continue 1000
!
route-map CUSTOMER_INBOUND permit 1000
set community 20:2000 additive
#R4
router bgp 20
add ipv4
neighbor 100.4.7.7 route-map CUSTOMER_INBOUND inVerification
R1 and R10 should only receive customer and local prefixes from R2. This includes 20/8 and 50/8.
We should see that routes belong to the appropriate communities on R2. 20/8 belongs to 20:1000, 50/8 belongs to 20:2000, and 10/8, 30/8, 40/8 belong to 20:3000. Note that 50/8 also belongs to 20:3000, but this is only the advertisement from R1. This is not currently the best path.
Let’s now test that communities work inbound from a customer. On R7 we’ll set local preference higher and also prepend the announcement twice.
#R7
route-map R4_OUT
set community 20:120 20:2
!
router bgp 50
add ipv4
neighbor 100.4.7.4 route-map R4_OUT out
neighbor 100.4.7.4 send-community
do clear ip bgp * soft outOn R2 we see that the route indeed has an LP of 120, and is prepended two more times to R1.
Last updated