Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Static Route Preferences and Qualified Next Hops

 

Understanding Static Route Preferences and Qualified Next Hops

A static route destination address can have multiple next hops associated with it. In this case, multiple routes are inserted into the routing table, and route selection must occur. Because the primary criterion for route selection is the route preference, you can control the routes that are used as the primary route for a particular destination by setting the route preference associated with a particular next hop. The routes with a lower route preference are always used to route traffic. When you do not set a preferred route, the Junos OS chooses in a random fashion one of the next-hop addresses to install into the forwarding table.

In general, the default properties assigned to a static route apply to all the next-hop addresses configured for the static route. If, however, you want to configure two possible next-hop addresses for a particular route and have them treated differently, you can define one as a qualified next hop.

Qualified next hops allow you to associate one or more properties with a particular next-hop address. You can set an overall preference for a particular static route and then specify a different preference for the qualified next hop. For example, suppose two next-hop addresses (10.10.10.10 and 10.10.10.7) are associated with the static route 192.168.47.5/32. A general preference is assigned to the entire static route, and then a different preference is assigned to only the qualified next-hop address 10.10.10.7. For example:

In this example, the qualified next hop 10.10.10.7 is assigned the preference 6, and the next-hop 10.10.10.10 is assigned the preference 5.

Note

The preference and metric options in the [edit route route qualified-next-hop] hierarchy only apply to the qualified next hops. The qualified next-hop preference and metric override the route preference and metric for that specific qualified next hop only, similar to how the route preference overrides the default preference and metric (for that specific route).

Note

Starting in Junos OS Release 15.1R4, the router no longer supports a configuration where a static route points to a next hop that is tied to a subscriber. Typically, this might occur when RADIUS assigns the next hop with the Framed-IP-Address attribute. An alternative to this misconfiguration is to have the RADIUS server provide a Framed-Route attribute that matches the static route.

Example: Configuring Static Route Preferences and Qualified Next Hops to Control Static Route Selection

This example shows how to control static route selection.

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

In this example, the static route 192.168.47.0/24 has two possible next hops. Because one link has higher bandwidth, this link is the preferred path. To enforce this preference, the qualified-next-hop statement is included in the configuration on both devices. See Figure 1.

Figure 1: Controlling Static Route Selection
Controlling
Static Route Selection

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 B in Provider Network

Device D in Customer Network

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To control static route selection:

  1. On Device B, configure the interfaces.
  2. On Device B, configure a static route to the customer network.
  3. On Device B, configure a backup route to the customer network.
  4. On Device D, configure the interfaces.
  5. On Device D, configure a static default route to external networks.
  6. On Device D, configure a backup static default route to external networks.

Results

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

If you are done configuring the devices, enter commit from configuration mode on both devices.

Verification

Confirm that the configuration is working properly.

Checking the Routing Tables

Purpose

Make sure that the static routes appear in the routing tables of Device B and Device D.

Action

user@B> show route protocol static
user@D> show route protocol static

Meaning

The asterisks (*) in the routing tables show the active routes. The backup routes are listed next.

Pinging the Remote Addresses

Purpose

Verify that the static routes are working.

From Device B, ping one of the loopback interface addresses on Device D.

From Device D, ping one of the loopback interface addresses on Device B.

Action

user@B> ping 192.168.47.5
user@D> ping 10.0.0.1

Making Sure That the Backup Route Becomes the Active Route

Purpose

If the primary route becomes unusable, make sure that the backup secondary route becomes active.

Action

  1. Disable the active route by deactivating the ge-1/2/0.0 interface on Device B.

  2. Check Device B’s routing table.

    user@B> show route protocol static

Meaning

The backup route has become the active route.

Conserving IP Addresses Using Static Routes

Hosting providers host multiple servers for multiple customers and want to conserve the usage of their IP address space. Traditionally, when a hosting provider client adds new servers, the servers are allocated a small block of IP addresses, such as a /29 block, and the client’s servers are all located in that block of IP addresses.

The Issue, Illustrated

For example, Customer A might need three servers and is assigned the block 10.3.3.0/29 (10.3.3.0 through 10.3.3.7). In this scenario, several IP addresses are consumed. These include the network and broadcast IP addresses (10.3.3.0 and 10.3.3.7), the addresses for the router gateway that the servers are connected to, and the addresses of the individual servers. To allocate three servers, eight IP addresses have to be allocated. Breaking up a single /24 network into 32 /29 networks results in 96 IP addresses out of the 256, in that /24 is being consumed by the network, broadcast, and gateway addresses. When this effect is multiplied across thousands of hosting providers, IP address space is far from being used efficiently. Figure 2 illustrates the issue.

Figure 2: Inefficient Use of IP Address Space
 Inefficient Use of IP Address Space

In this configuration, each customer is allocated a /29 block of address space. For each block, the network, broadcast, and gateway addresses are not available for server IP addressing, which results in three IP addresses being used inefficiently. In addition, the blocks consume unused IP addresses for future expansion.

Solution

This issue can be resolved by configuring the interface on the router with an address from the reserved IPv4 prefix for shared address space (RFC 6598) and by using static routes pointed at interfaces. IANA has recorded the allocation of an IPv4 /10 for use as shared address space. The shared address space address range is 100.64.0.0/10.

The interface in the router gets allocated an IP address from the RFC 6598 space, so it is not consuming publicly routable address space, and connectivity is handled with static routes on an interface. The interface in the server is configured with a publicly routable address, but the router interfaces are not. Network and broadcast addresses are consumed out of the RFC 6598 space rather than the publicly routable address space.

