Without controlling which traffic enters your network and how it moves through it, your entire system could be flooded with junk data, malicious attacks, or critical information sent the wrong way. Routing policy and firewall filters are the two tools Junos gives you to decide exactly what happens to every packet that touches your router — and understanding them is essential for passing JNCIA-JUNOS and keeping any real network secure.
Jump to a section
A simple way to picture Junos Routing Policy and Firewall Filters
At a busy international airport, 3,000 passengers arrive every hour from flights around the world. Each passenger is a data packet trying to enter or move through a country. The airport has two separate teams: security screening at the entrance and customs officials at the gate to the departures lounge. Security screening is like a firewall filter — they check every passenger (packet) entering the terminal against a list of rules: no liquids over 100ml, no sharp objects, no suspicious behaviour. If a passenger fails a rule, they are denied entry immediately. Customs officials are like routing policy — they check passengers who have already passed security and decide which gate they should go to based on their ticket, visa, and destination. Some passengers get priority boarding (higher preference routes), some are delayed for secondary inspection (reject routes), and some are routed to a different terminal entirely (next-hop changes). If a passenger has a diplomatic passport, customs gives them a special path. If their visa is expired, they are turned away. The firewall filter acts on the packet itself — allow or deny. The routing policy acts on how the packet moves through the network — which path it takes, what priority it gets, and whether it is accepted or rejected based on attributes like origin or destination. Just as the airport needs both teams to function safely and efficiently, a Junos router needs both firewall filters and routing policies to control traffic properly without chaos or security breaches.
In Junos, firewall filters and routing policies serve two different but complementary purposes. A firewall filter inspects packets as they enter or leave an interface and makes a simple decision: allow the packet through or discard it. Think of it as a bouncer at a club checking IDs — if the packet matches certain criteria (like source IP address, destination port, or protocol), the filter either permits it or denies it. Firewall filters can also perform actions like counting packets for logging or setting a specific class of service marking, but the core action is accept or reject.
A routing policy, meanwhile, controls how routes are shared between routing protocols or how routes are selected for the forwarding table. Routes are paths to destinations that the router learns via protocols like OSPF (Open Shortest Path First) or BGP (Border Gateway Protocol). Routing policies can modify route attributes (like local preference or metric), reject certain routes from being installed or advertised, or tag routes for special treatment later. The key difference: firewall filters act on packets, routing policies act on routes.
Firewall filters are configured under the 'firewall' hierarchy in Junos, typically applied to an interface using the 'filter' statement under the 'interface' configuration. You create a filter with one or more terms. Each term has 'from' conditions (match criteria) and 'then' actions (what to do if matched). Terms are evaluated in order, from top to bottom. If a packet matches a term, the action is taken and evaluation stops. Common actions include 'accept', 'discard', 'reject' (sends an ICMP unreachable message), 'count', and 'log'.
Routing policies are configured under the 'policy-options' hierarchy. You define a 'policy-statement' that contains terms similar to firewall filters, but working with routes instead of packets. The 'from' conditions match route attributes like prefix (the destination network), protocol (e.g., OSPF, BGP), or community tags. The 'then' actions can 'accept', 'reject', or modify attributes such as 'local-preference', 'metric', or 'community'. Policies are then applied to protocols using the 'import' or 'export' statements — for example, 'import' policies control which routes are accepted into the routing table from a BGP neighbour, while 'export' policies control which routes are advertised to that neighbour.
Why do these concepts exist? Without firewall filters, any traffic could enter your network — including denial-of-service attacks, unauthorised scans, or unwanted protocols like Telnet to your core router. Without routing policies, a router might learn a route to a destination through a slow, unreliable link when a fast, expensive link is available, or it could accidentally advertise private internal routes to the public internet, causing security breaches or routing loops.
Junos replaces legacy access control list (ACL) configurations found in other vendors with a modern, term-based structure that is consistent across firewall filters and routing policies. This design means once you learn the 'from' and 'then' pattern for one, you already understand the other — the logic is identical, just the objects being tested differ.
Example: Suppose you have a router with two interfaces — ge-0/0/0 facing the internet and ge-0/0/1 facing your internal network. You want to block all inbound traffic to port 22 (SSH) from the internet except from your IT team's public IP address 203.0.113.5. You create a firewall filter with two terms: the first term matches source IP 203.0.113.5 and destination port 22, then accepts. The second term matches destination port 22, then discards. Apply this filter as an input filter on ge-0/0/0. For routing policy, imagine your router learns a default route via BGP from two different internet providers. You want to prefer one provider over the other. You configure a routing policy that sets a higher local preference (e.g., 200) for routes from the preferred provider's BGP session, while leaving the other at the default 100. The policy is applied as an import policy to the BGP group.
Both firewall filters and routing policies can contain multiple terms, and the first match wins. This 'first match' behaviour is critical to understand. If you misorder terms, you might accidentally block traffic you meant to allow or accept routes you meant to reject. Always put more specific match conditions before general ones.
To verify your configuration, use 'show firewall filter', 'show route protocol bgp', and 'show policy' commands. Junos also provides 'show route forwarding-table' to confirm which routes are actually being used.
In summary, firewall filters are about packet-level access control — think security guard at the door. Routing policies are about route selection and advertisement — think traffic controller directing cars onto different highways. Both use the same term-based logic, both are evaluated top-down, and both are essential for a secure, efficient network.
Define the objective
Before writing any configuration, decide what you want to achieve — is it blocking specific traffic (firewall filter) or controlling which routes are used or advertised (routing policy)? Clarify the direction: inbound or outbound for filters, import or export for policies.
Create the filter or policy using 'term' blocks
In configuration mode, navigate to 'edit firewall family inet filter <name>' for a filter, or 'edit policy-options policy-statement <name>' for a policy. Each term is a block with a 'from' section (match conditions) and a 'then' section (action). For example, 'term block-ssh { from { destination-port 22; protocol tcp; } then { discard; } }'.
Apply the filter or policy to the correct interface or protocol
For a firewall filter, use 'set interfaces <interface> unit 0 family inet filter input <filter-name>' or 'output'. For a routing policy, use 'set protocols bgp group <name> import <policy-name>' or 'export'. The apply point determines whether the rule affects traffic entering or leaving.
Validate the configuration with 'show' commands
Use 'show firewall filter <name>' to see packet counters and match counts. Use 'show route protocol bgp' to see which routes are being accepted or rejected. Use 'show route forwarding-table' to confirm which routes are actually installed for forwarding. Always verify before considering the task done.
Test with real traffic or simulation
Generate test packets using tools like ping or telnet to confirm that the filter or policy behaves as expected. For routing policy, use 'show route 10.0.0.0/8' to confirm the preferred path. If something is misconfigured, use 'commit check' before committing to catch syntax errors, and use 'commit confirmed 10' to roll back automatically after 10 minutes if the change breaks connectivity.
A medium-sized company, DataFlow Inc., has a Juniper router at its headquarters connecting to two internet service providers (ISPs) for redundancy. The router also connects to a branch office via a VPN over the internet. The network engineer needs to achieve three goals: block malicious traffic from the internet, ensure that internal traffic to a critical SaaS application uses the faster ISP (ISP-A), and prevent internal private IP addresses (like 10.0.0.0/8) from being advertised to either ISP.
Step by step, here is what the engineer does:
First, to block malicious traffic, the engineer creates a firewall filter called 'block-bad'. The filter includes terms that match known malicious source addresses (from a threat feed), traffic on port 23 (Telnet) which is insecure, and ICMP flood packets. The 'then' action for these terms is 'discard'. A final term matches all other traffic and 'accepts' it. This filter is applied as an input filter to the internet-facing interfaces (ge-0/0/0 and ge-0/0/1) using the 'family inet filter' statement. Without this, attackers could easily probe the network.
Second, to prefer ISP-A for the SaaS application, the engineer creates a routing policy called 'prefer-isp-a'. The policy has a term that matches routes received from ISP-A's BGP session and sets 'local-preference' to 200. A second term matches all other routes and sets local-preference to 100. The policy is applied as an import policy on the BGP group for ISP-A. This ensures that when both ISPs advertise a route to the SaaS application's IP range, the one from ISP-A is chosen because it has a higher local-preference value. The engineer verifies this with 'show route 203.0.113.0/24' and sees the correct next-hop.
Third, to prevent private IP addresses leaking to the ISPs, the engineer creates a routing policy called 'filter-private'. It has a term that matches routes with prefixes in the 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 ranges and sets 'then reject'. The policy is applied as an export policy on both BGP groups. Now, even if a private route is in the routing table, it will not be advertised to the ISPs. Without this, the company could accidentally expose its internal network structure, leading to security vulnerabilities.
Finally, the engineer tests the configuration. A packet from a known malicious IP arrives at ge-0/0/0. The firewall filter matches and discards it — the engineer sees the packet counter increment in 'show firewall filter block-bad'. A legitimate employee accesses the SaaS application; the traffic flows through ISP-A as intended because the preferred route is installed. The engineer runs 'show route protocol bgp' to confirm only public routes are being advertised. All goals are met.
In practise, network engineers routinely combine firewall filters and routing policies in this way. They might also use 'prefix-lists' and 'community' tags to simplify large policies, and they rely on 'commit confirmed' to test changes without long outages. The key skill is translating business requirements into Junos terms — which interface, which direction, which protocol, and which action.
The JNCIA-JUNOS exam (exam code JN0-104) tests your understanding of routing policy and firewall filters in several specific ways. You will encounter multiple-choice questions that present a scenario and ask which configuration block achieves a given goal. The exam loves to test the difference between 'accept' and 'reject' in firewall filters versus routing policies. Remember: in firewall filters, 'reject' sends an ICMP unreachable message back to the sender, while 'discard' silently drops the packet. In routing policies, 'reject' means the route is not installed or advertised, but there is no ICMP message involved. Traps often involve confusing these terms.
Key concepts the exam tests repeatedly:
The order of terms in a filter or policy: first match wins. A common trap question gives a filter with a 'deny all' term placed before a 'permit specific IP' term. The correct answer is that the specific IP is denied because the first term matched first.
Application direction: input (inbound) filters examine traffic entering an interface; output (outbound) filters examine traffic leaving. The exam might ask where to apply a filter to block traffic from the internet to a server: input on the internet-facing interface.
Protocol-specific matching: filters can match on 'protocol' (TCP, UDP, ICMP), 'source-port', 'destination-port', 'source-address', 'destination-address', and 'icmp-type'. You must know the correct match fields for common scenarios (e.g., block SSH uses destination-port 22 and protocol tcp).
Routing policy apply points: 'import' controls routes entering the routing table from a protocol; 'export' controls routes leaving the routing table to be advertised. The exam loves to ask: which apply point prevents a route from being sent to a BGP neighbour? Answer: export.
Default behaviours: without any firewall filter applied, all traffic is allowed. Without a routing policy applied, all routes are accepted and advertised. The exam tests what happens when no filter or policy is configured — the answer is always the default.
The 'then' action 'next term' is a subtle but testable feature. It allows a packet or route to continue to the next term for further evaluation. This is used for logging without discarding.
Prefix-list and community matching: you might see a question where a routing policy uses a 'prefix-list' to match a set of networks. Know that 'prefix-list' is defined separately and then referenced inside a term's 'from' condition.
Exam traps to watch for:
They will give a filter that matches on 'source-address' but the scenario describes blocking traffic to a server (destination). Always verify whether you need to match source or destination.
They will mix up 'family inet' (IPv4) and 'family inet6' (IPv6) filter applications. If the scenario is about IPv4 traffic, the filter must be under 'family inet'.
A routing policy that 'rejects' a route does not prevent the route from being learned via the protocol — it simply prevents it from being installed in the routing table. The route might still appear in 'show route protocol bgp' but not in 'show route forwarding-table'.
Counters and log actions are for troubleshooting, not for affecting traffic flow. A question might ask: which action allows traffic but records it? Answer: 'accept' with 'count' or 'log'.
To memorise: firewall filters = packet actions (accept, discard, reject, count, log). Routing policies = route actions (accept, reject, and attribute modifications like local-preference, metric, community). The syntax structure is identical: 'term name { from { conditions } then { action } }'. Practise writing both until the pattern is automatic.
Firewall filters inspect packets and can accept, discard, or reject them; routing policies inspect routes and can accept, reject, or modify their attributes.
Both firewall filters and routing policies use a term-based structure with 'from' conditions and 'then' actions, and terms are evaluated top-down with the first match taking effect.
By default, Junos allows all packets through an interface and accepts all routes into the routing table unless a filter or policy is applied.
The 'import' apply point controls routes entering the routing table from a protocol; the 'export' apply point controls routes leaving the routing table to be advertised.
In firewall filters, 'reject' sends an ICMP unreachable message back to the sender, while 'discard' silently drops the packet without sending any notification.
A routing policy 'reject' action prevents a route from being installed in the forwarding table, but the route may still appear in the protocol-specific table as hidden until explicitly cleared.
These come up on the exam all the time. Here's how to tell them apart.
Firewall Filter
Acts on packets (data plane): inspects actual data flowing through the router.
Actions are limited to accept, discard, reject (with ICMP), count, and log.
Applied to interfaces using 'family inet filter input/output'.
Routing Policy
Acts on routes (control plane): inspects routing information, not actual data.
Actions include accept, reject, and modifying attributes like local-preference or metric.
Applied to routing protocols using 'import' or 'export' statements.
Import Policy
Controls which routes are accepted into the routing table from a protocol neighbour.
Affects routes that the router itself will use for forwarding decisions.
Applied with 'import' under the protocol configuration (e.g., 'set protocols bgp group my-group import my-policy').
Export Policy
Controls which routes are advertised from the routing table to a protocol neighbour.
Affects routes that other routers in the network will learn about.
Applied with 'export' under the protocol configuration.
Discard (Firewall)
Silently drops the packet without sending any notification to the sender.
The sender has no way to know the packet was dropped (timeout may occur).
Used for stealth blocking to avoid revealing the router's presence.
Reject (Firewall)
Drops the packet and sends an ICMP unreachable message back to the sender.
The sender immediately knows the destination is unreachable.
Used when you want to inform the sender that traffic is not allowed.
Mistake
Firewall filters and routing policies are the same thing because they both use 'from' and 'then' syntax.
Correct
Firewall filters act on packets (data plane) and can only accept, discard, reject, or log them. Routing policies act on routes (control plane) and can accept, reject, or modify route attributes like local preference. They operate on completely different objects.
The similar syntax structure leads beginners to assume they are interchangeable. However, the underlying data being processed — packets versus routes — is fundamentally different.
Mistake
If I apply a routing policy with 'reject', the route is deleted from the routing table immediately.
Correct
A routing policy with 'reject' prevents the route from being installed in the forwarding table, but the route may still be visible in 'show route protocol' as a 'hidden' or 'rejected' route. It can still be used by the routing protocol for other purposes like path selection if not properly filtered.
Beginners think 'reject' means 'delete entirely', but Junos keeps the route in the protocol-specific table for diagnostic purposes unless explicitly removed using additional commands like 'clear bgp neighbor'.
Mistake
You must configure a firewall filter on an interface for it to be secure — by default the router blocks all traffic.
Correct
By default, Junos allows all traffic through an interface unless a firewall filter is applied. The default action is 'accept'. You must explicitly create and apply a filter to block unwanted traffic.
Many other networking devices come with default 'deny all' ACLs, but Junos defaults to 'allow all' for operational simplicity. Beginners from other platforms bring that assumption and get caught out.
Mistake
Routing policies only work with BGP — they are not needed for other protocols.
Correct
Routing policies can be applied to any routing protocol, including OSPF, IS-IS, RIP, and static routes. They are used to control route redistribution between protocols and to filter routes regardless of the protocol.
BGP is the most common protocol where routing policies are used, leading beginners to think they are BGP-specific. The exam tests understanding that policies are protocol-agnostic.
Mistake
The 'then reject' action in a firewall filter and the 'then reject' in a routing policy do the same thing.
Correct
In a firewall filter, 'reject' sends an ICMP unreachable message to the packet sender and drops the packet. In a routing policy, 'reject' simply does not install the route in the routing table — no packet is involved.
The same keyword 'reject' is used in both contexts but with completely different effects. This confuses beginners because they assume consistent semantics.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A firewall filter inspects actual data packets (like an email or webpage) and decides whether to allow or block them. A routing policy inspects route information (paths to networks) and decides which routes to use, advertise, or modify.
Create a firewall filter with a term that matches the source IP address (e.g., 'from source-address 192.0.2.1/32') and set 'then discard'. Apply the filter as an input filter on the interface where that traffic enters.
Check whether you applied the policy in the correct direction (import vs export) and to the correct protocol. Also verify the order of terms — a default 'accept all' term earlier in the policy may override your specific reject term. Use 'show route protocol bgp' to see if routes are being filtered.
It prevents the matched route from being installed into the routing table. The route may still appear in the protocol table as a 'hidden' route, but it will not be used for forwarding or advertised to neighbours unless another policy overrides this.
Yes, you can have multiple terms. They are evaluated in order from top to bottom. Only the first term that matches the packet is executed — once a match is found, the action is taken and no further terms are checked.
Not necessarily, but best practise is to apply filters on interfaces that face untrusted networks (like the internet). Internal interfaces may not need filters if you trust the traffic. However, the default is to allow all, so it is your responsibility to protect vulnerable interfaces.
You've finished Junos Routing Policy and Firewall Filters. Continue through the JNCIA-JUNOS study guide to build a complete picture of the exam.
Done with this chapter?