On Mon, 16 Aug 1999, Tatai SV Krishnan wrote:
I have not seen this problem nor have heard from anyone - A few days ago I came to know about this - may be I missed this list or something. As far as ISDN goes - I used it - have a nailedup connection with our chassis here and have never seen the problem - I do use some of the same TA's mentioned in the problem.
Nailing up both channels seems to keep things in harmony for longer periods, but using a BOD set-up like I used to caused problems a lot more often.
Got to disagree with this. 2.0.81 has more fixes in terms of packet bus issues and features. Yes 1.2.37 is very close but does not have the same type of feature set.
No argument there. I like the telnet to the HDM feature of the 2.x.x code. What I meant was that his upgrading to 2.0.81 probably wouldnt help his ISDN problem (at least judging from what I am experiencing). Not that he shouldnt try.
We have not tried the MTU option. I want to make sure it's not my Netgear first. Don't get me wrong, we have a lot of ISDN customers complaining, but I've had compression turned on recently, and now that it's off, I want to make sure that isnt what was choking the router. The router, when first recieved and brought on-line (around September of last year) worked flawlessly (with out compression) until 2.0.81. AFAIK it was screwing up before I played with compression.
Krish, what commands would be most beneficial for me to run for your troubleshooting efforts? (from the ARC or HDM? Both?)
So the problem is there irrespective of compression enabled or not correct?
Yes, I believe that to be the case.
If so are you also have the same problem where you cannot browse (send http data) but can use pings etc? If that is the case first in order to reproduce the problem faster I would recommend setting the mtu for the user at a low value like 576 and then disable tcp header compression.
When this happens to me I experience "router death". I cant go anywhere through any TCP port. No web, no mail, no telnet. I can run around fine on the lan of course, and telnet into the router, but thats it. Turning off the router is the only way to unlock it. Like I said before, I am still at the stage of determining if it's my router or it's the TC box. One would think that if it was the TC box, I could simply drop both channels and reconnect, problem corrected, but I dont believe this is the case. I will post my observations later this evening. I have re-software downloaded the router once already with no effect. Like I said, this was not an issue until our last upgrade to the TC box. I will try the MTU fix. There is no option I can find for header compression on the Netgear so I will have to disable it on the arc. When I refer to compression I am referring to STAC which I believe is packet data only. I could be wrong. That being said, the largest part of our customers problems seem to occur when they are bringing up the B2 channel. If it works, everything goes ok, if it doesnt, the packets stop until the B2 channel times out (BOD causes it to drop due to 0% utilization) and things start up once again on the B1 channel. Of course this causes a flood on the B1 which causes B2 to re-kick in and hopefully this time it gets a good connect. if not, we repeat the time-out again... When I was using BOD, this is also what I experienced. This is from Netgears, 3Com IQ modems, Pipelines, etc.
If you have a setup where the problem is currently happening send me note, will be glad to take a look at it.
krish
I will definately keep you posted. -Ken ___ ___ (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) - 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.