Subject: (usr-tc) DSP 2.0.60 & ARC 4.1.59

From: "Mark E. Levy" <[email-masked]>
Date: Sat, 18 Dec 1999 18:11:51 +0000

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
[email-masked]
---------------------------------------------------------------------

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 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.

---

From: K Mitchell <[email-masked]>
Date: Sat, 18 Dec 1999 18:50:17 +0000

>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        [email-masked]
Keystone Connect                     Unlock Your World
Altoona, PA   814-941-5000      http://www.keyconn.net

-

---

From: [email-masked]
Date: Sat, 18 Dec 1999 21:13:35 +0000

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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 18 Dec 1999 22:45:24 +0000

Thus spake [email-masked]
>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Brian <[email-masked]>
Date: Mon, 20 Dec 1999 03:33:15 +0000

> 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

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 20 Dec 1999 04:59:58 +0000

Thus spake Brian

>reasoning is that any time spent on developing BGP code, could be better

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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Scot Desort <[email-masked]>
Date: Mon, 20 Dec 1999 07:39:25 +0000

>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

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 20 Dec 1999 15:17:20 +0000

Thus spake Scot Desort

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Brian <[email-masked]>
Date: Tue, 21 Dec 1999 05:14:58 +0000

> broken...I think I'll pass.  :)

I am holding off on the OSPF until they get that fixed as well.

-

---

From: Scot Desort <[email-masked]>
Date: Thu, 23 Dec 1999 05:52:02 +0000

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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Jeff Mcadams
>Sent: Monday, December 20, 1999 8:14 AM
>To: [email-masked]
>Subject: Re: (usr-tc) DSP 2.0.60 & ARC 4.1.59
>
>
>Thus spake Scot Desort
>>Jeff Mcadams wrote:

-