I have about 250 servers that are directly connected to a 6500 switch. I received a report that data transfer from one of the servers with a Gig NIC in VLAN100 to another server with Gig NIC that is connected to the same VLAN100 is experiencing very high slowness. Can someone please guide on what would the best method to find out what is causing this slowness between these servers that are connected to the same switch?
Thanks in advance,
Since both hosts reside on the same vlan, a routing or L3 forwarding issue can pretty much be ruled out.
The problem could be with one or both of the switch ports, the cables that connect the servers to the switch ports, the server NICs, or a configuration issue.
1.) Check the stats on each switch port. Look for any errors. Clear the counters and monitor the stats.
2.) Check that speed and duplex settings match on each server NIC and the port to which each is connected. Mismatches cause intermittent loses in connectivity. SEE ATTCHMENT IN NEXT POST.
3.) Check each server NIC for erros.
4.) If speed and duplecx are OK, start swapping out hardware: switch ports, server cables, NICs, etc.
Obviously, swapping out hardware will interrupt service, so make sure you have th egreen light to do so.
If you don't find any problem with the physical layer hardware or data link layer speed and duplex settings, start examining the TCP/IP stacks, application statistics and overall health of each server.
Please rate all posts that are helpful.
I have the same Issues when I connect a HP server NIc to a Cisco 3750 Gigabit switchport.
Could you tell me please what is the solution to fix it?
Thanks in advance,
You should refer to the document that I attached in one of my previous posts on this thread. Scroll up.
I will say that the 'autonegotiation' feature between different manufacturers' can cause some issues on link integrity.
I am still troubleshooting this issue as the systems group won't allow me access to the servers in question. I am also using a sniffer (netscount) reports to gather traffic informtion on these servers.
I will post again once I have new updates.
Gig Full Duplex on both ends (Server and SW Port)
How do you find out what the NIC buffer and memory sizes are?
In some of Cisco whitepapers, they mention something about buffer overrun and buffer underrun with respect to the NIC card since memory or CPU can't catch up. Is this referring to the device's memory or the NIC's memory?
If you don't see any errors, collissions, packet drops in Switch ports connected to servers. Can you check if there is an update available for the server NIC driver by running Windows Update?
If you are sure that network is okay i.e. switch ports connected to two servers has no errors whatsoever, switch cpu/mem utilization is low, monitored bandwidth utilization is low at the time they experience the slowness. Then it is safe to say that the problem could be in the server side. The way Windows 2003 Server is setup affects overall system performance which includes network. A poorly trained Windows 2003 System Admin will not know this and just point its finger in the network if their data transfer accross the network is slow. For example, always do the following best practice when setting up a Windows 2003;
- Make sure to have plenty of RAM for the setup type and applications/services that will be running in this server
- 20GB C partition (preferably RAID1)
- C will only installed with the system and other windows services as patches/updates are large and accumulating.
- 4GB/4GB Pagefile (maximum for NTFS), you can set higher but windows will not use more than 4GB.
- Pagefile in other partition or separate disk (preferably RAID0)
- Do not install unecessary application/services specially media player :)
- Regularly apply Security and Driver patches/updates
- Install AntiVirus
If you don't have a monitoring system in place for your network, it's easy to point finger at you as you won't have a historical record to verify. Always monitor all network devices cpu, mem, and ports. CRICKET can monitor interface errors unlike MRTG.
Thank you very much for all the replies.
I will troubleshoot next wednesday and friday and will come back with the results.