Category: Net

ECIX started as a classical Internet Exchange in Berlin, Germany. We tried to sell peering ports to ISPs, carriers and hosters on our platform, hoping to give them some advantage over buying ip transit. Mostly smaller companies made use of it. Shortly after Berlin, we opened an IX in Düsseldorf, which is the biggest internet hotspot on the biggest urban agglomeration in Germany.

Obviously having local peers from carriers with end customers and datacenter operators with content is the best mix. There were people offering content and people eager to consume it.

How does peering work? You run a service called Border Gateway Protocol (BGP) on your edge routers installed at the demarcation points of your AS. BGP manages the connections between the AS edge routers and is responsible to build a table of IP prefixes. This is the Routing Information Base (RIB), summing up as much as possible IP addresses under one entry by aggregation. BGP also is responsible to make a selection of the best path between two AS networks based on rules und communities. After the best bath has been chosen, you will forward this information to the forwarding daatabase used by the router to move IP packets.

An ISP is normally connected to more than one AS. In the beginning you will buy one link from a bigger AS and connect the second port to an IX. You are doing so, because you will not have all worldwide available prefixes on an IX. Therefore you will need a default path for all the AS you can not yet connect to via the IX. The IX traffic should normally be much cheaper than the IP traffic you are buying from a bigger AS. This is because you are paying only for the physical link to the IX port and the management fee at the IX.

One day one of our bigger partners offered us connectivity between Berlin and Düsseldorf. This was the starting point of our remote peering product. Starting small with just a Gigabit-Ethernet port and a few hundred Mbps of traffic, customers started to use that service. Especially smaller ISP were happy to take part and by that way they extended their service reach to Berlin or Düsseldorf respectively.
Over the last four years we expanded this service to new locations like Hamburg and Frankfurt. We upgraded our transport backbone from pure Ethernet-transport between the cities carrying only VLAN to MPLS/VPLS transport over rented wavelength.

To be clear about it, the ECIX POPs are working standalone with their own peering mesh and peering IP address space. The remote peering product connects the customer using a virtual ethernet link to that local peering mesh.

With enough experience and knowledge in remote-peering, we searched for new opportunities in Europe and found LU-CIX to be interested in connecting Luxemburg to Düsseldorf and the rest of the ECIX POPs. Later that year we joined AMSI-X remote peering, with competitive pricing and a large number of customers using this service right from the start.

What we did wrong: definitely using a layer 2 Ethernet Backbone link to connect the peering lans. This was a hard time, filtering broadcast traffic, counting local traffic, etc.
What we did right: switching to MPLS/VPLS and using virtual point-to-point Ethernet links between the remote customer and the local peering LAN.

Any issues? Yes there are some unsolved things to be fixed. First of all, the unbalanced selling of ports. Normally the customer of a smaller IX buys remote peering, not the other way around. Second the BGP routing must be very consequent on the customer edge routers. Not sending traffic over long distance links, if the peer is also present on a IX nearby. We try to help with our route-servers and sophisticated BGP communities.

Would we do it again? Yes! Remote Peering is one of our main features and we are continuing to find new interesting remote IX to the benefit of our customers.

Other peering week posts you might like to read include:

UK internet history – The Early Days of LONAP by Raza Rizvi
INEX’s IXP Manager – Tools to help manage an Internet Exchange by Barry O’Donovan
Regional Peering in the UK by James Blessing
Co-operation makes internet exchanges future proof by Pauline Hartsuiker
Experience of launching an IXP in North America by Ben Hedges
The evolution of an IXP network engineer by Rob Lister
Why does Scotland need an Internet Exchange? by Charlie Boisseau

Forewords: The Italian Landscape

Basic facts about Italy and its Internet Landscape:

a. Italy has a strong incumbent, one of the strongest in Europe. It has been amongst the first in splitting domestic and global/foreign business into two separate branches, where the international one is Sparkle, one of the Renesys baker’s dozen, if not a Tier-1.

b. most of the business is concentrated around Milano as this city is the sixth european telecommunication services market according to Telegeography.  Nearly all internet traffic is backhauled there in a ‘Docklands-like’ location known as Via Caldera, a business campus located on the west side of the city close to the highway ring.

