Valstan's absolutely on the right track, most "strange" AD issues are related to issues with the supporting locater services (DNS/WINS).

Nothing looks broken in your config.

Portfast doesn't actually apply when trunking is turned on. Kind of like "switchport access vlan NN" doesn't do anything when the op mode is trunk.

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.

J:

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.

HTH

Victor

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

end

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)

J:

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.

Understand?

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.

http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/ios121_8/swcg/stp_enha.htm#1042489

"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."

And...

"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. :-)

Thanks

Victor

david:

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.

Victor

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.