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