Principle and experiment of BGP route aggregation (Huawei equipment)

Overview:

In a large-scale network, the BGP routing table is very large, causing a great burden on the equipment, and at the same time greatly increasing the probability of route oscillation, which affects the stability of the network.

Route aggregation is a mechanism for merging multiple routes. It reduces the size of the routing table by sending only aggregated routes to peers without sending all specific routes. In addition, if the aggregated routes experience route oscillation, they will no longer affect the network, thereby improving the stability of the network.

Route aggregation will use Aggregator attributes and AutoAggregator attributes:

Atomic-Aggregate attribute: It is a recognized arbitrary attribute and is mainly used for route aggregation. If the aggregated route suppresses all detailed routes, this attribute will be generated for the aggregated route. The use of this attribute also has a warning effect, which is used to inform the peer that the original detailed route AS_PATH has been lost.

Aggregator attribute: It is an optional transitional attribute. This attribute is used as a supplement to Atomic-Aggregate to indicate where the routing information is lost. This attribute includes the AS number that initiated the aggregated route and the RouterID of the BGP advertiser that generated the aggregated route (also Called Aggregator ID).

Automatic aggregation:

Note for automatic aggregation:

1. This command aggregates the routes imported by BGP. The imported routes can be direct routes, static routes, RIP routes, OSPF routes, and IS-IS routes. After aggregation is configured, BGP will aggregate routes according to natural network segments, and detailed routes will be suppressed in BGP route updates. This command is invalid for the routes imported by the network command.
2. BGP only sends aggregated routes to peers.
3. BGP does not enable automatic aggregation by default.

Configuration:

1. Run the bgp as-number command to enter the BGP view.
2. Run the ipv4-family unicast command to enter the IPv4 unicast address family view.
3. Run the summary automatic command to configure automatic aggregation of locally imported routes.
   This command aggregates the routes imported by BGP. The imported routes can be direct routes, static routes, RIP routes, OSPF routes, and IS-IS routes. After configuring this command, BGP will aggregate routes according to natural network segments. This command is invalid for the routes imported by the network command.

Manual aggregation:

1. Use static routing for aggregation.
This method is to create a static entry for the aggregation address in the routing table, and then use the network command to announce the aggregation address, as shown in the following example: as shown in the

figure, AS100 has 192.168.1.0/24 , 192.168.2.0/24, 192.168.3.0/24 and 192.168.4.0/24 four internal networks, now we need to aggregate the routes of the four internal networks into one route 192.168.0.0/16. The key configuration of R1:

bgp 100
peer 11.1.1.2 as-number 200

ipv4-family unicast
undo synchronization
network 192.168.0.0 255.255.0.0 //Publish aggregated routes to BGP
peer 11.1.1.2 enable

ip route-static 192.168.0.0 255.255.0.0 NULL0 //Configure a static aggregated route pointing to NULL0

Since the aggregated route itself is not a valid terminal destination address, the static route points to the Null interface. This route only represents an accurate route in the routing table of R1. If the destination address of the data packet belongs to the class C address of AS100, the external router of AS100 will pre-allocate the aggregated route and forward it to R1. After reaching router R1, the data packet will be matched to a more accurate address and forwarded to the correct address. The internal next-hop router. If for some reason the more accurate Class C address is not in the R1 routing table, the packet will be forwarded to the Null interface and discarded. We check the BGP routing table of

R2 : There is only one aggregated route in the routing table of R2, and none of the other detailed routes enter the routing table of R2.

2. Manually aggregate routes through the aggregate command and suppress detailed routing.
In the simple scenario above, aggregation through static routing is sufficient, but for the situation where the topology or routing strategy is slightly more complicated, static routing is used. The aggregation method is not recommended to be used, we can use the aggregate command for manual aggregation. The following specifically describes the role of the aggregate command and its parameters. First use the aggregate command in the simple example above.

The key configuration of R1:

bgp 100
peer 11.1.1.2 as-number 200

ipv4-family unicast
undo synchronization
aggregate 192.168.0.0 255.255.0.0 detail-suppressed
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
peer 11.1.1.2 enable

To announce the aggregated route specified by the aggregate command, at least one more accurate address must be entered into the BGP routing table through redistribution or network command. Here we look at the BGP routing tables of R1 and R2:

you can see that the BGP routing table of R1 contains all precise routes, while the routing table of R2 only has one aggregated route. This is because the detail-suppressed is configured in the aggregate command. Parameter so that R1 will only send aggregated routes to R2. In the BGP routing table of R1, the detailed routes are marked with an "s", which means that these routes have been suppressed by the aggregated routes.

3. Send aggregated routes and detailed routes at the same time
For a simple topology like the above, it is indeed not necessary to announce aggregated routes and detailed routes at the same time. Look at the following example again:

