We have a 6509 with 4 vlans defined on it. Our Novell 4.xx server has 1 nic plugged into each VLAN. Workstations are running Dos. The network is running only IPX/SPX over Ethernet. There is no inter vlan routing on the 6509 because the workstations dont need to communicate with each.
Workstations are running fiber nics connected directly to MTRJ blades on the 6509. The Novell server nics connect to a blade with ordinary RJ-45 ports.
Periodically we in the application on the Novell server we loose connectivity between all workstations in a VLAN and the Novell server application. When this occurs there are no indications of errors on the 6509. All ports appear to be up and indications are we have layer 1 and 2 connectivity. This leads us to believe that the application is the problem. Packet captures have not yielded any clues.
We need to rule the network out as a cause. Any suggestions on what we could look at on the 6509? Does the 6509 perform MLS on IPX/SPX by default? Could IPX/SPX MLS cause these symptoms?
We have the IPXping.nlm on the server however is there some sort of IPXping program needed on workstations to use IPXping to test connectivity?
Is Spanning-Tree PortFast enabled on the switch ports that the servers plug into? How about on the switchports that the workstations are plugged into? Do you have any switches plugged into the 6509, and if so are there any redundant connection paths?
Things to look at on the Novell side:
Is your IPX/SPX-based application very network traffic intensive? When you lose connectivity on a VLAN, is it all users all at once on that VLAN, or just a handful but they all happen to be on the same VLAN? When you lose connectivity, do you just have to log back in to re-establish connection?
On your server, are you seeing Watchdog timeout messages? On the clients (in NET.CFG) and on the server (via SPXCONFG.NLM) what are your IPX Retry Count, Minimum SPX Retries, SPX Verify Timeout, SPX Listen Timeout, SPX Abort Timout? On a busy network segment the keepalives between the server and a workstation that's been idle can get lost in the high volume of traffic, and a workstation's server session can end up being disconnected prematurely if it's using default values for those parameters.
I have found in the case of Watchdog timeouts and workstations being disconnected from the server that tripling the retry counts and doubling the timeouts helps. Setting changes need to be made both on the client side, and on the server.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...