Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Limiting VPN Routes Using Route Resolution

This topic describes limiting VPN routes by configuring route resolution on PE routers and route reflectors and by configuring the PE router to accept a limited number of prefix from a CE router.

Example: Configuring Route Resolution on PE Routers

This example shows how to configure a routing table to accept routes from specific routing tables. It also shows how to configure a routing table to use specific import policies to produce a route resolution table to resolve routes.

Requirements

Before you begin, configure a Layer 3 VPN, as shown in one of the following examples:

Overview

One method to achieve IPv4 route scaling is to modify how BGP routes are added to the forwarding tables. By default, the Routing Protocol Process (rpd) adds all the routes in inet.0 and inet.3 to the resolution tree. Normally, this includes the resolved IPv4 BGP routes, which can increase memory consumption. To achieve better scaling for IPv4 routes, this example shows how to configure the Junos OS so that resolved BGP routes are not added to the resolution tree. This is achieved by applying an import policy on the route resolution table, which ensures it does not accept any BGP routes from inet.0.

You would apply this configuration to all provider edge (PE) routers in the Layer 3 VPN.

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.

PE Router

Procedure

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 CLI User Guide.

To configure route resolution:

  1. Configure the routing policy.

  2. Apply the routing policy.

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

Results

Confirm your configuration by issuing the show policy-options and show routing-options commands.

Verification

Confirm that the configuration is working properly by running the following commands:

Example: Configuring Route Resolution on Route Reflectors

This example shows how to change the default resolution behavior on a route reflector (RR) to use inet.0 for next-hop resolution instead of inet.3.

Requirements

Before you begin, configure a Layer 3 VPN, as shown in one of the following examples:

Overview

One scenario for route resolution is when you have a label-switched path configured from an RR to a provider edge (PE) router, or when the PE routers only peer with the RR. This can result in routes being hidden. To resolve this issue, you can change the default resolution behavior to use inet.0 for next-hop resolution.

By default, the bgp.l3vpn.0 routing table stores all VPN-IPv4 unicast routes. This table is present on any router that has Layer 3 VPNs configured, including PE routers and RRs.

When a Layer 3 VPN router receives a route from another Layer 3 VPN router, it places the route into its bgp.l3vpn.0 routing table. The route is resolved using the information in the inet.3 routing table. This means that when BGP receives a route destined for table bgp.l3vpn.0, the protocol nexthop (received BGP nexthop) has its forwarding nexthop recursively determined from the inet.3 table. The resulting route is converted into IPv4 format and redistributed to all routing-instance-name.inet.0 routing tables if it matches the VRF import policy.

On an RR with no attached customer edge (CE) routers, the resolution rib bgp.l3vpn.0 resolution-ribs inet.0 configuration causes routes in bgp.l3vpn.0 to use the information in inet.0 instead of inet.3 to resolve routes. You should not use this configuration on a router that is directly attached to a CE router. In other words, do not use resolution rib bgp.l3vpn.0 resolution-ribs inet.0 on a PE router.

If you want both inet.0 and inet.3 to be used, you must configure both, as in set resolution rib bgp.l3vpn.0 resolution-ribs [inet.0 inet.3].

In this example, the policy POLICY-limit-resolve-routes limits the route resolution to only routes learned through IS-IS. If you omit the import policy, all routes in inet.0 are evaluated and potentially used to resolve the protocol next hop. If you do not want to resolve against all entries, you use a policy to filter for a subset of the routes from the tables that are used for route resolution.

One common example is when you resolve against all routes in inet.0, except the default route (0/0).

Although the import statement is used in this configuration, no routes are imported or copied. Rather, the import policy-name configuration limits the set of possible routes that can be considered for route resolution.

The resolution rib bgp.l3vpn.0 resolution-ribs inet.0 configuration is useful when a BGP RR is not in the forwarding path. In other words, there are no ingress LSPs at the RR. Consider the case where RSVP is the label signaling protocol, and RSVP is configured full mesh at the edge routers. The RR needs to be able to reflect the routes. To do so, BGP is expected to perform a route resolvability check. If a Layer 3 VPN route is received but the nexthop is not in the inet.3 table, the route cannot be resolved. Because the router is not in the forwarding path, an effective workaround is to use the information in inet.0. The metric information in inet.0 is useful for choosing the best route, even though it cannot be used for forwarding.

An alternative approach is to make sure that LSPs are provisioned to the RR. This happens automatically if you configure LDP.

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.

Route Reflector

Procedure

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 CLI User Guide.

To configure route resolution:

  1. Configure bgp.l3vpn.0 to use the information in inet.0 instead of inet.3 to resolve routes.

  2. (Optional) Configure the routing policy.

  3. (Optional) Apply the policy.

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

Results

Confirm your configuration by issuing the show policy-options and show routing-options commands.

Verification

Confirm that the configuration is working properly by running the following commands:

Limiting the Number of Paths and Prefixes Accepted from CE Routers in Layer 3 VPNs

You can configure a maximum limit on the number of prefixes and paths that can be installed into the routing tables. Using prefix and path limits, you can curtail the number of prefixes and paths received from a CE router in a VPN. Prefix and path limits apply only to dynamic routing protocols, and are not applicable to static or interface routes.

To limit the number of paths accepted by a PE router from a CE router, include the maximum-paths statement:

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

Specify the log-only option to generate warning messages only (an advisory limit). Specify the threshold option to generate warnings before the limit is reached. Specify the log-interval option to configure the minimum time interval between log messages.

There are two modes for route limits: advisory and mandatory. An advisory limit triggers warnings. A mandatory limit rejects additional routes after the limit is reached.

Note:

Application of a route limit may result in unpredictable dynamic routing protocol behavior. For example, when the limit is reached and routes are rejected, BGP may not reinstall the rejected routes after the number of routes drops back below the limit. BGP sessions may need to be cleared.

To limit the number of prefixes accepted by a PE router from a CE router, include the maximum-prefixes statement:

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

There are two modes for route limits: advisory and mandatory. An advisory limit triggers warnings. A mandatory limit rejects additional routes after the limit is reached.

Note:

Application of a route limit may result in unpredictable dynamic routing protocol behavior. For example, when the limit is reached and routes are rejected, BGP may not reinstall the rejected routes after the number of routes drops back below the limit. BGP sessions may need to be cleared.

A mandatory path or prefix limit, in addition to triggering a warning message, rejects any additional paths or prefixes once the limit is reached.

Note:

Setting a path or prefix limit might result in unpredictable dynamic routing protocol behavior.

You can also configure the following options for both the maximum-paths and maximum-prefixes statements:

  • log-interval—Specify the interval at which log messages are sent. This option generates warning messages only (an advisory limit).

    Specify the log-interval option to configure the minimum time interval between log messages.

  • log-only—Generate warning messages only. No limit is placed on the number of paths or prefixes stored in the routing tables.

  • threshold—Generate warning messages after the specified percentage of the maximum paths or prefixes has been reached.