Usage Scenario

By default, BGP advertises all selected routes in the BGP routing table to peers. After the active-route-advertise command is configured, only the routes selected by BGP and also active at the routing management layer are advertised to peers.

Precautions

The active-route-advertise and routing-table rib-only commands are mutually exclusive.

Usage Scenario

By default, BGP advertises all selected routes in the BGP routing table to peers. After the active-route-advertise command is configured, only the routes selected by BGP and also active at the routing management layer are advertised to peers.

Precautions

The active-route-advertise and routing-table rib-only commands are mutually exclusive.

Usage Scenario

By default, BGP advertises all selected routes in the BGP routing table to peers. After the active-route-advertise command is configured, only the routes selected by BGP and also active at the routing management layer are advertised to peers.

Precautions

The active-route-advertise and routing-table rib-only commands are mutually exclusive.

Usage Scenario

By default, BGP advertises all selected routes in the BGP routing table to peers. After the active-route-advertise command is configured, only the routes selected by BGP and also active at the routing management layer are advertised to peers.

Precautions

The active-route-advertise and routing-table rib-only commands are mutually exclusive.

Usage Scenario

By default, BGP advertises all selected routes in the BGP routing table to peers. After the active-route-advertise command is configured, only the routes selected by BGP and also active at the routing management layer are advertised to peers.

Precautions

The active-route-advertise and routing-table rib-only commands are mutually exclusive.

Usage Scenario

By default, BGP advertises all selected routes in the BGP routing table to peers. After the active-route-advertise command is configured, only the routes selected by BGP and also active at the routing management layer are advertised to peers.

Precautions

The active-route-advertise and routing-table rib-only commands are mutually exclusive.

Usage Scenario

By default, the device advertises all routes in the BGP VPN routing table to the BGP VPNv4/VPNv6 routing table. For example, the supernet unicast routes are invalid, but VPNv4 and VPNv6 routing tables have such routes. In addition, forwarding entries are generated for such routes, and the routes are advertised to peers. You can run the advertise valid-routes command to configure a device to send only valid routes in a BGP VPN routing table to a BGP VPNv4/VPNv6 routing table.

Usage Scenario

By default, the device advertises all routes in the BGP VPN routing table to the BGP VPNv4/VPNv6 routing table. For example, the supernet unicast routes are invalid, but VPNv4 and VPNv6 routing tables have such routes. In addition, forwarding entries are generated for such routes, and the routes are advertised to peers. You can run the advertise valid-routes command to configure a device to send only valid routes in a BGP VPN routing table to a BGP VPNv4/VPNv6 routing table.

Usage Scenario

You can run the advertise bgp ipv4-family unicast lowest-priority enable command to forcibly adjust the BGP route priority to the lowest (the MED value is set to the maximum value and the Local_Pref value is set to the minimum value) so that service traffic is switched to the other device.

Precautions

The advertise bgp ipv4-family unicast lowest-priority enable command takes effect for all routes in the BGP-Ipv4 unicast and BGP-VPN instance Ipv4 address families.

If at least one of the advertise bgp ipv4-family unicast lowest-priority enable and advertise lowest-priority all-address-family peer-up commands is run, BGP can set the priorities of routes (to be advertised) in the preceding address families to the lowest when BGP peers in these address families go up from down.

After the advertise bgp ipv4-family unicast lowest-priority enable command is run, modifying the MED and Local_Pref attributes of BGP routes to be advertised through an export routing policy does not take effect.

Usage Scenario

You can run the advertise bgp ipv6-family unicast lowest-priority enable command to forcibly adjust the BGP route priority to the lowest (the MED value is set to the maximum value and the Local_Pref value is set to the minimum value) so that service traffic is switched to the other device.

Precautions

The advertise bgp ipv6-family unicast lowest-priority enable command takes effect for all routes in the BGP-IPv6 unicast and BGP-VPN instance IPv6 address families.

If at least one of the advertise bgp ipv6-family unicast lowest-priority enable and advertise lowest-priority all-address-family peer-up commands is run, BGP can set the priorities of routes (to be advertised) in the preceding address families to the lowest when BGP peers in these address families go up from down.

After the advertise bgp ipv6-family unicast lowest-priority enable command is run, modifying the MED and Local_Pref attributes of BGP routes to be advertised through an export routing policy does not take effect.

Usage Scenario

