Automation of C9200L using non default VN

[L.Nikulski]

Hi,

I have been trying to get a stack of two C9200L switches integrated into a fabric where we are using a non default VN for the fabric.
Currently three VNs are shown when checking the fabric,DEFAULT_VN, INFRA_VN and our custom VN. Only our VN is configured for host pools. C9300L switches are able to be automated and provisioned without a problem but the C9200L is not being claimed with the LAN Automation. Since the C9200L only supports 1 VN do I have to only use the DEFAULT_VN because I can't delete it or should the C9200L be able to join the fabric since only one VN is in use? 

Log from the C9200L while LAN Automation is running:

Jun 25 10:34:14.051: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down

Jun 25 10:34:16.067: %LINK-3-UPDOWN: Interface Vlan1, changed state to up

Jun 25 10:34:17.068: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up

Jun 25 10:34:19.078: %PNPA-DHCP Op-43 Msg: Op43 has 5A. It is for PnP

Jun 25 10:34:19.078: %PNPA-DHCP Op-43 Msg: After stripping extra characters in front of 5A, if any: 5A1D;B2;K4;****;J80; op43_len: 29

Jun 25 10:34:19.078: %PNPA-DHCP Op-43 Msg: _pdoon.2.ina=[Vlan1]

Jun 25 10:34:19.078: %PNPA-DHCP Op-43 Msg: _papdo.2.eRr.ena

Jun 25 10:34:19.078: %PNPA-DHCP Op-43 Msg: _pdoon.2.eRr.pdo=-1

Best Regards

[willwetherman]

Hi,

The 9200L only supports a single VN as you correctly say. This can either be the DEFAULT_VN (which is a User VN that is provided by default) or a user-Defined VN such as CORP_VN but not both. As far as I'm aware, although the DEFAULT_VN is created in DNAC by default, it wont count towards the limitation of one VN until its added to the fabric site along with an IP pool so you shouldn't have any issues. The INFRA_VN also doesn't count towards the limitation 

Also the VN limitation shouldn't impact LAN automation as LAN automation is simply used to provision the underlay on the discovered 9200L and add it to the inventory. LAN automation doesn't add the 9200L to the fabric (as a fabric edge) which is when the VN limitation will become apparent as DNAC will restrict the entire fabric site to the VN limit of the lowest capability switch.

The debugs look very sparse to me so something else must be causing LAN automation to fail.

What version of DNA Center are you running?

What model of C9200L are using using?

Are the 9200Ls using the network/DNA advantage license?

Edit

Regarding the last paragraph, i'm not entirely sure if simply adding the 9200L to the inventory and site that is associated to the fabric is enough to force the entire fabric site to use a single VN, or if this only happens once the 9200L is added as a fabric edge. Hopefully someone else can comment on this.

[L.Nikulski]

Hi and thank you for your input,

License is in eval mode, but available for NW and DNA.

I am currently on Version 1.3.1.6 but I am also in the middle of the upgrade to 1.3.3.5 which is also not working but thats another topic. I also had this issue in 1.3.1.4.

License Usage

==============



(C9200L-NW-A-48):

  Description:

  Count: 2

  Version: 1.0

  Status: EVAL MODE

  Export status: NOT RESTRICTED



(C9200L-DNA-A-48):

  Description:

  Count: 2

  Version: 1.0

  Status: EVAL MODE

  Export status: NOT RESTRICTED

I was able to get a live log of the automation on the CLI, I didn't press any buttons and just recorded the process.

After PnP Discovery the Switch tries to open network-confg over tftp, fails and then just stays there without anything happening, LAN Automation doesn't detect the switch and stays in "initialising".
I am not entirely sure but isn't TFTP Config the old way of doing PnP like in Cisco Prime Infrastructure or APIC-EM? This is the only recording of a LAN I have so I can't compare it to a successfull one.

*Jul 7 13:04:38.726: %PKI-4-NOCONFIGAUTOSAVE: Configuration was modified. Issue "write memory" to save new IOS PKI configuration
*Jul 7 13:04:38.761: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty0
*Jul 7 13:04:39.167: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named TP-self-signed-2990682944.server has been generated or imported by crypto-engine
*Jul 7 13:04:42.799: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty0
*Jul 7 13:04:42.831: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty0
*Jul 7 13:04:43.839: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty0
*Jul 7 13:04:44.837: %PNP-6-PNP_SAVING_TECH_SUMMARY: Saving PnP tech summary (pnp-tech-discovery-summary)... Please wait. Do not interrupt.
*Jul 7 13:04:34.011: %SYS-6-CLOCKUPDATE: System clock has been updated from 13:04:48 UTC Tue Jul 7 2020 to 13:04:34 UTC Tue Jul 7 2020, configured from console by vty0.
Jul 7 13:04:34.011: %PKI-6-AUTHORITATIVE_CLOCK: The system clock has been set.
Jul 7 13:04:34.021: %SYS-5-CONFIG_P: Configured programmatically by process XEP_pnp-zero-touch from console as vty0
Jul 7 13:04:34.065: %SMART_LIC-5-SYSTEM_CLOCK_CHANGED: Smart Agent for Licensing System clock has been changed
Jul 7 13:04:35.345: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty0
Jul 7 13:04:36.368: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty0
Jul 7 13:04:37.170: %PKI-4-NOCONFIGAUTOSAVE: Configuration was modified. Issue "write memory" to save new IOS PKI configurationRedundant RPs - 
Jul 7 13:04:37.465: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty0
Jul 7 13:04:39.572: %SYS-5-CONFIG_P: Configured programmatically by process PnP reconnect profile from console as vty0
Jul 7 13:04:39.908: %SYS-5-CONFIG_P: Configured programmatically by process XEP_pnp-zero-touch from console as vty0
Jul 7 13:04:45.278: %SYS-5-CONFIG_P: Configured programmatically by process PnP Agent Discovery from console as vty1
Jul 7 13:04:46.278: %PNP-6-PNP_TECH_SUMMARY_SAVED_OK: PnP tech summary (pnp-tech-discovery-summary) saved successfully.
Jul 7 13:04:46.279: %PNP-6-PNP_DISCOVERY_DONE: PnP Discovery done successfully (PnP-DHCP-IPv4)
%Error opening tftp://255.255.255.255/network-confg (Timed out)
Jul 7 13:04:56.717: AUTOINSTALL: Tftp script execution not successful for Vl1.

