3750G 12S Clients Lose Connection After Client Restart

[Highspeedlane]

Sorry about this very noob question. I can get clarifying info if needed next week as I won't be there again until Monday.

We have a 3750G 12S that is connected to its clients with 1000 Mb SFPs. On the switch is a simple Vlan all the ports are assigned to. The ports are auto-sensing gig connection speed and full duplex when I run the show interface command.

What happens is that if a client workstation is restarted or shut down and powered back up, the client cannot reconnect to the switch unless we cycle the switch itself (power off and back on)

I know only the very basics of switch configuring and finding it difficult to source any trouble shooting info on issues like this. Thanks if you have any places I need to look, or configuration perameters I could check to see if it's contributing to the problem.

[Reza Sharifi]

Since these are fiber gig interfaces (SFP), try hard coding the interfaces to 1000 full. Do the same for the end point devices and test again.

HTH

[Leo Laohoo]

We have a 3750G 12S that is connected to its clients with 1000 Mb SFPs. On the switch is a simple Vlan all the ports are assigned to. The ports are auto-sensing gig connection speed and full duplex when I run the show interface command.

Please post the config of the ports.

Can you also post the following command outputs:

1.  sh version

2.  dir flash:

[Highspeedlane]

Reza - will look into that, thanks.

Leolaohoo - will get that info at beginning of next week. Thanks for your help.

[Highspeedlane]

This network is not connected to the WWW so I have to hand copy stuff to post here.

The dir_flash: output looks something like this. I shortened the column showing time value by using (Time) instead

2 -rwx 616 Mar 1 1993 (Time) +00:00 vlan.dat

3 -rxw 171 Mar 1 1993 (Time) +00:00 express-setup.debug

4 -rxw 1049 Mar 1 1993 (Time) +00:00 multiple-fs

5 drwx 192 Mar 1 1993 (Time) +00:00 C3750-ipbase-mz.122.50.SE5

428 -rwx 5 Mar 1 1993 (Time) +00:00 private-config.text

429 -rwx 1886 Mar 1 1993 (Time) +00:00 config.text

------------------------

The sh version is - 12.2(50)SE5, Release Software (fc1)

------------------------

We suspect it's the NICs on the workstations because I'm told they are PCI cards in PCIe card slots, and the maximum transmission value settable in the Windows OS under device properties is 100Mb

I didn't see a way to hard code that speed on the switch. The >speed ? command just brings up Negotiate or non-Negotiate (this problem exists with either option).

The port stays alive if the workstation is restarted, but if you do a shutdown/power up of a workstation, you have to re-enable the port with shut/noshut.

Thanks for any insight here.

[Leo Laohoo]

I didn't see a way to hard code that speed on the switch. The >speed ? command just brings up Negotiate or non-Negotiate (this problem exists with either option).

Let see ... You have a 3750G-12S, right?

So how are you connecting the clients' NIC to the switch?  Fibre or copper?

IF copper and using GLC-T/GLC-TX you can configure the speed, however, if you are using fibre then there's no way you can change the speed.

If you want the fibre to run at 100 Mbps then you need to get the appropriate fibre optic module.

Cisco 100BASE-X Small Form-Factor Pluggable Modules for Fast Ethernet Applications Data Sheet

[glen.grant]

  Please clarify the problem a little more.  Do you see a link light  when powering up ?  Or are they just not pulling an ip address ?   If not pulling  an address make sure portfast is on each port , you can use the "switchport host " command on each port to turn it on , use only on client ports and not on any interswitch links.

[Highspeedlane]

Leolaohoo - clients connect via MM fiber from NIC to GLC-SX-MM SFP at the switch. I see in the client NIC properties (Broadcom NetXtreme Gigabit Ethernet) that when it is set to Auto it is negotiating 1000Mbs. It's settable speeds are 100Mbs or 10Mbs. Driver for it is up to date. I know what you mean about the SFP speed (all we have handy now are gig SFPs)

Glen - when a client is shut down and then powered up, the link light at the switch is totally black. Only when you go to the interface in Hyperterminal and issue a shut / no shut does it re-establish connectivity.

The ports are not addressed, they are members of a Vlan that just passes the client traffic on to a router.

Hope this info helps clarify and thanks for your assistance.

[Highspeedlane]

Update: I ran 'switchport host' on the ports and ran another test. After the host was powered back up, a console error message appeared "%PM-4_ERR_DISABLE: link-flap error detected on port Gi1/0/11"

The rest of the message is that it is putting the port into error disable.

I'm guessing this issue is caused (as mentioned previously) by the host NICs.

