Linux-ATM support.

[Lamar Owen]

On Saturday 31 July 2004 12:04, Alan Cox wrote:
> On Sat, Jul 31, 2004 at 11:29:50AM -0400, Lamar Owen wrote:
> > and it has CONFIG_ATM unset, too.  My question to the kernel maintainers
> > here (Arjan, Alan, and Dave) is simply 'Why no ATM?'  The ATM support is
> > actively maintained, is production quality, etc.

> That is good to hear. Can you tell us which cards and setups you've tested

I currently have a Dell PowerEdge 1600SC (2.4GHz Xeon, 1GB RAM, 66MHz 64-bit 
PCI slots) running the FC1 kernel with the shipped he drivers, 
linux-atm-2.4.1, and a Fore HE622 OC-12 card connected to a 3Com CoreBuilder 
7000 OC-12 interface.

I know the kernel configurator says it's EXPERIMENTAL; I'm just not sure 
that's the case any more.

I have many more cards; I am able to test Fore PCA-200, Fore LE, IBM 
Interphase 5155, and a few others.  For obvious reasons the HE622 support is 
the most important to me for server/firewall use.

Chas Williams is the HE maintainer for both the 2.4.x series kernels and the 
2.6.x series kernels, and has updated the he driver pretty well during 2.5.x 
and 2.6.x development.  While the userland tools have not had a release in a 
year, the tools are fairly stable, and CVS commits have occurred pretty 
recently.  It is fairly mature technology, judging by the linux-atm list 
traffic.

But, since the ATM configuration was not included in the FC2 kernels, it makes 
it difficult to test there.  I am assuming that there was a good reason for 
not inlcuding the ATM config, but Arjan or Dave will have to answer that 
question, as the changelog in the FC2 kernel doesn't mention a reason, nor 
does it mention that the CONFIG_ATM option is even unset.  It doesn't even 
mention ATM at all....

> > I am looking at system-config-network too for ATM support; I know this is
> > not a RedHat-supported item, but it is something I will need at some
> > point, since I want native ATM networking available to some of my users.

> I can't see it ever becoming Red Hat supported (unless there is strong RHEL
> customer demand). For Fedora however the big problem is knowing if it
> actually works.

ADSL PPPoA connections are ATM; having full-bore tools can help there too, 
unless the PPPoA stuff is separately supported. (ADSL is a B-ISDN ATM 
technology, after all, and high-bandwidth Internet connections at OC-3, 
OC-12, and higher rates are typically POS (Packet over SONET) or ATM (my 
local ISP quotes OC-3 connections, and prefers ATM CLIP delivery)).

So ATM features are more Enterprise than hobbyist, but having robust ATM 
networking for CLIP over PVC and SVC as well as LANE support could raise some 
interest in high-bandwidth applications.  

In my case, the server that the HE card is in needs to associate with multiple 
ELANS for firewall and routing purposes; ATM NIC's are great for that sort of 
thing, since I can set up a CLIP VC and two or more LEC's on the one card; 
but as far as the kernel is concerned they are physically separate 'ethernet' 
interfaces.

The problem ATM has faced in the past is a combination of cost and complexity.  
Cost is going down, and enterprise-class switches routinely turn up on eBay 
at a fraction of their retail cost (hrmph, I've seen several Nexabit NX64000 
switch/routers capable of OC-3072 internal speeds routing 6.4Tbps regularly 
cross eBay for ~$2,000, even Juniper and Cisco equipment at OC-12 and OC-48 
speeds are relatively affordable).  The complexity is a turn-off, but a good 
GUI to the linux-atm stack and good support of that stack could flatten the 
learning curve substantially.  After all, without any help, I brought up a 
five-switch fully redundant ATM network with multiple ELANS and LECS/LES/BUS 
automatic failover in just a few months (and, while my title is IT Director, 
I am basically the entire IT department, and do everything from terminating 
fibers to writing software).  It just wasn't that hard.  And it impresses 
people to no end when I physically pull an OC-12 trunk fiber out of a switch 
port and the switch transparently reroutes over the other fibers....
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu