Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring Route Aggregation

Understanding Route Aggregation

The route aggregation methodology helps minimize the number of routing tables in an IP network by consolidating selected multiple routes into a single route advertisement. This approach is in contrast to non-aggregation routing, in which every routing table contains a unique entry for each route. The aggregation methodology does not help reduce the size of the routing-table on the router that does the aggregation. When you configure an export policy that only advertises the aggregate but not the contributing routes anymore, you then have the aggregation effect on the routers that receive updates.

An aggregate route becomes active when it has one or more contributing routes. A contributing route is an active route that is a more specific match for the aggregate destination. For example, for the aggregate destination 192.168.0.0/16, routes to 192.168.192.0/19 and 192.168.67.0/24 are contributing routes, but routes to 192.168.0.0./8 and 192.168.0.0/16 are not.

A route can only contribute to a single aggregate route. However, an active aggregate route can recursively contribute to a less-specific matching aggregate route. For example, an aggregate route to the destination 192.168.0.0/16 can contribute to an aggregate route to 192.168.0.0/13.

When an aggregate route becomes active, it is installed in the routing table with the following information:

  • Reject next hop—If a more-specific packet does not match a more-specific route, the packet is rejected and an ICMP unreachable message is sent to the packet’s originator.

  • Metric value as configured with the aggregate statement.

  • Preference value that results from the policy filter on the primary contributor, if a filter is specified.

  • AS path as configured in the aggregate statement, if any. Otherwise, the path is computed by aggregating the paths of all contributing routes.

  • Community as configured in the aggregate statement, if any is specified.

    Note:

    You can configure only one aggregate route for each destination prefix.

To configure aggregate routes in the default routing table (inet.0), include the aggregate statement:

To configure aggregate routes in one of the other routing tables, or to explicitly configure aggregate routes in the default routing table (inet.0), include the aggregate statement:

Note:

You cannot configure aggregate routes for the IPv4 multicast routing table (inet.1) nor the IPv6 multicast routing table (inet6.1).

The aggregate statement consists of two parts:

  • defaults—(Optional) Here you specify global aggregate route options. These are treated as global defaults and apply to all the aggregate routes you configure in the aggregate statement.

  • route—Here you configure individual aggregate routes. In this part of the aggregate statement, you optionally can configure aggregate route options. These options apply to the individual destination only and override any options you configured in the defaults part of the aggregate statement.

When you configure an individual aggregate route in the route part of the aggregate statement, specify the destination of the route (in route destination-prefix) in one of the following ways:

  • network/mask-length, where network is the network portion of the IP address and mask-length is the destination prefix length.

  • default if this is the default route to the destination. This is equivalent to specifying an IP address of 0.0.0.0/0.

After you have configured aggregate routes, you can have a protocol advertise the routes by configuring a policy that is then exported by a routing protocol.

You can associate a routing policy when configuring an aggregate route’s destination prefix in the routes part of the aggregate statement. Doing so provides the equivalent of an import routing policy filter for the destination prefix. That is, each potential contributor to an aggregate route, along with any aggregate options, is passed through the policy filter. The policy then can accept or reject the route as a contributor to the aggregate route and, if the contributor is accepted, the policy can modify the default preferences.

The following algorithm is used to compare two aggregate contributing routes in order to determine which one is the primary or preferred contributor:

  1. Compare the protocol’s preferences of the contributing routes. The lower the preference, the better the route. This is similar to the comparison that is done while determining the best route for the routing table.

  2. Compare the protocol’s preferences2 of the contributing routes. The lower preference2 value is better. If only one route has preferences2, then this route is preferred.

  3. The preference values are the same. Proceed with a numerical comparison of the prefix values.

    1. The primary contributor is the numerically smallest prefix value.

    2. If the two prefixes are numerically equal, the primary contributor is the route that has the smallest prefix length value.

  4. At this point, the two routes are the same. The primary contributor does not change. An additional next hop is available for the existing primary contributor.

A rejected contributor still can contribute to a less specific aggregate route. If you do not specify a policy filter, all candidate routes contribute to an aggregate route.

To associate a routing policy with an aggregate route, include the policy statement when configuring the route:

In the defaults and route parts of the aggregate statement, you can specify aggregate-options, which define additional information about aggregate routes that is included with the route when it is installed in the routing table. All aggregate options are optional. Aggregate options that you specify in the defaults part of the aggregate statement are treated as global defaults and apply to all the aggregate routes you configure in the aggregate statement. Aggregate options that you specify in the route part of the aggregate statement override any global aggregate options and apply to that destination only.

To configure aggregate route options, include one or more of them in the defaults or route part of the aggregate statement:

Configuring a Metric Value for Aggregate Routes

You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2, metric3, and metric4 by including one or more of the following statements:

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

In the type option, you can specify the type of route.

Configuring a Preference Value for Aggregate Routes

By default, aggregate routes have a preference value of 130. If the routing table contains a dynamic route to a destination that has a better (lower) preference value than this, the dynamic route is chosen as the active route and is installed in the forwarding table.

To modify the default preference value, specify a primary preference value (preference). You also can specify secondary preference value (preference2); and colors, which are even finer-grained preference values (color and color2). To do this, include one or more of the following statements:

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

The preference value can be a number in the range from 0 through 4,294,967,295 (232 – 1) with a lower number indicating a more preferred route. For more information about preference values, see Route Preferences Overview.

In the type option, you can specify the type of route.

Configuring the Next Hop for Aggregate Routes

By default, when aggregate routes are installed in the routing table, the next hop is configured as a reject route. That is, the packet is rejected and an ICMP unreachable message is sent to the packet’s originator.

When you configure an individual route in the route part of the aggregate statement, or when you configure the defaults for aggregate routes, you can specify a discard next hop. This means that if a more specific packet does not match a more specific route, the packet is rejected and a reject route for this destination is installed in the routing table, but ICMP unreachable messages are not sent.

Being able to discard next hops allows you to originate a summary route, which can be advertised through dynamic routing protocols, and allows you to discard received traffic that does not match a more specific route than the summary route. To discard next hops, include the discard option:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Associating BGP Communities with Aggregate Routes

By default, no BGP community information is associated with aggregate routes. To associate community information with the routes, include the community option:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. community-value is the community identifier and can be a number in the range from 0 through 65,535.

community-ids is one or more community identifiers for either communities or extended communities.

The format for community identifiers is:

as-number is the AS number and can be a value in the range from 1 through 65,534.

You also can specify community-ids for communities as one of the following well-known community names, which are defined in RFC 1997:

  • no-export—Routes containing this community name are not advertised outside a BGP confederation boundary.

  • no-advertise—Routes containing this community name are not advertised to other BGP peers.

  • no-export-subconfed—Routes containing this community name are not advertised to external BGP peers, including peers in other members’ ASs inside a BGP confederation.

You can explicitly exclude BGP community information with an aggregate route using the none option. Include none when configuring an individual route in the route portion of the aggregate statement to override a community option specified in the defaults portion of the statement.

Note:

Extended community attributes are not supported at the [edit routing-options] hierarchy level. You must configure extended communities at the [edit policy-options] hierarchy level. For information about configuring extended communities information, see the “Configuring the Extended Communities Attribute” section in the Routing Policies, Firewall Filters, and Traffic Policers User Guide. For information about configuring 4-byte AS numbers and extended communities, see Using 4-Byte Autonomous System Numbers in BGP Networks.

Associating AS Paths with Aggregate Routes

By default, the AS path for aggregate routes is built from the component routes. To manually specify the AS path and associate AS path information with the routes, include the as-path option:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

as-path is the AS path to include with the route. It can include a combination of individual AS path numbers and AS sets. Enclose sets in brackets ( [ ] ). The first AS number in the path represents the AS immediately adjacent to the local AS. Each subsequent number represents an AS that is progressively farther from the local AS, heading toward the origin of the path.

Note:

In Junos OS Release 9.1 and later, the numeric AS range is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. For the AS number, you can configure a value from 1 through  4,294,967,295. All releases of Junos OS support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 (this is a subset of the 4-byte range).

In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: <16-bit high-order value in decimal>.<16-bit low-order value in decimal>. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation format.

You also can specify the AS path using the BGP origin attribute, which indicates the origin of the AS path information:

  • egp—Path information originated in another AS.

  • igp—Path information originated within the local AS.

  • incomplete—Path information was learned by some other means.

To attach the BGP ATOMIC_AGGREGATE path attribute to the aggregate route, specify the atomic-aggregate option. This path attribute indicates that the local system selected a less specific route rather than a more specific route.

To attach the BGP AGGREGATOR path attribute to the aggregate route, specify the aggregator option. When using this option, you must specify the last AS number that formed the aggregate route (encoded as two octets), followed by the IP address of the BGP system that formed the aggregate route.

Note:

Starting with Junos OS 13.2R1, a BGP route is hidden when the AS path of an aggregate route—built from contributing routes— is more than half of the maximum BGP packet size (4096 bytes). Such AS paths have the OverflowASPathSize flag set for them. If you would like to leak such a BGP route, whose AS path length can overflow, we recommend to add the AS path statically in the default route configuration. For example:

Including AS Numbers in Aggregate Route Paths

By default, all AS numbers from all contributing paths are included in the aggregate route’s path. To include only the longest common leading sequences from the contributing AS paths, include the brief option when configuring the route. If doing this results in AS numbers being omitted from the aggregate route, the BGP ATOMIC_ATTRIBUTE path attribute is included with the aggregate route.

To explicitly have all AS numbers from all contributing paths be included in the aggregate route’s path, include the full option when configuring routes. Include this option when configuring an individual route in the route portion of the aggregate statement to override a retain option specified in the defaults portion of the statement.

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Configuring a Tag Value for Aggregate Routes

By default, no tag values are associated with aggregate routes. You can specify a tag value by including the tag option:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Controlling Retention of Inactive Aggregate Routes in the Routing and Forwarding Tables

Static routes are only removed from the routing table if the next hop becomes unreachable, which happens if there are no contributing routes. To have an aggregate route remain continually installed in the routing and forwarding tables, include the passive option when configuring the route:

Routes that have been configured to remain continually installed in the routing and forwarding tables are marked with reject next hops when they are inactive.

To explicitly remove aggregate routes when they become inactive, include the active option when configuring routes. Include this option when configuring an individual route in the route portion of the aggregate statement to override a passive option specified in the defaults portion of the statement.

Example: Summarizing Static Routes Through Route Aggregation

This example shows how to summarize routes by configuring aggregate routes.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

In this example:

  • Device R1 is connected to customer networks 10.200.1.0/24 and 10.200.2.0/24.

    For demonstration purposes, these routes are represented in this example as loopback interfaces on Device R1.

  • Device R1 has a static default route to reach the ISP network (10.0.45.0).
  • Device R2 has static routes configured to reach Device R1’s customer networks (10.200.1.0/24 and 10.200.2.0/24).
  • Device R2 also has a routing policy configured to advertise all static routes to its neighbor, Device R3.
  • When Device R3 sends information about these routes (10.200.1.0/24 and 10.200.2.0/24) to Device ISP, the information is summarized as a single aggregate route (10.200.0.0/16).
  • Device R2 and Device R3 share an IBGP session and have OSPF as the IGP.
  • Device ISP injects a default route into AS 64501.

This example shows the configuration for all of the devices and the step-by-step configuration on Device R3.

Topology

Figure 1 shows the sample network.

Figure 1: Aggregate Route Advertised to an ISPAggregate Route Advertised to an ISP

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R1

Device R2

Device R3

Device ISP

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R3:

  1. Configure the device interfaces.

  2. Configure the AS number.

  3. Configure an EBGP session with the ISP device.

  4. Configure an IBGP session with Device R2.

  5. Configure OSPF as the IGP.

  6. Configure the aggregate route for the customer network routes.

  7. Configure a routing policy to advertise the aggregate route.

    The first term in this policy advertises the aggregate route. The second term prevents more specific routes from being advertised.

  8. Configure a routing policy to report Device R3 as the next hop as a result of participating in the EBGP session with Device ISP.

  9. Apply the aggregate route policy to the EBGP session with Device ISP.

  10. Apply the next-hop-self policy to the IBGP session with Device R2.

  11. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying That Device R3 Has the Expected Routes

Purpose

Confirm that Device R3 has the advertised static routes from Device R2.

Action
Meaning

The output shows that Device R3 has learned the static routes configured on Device R2 to reach Device R1’s customer networks (10.200.1.0/24 and 10.200.2.0/24) through IBGP peering.

Verifying That Device R3 Advertises the Aggregate Route to Device ISP

Purpose

Make sure that Device R3 does not send the specific static routes and only sends the summarized aggregate route.

Action
Meaning

The output shows that Device R3 sends only the summarized route to Device ISP.

Verifying End-to-End Connection

Purpose

Confirm end-to-end connection from the customer network on Device R1 to Device ISP.

Action
Meaning

The output shows a successful ping verifying the reachability to Device ISP from customer network 10.200.1.1.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
13.2R1
Starting with Junos OS 13.2R1, a BGP route is hidden when the AS path of an aggregate route—built from contributing routes— is more than half of the maximum BGP packet size (4096 bytes).