From: Joe Freeman (joe.freeman@xxxxxxxxxxxxxx)
Date: Mon May 06 2002 - 13:30:10 GMT-3
How many NICS are in the server? Are you using just IP?
I ask this because the sho int below indicates counters were cleared 25
hours or so prior to the sho int command. In that time frame, the switch has
seen no input on that port from the server.
If you've got multiple NICS on the same IP network, check to see which one
is bound to IP first, chances are, it's the other NIC. This creates a
problem with some stacks and switches because all IP traffic outbound from
the server will go out the first NIC to bind to IP. Because of this, the
switch never sees frames sourced from the other NIC, so it doesn't put an
entry into the CAM for that NIC.
This causes the switch to have to flood frames to the IP bound to the second
NIC out all ports, in the expectation that the reply traffic will be sourced
from that NIC, so it will then be able to make the CAM entry.
Since the IP stack will instead send the replies out the first NIC to bind,
with the IP address of the second NIC, the switch never learns the correct
MAC address/Port relationship. When a host issues an ARP request, the server
will reply, correctly since the bindings are correct, with the MAC address
of the second NIC, but it will usually do it via the first NIC.
I've seen this problem several times, mostly with AIX machines, but also in
Solaris boxes, Linux boxes, NT and Netware. It's not been consistent,
however with any platform other than AIX, so YMMV.
So far, the only two work arounds I've found are to put the NICS on
different subnets, or to put static CAM entries in the switches (YUK!).
However, it does look like you've got a duplex mismatch, although the switch
is usually intelligent enough to recognize that and complain in the logs.
Excessive Input Errors (usually, but not always Alignment Errors), and CRC
Errors of roughly equivalient numbers are a pretty good indication of a port
mismatch condition. Of course, a port mismatch may not always be a
configuration issue with either side... a bad cable can appear to be a
mis-matched port as well.
Anyhow, that's my experience with the information you've presented. Hope it
helps.
Joe Freeman, CCNP-VA/CCDP
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brett Lewis
Sent: Monday, May 06, 2002 5:08 AM
To: 'Jeff Szeto'; ccielab@groupstudy.com
Subject: RE: (Long) Network Slow
Jeff,
Is the interface card on the Novell server set to auto-negotiate for
speed and duplex?
Brett
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jeff Szeto
Sent: 06 May 2002 05:30
To: ccielab@groupstudy.com
Subject: OT: (Long) Network Slow
Hi Group,
Sorry for this OT thread, but I need help.
My friend's network has a novell file server and an email server. Users
complain sometimes it takes a long time to open a file or an email
attachment.
All the PCs and servers are connected via two 3500 switches which are
interconnected via gigabit module.
I check the switches and see the port that connecting to novell server
has
many errors (see the show interface below), while the other ports seems
OK.
FastEthernet0/35 is up, line protocol is up
Hardware is Fast Ethernet, address is 0008.a3d0.f863 (bia
0008.a3d0.f863)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters 1d01h
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 225000 bits/sec, 64 packets/sec
5 minute output rate 68000 bits/sec, 61 packets/sec
4839382 packets input, 1992532408 bytes
Received 21073 broadcasts, 0 runts, 0 giants, 0 throttles
24545 input errors, 24545 CRC, 0 frame, 302 overrun, 302 ignored
0 watchdog, 236 multicast
0 input packets with dribble condition detected
7751432 packets output, 3144451132 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
I also use a sniffer to see what is happening. Although not much was
found, I
list the major finding below. They appear from time to time and my lead
to the
problem.
There is no loop on the switches and users have the permissions for the
files.
Source ---> Destination ----- Summary
PC Netware Loops on same request
Netware PC Request Denied
PC Email Ser Ack Too Long
PC Email Ser Window Frozen
Any suggestions are welcome and appreciated.
Thank you in advance
Jeff
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:51 GMT-3