Understanding BGP Community Attributes

Rashmi Bhardwaj | Blog,Config & Troubleshoot,Routing & Switching
Advertisements

BGP Community Attributes: Introduction

BGP community is an optional transitive attribute. We can use route-maps to set communities on the BGP updates. By default the BGP communities aren’t sent with BGP updates hence we have to specifically mention ‘send-community’ command to send the update with community.

Few of the well-known communities are as below:

  • No-export: Do not advertise to EBGP peers
  • No-advertise: Do not advertise this route to any peer
  • Internet: Advertise this route to the internet community, any router belongs to it.

Communities can also be used in BGP for the route-filtering also known as community filtering.

Advertisements

BGP Community Attributes

Let us use the topology below to configure and verify the community filtering:

We are running eBGP between R1 – R2 and R2 – R3. R3 will advertise the route for 3.3.3.3 to R2 with the BGP community attribute applied to it. First, we will apply community no-advertise and we will see once R2 receives the route with community no-advertise it won’t announce the route about 3.3.3.3 to R1. Secondly we will use community internet while advertising 3.3.3.3 from R3 and will be able to see that the route of 3.3.3.3 is announced to R1.

 

Configuration

R3

router bgp 300

bgp log-neighbor-changes

neighbor 9.9.23.2 remote-as 200

neighbor 9.9.23.2 send-community

neighbor 9.9.23.2 route-map Community out

route-map Community permit 10

 match ip address ACL

 set community no-advertise

 R3#sh ip access-lists ACL

Extended IP access list ACL

10 permit ip any any (2 matches)

We are using a route-map on R3 which call matches an access-list named ACL. ACL is configured to allow all traffic. Hence all routing updates from R3 will be matched in ACL and hence will be set with community no-advertise.

 

Verification –

We see R2 has received route about 3.3.3.3 with community no-advertise as below:

R2#sh ip bgp 3.3.3.3

BGP routing table entry for 3.3.3.3/32, version 4

Paths: (1 available, best #1, table default, not advertised to any peer)

Not advertised to any peer

Refresh Epoch 1

300

9.9.23.3 from 9.9.23.3 (3.3.3.3)

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

      Community: no-advertise

rx pathid: 0, tx pathid: 0x0

We also see R2 isn’t advertising the route about 3.3.3.3 to R1 as below:

R2#sh ip bgp neighbors 9.9.12.1 advertised-routes

BGP table version is 4, local router ID is 2.2.2.2

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

*>  1.1.1.1/32       9.9.12.1                 0             0 100 i

*>  2.2.2.2/32       0.0.0.0                  0         32768 i

Total number of prefixes 2

R1#sh ip bgp

BGP table version is 3, local router ID is 9.9.12.1

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

*>  1.1.1.1/32       0.0.0.0                  0         32768 i

*>  2.2.2.2/32       9.9.12.2                 0             0 200 i

Now let us configure the route-map on R3 to set community to internet and we shall be able to see R2 advertising the route of 3.3.3.3 to R1.

 

Configurations –

 R3:

route-map Community permit 10

 match ip address ACL

 set community internet

 

Verification –

Let us check on R2 now we will see the community as internet and 3.3.3.3 is announced to R1 as below:

 R2#sh ip bgp 3.3.3.3

BGP routing table entry for 3.3.3.3/32, version 5

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

Advertised to update-groups:

1

Refresh Epoch 2

300

9.9.23.3 from 9.9.23.3 (3.3.3.3)

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

      Community: internet

rx pathid: 0, tx pathid: 0x0

R2#sh ip bgp neighbors 9.9.12.1 advertised-routes

BGP table version is 5, local router ID is 2.2.2.2

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

*>  1.1.1.1/32       9.9.12.1                 0             0 100 i

*>  2.2.2.2/32       0.0.0.0                  0         32768 i

 *>  3.3.3.3/32       9.9.23.3                 0             0 300 i

Total number of prefixes 3

Route is received on R1:

R1#sh ip bgp

BGP table version is 4, local router ID is 9.9.12.1

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

*>  1.1.1.1/32       0.0.0.0                  0         32768 i

*>  2.2.2.2/32       9.9.12.2                 0             0 200 i

 *>  3.3.3.3/32       9.9.12.2                               0 200 300 i

Related-

BGP Origin Attribute

BGP Multipath Scenario

ABOUT THE AUTHOR


Leave a Comment

Your email address will not be published. Required fields are marked *

Shopping Cart