Best Regards

[willwetherman · Accepted solution]

I have seen the TFTP network-config broadcast in the logs before during LAN automation so I would say that this is normal (although i'm not sure what triggers it but it hasn't impacted the LAN automation process for me).

DNAC version 1.3.1.6 is ok as that versions supports all models of the C9200L. License on the C9200L also looks ok as you need to be running advantage for the automation of IS-IS.

A few things to try

1) Can you check if the C9200L is listed under DNAC Provision -> Devices -> Plug and Play? Delete if it is listed

2) Erase the C9200L back to factory default using the script below

3) When LAN automation is running, check the DHCP binding for the C9200L on the LAN auto seed device and then make sure that you can ping this IP from DNAC to ensure that there are no connectivity issues 

When LAN automation is running, and the switch has booted and discovered DNAC using PNP, you will actually see the C9200L under the list of plug and play devices first before you see anything in LAN automation status. The PnP status of the C9200L will initially appear as unclaimed and then it will change to planned before it appears as ‘In Progress’ under LAN automation. It will then move to onboarding and then provisioned once complete

enable
erase startup-config
y
!
delete /force vlan.dat
delete /force nvram:*.cer
delete /force flash:pnp*
delete /force nvram:pnp*
!
conf t
!
crypto key zeroize
yes
no crypto pki cert pool
yes
no crypto pki certificate pool
yes
no crypto pki trustpoint pnplabel
yes
no pnp profile pnp-zero-touch
yes
!
end
!
write erase
y
!
reload
no

Let us know how you get on

[willwetherman]

Hi,

I have quickly run through the LAN automation process for a Lab C9300 so that you can see the logs for comparison.

You can see that the logs are exactly the same up until 15:25:42  (including the TFTP config broadcast).

When PnP reaches this stage, the C9300 first appears in DNAC -> Provision -> Devices -> Plug & Plug. As per my previous post, the C9300 PnP status initially displays as unclaimed before moving to planned (at which point it displays as in progress in LAN auto status) and then to onboarding. Onboarding happened at 15:28:34 and provisioning completed at 15:33:14

Its also worth checking DNAC -> Provision -> Devices -> Plug & Plug -> C9200L -> History for any errors that may occur as soon as PnP starts.

Hope that this helps.

[L.Nikulski]

Its also worth checking DNAC -> Provision -> Devices -> Plug & Plug -> C9200L -> History for any errors that may occur as soon as PnP starts.

This helped me so much. The stack was visible under Plug&Play Devices. After I deleted the entry I was able to lan automate the device successfully. 

This was showing for the history:

History
Status	Time	Details	Info
			
	07/07/2020 03:04:52 PM	Device Authenticated Successfully	Info
	07/07/2020 03:04:46 PM	Secured Device	Info
	07/07/2020 03:04:23 PM	NCOB02073: Unexpected reload detected	Info
	07/07/2020 03:04:20 PM	Securing Device	Info
	06/24/2020 02:12:57 PM	Device Authenticated Successfully	Info
	06/24/2020 02:12:51 PM	Secured Device	Info
	06/24/2020 12:34:25 PM	NCOB02073: Unexpected reload detected	Info
	06/24/2020 12:34:25 PM	Securing Device	Info

And this for the device details:

Device represents a Stack  - Check the Stack Tab for member details
State Error
Onboarding State Initialization Error
Device Name Switch
Serial Number **********
Product ID C9200L-48T-4X
Source Network
Created 06/09/2020 02:13:42 PM
Last Updated 07/07/2020 03:55:18 PM
First Contact 06/09/2020 02:13:42 PM
Last Contact 07/07/2020 03:55:18 PM
Image Name flash:cat9k_lite_iosxe.16.09.02.SPA.bin
Image Version 16.9.2

The stack master was showing as ready but the stack member as initializing. I think the stack might also not have been fully formed when I first tried to do the lan automation. Also the image version 16.9.2 was the one the switch had when I first tried to lan automate the stack, after that I upgraded to 16.12.2t but that apperently didn't get updated in the PnP entry, I guess the entry was stale after all.

Thanks for the help!

Best Regards