Juniper MX Filtering Gateway: always-on DDoS firewall at line rate
A ready-to-deploy DDoS filtering firewall for Juniper MX204 (4×100GE) at ISP and data-center edges: stateless firewall filters and policers drop attack traffic in the PFE at line rate. Configured and deployed by ITORO for your router.
Protection, telemetry, two Grafana dashboards and e-mail reports sent only when a problem is detected, delivered as one product.
Works standalone. With WanGuard, attack detection additionally injects BGP FlowSpec rules into the router automatically; WanGuard is optional.
One product, four components
Not just a dashboard: four components, each running independently of ITORO infrastructure.
Edge router protection
Firewall filters and policers on the router for inbound and outbound traffic, plus a dedicated lo0 filter protecting the Routing Engine.
Telemetry without Routing Engine load
Native Junos telemetry streamed directly from the PFE. No SNMP polling, no periodic CLI sessions.
DDoS visibility
Per-link transit and peering traffic, per-customer traffic, attack traffic by vector and active mitigation rules in a single view.
Router health and problem reports
Eight health tiles backed by detailed panels; an e-mail report is sent only when a problem is detected.
A standalone product
All four components work without WanGuard. Where WanGuard is deployed, attack detection injects BGP FlowSpec rules into the router and the DDoS Streams dashboard shows them alongside the always-on filters.
Hardware line-rate filtering, always on
Cloud scrubbing needs tens of seconds to divert traffic and is billed per Gbps. An on-premise Juniper MX gateway filters attack traffic on the router itself, in hardware, with no traffic diversion.
MX204 gateway throughput, sized for ISP and data-center edges.
Attack traffic dropped in hardware, clean traffic passes untouched.
With WanGuard, attack detection injects FlowSpec rules into the MX automatically.
Juniper MX: always-on DDoS protection
A line-rate stateless firewall, active before any attack reaches your network: transit DDoS filtering on the WAN/LAN interfaces (Layer 1) plus routing-engine protection via lo0 CoPP (Layer 2).
Filter coverage and rollout
- Separate filter chains for inbound traffic from the Internet and outbound traffic from your network.
- Over 40 classified traffic types: reflection/amplification vectors, malformed packets, bogon and martian source addresses.
- Policers for selected protocols and prefix lists of trusted sources excluded from filtering.
- A dedicated lo0 filter with policers limits traffic destined to the Routing Engine, so a volumetric attack cannot destabilise the routing protocols.
- Staged rollout: terms first run in accept + count mode to measure real traffic, then discard is enabled for confirmed vectors. No customer service is blocked blindly.
Juniper MX filter package: depth & complexity
Delivered by ITORO as a ready-to-deploy configuration.
Transit filters: hard-blocked categories
- Rate-limited (policed, not dropped): SYN floods · IP fragments · ICMP · DNS · NTP.
Routing Engine CoPP
- Default-deny, all unmatched traffic blocked.
- Thousands of potential attack vectors eliminated by architecture alone.
Every filter term has a named counter
- Real-time visibility via Grafana and Juniper Telemetry.
- Counters follow structured naming: protocol, direction, attack type.
- Live monitoring available also from the JunOS CLI at any time.
Anti-spoofing: RPF check on interfaces
- We recommend enabling an RPF check on interfaces to drop traffic with spoofed source addresses.
Junos telemetry to Grafana without Routing Engine load
Native Junos telemetry sensors export data over UDP every 60 seconds, directly from the PFE. The Routing Engine is not involved in the export, and there are no periodic CLI sessions and no SNMP polling.
60-second export interval
Continuous streaming instead of SNMP polling at multi-minute intervals: link saturation shows up while it is happening.
Read-only account
The router account we use has a read-only login class and cannot modify the configuration.
Runs on your infrastructure
Collectors and dashboards run independently of ITORO infrastructure.
DDoS Streams: the full DDoS attack picture in Grafana
Traffic per transit and peering link and per customer interface, attack traffic by vector and by filter action (discard, policer, accept), and active BGP FlowSpec rules with the bandwidth each one holds back. Data comes from firewall filter counters and interface telemetry, refreshed every 60 seconds.
- Transit and peering traffic per link, in both directions, labelled with the carrier names from the interface descriptions.
- Traffic to and from each customer interface, identifying both attack targets and sources of anomalous traffic.
- Attack traffic by vector and filter action: discard, policer, or accept + count (observation mode before discard is enabled).
- Active BGP FlowSpec rules with the traffic volume matched by each rule.
Router Health: RE, PFE, optics and interface health in one view
Key router health parameters with history charts: Routing Engine, PFE and NPU, optics, interfaces and queues, control-plane DDoS protection policers and chassis environment. Each panel describes the metric and gives ready-to-paste Junos CLI commands to verify it on the router, such as show pfe statistics traffic or show chassis fpc.
- Routing Engine and line-card CPU and memory utilisation.
- PFE and NPU load and memory utilisation.
- Routing Engine and chassis component temperatures, fan tray status.
- Optics: Rx/Tx power per lane (dBm), transceiver temperature and laser bias current, early indicators of a degrading link.
- Interface errors and discards, FCS errors indicating dirty connectors or fibre, and output queue drops.
- Link flaps: the most common cause of routing instability, often mistaken for an attack.
- Control-plane DDoS protection (jddosd): which policers were violated, and when.
- Chassis inventory with the status and temperature of every component.
E-mail reports only when a problem is detected
No routine daily reports: an e-mail is sent only when a problem is detected. It contains per-router health cards, eight charts covering the last 12 hours and a table of control-plane protection incidents, with the same report attached as a PDF.
- Alert thresholds are configurable to match the normal operating profile of your network.
- It works whether or not anyone is watching the dashboards.
- It also monitors the collection pipeline and raises an alert when telemetry stops arriving.
- The stored history supports post-incident analysis and capacity planning.
WanGuard detects, Juniper MX filters
WanGuard sees your traffic via a port mirror and identifies the attack in seconds. It then pushes granular BGP FlowSpec rules to the Juniper MX, which enforces them at line rate on the forwarding plane. RTBH remains available as a last-resort fallback for attacks too large to filter granularly.
- Always-on: no traffic redirection, no scrubbing-center latency.
- FlowSpec on the MX line cards; RTBH as fallback.
- Pre-configured filter package tuned by ITORO.
- Telemetry and dashboards are part of the same deployment.
It completes your network protection and protects its heart: the router
A stable router under attack
Under attack a router can lose stability. Firewall filters and Routing Engine protection (lo0 filter) keep routing stable for the duration of the attack.
Filtering at interface speed
Attack traffic is filtered at interface speed with no impact on the rest of the network, as long as the attack fits within your transit and peering links.
The lowest-cost form of protection
A one-time payment. Technical support is available as an option and is not required.
Deployed by certified Juniper engineers
Engineers holding Juniper JNCIS and JNCIE certifications deliver the filtering firewall, the telemetry and the dashboards as one solution, with WanGuard integration if you use it.
All data stays with you
All data is stored on your side. It can run on an existing server, as collection and presentation generate negligible load. Most often we install it on the same server as WanGuard; the requirements depend on the number of routers.
Juniper MX firewall: frequently asked questions
How long does a standard deployment take?
A standard deployment for two routers takes up to a week, often less. It depends on how quickly the network administrator prepares the target configuration with us and on the most convenient deployment method we agree on. Changes are made in a maintenance window, as they affect both the transit links and the customer-facing (downstream) interfaces.
How are new filters rolled out?
New filters are rolled out in at least two or three stages. The first stage blocks protocols and malformed packets that can be dropped safely even on transit traffic. In the second stage we tighten the protocols: terms move from accept to policer (rate-limit) or discard. The last stage tightens the remaining scope step by step. All counters are visible in Grafana, so before each change we see how much traffic it will affect and enable filtering incrementally, without impacting customer traffic or blocking too aggressively.
Do the firewall and telemetry load the router during a DDoS attack?
No. Firewall filter rules are programmed in hardware on the interfaces, so attack packets are discarded at line rate. Telemetry uses the native Junos Telemetry Interface, which exports statistics directly from the PFE without involving the Routing Engine. We do not use SNMP polling or periodic sessions on the router.
Interested in an active Juniper MX filtering gateway?
To define the scope and verify whether your deployment fits the listed price, we need:
- The number of Juniper routers in scope.
- The series and models of those routers.
- The router configuration (without SECRETS), to assess the implementation of all filters. Example command:
show configuration | display inheritance no-comments | display omit | except SECRET-DATA | no-more
We will send you a complete guide to preparing the data as a PDF.
Every deployment includes adapting the filters to your network and interface descriptions. We follow your existing naming convention or slightly adjust the descriptions so that Grafana also shows the link capacity and the uplink commit.