November 1999 - USR-TC - mailman.xmission.com

Fwd: Re: (usr-tc) HiperArc 4.2.32 problem with large blocks
by Colin J Wantling 17 Nov '99

17 Nov '99

As Jeff says, 4.2.32-1 was the version. We used it because all 4.1.x versions are believed to have MTU negotiation problems. We shall set up a test chassis to check out operation with the new DSPs and HiperArcs with V 4.2.32. We can expect this to be time-consuming. I was just checking we are not re-inventing the wheel. Colin >Envelope-to: wantling(a)rampoint.co.uk >Date: Wed, 17 Nov 1999 09:35:56 -0500 >From: Jeff Mcadams <jeffm(a)iglou.com> >To: usr-tc(a)lists.xmission.com >Thus spake Brian > >On Wed, 17 Nov 1999, Colin J Wantling wrote: > >> Having had MTU problems with HARC software 4.1.11, we tried upgrading to > >> 4.1.32 today. It soon became apparent that large blocks were no longer > >> being handled at all! We had been looking forward to an improvement. > > >What keeps you from going to 4.1.59-6? It probably is the best 4.1.x > >version to be running. > >I think he was actually referring to 4.2.32-1, not 4.1.32-1, which, to >my knowledge doesn't exist...or at least isn't released. >-- >Jeff McAdams Email: jeffm(a)iglou.com - To unsubscribe to usr-tc, send an email to "majordomo(a)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 1

(usr-tc) HiperArc 4.2.32 problem with large blocks
by Colin J Wantling 17 Nov '99

17 Nov '99

Hi, Having had MTU problems with HARC software 4.1.11, we tried upgrading to 4.1.32 today. It soon became apparent that large blocks were no longer being handled at all! We had been looking forward to an improvement. Because of service requirements, we didn't get much time to debug this, but the max block size handled OK seemed to be about 580. Anybody seen a similar problem or have a lucky-rabbit's foot please? Colin Wantling - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

4 3

Re: (usr-tc) HiperArc 4.2.32 problem with large blocks
by Colin J Wantling 17 Nov '99

17 Nov '99

>Thus spake Brian > >On Wed, 17 Nov 1999, Colin J Wantling wrote: > >> Having had MTU problems with HARC software 4.1.11, we tried upgrading to > >> 4.1.32 today. It soon became apparent that large blocks were no longer > >> being handled at all! We had been looking forward to an improvement. > > >What keeps you from going to 4.1.59-6? It probably is the best 4.1.x > >version to be running. > >I think he was actually referring to 4.2.32-1, not 4.1.32-1, which, to >my knowledge doesn't exist...or at least isn't released. >-- >Jeff McAdams Email: jeffm(a)iglou.com - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

1 0

Re: (usr-tc) Continuing OSPF problems
by Brian 17 Nov '99

17 Nov '99

> > This popped up today when I needed to add an NM-4T to our Cisco 3620, > which is set to the highest OSPF priority so that it normally becomes the > DR, and our 2611 becomes the BDR. Power cycling to add the NM-4T made > this swap, of course, so right now the 2611 is the DR and the 3620 is the > BDR. Normal enough... If I remember right it doesn't work like that. When you have a DR and a BDR, and you reboot the DR, yes the BDR becomes the DR. But then when the "old" DR comes back up it does not become BDR. You have to reboot your other box (the original BDR , now DR) for this too happen. In other words, the cluenote I remember is "2 reboots are necessary for a re-election of OSPF DR/BDR". This may be Ciscocentric, I don't remember. > > However, both the ARCs on the subnet suddenly stopped advertising their IP > pools, and stopped listening to advertisements from the other routers... > basically quit exchange OSPF routes entirely. Naturally, our dialup > customers weren't real happy about this. Rebooting the ARCs got things > back into shape - a bit drastic of a solution. I wonder if somehow the ospf database got fscked. I think OSPF does a "flood" every 30 minutes or so, and rebooting the 3com box would have forced at least an initial flood. > > I may have narrowed this down a bit more this time though. > > Cranking out a listing of OSPF neighbors indicates that maybe the ARC is > having trouble talking to the new DR at all. > > Here is the current DR (206.240.130.3): > > fra2>show ip ospf nei > > Neighbor ID Pri State Dead Time Address > Interface > fra-ts1.dcr.net 0 FULL/DROTHER 00:00:35 206.240.130.12 Ethernet0/0 > fra1-e0-0.dcr.n 50 FULL/BDR 00:00:31 206.240.130.1 Ethernet0/0 > dusty.dcr.net 0 FULL/DROTHER 00:00:32 206.240.130.7 Ethernet0/0 > fra3-e0.dcr.net 20 FULL/DROTHER 00:00:33 206.240.130.4 Ethernet0/0 > fra-ts2.dcr.net 0 EXSTART/DROTHER 00:00:32 206.240.130.14 Ethernet0/0 > andrew.dcr.net 0 FULL/DROTHER 00:00:35 206.240.130.2 Ethernet0/0 Yes, it would appear that fra-ts2 is not establishing adjacency with the DR....... > > The BDR (206.240.130.1): > > fra1>show ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > fra-ts1.dcr.net 0 FULL/DROTHER 00:00:33 206.240.130.12 Ethernet0/0 > fra2-e0-0.dcr.n 40 FULL/DR 00:00:38 206.240.130.3 Ethernet0/0 > fra3-e0.dcr.net 20 FULL/DROTHER 00:00:32 206.240.130.4 Ethernet0/0 > fra-ts2.dcr.net 0 FULL/DROTHER 00:00:30 206.240.130.14 Ethernet0/0 > andrew.dcr.net 0 FULL/DROTHER 00:00:34 206.240.130.2 Ethernet0/0 > dusty.dcr.net 0 FULL/DROTHER 00:00:30 206.240.130.7 Ethernet0/0 > office1.dcr.net 15 FULL/ - 00:00:32 199.77.100.18 Serial1/0 > law1-e0.dcr.net 20 FULL/ - 00:00:39 199.77.100.26 Serial1/1 > > fra-ts1 (206.240.130.12) is an ARC that was sick and was rebooted to fix > the problem: > > fra-ts1> list ospf nei > OSPF NEIGHBORS > IfIpAddr/IfInd RouterId Area Prior. State Event QLen Status > 206.240.130.1 206.240.130.1 TRANSIT 50 Full/BDR 6 0 dynamic > 206.240.130.2 128.167.1.69 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.3 206.240.130.3 TRANSIT 40 Full/DR 6 0 dynamic > 206.240.130.4 206.240.130.4 TRANSIT 20 TwoWay 4 0 dynamic > 206.240.130.7 206.240.130.7 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.14 206.240.130.14 TRANSIT 0 TwoWay 4 0 dynamic > > fra-ts2 (206.240.130.14) is an ARC that was and still is sick right now > (it won't advertise its IP pool, and its routing table has only default, > itself, loopback, and the LAN). Fortunately it has no live modems at the > moment, so I can leave it this way for testing: > > fra-ts2> list ospf nei > OSPF NEIGHBORS > IfIpAddr/IfInd RouterId Area Prior. State Event QLen Status > 206.240.130.1 206.240.130.1 TRANSIT 50 Full/BDR 6 0 dynamic > 206.240.130.2 128.167.1.69 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.3 206.240.130.3 TRANSIT 40 ExStart 3 0 dynamic > 206.240.130.4 206.240.130.4 TRANSIT 20 TwoWay 2 0 dynamic > 206.240.130.7 206.240.130.7 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.12 206.240.130.12 TRANSIT 0 TwoWay 2 0 dynamic > > Basically the newly appointed DR is stuck in "exstart" state with the sick > ARC. Any pointers as to which debug flags I should turn on to figure out > why? I'm still not quite to the OSPF Guru state yet. You can debug ospf adjacency information on the Cisco. The last time I had adjacency problems it was a bad PtP t1 circuit. check for any wierd ping/packet loss between fra-ts2 and the DR. > > > Mike Andrews (MA12) * mandrews(a)dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville > "With sufficient thrust, pigs fly just fine." -- RFC 1925 > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)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(a)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(a)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.

4 19

(usr-tc) Evil Twin Modem Syndrome
by Greg Coffey 16 Nov '99

16 Nov '99

It looks like we have 2 pair of the evil twin modem syndrome. We have 2 pair of modems with much lower times and they are both together as described in here earlier. Does simply resetting them fix it for a while? Is there a semi-permanent fix for this yet? We are running 8 DSP's in a chassis with a hyperarc card, all on channelized T1's. Thanks, Greg Coffey <gcoffey(a)vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center, Casper, WY 82601 www.vcn.com - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

1 0

Out of Office Response: Re: (usr-tc) Continuing OSPF problems (fwd)
by Brian 16 Nov '99

16 Nov '99

Someone at 3Com please go find Amy, and bring the clue-by-four. Brian ----------------------------------------------------- Brian Feeny (BF304) signal(a)shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) ---------- Forwarded message ---------- Date: Tue, 16 Nov 1999 10:59:47 -0600 From: Amy_Gabel(a)3com.com To: signal(a)shreve.net Subject: Out of Office Response: Re: (usr-tc) Continuing OSPF problems Amy Gabel will be away from Monday November 15, 1999 to Thursday November 18, 1999. Mail is not being forwarded. I will be off site Tuesday, 11/16 through Thursday,11/18. If this is an urgent matter, I can be paged at 888-759-3266, pin 1656290. - To unsubscribe to usr-tc, send an email to "majordomo(a)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 1

(usr-tc) Urgent: 2.0.60...need advice!
by Fairlight 16 Nov '99

16 Nov '99

