2011-01-31

When IPv6 routing breaks...

Well, I have had an interesting experience today because some things I wanted to get to were on IPv6 that had broken routing. As it happens some google IPv6 blocks are borked, though nearly all sorted now (not sure of cause yet, pretty sure them not us though). But one web site linked to google translate and stalled, and my blog is on google and not been accessable all day. Some stuff was not working well for me.

Sadly the outage was a black hole, so some browsers stalled for a long time and some gave up. It is the worse case scenario. Yes, on one machine it eventually fell back to IPv4, and then it tried to load the style sheet or an image and again stalled for minutes. Not good.

What is interesting is that this is the first time I have really experienced this myself in a really long time, if ever - IPv6 has "just worked" for us for so long. I know it is an issue on some broken installations and have seen customers with it, but not suffered personally. It is ironic that google are so careful and cautious about IPv6 deployment, but even though we route via two direct links and two transit links, none were working. We even shut down links one by one to try and find a fix.

Now, it will be fixed, and TBH, if I could have been arsed, I could have forced IPv4 handling of the pages that I needed.

What worries me is how people react to something like this. Personally, I understand "shit happens" and I have seen enough broken routing with recent LINX issues to know how things can break and how a lot of people work hard to fix them when they do (sometimes I am one of them!).

So it is not a special case for IPv6. But people will see IPv6 broken, would have been fine on IPv4, and think bad things about IPv6. People need to realise IPv4 can (and does) also break!

In this case the fact I had IPv4 means I could access information even when there was a problem. I had an alternative means. And to be quite frank I have managed to get in this situation the other way around on several occasions (almost always my own doing) where IPv4 was borked but IPv6 worked and rescued the situation. I had a customer to the same recently with some badly formatted fire-walling rules. It is the choice of networks that provides an extra level of fall-back, and that is good!

So yes, you can see something like this and blame IPv6, but that really is not the right thing to do. Blame Sod's law, not IPv6.

3 comments:

  1. I noticed this yesterday too on my AAISP ADSL connection, but I kept checking your status page and no known problems were listed! I wasted quite some time troubleshooting what I thought must have been a local issue, can you please mention this on the status site if it happens again? Thanks!

    ReplyDelete
  2. Hmmm, I better go beat someone up for not putting that on the status pages - sorry about that.

    ReplyDelete
  3. I used to get this all the time at work, because a rogue bit of kit left over from after a Networkshop.

    If a really big site is broken via IPv6, maybe there's a case for returning packet to the sender. It'd only make sense for the biggest websites because of the effort involved in deciding when to trigger the special treatment.

    Clients getting packets coming back undeliverable will fail onto IPv4 with little added latency. So the user experience is pretty good.

    ReplyDelete

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Missing unix/linux/posix file open option

What I would like is a file open option for "create replacement file". The idea is that this makes a new inode in the same mount p...