Following are the various types of communities used in BGP:

• No-Advertise Community

When a route is associated with a No-Advertise community, the BGP speaker will not advertise the route to any internal or external BGP peers.

R1 does not advertise a No-Advertise Route (10.10.10.0/24) to peers R11, R12, and R111 in the following example.

• Community with No Exports

When a No-Export community is associated with a route, the router will only advertise the route to internal peers.

R1, R11, and R12 are not advertising a No-Export Route (10.10.10.0/24) to their external peer, R111, as seen in the following example.

R1 will not advertise the route to R111 in this situation, just to R11 and R12, because they are internal BGP peers. As a result, because R111 is an external BGP peer, R11 and R12 will not advertise either route to it.

• Local AS Community 

There is an important regulation about internal BGP neighbours to avoid BGP routing loops: an IBGP neighbour cannot advertise a route to another IBGP neighbour if it obtained that route from another IBGP neighbour.

A Local AS Route (10.10.10.0/24) is not promoted between IBGP neighbours (R11 and R111) within the local AS in the following example.

According to the criteria indicated above, R11 advertises the route to R22, but R22 does not advertise the path to R111. There are several options for getting the route to R111, including constructing a full mesh of IBGP sessions between AS11 routers or dividing the AS 11 into a sub-AS within a confederation.

Outside of AS11, no one knows what AS 1000 and AS1001 are. R111 can now receive the 10.10.10.0/24 route even if it does not have full mesh BGP peering. Outside of the sub-AS, the Local-AS community does not advertise routes.

• Graceful Shutdown Community

When a router's peer router is about to be purposely shut down, the Graceful SHUTDOWN (65535:0) community is used to seamlessly shut down paths it could use. Consider the following scenario: R111 is utilising R11 to access the 10.10.10.0/24 network, but R11 will be rebooted to be upgraded:

R111 replies by transferring traffic to R12 with minimum disruption when R11 announces this community:

• EXTENDED Community 

An Extended community is an 8-byte value that is split into TWO parts:

• The first two bytes indicate the sort of community.
• The last six bytes provide information that is specific to the type of community.

There are three fields in an extended community: kind, administrator, and assigned number (type:administrator:assigned-number). The administrator field can be an AS or an IP ADDRESS, depending on the value of the high-order byte in the Type field. MPLS-VPN is the most well-known use for extended communities, as it uses two extended communities:

• Route Target community: Determines which routers are capable of receiving a given set of routes.
• Route Origin community: This group of routers is responsible for injecting a specified set of routes into BGP.

A Virtual Routing and Forwarding (VRF) table is a virtual routing table that can have its own routing policies that are independent of the global routing table or other VRFs. Essentially, you can connect numerous client sites and create a DISTINCT routing table (VRF) throughout the entire network exclusively for this customer, with routing policies that differ from those of other customers.

• Route Target Community 

In MPLS VPN setups, the Route Target community is used to segregate two customers' routing tables, as depicted in the diagram below:

VRF Customer RED is only present on R1 and R12, and VRF Customer BLUE is only present on R11 and R22 in this scenario, but they may have been present on all four routers.

When a route is exported from VRF Red using BGP, the route-target 100:100 is assigned to the route. When the route reaches R12, the route from R1 is imported, allowing the sites connected to R1 and R12 to communicate.

• Route Origin Community 

The route origin community is used in an MPLS VPN environment to identify where routes originated from so that readvertisement back to that site is avoided.

When PE1 receives the route from CE1, it ATTACHES the route origin community in addition to the route-target that is linked to the route (through export).

The route reaches PE2, but PE2 does not inform CE2 because it is aware that it originated at the location.