I am currently investigating an issue which I find rather difficult to "catch" and find information about.
We are running a DMVPN environment based on 2951 HUB routers & 1941 Spoke routers all over the globe (20 locations).
HUB routers are connected on 200Mbit Internet lines, the spokes are connected on lots of different speeds most of them 10Mbit / 20Mbit, and 95% are performing well (getting 80 to 90% of the offered internet line over the VPN)
Recently we added a new location which is having performance issues. From my perspective it's a problem with the local ISP. But it also made me a bit more aware of having a quite high latency 220ms which might ask for tweaking the TCP window size.
I did find some info about setting the ip tcp window-size on the routers, but this made absolutely no change in performance what so ever. (and I tried lots of different calculations / values)
So this gives me the impression there is already a mechanism active which optimizes the TCP window size.
Trying to find more information in regard to optimize DMVPN connections vs latency as our new locations is connected via a 30Mbit line but via the VPN we do not even get 5 to 7 Mbit.
We did some serious testing with the ISP and from my perspective it is still an issue from their side / the routing / peering we are getting from these guys. But the ISP keeps pointing out the latency v.s. performance and advises to adjust the TCP windows size.
As performance has never being an issue, and worked to our expectations makes me new to the debugging of our VPN networks in regard to performance.
I would love to share some thoughts here, or pointed into the right directions / to the right place to find documentation. I want to be able to give an educated answer to my ISP that it is an issue on their / the internet side.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...