4.5 Layer 2 Firewall Filters: Types, Order and Actions
Key Takeaways
Use family ethernet-switching for the switched-frame example; family inet and inet6 describe IP filter contexts.
Terms are evaluated in configured order: a terminating accept/discard stops evaluation, while unmatched traffic reaching the end is discarded.
A count action records traffic but is not itself a deny; a matching term with only nonterminating actions implicitly accepts unless explicit supported continuation is configured.
Apply filters at the intended interface and direction, then verify both the attachment and counters; hardware support differs by switch and release.
Selecting the Filter Type
A Layer 2 firewall filter is a stateless rule set for frames being switched. It is distinct from routing policy, which decides which routes enter a RIB or protocol advertisement. Rejecting a route in a BGP import policy does not inspect an Ethernet frame at an access port; discarding a frame does not withdraw its destination route from OSPF.
Junos uses filter families to establish the packet context. The access-switch example uses firewall family ethernet-switching. IPv4 routed filters use family inet, and IPv6 routed filters use family inet6. On some routing platforms, a bridge filter uses a different family or attachment hierarchy. A shared filter name is not proof that its match conditions are valid in every context.
Supported Layer 2 matches can include source/destination MAC address, EtherType, VLAN characteristics and, on applicable hardware, selected encapsulated IP or transport fields. Consult the switch’s match/action table before combining them. For example, matching ARP requires an Ethernet/ARP-aware context; an IPv4 destination-address match is not a general match on every frame that happens to traverse an IPv4 subnet.
Term Order and Processing
Terms are evaluated in the order written. A packet that does not match a term moves to the next term. Within a term, distinct conditions normally combine as AND, while alternatives in one condition allow a matching value. A term with no from conditions matches all remaining traffic.
| Result | Effect |
|---|---|
Matching accept | Stop filter evaluation and allow the next forwarding stage |
Matching discard | Stop evaluation and silently drop the frame |
Matching count plus discard | Record the match and drop |
| Matching only a nonterminating modifier | Implicitly accept unless explicit supported continuation changes the behavior |
| No matching term at filter end | Implicit discard |
The word nonterminating does not mean a count-only term automatically falls into a later deny. Count is an auxiliary action; the term’s implicit disposition still matters. Use an explicit supported next term when deliberately counting and continuing, or put the counter in the same term as the intended terminating action.
Worked Ethernet Filter
Assume a supported ELS access-switch interface should count and drop frames from a known prohibited source MAC while permitting other traffic. This is a narrow teaching example, not endpoint authentication: a source MAC can be spoofed, and a denylist is not an authorization system.
[edit]
set firewall family ethernet-switching filter ACCESS-IN term deny-source from source-mac-address 00:11:22:33:44:55/48
set firewall family ethernet-switching filter ACCESS-IN term deny-source then count blocked-source
set firewall family ethernet-switching filter ACCESS-IN term deny-source then discard
set firewall family ethernet-switching filter ACCESS-IN term allow-other then accept
set interfaces ge-0/0/10 unit 0 family ethernet-switching filter input ACCESS-IN
A frame from that exact 48-bit source hits deny-source, increments blocked-source, and is dropped. A different source fails the first term and reaches allow-other. If the two terms were reversed, allow-other would match every frame first and make the deny unreachable. If the final permit were omitted, every other source would fall into the filter’s implicit discard.
The input attachment examines received frames at this switch interface. An output filter examines the egress direction at a supported attachment. Do not assume a supported ingress match/action also works on egress or on an IRB. Hardware resources, direction and encapsulation all constrain available combinations. Policy changes take effect after commit; merely defining a named filter does not attach it to any traffic path.
Monitoring, Troubleshooting and Packet Walks
Check show configuration interfaces ge-0/0/10 | display set for the attachment and show configuration firewall family ethernet-switching filter ACCESS-IN for term order. Inspect show firewall filter ACCESS-IN to see the named counter. Generate controlled traffic from the prohibited source and a permitted source, then compare counter deltas and destination reception. An unchanged counter can mean no matching traffic, a wrong source, a wrong interface/direction, or a filter that was never attached; it does not by itself prove the deny failed.
If ARP stops working after a restrictive EtherType filter, review whether ARP was permitted at all. An IPv4-only allow term can leave hosts unable to resolve a gateway MAC even though the IP route exists. If IPv6 fails, examine neighbor discovery and the family being filtered. If routed traffic reaches an IRB but later fails, investigate the routed filter and routing table separately rather than assuming the access filter explains the whole path.
For an exam packet walk, write the ingress interface, VLAN/family, first matching term, auxiliary action and terminating disposition. Then consider subsequent switching/routing checks. An accept means this filter allows the packet onward; it does not override a later STP state, another filter, unresolved neighbor entry or missing route. This layered interpretation avoids treating a counter hit as proof of end-to-end delivery.
Official references checked 2026-10-18: EX match conditions and actions and QFX/EX feature restrictions.
A Layer 2 filter first counts and discards frames from a particular source MAC, then has an unconditional accept. Which change would make its deny ineffective?
Putting the unconditional accept before the deny term
Adding a named counter to the deny term
Attaching the filter as input on the intended access interface
Using an exact /48 source MAC match
A restrictive switched-frame filter permits IPv4 EtherType only. Hosts cannot resolve their IPv4 gateway. What should be checked first?
Whether BGP has MED 0
Whether the OSPF router ID is a loopback
Whether an NSSA translator is active
Whether the Layer 2 filter also permits required ARP traffic
Sections you finish are checked off in the contents.