Multilink PPP: One Big Virtual WAN Pipe
One big problem with using routers for switched WAN services isn't activating a link, but shutting it down when data transfer is done. Most LAN protocols and client-server applications are chatty, carrying on almost incessant messaging to synchronize routing databases and maintain client-server sessions.
Left unchecked, these processes can keep an ISDN link up indefinitely without passing a single byte of application data. Needless to say, all this uptime quickly adds up, especially where charges are based on call duration. Considering that more than 35 percent of WAN costs are related to line costs, the ability to control activation and deactivation of member links in an MLPPP group is crucial.
MLPPP offers two solutions: usage thresholds and spoofing. In the usage threshold scheme, once a circuit becomes idle or the traffic it carries falls below a level predefined by the network manager, MLPPP will automatically remove that circuit from its bundle until demand rises. The problem with the usage threshold approach is that it can be difficult to define threshold levels effectively in bursty environments using chatty protocols. For example, in Novell IPX environments, it can be difficult to gauge the requirements of SAP (service advertising protocol) and RIP (router information protocol) messages.
Spoofing helps address this problem. It is a technique used by routers to filter network traffic. Spoofing keeps unnecessary traffic like session keep-alive messages from traversing the WAN link. Rather than sending these messages over the WAN, the router acts as a proxy and responds to them locally. Once the router takes over the polling and responses for the application, the WAN link can be shut down until it is truly needed.
MLPPP's WAN service independence means users and network managers can be insulated from network service changes. As new WAN services, such as frame relay and ATM become available, MLPPP can be used to incorporate them into logical bundles. To routers, MLPPP looks like a data link protocol; the router doesn't have to deal with the complexity of the various physical connections and switched circuits that MLPPP draws together in its logical pipes. This helps reduce router reconfiguration costs, since a new router interface isn't required when a new WAN service is added.
To network managers, the difference between adding a new circuit or virtual circuit to an MLPPP bundle and adding a router interface is significant. Adding a circuit to a preexisting MLPPP logical pipe is transparent to the network, particularly in switched environments like ISDN, frame relay or ATM. It simply adds bandwidth to the pipe; no additional interfaces or path information is required. In contrast, any change to a physical router interface triggers an update to the routing table of every router involved in the change. In environments where circuits are frequently activated and deactivated, this could generate excessive amounts of network topology changes and much extra work for network managers.
Not only can MLPPP save network managers time and effort, but it also offers an important tactical tool for network designers. It can be used to simplify fault management and build redundancy into the network at low cost.
Along with making use of WAN services already in place, MLPPP is positioned to work with technologies just making it to the real world. The most prominent of these technologies is ATM.
ATM SVCs can be activated and deactivated on demand, much like ISDN circuits. ATM circuits can be included in an MLPPP circuit group as more bandwidth is required. Bundling will become especially useful if lower-speed ATM ports (T1 or T3) become widely deployed.
In the long run, as ATM takes over the enterprise network backbone, things could get more complicated. ISDN, frame relay and ATM will dominate the WAN landscape, with ISDN and frame relay functioning as a feeder technology and ATM serving as the enterprise backbone aggregating ISDN and frame-relay circuits over faster pipes. An ATM pipe at Sonet OC3 speed (155Mbps) can aggregate more than 2,400 64Kbps ISDN B channels.
That is a large amount of bandwidth by today's standards, but thanks to the rise of LAN switching and high-speed LANs, aggregate throughput requirements for the LAN will escalate at an even more rapid rate, reaching tens of gigabits per second in the next few years. To reduce the disparity between the LAN and WAN worlds, network managers will need to aggregate B channels and frame-relay circuits. Inverse multiplexing using MLPPP offers a flexible way to do this.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development