PNP - Endpoints Grabbing DHCP IP During PNP

[usaf_27]

I am Utilizing external DHCP server to perform PNP discovery on new Cisco gear. 
I am Utilizing Option 43 (with proper ascii) and Option 60 (ciscopnp identifier). 

Vendor replaces old switch with new switch. 
Vendor cables everything back up including uplinks.  My uplinks are connected to routed interfaces with ip helpers pointing to the DHCP servers. However, the endpoints connected on the switch grab the IP address (technically every port is in Vlan1) before the switch does.  Which prevents the switch to perform PNP. 

I could only connect the uplinks, make sure it PNP’s then proceed with the endpoint cabling. However, I want the flexibility to know for sure nothing will disrupt that PNP process in the future if I need to RMA, or rebuild the switch with all the cabling still connected.  

Has anyone ran into this problem before during the PNP process? If so, what did you do or what recommendations are there?

Thanks. 

[kristoff1]

Hi,

On your seed device you need to configure a PNP Vlan. In that case the new switch will create a new vlan and SVI to perform the PNP.

pnp startup-vlan <vlan number>

Maybe this can help you.

It is never a good idea to use vlan 1 as PNP vlan.

Kind regards,

Kristoff

[Preston Chilcote]

If the upstream device is a router, it may not support pnp startup-vlan.

It's not obvious to me why the endpoints getting an IP prevents PnP on the swtich from working?  If your DHCP pool is big enough, then the switch should get it's IP address too (and the DHCP options), right?  Am I missing something?

[Jimmy Symoens]

The way I read it, his uplinks are connected to the seed device's routed interfaces. In that way, I would assume OP is running these in /30... So the PNP VLAN probably won't work either across that routed interface.

Been there too. What I did was just shut all the interfaces except for the uplinks manually until it went through PNP. 

You could also make DHCP reservations, but that's pretty cumbersome too....

Not very plug 'n play, but I'd be happy to hear if anyone has an actual solution for this I'm obviously unaware of.

[usaf_27]

Correct.  
I am using /30 links that are essentially dual purposed.  They act as the PNP DHCP subnet and as the P2P link.

The only hiccup here is the option 60 not working. It’s most likely on my end of things not having the DHCP filters set properly.  I will explore that and test. 

As a work around, when switch boots up, only the uplinks are connected until the switch gets an IP. Then the remaining cables are connected.  Which went really smooth.  

Thanks for all the feedback. Just getting some info out there seeing what others are doing.  

[Scottishcarrot]

We're using what krisoff1 mentioned above; a specific PnP VLAN with it's own DHCP scope and option 43 response.

Once the switch is claimed in DNA Center, the rest of the cabling is connected and then templates are applied via that DHCP IP that reported into DNAC.

As part of the templates we add a loopback IP and then change the management IP in DNAC to point to that instead of the DHCP IP. There might be more efficient ways to do this, but we have about 300 branch sites that we're replacing 3750v2's and 3650's with 9300-48P's so this has worked for us so far, we're just running into an issue with the switches not attempting PnP discovery or reporting into DNAC, which is causing it's own set of headaches.

[JL421-Retired]

Yeah I've hit that before. On smaller sites where there's generally one main network anyway, I just hijack that network for PnP until the switch completes the onboard.

So from the site's fusion router I setup the transport IP for the underlay handoff, make the hijacked network a secondary address, setup the DHCP scope with a 5 minute lease time and options for the secondary network. My PnP template for the switch then shuts down all the ports except the uplink and any downlinks.

Once everything is provisioned I have a finalize template that removes the secondary IP from the fusion, removes the route advertisement from the Fusion, and no shuts all of the ports on the switch.