After a device is restarted, routes on the device need to be advertised after a delay to prevent traffic loss during forwarding entry delivery. To solve this problem, run the advertise delay on-startup delay-time command before the device restarts to configure a BGP route advertisement delay after the device restarts. The command specifies how long the device must wait after a restart before it starts to advertise BGP routes. After forwarding entries are delivered, you can run the refresh bgp all export or reset bgp advertise delay on-startup command to enable the device to advertise BGP routes immediately.

Precautions

The advertise delay on-startup delay-time command takes effect only after the reboot command is executed and the configuration is saved.

If both this command and the advertise lowest-priority on-startup command are run, the latest configuration overrides the previous one.

This command and the advertise lowest-priority all-address-family peer-up delay command are mutually exclusive.

Usage Scenario

After a device is restarted, routes on the device need to be advertised after a delay to prevent traffic loss during forwarding entry delivery. To solve this problem, run the advertise delay on-startup delay-time command before the device restarts to configure a BGP route advertisement delay after the device restarts. The command specifies how long the device must wait after a restart before it starts to advertise BGP4+ routes. After forwarding entries are delivered, you can run the refresh bgp all export, refresh bgp ipv6 all export, or reset bgp advertise delay on-startup command to enable the device to immediately advertise BGP4+ routes.

Precautions

The advertise delay on-startup delay-time command takes effect only after the reboot command is executed and the configuration is saved.

If both this command and the advertise lowest-priority on-startup command are run, the latest configuration overrides the previous one.

This command and the advertise lowest-priority all-address-family peer-up delay command are mutually exclusive.

Usage Scenario

If the advertise lowest-priority all-address-family peer-up command is not run, BGP routes with unchanged priorities are advertised to peers when the peers go Up from Down. After the peers receive the routes, traffic may be switched back to the original paths. Consequently, lengthy packet loss may occur. To address this problem, run the advertise lowest-priority all-address-family peer-up command. After the command is run, routes advertised to the peers carry the lowest priorities (largest MED value and smallest Local_Pref value) until delay expires.

Precautions

If you run the advertise lowest-priority all-address-family peer-up delay command and then the advertise lowest-priority all-address-family peer-up command in sequence, the latest configuration overrides the previous one. That is, the delay time is cleared. The advertise lowest-priority all-address-family peer-up and advertise lowest-priority on-startup commands are mutually exclusive.

Usage Scenario

If the advertise lowest-priority all-address-family peer-up command is not run, BGP routes with unchanged priorities are advertised to peers when the peers go Up from Down. After the peers receive the routes, traffic may be switched back to the original paths. Consequently, lengthy packet loss may occur. To address this problem, run the advertise lowest-priority all-address-family peer-up command. After the command is run, routes advertised to the peers carry the lowest priorities (largest MED value and smallest Local_Pref value) until delay expires.

Precautions

If you run the advertise lowest-priority all-address-family peer-up delay command and then the advertise lowest-priority all-address-family peer-up command in sequence, the latest configuration overrides the previous one. That is, the delay time is cleared.

The advertise lowest-priority all-address-family peer-up and advertise lowest-priority on-startup commands are mutually exclusive.

Usage Scenario

When a device restarts during ARP entry delivery, the route advertised by the device needs to have a low priority to prevent traffic loss.<br /> Before restarting the device, you can run the advertise lowest-priority on-startup command to set the lowest priority for the routes advertised to peers. That is, you can change the MED value to 4294967295 and the Local_Pref value to 0. As such, a BGP route advertised by the device has the lowest priority among routes of the the same type after the device restarts, preventing the BGP route from being preferentially selected. To restore the priorities of these BGP routes after ARP entries are delivered, run the reset bgp advertise lowest-priority on-startup command.

You can also run the advertise lowest-priority on-startup delay-time command before the device restarts to ensure that the priority of the routes advertised by the device is the lowest among the routes of the same type within the configured delay after the device restarts. ARP entries are delivered within the delay time. After the delay time expires, the priority of the routes advertised by the device is automatically restored. Within the delay, you can also run the reset bgp advertise lowest-priority on-startup command to restore the default priority of the routes to be advertised.

In addition, when advertising low-priority routes, you can run the undo undo advertise lowest-priority on-startup [delay-time ] command to restore the default priority of routes to be advertised, regardless of whether there is a delay.

Precautions

If the advertise lowest-priority on-startup command is run after BGP configurations are committed, the configuration of this command takes effect only after the reboot command is run. If the advertise lowest-priority on-startup command and BGP configurations are committed as a whole, the configuration of this command takes effect immediately.

This command and the advertise delay on-startup delay-time command overwrite each other.

This command and the advertise lowest-priority all-address-family peer-up delay command are mutually exclusive.

