Peering is where networks meet, be it LINX, AMS IX, DE-CIX etc. All these peering providers have one goal and that is to connect as many networks as possible and make communication faster and more efficient. Peering exchange points are called Internet Exchange Points or IXPs.
At it’s heart, the main purpose of an IXP is to facilitate peering via the exchange itself eliminating the total reliance on tier 1 providers. Most IXPs however, force members to ensure they have presence on the internet routing table (usually via Tier 1 ISPs) before they can join them. IXPs are usually non-profit organisations where the members have full say in which direction the organisation takes.
Enterprises that depend on internet for revenue tend to register themselves with an internet registry such as RIPE, ARIN etc which enables them to present themselves on the internet routing table. Communication is then made possible via peering using BGP. With their own AS handy, they reach out to teir 1 internet service providers and create direct peering connections with them. However, these direct connections also mean that the tier 1 providers are always in the path of the enterprise and the destination network.
To avoid this latency, the concept of peering was born with the birth of the first IXP back in the 90s. The concept was simple, allow every member to be able to connect to a switched environment and create neighbour relationships over BGP locally. This was an instant hit as enterprises no longer needed to peer directly with anyone yet receive the same speed as a direct peering connection.
To elaborate this further, lets use the example of google. Your business might send a lot of traffic to google due to the use of google’s search, youtube etc. All this traffic would then traverse from your main tier 1 provider links. If your edge router is connected to an IXP’s switch that google already connects to, VOILA! you can now peer with google directly and send all your traffic to google via your IXP peer. This presents a win-win solution for all sizes of businesses that need to achieve the advantages of direct peering but at a fraction of the cost.
All members in an IXP are part of the same prefix. This means that if the prefix is a /22 subnet, than a thousand members can join in and share the same broadcast domain. Since all they need is connectivity to a given address on port 179 to activate BGP, the schema of keeping all peers in the same subnet easily achieves that.
It’s important to note that peering is not out of the realms of political influence. You will routinely see bigger companies refuse to peer with smaller companies unless they agree to send a specific amount of traffic their way. This problem is then resolved via the use of route servers.
It is possible to connect to an IXP and still not peer with anyone at all and yet reap the benefits of direct peering. How? By peering with route servers.
Usually IX’s have multiple linux hosts running bird which then peer with everyone willing to peer with them. Usually, every member of the internet exchange peers with the route servers. Once peered with the route server, the route server sends the prefixes advertised by every member to each member connected to it via BGP. This means member A will get prefixes of member B, C and D and so on via the route server itself. This is the same result member A would achieve had they peered with member B, C and D directly. The catch here is that route servers do go down due to maintenance. In case of an outage with all route servers, you can loose all your traffic to peering members at the IXP and will have to rely on your tier 1 links alone.
This brings us to the question, why peer directly anyway? The advantage of peering directly with another member is guaranteed connectivity at all times. This is why larger enterprises force you to either send more than a threshold of bandwidth their way, or rely on peering with route servers to reach them.
Another important thing to note is that the route server never changes the next-hop attribute of the received prefix from a member to itself when advertising out to another member. This way, all the route server does, is share prefixes between members. Since all members are part of the same network subnet, the received prefix’s next hop is always the originator of that prefix and always available. Therefore, outgoing traffic from member A is sent directly to member B and doesn’t use the route server as a transit hop.
Once you become a member of an internet exchange, all you have to do is look for a peering registry that hosts information about other peers. In the UK, we use peeringdb which provides all information regarding any member’s IP address and which internet exchange point they are part of. Once identified, you can simply configure your end and send them an email on their email address listed in their profile on peeringdb. Make sure you send them your peeringdb link which will have all details in place for them to configure their end. Once done, you can simply wait for their reply confirming their end is configured. You should be able to see BGP up and running and should also be able to see their prefixes received via direct peering.
Its best practice to ensure you have a single group for all peering neighbours. This way, your preferred settings are applied to each neighbour automatically when you configure a neighbour in the peering group. Its important to ensure you have a max prefix limit on your BGP peering group so that a peering neighbour’s bad configuration can’t accidentally cause the internet routing table to be received by your router and you end up re-routing your transit traffic via the peering neighbour. Also, at the same time, ensure your group policy doesn’t advertise any other prefixes apart from your own.
It would take two to tango but mistakes in configuration where the whole internet routing table is sent and received would end up in asynchronous flow of traffic whereby traffic would leave via the peering neighbour but return via the main transit links provided by the teir 1 provider, not ideal, of course!
Peering relationships are strictly for traffic intended for the peering neighbour’s public address range and are not meant to be used as transit to reach an end point over the internet.