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.
Tighter timing on routing on PPP
Subscribe to: Post Comments (Atom)
I am, once again, getting more spam. Someone must have put my email on some mailing list. This is a pain in the arse, takes up my time, and ...
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo...
Makes a difference to the errors seen when a line is bouncing, though, and is a nice improvement.ReplyDelete
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.
Ah, nearly right - should be on IPCP "up", so both ways negotiated and not just one. Fixed.ReplyDelete