c. following Telecom Italia approach, nearly all the big national players (carriers and ISPs) have been always trying to attack adjacent markets, like colo, system integration and so on. As a result of this carrier neutral co-locators have always found an extremely hostile environment there, and are almost unknown. Even in Milano there is just one of them. Basically anybody which has a national network have developed his own data centre.

d. Italy is not a language or cultural hub for the neighboring countries, but

May your networks be stable and free from DDOS attacks. Always wear a white hat and be nice to others. 24th Euro-IX Forum, Salem church, AQL, Leeds.

Other Peering Week posts on trefor.net include:
UK internet history – The Early Days of LONAP by Raza Rizvi
INEX’s IXP Manager – Tools to help manage an Internet Exchange by Barry O’Donovan
Regional Peering in the UK by James Blessing
Co-operation makes internet exchanges future proof by Pauline Hartsuiker
Experience of launching an IXP in North America by Ben Hedges

What a beautiful sight. Dozens of Guinness’ arranged tidily ready for consumption at the 24th Euro-IX Forum. Elsewhere in the world there is trouble. Planes get hijacked, countries annexed, revolution plotted but in Leeds all is well.

Guinness – not just a drink, an art form.

Other Peering Week posts on trefor.net include:
UK internet history – The Early Days of LONAP by Raza Rizvi
INEX’s IXP Manager – Tools to help manage an Internet Exchange by Barry O’Donovan
Regional Peering in the UK by James Blessing
Co-operation makes internet exchanges future proof by Pauline Hartsuiker
Experience of launching an IXP in North America by Ben Hedges

Here at AQL’s Salem church for the 24th Euro-IX Forum and Peering Week on trefor.net. AQL have very impressively converted the church into a datacentre. Upstairs and looking down through a toughened glass floor at the racks is a conference centre. It’s a great facility.

I thought I’d put up the header photo because it shows the mix of Apple / non Apple users. Simple really. You can click on the pic to enlarge it. In case you’re wondering there were a lot more people sat on my side of the church – it was where the door was. 110 people have signed up for the Forum which continues to grow.

More as it happens…

Other Peering Week posts on trefor.net include:

UK internet history – The Early Days of LONAP by Raza Rizvi
INEX’s IXP Manager – Tools to help manage an Internet Exchange by Barry O’Donovan
Regional Peering in the UK by James Blessing

Raza Rizvi is an early pioneer of the internet in the UK. He spent ten years on the board of LINX and was one of the founding signatories of LONAP. In this very interesting post he discusses the early years of internet peering in the UK and how the founding of LONAP came about:

Back in the middle of the second-half of the 1990s if you were a UK ISP that wanted to show you were serious about providing quality Internet access to your customers, you had to be seen to be connecting, or peering, with other ISPs.

The simplest mechanism to do this was to join a peering point.

IXP Manager has grown organically within INEX over the last decade from a CRUD interface on database tables to a fully fledged management system with an ever increasing toolkit of provisioning, configuration and management scripts built around it. If you’re an IXP starting up (or an IXP looking to grow and offer more value to your members), the question isn’t why should you use IXP Manager but rather why the hell aren’t you?

Every individual and business battles the philosophy of not invented here on a regular basis. And with good reason – it’s often more rewarding and interesting to build stuff yourself, just the way you want it. Building a management system for your IXP seems like a lot of fun. And it is – we did it after all! But, after six years of building, tweaking and improving IXP Manager, it can become a bit of a chore to crank out new features every couple of months.

Now, I want you to think about this –

To coincide with the 24th Euro-IX Forum being held on Monday and Tuesday in Leeds (England) we are having a peering week on trefor.net.

Last month James Blessing provided us with a primer on how ISPs provide internet access using Peering and Internet Transit. Every day next week we are going to be featuring guest posts by experts from amongst the top Internet Exchange Providers (IXPs) in Europe.

Look out for posts from all the UK players – that’s IX Manchester, Leeds, Scotland, LINX and LONAP together with contributions from various European centres of excellence including Holland, Ireland, Italy, Germany.

Stay tuned. You won’t want to miss a single word 🙂

Other peering posts – The LONAP AGM and my first Banksy.

Hi All

Going to have a peering week, or few days anyway, to coincide with the Euro-IX Forum in Leeds on 17th and 18th March.

This being the case I’m looking for contributions of a peering and networks related nature. If you are a member of an IX and have a good idea please drop me a line to my trefor.net email.

Atb

Tref