Configuring ATM Networks
The ATM switch configuration commands I use apply to the entire family of Fore ATM switches, because they all have a similar command interface.
When using SVCs, a host must pass information to the ATM switch, declaring its intent to set up a connection with another host. The term for connection setup is “signaling”. The ATM protocol used between a host and a switch is the user-network-interface (UNI) signaling standard. There are several revisions of the UNI standard. The Fore ATM switch supports UNI 3.0, 3.1 and 4.0. The Linux-ATM software also supports these versions.
However, there are standards and there are implementations. In setting up our SVCs, I encountered several problems with UNI 3.0 signaling. The UNI 3.1 signaling was more stable and reliable. To change the signaling on the Fore ATM switch, each port must be changed individually, using the switch control processor (SCP) command interface.
First, log on to the SCP via a TELNET session or by using a terminal attached to the serial port on the Fore switch. The command syntax used here is the same as Fore's. Required parameters are shown between “<” and “>”; options are enclosed in brackets (“[” and “]”); modifiers to options are enclosed in parentheses. One of the modifiers must be chosen.
Change to the UNI configuration menu:
localhost::> conf uni
The switch prompt is shown in italics, while the command is shown in normal text.
The command show will list the current UNI status for each port. If the port is already configured for UNI 3.1, no change needs to be made. Otherwise, you must first delete the current configuration. The syntax for the delete command is del port vpi, where port is the switch port and vpi is the virtual path identifier (usually 0). To delete the signaling on port 1A1 for VPI 0, you would enter this command:
localhost::configuration uni> del 1a1 0
Now you are ready to configure the port for UNI 3.1. The syntax for the new command is:
new <port><vpi> [auto | uni30 | uni31] [-ilmi (up | down)]The ilmi option is used when you want the port to respond to integrated local management interface (ILMI) requests. ILMI is used by the hosts to obtain the ATM NSAP address assigned to the host. You usually want to have ILMI active for the port, so the command for port 1A1, VPI 0 is:
localhost::configuration uni> new 1a1 0 uni31 -ilmi upNow that the ATM switch ports have been configured, the software on the workstation must be set up. The key portions of the Linux-ATM software are three daemons: atmsigd to handle signaling (UNI), ilmid to handle ATM address registration and atmarpd to map ATM addresses to IP addresses. Listing 1 is the startup script I use to start the ATM daemons and to configure the ATM interface on a host. This script can be called from a system startup script (/etc/rc.d/rc.local, for example) to configure the ATM interface at boot time.
The ATM signaling daemon, atmsigd, must be compiled specifically for the version of signaling you wish to use and must be compatible with the signaling version the ATM switch port has been configured to use. The default version used in the ATM software is UNI 3.0. If you've configured the switch to use UNI 3.1, having the hosts use UNI 3.0 will most likely work, due to backward compatibility. However, I recommend you configure the Linux-ATM software to use the same version as the switch, UNI 3.1.
To have the signaling daemon use UNI 3.1, edit the Rules.make file in the ATM source directory ( /usr/src/atm if you follow the steps in the USAGE file). You need to change the STANDARDS line to specify the version of signaling to support. For UNI 3.1, this line should be: STANDARDS=-DUNI31.
If you are using Efficient ENI-155p ATM cards, the number of simultaneous virtual channels available is limited. The ENI card performs the segmentation and reassembly (SAR) of ATM cells by using memory on the adapter card as a buffer. The host ATM software allocates buffer space for each virtual channel. If you attempt to open more SVCs than are supported by the available buffer space, you will receive this error message from the ATM ARP daemon:
atmarpd:IO: connect: No buffer space available
When IP over ATM is used, the device driver sends packets to the ATM card using an ATM Adaptation Layer (AAL). While several adaptation layers are available, AAL-5 is used for IP. The AAL-5 packet is a type of service data unit (SDU) and is somewhat analogous to an Ethernet frame. The AAL-5 packets are divided into individual ATM cells by the Efficient ATM adapter.
The MTU (maximum transmission unit) size for the ATM interface depends on the SDU size. The IP over ATM (Classical IP) specification says that the MTU should be no larger than 9180 bytes. There are also 8 bytes for an AAL-5 trailer, so the SDU for IP over ATM is 9188 bytes in the default configuration. The amount of buffer space needed on the card depends on the maximum SDU size.
The Linux-ATM software allocates three times the maximum SDU size, rounded up to the nearest power of two. In the default configuration, this allocation results in 32KB of buffer space being reserved for each ATM connection (9180 x 3 = 27540, rounded to 32768 bytes). Also, using classical IP causes two SVCs to be made: the initiating machine opens an active connection to the target machine and the target machine opens an active connection back, that is, a passive connection on the initiator. Therefore, these two connections result in the allocation of two buffers on the ATM card, for a total of 64KB.
The default configuration allows a host to have a maximum of fourteen simultaneous connections when using the “client” version of the ENI-155p ATM card, which has 512KB of memory and 504KB of memory available for the SAR buffers. These fourteen connections allow communication using IP over ATM to seven other hosts when using SVCs. If you set up PVCs, you can communicate with fourteen other hosts. When using an ARP server, you have one less connection available, reducing the host count by one as well. The “server” version of the ENI 155p card has 2MB of memory, with 2040KB for SAR buffers, allowing for more simultaneous connections.
To increase the number of simultaneous connections for classical IP, you need to change the size of the maximum SDU set on the ATM interface. By using the allocation rule given above, you can estimate the amount of memory needed for the connections. For example, if you want to use 16KB for each connection, the maximum SDU would be 16384 divided by 3, which is 5461 bytes. I'll use an SDU of 4352 bytes for my example in this article.
The maximum SDU is specified as an option to the ATM ARP daemon. However, when the SDU is changed, the IP interface must also be configured to have an MTU of the same size as the SDU, minus 8 bytes for the AAL-5 trailer. Therefore, in my example the MTU is 4344 bytes.
A potential problem occurs when changing the maximum SDU for the interface: the ATM ARP daemon (atmarpd) may not communicate with the ARP server on the Fore switch. Our switch would accept only connections with an SDU of 9188 bytes. The fix for this problem is to create a permanent ARP cache entry on the host, specifying the maximum SDU of 9188 bytes, for the connection to the ARP server. The steps for configuring the ATM software on the workstation are as follows:
Configure the IP interface for your MTU size, 4344 bytes in my example:
ifconfig atm0 ipaddr netmask netmask mtu 4344
Create a permanent ATM ARP cache entry for the ARP server with SDU size of 9188:
atmarp -s arpserver arpsrvnsap qos \ ubr:sdu=9188 arpsrv
Configure the SDU (MTU plus 8 bytes) on the ATM interface:
atmarp -q network ubr:sdu=4352
Refer to Listing 1 for a complete example of configuring the ATM software for the Efficient adapter.
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!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- 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