Configuring ATM Networks
The Linux ATM software (device driver and utilities) is developed and supported by Werner Almsberger in Switzerland as part of the Linux-ATM API software set (see Resources). This software contains device drivers for the following ATM adapters: Efficient ENI-155P, SMC ATM Power 155, Rolf Fiedler's TNETA1570 board, Zeitnet ZN1221/ZN1225 and the IDT 77901/77903 155 and 25 Mbps adapters. Also, a driver for the Fore PCA-200E ATM adapter is available separately (see Resources). The two adapters I have experience with are the Efficient ENI-155p and the Fore PCA-200E.
The National Institute of Standards and Technology (NIST) uses ATM and Fast-Ethernet networks as interconnects in its scalable cluster computing initiative. One research area is evaluating the benefits of ATM and Fast-Ethernet networks in this cluster environment.
In this article, I will tell you how to obtain and install the ATM support software and device drivers. I will also describe how to configure the ATM connections on the PCs and the switch to be used for IP network traffic.
The ATM interface cards I use are ENI-155P ATM adapters produced by Efficient Networks and PCA-200EPC adapters from Fore Systems. These cards are installed in standard Pentium or Pentium-Pro-based PCs running Linux. The ATM switch I used for this article is a Fore ASX-1000, although the information I give applies to all of the Fore ATM switches. This switch can be set up to allow the Linux workstations to use IP over both Switched Virtual Circuits (SVC) and Permanent Virtual Circuits (PVC).
The ATM software is available from http://lrcwww.epfl.ch/linux-atm/. The software is packaged as a compressed, gzipped tar file. Each version of the software is tied to a specific version of the Linux kernel. For this article, I used version 0.35 running on Linux kernel 2.1.90. The size of the ATM software distribution is roughly 500KB. The device driver for the Fore PCA-200E adapter can be obtained by anonymous FTP from ftp://os.inf.tu-dresden.de/pub/pca200e/. Refer to the README file in the PCA200 distribution for further information.
The driver portion of the Linux-ATM software, as well as the changes to the Linux kernel, are shipped as one large patch file. Therefore, adding support to the Linux kernel for ATM is straightforward: apply the kernel patch, configure and rebuild the kernel in the usual way. The ATM configuration items you must have are:
Asynchronous Transfer Mode (ATM) (CONFIG_ATM)
Classical IP over ATM with ATMARP (CONFIG_ATM_ATMARP)
Device driver, one of the following:Efficient Networks ENI155P (CONFIG_ATM_ENI)ZeitNet ZN1221/ZN1225 (CONFIG_ATM_ZATM)Rolfs TI TNETA1570 (CONFIG_ATM_TNETA1570)IDT 77201 (NICSTAR) (CONFIG_ATM_NICSTAR)
I recommend starting with a fresh Linux kernel source tree before applying the ATM patch. Refer to the USAGE file that is part of the Linux-ATM software, as things may change. All of the device drivers in the distribution can be built as kernel modules or as part of the kernel object itself. If you are using a Fore PCA-200E adapter, you do not select a driver during the kernel configuration. The PCA-200E device driver is built as a module separately, as specified in the README file included in the PCA200 distribution.
After the kernel is patched, rebuilt and installed, you are ready to build the ATM support software. Again, refer to the instructions in the USAGE file. One change I recommend is installing the support files in /usr/local/atm-version/bin and creating a soft link from /usr/local/atm to the actual install directory. By using the soft link, you can change ATM software levels and back them out, if needed, without changing the configuration scripts.
You are now ready to configure the IP over ATM. First, you must decide what type of “virtual circuits” to use to connect the machines. ATM is a point-to-point, switched technology; in order for two hosts to communicate, a virtual circuit must be established between them.
Switched Virtual Circuits (SVCs) are connections that are established dynamically and torn down when the connection is no longer needed. However, a high latency is associated with establishing a connection. Also, SVCs are deleted after a timeout period if no traffic is sent over the connection. Therefore, the latency associated with SVCs is not always predictable. I encountered several problems when using SVCs, such as connections not being established or sometimes failing to remain open.
Permanent Virtual Circuits (PVCs) are established and kept open. Thus, no latency is associated with establishing the connection, as there is when using SVCs. The disadvantage of PVCs is that the switch must be configured to establish all the connections between the hosts. When you have several hosts and each host needs to communicate with all the others, the number of PVCs required within the ATM switch grows rapidly. Specific configuration information for SVCs and PVCs is discussed later, but I will jump ahead a bit in order to complete the IP configuration now. The steps to configure the ATM interface are as follows:
Start the ATM software daemons with these commands:
atmsigd -b ilmid -b atmarpd -b
Create the ATM device name:
atmarp -c atm0
Configure the ATM interface for IP:
ifconfig atm0 ipaddr netmask netmask mtu mtu
Add the route for the ATM subnet:
route add -net network netmask netmask atm0
Create a permanent ATM ARP (address resolution protocol) cache entry for the ARP server:
atmarp -s arpserver arpsrvnsap arpsrv
ipaddr is the IP address of the ATM interface, netmask is the network mask and network is the IP address of the network to which we are connecting. arpserver is the IP address of the ATM ARP server and arpsrvnsap is the ATM address of the ARP server. The ATM ARP server is used to convert an IP address to an ATM network service access point (NSAP) address. (The NSAP address is similar to a media access control (MAC) address and is 20 octets long.) The NSAP address is needed to establish SVCs between nodes. You can also create an /etc/hosts.atm file to contain the IP to NSAP mapping, allowing for quicker IP to NSAP translations. For my network, I use the Fore switch as the ARP server. The atmarpd daemon maintains a cache of IP to NSAP mappings. The atmarp command makes the ARP cache entry permanent when the arpsrv option is used.
One final note: if you are going to use PVCs only, you do not need to start the atmsigd and ilmid daemons. Listing 1 contains a complete example of configuration commands.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- 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
- Doing for User Space What We Did for Kernel Space
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