Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring WPS

Use this example to configure Weighted Packet Spray (WPS) in a leaf–spine IP fabric. By selectively spraying traffic across multiple equal‑cost paths based on available bandwidth, WPS enhances link utilization, reduces the risk of packet loss, and maintains stable performance with improved traffic distribution.

Tip:
Table 1: Readability Score and Time Estimates

Readability Score

  • Flesch reading ease: 34

  • Flesch-Kincaid reading grade level: 11.9

Reading Time

Less than 15 minutes.

Configuration Time

Less than an hour.

Example Prerequisites

Table 2: Requirements

Hardware requirements

QFX5240 switches are used to build the toplogy.

Always confirm exact platform/release availability in the Release Notes or Feature Explorer

Software requirements

Junos OS Evolved Release starting 25.2X100-D10

Before You Begin

Benefits

  • Enhances traffic distribution by allocating flows proportionally to link bandwidth.
  • Improves efficiency and resilience during link failures.
  • Reduces packet loss and congestion across the network.
  • Allows selective application through firewall filters for tailored traffic management.
  • Ensures consistent performance and bandwidth utilization when applied uniformly across tiers.
Useful Resources:  

Know more

Weighted Packet Spray

Hands-on experience

vLab Sandbox: IP Fabric with EVPN-VXLAN

Learn more

Introduction to Juniper Data Center Networking

Functional Overview

Table 3: WPS Functional Overview
Protocols
  • BGP Multipath – The multipath support enabled in the spines. Multipath allows the leaves to install multipath equal-cost next hops.
  • Link Bandwidth and aggregate-bandwidth communities – The spines attach bandwidth information using the BGP link-bandwidth extended community, allowing the leaves to compute WECMP balance factors. WPS then uses these balance factors to proportionally distribute traffic according to available link capacity.
  • Auto-Sensed Link Bandwidth – As shown in the topology (Figure 1), Spine1 and Spine2 automatically detect the bandwidth of their physical uplinks to each leaf. The detected per‑link bandwidths are aggregated, allowing each spine to compute and advertise the total available uplink bandwidth toward the leaf.
  • Multipath multiple-as – Allows ECMP even when next hops come from different ASNs.
Firewall Filters
  • Firewall Filter – Junos forwarding (PFE) – The filter is the activation point for WPS. The firewall filter acts as a forwarding filter by selectively determining which flows uses packet-level weighted spraying.
    Note:

    Weighted Packet Spray (WPS) applies only to traffic matching the packet-spray filter and requires the destination to resolve over Weighted ECMP (WECMP). If the system resolves such traffic over ECMP without weights, it may drop packets. The LBW_CONDITIONAL_AUTOSENSE policy ensures link-bandwidth attributes are present to prevent packet drops. The system forwards all other traffic normally using ECMP or WECMP.

Policies
  • Import Policy: auto-link-bandwidth to add link‑bandwidth communities. Ensures the spine adds correct per‑link bandwidth for routes learned from the leaves.
  • Export Policy: aggregate-bandwidth to advertise total bandwidth. Ensures the spines publish an aggregate bandwidth value to downstream leaves.

Primary verification tasks

  • Introduce a link failure between Spine2 and Leaf1 and verify that Leaf2 receives updated, unaltered bandwidth communities from each spine.

  • Confirm that Leaf2 computes updated WECMP balance factors from these values and programs higher balance factors toward Spine1 and lower balance factors toward Spine2 in the forwarding table.

Topology Overview

Device

Role

Function in this example

Spine1 and Spine2

Spine switches

Spine devices in typical IP fabric setup. Provide multiple equal cost paths to the leaf devices.

Leaf1 and Leaf2

Leaf switches

Provides baseline ECMP paths to both spines. Performs packet‑level proportional load balancing based on WECMP next-hop weights

H1, H2, H3, H4, H5, H6

Host devices

Initiate traffic flow

Topology Illustration

Figure 1: Weighted Packet Spray Topology Weighted Packet Spray Topology

In this topology, two leaf switches (Leaf1 and Leaf2) and two spines (Spine1 and Spine2) form an IP fabric running BGP multipath. Each spine uses the standard BGP link‑bandwidth extended community. When multiple equal‑cost links are present, the spine computes and advertises an aggregated bandwidth value using that same community. Leaf2 applies a firewall filter to enable Weighted Packet Spray (WPS) on selected ingress interfaces, so matching traffic is forwarded proportionally across ECMP next hops based on computed weights, while non‑matching traffic continues to use standard ECMP/WECMP behavior.

