Recently one ISP had an issue with packet loss on the path to a CDN, the office’s ability to use that web app was degraded. (this is currently resolved, through forcing the path/dns w/ an outbound rule)
I noticed that the best possible CDN entrypoint was really only 8ms away and 5 hops, but DNS results with the Balance 305 set to proxy DNS (but not cache) were choosing the distant and lossy path to the CDN.
I created this quick and dirty one liner using dnsyo to lookup an address globally and find pretty much every CDN entry point and list them by ping response time. I created a rule to force this request out a specific WAN interface to check speed to the CDN.
dnsyo foo.com | grep -oE “\b([0-9]{1,3}.){3}[0-9]{1,3}\b” | fping -e | sed ‘s/[()]//g’ | sort -g -k4
Unless I’m missing something, it doesn’t look like the Peplink can match a connection over the WAN to the resolvers for that WAN? I do have 3 WAN’s, each with the correct ISP’s resolvers and all are checked.
If there is some way that I’ve configured this wrong, I’m very interested to know. If this capability does not exist, I’d really like to know of any possible config options that could be workarounds?
If this doesn’t exist in the Peplink product - maybe there’s a complexity here that I’m not aware of that makes this difficult to implement. But, I’d really really like this feature. For an office like the one I’m referencing here that is heavily dependant on web based services and a triple WAN of commodity ISP’s, getting an optimal route into CDN’s is important everyday and critical on a day when somebody’s got a sick route.
Editing to add, I notice this post by rossh_pl - though I’m not totally clear how this table of routes should work. Example please?
“Yet another un-handled issue is DNS. Each WAN has different answers to the same questions for the major sites, because of internal CDN’s. But the default Peplink has no inbuilt rules to match up the proper WAN path to the DNS answer. i.e. DNS on WAN A says ip 1.2.3.4, which is only available to its own internal customers from within its net. But the Peplink tries to route request through WAN B, going to the resource via a public route to A, without success. The solution is to add a table of routes that are specific to each WAN…”