Provider Communities

Topology: bgp-mh-iol

configure replace unix:init.cfg

• All 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 in

Explanation

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_PREFIX

Next 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 out

The 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 out

R4 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 in

Verification

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 out

On R2 we see that the route indeed has an LP of 120, and is prepended two more times to R1.