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.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader 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