>From "Cisco LAN Switching" by Clark and Hamilton pages 262-3, 271-3 see the discussion of PortFast and disabling Port Aggregation Protocol. On CCO look for a command "set port host" that should change several parameters in one shot. "The set port host command sets channel mode to off, enables spanning-tree portfast, and sets trunk mode to off. Only an end station can accept this configuration." That should eliminate your logging messages. It should speed reconnection in the case of a disconnect. You have already indicated that speed and duplex are hard coded on the switch and (I hope) the NIC as well. I cannot comment on the reason for the initial disconnect. Sorry about the politics -
> -----Original Message----- > From: Puckette, Larry (TIFPC) [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 18, 2002 9: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=32529&t=32449 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
