nanog mailing list archives

Re: interesting troubleshooting


From: Brandon Martin <lists.nanog () monmotha net>
Date: Tue, 24 Mar 2020 13:02:49 -0400

On 3/20/20 5:57 PM, Jared Mauch wrote:
It’s the protocol 50 IPSEC VPNs.  They are very sensitive to path changes and reordering as well.

Is there a reason these are so sensitive to re-ordering or path changes?  ESP should just encap whatever is underneath 
it on a packet-by-packet basis and be relatively stateless on its own unless folks are super strictly enforcing 
sequence numbering (maybe this is common?).  I can understand that some of the underlying protocols in use, especially 
LAN protocols like SMB/CIFS, might not really like re-ordering or public-Internet-like jitter and delay changes, but 
that's going to be the case with any transparent VPN and is one of SMB/CIFS many flaws.

For LAGs where both endpoints are on the same gear (either the same box/chassis or a multi-chassis virtual setup where 
both planes are geographically local) and all links traverse the same path i.e. the LAG is purely for capacity, I've 
always wondered by round-robin isn't more common.  That will re-order by at worst the number of links in the LAG, and 
if the links are much faster and well utilized compared to the sub-flows, I'd expect the re-ordering to be minimal even 
then though I haven't done the math to show it and might be wrong.

I'd argue that any remote access VPN product that can't handle minor packet re-ordering is sufficiently flawed as to be 
useless.  Systems designed for very controlled deployment on a long-term point-to-point basis are perhaps excepted, 
here.
-- 
Brandon Martin


Current thread: