Abstract
This article introduces the interpretation and application of BGP's recognized community attributes.
Introduction
Community. A community is a group of purposes that share the same characteristics.
The autonomous system manager can define the community to which the destination belongs. By default, all purposes belong to the Internet community.
Community attribute
The BGP community attribute is defined in RFC1997 (the usage method is defined in RFC1998 and 2519), and it is an optional transition attribute. A community is a group of routes with the same nature of destinations. A community is not limited to a network or an autonomous system. It has no physical boundary. This attribute is generally used as a routing strategy.
The BGP community attribute is a 32-bit value with a total of 4 octets. However, for management arrangement, the following assumptions are made:
Community attribute values ranging from 0x00000000 to 0x0000FFFF and from 0xFFFF0000 to 0xFFFFFFFF are reserved.
The remaining community attribute values should use the AS number as the first two bytes. The semantics of the last two bytes can be defined by the AS itself. (For example, AS690 can define research, education, and business community values for policy routing. For example, operators of AS use community attribute values from 0x02B20000 to 0x02B2FFFF).
Community attributes can be defined in three ways: decimal mode, with a value ranging from 1 to 4 294 967 295; hexadecimal mode, expressed in the format aa: nn, with the local autonomous system number in front and two octets in the back, Is a locally defined value; the third way is to use a name, using a well-known BGP community name.
Recognized community attributes
The following attributes are of global significance and their operations should be applied to any BGP spokesperson that identifies community attributes.
Internet (0)
The default community. All routers that support the BGP community attribute belong to this community.
NO_EXPORT (0xFFFFFF01)
The community attribute contained in all received routing bearers must not be advertised to the autonomous system or its neighbors outside the confederation (an isolated AS, if it is not part of the confederation, it can be regarded as forming a confederation).
NO_ADVERTISE (0xFFFFFF02)
The community attribute contained in all received routing bearers must not be advertised to any other neighbors.
Local-AS (also known as NO_EXPORT_SUBCONFED) (0xFFFFFF03)
All received routes containing this value in the community attribute must not be broadcast to any EBGP neighbors (including members of other ASs in the confederation).
Application in practical networking
Although we understand the definitions of the above four recognized community attributes, we still cannot flexibly apply them in actual networking. We use the following example to illustrate their application scenarios.
The corresponding IBGP and EBGP neighbors are established between the devices as shown in the figure above. Now, two routes 10.10.10.0/24 and 20.20.20.0/24 have been sent from RTA. We can implement different requirements on different devices according to the set attribute values. We first assume a policy named P1.
1. Internet Properties: This is the default property. It doesn't matter if it is set or not. Anyway, you have to send a route.
2. No-Export attribute: The route with this community attribute value must not be advertised to its autonomous system or its neighbors outside the alliance.
As shown above:
(1) When publishing a route on RTA, if you add this attribute:
route-policy p1 permit node 10
apply community no-export
bgp 100
network 10.10.10.0 255.255.255.0 route-policy p1
As a result, when the route is originated by RTA, the no-export attribute is set. Then, if you check the route on RTB, you can see the route on the 10.10.10.0/24 network segment, but other ASs cannot see the route information. Limit routing to this AS.
(2) If this property is not set on RTA, but configure policy P1 on RTB, apply it to the outbound direction of RTB to RTC neighbors (or configure policy P1 on RTC, apply to RTC and RTB Neighbor's inbound direction), so what will happen? Similarly, because the attribute is not originated by the RTA at this time, the RTA will advertise the route on the 10.10.10.0/24 network segment to the RTF, and there will be such a route on the RTB, but is it available on the RTC? It still exists on RTC, because this route entered AS200 with this attribute and cannot go out, so there are still routes on RTC and RTD, but there is no route on this network segment on RTE. Because the attribute takes effect, AS does not appear, resulting in no RTE. routing.
3. NO_ADVERTISE: The community attribute of all received route bearers must not be advertised to any other neighbors if this value is included.
As shown above:
(1) When publishing a route on RTA, if you add this attribute:
route-policy p1 permit node 10
apply community no-advertise
bgp 100
network 10.10.10.0 255.255.255.0 route-policy p1
As a result, when the route was originated by RTA, the no-advertise attribute was set, so when viewing the route on RTB, the route on the 10.10.10.0/24 network segment cannot be seen, but other ASs cannot see the route information. It doesn't make much sense, it is better not to advertise this route in BGP.
(2) If this property is not set on RTA, but configure policy P1 on RTB, apply it to the outbound direction of RTB to RTC neighbors (or configure policy P1 on RTC, apply to RTC and RTB Neighbor's inbound direction), so what will happen? There are still routes on the 10.10.10.0/24 network segment on RTB and RTC, but there is no such route on RTD, and of course, there will be no such route on RTE. Because routes with this attribute will not be sent to any neighbors.
4. Local-AS: All routes containing this value in the community attribute must not be broadcast to any EBGP neighbors (including members of other ASs in the confederation).
The usage of this attribute is very similar to No-export. The only difference is that Local-AS cannot broadcast to any EBGP neighbor (which contains other AS members in the same confederation), and no-export cannot also broadcast to any EBGP neighbor. But can advertise routes to other AS members in the same confederation.
Summary:
The application definition of these attributes is very clear, but the application scenario is easy to be confused. To grasp a principle, which router receives the corresponding attributes in the route can be processed according to the requirements in the definition. If you have any problems, please post them in our Community. We are happy to solve them for you!