The leaf and spine devices are interconnected by two back‑to‑back 100G links per leaf–spine pair (200G total). During steady state, hosts H1–H4, H2–H5, and H3–H6 each send traffic at 90% line rate, totaling 270G. With basic ECMP per‑packet load balancing, each 90G flow is distributed evenly across all four available uplinks, sending approximately 135G toward each spine. Since each spine has 200G of egress capacity (2×100G), both spines can forward this traffic without congestion.

When weighted ECMP is enabled using BGP auto-sensed link bandwidth, each spine detects its uplink capacity toward connected leaves and attaches a link-bandwidth community to routes learned from them. As spines re‑advertise these routes toward Leaf2, they also include an aggregate‑bandwidth community representing the sum of their active uplink capacities. In steady state, Leaf2 receives identical aggregate‑bandwidth values from both spines across all four BGP sessions, resulting in equal WECMP weights.

If one of the two 100G links between Spine2 and Leaf1 fails, Spine2 now has only 100G of available bandwidth toward Leaf1. Spine2 therefore advertises a lower aggregate‑bandwidth value to Leaf2, while Spine1—still operating with two 100G links—advertises a higher aggregate‑bandwidth value. With these updated communities, Leaf2 recomputes weighted ECMP next hops and shifts more traffic toward Spine1 and less toward Spine2 to reflect the new bandwidth ratios. This prevents oversubscription on Spine2’s reduced 100G egress path.

However, under standard ECMP, Leaf2 lacks bandwidth awareness and continues forwarding traffic evenly to both spines. Spine2 still receives 135G but can forward only 100G, creating a 35G oversubscription. This results in egress queue buildup and packet drops on Spine2. These active tail drops can be observed using operational commands on the affected device.

Step-by-Step Configuration on Spine1

Note:

For complete sample configurations on the DUT, see:

  1. Configure device identity.

  2. Configure device interfaces inlcuding loopback interface.

  3. Configure the bandwidth aggregation policy, route export policy, and the conditional link bandwidth sensing policies.

    Note: The import and export policies enable link-bandwidth signaling, aggregate on the spines, and propagate bandwidth information used for WECMP and WPS calculations. In production deployments, administrators must control link-bandwidth communities at fabric boundaries. Network engineers should filter or remove these communities at domain edges to prevent propagation beyond the intended routing domain.
  4. Configure the per-packet load balancing policy and apply it to the forwarding table.

  5. Configure BGP communities that identify routes carrying bandwidth information for intelligent load balancing.

  6. Configure autonomus system and router ID for the device.

  7. Configure the BGP neighbors and peer group for leaf devices.

  8. Enable eBGP multipath peering toward the leaf devices and enable auto‑sensed link bandwidth.

Step-by-Step Configuration on Leaf1

  1. Configure device identity.

  2. Configure device interfaces inlcuding loopback interface.

  3. Configure the IRB interface on Leaf1 to act as the default gateway for hosts (H1–H3) and to originate the test prefix.

  4. Configure the route export policy.

  5. Configure the per-packet load balancing policy and apply it to the forwarding table.

  6. Configure BGP communities that identify routes carrying bandwidth information for intelligent load balancing.

  7. Configure autonomus system and router ID for the device.

  8. Configure the BGP neighbors and peer group for leaf devices.

  9. Enable eBGP multipath peering toward the leaf devices and enable auto‑sensed link bandwidth.

Step-by-Step Configuration on Leaf2

Note:

For complete sample configurations on the DUT, see:

  1. Configure device identity.

  2. Configure device interfaces inlcuding loopback interface and enable weighted packet spray.

  3. Configure an optional IRB interface on Leaf2 to act as the default gateway for hosts (H4–H6).

  4. Configure the bandwidth aggregation policy, route export policy, and the conditional link bandwidth sensing policies.

  5. Configure the per-packe load balancing policy and apply it to the forwarding table.

  6. Configure BGP communities that identify routes carrying bandwidth information for intelligent load balancing.

  7. Configure Firewall Filter for Weighted Packet Spray.

    Note: WPS might reorder packets and should only apply to flows that can tolerate such reordering. The firewall filter serves as the control point for selectively enabling packet spray, while it forwards other traffic normally.
  8. Add the Firewall Filter to an interface.

  9. Configure autonomus system and router ID for the device.

  10. Configure the BGP neighbors and peer group for spine devices.

  11. Enable eBGP multipath peering toward the spine devices and enable auto‑sensed link bandwidth.

Verification

