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
