TechLibrary

Navigation Back up to About Overview

Configuring Aggregate Route Options

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:

[edit]routing-options {aggregate {(defaults | route) {(active | passive);as-path <as-path> <origin (egp | igp | incomplete)> <atomic-aggregate> <aggregator as-number in-address>;community [ community-ids ];discard;(brief | full);(metric | metric2 | metric3 | metric4) metric <type type>;(preference | preference2 | color | color2) preference <type type>;tag string;}}}

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

The following sections explain how to configure aggregate route options:

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:

aggregate (defaults | route) {(metric | metric2 | metric3 | metric4) metric <type type>;}

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:

aggregate (defaults | route) {(preference | preference2 | color | color2) preference <type type>;}

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:

aggregate (defaults | route) {community [ community-ids ];}

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:community-value

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 Junos OS Policy Framework Configuration Guide. For information about configuring 4-byte AS numbers and extended communities, see Configuring 4-Byte AS Numbers and BGP Extended Community Attributes in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview.

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:

aggregate (defaults | route) {as-path <as-path> <origin (egp | igp | incomplete)> <atomic-aggregate> <aggregator as-number in-address>;}

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 the 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.

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.

aggregate (defaults | route) {brief;}

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.

aggregate (defaults | route) {full;}

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

Configuring an OSPF Tag String for Aggregate Routes

By default, no OSPF tag strings are associated with aggregate routes. You can specify an OSPF tag string by including the tag option:

aggregate (defaults | route) {tag string;}

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:

aggregate (defaults | route) {passive;}

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 retain option specified in the defaults portion of the statement.

aggregate (defaults | route) {active;}

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


Published: 2010-10-11