Usage Scenario

When a device restarts during ARP entry delivery, the route advertised by the device needs to have a low priority to prevent traffic loss.<br /> Before restarting the device, you can run the advertise lowest-priority on-startup command to set the lowest priority for the routes advertised to peers. That is, you can change the MED value to 4294967295 and the Local_Pref value to 0. As such, a BGP route advertised by the device has the lowest priority among routes of the the same type after the device restarts, preventing the BGP route from being preferentially selected. To restore the priorities of these BGP routes after ARP entries are delivered, run the reset bgp advertise lowest-priority on-startup command.

You can also run the advertise lowest-priority on-startup delay-time command before the device restarts to ensure that the priority of the routes advertised by the device is the lowest among the routes of the same type within the configured delay after the device restarts. ARP entries are delivered within the delay time. After the delay time expires, the priority of the routes advertised by the device is automatically restored. Within the delay, you can also run the reset bgp advertise lowest-priority on-startup command to restore the default priority of the routes to be advertised.

In addition, when advertising low-priority routes, you can run the undo undo advertise lowest-priority on-startup [delay-time ] command to restore the default priority of routes to be advertised, regardless of whether there is a delay.

Precautions

If the advertise lowest-priority on-startup command is run after BGP configurations are committed, the configuration of this command takes effect only after the reboot command is run. If the advertise lowest-priority on-startup command and BGP configurations are committed as a whole, the configuration of this command takes effect immediately.

This command and the advertise delay on-startup delay-time command overwrite each other.

This command and the advertise lowest-priority all-address-family peer-up delay command are mutually exclusive.

Usage Scenario

BGP route summarization is classified as manual route summarization or automatic route summarization. The aggregate command is used to implement manual route summarization, which takes precedence over automatic route summarization. The aggregate ipv4-address { mask | mask-length } command configures BGP to summarize specific routes in the local BGP routing table and then advertise all specific routes as well as the summary route. The generated summary route inherits the Origin attribute from the specific routes if they have the same Origin attribute. If the specific routes have different Origin attributes, the summary route selects one as its own from these Origin attributes in descending order of preference: incomplete > egp > igp. In addition, the summary route carries the atomic-aggregate attribute. Except the Origin and atomic-aggregate attributes, the summary route does not carry any other attributes of the specific routes.

To generate a summary route that can be used to detect a routing loop, you can specify the as-set parameter when running the aggregate command. The summary route inherits the attributes such as Origin, AS_Path (used for loop prevention), community, and large-community from the specific routes. The summary route also carries the community attributes of all its original specific routes. If the number of community attributes carried in the specific routes being summarized exceeds 255, route summarization stops, and the routes that fail to participate in summarization are still advertised as specific routes. Exercise caution to use this parameter if a large number of AS_Path lists are involved in route summarization. This is because frequent changes in the specific routes may cause route flapping.

If detail-suppressed is specified in the command, the summarized route is advertised, but specific routes are not. The summarized route carries the atomic-aggregate attribute, not the community attributes of specific routes.

If suppress-policy is specified in the command, specified routes are not advertised. The if-match clause of route-policy can be used to filter the routes, and only the routes matching the policy will be suppressed. The peer route-policy command can also be used to filter routes and prevent unwanted routes from being advertised to peers.

If origin-policy is specified in the command, only the routes matching route-policy are summarized.

If attribute-policy is specified in the command, attributes can be set for the summarized route. If the AS_Path attribute is set in the policy using the apply as-path command and as-set is set in the aggregate command, the AS_Path attribute in the policy does not take effect. The peer route-policy command can also be used to set attributes for a summarized route.

Configuration Impact

If detail-suppressed is configured in the command, the advertisement of specific routes will be suppressed. If suppress-policy is configured in the command, the advertisement of the specific routes that match the policy will be suppressed.

Precautions

If the undo aggregate command is run, the system will match routes against the configured attribute-policy, origin-policy, suppress-policy, as-set, or detail-suppressed. If no parameter is configured, the system will fail to execute the undo aggregate command.

After a summary route is configured using the aggregate command and the summary route is leaked from the local VPN instance to another VPN instance, the summary route may be selected to guide traffic forwarding due to its high priority. As a result, traffic is dropped. To prevent this issue, plan a proper mask length for the summary route.

Usage Scenario

