We are running Novell 5.0 and using the default thresholds that are set in sniffer we are getting excessive amounts of the following expert diagnosis and symptoms. <br>Ack too long<br>window frozen<br>too many retransmissions<br>too many loops on the same request<br><br>We have problems in our network and can't really get a good baseline of what our network would look like while running well. <br><br>We have put it in both our test network and our production network and have seen similar results. Are the thresholds just set to small or do we really have some problems. I am hoping someone out there has had a similar experiance and can help.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Novell environment
- Thread starter bmorritt
- Start date
Are you experiencing broadcast storms? In my experience all those symptoms are usually linked to broadcast storms causing congestion on a network. You can usually find them under your global symptoms in the expert window. Are you running connections to a local Novell server or is it across a wide area link? IPX is notorious for excessive broadcasts. We have the same problems locally so I know where you are coming from. The only way to cutdown on the broadcast storms is to do IPX filtering and that gets hairy. I hope this helps and good luck.<br><br>Rob Brown
- Thread starter
- #3
Rob,<br><br> No, we aren't really experiencing broadcast storms. And like I said we have tried it in our test network which is relatively small. And we are using some pretty beefy Cisco switches with Gig links. <br><br>It is a local Novell server, our only Wan link is our T-1 to the internet. We do have a mixed enviroment (Unix & alittle NT) in our production network, but our test network is pure Novell right now.<br><br>Thanks for your post!
Sorry it took so long to get back. Are you using TCP/IP with Novell 5 or actually still running IPX? I haven't messed with 5 yet so maybe there is something new that can be causing it. I know sometimes it is just the way applications work that it records that type of information. I am guessing here so if you figure it out let me know.<br><br>Thanks<br>Rob
- Thread starter
- #5
No Problem....acutally I need to correct myself...we are getting some broadcast storms on our production network, atleast according to sniffer...I am taking a better look at things right now, I had been going by what a co worker had told me about the production network.<br><br>The plan is to go to pure IP but as of right now we are running a mixed bag of IP & IPX.<br><br> I will def. let you know if I figure anything out.<br><br><br>
I'm curious if you have resolved your Novell problem. It's scary but we have the same situation with a similar environment. Novell 4.11,5.0 with UNIX and NT. We have gigabit ethernet though Bay Network switches. My sniffs come up with the same information. I am not experienced on the use of the sniffer as probably you are but how can you tell when you have a broadcast storm or an underpowered server? Any input would be appreciated!!<br><br>Thanks in advance!!<br><br>maclark
- Thread starter
- #7
maclark,<br><br> Nope, really haven't been working on it much lately...have been spending to much time putting out fires and working on major projects. I am still pretty new to the sniffer myself, but am starting to get the hang of it. In our case I doubt we have underpowered servers, but anything is possible.<br><br> I will post here when we figure it all out...<br><br>Brian
To make a long story short, don't believe everthing the expert in sniffer tells you. I have trace a lot of IPX/SPX and still have a lot to learn, but if you go through the tedious process of verifying the expert diagnosis you may find some incorrect analysis:<br><br>Ack too long - usually a sluggish PC but may just be an app waiting for a keystroke<br>Window frozen - TCP/IP can mean the incoming buffers are not being service if they stay low (<<1000) for several frames. Otherwise, it is not uncommon to see them stuck high (~7000-8000 for ethernet)<br>Too many retransmissions - sniffer makes a lot of errors here. Check the sequence<br> numbers and ack numbers to see missing frames. Verify with the netstat command<br> and look for retrans on TCP/IP. For IPX match up the retransmitted frames to make sure they are indeed a retrans of the same data.<br>too many loops - bad programming , give it up progammers will always do this.<br><br>baselinne - look for a good throughput baseline by finding an ncp transfer after the file<br> has opened and before it closes. Save just these frames and look at the statistics tab. Pay attention to how large the frames are and how long the connection stays in burst.
- Status
Similar threads
- Locked
- Question