WIX: a Distributed Internet Exchange
Border Gateway Protocol (BGP) is fundamental to the operation of the Internet, because it automates the sharing of routes by a process called advertising. Adjacent routers establish a BGP session and advertise their networks to the other routers. It is a bit like one router saying to another, “Here is my IP address. If you have traffic with any of the following destination addresses, send it to me.” BGP doesn't stop there, though. Routers also share information they have gathered from other routers. They say, “I also know how to get traffic to some other networks. Send that to me as well.”
Typical Internet exchanges are different from the rest of the Internet and use Internal Gateway Protocol (IGP) instead. This protocol does not pass on information to other routers—it only advertises routes within the networks to which it is connected. The router says, “You can send me traffic for these addresses, but you can't pass that address information on to any other routers.”
In 1998, Citylink started work on deploying a BGP/4-based Internet exchange on top of the public Ethernet. One of the key design criteria was a low cost of entry. So the Citylink team took a step back and looked at the exchange problem from a logical point of view: what were the core requirements of an exchange, and how could they use the existing fibre infrastructure to create an environment that would encourage as many people as possible to join? Exchanging traffic via an exchange is called peering.
A key component of Citylink's approach involved placing routers at a customer's point of connection to the fibre infrastructure rather than in a central location. Not a lot of options were available for BGP/4-capable routers, though—you pretty much bought a Cisco or a Cisco (Figure 2).
Because the exchange was distributed, Citylink needed a low-cost mechanism to allow people to peer, and so they started using Zebra on Linux as an alternative routing platform to Cisco.
Because of the limited space in clients' cabinets and the need to be able to buy the same hardware over a reasonable period of time, Citylink now has standardized on two systems. Boards from Soekris Engineering (4501 and 4801) are used for routers up to 30Mb/s, while Nexcom P4 GigE and VIA 100Mb boards are used for 100Mb/s connections and upwards to 300–500Mb/s on a good day. The Linux Embedded Appliance Firewall (LEAF) forms the basis of all software used on Citylink routing hardware.
Customers can use the Citylink routers or whatever suits their needs and budgets. A wide variety are in use—from Dlink and Xyzel at the low end to Juniper and Cisco boxes at the high end. A lot of people also use their own Linux and *BSD boxes. Using PC-based routers does limit the options for network interfaces, but this is not an issue for Citylink, which uses only Ethernet.
In addition to devolving hardware to client's premises, the routing tables for the whole exchange are managed by way of route servers, the operation of which I explain later in this article.
The new exchange was dubbed WIX, the Wellington Internet Exchange. There is a fixed monthly charge for connection, and traffic over the fibre network is free. Because the network often runs right past a potential user's door, it is easy for anyone to connect and peer. And this is exactly what has happened—even end users who could never peer under a traditional model now can. For all exchange users, access to the global Internet still necessitates the purchase of “transit”—access to the global Internet routing table—from at least one ISP.
The open peering approach has made a huge impact on traffic flows and latency. When the Internet first started in New Zealand, the country's single exchange point, at Waikato University, was also the international gateway for the whole country. Two businesses in Wellington wanting to exchange data would send it to their respective ISPs, who sent it upstream to Waikato. The path time for this typically ran 50–200ms. When ISPs began to exchange data directly in Wellington, this rate dropped to 20ms. End-user peering reduced this by another factor of ten, to 2ms.
In addition to shorter and faster network paths, no charges are levied for traffic sent over Citylink by way of the exchange. ISPs never see the traffic, because the exchange directs it through the shortest path to the requesting party.
A number of printing companies peer at WIX and exchange huge publishing files at no cost. One local newspaper runs an FTP server on WIX to which pre-press companies can upload files. Some graphics houses also run media stores for their clients, and these can browsed at no cost, as though they were part of the client's own LAN. These are only a few of the ways that the fibre infrastructure and WIX have helped local businesses to lower costs, expand and innovate.
The distributed exchange environment has been likened to a market square—anyone can trade his or her wares with no cost for participation. Not everyone chooses to peer openly though, and the exchange supports all types of participation. A number of ISPs exchange traffic only with established customers and ignore any other traffic. Some simply use WIX as a neutral point to exchange data with one other party.
About 130 entities are peering at WIX, with close to 1,000 using the Citylink fibre for private purposes or public Internet connectivity. Encouraging peering comes with a downside though—a lot of participants means a lot of routing tables need to be managed.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide