Understanding Routing Policies
For some routing platform vendors, the flow of routes occurs between various protocols. If, for example, you want to configure redistribution from RIP to OSPF, the RIP process tells the OSPF process that it has routes that might be included for redistribution. In Junos OS, there is not much direct interaction between the routing protocols. Instead, there are central gathering points where all protocols install their routing information. These are the main unicast routing tables inet.0 and inet6.0.
From these tables, the routing protocols calculate the best route to each destination and place these routes in a forwarding table. These routes are then used to forward routing protocol traffic toward a destination, and they can be advertised to neighbors.
Importing and Exporting Routes
Two terms—import and export—explain how routes move between the routing protocols and the routing table.
When the Routing Engine places the routes of a routing protocol into the routing table, it is importing routes into the routing table.
When the Routing Engine uses active routes from the routing table to send a protocol advertisement, it is exporting routes from the routing table.
The process of moving routes between a routing protocol and the routing table is described always from the point of view of the routing table. That is, routes are imported into a routing table from a routing protocol and they are exported from a routing table to a routing protocol. Remember this distinction when working with routing policies.
As shown in Figure 1, you use import routing policies to control which routes are placed in the routing table, and export routing policies to control which routes are advertised from the routing table to neighbors.
In general, the routing protocols place all their routes in the routing table and advertise a limited set of routes from the routing table. The general rules for handling the routing information between the routing protocols and the routing table are known as the routing policy framework.
The routing policy framework is composed of default rules for each routing protocol that determine which routes the protocol places in the routing table and advertises from the routing table. The default rules for each routing protocol are known as default routing policies.
You can create routing policies to preempt the default policies, which are always present. A routing policy allows you to modify the routing policy framework to suit your needs. You can create and implement your own routing policies to do the following:
Control which routes a routing protocol places in the routing table.
Control which active routes a routing protocol advertises from the routing table. An active route is a route that is chosen from all routes in the routing table to reach a destination.
Manipulate the route characteristics as a routing protocol places the route in the routing table or advertises the route from the routing table.
You can manipulate the route characteristics to control which route is selected as the active route to reach a destination. The active route is placed in the forwarding table and is used to forward traffic toward the route’s destination. In general, the active route is also advertised to a router’s neighbors.
Active and Inactive Routes
When multiple routes for a destination exist in the routing table, the protocol selects an active route and that route is placed in the appropriate routing table. For equal-cost routes, the Junos OS places multiple next hops in the appropriate routing table.
When a protocol is exporting routes from the routing table, it exports active routes only. This applies to actions specified by both default and user-defined export policies.
When evaluating routes for export, the Routing Engine uses only active routes from the routing table. For example, if a routing table contains multiple routes to the same destination and one route has a preferable metric, only that route is evaluated. In other words, an export policy does not evaluate all routes; it evaluates only those routes that a routing protocol is allowed to advertise to a neighbor.
By default, BGP advertises active routes. However, you can configure BGP to advertise inactive routes, which go to the same destination as other routes but have less preferable metrics.
Explicitly Configured Routes
An explicitly configured route is a route that you have configured. Direct routes are not explicitly configured. They are created as a result of IP addresses being configured on an interface. Explicitly configured routes include aggregate, generated, local, and static routes. (An aggregate route is a route that distills groups of routes with common addresses into one route. A generated route is a route used when the routing table has no information about how to reach a particular destination. A local route is an IP address assigned to a router interface. A static route is an unchanging route to a destination.)
The policy framework software treats direct and explicitly configured routes as if they are learned through routing protocols; therefore, they can be imported into the routing table. Routes cannot be exported from the routing table to the pseudoprotocol, because this protocol is not a real routing protocol. However, aggregate, direct, generated, and static routes can be exported from the routing table to routing protocols, whereas local routes cannot.
In Junos OS Release 9.5 and later, you can configure routing policies and certain routing policy objects in a dynamic database that is not subject to the same verification required by the standard configuration database. As a result, you can quickly commit these routing policies and policy objects, which can be referenced and applied in the standard configuration as needed. BGP is the only protocol to which you can apply routing policies that reference policies configured in the dynamic database. After a routing policy based on the dynamic database is configured and committed in the standard configuration, you can quickly make changes to existing routing policies by modifying policy objects in the dynamic database. Because Junos OS does not validate configuration changes to the dynamic database, when you use this feature, you should test and verify all configuration changes before committing them.