Showing results for 
Search instead for 
Did you mean: 

{PNP}Streamlining Zero-Touch


Currently, we are using the dhcp method for pnp discovery. This has been working well, however, our current deployments depend on having 2 uplinks to our upstream switch. On the uplink switch, we use the first link as a trunk and pass specific vlans through, while the second link we have been using as an access port into our pnp specific vlan, 1400. This works no problem, but we need to remember to go back to our upstream switch and change that access port to match the 1st link and add it to the existing port-channel for redundancy. I would like to eliminate this final step and truly make this zero-touch after install. I found the PNP stacking blog posts by Adam helpful. This one in particular sparked my interest: Network Automation with Plug and Play (PnP) – Part 6.

Using a 6807 as my upstream switch and 2 3650s as by deployment, I used the following config and was unable to get this deployment to discover:


pnp start-up vlan 1400

int po77

description APIC-EM-TEST


switchport mode trunk

switchport trunk allowed vlan 1,1000,1400

no port-channel standalone-disable

int gi 2/46-47

description TEST-APIC-EM


switchport mode trunk

switchport trunk allowed vlan 1,1000,1400

udld port

channel-group 77 mode active

Based on the article linked above, cdp should create vlan 1400 on the deployment and have it pull from DHCP. Then it would assign all active interfaces on the stack to 1400, in this case, 1/1/1 and 2/1/1. Unfortunately, 1400 is never created on the 3650s and discovery never happens. The main 1400 vlan lives on the 6807 and has a helper that points at an MS DHCP. Option 43 lives there and has been working with our current deployment standard. Just looking to see if I misunderstood something or misconfigured something.



1 Accepted Solution

Accepted Solutions

There is an issue in 3.7.3 and below that makes DHCP problematic with NV1.

Release Notes for Cisco Network Plug and Play, Release 1.3x - Cisco

Screen Shot 2017-02-18 at 8.01.19 am.png

Just to confirm this, can you upgrade this switch to 3.7.4 and see if that resolves the issue?


View solution in original post

36 Replies 36

Cisco Employee
Cisco Employee

Hi Zak,

what version of software are you running on 6k?  There are some issues with pnp-startup vlan on earlier versions of code.

Can you do a "show cdp tlv app" on the 6k, you should see the vlan being advertised.


Currently running 152-1.SY1a on this 6k

And it appears that it is not advertising 1400 to the deployment stack:

APP TLV (Neighbor: Switch), Received tlv type: 4100,value: 006b.f1df.a400

APP TLV (Neighbor: Switch), Received tlv type: 4099,value: 1

APP TLV (Neighbor: Switch), Received tlv type: 4100,value: 006b.f1df.a400

APP TLV (Neighbor: Switch), Received tlv type: 4099,value: 1

- 15.4(1)SY is a good version for PnP startup vlan.


Sent from my iPhone

Btw, sometime a "no PnP startup-vlan" followed by a reapplication of the command will help on the older code.

You could try that first before upgrading.


That did not work, but I will upgrade our test 6K and test on the new code.

please let us know how the 15.4(1)SY code goes.

By chance, I believe I got this semi working on accident during another deployment of another switch model. I was deploying a 3560CX and it never fully contacted the controller but when I consoled into, the logs had the following:

%SW_VLAN-4-VLAN_CREATE_FAIL: Failed to create VLANs 1400: extended VLAN(s) not allowed in current VTP mode

Feb  9 14:34:41.351: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1400, changed state to down

Feb  9 14:34:41.369: %PM-2-VLAN_ADD: Failed to add VLAN 1400 - VTP error.

Vlan 1400 is our PNP deployment vlan. So I'm not sure if it is something specific to this switch as this is the first one of this model we received or if it was because I reapplied the startup vlan and now it is "working". Either way, based on the logs, it looks like using this could be a problem. What do you think?

3560CX was on 15.2(4)E
Upstream 6K has not been upgraded yet

Hi Zak,

this is interesting.

#1) pnp startup-vlan was not working earlier as the "show cdp tlv app" command showed that it was not sending the  vlan information.  The good news is that CDP is sending the correct vlan now.

#2) On a 3650, this is not a problem as it supports extended vlan.  I set my startup-vlan to 1400, and saw the vlan being created on a 3650.  However, as the compacts run classic IOS, I can see how 1400 would be a problem for them.

In short, you have good news on the 6k sending CDP startup vlan.  It should be working on the 3650, but i can see why not on the 3560-cx (due to their architecture)


This makes sense. I'm going to do some further testing and then see if I still need to upgrade the code on the 6K if it flakes out on me again. I'll probably end up testing the 3560CX with another vlan id to make sure it works with that as well. I found it interesting that PNP will prefer pnp startup vlan method over doing standard DHCP deployment. Because when I was trying to deploy this, I was trying to use my standard option 43 method, but pnp start-up vlan took priority.

They work together.

Startup vlan creates the vlan on the switch and then has dhcp configured on it. It also configures any active links in this vlan.

Once this happens either dhcp or DNS can be used for PnP.


Sent from my iPhone

I get what you are saying, but I was previously just making the upstream switch an access port into 1400 so that the deployment switch would hit dhcp and get option 43. The 1400 vlan was never created on the deployment switch. So if I wanted to use pnp startup vlan and two trunks for my 3650/3850s, I would not be able to use the same upstream switch, that is still configured for pnp startup vlan, to deploy my 3560CX because pnp startup vlan would try and start pnp before the switch gets dhcp from upstream. This would fail to create my 1400 L2, on the deployment switch, because my pnp vlan is an extended vlan ID. Is there anyway to specify particular models to use pnp startup vlan vs straight dhcp as I have done in the past?  I am still going to test with pnp startup >1000 to make sure that its really working on the 6K, but I wanted other options to keep in my mind.

Hi Zak,

currently the "pnp startup-vlan" command is global on the upstream switch.  We were trying to keep things simple by doing this.

I can see the challenge of a management-vlan > 1003.

A lot of people choose management/native vlan <1000 to make sure there are no issues with switches that do no support extended vlan ranges.  This should be less of an issue now, but as you can see, some of the smaller devices still have restrictions.

One of the challenges with automation is that sometimes it requires a re-engineering of a process to ensure it can be better automated.

My concern with adding in different startup-vlan is that is going to create complexity as different models would have a different management vlan.  Would it be simpler to standardise on a management vlan that works on all devices?


That makes sense and we are tossing around the idea of moving our deployment vlan to 44. Just need to make sure we aren't using that vlan id anywhere else.

I was able to get pnp startup vlan 44 working with the 3560cx, and I was also able to get my 3650s working with pnp start up 1400, and 44. I feel like doing the deployment like this is much faster, but I can't put my finger on why it seems that way.
I did notice that pnp startup does not clean up after itself. So vlan 44/1400 and SVI 44/1400 still remain in the final deployment. Is there another way to clean these up after deployment other than an EMM?

Also, I found that when I was moving interfaces on my 6k to the deployment devices that I would have to reapply the pnp startup vlan because it was not advertising on those specific interfaces, presumably because they were just plugged in and configured. Is that a bug or just something weird with the code I'm still running?

I am still going to upgrade my test 6k next week to the version you suggested just to see if pnp startup reacts differently.

Thanks for all the help by the way.

Hi Zak,

Thanks for all the feedback and your patience.

startup vlan is not supposed to clean up.  It is meant to leave the vlan in place, so you can manage the device via that vlan (often referred to as the 'management vlan').  It is possible to remove it,  but what IP address/VLAN would you use to manage the device?

The issue you are seeing with needing to reapply is an issue that is resolved in the later version of code.  Reapplying the command is a workaround.


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers