You should also look at set option debounce and set port debounce. These commands were added to deal with NIC vendors (3Com) who were staying from the IEEE Ethernet standards. Basically electrical signals from the NIC would go link up/down/up/down and the switch would see it as the card going up and down (silly Cisco!!). Debounce tweaks the tolerances for these NICs so Cisco will once again play nice with 3Com.
As an additional note to my bashing 3Com...2 customers recently purchased hundreds of new PC's (Manufacture name withheld) which came with built in 3Com NICs. Not a single PC will auto-negotiate properly. The cards all go to 100-Half and the Switch 100-Full. When the switch is forced to 100-Full the PC's still go 100-Half. One customer was replacing Compaqs with Intel cards that auto-negotiated correctly 95% of the time. Will 3Com go bankrupt within 12 months????? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Cotts Sent: Friday, January 18, 2002 3:08 PM To: [EMAIL PROTECTED] Subject: RE: 6509 roaming disconnects part2 [7:32449] >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=32538&t=32449 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
