Incast protection via ECN

The most effective defence against a tenant-generated incast attack is correctly configured ECN thresholds, as covered in Chapter 21. If ECN min_threshold is set correctly (approximately BDP/4 for the link speed and RTT), the switch begins marking CE bits before its buffer fills. The attacking nodes' DCQCN rate controllers reduce their send rate. The attack is self-limiting.

# On the leaf switch facing the misbehaving tenant:
# Check current ECN thresholds:
nv show qos ecn profile roce

# If thresholds are missing or too high:
nv set qos ecn profile roce min-threshold 500KB
nv set qos ecn profile roce max-threshold 1500KB
nv config apply

# Monitor if ECN marking is actually occurring:
watch -n 1 'nv show interface swp1 counters | grep ecn'
# ecn_marked_packets should increment rapidly under incast

Per-tenant rate limiting at ToR

If a tenant's traffic consistently exceeds their provisioned share of fabric bandwidth — whether intentional or due to a misconfigured job — NVUE can apply ingress policing on the server-facing port:

# Limit tenant B's ingress rate to 200 Gbps (50% of 400GbE):
nv set interface swp12 link speed 200G
# Note: this limits the physical interface. For per-traffic-class rate limiting:

nv set qos scheduler profile tenant-b-limited
nv set qos scheduler profile tenant-b-limited class 3 bandwidth 50  # 50% of port
nv set interface swp12 qos scheduler profile tenant-b-limited
nv config apply

# Verify:
nv show interface swp12 qos scheduler

WJH as a security signal

WJH (What Just Happened) captures hardware-level drop events on Spectrum-4 with nanosecond timestamps. In a security context, WJH provides early warning of a flood: an attacking node generating traffic faster than the fabric can absorb will produce a distinctive WJH pattern — high-frequency drops from a single source port, all with the same drop reason (L3_LOOKUP_MISS for spoofed destinations, or TAIL_DROP_BY_TC for queue overflow floods).

# Monitor WJH for flood patterns:
# (requires wjhd running — typically via DOCA or Docker container)
docker exec wjhd wjh-util show --type forwarding \
  | grep -E "drop|flood|TAIL_DROP" \
  | sort | uniq -c | sort -rn | head -20

# Example output during a flood event:
# 14821  2026-03-15 02:31:44  src=10.200.0.12 dst=10.100.0.5  reason=TAIL_DROP_BY_TC tc=3
# 14819  2026-03-15 02:31:44  src=10.200.0.12 dst=10.100.0.6  reason=TAIL_DROP_BY_TC tc=3
# ...
# All drops from 10.200.0.12 (TenantB node) targeting TenantA addresses.
# This is a cross-tenant flood — should have been blocked by VRF routing.
# Escalate: check if GBP is configured and VRF route isolation is intact.

# Check if the source is actually reaching the wrong VRF:
nv show vrf VRF_A router rib ipv4 route 10.200.0.12/32
# If this route exists in VRF_A, there is a route leak — critical security event.

DOCA Flow ACL for B200 clusters

On B200 nodes (BF3 equipped), DOCA Flow can suppress flood traffic before it reaches the switch — at the source NIC. This is more effective than switch-side rate limiting because it prevents the malicious traffic from ever consuming fabric bandwidth.

# On DPU OS of the misbehaving B200 node:
# Install a DOCA Flow ACL rule to rate-limit outbound traffic:
doca_flow_inspector --apply-acl \
  "src_ip=10.200.0.12, dst_ip=any, rate_limit=100Gbps, burst=50MB"

# This caps the host's outbound injection rate at 100 Gbps regardless of
# what the host OS or any application attempts to send.