As shown in the figure, AS100 is multi-homed to AS200. AS200 needs to accept all routes from AS100 to set routing policies, but AS200 can only send aggregated routes to AS300. In this scenario, AS100 needs to send all routes to AS200. A simple solution here is to use community attributes. Let the detailed route sent from AS100 to AS200 carry the NO_EXPORT team attribute. Take R1 as an example:

bgp 100
peer 11.1.1.2 as-number 200

ipv4-family unicast
undo synchronization
aggregate 192.168.0.0 255.255.0.0 / route aggregation is 192.168.0.0/16, and does not suppress detailed routing
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
peer 11.1.1.2 enable
peer 11.1.1.2 route-policy COMMUNITY export / Use routing policy COMMUNITY
peer for the outbound direction of R2 11.1.1.2 advertise-community / Send routes with team attributes to R2

route-policy COMMUNITY permit node 5 /Configure routing policy COMMUNITY, do not set the team attribute for routes matching the prefix list AGGREGATE
if-match ip-prefix AGGREGATE
apply community none

route-policy COMMUNITY permit node 10 /The route of the previous node is not matched, and the team attribute NO_EXPORT is marked for it, so that only the detailed route is marked with the NO_EXPORT attribute
apply community no-export

ip ip-prefix AGGREGATE index 10 permit 192.168.0.0 16 /Configuration prefix list
AGGREGATE only matches 192.168.0.0/16

We use the display bgp routing-table 192.168.0.0 command to view the detailed information of the aggregated route on R2: we

can see that the route has been marked as an aggregated route and aggregated in AS100. The originating router's ROUTER ID is 11.1. 1.1. The route does not carry any team attributes. Check the BGP routing table of

R5 : Only aggregated routes exist on R5, and the detailed routes are not sent to R5 because they carry the NO_EXPORT team attribute.

4. Send only aggregated routes and selected detailed routes

In the above scenario, by sending only aggregated routes and selected detailed routes, we can also implement link backup and load sharing, as follows:

1. Let the R1-R2 link only announce the two routes 192.168.1.0/24 and 192.168.2.0/24.
2. Let the R3-R4 link only announce the two routes 192.168.3.0/24 and 192.168.4.0/24
3. The aggregated route is announced as a backup through the above two links. If any link fails, all traffic accessing AS100 on this link will be quickly switched to the other link.

Here, we need R1 and R3 to send aggregated routes and part of detailed routes respectively. In this case, another parameter "suppress-policy" of the aggregate command will be used. The key configurations of R1 and R3 are given below:

The key configuration of R1:

bgp 100
peer 11.1.1.2 as-number 200

ipv4-family unicast
undo synchronization
aggregate 192.168.0.0 255.255.0.0 suppress-policy SUPPRESS / Use the suppression list SUPPRESS when aggregated routing, suppress the detailed routes matching the routing policy SUPPRESS, and release those that do not match, without suppressing.
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
peer 11.1.1.2 enable

route-policy SUPPRESS permit node 5 /Configure routing policy. Note that only if-match clauses can be configured here to match suppressed routes. Although the suppression strategy is used above, the routing strategy can still be configured here, but the name needs and the suppression of the call. And don't add a new node, just match the suppressed entry.
if-match ip-prefix SUPPRESS

ip ip-prefix SUPPRESS index 10 permit 192.168.3.0 24 /Configure the prefix list to match the suppressed entry
ip ip-prefix SUPPRESS index 20 permit 192.168.4.0 24

The key configuration of R3:

bgp 100
peer 12.1.1.2 as-number 200

ipv4-family unicast
undo synchronization
aggregate 192.168.0.0 255.255.0.0 suppress-policy SUPPRESS
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
peer 12.1.1.2 enable

route-policy SUPPRESS permit node 5
if-match ip-prefix SUPPRESS

ip ip-prefix SUPPRESS index 10 permit 192.168.1.0 24
ip ip-prefix SUPPRESS index 20 permit 192.168.2.0 24

By suppressing specific detailed routes, we realized that R1 and R3 only announce aggregated routes and specific detailed routes. Check the BGP routing table on R5:

you can see that the aggregated route on R5 has two next hops, and 192.168.1.0 The next hop of the two routes /24 and 192.168.2.0/24 is R2, and the next hop of the two routes 192.168.3.0/24 and 192.168.4.0/24 is R4. This achieves load sharing of traffic accessing different network segments of AS100. Once a link fails, the traffic can be quickly switched to another link due to the existence of aggregated routes.

5. Aggregate only specific detailed routes
Still in this scenario, suppose we require R1 to aggregate only the two routes 192.168.1.0/24 and 192.168.2.0/24, and aggregate the remaining detailed routes. As shown in the figure:

here, we can use the "origin-policy" parameter of the aggregate command. The specific configuration of R1 is given below:

The key configuration of R1:

bgp 100
peer 11.1.1.2 as-number 200

