Changing access vlan to trunk ( on end user side)

[Kanan Huseynli]

Hi there,

when I worked with DTP in my lab,I have seen behavior different from what is written in Cisco docs ( what was it please skip).

So,I decided to change my port IN PRODUCTION network from access 101 to trunk with native 101 and sniff DTP traffic to understand this behavior (how my connecting Switch acts, as in doc OR as in lab) .

What I did step-by-step I will share now,BUT I want to say that after it, problem with voice ports happened  in PRODUCTION. (Really,didnt understand what happened,but want to know it).

Normal configuration of my user-port:

interface FastEthernet0/43
 switchport access vlan 101
 switchport mode access
 switchport voice vlan 30
 auto qos voip cisco-phone
 switchport nonegotiate
 spanning-tree portfast
end

1) switchport trunk encapsulation dot1q ( it still does not have effect,because port is access)

2) switchport trunk native vlan 101 (in order Sw to get untagged (sent by my-PC) frames in native vlan 101)

3) switchport mode trunk (due to STP I have lost connection for ~50sec)

Note that,access port settings (portfast,access vlan 101,voice vlan 30) are still there.

I haven't seen DTP traffic in sniffer,and suddenly noticed that "switchport nonegotiate" is configured previously. So,decided to remove this command. When I removed it,again I have lost connection for (~50sec),it seems for STP,but why? - this is my first question.

When connection came up,I have informede that "external calls dont work". I shutdown my port (then I backed config up from another PC) and problem solved.

Here is,my second question,what happened here? What might be reason for this? I just changed access port (vlan 101) to trunk with native vlan (vlan 101).

Please,help me figure out this( really,want to understand the process that happened.

P.S It seems,voice port had effect,but dont know how.

P.S.S Also,I want to say that,may be problem happened after step 3. May be "switchport nonegotiate" had not real effect. Because,I did removing "switchport nonegotiate" 1-2 minutes after step 3.

Regards,

[lpassmore]

If I can understand your sequence here:

1. You asked why STP will be the cause of your loss of connectivity for ~50secs.  Although you have spanning-tree portfast, depending on the IOS level, this does not always work on a trunk connection.  You may need to change that statement to 'spanning-tree portfast trunk' or spanning-tree edge'  to solve that particular issue.

2.  You lost phone connectivity when your interface changed into a trunk with the data (native) and voice VLANs permitted.  When a Cisco phone boots, it queries the switch using CDP for the Voice VLAN.  If the port is a trunk, I don't think the switch will answer that particular query correctly.  I haven't actually tried it, but I think for that particular exchange to work correctly the interface needs to be Access with Voice VLAN specified (as is in your configuration).  You can probably change that behaviour with some different configuration settings on the TFTP server, as you might for a different brand of phone (non-Cisco), or if you were putting a Cisco phone on a non-Cisco switch.  You could possibly try turning CDP off on your interface and that might cause a different startup sequence.  But I am not certain, sorry.

LP

Hope this helps you a bit

[Kanan Huseynli]

Thanks for your replay.

But

1) I know that portfast has no effect in this case,I have lost connection 2 times:

 i) when changed port to trunk ( here is clear why I have lost)

 ii) when removed "switchport nonegotiate" ,why did this command force STP to re-run,I dont understand

 2) when all these happened, other users couldnt call to external,this was my second question.

May be STP re-run? Since,when port goes to Forwarding state switch sends TCN BPDU over root port toward to root-bridge.After it during 15+20 sec mac addressed will be flushed (when root bridge send config bpdu with TC flag set)

I just want to understand possible causes.What could be a reason..

Regards,

[lpassmore]

When you removed the switchport nonegotiate command, that would have forced the switch to re-initialise the interface because it has to go through the negotiation phase.  This will cause your interface to stop passing traffic until it enters the spanning-tree forwarding state.  

I am not absolutely certain why doing this change on your interface would affect other interfaces. A complete topology diagram may help.

Maybe spanning-tree had to do a complete reconvergence which may have stopped other trunk ports from passing traffic (and in particular, the link toward the external voice gateway).  Is your switch the spanning-tree root for the voice VLAN by any chance?

[Kanan Huseynli]

My PC connected switch is not root.Root is 6506 core switch which is used as aggregator.

Since,I changed user port the port roles/states should not be changed,even effected by STP,I think.

Initially,I thought TCN propagation had effect ,because whenever root gets TCN,it will send config BPDU with TC bit set.Hence,others should decrease max_age time to 15sec. But traffic flow between core sw and voice gateway always exist ,less max_age time must not have effect.

(That is the reason I confusing, surprising).

regards,