OK, I duck, watch Jeff's brilliant explanation fly right over my head, and stand back up. Boy, I still have a lot to learn <g>. -Scot
-----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Monday, December 20, 1999 8:14 AM To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) DSP 2.0.60 & ARC 4.1.59
Thus spake Scot Desort
Jeff Mcadams wrote:
Develop the abilities of the Arc as a t1/t3, etc connected device. The new NICs with 4.2.x give the Arc the ability to terminate t1's. You apparently can (I haven't tested this yet) run PPP over these t1's (in previous messages I had said you couldn't), but the implementation seems fairly limited on it...also, with frame-relay PVC's...why not use PAP/CHAP and RADIUS to get the configuration for these ports? The manageability aspects that this gives you is a huge win (anyone doing DSL service has probably figured this out...I know we did when we started doing DSL...and in a big way!)
In what capacity do you use the TC in your DSL offerings? I'm curious as to how you have it setup. Would you care to share some details on the equipment, configuration and functionality?
Don't yet...its very close to being useable for it though...just not quite there.
We've only got DSL turned up in one city at this point...we've filed a formal complaint with BellSouth with the Kentucky PSC over their actions with regards to anti-competitive actions...particularly with respect to DSL...
In the city that we do have service (Lexington, KY...with GTE), we're using RedBack...no PPPoE (evil protocol). The cool thing about the RedBack is that the IP level network is abstracted from the physical, or even logical (ie, frame pvc's) connectivity.
The way you can set up the RedBack is that you have a port...like a T1 port...and you set the encapsulation on it as normal...but, say, for frame-relay...they have an "auto-subscriber" command that let's you configure, en mass, PVC's for the frame-relay. Those PVC's are bound to a "subscriber". So what happens is that when that PVC comes up (ie, GTE activates it), its bound to that subscriber (something of the form "lexdsl01.4.0.0.123"..."lexdsl01." is the prefix I put in, then slot 4, port 0, PVC 0.123....the PVC field has two numbers to be able to handle ATM pvc's which use two numbers)...the RedBack then authenticates that subscriber as a userid...meaning it looks in its local config, if it doesn't find it there, it sends it to a RADIUS server...so we do all of our router configuration in our RADIUS server.
The RedBack has some other stuff that makes it pretty nice for doing DSL type of service that most other equipment lacks...but none of it is really absolutely necessary.
The only thing that the Arcs are absolutely lacking in order to be able to be used to provide DSL service such as GTE's is bridging...GTE uses RFC1490 bridging over frame-relay to deliver the DSL connections to the ISPs. Some sort of traffic management features would be an almost necessity to be able to provide DSL and actually make money at it. :)
From what I understand, traffic tagging will be in tcs4.0...but the ability to actually throttle down the traffic within the Arc would be necessary for a DSL router...either throttle it down as a traffic shaping type of thing...or the ability to choose queuing strategies to do prioritization.
Obviously, DSL is the next step up for the Arc from what it is currently. I think it has the possibility to be even more...its got the cpu and memory to be a low-end core router...the routing protocols aren't there yet (thus the mention of BGP), nor is the control over the routing protocols (control over redistribution primarily).
Also, the current implementation of OSPF leaves a bit to be desired...as Mike Andrews pointed out...with the improper handling of multiple different routes (different length netmasks) with the same network number. That right there is enough to keep me from enabling OSPF on my Arcs...I don't *think* I would get bitten by it given the configuration of my network...but if the handling of OSPF routes in the Arc is that broken...I think I'll pass. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.