This feature is supported on QFX10000 switches starting with Junos OS 17.1R1.

Figure 3 shows the efficient use of IP address space.

Figure 3: Configuration Using the Shared Address Space
Configuration Using the Shared
Address Space

In this configuration, each customer gets allocated individual IP addresses per server. There is a static route that can be configured as a host route. The interface in the router gets allocated an IP address from the RFC 6598 space, so it does not consume publicly routable address space, and connectivity is handled with static routes out to an interface.

Configuration

The configuration would look like this for Customer A on the gateway router:

With this configuration, no publicly routable IP addresses are wasted. It is worth noting that when a packet is forwarded in this configuration from the router to the server of Customer A’s server 203.0.113.10, the route is forwarded out to the interface ge-1/0/1.0 which has an IP address of 100.64.0.1.

The servers for customer A would be configured as follows:

This example shows a single host route per server, which is a 1:1 mapping. This could equate to a large number of static host routes, if maintained. For scaling purposes, we need to support nonhost routes in this environment. For example, if there were a Customer C in this configuration that had eight servers, it would be much more efficient to allocate a /29 route on the router that points out the interface on which the eight servers are connected. If Customer C were allocated server IPs from 203.0.114.8 through 203.0.114.15 and these were connected via interface ge-1/0/2.0, this would look like:

Understanding Static Route Control in Routing and Forwarding Tables

You can control the importation of static routes into the routing and forwarding tables in a number of ways. Primary ways include assigning one or more of the following attributes to the route:

  • retain—Keeps the route in the forwarding table after the routing process shuts down or the device reboots.

  • no-readvertise—Prevents the route from being readvertised to other routing protocols.

  • passive—Rejects traffic destined for the route.

This topic includes the following sections:

Route Retention

By default, static routes are not retained in the forwarding table when the routing process shuts down. When the routing process starts up again, any routes configured as static routes must be added to the forwarding table again. To avoid this latency, routes can be flagged as retain, so that they are kept in the forwarding table even after the routing process shuts down. Retention ensures that the routes are always in the forwarding table, even immediately after a system reboot.

Readvertisement Prevention

Static routes are eligible for readvertisement by other routing protocols by default. In a stub area where you might not want to readvertise these static routes under any circumstances, you can flag the static routes as no-readvertise.

Forced Rejection of Passive Route Traffic

Generally, only active routes are included in the routing and forwarding tables. If a static route's next-hop address is unreachable, the route is marked passive, and it is not included in the routing or forwarding tables. To force a route to be included in the routing tables regardless of next-hop reachability, you can flag the route as passive. If a route is flagged passive and its next-hop address is unreachable, the route is included in the routing table, and all traffic destined for the route is rejected.

Example: Preventing a Static Route from Being Readvertised

This example shows how to prevent a static route from being readvertised into OSPF, thereby preventing the route from appearing in the routing and forwarding tables.

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

This example shows how to configure a routing policy that readvertises static routes into OSPF, with the exception of one static route that is not readvertised because it is tagged with the no-readvertise statement.

Figure 4 shows the sample network.

Figure 4: Customer Routes Connected to a Service Provider
Customer
Routes Connected to a Service Provider

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 A

Device B

Device C

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device A:

  1. Configure the interface to Device B.
  2. Configure OSPF to form an OSPF peer relationship with Device B.

Step-by-Step Procedure

To configure Device B:

  1. Configure the interfaces to Device A and Device C.
  2. Configure one or more static routes and the autonomous system (AS) number.
  3. Configure the routing policy.

    This policy exports static routes from the routing table into OSPF.

  4. Include the no-readvertise statement to prevent the 192.168.0.0/24 route from being exported into OSPF.
  5. Configure the routing protocols.

    The BGP configuration forms an external BGP (EBGP) peer relationship with Device C.

    The OSPF configuration forms an OSPF peer relationship with Device A and applies the send-static routing policy.

Step-by-Step Procedure

To configure Device C:

  1. Create the interface to Device B, and configure the loopback interface.
  2. Configure the EBGP peering session with Device B.
  3. Configure the AS number.

Results

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

Device A

Device B

Device C

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking the Routing Table

Purpose

Make sure that the no-readvertise statement is working.

Action

  1. On Device A, run the show route protocol ospf command to make sure that the 192.168.0.0/24 route does not appear in Device A’s routing table.

    user@A> show route protocols ospf
  2. On Device B, deactivate the no-readvertise statement.

  3. On Device A, rerun the show route protocol ospf command to make sure that the 192.168.0.0/24 route appears in Device A’s routing table.

    user@A> show route protocols ospf

Meaning

The no-readvertise statement is working as expected.

Verifying the Static Route Configuration

Purpose

Verify that the static routes are in the routing table and that those routes are active.

Action

From the CLI, enter the show route terse command.

Sample Output

user@host> show route terse

Meaning

The output shows a list of the routes that are currently in the inet.0 routing table. Verify the following information:

  • Each configured static route is present. Routes are listed in ascending order by IP address. Static routes are identified with an S in the protocol (P) column of the output.

  • Each static route is active. Routes that are active show the next-hop IP address in the Next hop column. If a route's next-hop address is unreachable, the next-hop address is identified as Reject. These routes are not active routes, but they appear in the routing table because the passive attribute is set.

  • The preference for each static route is correct. The preference for a particular route is listed in the Prf column of the output.

Release History Table
Release
Description
This feature is supported on QFX10000 switches starting with Junos OS 17.1R1.