BGP route summarization is classified as manual route summarization or automatic route summarization. The aggregate command is used to implement manual route summarization, which takes precedence over automatic route summarization. The aggregate ipv4-address { mask | mask-length } command configures BGP to summarize specific routes in the local BGP routing table and then advertise all specific routes as well as the summary route. The generated summary route inherits the Origin attribute from the specific routes if they have the same Origin attribute. If the specific routes have different Origin attributes, the summary route selects one as its own from these Origin attributes in descending order of preference: incomplete > egp > igp. In addition, the summary route carries the atomic-aggregate attribute. Except the Origin and atomic-aggregate attributes, the summary route does not carry any other attributes of the specific routes.

To generate a summary route that can be used to detect a routing loop, you can specify the as-set parameter when running the aggregate command. The summary route inherits the attributes such as Origin, AS_Path (used for loop prevention), community, and large-community from the specific routes. The summary route also carries the community attributes of all its original specific routes. If the number of community attributes carried in the specific routes being summarized exceeds 255, route summarization stops, and the routes that fail to participate in summarization are still advertised as specific routes. Exercise caution to use this parameter if a large number of AS_Path lists are involved in route summarization. This is because frequent changes in the specific routes may cause route flapping.

If detail-suppressed is specified in the command, the summarized route is advertised, but specific routes are not. The summarized route carries the atomic-aggregate attribute, not the community attributes of specific routes.

If suppress-policy is specified in the command, specified routes are not advertised. The if-match clause of route-policy can be used to filter the routes, and only the routes matching the policy will be suppressed. The peer route-policy command can also be used to filter routes and prevent unwanted routes from being advertised to peers.

If origin-policy is specified in the command, only the routes matching route-policy are summarized.

If attribute-policy is specified in the command, attributes can be set for the summarized route. If the AS_Path attribute is set in the policy using the apply as-path command and as-set is set in the aggregate command, the AS_Path attribute in the policy does not take effect. The peer route-policy command can also be used to set attributes for a summarized route.

Configuration Impact

If detail-suppressed is configured in the command, the advertisement of specific routes will be suppressed. If suppress-policy is configured in the command, the advertisement of the specific routes that match the policy will be suppressed.

Precautions

If the undo aggregate command is run, the system will match routes based on the configured parameter attribute-policy, origin-policy, suppress-policy, as-set, or detail-suppressed. If the parameter is not configured, the system will fail to execute the undo aggregate command.

After the aggregate command is run, the summary route that is leaked to a VPN instance may be preferentially selected to guide traffic forwarding because it has a higher priority. As a result, traffic is discarded. To prevent this problem, plan a proper mask length for the summary route.

When an origin-policy is applied to summary routes and the if-match route-type command is run to filter routes based on the route type, only the routes imported in import or network mode support route type-based filtering. Other types of routes (such as the routes learned from peers) do not support route type-based filtering.

Usage Scenario

BGP route summarization is classified as manual route summarization or automatic route summarization. The aggregate command is used to implement manual route summarization, which takes precedence over automatic route summarization. The aggregate ipv4-address { mask | mask-length } command configures BGP to summarize specific routes in the local BGP routing table and then advertise all specific routes as well as the summary route. The generated summary route inherits the Origin attribute from the specific routes if they have the same Origin attribute. If the specific routes have different Origin attributes, the summary route selects one as its own from these Origin attributes in descending order of preference: incomplete > egp > igp. In addition, the summary route carries the atomic-aggregate attribute. Except the Origin and atomic-aggregate attributes, the summary route does not carry any other attributes of the specific routes.

To generate a summary route that can be used to detect a routing loop, you can specify the as-set parameter when running the aggregate command. The summary route inherits the attributes such as Origin, AS_Path (used for loop prevention), community, and large-community from the specific routes. The summary route also carries the community attributes of all its original specific routes. If the number of community attributes carried in the specific routes being summarized exceeds 255, route summarization stops, and the routes that fail to participate in summarization are still advertised as specific routes. Exercise caution to use this parameter if a large number of AS_Path lists are involved in route summarization. This is because frequent changes in the specific routes may cause route flapping.

If detail-suppressed is specified in the command, the summarized route is advertised, but specific routes are not. The summarized route carries the atomic-aggregate attribute, not the community attributes of specific routes.

If suppress-policy is specified in the command, specified routes are not advertised. The if-match clause of route-policy can be used to filter the routes, and only the routes matching the policy will be suppressed. The peer route-policy command can also be used to filter routes and prevent unwanted routes from being advertised to peers.

If origin-policy is specified in the command, only the routes matching route-policy are summarized.

If attribute-policy is specified in the command, attributes can be set for the summarized route. If the AS_Path attribute is set in the policy using the apply as-path command and as-set is set in the aggregate command, the AS_Path attribute in the policy does not take effect. The peer route-policy command can also be used to set attributes for a summarized route.

