6.1 Routing Policy
Key Takeaways
- Routing policy controls which routes the routing engine imports into a routing table and which routes it exports/advertises to neighbors; it does not filter user data packets.
- Every policy is built from ordered terms, and each term uses optional from match conditions plus a then action; terms are evaluated top to bottom and the first matching term that takes a final action (accept or reject) ends evaluation for that route.
- Each routing protocol applies a default policy when no user policy makes a final decision: OSPF and IS-IS import all routes and export only local routes, BGP imports and exports all BGP routes, and RIP imports all routes but exports nothing by default.
- Multiple policies can be chained as a list (for example [ policy-A policy-B ]); they are evaluated left to right, and only if no policy reaches accept or reject does the protocol's default policy decide.
- Common uses include redistributing static or direct routes into a dynamic protocol, filtering received routes, and influencing route attributes such as metric or preference.
Why Routing Policy Matters for JNCIA-Junos
Routing policy is the Junos OS mechanism that decides which routes are accepted into the routing table and which routes a routing protocol advertises to its neighbors. On the JNCIA-Junos exam, the Routing Policy and Firewall Filters objective is roughly 10% of the test, and routing policy questions almost always test whether you can read a policy and predict its result.
The single most important distinction to lock in early: routing policy acts on routes (control plane), not on transit data packets (forwarding plane). Firewall filters (covered in 6.2) act on packets. Exam questions deliberately mix these to see whether you confuse the two.
Where Policy Is Applied
Routing policy is referenced from a routing protocol or routing instance, using two directions:
- Import policy — evaluated on routes a protocol receives before they are placed into a routing table.
- Export policy — evaluated on routes before a protocol advertises them to neighbors (and which routes are taken from the routing table).
| Direction | Applied to | Typical question |
|---|---|---|
| Import | Received/learned routes | "Which received routes are installed?" |
| Export | Advertised routes | "Which routes does the router send to its neighbor?" |
A frequent JNCIA trap is reversing import and export. Remember it from the device's point of view: import = routes coming in, export = routes going out.
Policy Structure: Terms, Match, and Action
A routing policy is configured under [edit policy-options policy-statement <name>] and is composed of one or more terms. Each term has two optional parts:
from— match conditions that select routes (for exampleprotocol,route-filter,prefix-list,neighbor,as-path,community,interface). A term with nofrommatches every route.then— the action taken on matched routes.
policy-options {
policy-statement export-statics {
term match-statics {
from {
protocol static;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term reject-everything-else {
then reject;
}
}
}
Evaluation Order
Terms are evaluated top to bottom. Within a term, all from conditions must match (logical AND) for the term to match. As soon as a term matches and its then takes a flow-control (final) action, evaluation stops for that route:
accept— accept the route and stop policy evaluation.reject— reject the route and stop policy evaluation.next term— skip remaining actions in this term and move to the next term.next policy— stop evaluating the current policy and move to the next policy in the chain.
Actions that are not final (such as setting metric, preference, local-preference, community, or next-hop) modify the route but do not end evaluation by themselves. If a term sets an attribute and has no final action, evaluation continues.
Default Policies Per Protocol
If a route reaches the end of every user-configured policy in a chain without an explicit accept or reject, the routing protocol's default policy decides. Knowing these defaults is high-yield for JNCIA-Junos:
| Protocol | Default import | Default export |
|---|---|---|
| OSPF (Open Shortest Path First) | Import all OSPF routes | Export only routes learned from OSPF; reject everything else (you cannot block OSPF link-state flooding with policy) |
| IS-IS (Intermediate System to Intermediate System) | Import all IS-IS routes | Same idea as OSPF — only IS-IS-learned routes; flooding is not policy-controlled |
| BGP (Border Gateway Protocol) | Import all BGP routes | Export all active BGP routes (BGP readvertises BGP routes by default) |
| RIP (Routing Information Protocol) | Import all RIP routes | Export nothing by default — RIP does not even advertise its own learned routes without an explicit export policy |
The RIP and OSPF behaviors are classic exam material. Two facts to memorize:
- RIP advertises nothing until you apply an export policy — even RIP-learned routes are not re-advertised by default.
- Link-state protocols (OSPF, IS-IS) do not let export policy stop the flooding of link-state advertisements; export policy only affects which external routes get redistributed into the protocol.
Policy Chains and Common Use Cases
Policy Chains
More than one policy can be applied at once by listing them in brackets:
protocols {
bgp {
group external-peers {
export [ advertise-statics deny-private-prefixes ];
}
}
}
Policies in a chain are evaluated left to right. Evaluation moves to the next policy only if the current one takes no final action (or uses next policy). If the entire chain finishes with no accept or reject, the protocol default policy is the final tiebreaker. This is why the order of policies in a chain matters: a broad accept early in the chain can mask a later, more specific reject.
Common Use Cases
| Goal | How policy is used |
|---|---|
| Redistribute static/direct routes into a dynamic protocol | Export policy with from protocol static (or direct) then accept |
| Filter unwanted received routes | Import policy with from route-filter ... then reject |
| Tag or color routes | Set community / tag without a final action, then accept in a later term |
| Influence path selection | Set local-preference, metric, or preference on matched routes |
| Aggregate/summarize | policy-statement applied to aggregate or generate routes |
A key conceptual point: static and direct routes are not advertised by any routing protocol unless an export policy explicitly redistributes them. Forgetting the export policy is the most common reason a redistributed route does not appear on a neighbor.
A router receives BGP routes and a network engineer applies no import or export policy to the BGP configuration. Based on the BGP default policy, what happens to BGP-learned routes?
A policy-statement has two terms. Term 1 matches static routes and sets a metric of 5 but has no flow-control action. Term 2 has no 'from' condition and a 'then reject'. What happens to a static route processed by this export policy?
Which statement correctly distinguishes Junos routing policy from a stateless firewall filter?
An engineer configures RIP with no export policy and expects RIP-learned routes to be re-advertised to other RIP routers. What actually happens?