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
set policy-options policy-statement protocol-bgp from protocol bgp set policy-options policy-statement protocol-bgp then reject set routing-options resolution rib inet.0 import protocol-bgp
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:
Configure the routing policy.
[edit policy-options policy-statement protocol-bgp] user@PE# set from protocol bgp user@PE# set then reject
Apply the routing policy.
[edit routing-options resolution] user@PE# set rib inet.0 import protocol-bgp
If you are done configuring the device, commit the configuration.
[edit] user@PE# commit
Results
Confirm your configuration by issuing the show
policy-options and show routing-options commands.
user@PE# show policy-options
policy-statement protocol-bgp {
from protocol bgp;
then reject;
}
user@PE# show routing-options
resolution {
rib inet.0 {
import protocol-bgp;
}
}
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
set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 set routing-options resolution rib inet.0 import POLICY-limit-resolve-routes set policy-options policy-statement POLICY-limit-resolve-routes term isis from protocol isis set policy-options policy-statement POLICY-limit-resolve-routes term isis then accept set policy-options policy-statement POLICY-limit-resolve-routes then reject
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:
Configure bgp.l3vpn.0 to use the information in inet.0 instead of inet.3 to resolve routes.
[edit routing-options resolution rib bgp.l3vpn.0] user@RR# set resolution-ribs inet.0
(Optional) Configure the routing policy.
[edit policy-options policy-statement POLICY-limit-resolve-routes] user@RR# set term isis from protocol isis user@RR# set term isis then accept user@RR# set then reject
(Optional) Apply the policy.
[edit routing-options resolution rib inet.0] user@RR# set import POLICY-limit-resolve-routes
If you are done configuring the device, commit the configuration.
[edit] user@RR# commit
Results
Confirm your configuration by issuing the show
policy-options and show routing-options commands.
user@RR# show policy-options
policy-statement POLICY-limit-resolve-routes {
term isis {
from protocol isis;
then accept;
}
then reject;
}
user@RR# show routing-options
resolution {
rib bgp.l3vpn.0 {
resolution-ribs inet.0;
}
rib inet.0 {
import POLICY-limit-resolve-routes;
}
}
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:
maximum-paths path-limit <log-interval interval | log-only | threshold percentage>;
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.
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:
maximum-prefixes prefix-limit <log-interval interval | log-only | threshold percentage>;
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.
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.
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.