Junos routing policies and firewall filters use similar building blocks—ordered terms, match conditions, and actions—but they control different things. Routing policy changes how routing information enters, leaves, or is selected within routing tables. Stateless firewall filters evaluate packets at defined processing points and can accept, discard, count, police, classify, or otherwise act on traffic. Keeping those two policy types conceptually separate prevents many configuration mistakes.
This topic remains part of the current JNCIA-Junos objectives, although the approved ExamTopics JN0-105 destination is now legacy: Juniper ended JN0-105 on April 5, 2026 and replaced it with JN0-106 on April 6. The technical concepts are still relevant, but current candidates should use Juniper’s present JN0-106 objectives while treating the older internal exam destination as historical context.
Junos policy is easiest to understand when the engineer asks one question first: am I controlling routes or packets? A route policy changes routing information and decisions. A firewall filter changes treatment of data or control-plane packets. Both are ordered, both can be precise, and both can create outages when a term is placed or matched incorrectly.
Understand the Junos policy evaluation model
A Junos policy is organized into named terms. Each term can contain match conditions and actions. Evaluation proceeds in order, so term sequence communicates intent. Put highly specific cases before broader matches when the specific case must be handled differently. A final broad term can provide an explicit default, making the policy easier to read and review.
The effect of a match depends on the policy type and action. Routing policies can accept or reject routes, modify attributes, or continue evaluation. Firewall filters can accept or discard packets, count or sample them, apply policers, assign forwarding behavior, or use other supported actions. Do not assume that a familiar word such as accept has identical operational consequences in every context.
Read the complete policy before changing one term. An apparently harmless match may be shadowed by an earlier term, or a new broad term may prevent later logic from ever running. During review, test representative routes or packets mentally from the first term to the last rather than focusing only on the line being edited.
Use names that explain purpose. Terms such as accept-bgp-from-transit or protect-re-from-ntp are more useful than term1 or allow2. Clear names improve troubleshooting because command output and counters can be connected to the reason the configuration exists.
Use import and export routing policy deliberately
Import policy controls which routing information is accepted into a routing table or protocol process and can modify attributes as routes are learned. Export policy controls what the device advertises from its routing information to a neighbor or protocol. Confusing the direction can produce a policy that is syntactically correct but acts on the opposite flow of route information.
Start with the routing objective: which prefixes should be learned, which should be rejected, what preference or metric should change, and what should be advertised. Then identify the protocol and policy attachment point. This approach prevents engineers from writing match terms before deciding where the policy actually participates in routing.
Routing policy can match properties such as prefix, protocol, community, route type, or other attributes depending on context. Actions can accept or reject and may modify route characteristics. Keep changes narrow and document why an attribute is changed, because route manipulation can affect traffic far beyond the device where the policy is configured.
The broader distinction between routing protocols is useful when policy behavior is being designed. OSPF and BGP exchange different kinds of information and solve different routing problems, so import and export policy must reflect the protocol’s role rather than reuse one generic filter everywhere.
Build prefix matching that reflects real routing intent
Prefix matching can be exact or can include more-specific routes depending on the configured route-filter behavior. Engineers should be explicit about whether a term should match one network, a range of subnets beneath it, or a limited prefix-length range. A small difference in match semantics can accidentally accept or advertise far more routes than intended.
Use prefix lists or reusable policy objects when several policies need the same set of networks, but keep ownership clear. A shared list that becomes a dumping ground for unrelated prefixes creates hidden coupling: changing it for one peer can alter routing for several others.
When building an allow policy, decide what happens to everything not explicitly matched. An explicit final rejection can make the intended default visible and reduce surprises when the policy is later extended. When building a deny exception inside an otherwise permissive policy, ensure the specific rejection is evaluated before the broader accept.
Validate routing policy with operational commands after commit. Check the active routes, protocol-learned routes, advertised and received routes where available, and policy counters or trace information when troubleshooting. Configuration intent is not proof of forwarding behavior; the resulting routing state is the evidence.
Use policy actions to shape routes without hiding complexity
Routing policy can do more than permit or deny. It can adjust preference, metrics, communities, next-hop behavior, and other attributes supported by the protocol and platform. These tools are powerful because they influence path selection while preserving dynamic routing, but they can make the control plane difficult to reason about when changes are layered without documentation.
Make one policy responsibility obvious. A policy that filters prefixes, rewrites communities, changes preference, and implements a special migration exception may be difficult to test. Breaking the logic into composable policies can improve readability when the evaluation behavior is well understood.
Policy-based routing is a different concept from routing protocol policy. Policy-based routing directs selected traffic according to packet criteria, while Junos routing policy normally controls routing information. Using the same word policy for both can obscure whether an engineer is manipulating the routing table or the forwarding treatment of specific packets.
During changes, compare the intended best path before and after the policy. If a route is still present but traffic moves unexpectedly, attribute changes may have altered selection. Record the expected route preference and next hop so post-change validation can detect unintended shifts quickly.
Treat firewall filters as stateless packet policy
Junos firewall filters evaluate packet fields rather than routing information. Depending on family and platform, terms can match addresses, protocols, ports, flags, packet lengths, interfaces, forwarding classes, and other properties. Because the filters are stateless, each packet is evaluated independently; they do not provide the session awareness of a stateful security policy.
Use them for purposes such as protecting the Routing Engine, restricting traffic on interfaces, counting selected flows, policing rates, classifying traffic, or implementing specific forwarding behavior. A filter should have a defined application point and purpose. Copying a control-plane protection filter onto a transit interface without analysis can block legitimate data-plane traffic.
Be careful with implicit behavior. Juniper documentation distinguishes routing-policy defaults from firewall-filter defaults, and a packet that reaches the end of a stateless firewall filter without matching an accepting term can be discarded. An explicit final action makes the design easier to review and reduces dependence on memory of defaults.
Firewall filters are not a replacement for a stateful firewall where connection tracking, application awareness, NAT, threat inspection, or user context is required. Choose the control based on the problem being solved.
Apply filters at the correct processing point
Filters can be applied to input or output directions and to different interface or routing processing points depending on the platform. An input filter sees packets as they enter the attachment point; an output filter sees packets leaving. Applying the correct logic in the wrong direction can make a filter appear ineffective or can block traffic that was never intended to match.
Control-plane protection often uses a filter on the loopback interface because traffic to the Routing Engine is logically associated with that path. The goal is to permit necessary routing, management, and infrastructure protocols while rejecting or policing unwanted traffic. Test carefully so the protection does not block routing adjacencies, management access, time synchronization, or other required services.
Interface filters used for transit traffic should account for asymmetric routing and the placement of the attachment point. The source and destination values seen on one interface may not match an engineer’s mental model formed from a higher-level network diagram. Packet captures, counters, and route lookups help validate the real path.
Before applying a new filter remotely, use a safe-change procedure. Preserve an out-of-band path where possible, schedule a rollback or commit-confirmed operation, and validate management reachability immediately. A logically correct filter can still lock out the engineer if the deployment path was not considered.
Use counters, policers, and logging for observable policy
Counters turn a firewall-filter term into an operational signal. They can confirm whether traffic matches the expected branch, identify unused terms, and show whether a proposed enforcement rule would affect production. During migrations, a count-only term can be a safer first step than immediate discard.
Policers can limit traffic rates for control-plane protection or other purposes. The threshold should reflect expected legitimate traffic plus reasonable bursts. An overly strict policer can create intermittent protocol failures that are harder to diagnose than a simple deny because some packets continue to pass.
Logging and sampling should be used selectively. High-volume filters can generate excessive records if every matching packet is logged. Choose telemetry that answers an operational question. Counters often provide sufficient evidence for broad traffic classes, while logs are more valuable for low-volume security-relevant events.
Document the baseline before enforcement. If a new filter term is expected to match only unwanted traffic, observe it first where risk allows. That evidence can reveal forgotten monitoring systems, management sources, or routing peers before a discard action causes an outage.
Troubleshoot policy by separating route and packet questions
When traffic fails, first determine whether the device has the expected route. If the route is missing or wrong, investigate routing protocol state and routing policy. If the route is correct, examine forwarding, interfaces, firewall filters, and downstream path. This simple separation prevents hours of inspecting packet filters for a problem created by route import policy.
Use Junos operational modes and commands deliberately. The Junos operational and configuration modes provide different views and actions, and troubleshooting should move between configuration intent and live state. Compare candidate changes, committed configuration, routes, forwarding state, interfaces, and counters.
For a route-policy problem, test which term should match the route and which attributes should result. For a firewall-filter problem, identify the attachment point, direction, address family, packet fields, term order, and counter behavior. Reducing the problem to one policy evaluation path is more effective than making several speculative changes.
The approved JN0-351 destination is also historical context: Juniper replaced that Enterprise Routing and Switching specialist exam with JN0-352 in June 2026. Current study should follow the active Juniper objectives while older pages remain useful for understanding the lineage of routing-policy topics.
Keep policy readable as the network evolves
Routing and filter policy tends to grow through exceptions. Quarterly review should identify dead terms, duplicated prefix sets, temporary migration logic, unused counters, stale management sources, and policies whose owner is no longer clear. Removal is part of policy engineering because obsolete logic increases the chance of unexpected matches.
Use comments and naming to preserve intent, but do not rely on documentation alone. Validate policy against the actual network topology, route advertisements, and traffic patterns. A comment saying “temporary partner route” is not evidence that the partner still exists.
Peer review should include the before-and-after route or packet path. Ask what the first matching term will be, what happens if no intended term matches, and which operational command will prove success. That review style catches ordering and default-action mistakes better than syntax review alone.
Juniper certifications have moved beyond JN0-105, but routing policy and firewall-filter reasoning remain foundational Junos skills. The durable lesson is to distinguish routes from packets, write ordered terms with explicit purpose, attach policy at the correct point, and verify the resulting control-plane or forwarding behavior after every meaningful change.