10:29 a.m.
Ok, a bit of introduction. Due to some phenomenal eBay buys, I have a fairly
elaborate ATM network here at PARI. I have five 3Com CoreBuilder 7000 5Gbps
switches, a dozen or so dual OC-12 cards, bunches of OC-3 cards, etc.
I have a Dell PowerEdge 1600SC running FC1 with a ForeRunner HE622 OC-12 NIC
installed that is working very well with the linux-atm project's LANE code
(oddly, I can't rebuild from source due to some fancy things a few of the
low-level diag pprograms need from the kernel headers, but since the
linux-atm project provides prebuilt binary RPMs that's not a big issue). I
get good bandwidth through the HE with a LANE LEC set up with the zeppelin,
atmsigd, and ilmid setup as shipped with the linux-atm userland package.
So, I am setting up a second Dell 1600SC with another HE622 card to test the
ATM cloud's performance. This 1600SC is my testbed and is running FC2. So I
install the linux-atm userland, and attempt to use the HE. Well, the .358
kernel doesn't have the HE or any ATM drivers. So I updated to the latest,
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.
The second question is 'how do you generate the configs used in the kernel
SRPM' and is that tool available as part of the SRPM? I will be recompiling
with ATM support, but I want to use the Officially Approved rpmbuild
--rebuild kernel-x.y.z-a.b.c.src.rpm method, since I want to distribute this
kernel internally to all machines that will be running ATM cards. I am not
uncomfortable hand-editing the config file, but I know that that is
suboptimal.
This of course is the Way to Do It since the desire is to not ship
kernel-sourcecode anymore, so custom kernels have to come from the SRPM,
which is fine by me as long as the configuration tools used to generate those
prepackaged configs are available.
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.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
11:04 a.m.
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 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.
Alan
11:46 a.m.
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
12:51 p.m.
On Sat, Jul 31, 2004 at 12:46:53PM -0400, Lamar Owen wrote:
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.
ATM is still too overly complex as an Enterprise networking
technology. Certainly support should be there for those who need it,
but I doubt it is worth the effort just for new high-bandwidth
applications, unless the intent is to work with legacy ATM
infrastructure.
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.
Ethernet can do that with 802.1Q VLANs. I just don't see the
advantage of ATM for new deployments in this case. Emulating
broadcast LANs on top of circuit-switched technology is inefficient,
complex, and fragile. On the other hand, the support could be useful
for those stuck with legacy ATM in order to create firewalls, IDS's,
flow analysis tools, etc.
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
[...]
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.
Ugh. It seems silly to create all that complexity just to work around
the inherent weaknesses of the LANE technology, with all the overhead
to boot. I don't think you characterize the average IT person.
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....
Ethernet can do that too with 802.3ad Link Aggregation. I too went
through my ATM phase and I'm much happier now that I have migrated to
a completely Ethernet infrastructure.
2:17 p.m.
On Saturday 31 July 2004 13:51, Charles R. Anderson wrote:
On Sat, Jul 31, 2004 at 12:46:53PM -0400, Lamar Owen wrote:
> 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.
ATM is still too overly complex as an Enterprise networking
technology. Certainly support should be there for those who need it,
but I doubt it is worth the effort just for new high-bandwidth
applications, unless the intent is to work with legacy ATM
infrastructure.
But all telco infrastructure on the WAN side is SONET, and most is ATM.
Ethernet can do that with 802.1Q VLANs. I just don't see the
advantage of ATM for new deployments in this case.
Real traffic isolation at the link level. Since ATM is connection-oriented,
there are no broadcasts to sniff, no way for a random user to get any traffic
they aren't supposed to see.
There are a few reasons I picked ATM over gigabit Ethernet. The first one was
distance. My fiber runs average longer than 300 meters, which is the limit
for 1000Base-SX on my fiber (which is already installed, and relatively old
at this point, having been installed in the early to mid 90's. I have more
than one run of fiber that I am using that is longer than 600 meters, but
works fine with OC-12 over multimode (HP HFBR 5208 transcievers)).
1000Base-LX is too expensive.
I have $2,500 invested in my ATM LAN with OC-12 links. Server connections are
available with 1000Base-SX and OC-12 ports. The switches feature full
hot-swap redundant power supplies, hot-swap interface cards, and enterprise
SNMP management.
Can 802.1Q give me full, automatic, link failover at the link level? With
automatic load balancing? The PNNI implementation in the 3Com gear does
both, transparently to the AAL5 above.
Emulating
broadcast LANs on top of circuit-switched technology is inefficient,
complex, and fragile. On the other hand, the support could be useful
for those stuck with legacy ATM in order to create firewalls, IDS's,
flow analysis tools, etc.
Yes, LANE is not the most elegant solution ever invented. But once the VCC is
up, the throughout is very good, and competive to CLIP. As far as 'legacy'
goes, ATM is at the core of new technology, not just old. ADSL, for
instance, is ATM. To support some USB ADSL modems requires the ATM stack; in
particular, PPPoA on the Alcatel Speedtouch is in kernel-2.6, but not built
in the Fedora kernel by default.
Ugh. It seems silly to create all that complexity just to work
around
the inherent weaknesses of the LANE technology, with all the overhead
to boot. I don't think you characterize the average IT person.
No, I don't, I guess. 3Com's Transcend Enterprise Manager did all the heavy
lifting. I just had to think through what I wanted, and learn the
terminology, and characterize the topology desired. PNNI on those switches
isn't hard, once you wrap your mind around it, remembering that ATM is
circuit-switched technology. And you don't have to do anything at the IP
level; it's all handled transparently to the IP layer.
I have yet to find an affordable gigabit layer 3 switch that can do now what
this ATM gear could do in 1998. Automatic load balancing and failover were
and are dealbreakers for me, given the geographic issues on my campus. Now,
these ATM switches were not really affordable in their day; but they are
_now_, and on an educational budget they work wonderfully well.
> 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....
Ethernet can do that too with 802.3ad Link Aggregation. I too went
through my ATM phase and I'm much happier now that I have migrated to
a completely Ethernet infrastructure.
I had a couple of Bay Networks switches that did the aggregation and trunking.
It was not as smooth nor as fast. Since implementing the ATM LAN things are
much smoother here. YMMV, of course. ATM is not the be all end all, but
neither is Ethernet. Nor is TCP/IP for that matter.
However, ATM is still very popular, in particular for the home user who wants
to use Linux and a USB ADSL modem that implements PPPoA (Alcatel Speedtouch,
for instance). This is not uncommon, and can provide lower latency and
higher throughput than PPPoE. I know a number of users on my ISP that run
the Speedtouch on Windows; they can't switch to Linux unless the PPPoA
support is there.
But the biggest reason I like and use ATM is the fact that there is no
boundary between WAN and LAN, since ATM is mostly a WAN technology. And I am
going to be using a Linux ATM firewall when I get a bigger pipe out of here.
The usage to which I am going to put my facility also make ATM attractive; I
want to be able to park a cage in a building and give users their own PVC's
in that are invisible to other users here, even though they are carried by
the same fiber and the same switches.
But our goal here is an OC-48 incoming for real-time telescope control; not
the typical application, granted.
My new ATM-enabled kernel is up and running on FC2, now. Only took 90 minutes
to rebuild the RPMs on a 2.4GHz Xeon (!!!???). Now to test my cloud's
bandwidth.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
8:50 a.m.
Le sam 31/07/2004 à 21:17, Lamar Owen a écrit :
However, ATM is still very popular, in particular for the home user
who wants
to use Linux and a USB ADSL modem that implements PPPoA (Alcatel Speedtouch,
for instance). This is not uncommon, and can provide lower latency and
higher throughput than PPPoE. I know a number of users on my ISP that run
the Speedtouch on Windows; they can't switch to Linux unless the PPPoA
support is there.
I use ATM and PPPOATM since RH8.0.
btw, ppp package miss pppoatm module.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
3:29 p.m.
On Saturday 31 July 2004 11:29, Lamar Owen wrote:
So I install the linux-atm userland, and attempt to use the HE.
Well, the
.358 kernel doesn't have the HE or any ATM drivers. So I updated to the
latest, 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.
Arjan, I've not seen a comment from you on this. Can you please comment, even
if the comment is for me to just go away with my ATM junk? :-)
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
3:37 p.m.
On Wed, 2004-08-04 at 22:29, Lamar Owen wrote:
On Saturday 31 July 2004 11:29, Lamar Owen wrote:
> So I install the linux-atm userland, and attempt to use the HE. Well, the
> .358 kernel doesn't have the HE or any ATM drivers. So I updated to the
> latest, 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.
Arjan, I've not seen a comment from you on this. Can you please comment, even
if the comment is for me to just go away with my ATM junk? :-)
ATM is of, ehm, mixed quality. Some parts are ok, some are
undermaintained it seems and might pose a security risk. Note that the
current erratum kernel has ATM at least partially turned on but I would
appreciate feedback on which hardware works to be able to make a more
informed decision about what to enable exactly... "it compiles" vs "it
gives scary warnings" isn't the bes ;)
4:44 p.m.
On Wednesday 04 August 2004 16:37, Arjan van de Ven wrote:
On Wed, 2004-08-04 at 22:29, Lamar Owen wrote:
> Arjan, I've not seen a comment from you on this. Can you please comment,
> even if the comment is for me to just go away with my ATM junk? :-)
ATM is of, ehm, mixed quality. Some parts are ok, some are
undermaintained it seems and might pose a security risk. Note that the
current erratum kernel has ATM at least partially turned on but I would
appreciate feedback on which hardware works to be able to make a more
informed decision about what to enable exactly... "it compiles" vs "it
gives scary warnings" isn't the bes ;)
First, thank you for taking the time out of your busy schedule to reply.
Second, the HE drivers seem to be well-maintained, with Chas Williams being
active in patching as well as on the linux-atm list. The HE622 is the
hardware I am using currently in a couple of Dell 2.4GHz Xeon servers
(ServerWorks chipset). I have done some stress testing using ttcp amongst
others, and the HE is giving high throughput numbers on both the FC1 kernel
and the FC2 kernel (my custom compiled version, based on the last production
erratum). I have stress-tested over several hours, and system load stays
pretty low, and things aren't throwing warnings or 'scary' errors.
In the interest of helping the project, I will be testing other adapters
shortly. Mike Westall of Clemson University can speak to the Interphase and
Turboways drivers and general stack stability, as he has developed and
maintained an ATM research network for several years (since 1997, I believe)
and he is also available on the linux-atm list. He also is currently active.
When building my custom kernel I did see some fairly scary warnings from one
of the drivers, but I forget ATM which one it was...Zeitnet?
The userland is a pill to build on FC2, unfortunately, but that isn't relevant
in this context.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
5:03 p.m.
On Wed, Aug 04, 2004 at 05:44:57PM -0400, Lamar Owen wrote:
On Wednesday 04 August 2004 16:37, Arjan van de Ven wrote:
> On Wed, 2004-08-04 at 22:29, Lamar Owen wrote:
> > Arjan, I've not seen a comment from you on this. Can you please comment,
> > even if the comment is for me to just go away with my ATM junk? :-)
> ATM is of, ehm, mixed quality. Some parts are ok, some are
> undermaintained it seems and might pose a security risk. Note that the
> current erratum kernel has ATM at least partially turned on but I would
> appreciate feedback on which hardware works to be able to make a more
> informed decision about what to enable exactly... "it compiles" vs
"it
> gives scary warnings" isn't the bes ;)
First, thank you for taking the time out of your busy schedule to reply.
Second, the HE drivers seem to be well-maintained, with Chas Williams being
active in patching as well as on the linux-atm list. The HE622 is the
hardware I am using currently in a couple of Dell 2.4GHz Xeon servers
(ServerWorks chipset). I have done some stress testing using ttcp amongst
others, and the HE is giving high throughput numbers on both the FC1 kernel
and the FC2 kernel (my custom compiled version, based on the last production
erratum). I have stress-tested over several hours, and system load stays
pretty low, and things aren't throwing warnings or 'scary' errors.
In the interest of helping the project, I will be testing other adapters
shortly. Mike Westall of Clemson University can speak to the Interphase and
ok how about this; can you check the kernels we ship occasionally and give
me suggestions about *exact* config changes that would improve atm support.
Like "it's better to turn THIS option on as module" etc.
you know ATM a lot more than I do...
7204
days inactive
7208
days old
9 comments
5 participants
participants (5)
-
Alan Cox -
Arjan van de Ven -
Chuck Anderson -
Féliciano Matias -
Lamar Owen