I read with some excitement that South African ISP MWEB have disconnected their transit connections with other ISPs in South Africa, claiming that their existing services from Vodacom and Telkom South Africa were congested and expensive, and detrimental to the quality of internet services in the country.
According to the RIPE RIS service, the links between MWEB (AS10474) to Telkom South Africa (AS5713) were disconnected on the November 2nd – Telkom being the original transit provider that MWEB used.
MWEB have detected that congestion reduces, therefore service levels increase when traffic bypasses the incumbent and is delivered directly to other ISPs in their region via peering links. If a network refuses to peer, MWEB simply deliver the traffic to local providers via their international links – possibly just as congested, but available at a fraction of a cost. If traffic is then delivered to the incumbents via links they themselves pay for, the incumbents also have a financial incentive to peer.
Peering is the best way to encourage enormous capacities between ISPs and other networks, because a direct one-to-one connection can be monitored and well managed in order to guarantee availability for internet traffic. Peering therefore increases available bandwidth and reduces bandwidth costs. This will enable high the sort of services that require high-bandwidth availability, like streaming media and high definition video conferencing.
Interestingly, thirty minutes after the adjacency with Telkom was severed, it appeared that MWEB picked up a new transit customer – Yebo, AS12258, with Yebo’s prefixes being advertised to Interoute (again, according to RIPE RIS). The commercial nature of this downstream relationship is, however, not revealed by the routing table.
The incumbent is perfectly entitled to – and well placed to – sell excellent transit links into the local market, but their strategy to do that, as I explained in my last article, must be to make the transit product in their key regions excellent – this means to peer with the key other local providers (not all providers) in the market, and to ensure that capacities across their backbone and to customers are well managed and available for traffic.
At Menog 7, I had the pleasure of enjoying an explanation of the Middle East IP market place (link), provided by James Cowie at research organisation Renesys.
It demonstrates clearly that deregulated markets offer enormous advantages over controlled ones, and should serve well as a reminder to operators and policy makers that simply getting out of the way could be the best way to further their aims for industry in any given region. This is mainly because:
Incumbent networks in this region have a huge opportunity to grow revenues, as the market expands, as long as they are willing to interconnect widely in this region. As the number of providers in a region expands, customers will be able to (and, according to this research, actually do) pick between innovative and disruptive new providers with excellent regional (via peering), and international (via transit) capacities. Peering also makes capacity cheap, because traffic can stay local to the ISP. An incumbent provider that refuses to peer in order to retain market share will not be able to compete in quality terms with the new providers. Defending a 100% market share is impossible in a competitive market, so the strategy must change, the aim must become enjoying the fruits of a booming market instead of monopoly. As the Renesys slides say, there is no dominent IXP in this region yet, with many networks dragging traffic to London, Amsterdam or Frankfurt to exchange, but this will change as the density of providers in the Middle East reaches a critical mass.
I’m in Istanbul at MENOG7 in order to present in a panel about internet exchange points. Our aim is to give groups of ISP networks in the Middle East enough knowledge to start internet exchange points, so there will also be presentations on the business case and organisational checklists. I am presenting on the technical pre-requisites required to build an Internet Exchange point.
Setting up an Internet Exchange point is simple from a technology point of view, but requires significant planning, and community support for the plans. Read the slides to find out more about what must be planned.
Download: [Slides + Notes (recommended)] ~ [Slides alone]
View directly from Slideshare (requires flash):
I noticed earlier that LONAP had passed a fantastic milestone just before the weekend – of the ninety nine networks which are plugged into the exchange, more than half of the networks choose to connect to each other via the route-server.
A route-server is a fantastic way for networks to start to peer (swap internet traffic) at Internet Exchanges, and results in instant success after connection. A network with an open peering policy can connect to the internet exchange, and then get peering with more than half of all the other networks on the exchange by bringing up a single pair of BGP sessions.
When a route-server peering is established, a BGP session is setup between your router and LONAP’s route database. LONAP advertise all of the prefixes of the other connected members to you, but the traffic between you and the other members flows between you and your peer directly (it does not need to traverse the route-server.) Members do not need to open their network to their own customers at the route servers, they can send special messages to the route-servers to prevent certain networks from seeing prefixes.
Route-servers are not new, but have had a bad reputation for stability for several years. With our colleagues at several other community exchanges, including the LINX, we shared bugs, workarounds, and feature requirements with each other and the main open-source route-server vendors. Eventually, we were able to report considerable improvement in stability last December. As a result, we at LONAP selected BIRD and OpenBGPd as our route server vendors, and built a support framework to link our configuration with the LONAP configuration system.
Since then we have been advocating the route-servers to our members, and the fact that they are now providing a stable stepping-stone to more than half of our peers shows that this effort was worthwhile. If you would like to start to peer, but need to be assured of instant success and results, then contact Andy for information about how the route-servers at LONAP can help.
We are now at the end of January, but IPv4, the Internet’s core addressing protocol still has a nasty hangover, and all signs are pointing to 2010 being a bad year for the protocol.
Since January 1st, a few key milestones have passed, indicating how urgent the IPv4 rundown problem has become. Firms that rely on internet connectivity must take urgent action in light of the events:
RIPE members should thoroughly audit their address space so that they can ensure that their records are accurate, because RIPE are more likely to ensure that address space is assigned to your end users in line with the community’s policies. ISPs and services providers who need help can contact me for further information or specific assistance.
Organisations who rely on internet connectivity for their products should ensure their providers have an IPv6 migration plan in place. Otherwise end-to-end connectivity for your home or office is unlikely to be something you can enjoy looking beyond the runout period. Companies hosting network services, for example a website, should enquire what their host’s IPv6 plans are, and start to enable their services via v6.
There is real traction to ensure v6 support appears in both the hardware and services you need to connect to the internet. It is easier today than before to find help making your services available via v6. The alternatives – patchy connectivity via nested stacks of ipv4 islands, or no more end-to-end connectivity (so that your internet service is a walled garden), have much worse consequencies than learning to roll v6.
Engineers know the facts by now and have no excuse. For more information, see the RIPE NCC’s information site, ipv6actnow.
Here are some slides that present some research undertaken by a number of European Internet Exchange points (IXPs), which I presented at UKNOF15 last week. They may be of interest to networks which connect to IXPs who have been considering connecting to the local multi-lateral peering (MLP) service, but are unsure whether testing has proved that the functionality and performance of the new ‘next-generation’ offerings (namely BIRD and OpenBGPd) are fit for purpose.
The slides show that the new route-servers perform splendidly well compared with traditional Quagga based MLPs, also that route-servers are now free of ‘first generation code’ bugs, and also that they handle your prefixes transparently – as you would expect.
Interestingly, BIRD and OpenBGPd behave identically ‘on the wire’ so IXPs are encouraged to use multi-vendor MLP on their platform for increased reliability and stability. The new breed of route-server code is dependable and tested, so networks that would like to connect should draw confidence from this testing, and IXPs wishing to roll out MLP services should feel confident in the software tested.
Happy peering!
Greetings from Philadelphia! I am presenting as part of the IPv6 at NANOG46 (click here for info of how to watch) at 9:30PM UK time today, or download the IPv6 for Enterprises presentation here, or see information about the other speakers here..
The messages are clear and simple. Working now to get ready for the IPv6 transition will be less expensive and lower risk than waiting for IPv4 starvation to hurt. I interviewed some key enterprises about their specific grumbles but the great news is that most are transitional and already people are working on fixing them.
At 3pm I’ll deliver this lightning talk to the LINX IPv6 Specialist Techical Workshop 2009 on IPv6 Tooling.
It covers :