Configuring Static, Aggregate, and Generated Routes | Juniper Networks Field Guide and Reference

The router uses dynamic routes to learn how to reach network destinations. Dynamic routes are determined from the information exchanged by the routing protocols and, as the name implies, the routes might change as network conditions change and these changes are discovered by the routing protocols. You can configure static (nonchanging) routes to some network destinations. The router uses static routes when it does not have a route to a destination that has a better (lower) preference value, when it cannot determine the route to a destination, or when it is forwarding unroutable packets. A static route is installed in the routing table only when the route is active; that is, the list of next-hop routers configured for that route contains at least one next hop on an operational interface.

To configure static routes in the default routing table ( inet.0 ), include the static statement at the [edit routing-options] hierarchy level. To configure static routes in one of the other routing tables, or to explicitly configure static routes in the default route table ( inet.0 ), include the static statement at the [edit routing-options rib routing-table-name ] hierarchy level.

 static {    defaults {  static-options  ;   }   rib-group  group-name  ;   route  destination-prefix  {     lsp-next-hop  lsp-name  {       metric  metric  ;       preference  preference  ;     }  next-hop  ;     qualified-next-hop  address  {       metric  metric  ;       preference  preference  ;     }  static-options  ;   } }

Route aggregation allows you to combine groups of routes with common addresses into a single entry in the routing table. This decreases the size of the routing table as well as the number of route advertisements sent by the router. 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 128.100.0.0/16 , routes to 128.100.192.0/19 and 128.100.67.0/24 are contributing routes, but routes to 128.0.0.0./8 , 128.0.0.0/16 , and 128.100.0.0/16 are not.

A route can contribute only 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 128.100.0.0/16 can contribute to an aggregate route to 128.96.0.0/13 .

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

Reject next hop ”This means that 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 was specified ”Otherwise, use the preference value as configured in the aggregate statement.
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.

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 at the [edit routing-options] hierarchy level. 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 at the [edit routing-options rib routing-table-name ] hierarchy level:

 aggregate {    defaults {  aggregate-options  ;   }   route  destination-prefix  {     policy  policy-name  ;  aggregate-options  ;   } }

Generated routes are used as the route of last resort. A packet is forwarded to the route of last resort when the routing tables have no information about how to reach that packet's destination. One use of these routes is to generate a default route to use if the routing table contains a route from a peer on a neighboring backbone. A generated 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 generated destination. For example, for the destination 128.100.0.0/16 , routes to 128.100.192.0/19 and 128.100.67.0/24 are contributing routes, but routes to 128.0.0.0./8 , 128.0.0.0/16 , and 128.100.0.0/16 are not.

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

By default, when generated routes are installed in the routing table, the next hop is chosen from the primary contributing route. You can configure only one generated route for each destination prefix.

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

 [edit routing-options]  generate {   defaults {  generate-options  ;   }   route  destination-prefix  {     policy  policy-name  ;  generate-options  ;   } }

The static , aggregate , and generated statements consist of two parts :

defaults ” Specify global options. These are treated as global defaults and apply to all the static, aggregate, or generated routes you configure.
route ” Configure individual static, aggregate, or generated routes.

Specifying the Route's Destination

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

network / masklen , where network is the network portion of the IP address, and masklen 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 .

Specifying Route Options

In the defaults and route parts of the static , aggregate , and generated statements, you can specify options that define additional information about routes that is included with the route when it is installed in the routing table. Options in the defaults part of the statement are treated as global defaults and apply to all configured routes. Options in the route part of the statement override any global options and apply to that destination only.

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

 [edit routing-options]  static {   defaults {     (active  passive);     as-path <  as-path  > <origin (egp  igp  incomplete)>       <atomic-aggregate> <aggregator  as-number in-address>  ;     community [  community-ids  ];     (install  no-install);     metric  metric  <type  type  >;     (preference  preference2  color  color2)  preference  <type  type  >;     (readvertise  no-readvertise);     (no-retain  retain);     (tag  tag2)  string  ;   }   route  destination-prefix  {     (active  passive);     as-path <  as-path  > <origin (egp  igp  incomplete)>       <atomic-aggregate> <aggregator  as-number in-address>  ;     community [  community-ids  ];     (install  no-install);     metric  metric  <type  type  >;     (preference  preference2  color  color2)  preference  <type  type  >;     (readvertise  no-readvertise);     (resolve  no-resolve);     (no-retain  retain);     (tag  tag2)  string  ;   } }

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;     (full  brief);     (metric  metric2  metric3  metric4) metric <type type>;     (preference  preference2  color  color2) preference <type type>;     (tag  tag2) string;   } }

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

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

