Catalyst Center PnP Provisioning ; Catalyst Center Does Not Respond

[zachartl]

Hello,

We're using a single Catalyst Center appliance, version 2.3.5.6 to provision for PnP. DHCP Provisioning Option 43.

Observing the console of the test switch, the pnp session appears to make contact with the Catalyst Center Appliance via TCP Port 80. We see the "Hello" at the end of the connect http://catalyst center fqdn line/80/Hello

However, we have yet to have seen the test switch show up in the Catalyst Center Plug-n-Play GUI Pane where we would normally Claim and Provision the Switch. We appear to stall at the switch connecting to TCP Port 80 of Catalyst Center.

Nothing else appears to happen. I'm writing to see if anyone has had a similar experience with PnP Provisioning.

Thank you,

Terry

[Preston Chilcote]

Can you ping the Cat Center from the switch?  Is there a firewall that could be blocking http?

[zachartl]

Hello,

Ping is good out and back. Thank you.

[zachartl]

Hello,

No firewall either.

[Dan Rowe]

If you are passing the CatC FQDN in as the DHCP option 43 value for PNP Discovery, the device will need to be able to resolve the FQDN. 

Can you verify DNS works on the network device by attempting to ping the CatC FQDN you have configured in the DHCP option 43 value?

[zachartl]

Yes Sir, that indeed works. I'm also able to telnet to the CatC FQDN on TCP Port 80 and get a session established. I'm starting to consider the Certificate. We had to utilize an External CA and Server Cert. Household name for External Certs. I've managed to install the Server Certificate and add the CA Cert to the CatC Trustpool. Cert seems okay. However, I didn't use IP addresses in the Cert SAN. And I have no Device Certificate present in the CatC.  System -> Settings -> Device Certificate. I'm a bit troubled by that. I've conducted a packet capture and can see the pnp test switch connect to the CatC on TCP Port 80. I see TCP keepalives and the session sustains for a while. I thought CatC was supposed to establish an SSL connection to the pnp test switch as part of the provisioning claim process. That's not happening. We don't seem to get past the pnp established connection on TCP port 80 of the CatC.

Thank you

[Preston Chilcote]

Did you include an entry for pnpserver.<domain> in the cert?  This is referenced in the docs:

https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/hardening_guide/b_cisco_catalyst_center_security_best_practices_guide.html#check_pnp_certificate_requirement

The reason you are seeing port 80 is so that the pnp agent on the switch can download the trustpool bundle from Cat Center.  It will then switch over to 443.

[edit] actually I see you are using option 43 so I don't think the pnpserver entry is required.  Just the "specific DNS name"

[zachartl]

Hello,

Yes, I added the pnpserver in the Cert as a SAN. Thank you for asking. I forgot to mention that. And that pnpserver FQDN was put in the DHCP Scope we're using. Thank you for the Reference too.

[DanielP211]

Hello!

What kind of pnp are you using? DHCP with option 60 and 43, dns lookup? I've tried all on DNA-2.3.5 with C9200 and they all work. Would be good to also try the USB bootstrapping method to see if you can get the switch to the pnp portal.

Also which switch + version are you using? 

BR

[maflesch]

Even if this was a cert issue, we should still see the device come into the PnP page and wait to be claimed. Then it would fail during claiming while installing the certificates. The fact that it is failing to come in suggests a network issue. Have you confirmed from the Catalyst Center side that it can communicate with the IP address that the PnP agent is sending with the HELLO request?

[zachartl]

Hello,

I believe we have found the issue. It appears we're using a tftp server for IP Phones. The tftp server IP address is configured within the DHCP Global Scope. As such, we are receiving that tftp server IP address within our DHCP addresses alongside option 43 for DNAC PnP provisioning. It appears our Lab switch, upon receiving this information, is opting to utilize the tftp server (option 150) for pnp/configuration download then failing that, utilizes the devicehelper.cisco.com addresses for pnp provisioning until that times out. And so if I manually create a pnp transport configuration within the switch pnp profile - transport http host ourhost.local source vlan x then this works immediately, I see the switch unclaimed within DNAC and I'm able to begin the claim, day 0 etc.... 

That appears to have been our issue. Although, we do see pnp provisioning "get through" by way of option 43 and not option 150 but it is rare. It doesn't appear we'll be able to manage pruning of our DHCP scope. We're working on a solution.

Thank you Everyone. Very much appreciate the assists.