As you may be aware there’s been a flurry of IPv6 related excitement in the past few days. IANA has allocated the last of the IPv4 address space to the regional registries. This means that obtaining IP addresses is going to become steadily more difficult from here and attempting to migrate the whole Internet to IPv6 is looking like more of an immediate priority.

We’ve been running an IPv6 network for over six months, yesterday we enabled IPv6 on two of our customer facing hosting servers, yali.mythic-beasts.com and onza.mythic-beasts.com. We also made their control panels and all services hosted on them available over IPv6.

pete@ubuntu:~$ dig AAAA yali.mythic-beasts.com +short
2a00:1098:0:86:1000::10

Temporarily an automated scripted cleaned up the A record for the hosts disabling access to all the services over IPv4 to all of our customers that don’t have IPv6 connectivity. As our support mailqueue testified, the majority of our customers do not have working IPv6 connectivity yet.

Unrelated to this activity we also discovered that by default linux limits the number of ipv6 routes to 4096. You can update this by doing,

echo 32768 >/proc/sys/net/ipv6/route/max_size 

this is a good idea on any linux machine that sees the full routing table, the IPv6 routing table is now about 4300 routes.

We’re now peering with Google over Lonap.

In May we upgraded our Telecity Meridian Gate site to have 10 Gigabit at the core. Early this week we upgraded the core network in Telecity Sovereign House to run at 10 Gigabit. We are planning to upgrade Telecity Harbour Exchange in the near future and to continue the rollout of 10GigE from the core switches. This means we’ve plenty of spare capacity for very high bandwidth customers in our docklands data centres.

Yesterday we believe was a power failure in Telehouse North. Mythic Beasts don’t have any equipment located in Telehouse but the effects were quite noticeable.

Two internet exchanges, LONAP and LINX were affected. The LONAP looking glass and traffic graph tell us that LONAP saw a all of the peers located in Telehouse North disconnect.

Lonap Traffic Graph

We don’t believe that LINX was directly affected by the power failure, but all sessions on the Brocade LAN were reset and brought up slowly over the course of about an hour, as you can see from the looking glass.

LINX Looking glass for the Brocade LAN

whereas the Extreme LAN wasn’t affected at all.

LINX Looking glass for the Extreme LAN

LINX Traffic Graph

Mythic Beasts saw no overall change in our traffic levels; we escaped unscathed.

Mythic Beasts Total Traffic

but we did see a brief drop on LONAP as various high bandwidth peers disconnected in Telehouse North.

Mythic Beasts LONAP Traffic

we didn’t see any measurable effect over Edge-IX (this traffic pattern is normal for this time of day)

Mythic Beasts Edge-IX Traffic

Mythic Beasts doesn’t currently peer directly on LINX, but we have two partial transit suppliers that do. Partial transit suppliers provide us with routes only from their peering partners so when they lose contact with a peer, we stop being able to route traffic to that network through them.

This partial transit supplier has 10G into the LINX Brocade LAN, 1G into the LINX Extreme LAN and 2G into LONAP plus private peers.

Mythic Beasts Transit 1

This partial transit supplier has 10G into LINX Brocade, 10G into LINX Extreme, 10G into AMSIX, 2.5G into Decix, 2G into LONAP and 1G into Edge-ix plus private peers.

Mythic Beasts Transit 2

We take partial transit from two suppliers, one in Telecity HEX 6/7, one in Telecity MER. Whilst this is more expensive than a single supplier or joining LINX ourselves, we’ve always felt that the additional redundancy was worth paying extra for. We discovered today that one partial transit supplier has almost no redundancy in the event of a failure of the LINX Brocade LAN. We’ve brought this up with the transit in question and will be pressuring them to add resiliency to their partial transit service. We do intend to join LINX, but when we do so we’ll join both the peering LANs from different data centres to maximise our resiliency.

We’re pleased to announce that as a result of tonight’s connectivity changes our core network, all four data centres now have IPv6 connectivity available. In the next weeks we’ll be contacting all our peering partners to enable direct IPv6 peerings where possible to improve our IPv6 connectivity.

If any customers would like to enable IPv6 on their colocated, dedicated or virtual servers please contact us and we’ll allocate you an address range and provide you with connectivity details.

Until the end of August 2010, all IPv6 bandwidth will be free.

Our Cambridge hosting centre has two physically redundant private circuits linking it back to our network core in Telecity Sovereign House and Telecity Harbour Exchange. We’re pleased to report that we’ve now completed upgrades on both links increasing the available bandwidth to Cambridge customers by a factor of 2.5.

As a result we have increased all standard bandwidth customers to 250GB bandwidth quotas, and now offer higher bandwidth packages for dedicated and colocated customers in Cambridge.

Over the last few years, we’ve been investing heavily in increasing both our network’s capacity and its redundancy.  We now have multiple gigabit upstream providers spread across our three London sites, allowing us to host very high bandwidth sites with a high level of redundancy.

Part of this work is to increase the number of peering agreements that we have in place.  Peering is an arrangement where two networks agree to exchange traffic directly with each other for their mutual benefit, rather than paying to send it by a third party (a transit provider).  Peering has two benefits:

1. it reduces overall bandwidth costs; and
2. it typically provides a much more direct, and therefore quicker, route between the two networks.

Usually the first one is the important one: our marginal cost of bandwidth goes down, and we can reflect these savings in our own prices.

At the end of last year we joined EDGE-IX, a distributed internet exchange that gives us the ability to peer with some networks that we don’t see at other internet exchanges. Most notably, we now have peering in place with two big end-user networks: JANET (the UK’s education and research network) and Virgin Media (formerly NTL).

Sometimes the second point can be important. For example, users of Nominet’s Domain Availability Checker (DAC) are often extremely sensitive to latency, with a few milliseconds making a lot of difference. We received an enquiry from a prospective customer interested in using Nominet’s DAC service. This prompted us to set up a peering arrangement with Nominet, and by providing the customer with a Mac Mini dedicated server in one of our London data centres we were able to offer just about the fastest route physically possible to Nominet’s network.