Larry, you haven't given us much but maybe you don't have much. One thing that may help ease the symptoms is to turn on portfast on the ports the servers are connected. When the port does flap, it won't take so long for it to begin forwarding again.
You didn't mention what type of cards the servers are using. Are these 100mbs or gig cards and who makes the cards? There are known issues with certain cards and certain drivers. Are you using the latest drivers downloaded from the vendor's website? If these are gig cards, are they fiber or copper? If copper, could you have bad or old cable or maybe the cables are routed over something causing EMI? What about the OS on the Cat? Is it the latest available (it's up to 7.x now)? Is flow control turned on or off? You can set this separately for transmit and receive. Did you try moving the server(s) to a different port on the switch? Did you get the same results? Is it possible to move ther server(s) to a different blade in the Cat? What about to a different switch? Your logs indicate the port is going up and down and Spanning Tree is doing its job and not much else. You can see when troubleshooting issues on the list, we need more info. This is just a small list to check but maybe it will be helpful. Rik -----Original Message----- From: Puckette, Larry (TIFPC) [mailto:[EMAIL PROTECTED]] Sent: Friday, January 18, 2002 10:10 AM To: [EMAIL PROTECTED] Subject: 6509 roaming disconnects part2 [7:32449] Hello again group. I have another question to propose to you. But first an updated history of the issue at hand. We have a 6509 that serves as the core to a server farm that has both NT and Unix boxes on it. In the beginning there were infrequent link drops between servers and the switch that had no pattern to isolate a card or VLAN, etc... and then frequency increased to be a constant problem. Sniffer information gave very little to hang our hat on, with 99% of it's findings being 2 messages. Too many retransmissions TCP and octets/s: current value 932,384. High Threshold=500,000. An example of the logging buffer on the switch's interesting messages were; IPPS6509> (enable) show logging buffer 2002 Jan 16 02:15:44 %PAGP-5-PORTFROMSTP:Port 8/23 left bridge port 8/23 2002 Jan 16 02:15:49 %PAGP-5-PORTTOSTP:Port 8/22 joined bridge port 8/22 2002 Jan 16 02:15:49 %PAGP-5-PORTFROMSTP:Port 6/23 left bridge port 6/23 2002 Jan 16 02:15:50 %SPANTREE-6-PORTFWD: Port 8/22 state in VLAN 172 changed to forwarding 2002 Jan 16 02:16:01 %PAGP-5-PORTTOSTP:Port 8/23 joined bridge port 8/23 2002 Jan 16 02:16:02 %SPANTREE-6-PORTFWD: Port 8/23 state in VLAN 172 changed to forwarding 2002 Jan 16 02:16:06 %PAGP-5-PORTTOSTP:Port 6/23 joined bridge port 6/23 2002 Jan 16 02:16:07 %SPANTREE-6-PORTFWD: Port 6/23 state in VLAN 172 changed to forwarding 2002 Jan 16 03:41:28 %PAGP-5-PORTFROMSTP:Port 8/17 left bridge port 8/17 2002 Jan 16 03:41:29 %PAGP-5-PORTFROMSTP:Port 7/16 left bridge port 7/16 2002 Jan 16 03:41:35 %SYS-6-CFG_CHG:Global block changed by SNMP/216.141.33.71/ 2002 Jan 16 03:41:47 %PAGP-5-PORTTOSTP:Port 8/17 joined bridge port 8/17 2002 Jan 16 03:41:47 %PAGP-5-PORTTOSTP:Port 7/16 joined bridge port 7/16 2002 Jan 16 03:41:48 %SPANTREE-6-PORTFWD: Port 7/16 state in VLAN 172 changed to forwarding 2002 Jan 16 03:41:48 %SPANTREE-6-PORTFWD: Port 8/17 state in VLAN 172 changed to forwarding 2002 Jan 16 03:44:27 %PAGP-5-PORTFROMSTP:Port 8/17 left bridge port 8/17 2002 Jan 16 03:44:43 %PAGP-5-PORTTOSTP:Port 8/17 joined bridge port 8/17 2002 Jan 16 03:44:44 %SPANTREE-6-PORTFWD: Port 8/17 state in VLAN 172 changed to forwarding but these had no consistency over time as to what port or group of ports were experiencing this. some interesting 'show tech' information was; udp: 0 incomplete headers 0 bad data length fields 2 bad checksums 20839 socket overflows 108568195 no such ports tcp: 111664 completely duplicate packets (6407 bytes) 111129 keepalive timeouts Ok, if you're still with me... It was dictated that we REPLACE the switch by the customer but of course Cisco did not go for that and we did a scheduled reboot on the switch and all problems have cleared. Now the customer wants a bi-monthly reboot of this switch scheduled to prevent the problem from occurring. My questions are: Is there any technical reason that these scheduled reboots would be a bad idea? (politics dictate that logical reasons don't apply) Does anyone know of a previously proven fix for this problem that has documentation that could be used in discussions of whether these scheduled reboots are necessary? Thank you all for any help,, in advance. Larry Puckette Network Analyst CCNA,MCP,LANCP Temple Inland [EMAIL PROTECTED] 512/434-1838 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32472&t=32449 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
