| Quote from: chrcoluk |
funny enough plexy I found the same, even on native ipv6 I had to set - 20bytes for android to be fully happy. so 1472 mtu on ipv6.
|
| Quote from: AndyH |
What I don't quite get is how everything works fine with v6 and then all of a sudden Akamai hosted content stops working - even though nothing has changed my end.
|
Interesting. I dont know how the carriage between PN and Akamai is set up, or how PNs internal IPv6 is handed. But having to set MTU of 1472 on native IPv6 would, to me, indicate there is a IPv4 tunnel being used somewhere upstream. If it only happens 'sometimes' then perhaps there is some native connectivity and some tunneled connectivity upstream, when native is used the 1492 is fine, but when tunneled is used you need 1472. I would be inclined to think that, based on your traceroutes, that if there is a tunnel involved its not something thats plusnet<>akamai (as your traces show you going off to akamai nodes outside of plusnets network, as opposed to the internal nodes). Perhaps Paul or Bob could confirm if there is any PN IPv6 egress which is tunneled over IPv4? Not necessarily to Akamai - just to 'anywhere'.
Dont forget, the Akamai node you are routed to can change every 30 seconds - so lets say you are using things just fine one minute, then the route changes and something breaks. It would be great to know the 'before' and 'after' routes used when that happens, though I see it being a pain to try to figure that out (perhaps some kind of IP logging/showing browser extension?)
Personally I would recommend setting your IPv6 MTU to 1472 anyway, as who knows what routing out there is tunneled - even out in transit providers. There could be a link somewhere which is affected, then another which is not and it just depends on which you get routed onto that the problem occurs or not. Again, speculation but seems likely given the symptoms.
So for me there are a few open questions;
- Is the max PPPoE MTU of 1492 valid for IPv6 native, or would 1472 be a better value just incase something somewhere out in transit land gets tunneled?
- Does PN have any IPv6 egress to any transit provider, peer or CDN which is tunneled over IPv4?
- Is there a problem with carrying the IPv6 family in EDNS0 when using google DNS (Jelv's tracert shows the PN Akamai nodes in use when using PN DNS or OpenDNS, but not when using Googles DNS. AndyH seems to not be routed to the PN Akamai nodes at all)
- Has Akamai got some internal IPv6 mapping issue thats contributing to this (I can try to validate this if you PM me the IPs you are making requests from).
We have to remember that the PN team do seem to be aware of an issue and its being looked at. That is probably compounding things. Lets imagine this scenario (hypothetical!):
- You do a DNS request for an akamaized site
- The PN Akamai nodes nearest to you has capacity, is in service and healthy
- Your request is kept inside the PN network, things display OK
Then this one;
- You do a DNS request for an akamaized site
- The PN Akamai nodes nearest to you are out of service/at capacity/under maintenance/whatever
- You are routed to the nearest available node, which takes you outside of PN's network
during technical issues, you could 'flip flop' between the two (up to every 20 seconds!). What if the problem is as I suspect, a MTU issue, but is only happening internal to some transit provider outside of PNs control. We know there is a potential PN<>Akamai issue, based on PN's graphs earlier in this thread. So if Akamai is routing a percentage of end user requests out of plusnet, through peering in order to keep the load down on PN Akamai nodes - AND - an upstream provider/Plusnet egress is using an ipv6 in ipv4 tunnel somewhere - what you see with a MTU of 1492 is 'this works.. yay'.... then later 'this doens t work.. booo'... rinse and repeat.
Try with MTU 1472
