BGP Communities

BGP Communities

  • BGP communities are an optional transitive BGP attribute that can traverse from autonomous system to autonomous system.
  • A BGP community is a 32-bit number that can be included with a route.
  • A BGP community can be displayed as a full 32-bit number (0-4,294,967,295) or as two 16-bit numbers (0-65535):(0-65535) commonly referred to as new-format.
  • Private BGP communities follow the convention that the first 16-bits represent the AS of the community origination, and the second 16-bits represent a pattern defined by the originating AS.
  • The private BGP community pattern could vary from organization to organization, do not need to be registered, and could signify geographic locations for one AS while signifying a method of route advertisement in another AS.
  • IOS XR and NX-OS devices display BGP communities in new-format by default, and IOS nodes display communities in decimal format by default. IOS nodes can display communities in new-format with the global configuration command ip bgp-community new-format.
  • IOS and NX-OS devices do not advertise BGP communities to peers by default. Communities are enabled on a neighbor-by-neighbor basis with the BGP address-family configuration command neighbor ip-address send-community [standard | extended | both], and NX-OS devices use the command send-community [standard | extended | both] under the neighbor address-family configuration.
  • IOS XR advertises BGP communities to IBGP peers by default, but EBGP peers require the neighbor address-family configuration command send-community-ebgp for advertising standard BGP communities, and the command send-extended-community-ebgp to advertise extended BGP communities. Both commands are required if both community formats are to be sent to an EBGP peer.

BGP communities provide additional capability for tagging routes and are considered either well-known or private BGP communities. Private BGP communities are used for conditional matching for a router’s route policy, which could influence routes during inbound or outbound route-policy processing. There are three well-known communities that affect only outbound route advertisement: No-Advertise, No-Export, and Local-As. Routes that contain these communities can be displayed with the command show bgp afi safi [community {local-AS | no-advertise | no-export}] on IOS, IOS XR, and NX-OS devices.

Why do we call them communities? A community is a group of prefixes that should be treated the same way. For example maybe you have 100 prefixes that require the same local preference or weight. You could match all prefixes using an access-list or prefix-list but using BGP communities is more convenient.

Instead of manually selecting the prefixes, an ISP could instruct its customers to tag prefixes with a certain BGP community. When the customer does this, their prefixes get a certain treatment.

The following list might not be up-to-date  but it gives you an impression of how BGP communities are used.

  • If a customer of Level 3 tags their prefixes with 3356:90 then they will set the local preference to 90.
  • If you tag them with 64983:0 then they will prepend the AS number three times to all their BGP neighbors in Europe.
				
					--------------------------------------------------------
customer traffic engineering communities - Regional
--------------------------------------------------------
Will only work for regional peers
64980:0   - announce to customers but not to EU peers
64981:0   - prepend once  to all EU peers
64982:0   - prepend twice to all EU peers
64983:0   - prepend 3x    to all EU peers
64984:0   - prepend 4x    to all EU peers
--------------------------------------------------------
customer traffic engineering communities - LocalPref
--------------------------------------------------------
3356:70   - set local preference to 70
3356:80   - set local preference to 80
3356:90   - set local preference to 90
				
			
BGP Community Formats

No-Advertise

  • The No_Advertise community (0xFFFFFF02 or 4,294,967,042) specifies that routes with this community should not be advertised to any BGP peer.
  • The No-Advertise BGP community can be advertised from an upstream BGP peer or locally with an inbound BGP policy.
  • In either method, the No-Advertise community is set in the BGP Loc-RIB table that affects outbound route advertisement.

Example:

  • R1 is advertising the 10.1.1.0/24 network to R2, and R3 does not have the 10.1.1.0/24 network in its BGP table.
  • R3 cannot see the route in its Adj-RIB-in table because the route was never advertised to it from R2.
  • Notice that the NLRI was “not advertised to any peer” and has the BGP community No-Advertise set.
BGP No-Advertise Community Topology

Example

				
					// R1
route-map NO_ADVERTISE permit 10
 set community no-advertise
!
router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 neighbor 10.1.1.2 remote-as 20
 neighbor 10.1.1.2 send-community
 neighbor 10.1.1.2 route-map NO_ADVERTISE out
				
			
				
					// R2
