"switchport trunk allowed vlan" Behavior

[mfarrenkopf]

Assume I have an interface with an allowed VLAN list of 100,200,300,400,500.  I want to add VLAN 600 into that.

What's the difference between executing:

switchport trunk allowed vlan 100,200,300,400,500,600

And

switchport trunk allowed vlan add 600

?

I thought the former caused a reconvergence of spanning tree on all VLANs, as if the VLANs had been removed from the list and then re-added.  In standard per-VLAN spanning tree (not rapid), I'd have expected to see the switch go through 30 seconds of listening and learning in order to get to stable state.  In lab testing, however, spanning tree did nothing.  There was no reconvergence.  VLAN 600 got added into the list and the other VLANs kept going like nothing had happened.

Is the "add" keyword strictly a convenience?  Did it used to reconverge spanning tree on all allowed VLANs if they were added back in?  Or is there an actual behavior difference between the two commands?

Thank you!

[Mark Malone · Accepted solution]

Hey if you don't use add and set just switch port trunk allowed vlan 600 it will wipe the other vlans on the interface, that is the recommended way to add it and use remove to remove it

It should not cause an stp change and if it did before you may have hit a bug , adding a vlan to an allowed list should not invoke any tcn notification to indicate a change.The vlan already exists in the databases all your telling it is its allowed move across the trunk , only if the trunk failed should a tcn be sent to indicate an actual topology change at layer 2

The first way is ok and works but it can lead to human error so the add statement was introduced to make it easier to add a vlan , I have seen trunks on some nexus devices with over a 100 manual vlans allowed,  in locked down networks its when your trying to copy all that in and add the vlan to problems occur as people tend to make mistakes and can end u[p actually forcing an stp change

[mfarrenkopf]

Hi Mark,

I marked your answer as correct because, upon doing additional lab testing, indeed it did not appear to cause an STP reconvergence.  I can't explain if I'd gotten bitten by a bug or if I was mis-remembering an event, but somehow I came to understand it did.  I ran the tests on Catalyst 3650 and 3750 gear; it seems to me I ran the test on Nexus as well, but I don't recall if that was wishful thinking or not.  Regardless, all ports remained in their existing states.  Turned on STP debugging, nothing to indicate I was missing an STP event anywhere.

I'm currently working through the CCIE R&S written syllabus, so this is just another bit to add to my notes.

Thank you,

Matt

[Ganesh Hariharan]

Hello,

Just to add with Mark's comment...

Add keyword is to make adjustment on existing configuration of allowed vlans...

Consider if you have around 50 vlans allowed on trunk , so you don't need to copy all and add new plan in the same line. To avoid that you can use add keyword to make it simplified for administrator.

STP convergence only trigger in case of failure of physical link or in case of unavailability of bpdu packets on any links between switches.

Hope it helps..

-GI

[mfarrenkopf]

Hi Ganesh,

I absolutely agree that it is tedious and error-prone to copy the entire VLAN list as opposed to just using the "add" or "remove" keyword -- in most circumstances.

If I reverse the situation -- let's say I only allowed VLANs 100 and 200, then wanted to add in VLANs 300, 400, 500, 600, and 700 -- it wouldn't be such a big deal to just straight-out replace the allowed VLAN list.  Yet in my mistaken belief, it would have caused 100 and 200 to STP reconverge.

But through additional lab testing, I found that's not the case.  I'm not clear on why I thought otherwise, but now I know for sure.

I appreciate your time in replying to my question!

Thanks,

Matt

[Jon Marshall]

My understanding was the same as yours although I have never tested it.

If you use your first command I thought that temporarily removed all the vlans off the trunk and then reapplied them whereas the second as you say simply adds the vlan(s) you want to the existing list.

Perhaps, although I am just speculating, it happens so quickly that no BPDUs go missing between the switches for each vlan so STP does not realise what has happened.

Jon

[mfarrenkopf]

Hi Jon,

We've had so many incidents in our network where we think we understand the problem -- it's a straight-up CCNA-level issue with EIGRP, or spanning tree, or . . . -- then been proven we don't have nearly the grasp on the nuances that we thought we did.  When we implemented a black-hole routing solution, we put all of our routes in EIGRP in the external network (around 27K routes).  When we were doing maintenance, people started complaining about dropping Citrix sessions.  It took much digging into, and some labbing, of EIGRP to fully understand what was going on.  We moved those black-hole routes to BGP.  Now when EIGRP converges, it's converging about 50 routes instead of 27K (more now).

The nuances and fine details of protocols really do matter.  I'm somewhat embarrassed by the number of times the behavior has been written in plain English, yet I didn't truly understand until after I researched and labbed.  I want to get my CCIE R&S, so I'd better understand the fine details.

Thanks,

Matt

[Jon Marshall]

Hi Matt

I know exactly what you mean.

I have lost count on these forums of the number of times I have begun to explain something or helped someone with troubleshooting a problem only to realise I didn't understand it as well as I thought I did and I have to go back to the documentation or create a lab for it.

And then you reread something later about the same thing and think "so that's what it means" :)

It's one of the main reasons I participate on these forums because you get a very good idea of what you do and don't know..

Good luck with CCIE when you decide to pursue it.

Jon