WinXP/4.83SP2 cannot find Tree/Context for 5 minutes after booting 2

[shinedog]

Here is about the strangest problem I have ever seen. We have two legacy Novell servers using Zenworks 3.2. We're not upgrading anything with the Novell as this is going away in about a month.

We just reimaged some Windows XP SP2 Dell stations with Client 4.83 SP2 installed. On boot, these stations come up to the Novell client logon and when attempting to login, it will hang for a minute or two and come back and say it can't find the tree or context, which of course are not locatable under those buttons. If I log in locally, I can ping my gateway, the router, and the server itself so it is definitely not a connectivity issue. The strangest thing is that if I let it sit on the login for about 5 mins, or even at the error message for 5 mins, and then try again, it logs in no problem.

Things I have tried:

*Disabled Windows XP firewall.
*Rebooted Novell 5.1 server.
*Moved the station back to VLAN 1 and changed IP address accordingly.
*Updated to Client 4.91 SP2.
*Different logins with varying contexts.

We have different workstations on different VLANs that are not having this problem. I was thinking there must be some sort of program not initializing right away that hangs the Novell service or something but there is no evidence of that locally, event viewer is clean, all services started when I log in locally.

Kind of baffled here. Any ideas?

 

[marvhuffaker]

Do you have Cisco switches?

Marvin Huffaker, MCNE

http://www.redjuju.com

 

[shinedog]

Why yes indeed I do have Cisco switches. These PCs connect through a patch panel to a 6509 which then uplinks to a 6513 where the Netware server is connected. The PCs and the Netware server are on different VLANs but putting them on the same VLAN hasn't changed the problem.

Is there something I should be aware of with Netware over Cisco switches?

 

[shinedog]

Incidentally, I saw your reply on another thread here at

http://www.tek-tips.com/viewthread.cfm?qid=1241434&page=1

and your #3 sounds very very similar so I am going to give that a shot this morning.

 

[shinedog]

Doh, no go on the Bad Address Cache Timeout and Bad Server Name Cache Enabled settings. Thought for sure that had to be it as the symptoms sound so similar.

 

[marvhuffaker]

To answer your question regarding NetWare and Cisco.. No. It isn't a NetWare problem. It's a Windows problem that is propogated by Cisco logic. You are only seeing it on the Netware login as a Symptom of the underlying problem.

I actually have a white paper written up for this for a client project I am currently working on. I'm going to extract bits and pieces and post here.

Also, it could be an SLP problem - not getting SLP to the workstation.. Your new VLANs could be interfering, or the owrkstations aren't getting SLP info like they used to.

The internal struggle I have here though, honestly, is that if you're getting rid of 'legacy netware' next month, why bother. You're throwing away something that you don't understand, that if you did, it could do some incredible things for your network. Why not upgrade to 'State of the Art NetWare' instead of whatever you're doing. I assume you're going to a Clunky and overly blaoted Windows server setup that is put together with bubble gum and bailing twine...

Anyway, here you go...
------
Root Cause Analysis
Many people look at the error messages and immediately blame the problem on 'Novell.' However, the error message is only a symptom of a much deeper issue that has two distinct parts. 1) Windows provides you with a login prompt before it is fully loaded and ready to go; 2) Faster and newer workstations boot faster than the network is configured to activate.

Problem Defined
The problem occurs because the ports on the Cisco switches go through a time consuming process to fully activate. The process can take 30 seconds or more, and is a default configuration out of the box. This can be demonstrated by turning on a workstation, and watching the port blink amber for 30 or more seconds before it finally lights up as solid (or whatever indicates it is fully active)

Solution
Cisco switches have a 'portfast' setting that needs to be enabled. Enabling portfast allows the port to fully activate immediately after sensing a network connection. With portfast enabled, users will be able to access the tree immediately.

Disclaimer
Enabling 'portfast' could have negative impact on the network if certain conditions exit. This is a solution that requires careful understanding of the switch and network infrastructure before implementing.



Marvin Huffaker, MCNE

http://www.redjuju.com

 

[LawnBoy]

Portfast is a patch designed to alleviate inherent latency in STP. I do not run STP because it can interfere massively with a WAP and legacy database apps (particularly Dbase).

<insert Dbase flame here, thank you>

 

[marvhuffaker]

That's why I caution against just going out and enabling it. You have to understand the infrastructure and the consequences of making a change like that. It's not a good fit for all environments.

I am also not a Cisco guy. but Lawnboy are you suggesting that you only have that latency when STP is configured? Turn STP off and you're good to go?

Marvin Huffaker, MCNE

http://www.redjuju.com

 

[LawnBoy]

I'm not a Cisco guy either, but my HP switches also have a patch for STP (forget their nomenclature at the moment). As far as I understand, the latency is inherent in any STP deployment, regardless of mfg. The switch has to take the time to check for duplicates in it's ARP tables, and reconfigure as needed.

However, turning off STP leaves you vulnerable to topology loops... and ARP storms can be really, really tough to nail down.

 

[LawnBoy]

HP fix is called RSTP - Rapid Spanning Tree Protocol. Same principles involved.

I've not heard of any side effects Portfast causes, but again, I don't run STP. There's a Cisco forum at Tek-Tips, I'd ask those guys about it.