Junos RE Protection: Control Plane Filter and Policers

The Routing Engine handles far more than routing: ARP and ND resolution, ICMP, BGP and OSPF sessions, SSH and SNMP. Each of those is work for a general-purpose CPU, and a flood of packets addressed to the RE will fill its queues long before it fills a link. The result is the familiar failure mode where the network is passing traffic fine but adjacencies drop, ARP entries age out, and the device becomes unmanageable. A Routing Engine firewall filter - the classic protect-RE pattern on the loopback interface - is the standard defence.

Why the loopback interface

A stateless firewall filter applied to a transit interface sees traffic passing through the device. A filter applied to lo0 input sees only traffic destined for the Routing Engine itself, which is exactly the traffic you want to rate-limit and control. That makes the loopback filter the right place for both permit-listing (only SSH and BGP from trusted sources) and policing (cap TCP and ICMP floods).

Build the policers first

set policer tcp-connection-policer filter-specific if-exceeding burst-size-limit 15k bandwidth-limit 500k
set policer tcp-connection-policer then discard

set policer icmp-policer filter-specific if-exceeding burst-size-limit 15k bandwidth-limit 1m
set policer icmp-policer then discard

A policer is a token bucket: bandwidth-limit is the sustained rate (32 kbps to 32 Gbps) and burst-size-limit is the allowance (1,500 bytes to 100 MB). Bytes or packets above the limit are discarded - the cheapest possible way to absorb a flood, because the packet never reaches a socket. filter-specific makes the policer a single instance for the filter rather than one per term, which is what you want when several terms share a rate limit.

Then the terms

set policy-options prefix-list trusted-addresses 192.168.0.0/24
set policy-options prefix-list trusted-addresses 10.2.1.0/24

set firewall family inet filter protect-RE term tcp-connection-term from source-prefix-list trusted-addresses
set firewall family inet filter protect-RE term tcp-connection-term from protocol tcp
set firewall family inet filter protect-RE term tcp-connection-term from tcp-flags "(syn & !ack) | fin | rst"
set firewall family inet filter protect-RE term tcp-connection-term then policer tcp-connection-policer
set firewall family inet filter protect-RE term tcp-connection-term then accept

set firewall family inet filter protect-RE term icmp-term from protocol icmp
set firewall family inet filter protect-RE term icmp-term from icmp-type [echo-request echo-reply unreachable time-exceeded]
set firewall family inet filter protect-RE term icmp-term then count icmp-counter
set firewall family inet filter protect-RE term icmp-term then policer icmp-policer
set firewall family inet filter protect-RE term icmp-term then accept

set firewall family inet filter protect-RE term ssh-term from protocol tcp
set firewall family inet filter protect-RE term ssh-term from destination-port ssh
set firewall family inet filter protect-RE term ssh-term from source-address 192.168.122.0/24
set firewall family inet filter protect-RE term ssh-term then accept

set firewall family inet filter protect-RE term bgp-term from protocol tcp
set firewall family inet filter protect-RE term bgp-term from destination-port bgp
set firewall family inet filter protect-RE term bgp-term from source-address 10.2.1.0/24
set firewall family inet filter protect-RE term bgp-term then accept

set firewall family inet filter protect-RE term discard-rest-term then log
set firewall family inet filter protect-RE term discard-rest-term then syslog
set firewall family inet filter protect-RE term discard-rest-term then discard

tcp-flags "(syn & !ack) | fin | rst" matches new connection attempts and teardowns while letting established traffic pass without hitting the policer - the point being to rate-limit connection setup, not to punish an existing session. An explicit discard-rest-term with log and syslog makes the default behaviour visible: an implicit discard at the end of a filter drops silently, and "why can't I reach the router" is much easier to answer when the attempt appears in the log.

Apply it - carefully

set interfaces lo0 unit 0 family inet filter input protect-RE
set interfaces lo0 unit 0 family inet6 filter input protect-RE-v6
commit confirmed 10

This filter can lock you out of your own router, so always use commit confirmed when applying or changing it: if management access breaks, the configuration reverts automatically. Apply the IPv6 equivalent as well - choosing not to protect inet6 because "we do not run IPv6" ignores link-local and ND traffic that the RE still processes.

Verify

user@router> show firewall
user@router> show firewall filter protect-RE
user@router> show interfaces lo0
user@router> show log messages | match protect-RE

show firewall lists each term's counters and each policer's statistics. Test deliberately: ping the loopback from an untrusted source and confirm loss and a rising icmp-counter, then verify BGP and SSH from trusted sources still work and that no adjacency flapped. If a protocol you did not think about - NTP, TACACS, DNS, SNMP, or the routing protocol's own keepalives - stops working, the discard-rest-term log will name it.

Design notes

• Order matters: rate-limiting and flood-protection terms belong before permissive application terms.
• Do not break what you depend on. IS-IS, OSPF, BFD, TACACS and DNS packets may all need to reach the RE; a filter that only allows SSH and BGP from the NOC is a filter that breaks AAA.
• On MX and EX platforms, combine the loopback filter with chassis-level DDoS protection, which handles packet types the RE filter never sees.
• Keep the trusted-address prefix-list in a policy or apply-group so it can be updated centrally instead of per device.
• Test in a lab with the same protocols and features - including any protocol you plan to deploy next quarter.

Related: Junos firewall filter terms: from and then, Junos monitor traffic and packet capture, and Junos commit confirmed and rollback.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/example/routing-stateless-firewall-filter-security-protect-against-tcp-and-icmp-flood-configuring.html