BGP Peering Functions with Peer Groups and Communities

BGP peer groups are administrative units that are deployed to simplify the maintenance of several BGP routers. Technically speaking, a peer group must consist of two or more BGP neighbor routers. BGP peers in a peer group have identical update policies and are administered as a single entity. Because all peer group members inherit all peer group settings, you might create one routing update policy and apply it to a peer group rather than configure a routing policy for each individual peer router. After you have properly configured a peer group, all changes on one member router will be dynamically applied to all the BGP routers within the peer group. Each member of the peer group routinely shares the policy information. All EBGP members of a peer group must be able to be accessible over the same interface so that the Next -hop attribute is different for the EBGP peers on different interfaces. Loopback addresses can be used as a workaround for this limitation. Peer group members can also be configured to override options if they do not affect outbound updates. You can override only peer group options that are set on the inbound.

Another structure that can be established to simplify administration of BGP routers is a Community. A Community is an attribute that can be assigned to a route to make route filtering, redistribution, and/or path selection easier. It is fundamentally a set of destination networks that have a common property and to which the same or similar policy rules can be applied. The administrative benefits of a Community pales in comparison to peer groups, but they can provide a suitable way to create a reliable route-selection policy when using route maps. (Route maps are covered in the next chapter.) The Community attribute is a 32-bit number. The first 16 bits represent the local AS and the second 16 bits identify the community number itself. BGP routers can use the Community attribute to flag routes that are entering and exiting interfaces during route updates. Any other router configured to support the Community attribute can then make routing decisions based upon the Community identifier. The Community attribute has an advantage over other types of routing policy because only a single attribute must be checked on incoming route update traffic, rather than entire packets, which must be processed using access list technology. Table 8.5 offers some commonly used Community types.

Table 8.5. Some Well-Known Community Types

Community Types	Description
No-export	This Community tells the router not to advertise to EBGP peers; keep this route within an AS.
No-advertise	This Community tells the router not to advertise the route to any peer, whether internal (IBGP) or external (EBGP).
internet	This Community tells the router to advertise the route to the Internet community, or any router that belongs to it.
Local-AS	This Community tells the router to advertise this route to IBGP peers only. Also uses confederation scenarios to prevent sending packets outside the local AS. (Confederations are covered in the next chapter.)