(usr-tc) DSP 2.0.60 & ARC 4.1.59
A few weeks ago, I upgraded my DSPs to 2.0.60 & my ARCs to 4.2.32. Almost immediately, I began to get complaints from users with either Kflex-only or 33.6 or slower modems that they had extreme difficulty connecting or staying connected. I downgraded the DSPs back to 2.0.19 & the ARCs to 4.1.59. I later heard from someone on the ISP-TECH list that he, too, had problems with that 2.0.60 & 4.2.32, and downgraded his ARCs to 4.1.59 but left the DSPs alone, and that solved his problems. I'd like to know if anyone else is running 2.0.60 with 4.1.59 without problems before I consider re-upgrading my DSPs (none of which are hardware rev 55) to get the alleged Rockwell fix. -- --------------------------------------------------------------------- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net --------------------------------------------------------------------- - 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.
At 10:05 AM 12/18/99 -0600, "Mark E. Levy" <mark@fsi.net> wrote:
A few weeks ago, I upgraded my DSPs to 2.0.60 & my ARCs to 4.2.32. Almost immediately, I began to get complaints from users with either Kflex-only or 33.6 or slower modems that they had extreme difficulty connecting or staying connected. I downgraded the DSPs back to 2.0.19 & the ARCs to 4.1.59.
I later heard from someone on the ISP-TECH list that he, too, had problems with that 2.0.60 & 4.2.32, and downgraded his ARCs to 4.1.59 but left the DSPs alone, and that solved his problems.
I'd like to know if anyone else is running 2.0.60 with 4.1.59 without problems before I consider re-upgrading my DSPs (none of which are hardware rev 55) to get the alleged Rockwell fix.
I'm at 4.2.32 on the ARCs and 2.0.81 DSP and it's been stable here for 6 weeks or so. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - 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.
2.0.60 and 4.1.59-6 seems to be the most stable DSP/ARC code. Most of the diff. in 4.2 series is for routing protocols (bgp) from what I understand. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sat, 18 Dec 1999, Mark E. Levy wrote:
A few weeks ago, I upgraded my DSPs to 2.0.60 & my ARCs to 4.2.32. Almost immediately, I began to get complaints from users with either Kflex-only or 33.6 or slower modems that they had extreme difficulty connecting or staying connected. I downgraded the DSPs back to 2.0.19 & the ARCs to 4.1.59.
I later heard from someone on the ISP-TECH list that he, too, had problems with that 2.0.60 & 4.2.32, and downgraded his ARCs to 4.1.59 but left the DSPs alone, and that solved his problems.
I'd like to know if anyone else is running 2.0.60 with 4.1.59 without problems before I consider re-upgrading my DSPs (none of which are hardware rev 55) to get the alleged Rockwell fix.
-- --------------------------------------------------------------------- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net ---------------------------------------------------------------------
- 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.
Thus spake farber@admin.f-tech.net
2.0.60 and 4.1.59-6 seems to be the most stable DSP/ARC code. Most of the diff. in 4.2 series is for routing protocols (bgp) from what I understand.
OSPF and frame-relay :) ...no BGP (yet at least). -- 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.
On Sat, 18 Dec 1999, Jeff Mcadams wrote:
Thus spake farber@admin.f-tech.net
2.0.60 and 4.1.59-6 seems to be the most stable DSP/ARC code. Most of the diff. in 4.2 series is for routing protocols (bgp) from what I understand.
OSPF and frame-relay :) ...no BGP (yet at least).
and hopefuly BGP will stay out of the code for a very long time :). My reasoning is that any time spent on developing BGP code, could be better spent elswhere......... Brian
-- 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.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - 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.
Thus spake Brian
On Sat, 18 Dec 1999, Jeff Mcadams wrote:
Thus spake farber@admin.f-tech.net
2.0.60 and 4.1.59-6 seems to be the most stable DSP/ARC code. Most of the diff. in 4.2 series is for routing protocols (bgp) from what I understand.
OSPF and frame-relay :) ...no BGP (yet at least).
and hopefuly BGP will stay out of the code for a very long time :). My reasoning is that any time spent on developing BGP code, could be better spent elswhere.........
Assuming that resources spent on developing BGP could be transferred to working on other features without cost...which is unlikely (unless you want to move the resources to a similar feature...IS-IS?). If 3Com has routing protocol programmers sitting there twiddling their thumbs, I'd rather them go ahead and do BGP...cause it could prove useful (particularly if 3Com wants the HiPer Arc to ever be more than just an edge system...which it definitely has the potential to be). I do agree with you though...there are many features that I'd rather see as a higher priority than BGP...what Cisco calls "policy routing" would be terribly useful, for example. Bridging is still something that I want drastically, and a "packet bus interface" would be seriously cool (ie, have an IP interface to the packet bus of the chassis to facilitate Arc to Arc communication...or combine with the bridging for added fun for the whole family! ;). Hrmm...other ideas... 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!) -- 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.
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? Regards, Scot - 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.
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.
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. :)
I am holding off on the OSPF until they get that fixed as well.
-- 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.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - 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.
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.
participants (6)
-
Brian -
farber＠admin.f-tech.net -
Jeff Mcadams -
K Mitchell -
Mark E. Levy -
Scot Desort