A regional ISP's edge router receives a packet claiming a source address from a private, non-routable range on an interface facing the public internet, which should never legitimately appear there. Which introductory firewall-filter approach addresses this kind of spoofed-source traffic at the network edge?

Filtering spoofed source addresses at the network edge is a classic use of a firewall-filter term: the from statement matches the private or otherwise inappropriate source-address range, and the then action discards it, applied to the input direction of the interface facing the public internet where such addresses should never legitimately originate. This directly addresses the packet-level problem described. A routing policy rejecting routes from private address space solves a different issue — it governs whether routes are accepted into or advertised from the routing table, not whether a packet's claimed source address is plausible for the interface it arrived on; a spoofed packet is not a route being advertised. A static route to a discard next hop affects how the router forwards traffic destined toward that address range, which is the reverse direction of the problem — this scenario is about traffic arriving claiming to be from that range, not traffic being sent to it. A login class governs administrative authentication and authorization to the router itself, entirely unrelated to filtering transit or inbound packets based on IP header fields. This kind of edge-facing anti-spoofing term is a foundational hardening step for any router with a public-facing interface, since it discards obviously forged traffic before it can be used for reflection or amplification abuse. To verify the term works, an engineer can send test traffic from a private-range source toward the public interface (in a lab, never on production) and confirm 'show firewall filter <name>' shows the discard term's counter incrementing while unrelated legitimate traffic is unaffected.