Note: IRB interfaces in this example act only as the default gateway for hosts connected to the leaf devices. Weighted ECMP (WECMP) and Weighted Packet Spray (WPS) do not depend on IRB interfaces and operate on any ECMP BGP‑learned prefix. All subsequent verification steps validate BGP and forwarding‑plane behavior independent of the prefix origin interface.

Verify the IRB interface and connected prefix on Leaf1

Purpose

Confirm that you have configured the local subnet on the access IRB and verified its operational status, allowing the device to originate and export the local route into BGP.

Action

Meaning

irb.3111 is up/up and IPv4 shows 101.0.111.1/24. These confirm that the connected network exists and is installed in the RIB.

Verify the connected route in the RIB on Leaf1

Purpose

Ensure the local IRB-connected network is installed as a Direct route (the source for further BGP advertisement).

Action

Meaning

101.0.111.0/24 appears as *[Direct/0] via irb.3111 - Confirms the origin of the route before it is exported into BGP.

Verify how Spine1 learns the prefix from Leaf1 through eBGP peering

Purpose

Confirm BGP multipath on the spine: the prefix is learned over both back‑to‑back leaf links, each accepted as part of ECMP.

Action

Meaning

First neighbor shows Accepted Multipath; second shows Accepted MultipathContrib - Confirms two ECMP contributors for the same destination from Leaf1 to Spine1.

Verify that Spine1 installs the prefix with Link-Bandwidth communities (auto-sense + import policy)

Purpose

Ensure the spine attaches bandwidth community to the received leaf prefix (even if the leaf didn’t send one) by using auto-link bandwidth on import.

Action

Meaning

Look for flags like RTargetLBWSet and Communities: bandwidth:<asn>:<bps>. You should see two ECMP next hops (50/50) to Leaf1 and a bandwidth community per path (e.g., bandwidth:23456:49999998976). This proves the spine derived and attached LBW values through import policy.

Verify that Spine1 advertises the prefix with aggregate bandwidth toward Leaf2

Verify that Spine1 installs the prefix with imported link‑bandwidth communities

Purpose

Verify that Spine1 imports per‑link bandwidth information from Leaf1 before computing an aggregate bandwidth value.

Action

Meaning

Each BGP path learned from Leaf1 carries a link‑bandwidth extended community representing the auto‑sensed bandwidth of that individual uplink. Spine1 uses these values to compute an aggregated bandwidth for downstream advertisement.

Purpose

Confirm the aggregate-bandwidth community is added on export so downstream devices learn total available capacity.

Action

Meaning

Look for Communities: bandwidth:...:99999997952 (example value = aggregate of equal links). Confirms aggregate bandwidth is propagated to leaves through BGP out of the spine.

Verify on Leaf2 that the prefix arrives from both spines with bandwidth communities and 4-way ECMP

Purpose

Ensure the leaf receives the prefix from both spines (two paths per spine) and installs four multipath next hops with the same LBW community, enabling WECMP/WPS.

Action

Meaning

Look for the four next hops (two via Spine1 and two via Spine2). Balances at steady state should be 25% each. Communities: bandwidth:…:99999997952 present on all paths.

Test Action: Initiate Link Failure

Purpose

Simulate lower fabric bandwidth by disabling one uplink between Spine2 and Leaf1.

Action

Verify Post-Failure WECMP and WPS Behavior on Leaf2

Purpose

Confirm that Leaf2 recalculates WECMP weights and updates WPS forwarding behavior after the link failure.

Action

Meaning

This confirms dynamic WECMP recalculation and correct WPS proportional packet spraying following a link failure.

Cross-check Spine2 also advertises the prefix with aggregate bandwidth downstream

Purpose

Validate consistency across spines—both must export the same bandwidth community semantics, enabling coherent WECMP at the leaves.

Action

Meaning

Multipath present with the two Leaf1-facing links (50/50). Export shows aggregate bandwidth community matching Spine1's behavior.

Verify WECMP + WPS steady state on Leaf2

Purpose

Confirm that with all links up, weights are equal, bandwidth communities are present for all next hops, and the forwarding table uses a unilist structure ready for packet spray.

Action

Meaning

You should see four bandwidth communities, one per next hop. Balance 25% on each next hop. FIB shows unilist with evenly stepped balance buckets (e.g., 16384/32768/49152/65535), which the PFE will use for per‑packet weighted spray when the firewall term matches.

Appendix 1: Set Commands on All Devices

Appendix 2: Show Configuration Output on DUT

Spine1

Leaf1

Leaf2