To associate a metric value with a static route, include the metric statement. In the type option, specify the type of route. For OSPF, when routes are exported to OSPF, type 1 routes are advertised in type 1 externals, and routes of any other type are advertised in type 2 externals . If a qualified-next-hop metric value is configured, the type value overrides the route metric.

 [edit routing-options static (defaults  route)]  metric  metric  <type  type  >;

For aggregate and generated 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 the following statement:

 (metric  metric2  metric3  metric4) metric <type type>;

For more information about preferences, see "Routing Protocols Concepts," on page 374.

By default, static routes have a preference value of 5, and aggregate and generated routes have a preference value of 130. To modify the default preference value, specify a primary preference value ( preference ). You also can specify a secondary preference value ( preference2 ) and colors, which are even finer-grained preference values ( color and color2 ). To do this, include the following statement. The preference value can be a number in the range 1 through 255, with a lower number indicating a more preferred route.

 (preference  preference2  color  color2)  preference  <type  type  >;

By default, no BGP community information is associated with static, aggregate, or generated routes. To associate community information with the routes, include the community statement. community-ids is one or more community or extended community identifiers.

 community [ community-ids ];

Community identifiers are defined in RFC 1997: BGP Communities Attribute.

The format for community identifiers is as-number : community-value . as-number is the autonomous system (AS) number and can be a value in the range 1 through 65,534. community-value is the community identifier and can be a number in the range 0 through 65,535. You also can specify community-ids as one of the following well-known community names :

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.

The format for extended community identifiers is type : administrator : assigned-number . type is the type of extended community and can be either a target , origin , or domain-id community. The target community identifies the destination to which the route is going. The origin community identifies where the route originated. The domain-id community identifies the OSPF domain where the route originated. administrator is the administrator. It is either an AS number or an IPv4 address prefix, depending on the type of extended community. assigned-number identifies the local provider.

By default, no AS path information is associated with static, aggregate, or generated routes. To associate AS path information with the routes, include the as-path statement:

 as-path <  as-path  > <origin (egp  igp  incomplete)>  <atomic-aggregate> <aggregator  as-number in-address>  ;

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. You also can specify the AS path using the BGP origin attribute, which indicates the origin of the AS path information:

igp ” Path information originated within the local AS
egp ” Path information originated in another AS
incomplete ” Path information learned by some other means

To attach the BGP ATOMIC_AGGREGATE path attribute to the 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 route, specify the aggregator option. You must specify the last AS number that formed the route (encoded as two octets), followed by the IP address of the BGP system that formed the route.

By default, no OSPF tag strings are associated with static, aggregate, or generated routes. You can specify up to two OSPF tag strings by including the tag and tag2 statement:

 [edit routing-options static (defaults  route)]  (tag  tag2)  string  ;

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

 brief;

To explicitly have all AS numbers from all contributing paths be included in the aggregate or generated route's path, include the full statement when configuring routes:

 full;

By default, the JUNOS software installs all active static routes into the forwarding table. To configure the software not to install active static routes into the forwarding table, include the no-install statement:

 [edit routing-options static (defaults  route)]  no-install;

Even if you configure a route so that it is not installed in the forwarding table, the route is still eligible to be exported from the routing table to other protocols. To explicitly install the routes into the forwarding table, include the install statement when configuring routes:

 [edit routing-options static (defaults  route)]  install;

By default, statically configured routes are deleted from the forwarding table when the routing protocol process shuts down normally. To have a static route remain in the forwarding table, include the retain statement when configuring the route. Doing this greatly reduces the time required to restart a system that has a large number of routes in its routing table.

 [edit routing-options static (defaults  route)]  retain;

By default, static, aggregate, and generated routes are removed from the routing and forwarding tables when they become inactive. To have the routes remain continually installed in the routing and forwarding tables, include the passive statement. 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.

 passive;

To explicitly remove static, aggregate, or generated routes when they become inactive, include the active statement:

 active;

By default, static routes are eligible to be readvertised (that is, exported) by dynamic routing protocols. To mark a static route as being ineligible for readvertisement, include the no-readvertise statement:

 [edit routing-options static (defaults  route)]  no-readvertise;

