Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet Software Hardware Linux

ATM Adapters for Linux? 62

Posted by Cliff from the penguins-on-reasonably-fast-pipes dept.
Raxxon asks: "I've been working with some guys in my company laying the groundwork for our next phase of network upgrades. We're looking at having an ATM feed for the main pipe but we're unsure of the Linux ATM support. I know that the firewall code is good (and plentiful) and that for an Ether/Ether or Ether/WAN (frame, DSL, etc) it's great, but with limited knowledge of how well Linux handles ATM, I'm a bit worried about suggesting this as an interface on the router/firewall given that we can convert it back to Ethernet (and in 60% of the case, it's going to stay ether anyway). What's the current state of Linux ATM and is it really worth it?"
This discussion has been archived. No new comments can be posted.

ATM Adapters for Linux? More

ATM Adapters for Linux?

Comments Filter:
  • What is the state of ATM, and is it worth it? I have worked with ATM several times, and keep coming back to the basic opinion that it stinks. Just like Token Ring stinks.

  • From the grooveyard of forgotten classics... (Score:1, Interesting)

    by Anonymous Coward

    A while back [maybe 1997/1998], there was one of those glossy magazines [in the ComputerWorld/InfoWorld/InformationWeek genre] that did a HUGE review of ATM cards [like 25 or more], on a huge variety of OS's [NT, NetWare, OS2, etc.] and concluded they ALL sucked, and refused to endorse any of them.

    Since I can't even remember the name of the now defunct glossy magazine, I'm not doing you much good, but after reading the review, I've always been prejudiced against ATM on the desktop.

    Then I was talking to

    • Re:From the grooveyard of forgotten classics... (Score:1, Funny)

      by Anonymous Coward

      ATM doesn't even perform error checking on its packets - i.e. ATM freeloads off the software error checking way up the TCPIP stack

      Neither does Frame Relay or HDLC. Ethernet is better in that it detects errors anywhere in the packet, but it still doesn't correct them. The hell with speed! Everyone should use X.25 for everything. Now that we're enlightned we realize that we don't want faster, cheaper networks! What we really want is networks that perform packet level error checking so that that IP stack do

    • I have news for you - IP and Frame Relay don't do per-packet error checking either, and that's a *feature*. One big innovation introduced by Frame Relay when it superseded X.25 was precisely this dropping of link level error checking - the point being that digital lines were reliable enough that it wasn't a problem to only do error checking end to end. X.25 people still say it's better to do this but it proved expensive and slowed down the switch hardware.

      ATM has many issues including complexity, switche

  • Possibly up to the task... (Score:5, Informative)

    by ComputerSlicer23 ( 516509 ) on Saturday August 30, 2003 @12:19PM (#6833228)
    Well, I know that there have been ATM drivers in the kernel since 1.2 series at least (when I started using Linux). I believe that there are any number of comercial routers based on linux which do ATM. The old LRP (Linux Router Project), always talked about how you could use it to do anything from ATM to dialup banks, to firewalling. That it could handle a T1, or ATM if you had the proper card.

    LRP died a while ago (at least thats the impression I get), and some guys followed it up with LEAF. I'd check that out. I believe it's leaf.sourceforge.net.

    I have no idea where you would get cards for it, but I'd buy 3 or 4 of them (to have redundant cards, and a one in a failover machine). I'd imagine the leadtime on a part like that could be a bit brutal (it's not like you just go pick one up down at the local CompUSA). So it's at least a day out, possibly two at the soonest.

    If the driver is good, Linux is easily up to the task of doing nearly anything you want it to in terms of routing. Other then the proprietary Cisco protocols, it does nearly everything other good routers can on similar hardware.

    Kirby

    • Re:Possibly up to the task... (Score:5, Informative)

      by MerlynEmrys67 ( 583469 ) on Saturday August 30, 2003 @12:49PM (#6833411)
      If the driver is good, Linux is easily up to the task of doing nearly anything you want it to in terms of routing. Other then the proprietary Cisco protocols, it does nearly everything other good routers can on similar hardware.

      Well the last point is correct - on similar hardware. However many times when you start wanting to go fast (and by fast I mean multiple Gig interfaces, General Purpose Hardware just doesn't cut it... The PCI bus (and by that I mean PCI-X or PCI-EXPRESS) is not fast enough to handle the traffic, so your box can not keep up with the interfaces.

      Linux works well as a replacement for low end routers, a handfull of 100Mbit interfaces... but if you are talking a real router with several 1Gbit interfaces and a couple OC-12/OC-48 connections out to the real world - General Purpose Hardware just won't cut it, and you need to get a real router from a company that has spent the bucks developing the ASICs and cross connects to handle the throughput for you

      • Well the last point is correct - on similar hardware. However many times when you start wanting to go fast (and by fast I mean multiple Gig interfaces, General Purpose Hardware just doesn't cut it.

        I couldn't agree more. If you find support for ATM under Linux it is most likely done for the sake of doing it or to run on hardware designed to be a router. ATM only makes sense when you're shoving around LOTS of traffic. It's one thing to use PCs for routers when you're talking traffic up to a few Mbits. After

      • Re:Possibly up to the task... (Score:5, Informative)

        by ComputerSlicer23 ( 516509 ) on Saturday August 30, 2003 @01:24PM (#6833678)
        Yeah, I just got my first set of Gigabit cards a while back... You are way out of my realm of experience. Linux can easily route a T1, probably could do a T3. It can route simple situations pretty darn fast. Two network cards, anything that comes in on one gets passed to the other, modulo a spoof filter.

        I really meant it could do BGP/OSPF and get you real redundant backup links. It can easily do the Multi-homing. It can easily do all the filtering. It can easily do stateful firewalling (with 2.4 at least). It can do pretty sophisticated IP configuration (local/global IP's/Links, the same IP on several cards). It can do policy routing. It can do bandwidth shaping. It can do channel bonding. It can do redundant failover (vrrpd). It can do VLAN's. It can do VPN. It can do IPv6. I can do IPSec (with patches). It can do tunneling. It can do virtually anything you want it to, that involves relatively low bandwidth. If you are talking about slower then T3 speeds, and you trust the Linux drivers for your hardware, there is very little need for Cisco equipment. I wonder when someone will finally build out the hardware and put Linux on it, and leverate Linux as the software and give Cisco a run for their money.

        Kirby

        • You're right in what features Linux networking syssection has. The features scale up to what Packeteer has (20000$ piece of equip).

          Still the statements about the PCI architecture doesnt have enough bandwidth is 100% correct. Even 64Bit PCI cannot handle more than 2 or 3 of those cards. There's just not enough PCI bandwidth to keep a gigabit card buffers full.
          • I don't believe Linux does everything that Packeteer does (TCP rate shaping etc, which is per-flow based and fiddles with ACKs etc). However, if you want the equivalent of what most people use Cisco routers for, including full routing and QoS, you should be fine. A suitable routing oriented distro would be best - or you can just buy Imagestream routers which are 'like Cisco' in capabilities but fully Linux based.

      • Last I checked the PCI bus (when in 64Bit mode) was capable of multi-gigabit speeds. Given that I'd be looking for a single OC3, possibly a dual, there should be NO problems with it.

        Heck, from what you're saying I can do 66% the number of 100Mbit feeds if I stick with OC3 just fine.... ;) it's only 155Mbit at that point. If I were talking about OC12 or 48... *shudder* That's just damn scary.
  • Considering you said ATM, my first thought was Automated Teller Machines - which run on an OS/2 package.

  • Linux ATM works (Score:4, Informative)

    by doozer ( 7822 ) on Saturday August 30, 2003 @02:30PM (#6834047) Homepage
    In later 2.4 and 2.6 kernels, alot of stuff was cleaned up, and it
    works quite well now.

    Interphase makes a couple of fairly nice cards (the 5575 and 5576)
    that work under linux.
    • Great now SCO will take credit for THAT too! :-p
    • I'll have to check them out...

      Has anyone used these cards that can give direct feedback on their quality/durability/usablilty?
      • I've only been using them for a few months, so I'm not sure of the long term durability of them.

        There are drivers in the stock kernel for the 5575, and Interphase supplies half-and-half
        drivers for both the 5575 and 5576 which work even better (and support stuff like VBR and
        the failover capabilities of the 5576)

        The 5575 can do 4096vc while the 5576 with full memory can do 64k. The 5575 only supports using a
        single PVC at a time, while the 5576 is a little more flexible.

        Driving the 5576 at line rate using t
  • I bought two ATM cards, Madge Collage Horizon cards to use back to back to start up using ATM. All kernels I tried simply crashed and this was maybe a month ago. Yes I tried different computers, removing all options from the kernels, different compilers etc. I tried 2.4.0, 2.4.5, 2.4.20, 2.4.21, 2.5.75 and a pre version of 2.6. I joined the mailing list where they said not much could go wrong there.

    I suggest you buy and try the cards and networks before deciding to implement it. I've ordered more (Efficien
    • I thought those old IBM things were only the 25mps ATM. Which isn't even real ATM, as far as I've ever been able to tell.

      I have a Cabletron SmartCell zx250, and I use the 32bit pci Fore cards... can't remember the model # at the moment. I only got them because I like to play with weird networking stuff... but I have had some minor success. Driver's load at least, and I get the equivalent of a link light. My understanding of AAL5 and LANE isn't good enough, I fear, to do anything truly interesting.

      On the
      • I like to play with weird networking stuff

        I know where you're coming from. Ive got a 2-hub Tokenring, arcnet (remember that?) FDDI and framerelay setup at home (and of course ethernet and 802.11). I tried the hardest and had the least luck with the 25-speed ATM cards (I still have 5 of em).Yeah I got the driver to work well in the kernel with lights on, but atmsigd always crashes. I tried various kernels, atm tools versions, and various library versions that the atm tools depend on.

        I'm waiting on some
        • Arcnet is what I use to network my Amigas. I really want the TRS-80 Model 2/16 arcnet card though.

          I haven't gotten a FDDI concentrator yet, but do have the nics. Also have an extensive, even obscene localtalk network. Macs, apple2s, a Newton, linux/x86, NeXTstation, and possibly an SGI.

          And, I do have that 2slot sbus HIPPI card... too bad I can't find more gear to build it.

          Good luck on the ATM, but what switch are you using? I've yet to see a switch that will do both 25mps and 155mps... lord knows I'd lo
          • <i> localtalk network</i>
            <br>What in the world... I missed one networking technology.
            <br><i>Macs, apple2s, a Newton, linux/x86, NeXTstation, and possibly an SGI.</i><br>
            Ive got ultrasparc and sparcs, planning to get an iMac, otherwise have not been exposed to macs much. Got an RS6000 with AIX, Pentium1 with Unixware, and will get the Octane with IRIX, something with HP-UX and Tru64 too. I wanted to get a complete UNIX-clone set but the OS390 is a little out of reach
  • I thought that ATM was basically uncompetetive compared to gigabit ethernet, and that you could afford to overspecify an ethernet solution with wide-enough a margin so that you could provide reasonable QoS guarantees, and still have money left over for lunch, compared to the comparable ATM solution.

    Not assertions, questions!
    • when you're feeding directly off of a telco link, doesn't it make sense to talk what the telco is talking? ;)

      I can do everything over 100Mbit ether if I wanted to, but I'm looking at what can be done to reduce the number of SAR (Segmentation And Reassembly) jumps that have to be made on my network. If I can avoid some of them by bringing the feed in as ATM, and it's as reliable as doing 100Mbit ether, why not do so?
  • If you have the money for an ATM network equipment you should be using something other than a linux box as a firewall.
    • Exactly what do you have in mind that is more secure than a linux box?

      The PCI bus is certainly not up to spec for handling anything that truely would justify ATM levels of traffic, but linux itself will rival anything cisco has on the market.
  • I'm gonna make a couple of assumptions...
    #1 If you're using ATM, you've got at least 4xT1 IMA group. Anything smaller and Multi-link PPP or Multi-link Frame Relay makes more sense.

    #2 There's something about ATM that you need for your application. Most of the QoS functions you can get now with the DSCP bits and other IP QoS techniques.

    ATM uses 58 byte cells. A 4xT1 IMA group is roughly 6.1Mbps. With these numbers, we can see that this 4xT1 IMA group will handle slightly more than 13K Cells/s.

    At layer 1, A
    • The ATM pipe we're looking at tapping is a feed between a Cisco ONS and our Telco Switch.

      Basically I was looking at what the benefits might be of offloading the SAR process from the Telco Switch to a Linux box (most ATM cards that I've seen are hardware based SAR, they just return an IP frame) since we're going to set one up for the router anyway. IF I can keep the traffic ATM based, given that a chunk of it comes in as ATM to begin with and most of it will leave as ATM, it should be an overall benefit to
      • If you're using an ONS, why not just use an ethernet card in the ONS?
        • Because the ONS is at a physically different site.

          Plus, as I've said in other posts, I can do this via ethernet off the Telco switch, but I'm looking at eliminating as many SAR jumps as I can. Up front it won't mean that much, but later on (assuming things go well once we have the gear in place) it could make for some very noticible performance differences.
          • I read your Journal entry. A couple of things for you-

            1. Are you doing Voice or Data CLEC? The type of traffic will dictate the network you use. ATM is good for data, but TDM is better for Voice, even now.

            2. Have you gotten your certificate from your state PUC? Without it, the local ILEC won't (and doesn't have to) give you the time of day.

            3. If you've gotten your certificate, have you negotiated your ICA (inter-connect agreement)? The ICA will specify exactly what the ILEC has to provide you, and at wha
            • The paperwork stuff is up to the boss. ;) I'm just the geek getting everything wired.

              I know that there's a ton of paperwork that's gone out to the PUC, and I think that part is done. The ICA is being worked on now. We have our initial number block and the SS7 hosting is being worked on. As far as 911 goes, I have no idea.

              We will be voice and data. Are there any nightmares that I should be aware of looking at setting this up?
    • Just FYI, ATM actually uses 53 byte cells... This odd number came as a result of some compromise in the standards process. Europe wanted 64 bytes and the US wanted 48(?) bytes, because of the slight differences between an E1 and a T1.
      • Yeah.. I was thinking 53 (48+5) and typed 58...
        and it wasn't all of Europe... was France.. Propagation delay on 48 byte cells would have let them send it across the country without electrical regeneration of timing.

  • linux ATM driver page.. (Score:2, Informative)

    by kfuq ( 513110 ) *
    Here is the "linux-atm" page. [sourceforge.net]

    when all else fails, try sourceforge !!!!

    LOL |-)
  • ATM on Linux [lrcwww.epfl.ch]

    linux ATM links [topology.org]

  • I was back at Case Western Reserve University (see /.'s recent wiffy post about CWRU) when they were running ATM to student rooms in residence halls on campus. We were using Fore PCA200Es at the time; they were kinda crappy cards, but they worked. There were various Linuxes running on ATM. I was running RedHat 2.0.36 at the time (yeah, this was circa 1998/9), and the ATM driver worked only as a module. Once things were set up, there were very few substantial problems. The 2.2 kernels brought some bette
  • FreeBSD has had good PCI ATM support since 1999 or so...

    I used it for building IP over ATM test gear in the Williams labs back then... worked great!

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close