Solved: Re: {PNP}Streamlining Zero-Touch - Page 3

zlantz · ‎02-06-2017

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:

6807:

pnp start-up vlan 1400

int po77

description APIC-EM-TEST

switchport

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

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.

Thanks,

Zak

zlantz · ‎02-21-2017

So is this issue specifically related to using pnp startup vlan? I would imagine that I would have seen this issue over the past year of testing without using pnp startup vlan.

Also, while this fixed the discovery issue I was having, I am now seeing a different issue with the same switch stack. It gets through the discovery process now, but, in the GUI, pnp hangs on "Getting Device Info" for the 16 minute dead timer, then fails.

Logs and trace I have didn't look particularly helpful. Just retries until HA is successful. Then hits the controller successfully and ends the trace.

Thoughts? Still on 3.7.4 and nothing other than code version has changed

aradford · ‎02-21-2017

The issue is specific to pnp-startup vlan.

With startup-vlan, the management interface that does DHCP is moved off vlan 1 onto the new vlan. The issue was related to the dhcp request from this new interface.

Can you confirm the device can ping the controller (some time after the initial contact). I am wondering if there is some vlan pruning/ STP blocking issue. I know you were using vlan 1400 for management vlan...

- can device ping controller after say 5mins from initial contact?

zlantz · ‎02-21-2017

Ok, that is interesting.

I can ping the controller from the same vlan no problem, even after it appears to stall out in the GUI on getting device info.

I did notice this in console though:

%Error opening tftp://10.255.72.116/network-confg (Timed out)

Redundant RPs - Simultaneous configs not allowed:locked from console

%Error opening tftp://10.255.72.116/network-confg (Timed out)

So the tftp issue I know about. It goes back to me setting my scope options for DNS and tftp to the controller IP, otherwise the global options would grab some sort of cisco config from an external connection. The Redundant RPs, I have seen before, but I noticed that this message would log after the initial connection to the controller and it would then grab its config from the controller no problem. Now, it is logging this message, but then continues to try and get a config from tftp. So could you elaborate what causes that message to log and how it effects my situation?

aradford · ‎02-23-2017

ok. I ignore the redundant RP message. That is normal.

I am not sure if the setting of the tftp server is interfering in some way.

what does a "show pnp trace" tell you?

zlantz · ‎02-28-2017

Sorry for the delay, been a bit busy.

pnp trace doesn't really give me much other than it successfully hits the controller and then it aborts.

Here is a copy: Dropbox - sh-pnp-trace-test.txt

aradford · ‎03-02-2017

strange. It seems to hit controller ok.

Did you reset the rule on the controller?

zlantz · ‎03-07-2017

I have reset the rule. I have deleted and remade the rule in the same project. I tried it in a different existing project and I tried in a brand new project.
lay, things finally slowed down here

Sorry for the delay, things finally slowed down here so I have some time to play with PNP again.