By default, static routes can point only to a directly connected next hop. To configure a route to a prefix that is not directly connected by resolving the route through the inet.0 and inet.3 routing tables, include the resolve statement:

 [edit routing-options static (defaults  route)]  resolve;

Specifying the Next Hop of the Static Route

When you configure an individual static route in the route part of the static statement, specify how to reach the destination (in next-hop ) in one of the following ways:

next-hop address ” IP address of the next hop to the destination, specified as:
- IP address of the next hop
- Interface name (for point-to-point interfaces only)
- address / interface-name to specify an IP address on an operational interface
next-table routing-table-name ” Name of the next routing table to the destination.
reject ” Do not forward packets addressed to this destination. Instead, drop the packets, send ICMP unreachable messages to the packets' originators, and install a reject route for this destination into the routing table.
discard ” Do not forward packets addressed to this destination. Instead, drop the packets, do not send ICMP unreachable messages to the packets' originators, and install a reject route for this destination into the routing table.
receive ” Cause packets to the destination to be received by the local router.

Specifying an Independent Preference for a Static Route

You can configure multiple static routes with different preferences and metrics to the same destination. The static route with the best preference, metric, and reachable next hop is chosen as the active route. This feature allows you to specify preference and metric on a next-hop basis.

To specify an independent preference for a static route, include the following statements. The preference value can be in the range 1 through 255, with a lower number indicating a more preferred route. The metric value can be in the range 1 through 65,535.

 [edit routing-options static route]  qualified-next-hop  address  {   metric  metric  ;   preference  preference  ; }

The preference and metric configured by means of this statement apply only to the qualified next hops. The qualified-next-hop preference and metric override the route preference and metric (for that specific qualified next hop), similar to how the route preference overrides the default preference and metric (for that specific route).

Specifying an LSP as the Next Hop for a Static Route

Static routes can be configured with a next hop that is a label-switched path (LSP). This is useful when implementing filter-based forwarding. To specify an LSP as the next hop and assign an independent preference and metric to this next hop, include the following statements. The preference value can be a number in the range 1 through 255, with a lower number indicating a more preferred route. The metric value can be a number in the range 1 through 65,535.

 [edit routing-options static route]  lsp-next-hop  lsp-name  {   metric  metric  ;   preference  preference  ; }

Installing a Static Route into More Than One Routing Table

To install a static route into more than one routing table, instead of configuring the same static route for each routing table, use routing table groups. To create a routing table group, include the rib-group statement at one of the following hierarchy levels:

[edit routing-options static]
[edit routing-options rib routing-table-name static]
[edit routing-instance instance-name routing-options static]
[edit routing-instance instance-name routing-options rib routing-table-name static]

To install the routing table into a configured routing table group, include the import-rib statement at the [edit routing-options rib-groups] or [edit routing-options rib routing-table-name rib-groups] hierarchy level. The first routing table you list in the import-rib statement must be the one configured in the rib-group statement.

 rib-group  group-name  {   import-rib [  routing-table-names  ] }

Configuring a Default Static Route

To configure a default static route, include the next-hop address and retain statements:

 [edit routing-options static route default]  next-hop  address  ; retain;

Propagating Static Routes into Routing Protocols

A common way to propagate static routes into the various routing protocols is to configure the routes so that the next-hop router is the loopback address (commonly, 127.0.0.1 ). However, configuring static routes in this way with the JUNOS software (by including a statement such as route address / mask-length next-hop 127.0.0.1 ) does not propagate the static routes, because the forwarding table ignores static routes whose next-hop router is the loopback address. To propagate static routes into the routing protocols, include the discard statement:

 [edit routing-options rib inet6.0 static (defaults  route)] discard;

Specifying Policy with Aggregate and Generated Routes

You can associate a routing policy when configuring an aggregate or a generated route's destination prefix in the routes part of the aggregate or generate statement. Doing so provides the equivalent of an import routing policy filter for the destination prefix. That is, each potential contributor to a generated route, along with any generate options, is passed through the policy filter. The policy can accept or reject the route as a contributor to the route, and, if the contributor is accepted, the policy can modify the default preferences. The contributor with the numerically smallest prefix becomes the most preferred, or primary, contributor. A rejected contributor still can contribute to a less specific route. If you do not specify a policy filter, all candidate routes contribute to a route.

To associate a routing policy with an aggregate or a generated route, include the policy statement:

 policy  policy-name  ;