7.1 Routing Policy Framework & Term Evaluation

Routing Policy Framework & Term Evaluation

In Junos OS, routing policy provides a centralized, deterministic framework for controlling the exchange of routing information between protocol processes and the Routing Information Base (RIB, known as inet.0 for IPv4 unicast). While dynamic routing protocols calculate reachability based on standard algorithm metrics, enterprise network architects deploy routing policies to enforce administrative boundaries, redistribute routes across protocol boundaries, manipulate route path attributes, and prevent routing loops. Mastering policy construction, term execution order, and implicit protocol defaults is a core competency for the JNCIS-ENT examination.

---

1. Architectural Role of Routing Policies in Junos OS

Junos OS strictly decouples the control plane (running on the Routing Engine) from the forwarding plane (running on the Packet Forwarding Engine). Within the Routing Engine (RE), the routing protocol daemon (rpd) manages all routing protocols and maintains the routing table (inet.0). Routing policies operate directly within rpd at two distinct junctions: Import and Export.

+---------------------------------------------------------------------------------------------------+
| JUNOS ROUTING POLICY INTERACTION ARCHITECTURE                                                     |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|   +-------------------+          +------------------+          +-------------------+              |
|   | Incoming Protocol |  ====>   |  Routing Table   |  ====>   | Outgoing Protocol |              |
|   | Updates (BGP/OSPF)|          |     (inet.0)     |          | Advertisements    |              |
|   +-------------------+          +------------------+          +-------------------+              |
|             |                              |                             |                        |
|             v                              v                             v                        |
|      [ IMPORT POLICY ]              Active Route                  [ EXPORT POLICY ]               |
|      Controls which routes          Selection Algorithm           Controls which active           |
|      enter inet.0                   (Preference/Metric)           routes leave inet.0             |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

Import Policies vs. Export Policies

• Import Policy: Evaluates routes received from routing protocol peers or neighbors before those routes are accepted into the Routing Information Base (inet.0). An import policy can filter unwanted routes, alter route preferences, or tag prefixes before they participate in the route selection process.
• Export Policy: Evaluates routes currently residing in inet.0 before advertising them to neighboring routers via dynamic routing protocols. An export policy controls redistribution (e.g., introducing static or direct routes into OSPF or BGP) and manipulates protocol-specific attributes (such as BGP AS-path, communities, or OSPF external metrics).

The Golden Active-Route Rule: Normal export uses active eligible routes. Hidden routes are unusable. Special features such as BGP advertise-inactive or add-path change normal advertisement behavior; they are explicit exceptions rather than evidence that every inactive route is exportable.

---

2. Junos Default Routing Policies by Protocol

When no user-defined routing policy is applied, Junos OS enforces built-in default routing policies. These defaults vary significantly across protocols to preserve protocol integrity and prevent accidental transit routing.

The Link-State Protocol Filtering Trap on the JNCIS-ENT Exam

A frequent misconception among enterprise engineers involves attempting to filter intra-area OSPF routes using an import policy. In Junos OS, you cannot filter OSPF intra-area (Area 0 or non-backbone) routes using an import policy. Because OSPF uses Dijkstra's Shortest Path First (SPF) algorithm, every router within an area must maintain an identical link-state database. If individual routers suppressed specific LSAs locally via import policies, the SPF tree would partition, causing catastrophic routing loops or black holes. Policy filtering in OSPF can only occur at Area Border Routers (ABRs) via summarization and type 3 LSA filtering, or at Autonomous System Boundary Routers (ASBRs) via export policies redistributing external routes (Type 5/7 LSAs).

---

3. Structure of a Junos Policy Statement

Junos routing policies are defined centrally under the [edit policy-options] hierarchy and applied within the respective protocol or routing-options stanza. A policy statement consists of one or more named terms that house match conditions (from) and actions (then).

[edit policy-options]
policy-statement <policy-name> {
    term <term-name> {
        from {
            <match-conditions>;
        }
        then {
            <actions>;
            <action-modifiers>;
        }
    }
}