In your opinion, would it hurt anything to enable disable recovery and set a short time period, such as 30 seconds?

The port always returns to a normal state after manually (shut /no shut) recovering from the error, this occurs only When the host is initially started up from a shut down state.

We would only have to do this until the new NICs arrive, but since there's no telling how long that will take (we have to go through a contracting purchase process that adds to acquisition time), the above short term solution seems feasible if you don't think it will damage anything.

Thanks.

[Leo Laohoo]

In your opinion, would it hurt anything to enable disable recovery and set a short time period, such as 30 seconds?

If you have a possible layer 1 issue and you enable disable recovery, I don't see how this is going to help.  All this does is re-enable the port automatically.  As to whether or not it will fix a potential problem the answer is NO.

Can you post the output to the following commands:

1.  sh interface Gig ;

2.  sh controller e Gig

[Highspeedlane]

To clarify, the clients connections survive restart (I thought differently when I titled the post). It is only when clients are shutdown/startup that link-flap causes a port errdisable condition. Posting outputs (MAC address removed). Thanks for your help on this.

switch#sh int gi1/0/11 GigabitEthernet1/0/11 is up, line protocol is up (connected)   Hardware is Gigabit Ethernet, address is   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,     reliability 255/255, txload 1/255, rxload 1/255   Encapsulation ARPA, loopback not set   Keepalive not set   Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP   input flow-control is off, output flow-control is unsupported   ARP type: ARPA, ARP Timeout 04:00:00   Last input never, output 00:00:00, output hang never   Last clearing of "show interface" counters never   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0   Queueing strategy: fifo   Output queue: 0/0 (size/max)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec     76183 packets input, 27279360 bytes, 0 no buffer     Received 4012 broadcasts (0 multicasts)     0 runts, 0 giants, 0 throttles     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored     0 watchdog, 0 multicast, 0 pause input     0 input packets with dribble condition detected     169177 packets output, 56876693 bytes, 0 underruns     0 output errors, 0 collisions, 11 interface resets     0 babbles, 0 late collision, 0 deferred     0 lost carrier, 0 no carrier, 0 PAUSE output     0 output buffer failures, 0 output buffers swapped out

switch#sh controller e gi1/0/11     Transmit GigabitEthernet1/0/11          Receive     56891887 Bytes                        27280902 Bytes         75717 Unicast frames                  72177 Unicast frames         88092 Multicast frames                    0 Multicast frames         5563 Broadcast frames                  4021 Broadcast frames             0 Too old frames                26835871 Unicast bytes             0 Deferred frames                      0 Multicast bytes             0 MTU exceeded frames            445031 Broadcast bytes             0 1 collision frames                  0 Alignment errors             0 2 collision frames                  0 FCS errors             0 3 collision frames                  0 Oversize frames             0 4 collision frames                  0 Undersize frames             0 5 collision frames                  0 Collision fragments             0 6 collision frames             0 7 collision frames              25436 Minimum size frames             0 8 collision frames              17564 65 to 127 byte frames             0 9 collision frames              16224 128 to 255 byte frames             0 10 collision frames              2635 256 to 511 byte frames             0 11 collision frames              1298 512 to 1023 byte frames             0 12 collision frames              13041 1024 to 1518 byte frames             0 13 collision frames                  0 Overrun frames             0 14 collision frames                  0 Pause frames             0 15 collision frames             0 Excessive collisions                0 Symbol error frames             0 Late collisions                      0 Invalid frames, too large             0 VLAN discard frames                  0 Valid frames, too large             0 Excess defer frames                  0 Invalid frames, too small       102264 64 byte frames                      0 Valid frames, too small         10566 127 byte frames         18576 255 byte frames                      0 Too old frames         6783 511 byte frames                      0 Valid oversize frames         2203 1023 byte frames                    0 System FCS error frames         28980 1518 byte frames                    0 RxPortFifoFull drop frame             0 Too large frames             0 Good (1 coll) frames             0 Good (>1 coll) frames

[Highspeedlane]

Sorry about the output format. For some reason I can't get the browser I'm using to Paste unless I go to the advanced HTML feature (I have no ability to change settings). Thanks.

[Leo Laohoo]

Don't see anything wrong from the output.

[Highspeedlane]

Yes, we think the NICs are causing the link-flap and I believe there are replacements on order.

I want to thank you for your time and hopefully when NICs are replaced this issue will go away.

We ended up (as a short term workaround) enabling automatic errdisable recovery and set the time out interval for 120 seconds. It works great as once link is established it remains stable until the client is shut down and powered back up again.

Thanks again.