6.3 Junos Load Balancing & Filter-Based Forwarding (FBF)
Key Takeaways
In default Junos OS operation, even when multiple equal-cost paths exist in the Routing Information Base (inet.0), only a single next-hop is installed into the Packet Forwarding Engine (PFE).
Enabling Equal-Cost Multi-Path (ECMP) forwarding on the traditional single-next-hop default requires creating a routing policy with then load-balance per-packet and exporting that policy into routing-options forwarding-table.
On current forwarding hardware, load-balance per-packet commonly enables per-flow hashing; the exact hash inputs depend on platform, packet type and configuration.
Filter-Based Forwarding (FBF) overrides standard destination-based routing by inspecting Layer 3 and Layer 4 header fields to steer traffic into non-default routing instances.
Deploying FBF requires a strict three-step configuration: 1) create a firewall filter with then routing-instance, 2) define a routing instance of instance-type forwarding, and 3) apply the filter as an input filter on the ingress interface.
Junos Load Balancing & Filter-Based Forwarding (FBF)
Standard IP routing operates on a "hop-by-hop" destination-based paradigm: a router consults its forwarding table, matches the destination IP address against the longest prefix match, and transmits the packet out the designated next-hop interface. However, modern enterprise networks require greater agility—specifically, distributing traffic across parallel equal-cost uplinks and steering specific application flows through specialized security devices or cost-effective WAN connections. This section explores Equal-Cost Multi-Path (ECMP) load balancing and Filter-Based Forwarding (FBF) in Junos OS.
1. Equal-Cost Multi-Path (ECMP) Routing & Junos Forwarding Defaults
When dynamic routing protocols (such as OSPF, IS-IS, or BGP) or static routing identify multiple paths to the same destination prefix with identical metric and preference, all eligible paths can be represented in the Routing Information Base (RIB, inet.0).
The Critical Junos Default Forwarding Behavior
+---------------------------------------------------------------------------------------------------+
| JUNOS ROUTING TABLE (RIB) VS FORWARDING TABLE (FIB / PFE) DEFAULTS |
+------------------------------------+--------------------------------------------------------------+
| Component | Default Multi-Path Behavior |
+------------------------------------+--------------------------------------------------------------+
| Routing Table (RIB / inet.0) | Installs ALL equal-cost paths learned from protocols. |
| Forwarding Table (FIB / PFE ASIC) | Installs ONLY A SINGLE NEXT-HOP chosen arbitrarily! |
+------------------------------------+--------------------------------------------------------------+
The #1 Junos Load Balancing Trap: In default Junos OS operation, the Packet Forwarding Engine (PFE) does not load-balance across equal-cost links! Even if
show routedisplays four equal-cost OSPF next-hops ininet.0, the PFE installs only a single next-hop into the hardware forwarding table. All transit packets flow across that single interface, leaving the remaining links completely idle. To utilize multiple paths simultaneously, you must explicitly enable multi-path forwarding.
2. Enabling Per-Packet (Flow-Based Hash) Load Balancing
To instruct the PFE to install all equal-cost next-hops into the active forwarding table, an administrator must configure a routing policy and export it into the forwarding table.
Step-by-Step ECMP Configuration
Step 1: Define the Load-Balancing Policy
Create a policy statement under [edit policy-options] with the action load-balance per-packet:
[edit policy-options]
user@router# set policy-statement ecmp-load-balance then load-balance per-packet
Step 2: Export the Policy to the Forwarding Table
Apply the policy under the [edit routing-options forwarding-table] hierarchy:
[edit routing-options]
user@router# set forwarding-table export ecmp-load-balance
Demystifying "Per-Packet" vs. "Per-Flow"
Although the Junos CLI command explicitly uses the keyword per-packet, modern Junos hardware platforms (including EX Series switches, QFX Series switches, MX Series routers, and SRX Series firewalls) perform per-flow hashing, not true round-robin packet-by-packet forwarding.
- Why True Round-Robin Fails: Transmitting individual packets of a single TCP session across alternating links causes packets to arrive out of order due to micro-variations in serialization delay. Out-of-order packets trigger duplicate ACKs, false packet-loss detection, and catastrophic TCP window collapsing.
- Junos Hardware Flow Hashing: The PFE ASIC extracts header fields from incoming IP packets to compute a hash key. A common 5-tuple key can include:
- Source IP Address
- Destination IP Address
- Protocol Field (e.g., TCP = 6, UDP = 17)
- Source Layer 4 Port
- Destination Layer 4 Port
- Flow Consistency: With stable forwarding state, packets sharing the configured hash inputs map consistently to a next hop. Exact fields vary by platform, packet type and configuration; do not assume every device includes transport ports by default. Distinct flows can collide in the hash, so equal utilization is not guaranteed. A failed member or changed next-hop set can remap flows.
3. Filter-Based Forwarding (FBF) Architecture
While ECMP balances traffic matching identical destination prefixes, Filter-Based Forwarding (FBF) (known conceptually as Policy-Based Routing, or PBR) selects an alternative routing table before that table performs its destination-prefix lookup. FBF inspects Layer 3 and Layer 4 packet header fields—such as source IP address, source subnet, TCP/UDP port number, or DSCP marking—and redirects matching packets into dedicated routing instances.
Enterprise FBF Use Cases
- Selective Internet Breakout: Routing guest Wi-Fi subnets out an inexpensive commodity broadband connection while routing corporate subnets through a high-assurance MPLS WAN.
- Security Service Chaining: Intercepting HTTP/HTTPS traffic (TCP ports 80/443) and steering it through a dedicated proxy or Next-Generation Firewall (NGFW) cluster before reaching the internet.
- Voice / Real-Time Traffic Steering: Routing DSCP EF (Expedited Forwarding) voice packets over low-jitter links while routing standard bulk file transfers over secondary circuits.
4. The Three-Step FBF Configuration Workflow
Implementing FBF in Junos OS follows a mandatory three-step sequence:
+---------------------------------------------------------------------------------------------------+
| THE THREE-STEP JUNOS FILTER-BASED FORWARDING (FBF) WORKFLOW |
+---------------------------------------------------------------------------------------------------+
| Step 1: Create a Firewall Filter matching packet criteria with action "then routing-instance". |
| Step 2: Create a Routing Instance of "instance-type forwarding" containing alternative paths. |
| Step 3: Apply the Firewall Filter as an "input" filter on the ingress interface. |
+---------------------------------------------------------------------------------------------------+
Step 1: Define the Firewall Filter
Configure a firewall filter under [edit firewall family inet filter <name>]. The matching term evaluates packet attributes and directs matches to the target instance. A default accept term is mandatory to permit standard forwarding for non-matching traffic:
[edit firewall family inet filter redirect-web-traffic]
user@router# set term match-http from destination-port [ 80 443 ]
user@router# set term match-http from protocol tcp
user@router# set term match-http then routing-instance web-proxy-vr
user@router# set term allow-remaining then accept
Exam Trap: If you omit
term allow-remaining then accept, Junos applies its implicit default action:then discard. All traffic that is not HTTP/HTTPS will be dropped at the interface!
Step 2: Create the forwarding Routing Instance
Define the routing instance specified in the filter. Crucially, the instance must be configured with instance-type forwarding:
[edit routing-instances web-proxy-vr]
user@router# set instance-type forwarding
user@router# set routing-options static route 0.0.0.0/0 next-hop 192.168.200.1
A forwarding instance type does not run dynamic routing protocols; it serves exclusively as a container for alternative static routes or leaked RIB entries used by the PFE.
Step 3: Apply the Filter to the Ingress Interface
Apply the firewall filter to the incoming interface under unit <unit> family inet filter input:
[edit interfaces ge-0/0/0 unit 0 family inet]
user@router# set filter input redirect-web-traffic
FBF filters must strictly be applied on ingress (input). Applying an FBF filter on egress (output) will not divert packets because the routing lookup has already occurred before egress filter evaluation.
5. RIB Groups Integration with FBF
In many enterprise FBF deployments, the forwarding instance must reach internal subnets as well as its specialized gateway. Because a forwarding instance does not run dynamic routing protocols, an administrator uses a RIB group to leak connected interface routes and core prefixes from inet.0 into web-proxy-vr.inet.0:
[edit routing-options]
user@router# set rib-groups fbf-leak import-rib [ inet.0 web-proxy-vr.inet.0 ]
user@router# set interface-routes rib-group inet fbf-leak
This ensures that return paths and directly connected gateways are resolvable within the forwarding instance table.
6. Verification and Troubleshooting CLI Commands
Verifying ECMP in the Forwarding Table
To confirm that multiple next-hops are installed in hardware, query the forwarding table directly:
user@router> show route forwarding-table destination 10.50.0.0/16
In the output, verify that multiple entries for the destination prefix appear forming a composite/list next hop and its component interfaces. A ucst entry by itself does not prove multipath forwarding.
Verifying FBF Operation
user@router> show firewall filter redirect-web-traffic
user@router> show route table web-proxy-vr.inet.0
The filter example has no counter action. On platforms supporting counting with an FBF routing-instance action, add a supported counter; otherwise compare route resolution, egress/interface statistics, and controlled test traffic. Do not assume every term automatically has counters.
Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.
Official references checked 2026-10-18: Per-flow behavior and platform context, Hash-key configuration.
A Junos router learns two equal-cost paths to prefix 10.50.0.0/24 via OSPF and installs both into inet.0. Without any additional policy configuration, how does the Packet Forwarding Engine (PFE) forward transit traffic destined for 10.50.0.1?
The PFE performs round-robin packet-by-packet distribution across both next-hops.
The PFE installs only a single next-hop into the forwarding table, directing all packets through that single path.
The PFE drops the packets due to an unresolved equal-cost collision in the hardware tables.
The PFE broadcasts copies of each packet across all interfaces associated with the equal-cost paths.
An administrator must implement Filter-Based Forwarding (FBF) to redirect branch guest traffic out a dedicated ISP gateway. Which sequence of configuration steps correctly implements FBF in Junos OS?
Create a static route with qualified next-hops, enable hyper-mode forwarding, and apply a policy to routing-options forwarding-table.
Configure a VRF instance with route-distinguishers, create an export policy matching guest IP prefixes, and apply it to BGP.
Create a firewall filter with then routing-instance <name>, create a routing instance of instance-type forwarding, and apply the filter as an input filter on the ingress interface.
Define a RIB group linking inet.0 to inet.3, assign the ingress interface to instance-type virtual-router, and enable load-balance per-packet on egress.
Although the Junos CLI statement is configured as load-balance per-packet, how does the Junos Packet Forwarding Engine (PFE) actually distribute IP traffic across equal-cost next-hops in hardware?
It uses a hardware hash of supported packet fields to keep a flow on one next hop while the forwarding set remains stable.
It alternates physical packet transmission on a strict packet-by-packet round-robin schedule regardless of session state.
It measures interface bandwidth utilization every millisecond and redirects entire VLANs to the link with the lowest load.
It encapsulates alternate packets into GRE tunnels to distribute load across Layer 2 switching paths.
Sections you finish are checked off in the contents.