Configuration Impact

If detail-suppressed is configured in the command, the advertisement of specific routes will be suppressed. If suppress-policy is configured in the command, the advertisement of the specific routes that match the policy will be suppressed.

Precautions

If the undo aggregate command is run, the system will match routes against the configured attribute-policy, origin-policy, suppress-policy, as-set, or detail-suppressed. If no parameter is configured, the system will fail to execute the undo aggregate command.

After a summary route is configured using the aggregate command and the summary route is leaked from the local VPN instance to another VPN instance, the summary route may be selected to guide traffic forwarding due to its high priority. As a result, traffic is dropped. To prevent this issue, plan a proper mask length for the summary route.

Usage Scenario

BGP route summarization is classified as manual route summarization or automatic route summarization. The aggregate command is used to implement manual route summarization, which takes precedence over automatic route summarization. The aggregate ipv4-address { mask | mask-length } command configures BGP to summarize specific routes in the local BGP routing table and then advertise all specific routes as well as the summary route. The generated summary route inherits the Origin attribute from the specific routes if they have the same Origin attribute. If the specific routes have different Origin attributes, the summary route selects one as its own from these Origin attributes in descending order of preference: incomplete > egp > igp. In addition, the summary route carries the atomic-aggregate attribute. Except the Origin and atomic-aggregate attributes, the summary route does not carry any other attributes of the specific routes.

To generate a summary route that can be used to detect a routing loop, you can specify the as-set parameter when running the aggregate command. The summary route inherits the attributes such as Origin, AS_Path (used for loop prevention), community, and large-community from the specific routes. The summary route also carries the community attributes of all its original specific routes. If the number of community attributes carried in the specific routes being summarized exceeds 255, route summarization stops, and the routes that fail to participate in summarization are still advertised as specific routes. Exercise caution to use this parameter if a large number of AS_Path lists are involved in route summarization. This is because frequent changes in the specific routes may cause route flapping.

If detail-suppressed is specified in the command, the summarized route is advertised, but specific routes are not. The summarized route carries the atomic-aggregate attribute, not the community attributes of specific routes.

If suppress-policy is specified in the command, specified routes are not advertised. The if-match clause of route-policy can be used to filter the routes, and only the routes matching the policy will be suppressed. The peer route-policy command can also be used to filter routes and prevent unwanted routes from being advertised to peers.

If origin-policy is specified in the command, only the routes matching route-policy are summarized.

If attribute-policy is specified in the command, attributes can be set for the summarized route. If the AS_Path attribute is set in the policy using the apply as-path command and as-set is set in the aggregate command, the AS_Path attribute in the policy does not take effect. The peer route-policy command can also be used to set attributes for a summarized route.

Configuration Impact

If detail-suppressed is configured in the command, the advertisement of specific routes will be suppressed. If suppress-policy is configured in the command, the advertisement of the specific routes that match the policy will be suppressed.

Precautions

If the undo aggregate command is run, the system will match routes against the configured attribute-policy, origin-policy, suppress-policy, as-set, or detail-suppressed. If no parameter is configured, the system will fail to execute the undo aggregate command.

After a summary route is configured using the aggregate command and the summary route is leaked from the local VPN instance to another VPN instance, the summary route may be selected to guide traffic forwarding due to its high priority. As a result, traffic is dropped. To prevent this issue, plan a proper mask length for the summary route.

Usage Scenario

BGP route summarization is classified as manual route summarization or automatic route summarization. The aggregate command is used to implement manual route summarization, which takes precedence over automatic route summarization. The aggregate ipv4-address { mask | mask-length } command configures BGP to summarize specific routes in the local BGP routing table and then advertise all specific routes as well as the summary route. The generated summary route inherits the Origin attribute from the specific routes if they have the same Origin attribute. If the specific routes have different Origin attributes, the summary route selects one as its own from these Origin attributes in descending order of preference: incomplete > egp > igp. In addition, the summary route carries the atomic-aggregate attribute. Except the Origin and atomic-aggregate attributes, the summary route does not carry any other attributes of the specific routes.

To generate a summary route that can be used to detect a routing loop, you can specify the as-set parameter when running the aggregate command. The summary route inherits the attributes such as Origin, AS_Path (used for loop prevention), community, and large-community from the specific routes. The summary route also carries the community attributes of all its original specific routes. If the number of community attributes carried in the specific routes being summarized exceeds 255, route summarization stops, and the routes that fail to participate in summarization are still advertised as specific routes. Exercise caution to use this parameter if a large number of AS_Path lists are involved in route summarization. This is because frequent changes in the specific routes may cause route flapping.

