«

Running Cisco 3550 switches and was experiencing problems with our
Dell PC's, network connectivity and downloading A.D. group policies.
We resolved most of our issues by enabling portfast on the switches
for the workstations and servers. My problem is that some of our PC's
are connected to those small Linksys switches (I know we shouldn't be
using them but someone saved a few pennies by only putting one jack
per office)and are still having problems so I'm not sure what to do at
this point. If I understand correctly, portfast should not be enabled
on a port that a switch is connected to. If I do enable
portfast...what am I risking? Problems with just the PC's connected
to the Linksys or the entire network?

In article <>,
The Other Mike <> wrote:
>Running Cisco 3550 switches and was experiencing problems with our
>Dell PC's, network connectivity and downloading A.D. group policies.
>We resolved most of our issues by enabling portfast on the switches
>for the workstations and servers. My problem is that some of our PC's
>are connected to those small Linksys switches (I know we shouldn't be
>using them but someone saved a few pennies by only putting one jack
>per office)and are still having problems so I'm not sure what to do at
>this point. If I understand correctly, portfast should not be enabled
>on a port that a switch is connected to. If I do enable
>portfast...what am I risking? Problems with just the PC's connected
>to the Linksys or the entire network?

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 Roberson wrote:
> In article <>,
> The Other Mike <> wrote:
> >Running Cisco 3550 switches and was experiencing problems with our
> >Dell PC's, network connectivity and downloading A.D. group policies.
> >We resolved most of our issues by enabling portfast on the switches
> >for the workstations and servers. My problem is that some of our PC's
> >are connected to those small Linksys switches (I know we shouldn't be
> >using them but someone saved a few pennies by only putting one jack
> >per office)and are still having problems so I'm not sure what to do at
> >this point. If I understand correctly, portfast should not be enabled
> >on a port that a switch is connected to. If I do enable
> >portfast...what am I risking? Problems with just the PC's connected
> >to the Linksys or the entire network?
>
> 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*.

"The Other Mike" <> wrote in message
news:...
> Running Cisco 3550 switches and was experiencing problems with our
> Dell PC's, network connectivity and downloading A.D. group policies.
> We resolved most of our issues by enabling portfast on the switches
> for the workstations and servers. My problem is that some of our PC's
> are connected to those small Linksys switches (I know we shouldn't be
> using them but someone saved a few pennies by only putting one jack
> per office)and are still having problems so I'm not sure what to do at
> this point. If I understand correctly, portfast should not be enabled
> on a port that a switch is connected to. If I do enable
> portfast...what am I risking? Problems with just the PC's connected
> to the Linksys or the entire network?

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

On 12 Sep 2006 21:51:17 -0700, "James" <> wrote:

>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?

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.

"James" <> wrote in message
news: oups.com...
> 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 Roberson wrote:
>> In article <>,
>> The Other Mike <> wrote:
>> >Running Cisco 3550 switches and was experiencing problems with our
>> >Dell PC's, network connectivity and downloading A.D. group policies.
>> >We resolved most of our issues by enabling portfast on the switches
>> >for the workstations and servers. My problem is that some of our PC's
>> >are connected to those small Linksys switches (I know we shouldn't be
>> >using them but someone saved a few pennies by only putting one jack
>> >per office)and are still having problems so I'm not sure what to do at
>> >this point. If I understand correctly, portfast should not be enabled
>> >on a port that a switch is connected to. If I do enable
>> >portfast...what am I risking? Problems with just the PC's connected
>> >to the Linksys or the entire network?
>>
>> 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*.
>

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

In article < .com>,
"James" <> wrote:

> 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?

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

In article <Sam.Wilson->,
says...
> In article < .com>,
> "James" <> wrote:
>
> > 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?
>
> 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.

> If ports on the linksys accidently get wired together,

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 Roberson wrote:
> In article <>,
> The Other Mike <> wrote:
> >Running Cisco 3550 switches and was experiencing problems with our
> >Dell PC's, network connectivity and downloading A.D. group policies.
> >We resolved most of our issues by enabling portfast on the switches
> >for the workstations and servers. My problem is that some of our PC's
> >are connected to those small Linksys switches (I know we shouldn't be
> >using them but someone saved a few pennies by only putting one jack
> >per office)and are still having problems so I'm not sure what to do at
> >this point. If I understand correctly, portfast should not be enabled
> >on a port that a switch is connected to. If I do enable
> >portfast...what am I risking? Problems with just the PC's connected
> >to the Linksys or the entire network?
>
> 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*.

In article < .com>,
<> wrote:
>> If ports on the linksys accidently get wired together,

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

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


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

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.