ipv4-family unicast
undo synchronization
aggregate 192.168.0.0 255.255.0.0 detail-suppressed origin-policy ORIGIN / Here only routes matching the routing policy ORIGIN are aggregated, and other detailed routes are not aggregated. And only announce the aggregated route
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
peer 11.1.1.2 enable

route-policy ORIGIN permit node 5 /Configure the routing policy ORIGIN (still configure the routing policy), note that only if-match clauses can be configured here, the route matching the prefix list ORIGIN
if-match ip-prefix ORIGIN

ip ip-prefix ORIGIN index 10 permit 192.168.1.0 24 / configure prefix list
ip ip-prefix ORIGIN index 20 permit 192.168.2.0 24

In this way, it is realized that only specific detailed routes are aggregated, and the other detailed routes are not aggregated. Let's check the BGP routing table of R2:

It can be seen that in the BGP routing table of R2, there is only one aggregated route and two detailed routes. Since the two routes 192.168.1.0/24 and 192.168.2.0/24 have been aggregated, and the detail-suppressed parameter is configured on R1, the two detailed routes are not sent to R2, and the remaining detailed routes are not sent to R2. Aggregation, so it is sent to R2. It should be noted here that the aggregated route will only be effective if the aggregated detailed routes (192.168.1.0/24 and 192.168.2.0/24) are invalid, and the rest of the details Whether the route fails or not will not affect the aggregated route.

Six, modify the attributes of aggregated routes

Still in this scenario, on R5, there are two next hops for the aggregated route, R2 and R4, and we may need to manually implement R5 to select R4 as the preferred next hop and R2 as the backup next hop. If the MED attribute is used, we need to deploy routing policies on R2 and R4. Here we use another method: when sending aggregated routes, you can modify the attributes of aggregated routes.

Since the detailed routes are entered into R1 manually, the Origin attribute of the route is IGP. When the Origin of the two BGP routes are IGP and Incomplete respectively, BGP will prefer the route with the Origin attribute of IGP. So we can modify the attribute of the aggregate route sent from R1 to R2 to Incomplete.

At this time, we will use another parameter "attribute-policy" of the aggregate command. The specific configuration is given below:

The key configuration of R1:

bgp 100
peer 11.1.1.2 as-number 200

ipv4-family unicast
undo synchronization
aggregate 192.168.0.0 255.255.0.0 detail-suppressed attribute-policy ATTRIBUTE / Modify the aggregated route attribute according to the routing policy ATTRIBUTE
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
peer 11.1.1.2 enable

route-policy ATTRIBUTE permit node 5 / Configure routing policy ATTRIBUTE and modify the attribute to incomplete
apply origin incomplete

Check the BGP routing table of R5:

you can see that BGP prefers R4 as the preferred next hop. Since the Ogn value of the route corresponding to R4 is "i", the Origin attribute of the route is IGP, and the Ogn value of the route corresponding to R2 is "?" means that the Origin attribute of the route is Incomplete.

Configuration summary:

1. Run the bgp as-number command to enter the BGP view.
2. Run the ipv4-family unicast command to enter the IPv4 unicast address family view.
3. According to the actual network selection, execute the following commands to configure manual aggregation of routes.
   • Publish all aggregated routes and detailed routes: execute the command aggregate ipv4-address {mask | mask-length}
   • Publish only aggregate routes: execute the command aggregate ipv4-address {mask | mask-length} detail-suppressed
   • Selectively publish Detailed routing: Execute the command aggregate ipv4-address {mask | mask-length} suppress-policy route-policy-name
   to achieve the same effect by applying a policy through the peer route-policy command.
   • Generate aggregated routes for loop detection: run the command aggregate ipv4-address {mask | mask-length} as-set
   • Set the attributes of aggregated routes: run the command aggregate ipv4-address {mask | mask-length} attribute-policy route- The policy-name
   can also achieve the same effect by executing the peer route-policy command.
   When the aggregate command is executed, if the keyword as-set is used, and the apply as-path command is also executed in the policy to configure the AS_Path attribute, the AS_Path in the policy will not take effect.
   • Generate aggregated routes based on only partial detailed routes: execute the command aggregate ipv4-address {mask | mask-length} origin-policy route-policy-name

Manual aggregation is effective for routing entries that already exist in the BGP local routing table. For example, there is no route with a mask length of 16. such as 10.1.1.1/24 in the BGP routing table, even if the command aggregate 10.1.1.1 16 is configured to aggregate it , BGP will not advertise this aggregated route.

Check the configuration result: Use the display bgp routing-table [network [mask | mask-length]] command to view the BGP aggregated routing information.

In addition, what if the origin of an aggregated route entry is? There is also i. What is the origin of the last aggregated routing entry? . If both are i, then it is i.

Sorting out data sources: "Switches in Jianghu", Huawei training documents