If detail-suppressed is specified in the command, the summarized route is advertised, but specific routes are not. The summarized route carries the atomic-aggregate attribute, not the community attributes of specific routes.

If suppress-policy is specified in the command, specified routes are not advertised. The if-match clause of route-policy can be used to filter the routes, and only the routes matching the policy will be suppressed. The peer route-policy command can also be used to filter routes and prevent unwanted routes from being advertised to peers.

If origin-policy is specified in the command, only the routes matching route-policy are summarized.

If attribute-policy is specified in the command, attributes can be set for the summarized route. If the AS_Path attribute is set in the policy using the apply as-path command and as-set is set in the aggregate command, the AS_Path attribute in the policy does not take effect. The peer route-policy command can also be used to set attributes for a summarized route.

Configuration Impact

If detail-suppressed is configured in the command, the advertisement of specific routes will be suppressed. If suppress-policy is configured in the command, the advertisement of the specific routes that match the policy will be suppressed.

Precautions

If the undo aggregate command is run, the system will match routes against the configured attribute-policy, origin-policy, suppress-policy, as-set, or detail-suppressed. If no parameter is configured, the system will fail to execute the undo aggregate command.

After a summary route is configured using the aggregate command and the summary route is leaked from the local VPN instance to another VPN instance, the summary route may be selected to guide traffic forwarding due to its high priority. As a result, traffic is dropped. To prevent this issue, plan a proper mask length for the summary route.

Usage Scenario

BGP route summarization is classified as manual route summarization or automatic route summarization. The aggregate command is used to implement manual route summarization, which takes precedence over automatic route summarization. The aggregate ipv4-address { mask | mask-length } command configures BGP to summarize specific routes in the local BGP routing table and then advertise all specific routes as well as the summary route. The generated summary route inherits the Origin attribute from the specific routes if they have the same Origin attribute. If the specific routes have different Origin attributes, the summary route selects one as its own from these Origin attributes in descending order of preference: incomplete > egp > igp. In addition, the summary route carries the atomic-aggregate attribute. Except the Origin and atomic-aggregate attributes, the summary route does not carry any other attributes of the specific routes.

To generate a summary route that can be used to detect a routing loop, you can specify the as-set parameter when running the aggregate command. The summary route inherits the attributes such as Origin, AS_Path (used for loop prevention), community, and large-community from the specific routes. The summary route also carries the community attributes of all its original specific routes. If the number of community attributes carried in the specific routes being summarized exceeds 255, route summarization stops, and the routes that fail to participate in summarization are still advertised as specific routes. Exercise caution to use this parameter if a large number of AS_Path lists are involved in route summarization. This is because frequent changes in the specific routes may cause route flapping.

If detail-suppressed is specified in the command, the summarized route is advertised, but specific routes are not. The summarized route carries the atomic-aggregate attribute, not the community attributes of specific routes.

If suppress-policy is specified in the command, specified routes are not advertised. The if-match clause of route-policy can be used to filter the routes, and only the routes matching the policy will be suppressed. The peer route-policy command can also be used to filter routes and prevent unwanted routes from being advertised to peers.

If origin-policy is specified in the command, only the routes matching route-policy are summarized.

If attribute-policy is specified in the command, attributes can be set for the summarized route. If the AS_Path attribute is set in the policy using the apply as-path command and as-set is set in the aggregate command, the AS_Path attribute in the policy does not take effect. The peer route-policy command can also be used to set attributes for a summarized route.

Configuration Impact

If detail-suppressed is configured in the command, the advertisement of specific routes will be suppressed. If suppress-policy is configured in the command, the advertisement of the specific routes that match the policy will be suppressed.

Precautions

If the undo aggregate command is run, the system will match routes against the configured attribute-policy, origin-policy, suppress-policy, as-set, or detail-suppressed. If no parameter is configured, the system will fail to execute the undo aggregate command.

After a summary route is configured using the aggregate command and the summary route is leaked from the local VPN instance to another VPN instance, the summary route may be selected to guide traffic forwarding due to its high priority. As a result, traffic is dropped. To prevent this issue, plan a proper mask length for the summary route.

Usage Scenario

To prevent traffic that does not match the IPv4 prefix filter from being imported to the local device, run this command to configure the local device to advertise default routes to the peer device based on the IPv4 prefix filter. This saves bandwidth resources. For details, see Configuration > IP Routing > BGP Configuration > Configuring BGP to Summarize Default Routes.