I could really use some advice.. We have HiPer DSP's (T1/PRI), and were previously running 1.0.26 code. This had been doing "okay" but we were getting more and more handshaking problems as our service expanded, and more and more cases of ring-on where nothing would answer at a particular modem. Well, we got under software contract, and I just updated to 2.0.60. One problem: When people dial in, many times (I've got at least 30-50 reports in one night alone) they are hearing a "click" and then dead air. That's it. Nothing else happens for them. Yet you can re-dial in (sometimes after several attempts). It's not totally dead, but what is up with this? I need expediant advice as to what might be causing this, and what the best fix is. If 2.0.60 is knackered, what version would people recommend I go to, since that was a "fix" version for 2.0.19...? Help! The natives are getting restless. :( TIA...on-list and/or private replies welcome! mark-> -- Fairlight-> ||| fairlite(a)sostech.net | __/\__ ||| | "I'm talking for free... <__<>__> ||| System Administrator | It's a New Religion..." \/ ||| | - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

1 0

Re: (usr-tc) Re: Continuing OSPF problems
by Brian 16 Nov '99

16 Nov '99

On Thu, 11 Nov 1999, Mike Andrews wrote: > On Thu, 11 Nov 1999, Mike Andrews wrote: > > > A while back I mentioned a problem I had where my ARCs would stop > > routing correctly after various Ciscos in my network rebooted. The > > general consensus was that it was related to Designated Router/Backup > > Designated Router designations... and that maybe the ARCs were becoming a > > DR/BDR. > [munch] > > More on the above problem: > > A quick search around suggests one possible reason the routers won't > negotiate is a subnet mask mismatch. Here's the routing table on the sick > ARC: > > fra-ts2> list ip route > > IP ROUTES > Destination Prot NextHop Metric Interface > 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 > 127.0.0.1/H LOCAL 127.0.0.1 1 loopback > 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 > 206.240.130.14/H LOCAL 206.240.130.14 1 eth:1 > > This points out a problem I've brought up before. The subnet mask on this > LAN should be /25, not /23. There is a /23 route being advertised by the > Cisco that points at fra1's Null0 though (for BGP4 purposes) and this is > somehow getting confused with the local netmask set on the eth:1 > interface, which is set correctly: Ok, fra1 is that your border? Are you injecting static routes into the IGP at all? I use tiedowns for my BGP routes as well.........you want to set these with a HIGH administrative weight, of like 250 though, so they don't get used. Do you have a weight set on them? Also, using null0 as a tiedown used to be slow switched, so people used loopbacks, but I think now in later ios's this is not the case, and both can be used, but if you are running an older version you may want to consider that. > > fra-ts2> show ip network ip > > SHOW IP NETWORK ip SETTINGS: > Interface: eth:1 > Network Address: 206.240.130.14/25 > Frame Type: ETHERNET_II > Status: ENABLED > Reconfigure Needed: FALSE > Mask: 255.255.255.128 > Station: 206.240.130.14 > [munch] > > So maybe the two bugs I'm running into are related after all? > > Guess I'll go turn on OSPF debugging on the DR and see what comes up. > > > Mike Andrews (MA12) * mandrews(a)dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville > "With sufficient thrust, pigs fly just fine." -- RFC 1925 > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)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(a)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(a)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.

1 0

RE: (usr-tc) Pipeline 75 to a HiperARC V4.1.59
by Brian 16 Nov '99

16 Nov '99

You can also use RADIUS. Also NAT works fine. On Thu, 11 Nov 1999, Blake Fithen wrote: > They only way I've done it is to define the user on the ARC > and assign them their own subnet. Works perfectly. Let me > know if you want my configs. > > blake > > > -----Original Message----- > > From: Matthew Opoka [mailto:phantom@pemberton.magnolia.net] > > Sent: Thursday, November 11, 1999 12:10 PM > > To: usr-tc(a)lists.xmission.com > > Subject: (usr-tc) Pipeline 75 to a HiperARC V4.1.59 > > > > > > Any one know how to connect a pipeline 75 to hiperarc? > > If so email me at matthew(a)magnolia.net > > > > -- > > Matthew Opoka > > Systems Admin > > Mississippi Internet Services, Inc. > > http://www.magnolia.net > > Voice: 601.661.0081 > > Fax: 601.634.1952 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo(a)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(a)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(a)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(a)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.

1 0

Re: (usr-tc) USR STOPS WORKING
by Brian 16 Nov '99

16 Nov '99

lets start with what code are you running? On Wed, 10 Nov 1999 vito(a)arvotek.net wrote: > If your USR stops working in other words when you try pinging it you get > no response. What could be the problem? Theres still income calls but the > USR is unable to check to make sure it's a valid user, because it lost it > connection to the main server. But when I turn it off for about 2 to 4 > mins its working again with no problems. Anyone know why this is > happening? > > Thanks > Vito > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)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(a)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(a)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.

1 0