Date: Mon, 6 Sep 2004 09:01:00 +0200 (CEST) From: Harti Brandt <harti@freebsd.org> To: Ted Mittelstaedt <tedm@toybox.placo.com> Cc: freebsd-atm@freebsd.org Subject: RE: Question on ATM w/ FreeBSD Message-ID: <20040906085005.R16723@beagle.kn.op.dlr.de> In-Reply-To: <20040904153835.C2146@mail.cheapline.net> References: <LOBBIFDAGNMAMLGJJCKNMEDMEPAA.tedm@toybox.placo.com> <20040904153835.C2146@mail.cheapline.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 4 Sep 2004, Richard Hodges wrote: RH>On Sat, 4 Sep 2004, Ted Mittelstaedt wrote: RH> RH>> > -----Original Message----- RH>> > From: Harti Brandt [mailto:harti@freebsd.org] RH>> > On Thu, 2 Sep 2004, Ted Mittelstaedt wrote: RH> RH>> When I got that response I followed up with a second query to the carrier RH>> of whether the encap was RFC1483 Bridged or RFC1483 Routed. Apparently that RH>> exhausted the meager store of ATM knowledge that the technical contact had RH>> and the RH>> question was referred up the chain, presumably to someone more RH>> knowledgeable. RH>> RH>> It's week end now and I've not got a response. RH> RH>Maybe they could say what device they are using and some info on how RH>they plan to configure their end. RH> RH>> > If you have bridged LLC - I don't know whether HARP can do this. RH> RH>No, HARP only uses routed PDUs. At first glance, it seems that it would RH>be easy to strip off the bridged PDU header on incoming packets and RH>prepend one to outbound packets, but unless you are dealing with a single RH>host on the other end, you now have to maintain an ARP table. Either RH>that, or create a special virtual ethernet device that can attach to the RH>kernel ethernet block. With netgraph this should be doable: ng_eiface <---> ng_atmllc <---> ng_atm Would be a nice to get this working. RH>> My suspicion is that it's going to end up being Routed. The reason why RH>> is that we are already using a different group within this carrier to RH>> provide Frame Relay to customers -ie: we buy Frame circuits from their RH>> network to supply bandwidth to customers. Basically it's ATM vc's from us RH>> to their ATM switch which interworks it to a Frame circuit that the RH>> end user sees on the usual T1. That is of course a completely separate RH>> DS3 than what we are looking at buying. But the circuits provisioned off RH>> that are Routed not bridged, and all5snap, and vbr. RH> RH>Okay, one point in favor of using FreeBSD for the ATM endpoint :-) RH> RH>> It would also almost certainly be a single VC on the DS3. RH>> RH>> DSL egress in this market, by contrast, is all Bridged, both with Verizon RH>> and Qwest. (we have both those ilecs here, ugh) They both use vbr and RH>> aal5mux. RH> RH>One other possibility that comes to mind is that if they want to used RH>bridged, you could get a (cheap) Newbridge Orange Ridge, which has an OC3 RH>and 12 10/100 ethernet ports. Forget about LANE and MPOA, just configure RH>a static PVC. It's been years since I have configured an Orange Ridge, RH>but I think that _should_ work. RH> RH>> I have another question for you guys,- if I am using routed/vbr is there any RH>> benefit to using a forerunner he155 and the fatm() driver as opposed to RH>> a Fore LE155 with the idt() driver? RH> RH>I know next to nothing about the HE155, but I can say that the LE155 is a RH>pretty good card. The driver is capable of CBR and a pseudo-VBR as well RH>as UBR, at least when given the proper traffic setup parameters. HARP RH>does not set these parameters, but you could force arbitrary PCR and SCR RH>in the function idt_instvcc() if you wanted. I think it would be trivial RH>to add a sysctl (like " hw.idt.next_pcr") to assign a PCR to the next VC RH>created. The HE155 can do up to 4k CBR and ABR connections. It can send 150kpts per second (the HE622 should do 300kpts). It has no VBR. The LE155 on the other hand can do CBR (also on a lot of connections, and, as Richard says a couple of VBR connections (2 I think). RH>> Also, what exactly is the difference RH>> between a Fore LE155 and a Fore PCA-200 (which uses the hfa() driver I RH>> understand)? RH> RH>The PCA200 has its own processor and firmware, and in my opinion it is not RH>nearly as flexible as the LE155. I do not believe that it can handle CBR RH>or VBR, just UBR. With the 4.X.Y firmware it can shape at least one CBR channel. Someone told me that it can do actually four of them, but I had no time to verify this. It's flexibility is in the possibility to load your own firmware (like Vince did), but I was never able to get access to the firmware interface specificiation. RH>> Has anyone worked with the Ascend/Lucent/Avaya PSAX gear, like the PSAX RH>> 100? Is that an ATM switch that could run a VC from one interface to RH>> another? The documentation on Avaya's site is very unclear plus the PSAX RH>> 100 has been long discontinued. But because of that they appear to be RH>> rediculously cheap on the secondary market. RH> RH>It has been about five years since I have configured the SA100, but I did RH>have a pair set up for ether-ATM-ether bridging. I don't think it can RH>handle routed encapsulation, though. In my opinion (!), Ascend people RH>knew almost nothing about the unit after aquiring it from Sahara, and I RH>bet the Lucent people know even less than nothing, unless they still have RH>some ex-Sahara employees on board. I have an "almost working" SA100 with RH>10/100 ports you can have for spare parts if you want, but even for free I RH>don't know that you would be getting a good deal... RH> RH>One other possibility for bridged PDUs might be a Fore ES3810 with an OC3 RH>on the top and a 10/100 card. You could configure a PVC to one or more of RH>the ether ports pretty easily. This should also be fairly cheap on ebay. RH> RH>All the best, RH> RH>-Richard RH> RH> RH>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040906085005.R16723>