Prerequisites

An IPv4 prefix list has been configured using the ip ip-prefix command.

Precautions

The number of entries in the IPv4 prefix list specified in the aggregate default-route command cannot exceed 200.

Usage Scenario

To prevent traffic that does not match the IPv4 prefix filter from being imported to the local device, run this command to configure the local device to advertise default routes to the peer device based on the IPv4 prefix filter. This saves bandwidth resources. For details, see Configuration - IP Routing - BGP Configuration - Configuring BGP to Summarize Default Routes.

Prerequisites

An IPv4 prefix list has been configured using the ip ip-prefix command.

Precautions

The number of entries in the IPv4 prefix list specified in the aggregate default-route command cannot exceed 200.

Usage Scenario

To prevent traffic that does not match the IPv4 prefix filter from being imported to the local device, run the ipv4 prefix-filter default-route command to configure the local device to advertise default routes to the peer device based on the IPv4 prefix filter. This saves bandwidth resources. For details, see Configuration > IP Routing > BGP4+ Configuration > Configuring BGP4+ to Summarize Default Routes.

Prerequisites

An IPv6 prefix list has been configured using the ip ipv6-prefix command.

Precautions

The number of entries in the IPv6 prefix list specified in the aggregate default-route command cannot exceed 200.

Usage Scenario

To prevent traffic that does not match the IPv4 prefix filter from being imported to the local device, run this command to configure the local device to advertise default routes to the peer device based on the IPv4 prefix filter. This saves bandwidth resources. For details, see Configuration > IP Routing > BGP Configuration > Configuring BGP to Summarize Default Routes.

Prerequisites

An IPv4 prefix list has been configured using the ip ip-prefix command.

Precautions

The number of entries in the IPv4 prefix list specified in the aggregate default-route command cannot exceed 200.

Usage Scenario

To prevent traffic that does not match the IPv4 prefix filter from being imported to the local device, run the ipv4 prefix-filter default-route command to configure the local device to advertise default routes to the peer device based on the IPv4 prefix filter. This saves bandwidth resources. For details, see Configuration > IP Routing > BGP4+ Configuration > Configuring BGP4+ to Summarize Default Routes.

Prerequisites

An IPv6 prefix list has been configured using the ip ipv6-prefix command.

Precautions

The number of entries in the IPv6 prefix list specified in the aggregate default-route command cannot exceed 200.

Usage Scenario

Precautions

Usage Scenario

Prerequisites

If a BGP peer or a BGP peer group has been configured in the VPN instance, delete the configuration of the BGP peer or peer group before configuring or deleting an AS number.

Precautions

If a VPN instance has been configured with an AS number, no confederation can be configured for the VPN instance. When configuring a confederation, you cannot configure an independent AS number for a VPN instance.

The AS number configured in the VPN instance view cannot be the same as the AS number configured in the BGP view.

In the YANG management mode of BGP, the configuration is not allowed. To configure an AS number for the VPN instance IPv4 address family, run the as-number ipv4 ipv4-as command in the BGP-VPN instance view.

Usage Scenario

Prerequisites

If a BGP peer or a BGP peer group has been configured in the VPN instance, delete the configuration of the BGP peer or peer group before configuring or deleting an AS number.

Precautions

If a VPN instance has been configured with a separate AS number, no confederation can be configured for the VPN instance. When a confederation is configured, no separate AS number can be configured in the VPN instance.

The AS number configured in the VPN instance cannot be the same as the AS number configured in the BGP view.

When a 4-byte AS number is configured for BGP, OSPF does not support automatic tag-based loop prevention.

Usage Scenario

Prerequisites

If a BGP peer or a BGP peer group has been configured in the VPN instance, delete the configuration of the BGP peer or peer group before configuring or deleting an AS number.

Precautions

1. If an independent VPN instance has been configured with an AS number, no confederation can be configured for the VPN instance. A VPN instance configured with BGP confederation cannot be configured with an AS number.
2. The independent AS number configured in the VPN instance view cannot be the same as the AS number configured in the BGP view.
3. The AS number of the BGP VPN instance address family cannot coexist with the AS number of the BGP VPN instance.
4. If a peer or peer group exists, the AS number of the BGP VPN instance cannot be changed.
5. After an AS number is configured for a BGP VPN instance, the peers in the BGP VPN instance view can be enabled only in the IPv4 or IPv6 address family of the VPN instance.

Usage Scenario

Prerequisites

If a BGP peer or a BGP peer group has been configured in the VPN instance, delete the configuration of the BGP peer or peer group before configuring or deleting an AS number.

Precautions

1. If an independent VPN instance has been configured with an AS number, no confederation can be configured for the VPN instance. A VPN instance configured with BGP confederation cannot be configured with an AS number.
2. The independent AS number configured in the VPN instance view cannot be the same as the AS number configured in the BGP view.
3. The AS number of the BGP VPN instance address family cannot coexist with the AS number of the BGP VPN instance.
4. If a peer or peer group exists, the AS number of the BGP VPN instance cannot be changed.
5. After an AS number is configured for a BGP VPN instance, the peers in the BGP VPN instance view can be enabled only in the IPv4 or IPv6 address family of the VPN instance.

Usage Scenario

Prerequisites

If a BGP peer or a BGP peer group has been configured in the VPN instance, delete the configuration of the BGP peer or peer group before configuring or deleting an AS number.

Precautions

If a VPN instance has been configured with an independent AS number, no confederation can be configured. When configuring a confederation, you cannot configure an independent AS number for a VPN instance.

The independent AS number configured in the VPN instance view cannot be the same as the AS number configured in the BGP view.

This command cannot be configured in the BGP YANG management mode. To configure an independent AS number for the VPN instance IPv6 address family, run the as-number ipv6 ipv6-as command in the BGP-VPN instance view.

Usage Scenario

Prerequisites

If a BGP peer or a BGP peer group has been configured in the VPN instance, delete the configuration of the BGP peer or peer group before configuring or deleting an AS number.

Precautions

If a VPN instance has been configured with a separate AS number, no confederation can be configured for the VPN instance. When configuring a confederation, you cannot configure a separate AS number in the VPN instance.

The AS number configured in a VPN instance must be different from the AS number configured in the BGP view.

This command cannot be configured in the YANG management mode of BGP. To configure a separate AS number for the VPN instance IPv4 address family, run the as-number ipv4 ipv4-as command in the BGP-VPN instance view.

When a 4-byte AS number is configured for BGP, OSPF does not support automatic tag-based loop prevention.

Usage Scenario

This command is used to limit the maximum number of AS numbers in the AS_Path attribute only when the AS_Path attribute is reconstructed, routes are summarized to generate new routes, routes are newly learned from peers, or routes are advertised to peers.

Configuration Impact

After the as-path-limit command is configured, the device checks whether the number of AS numbers in the AS_Path attribute of the routes to be received or sent exceeds the upper limit. The learned routes are not checked. If the number of AS numbers exceeds the upper limit, the device discards the route. Therefore, if the maximum number of AS numbers in the AS_Path attribute is set too small, routes will be lost.

Usage Scenario

As networks continue to develop, services, such as voice, online video, and financial services, pose higher requirements for real-time transmission. Primary and backup links are typically deployed on a network to ensure the stability of these services. In traditional forwarding mode, the device selects the optimal route from multiple routes to the same destination and delivers the route to the FIB table to guide data forwarding. If the optimal route fails, the device must wait for route convergence to be completed, after which the device reselects an optimal route and delivers it to the FIB table to restore services. This process leads to long service interruption, resulting in a failure to meet service requirements.

After BGP Auto FRR is enabled on a device, the device selects the optimal route from the routes that are bound for the same destination network. In addition, the device automatically adds information about the suboptimal route to the backup forwarding entries of the optimal route. If the primary link fails, the device quickly switches traffic to the backup link. The switchover does not depend on route convergence and can be performed within sub-seconds, greatly reducing service interruption time. For BGP labeled routes, FRR is supported only on the ingress and transit nodes.

Usage Scenario

As networks continue to develop, services, such as voice, online video, and financial services, pose higher requirements for real-time transmission. Primary and backup links are typically deployed on a network to ensure the stability of these services. In traditional forwarding mode, the device selects the optimal route from multiple routes to the same destination and delivers the route to the FIB table to guide data forwarding. If the optimal route fails, the device must wait for route convergence to be completed, after which the device reselects an optimal route and delivers it to the FIB table to restore services. This process leads to long service interruption, resulting in a failure to meet service requirements.

After BGP Auto FRR is enabled on a device, the device selects the optimal route from the routes that are bound for the same destination network. In addition, the device automatically adds information about the suboptimal route to the backup forwarding entries of the optimal route. If the primary link fails, the device quickly switches traffic to the backup link. The switchover does not depend on route convergence and can be performed within sub-seconds, greatly reducing service interruption time. For BGP labeled routes, FRR is supported only on the ingress and transit nodes.