Evaluation Logic Inside a Term

1. Multiple Match Conditions (from): When multiple distinct match conditions are defined within a single term (e.g., matching both a protocol and a prefix list), Junos evaluates them using a logical AND. The route must satisfy all specified match criteria to trigger the term's action.
2. Multiple Arguments within a Single Match Condition: If a single match condition contains multiple arguments (e.g., from protocol [ ospf static direct ]), Junos evaluates them using a logical OR. If the route matches any listed argument, that specific condition is satisfied.
3. Omitting the from Statement: If a term contains no from statement, it automatically matches all routes. Any route evaluated by this term immediately executes the specified then action.
4. Omitting a terminating action: Attribute changes do not themselves accept or reject a route. Evaluation proceeds through later terms/policies until a terminating action or the protocol default resolves the result.

---

4. Term Evaluation Mechanics: Terminating vs. Flow-Control Actions

Junos OS evaluates policy terms in strict sequential order from top to bottom. The first term in the stanza is evaluated first; if a route does not match, the second term is evaluated, continuing down the list.

Terminating Actions

Terminating actions immediately conclude evaluation for the route. Once a terminating action executes, Junos halts all further processing—no subsequent terms or policies in the chain are evaluated for that route:

• accept: Accepts the route (installs it into inet.0 if an import policy, or advertises it if an export policy) and immediately terminates policy evaluation.
• reject: Silently drops or blocks the route (prevents installation into inet.0 or prevents protocol advertisement) and immediately terminates policy evaluation.

Flow-Control Actions

Flow-control actions override the default termination behavior, enabling complex multi-stage evaluation pipelines:

• next term: Applies configured route attribute modifiers and moves to evaluate the next term within the same policy statement. This is commonly used to apply an action modifier (like setting an administrative tag or community) before testing the route against subsequent criteria.
• next policy: Skips all remaining terms in the current policy statement and moves directly to evaluate the first term of the next policy statement in a chained policy list.

Action Modifiers (Non-Terminating Properties)

Action modifiers alter the attributes of a route without terminating evaluation (unless coupled with an explicit terminating action):

• metric <value>: Sets the internal multi-exit discriminator (MED) or protocol cost.
• preference <value>: Overrides the default Junos route preference (administrative distance).
• community (add | set | delete) <name>: Manipulates BGP community attributes.
• as-path-prepend <asn-sequence>: Prepends autonomous system numbers to influence inbound BGP traffic.
• tag <value>: Applies an internal 32-bit administrative tag used for downstream filtering.

[edit policy-options policy-statement tag-and-accept]
set term term-1 from protocol static
set term term-1 then tag 200
set term term-1 then next term
set term term-2 from tag 200
set term term-2 then metric 50
set term term-2 then accept

---

5. Policy Chains and The Implicit Protocol Default Action

In enterprise configurations, multiple policy statements can be applied in a chained list to an interface, protocol, or peer group:

[edit protocols bgp group ebgp-peers]
user@router# set export [ scrub-routes set-communities advertise-prefixes ]

When a route is evaluated against a chained policy list:

1. The route enters scrub-routes and evaluates its terms sequentially.
2. If a term executes accept or reject, evaluation terminates completely.
3. If the route does not match any term, or if a term executes next policy, evaluation moves to the first term of set-communities.
4. If the route traverses all terms in all chained policies without matching an explicit terminating action, it encounters the implicit default protocol action.

The Implicit Default Fallthrough Trap: The implicit default action at the end of a policy chain is not a universal accept or reject. It is strictly determined by the protocol to which the policy is applied! If you apply a custom export policy to BGP that only matches and rejects RFC 1918 subnets, all other active BGP routes fall through to the end of the policy and are advertised by BGP's default export policy (which exports active BGP routes). Conversely, in OSPF export, any route falling through the policy is rejected by OSPF's default export policy.

Official references checked 2026-10-18: Protocol defaults and import scope.