Tuesday, 28 February 2012

Tighter timing on routing on PPP

When we get a PPP connection (over L2TP) one of the first things we do is a RADIUS request to authenticate. That provides the IP routing which may be single PPP link IPv4, blocks of IPv4, and blocks of IPv6. We even allow IPv6 tunneled to IPv4.

What we used to do is add the routes at that point in time, then negotiate PPP IPCP, and IPV6CP. When the session closed we did RADIUS STOP and then removed routing.

The RFC prohibits sending packets until IPCP or IPV6CP is complete and we had a check for that which dropped the packets.

We have made some changes which should come in later this week which makes the routing much more closely tied to the IPCP and IPV6CP state.

The main impact is bonded and fallback lines. The few seconds that can happen on IPCP and IPV6CP negotiation at the start, and for RADIUS STOP at the end, can mean routing is up but the link drops the traffic.

So the new plan is that immediately on IPCP ACK received we announce the IPv4 routes, and immediately on IPV6CP ACK received we announce IPv6 routes. IPv6 tunneled over IPv4 are on IPCP ACK as the PPP level traffic is IPv4.

We also drop the routes immediately on LCP TERM or L2TP CDN, before waiting for RADIUS STOP confirmation.

This should avoid even milliseconds of routing where there is no link.

Subtle, I know, but am improvement.


  1. Makes a difference to the errors seen when a line is bouncing, though, and is a nice improvement.

    With the old code, I would see ICMP unreachables until the line started PPP, then traffic vanished for a bit, then it got to the destination. You've removed the vanishing bit in the middle.

  2. Ah, nearly right - should be on IPCP "up", so both ways negotiated and not just one. Fixed.