IP over ATM is supported with Classical IP over ATM (CLIP, defined in RFC1577 [RFC1577], LAN Emulation (LANE, defined in [lanev1] and [lanev2]) and Multi-Protocol Over ATM (MPOA, client only, defined in [mpoav1]).
A demon process is used to generate and answer ARP queries. The actual kernel part maintains a small lookup table only containing partial information.
Man pages: atmarpd(8), atmarp(8)
atmsigd and ilmid
must already be running when atmarpd is
started. Use the -b
option to make sure they're properly synchronized,
e.g.
The atmarp program is used to configure ATMARP. First, you have to start atmsigd, ilmid, and atmarpd, then create an IP interface and configure it:
e.g.If only PVCs will be used, they can now be created with a command like
NULL encapsulation is used if the null
keyword is specified.
Note that ARP requires LLC/SNAP encapsulation. NULL encapsulation can
therefore only be used for PVCs.
When using SVCs, some additional configuration work may be necessary. If the
machine is acting as the ATMARP server on that LIS, no additional
configuration is required. Otherwise, the ATM address of the ATMARP
server has to be configured. This is done by creating an entry for the
network address with the option arpsrv
set, e.g.
Note that the ATMARP server currently has to be started and configured before any clients are configured.
The kernel ATMARP table can be read via \path{/proc/net/atm/arp}. The table
used by atmarpd
is regularly printed on standard error if atmarpd
is started with the -d
option.
If atmarpd is invoked without
-d
, the table is written to the file
atmarpd.table in the dump
directory (by default /var/run; can be
changed with -D
), and
it can be read with atmarp -a.
Besides Classical IP over ATM, LAN Emulation (LANE) can be used to carry IP over ATM. LANE emulates the characteristics of legacy LAN technology, such as support for broadcasts. LANE server support is described in the src/lane/USAGE file in the linux-atm distribution.
Man pages: bus(8), lecs(8), les(8), and zeppelin(8)
If you plan to run more than one LANE clients, LANE service or LANE clients and LANE service, you need to specify different local ATM addresses for each demon. Since all the LANE demons use similar service access points (SAPs) they need different ATM addresses to differentiate between connections.
Just as with CLIP, the LANE client consists of two parts: a demon process called zeppelin which takes care of the LANE protocol and kernel part which contains LANE ARP cache.
atmsigd and ilmid must already be running when zeppelin is started. When zeppelin starts, the kernel creates a new interface which can then be configured:
In the example below, two LANE clients are started. The first client
uses default interface lec0,
default listen address and tries to
join the default ELAN. The other LANE client gets interface
lec2
assigned to it, binds to local address
mybox3
, tries to join
ELAN called myelan
and will bridge packets between ELAN and
Ethernet segments. Address mybox3
is defined in
/etc/hosts.atm. Rest of the bridging can be configured
by reading the Bridging mini-HOWTO. [bridge-howto]
# zeppelin & # ifconfig lec0 10.1.1.42 netmask 255.255.255.0 \ broadcast 10.1.1.255 up # # zeppelin -i 2 -l mybox3 -n myelan -p & # ifconfig lec2 10.1.2.42 netmask 255.255.255.0 \ broadcast 10.1.2.255 up |
By default, zeppelin uses interface lec0, binds to local ATM address using selector byte value 0, tries to contact LECS using Well-Known LECS address, joins the default ELAN as defined by the LECS, accepts the MTU size as defined by the LES and will not act as an proxy LEC. These parameters can be tailored with command line options which are defined in zeppelin(8).
zeppelin will automatically join any ELANs which use higher MTU than the default MTU of 1516 bytes. The MTU of the LANE interface will adjust itself according to the MTU of the current ELAN.
The state of the LANE ARP cache entries can be monitored through /proc/net/atm/lec. For each entry the MAC and ATM addresses and status is listed. If the entry has an active connection, the connection identifiers are also listed.
The LANE service ( lecs(8), les(8), and bus(8)) is configured using configuration files. The configuration file syntax is listed on the respective manual pages.
A more detailed description of Linux LANE services is discussed in Marko Kiiskilä's Master's Thesis [kiis].
The Linux MPOA client continues the tradition of user space -- kernel divided ATM services. The demon process called mpcd processes MPOA control packets while the kernel holds MPOA ingress and egress caches and does the packet forwarding.
Man page: mpcd(8)
atmsigd and ilmid must already be running when mpcd is started. Since MPOA detects IP layer flows from LANE traffic, you need to have zeppelin running before MPOA can function. However, the order in which zeppelin and mpcd is started is not fixed. You can kill any of the demons at your will and restart it later without need to restart the other demon. The easiest way to disable MPOA is to kill the running mpcd.
Below is the example from Section LAN Emulation which starts two LANE clients. The configuration has been augmented with two MPOA clients which the LANE clients will serve.
# zeppelin & # ifconfig lec0 10.1.1.42 netmask 255.255.255.0 \ broadcast 10.1.1.255 up # mpcd -s mybox1 -l mybox2 & # # zeppelin -i 2 -l mybox3 -n myelan -p & # ifconfig lec2 10.1.2.42 netmask 255.255.255.0 \ broadcast 10.1.2.255 up # mpcd -i 2 -s mybox4 -l mybox5 & |
The MPOA demon needs two different local ATM addresses which it uses when initiating and receiving data and control connections. The addresses can be the same as with e.g. zeppelin but must be different among other mpcd demons. By default, mpcd does not retrieve configuration information from the LECS. The necessary command line options and an example of using LECS are shown on the mpcd manual page. The manual page also lists the rest of the available options.
The contents of MPOA ingress and egress caches can be monitored through the /proc/net/atm/mpc file.
The Linux MPOA client also supports CBR traffic class for shortcuts SVCs instead of default UBR. The QoS specifications for future shortcuts can be set and modified using /proc/net/atm/mpc.
# echo add 130.230.54.146 tx=80000,1600 rx=tx > /proc/net/atm/mpc # # generate enough traffic to trigger a shortcut # cat /proc/net/atm/mpc QoS entries for shortcuts: IP address TX:max_pcr pcr min_pcr max_cdv max_sdu RX:max_pcr pcr min_pcr max_cdv max_sdu 130.230.54.146 80000 0 0 0 1600 80000 0 0 0 1600 Interface 2: Ingress Entries: IP address State Holding time Packets fwded VPI VCI 130.230.4.3 invalid 1160 0 130.230.54.146 resolved 542 151 0 109 ... |
130.230.54.146
was established with
the parameters shown above. There also exist patches which extend the
flow detection to fully support layer 4 flows. The layer 4 flows are
expressed as a 5 tuple (proto, local addr, local port, remote addr,
remote port) and they identify application to application flows. If
you are interested, see
ftp://sunsite.tut.fi/pub/Local/linux-atm/mpoa/
for the latest
patch.