Portfast question

If ports on the linksys accidently get wired together, you can end up with broadcast storms (because layer 2 doesn't have any TTL, the broadcasts can bounce around the network indefinitely.

Historically, there used to be a number of anecdotes about complete network meltdowns that were traced to a single device. That was -mostly- in the days of unmanaged switches and hubs and half duplex, but even later there were reports of network lockups traced down to spanning tree loops.

It's been more than a year since I looked at the 3550 documentation, but I seem to recall seeing in there some protections that could be enabled that could reduce the effect of this.

Modern managed switches should automatically disable a port that is jammed (avoiding total network lock up). *Should*.

Port Fast shouldn't have any affect on a PC's network connectivity. I have never had any problems with PC's connecting to a non PortFast port. Has anyone else seen problems like this before?

Your problems could also be due to a Speed / Duplex mismatch. Check problematic ports for CRC errors (show interface fastethernet x/y) and manually set speed and duplex whenever possible.

You can use PortFast on ports which connect to switches, however, enabling PortFast effectively disables spanning tree on that port. This means that if someone was to create a loop in the network by having more than one uplink from the Linksys device then you will start to experience broadcast storms. Also, you should never enable PortFast on Trunk ports.

Fortunately there are some safe guards you can implement. Whenever I enable PortFast I also enable the following:-

switchport mode access bpdufilter enable bpduguard enable

If a BPDU packet is detected on a port with these commands enabled the switch will put the port into err-disabled mode (shut down).

I would suggest reading up a little on Spanning Tree, Port Fast and the commands above and then enable PortFast for one of the Linksys devices and see if it fixes your problem.

Be sure to post the outcome here.

James

Walter Robers> > >Running Cisco 3550 switches and was experiencing problems with our

We also had problems with AD due to a couple of the AD servers not having portfast enabled.

Enabling portfast on the link to the Linksys switch will not cause problems by itself. .If another link gets connected between the two switches than a layer-2 loop is formed but if that 2nd link does not have portfast enabled than spanning-tree will block one end of the link. Of course if both links have portfast enabled then the layer-2 loop remains.

It's not uncommon to see single switch-to-switch links configured with portfast. In fact without it, portfast on the access ports of the remote switch is only allowing hosts attached to that switch communicate between themselves because the switch is forwarding frames on the access ports but the link back (possibly to the rest of the network) is going through the spanning-tree states and won't start forwarding frames for 45 sec. I believe.

And it doesn't matter whether the switch-to-switch link is configured as 'access' or 'trunk' .. there is a 'spanning-tree portfast trunk' option.

BernieM

Thanks for the advice from everyone...will try out a couple of things and read up on spanning tree some more.

Just to clarify...we're not really having network connectivity issues exactly...it's just an AD thing. Didn't really notice any network problems until we implemented a startup script (regular login scripts ran fine)...alot of the PC's weren't running the startup scripts and group policy and "domain not found" errors were in the event logs. Ran about 1/2 dozen tests on machines with these issues and enabling Portfast on their ports fixed all of them.

Enabling portfast does NOT disable spanning-tree on a port permanently, it only disables spanning-tree until a BPDU packet is received on that port. Without spanning-tree portfast, after the port comes up, the port listens for 30 seconds for BPDU packets to determine if spanning-tree is running on the newly connected device (LISTENING). During this time, no packets are sent or received, except for BPDU packets. With portfast enabled, the packet is immediately put into FORWARDING state. Subsequently if a BPDU packet is seen on the port, the port is IMMEDIATELY then put into LISTENING state and spanning-tree is enabled on that port.

The biggest problem with most of the low-end "desktop" type switches is that they don't even run spanning-tree, so enabling bpdugard and bpdufilter have no effect.

Generally, it is always a good idea to always enable portfast. Portfast is always disabled when a port is in trunking mode, even if it explicitly configured for portfast.

Scott

If you mean "PC running Windows" then I haven't come across any documented problems, but there are anecdotal stories of PCs timing out on DHCP because the switch port was doing its listening/ learning/ forwarding trick. There were certainly documented issues with the dynamic address allocation in AppleTalk failing for that reason.

Sam

Using catalyst 2950 switches I find it takes a long time to receive an IP address whilst using RIS on a W2k server - if I plug in an unmanaged switch to the same point and then connect my device to it I get the ip address almost instantly.

I was told it was a portfast issue although it doesnt seem to give me any other issues so havent followed it up as yet.

Walter, you mean physically a loop in between two ports of a switch ?

perhaps you can also use storm-control features in IOS on some port if you have suspisions of broadcast storms.

Ahmad

Walter Robers> > >Running Cisco 3550 switches and was experiencing problems with our

You've never accidently done it?

A pile of cables running under a desk, a pair of ports, you're trying to clean up, you plug one of the ports in, look around and grab the other cable and plug it in, crawl out from under the desk and nothing works... because you accidently plugged both ends of the same cable into the wall warts.

Then there are cases where you have a low-end crossbar switch in the back of a device, such as a multiport switch on the back of a wireless access point, and you accidently plug in two different ports from it into the LAN.

As for what -users- will do... well when you accidently plug a phone into a datajack, that can create a very effective loopback plug :(

Right, but it's been enough years since I IOS'd at that level that I didn't want to name off specific features, since half of them have changed anyhow.

Makes sense - when you connect the PC to the Catalyst the port comes up and spends ~45 seconds going through spanning tree startup. When you plug a dumb switch into that port it'll do the same but then the Catalyst port stays up. When you later (more than 45 seconds later) connect your PC to the dumb switch then the PC will see traffic straight away because there's no spanning tree on the dumb switch port.

Sam