Cisco 3560 - Windows PCs/Servers taking 10 miniutes to boot

Unanswered Question
Apr 28th, 2008

Windows PCs and Servers are taking up to 10 minutes, and are stuck on the screen "Preparing Network Connections".

All host ports are set for spanning-tree portfast.

Are there any other reasons why this might happen, other than possible Active Directory issues?

As soon as I unplug hosts from the switch, they boot up quickly.

Attached is a config example.

Thanks ahead of time!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
d.metheny Mon, 04/28/2008 - 10:41

Do you have other switches on this LAN? If so, how does boot time compare?

When you boot the PC while disconnected to the switch, then you connect it to the switch, do you get an IP address right away, or does it take a few minutes?

Assuming you are using DHCP - have you tried putting a static IP (and DNS Server IP) on the PC?

What is your ping RTT to your DHCP/DNS server from the PC?

lamav Mon, 04/28/2008 - 11:32


I dont know if this is causing the delay you are talking about, but the config you're using is a little fugazy.

Why do you have portfast configured on the trunk? It should never be configured on a trunk. Configure portfast only on interfaces that face end devices.

Why are you using vlan 1 as your data vlan? You should probably leave vlan 1 for management and for control plane traffic: STP, CDP, PAgP control messages, etc. Im assuming you are using vlan 1 as a data vlan because Im seeing a /22 mask and none of the interfaces is configured to be placed in a vlan other than this default.



lamav Mon, 04/28/2008 - 12:09


Configuring portfast on a trunk is counter intuitive and has forever been discouraged by Cisco for obvious reasons. The purpose of portfast is to bypass the STP listening and learning states and have the portfast-configured port go directly to the forwarding state. The danger in doing this is obvious if you have multiple trunks...

Now, if it is true that portfast does not apply when trunking is enabled on an interface, can you kindly provide a link to that? That is the first time I have ever heard that.

Also, configuring a trunk port with the switchport access vlan command does do something. It changes the native vlan on that trunk port from 1 to whatever you enter in the command. It is done quite frequently, in fact.

"It's his prerogative to use VLAN1 for his data traffic. Is it best practice? Not really but it's still a functional and supported config."

Yes, it is. Never said it wasn't. What I did say is that he should "probably" want to change that approach and I gave him a reason for it. It is definitely not recommended by industry standards or Cisco best practices.



Re: portfast. It says it when you configure portfast on the port "%Portfast has been configured on FastEthernet0/5 but will only

have effect when the interface is in a non-trunking mode." Now, "spanning-tree portfast trunk" that's playing with fire.

Re: access vs. native vlan when trunking. Beg to differ:

sw1#sh running-config interface po1

interface Port-channel1

switchport access vlan 5

switchport trunk encapsulation dot1q

switchport mode dynamic desirable


sw1#sh interfaces po1 switchport

Name: Po1

Switchport: Enabled

Administrative Mode: dynamic desirable

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 5 (VLAN_D)

Trunking Native Mode VLAN: 1 (default)

lamav Mon, 04/28/2008 - 13:54


Thanks for the response. I appreciate the time you took to explain yourself. Let me try to shed some light for you.

"Re: access vs. native vlan when trunking. Beg to differ:"

First of all, don't beg, it's unbecoming. ;-)

Second of all, showing me the status of the trunk port and the native vlan is nice of you to do, but it does not address the issue at hand.

It was your contention that applying the switchport access vlan command on an interface already configured as a trunk "doesn't do anything," as if the command is inconsequential. It is consequential. Maybe not in terms of the immediate situation, but it does alter the behavior of the port.

Let's review some basics:

1.) All switch ports, by default, are in vlan 1.

2.) The native vlan on a dot1q trunk, by default, is vlan 1.

3.) If a trunk port ceases to function as a trunk, it will default to being an access port in vlan 1, the native vlan.

4.) HOWEVER, with the switchport access vlan command, you can dictate which vlan that trunk port will default to when and if it stops trunking.


I've also used that command in trunk mode for another reason, which I don't care to get into now becuase we are digressing from the issue.


Now, as far as the initial point. The initial point I made with regard to the OPs config is that portfast should not be configured on a trunk port. This is fundamental and you will see this caution in almost every discussion of portfast and trunking that you will ever come across.

There are 2 warnings in the following Cisco link alone.

"Caution: Because the purpose of PortFast is to minimize the time that access ports must wait for STP to converge, it should only be used on access ports. If you enable PortFast on a port connected to a switch, you might create a temporary bridging loop."


"Caution Use PortFast only when connecting a single end station to a Layer 2 access port. Otherwise, you might create a network loop."

As far as the output you displayed, it is expected that the switch is going to inform the administrator that "%Portfast has been configured on FastEthernet0/5 but will only

have effect when the interface is in a non-trunking mode" when you add the portfast feature to a trunked port.

Remember, portfast is used to bypass the STP listening and learning states and place the port directly into the forwarding state from the blocked state.

In a situation in which the trunk port is already in a forwarding state, the portfast command will not take effect, of course. This is not a point of contention.

The cautionary note is with regard to the situation in which the trunk port is coming up. You would want to wait for STP to converge and place any redundant port -- which can cause an L2 loop -- in a blocked state to prevent a temporary bridging loop.

Ihope I have helped clarify things. If not, sorry I couldn;t help you more, but c'est la vie. I'm moving on. :-)



lamav Mon, 04/28/2008 - 14:05


Sorry we digressed. Please take the time to digest the information because I think it will help you in the long run, notwithstanding the immediate problem at hand.

Good luck.


I was only responding to you assertion that, and I quote "configuring a trunk port with the switchport access vlan command does do something. It changes the native vlan on that trunk port from 1 to whatever you enter in the command. It is done quite frequently, in fact." The pasted output was to demonstrate that it does not, in fact, set the native vlan. The native VLAN and access VLAN IDs are each part of 2 different switchport modes. I do understand that the access command only applies when the port switches to a non-trunked mode.

As for your points on best practices (including portfast). I'd love to go over them for the benefit of the OP but that would be hijacking the OPs thread even more than we already have :-).

I now return to regularly scheduled programming.


This Discussion