In my recent training sessions I noticed that intermediate and even advanced users of JUNOS struggled with some of the basics of routing on Juniper devices. Of course they know how to create a static route with the basic settings, and maybe even how to create a aggregate route for summarization with BGP or ISIS/OSPF. But they are not familiar with some of the more esoteric settings that are possible in the [edit routing-options] hierarchy.
In this post I'll discuss the following topics as they are useful for both network engineers and JNCIE candidates.
1. Static routes
2. Aggregate routes
3. Generate routes
1. Static Routes
Static routes are useful in situations where ultimate routing control is required. By manually configuring the next-hop to the destination you are certain where the traffic will go. Especially in edge situations static routes are very useful and often used. Most firewall admin's love them.
The basic commands for static routes for IPv6 and IPv4 respectively are:
IPv6: set routing-options rib inet6.0 static route 2001:1:1::/48 next-hop 2001:A:A::1
IPv4: set routing-options static route 10.100/16 next-hop 10.10.2.1
For a static route to be installed in the routing table the next-hop needs to be valid. Static routes have multiple options with regard to their next-hop:
a. IP next-hop on directly connected interface (see above)
b. Outgoing interface, this is only supported for point-to-point type of interfaces
set routing-options static route 10.100/16 next-hop so-0/0/1.0
c. IP remote next-hop, ie recursive routing will be required. The additional keyword resolve is
required, as well as way to reach the remote next-hop (other static or dynamic route)
set routing-options static route 10.100/16 next-hop 200.1.1.1 resolve
d. Reject, this drops traffic matching this route and sends an ICMP unreachable back to the source
set routing-options static route 10.100/16 reject
e. Discard, this drops traffic matching this route silently
set routing-options static route 10.100/16 discard
f. next-table, this allows traffic to use different route table for finding path to destination*
* This can only be used in 1 direction, you can NOT point any static route with next-table X if there is already a static route with next-table option Y in use in table X. This means that possible return traffic needs to be routed by different means (RIB-groups etc).
set routing-options static route 10.100/16 next-table VR-A.inet.0
If you need to use static routes for redistribution and backup scenario's than you need to be familiar how to change the preference and/or metric of a static route in certain situations:
a. Static routes for redistribution
By default static routes have a metric of 0 unless you configure a specific metric.
set routing-options static route 10.100/16 next-hop 10.10.1.2 metric 5
b. Static route backups a dynamic protocol route
This is a straightforward issue as you need to ensure that the static route's preference is higher than the dynamic protocol. The easiest way is to increase the preference of the static route (default = 5).
set routing-options static route 10.100/16 next-hop 10.10.2.1 preference 200
c. Static route backups another static route
In this case you need each static route, to the same destination, to have a distinct preference or metric. The only way to accomplish this is to use the qualified-next-hop keyword for at least one of the static routes.
set routing-options static route 10.100/16 next-hop 10.10.1.1 (default preference = 5)
set routing-options static route 10.100/16 qualified-next-hop 10.10.1.3 preference 6
Same idea for using metric as differentiatior between the routes.
set routing-options static route 10.100/16 next-hop 10.10.1.1 metric 10
set routing-options static route 10.100/16 qualified-next-hop 10.10.1.3 metric 100
Static routes also have multiple options for interacting with the route and forwarding table
a. Active / Passive;
By default static routes are removed from the routing and forwarding table when the next-hop becomes unreachable. You can keep routes in the forwarding table after the next-hop becomes unreachable by marking the route as passive. The traffic will still match on the specific route but the traffic will be rejected as the next-hop will be reject when the next-hop is unreachable
b. Install / no-install
By default static routes that have a valid next-hop will be installed into the forwarding table. If you don't want the static route to be installed into the route table then use the no-install keyword. The routes can still be redistributed by other routing protocols (potential blackhole). Can be useful for a RR device as it normally doesn't use the routes for forwarding itself.
c. Retain / no-retain
Normally static routes disappear from the forwarding table when the RPD shuts down or the router reboots. To keep static routes in the forwarding table during an RPD shutdown and be available quickly after a reboot use the retain keyword. Useful for routes that provide connectivity to the NOC.
d. No-readvertise / readvertise
Any route in the route table is normally eligible for export into another routing protocol. To avoid a static route from ever being redistributed to any dynamic protocol you can use the no-readvertise keyword. Advised to use this for routes that point out of your fxp0 / Mgmt interface. Can also be useful for routes with the no-install option to avoid blackholing as a result of redistribution.
The last set of options related to static routes have mainly to do with attributes that can be useful when redistributing the route into dynamic protocols.
a.BGP related options
When redistributing static routes into BGP it can be useful to already add certain BGP related attributes (as-path, communities) to the static route so that they do not need to be manipulated inside the export policy.
b. IGP related option
For IGP there is really only 1 option which is the tag field for administrative control during dual redistribution scenario's
Example of BGP related options for static route.
Many of the options discussed can be set under the [edit routing-options static default] section so that they can apply on any static route that doesn't have a overriding specific setting.
set routing-options static defaults preference 200
set routing-options static route 10.100/16 next-hop 10.10.1.1 (will use preference from defaults)
set routing-options static route 10.200/16 next-hop 10.10.1.1 preference 100
Static routes use to have the problem that they couldn't react correctly to certain situations. For example if a L2 switch was between routers it was impossible to detect a remote interface failure. For these kind of scenario's you can use bidirectional forwarding detection (BFD) on static routes. If BFD is used it must be configured on both side of the connection!!!
2. Aggregate Routes
Aggregate routes are the main technique to summarize routes in JUNOS. Basically you manually create your summary in most cases and use the export policy to send your mix of aggregate routes and specific routes. Other vendors typically have options inside the protocol to do this but JUNOS only has the area-range command for inter-area summarization and the nssa area-range command for type 7 to type 5 summarization.
Many but not all of the options that apply to static routes also apply to aggregate routes so I'm not revisiting those here. The preference for aggregate routes is 130 by default.
Many engineers are familiar with a static route to the null interface (reject / discard in JUNOS) for summarization purposes with other vendors. An aggregate route is very similar with 1 big difference and that is that aggregate routes are always conditional. Only if there are more specific routes (contributing routes) will the aggregate be active in the routing table and therefore available for use in the export policy. An aggregate route only has 2 options for its next-hop: reject (default) and discard
set routing-options aggregate route 10.1.0.0/22
set routing-options aggregate route 10.2.0.0/22 discard
To see the contributing routes use the show route detail command. The contributing routes are ordered based on route preference and if there is a tie than numerically (lowest first).
Aggregate routes are typically used on Internet border routers for redistribution of a default route into the IGP domain. A 0/0 aggregate will normally always be active as any route (including local interfaces like lo0) is a more specific route than 0/0 and therefore be considered as a contributing route. If you need to limit which routes can contribute to your 0/0 becoming active use a policy in combination with your 0/0 aggregate definition. Typical scenario is to make sure you have Internet connectivity on your border router before announcing it as an exit point with a 0/0 route into the IGP. To check Internet connectivity you can check any route that you would learn from your peering session(s).
In the example above I used the CheckISP policy to check for some routes coming from my peering session. Only if I receive at least 1 of those 2 routes will the aggregate 0/0 route be active. Note that with an aggregate route the border router itself can NOT use it as the next-hop of the 0/0 route is reject or optionally discard.
3. Generate Routes
Generate routes are very much like aggregate routes as they have the same preference of 130 and even show up with the show route protocol aggregate command (there is no protocol generate option). The only difference is that an aggregate route can use the next-hop of its primary contributing route, so it can have a real next-hop (discard is also option). This also means that only routes with a real-next hop can contribute to an generate route!!
If you ever want your default 0/0 route to have a real next-hop so your border router can use it you have 3 options:
a. Learn the default route from your BGP peering session
b. Configure your own static 0/0 route with a real next-hop (ip address or outgoing p2p interface)
c. Use a generate route instead of a aggregate route
When using the generate variant of the 0/0 route its next-hop is taken from its primary contributing route. This means that this next-hop is installed in the forwarding table of the router that has the generate route configured so this next-hop is used to locally forward packets.
Compare this output to the aggregate output and you should see that the next-hop is 10.10.1.2 in the generate version, whereas it is reject for the aggregate version. So it is up to you to choose what you want for your local 0/0 route with regards to its next-hop properties.
Of course both the aggregate and generate route section has the option to set defaults that apply to all routes that don't have a more specific setting just as with static routes.
Summary
In this blog we covered most settings related to "manual routing" in JUNOS. Understanding of static routes, aggregate routes, and generate routes is essential for engineers working in networks with a complex Layer 3 domain.
More information about protocol independent routing can be found in the iNET ZERO’s JNCIE-SP and JNCIE-ENT workbooks.
Let us know what other topics you would like to have covered in a blog post.