R2#show bgp ipv4 unicast 192.168.1.0 255.255.255.0
BGP routing table entry for 192.168.1.0/24, version 10
Paths: (1 available, best #1, table default, not advertised to any peer)
  Not advertised to any peer
  Refresh Epoch 5
  10
    10.1.1.1 from 10.1.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-advertise
      rx pathid: 0, tx pathid: 0x0
R2#

R2#show bgp ipv4 unicast neighbors 10.2.2.1 advertised-routes 
Total number of prefixes 0 

R2#show bgp ipv4 unicast neighbors 10.3.3.1 advertised-routes 
Total number of prefixes 0 
R2#
				
			

No-Export

  • The No_Export community (0xFFFFFF01 or 4,294,967,041) specifies that when a route is received with this community, the route is not advertised to any EBGP peer.
  • If the router receiving the No-Export route is a confederation member, the route can be advertised to other sub-ASs in the confederation.

Example:

  • R1 is advertising the 10.1.1.0/24 network to R2, which advertises to R3, and then on to R4.
  • R4 does not advertise the prefix on to R5, so R5 does not have the 10.1.1.0/24 network in its BGP table.
  • Notice that the R3 and R4 displays “not advertised to EBGP peer.
  • R3 is able to advertise the network to R4 (via Update Group #3) because they are members of the same confederation, even though their ASNs are different.
BGP No-Export Community Topology

Example

				
					// R1
route-map NO_EXPORT permit 10
 set community no-export
!
router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 neighbor 10.1.1.2 remote-as 20
 neighbor 10.1.1.2 send-community
 neighbor 10.1.1.2 route-map NO_EXPORT out
				
			
				
					// R2
R2#show bgp ipv4 unicast 192.168.1.0 255.255.255.0
BGP routing table entry for 192.168.1.0/24, version 8
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Advertised to update-groups:
     3         
  Refresh Epoch 5
  10
    10.1.1.1 from 10.1.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-export
      rx pathid: 0, tx pathid: 0x0
R2#

R2#show bgp ipv4 unicast neighbors 10.2.2.1 advertised-routes              
/* BGP table version is 8, local router ID is 192.168.1.2
output omitted */
     Network          Next Hop            Metric LocPrf Weight Path
 *>   192.168.1.0      10.1.1.1                 0             0 10 i
Total number of prefixes 1 
R2#

R2#show bgp ipv4 unicast neighbors 10.3.3.1 advertised-routes 
Total number of prefixes 0 
R2#
				
			

Local_AS (No Export SubConfed)

  • The No_Export_SubConfed community (0xFFFFFF03 or 4,294,967,043) known as the Local-AS community specifies that a route with this community is not advertised outside of the local AS.
  • If the router receiving a route with the Local-AS community is a confederation member, the route can be advertised only within the sub-AS (Member-AS) and is not advertised between Member-ASs.

Example:

  • R1 is advertising the 10.1.1.0/24 network to R2, which advertises to R3.
  • R3 does not advertise the prefix on to R4, so R4 does not have the 10.1.1.0/24 network in its BGP table.

Example

				
					// R1
route-map LOCAL_AS permit 10
 set community local-AS
 !
router bgp 100
 bgp log-neighbor-changes
 network 192.168.1.0
 neighbor 10.1.1.2 remote-as 200
 neighbor 10.1.1.2 send-community
 neighbor 10.1.1.2 route-map LOCAL_AS out
				
			
				
					// R2
R2#show bgp ipv4 unicast 192.168.1.0
BGP routing table entry for 192.168.1.0/24, version 3
Paths: (1 available, best #1, table default, not advertised outside local AS)
  Advertised to update-groups:
     6         
  Refresh Epoch 1
  100
    10.1.1.1 from 10.1.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: local-AS
      rx pathid: 0, tx pathid: 0x0
R2#

R2#show bgp ipv4 unicast neighbors 10.2.2.4 advertised-routes 
/* BGP table version is 3, local router ID is 10.3.3.2 */
     Network          Next Hop            Metric LocPrf Weight Path
 *>   192.168.1.0      10.1.1.1                 0             0 100 i
Total number of prefixes 1 
R2#

R2#show bgp ipv4 unicast neighbors 10.3.3.3 advertised-routes 
Total number of prefixes 0 
R2#

// R4
R4#show bgp ipv4 unicast 192.168.1.0
BGP routing table entry for 192.168.1.0/24, version 3
Paths: (1 available, best #1, table default, not advertised outside local AS)
  Not advertised to any peer
  Refresh Epoch 1
  100
    10.2.2.2 from 10.2.2.2 (10.3.3.2)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      Community: local-AS
      rx pathid: 0, tx pathid: 0x0
R4#

R4#show bgp ipv4 unicast neighbors 10.4.4.5 advertised-routes 
Total number of prefixes 0 
R4#
				
			

Leave a Reply

Related Post

Policy ControlPolicy Control

Policy Control Using BGP Attributes Most commonly used BGP attributes: LOCAL_PREF AS_PATH MED ORIGIN NEXT_HOP WEIGHT BGP picks a best path for a destination IP prefix from multiple paths and