When running Cisco ASR1000 with ISG (Internet Services Gateway) or BNG (Broadband Network Gateway) functionality, bulk session state changes — particularly when many subscriber sessions drop and reconnect simultaneously — can cause session setup failures and CPU overload. Proper tuning of L2TP window sizing and call admission control prevents cascading failures.
L2TP Congestion Avoidance
When PPPoEoL2TP tunnels experience flaps (rapid up/down cycles), user sessions often fail to establish properly during the recovery phase. This is typically related to the L2TP window size (WS) parameter negotiated during tunnel setup.
The L2TP window size works similarly to TCP window size: it governs how many sessions can be admitted into the tunnel concurrently. If the window size is too large (the default local RWS is 1024), the tunnel may attempt to admit far more sessions at once than it can handle, causing session setup failures.
Diagnosing Window Size Mismatch
Check the L2TP tunnel window sizes with:
show vpdn tunnel all | include WS
You’ll often see a mismatch — for example:
Local RWS 1024 (default)
Remote RWS 8
The local end defaults to a window size of 1024, while the remote peer negotiates to 8. This asymmetry can cause congestion and session failures during bulk reconnect events.
Solution: Enable L2TP Congestion Control
Use the l2tp congestion-control command to enable dynamic window size adjustment:
l2tp congestion-control
This allows the tunnel to dynamically throttle the window size based on real-time congestion, preventing the local side from overwhelming the remote peer with too many concurrent session setups.
Call Admission Control
Beyond L2TP tuning, call admission control prevents ISG CPU overload by rate-limiting new session establishments. When ISG is under heavy load (e.g., after a mass session dropout), accepting unlimited new session requests can spike CPU usage, creating a vicious cycle: CPU goes high → session setup slows → timeouts → more reconnects → higher CPU.
Call admission control artificially limits how many new sessions can be set up per second, smoothing the load.
Configuration
Enable the call admission new-model and set limits:
call admission new-model
call admission limit 1000
call admission cpu-limit 65
call admission vpdn 10 1
call admission pppoe 10 1
Explanation:
| Command | Meaning |
|---|---|
call admission new-model | Enables the new-model call admission (required) |
call admission limit 1000 | Maximum number of concurrent active calls |
call admission cpu-limit 65 | If CPU hits 65%, no new calls are admitted (Cisco-recommended threshold) |
call admission vpdn 10 1 | Allow max 10 L2TP/VPDN sessions per second, with 1 connection per remote gateway per second |
call admission pppoe 10 1 | Allow max 10 PPPoE sessions per second, with 1 per interface per second |
Rationale
- CPU limit 65%: Keeping CPU utilization below this threshold maintains headroom for routing, tunneling, and other platform functions. Once CPU crosses 65%, new session admits are blocked temporarily.
- Session rate limits (10/1): Throttles the rate at which ISG processes new session setup requests. This prevents CPU spikes from processing thousands of concurrent setup requests when many subscribers reconnect after an outage.
References
Summary
When ISG/BNG subscribers experience bulk session recovery:
- Enable L2TP congestion-control to dynamically manage tunnel window sizing and prevent L2TP session admission storms.
- Configure call admission control with appropriate CPU and session rate limits to prevent ISG CPU overload during high-volume reconnect events.
These two tunings — combined with appropriate timers and backoff strategies on the client side — ensure graceful scaling when handling thousands of simultaneous subscriber sessions and their state transitions.
The content of this post was created by the author; AI was used for editing and restructuring.