Inner Workings of WANPIPE
From the start, Linux has been the operating system of choice for network appliances—devices that provide services such as network address translation (NAT), firewalling, virtual private networks (VPN), mail services and web caching. It was therefore a natural requirement, from the earliest days, that Linux provide internal support for wide area network (WAN) connectivity.
In 1994, Sangoma began developing its WANPIPE code and utilities for Linux to supplement drivers that had been written by third parties to support Sangoma WAN cards.
WANPIPE supports the Sangoma S series. Included in this series are cards such as the S514 PCI and S508 ISA—intelligent adapters that support most WAN protocols in firmware, including Frame Relay, PPP, HDLC, X25 and BiSync.
Because protocols are supported in firmware, design of the device driver is much simpler. It is easier to port to a new operating system as there are fewer chances of failure and CPU load is kept to a minimum. These characteristics enable a relatively slow machine like a 486 to use a Sangoma adapter and Linux to create a powerful T1 router.
With protocols isolated on the board, it is possible to test and certify the protocol implementations of one operating system and know that they will work identically on any other operating system. If necessary, a protocol update can be installed on the fly, without recompiling the driver or the kernel.
Sangoma adapters can have two different physical interfaces, T1 (CSU/DSU on board) or serial V.35/X.21/EIA530/RS232. The card with the T1 interface allows the server to connect directly to the T1 line without an external CSU/DSU.
Sangoma S514 and S508 cards support up to four high-speed sync lines, each carrying a multichannel WAN protocol. The driver architecture was based on the following requirements:
Multi-adapter support, where each adapter can have up to four physical links
Each link can have a maximum of 255 logical channels
Control and configure each link separately
Control and configure each logical channel separately
Support multiple protocols: Frame Relay, CHDLC, PPP, X25, SDLC, etc.
Easily expandable (future protocols)
Support for both Routing and API applications simultaneously
Secure socket for API applications (No silent packet dropping allowed)
Local and remote debugging support
Fast Tx and Rx paths
Proc file system support: statistics and debugging
Driver Message/Event Logging
Easy updates and upgrades
The following design rules were adopted in developing the driver:
1. WANPIPE drivers map each active physical link to a separate device in the kernel. Each physical line can be configured, restarted or debugged without conflicting with other sync lines. WANPIPE drivers can support up to 16 devices, four cards with four physical links.
2. Since WAN protocols can have many logical channels on a single physical link, each channel is mapped to a network interface. WAN protocols, such as Frame Relay or X.25, support one-to-many connections through the use of logical channels. For each physical line, WANPIPE supports up to 255 logical channels for X.25 and 100 logical channels for Frame Relay. Each logical channel can be restarted or reconfigured without bringing down all other channels on the same physical link.
3. Management/debugging interface calls are user datagram protocol (UDP) based and OS independent. Sangoma adopted a common UDP-based interface for collecting statistics and managing WAN links to provide an alternative to SNMP-based tools that are often complicated and costly. Sangoma felt that users should be able to easily interrogate and manage the system remotely, using tools that are included in the WANPIPE package.
The system developed is UDP-based and operating system independent so that, for instance, a Windows GUI application can be used to monitor a remote Linux system. The system is password-free but can be made to operate in a highly secure manner.
4. Each network interface can support either API or ROUTING mode. Aside from IP routing, many of Sangoma's customers use the Sangoma S series as communication building blocks for their own applications, using our published applications program interfaces (API). These applications include such diverse uses as:
Providing unidirectional broadcasts of financial information and newscasts over satellite links.
Monitoring cellular switch information using X.25.
Emulation of IBM mainframes or controllers over SDLC, X.25 or BSC.
Controlling military hardware using HDLC LAPB.
For maximum flexibility, the architecture was designed so that API calls and standard IP routing traffic can coexist on any physical port. For instance, a set of X.25 logical channels can be used to provide standard IP connectivity between a series of locations while other channels are used to exchange point-of-sale (POS) credit card swipe information that is not IP-based. The driver can accept API or routing packets simultaneously, depending on the network interface setup.
5. No API packets to be dropped by the stack. IP stacks are designed to silently discard packets when congested. This is accepted behavior in the IP world, where data integrity is ensured by higher-level TCP protocol. However, in the case of error-correcting protocols such as BSC, HDLC LAPB, X.25 and SDLC, it is assumed that once a packet has been acknowledged at the link level, delivery to the application is guaranteed. Therefore, it was absolutely necessary that the WANPIPE raw socket stack would not silently drop packets.
6. WANPIPE device drivers should be loaded as modules into the Linux kernel.
Using modules, rather than compiling the kernel, makes it easy to update the driver. Also, because only the modules need to be compiled, no reboot is needed.
Employing the above design rules, WANPIPE device drivers maximize the utility of the S series cards. Clearly defined data, debugging and (re)configuration paths enable simultaneous multiprotocol operation to be efficient, configurable and manageable. The design of the driver is shown in Figure 1.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- 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