LAN Automation vs PnP conflict

[Sylvain_Che]

Hello,

I want to onboard a Cat9K switch into my SDA fabric using LAN Automation. But since we have configured an IP Pool under INFRA_VN to permit the onboarding of extended nodes (3560CX, ...), it looks like the Cat9K goes through the PnP process during bootup and becomes an Extended Node. Thus preventing us to onboard this switch via LAN Automation and configuring it as a Fabric Edge.

How can I prevent the Cat9K to become an Extended Node, so I can actually onboard it with LAN Automation ?

Best regards,

Sylvain.

[andy!doesnt!like!uucp]

basically for the ExNode there is different on-boarding workflow in more or less accuracy with regard to latest SW it's described here How to connect IoT Extended Nodes in SD-Access (SDA) with Cisco DNAC 1.3 - Cisco Community (onboarding starts at Create Port Channel chapter). At the end it makes device ExNode. Essencially, switch wont become ExNode unless u specifically direct DNAC to do so... 

Instead, LAN-automation creates for u routed LAN. It doesnt create SDA Fabric which components can be different (BN,CP,EN) & assigned by admin after LAN-automation is complete.
UPD. for the LAN-automation u must have separate pool for Underlay. u refers to it during LAN-automation w/f

[Torbjørn · Accepted solution]

On-boarding devices by LAN auto will work as intended if you start the LAN automation discovery before connecting/powering up the device. AFAIK there is no way to prevent the PNP from starting upon device startup in this scenario except shutting/no shutting the ports manually.

[andy!doesnt!like!uucp]

for the LAN-automation order of actions "interconnect new devices to SEEDs & power them on" or "start LAN-automation" makes few difference. Bc in the background when u submit LAN-automation DNAC will prepare SEEDs with DHCP pool for underlay & ports to be in the default state, to allow connected devices to get addressing in VLAN1 & provision switches with day0 config & to stay like this until LAN-automation is stopped. As soon as latter is stopped, DNAC instructs switches to transform their interconnects into routed links. After process is finished u obtain routed LAN (kinda IP CLOS). Then u provision your SDA Fabric.
PnP-process is building block of the LAN-automation. w/o former latter wont work. 

[Torbjørn]

Yes, that is true. LAN Automation is really PNP with a different config and some extra automation to handle IP assignment and the routed link. I interpret the issue in the OP as being unable to use LAN auto once the device discovers PNP through the regular(non LAN Auto) way. Once the device discovers PNP the regular way you will not be able to LAN Auto it without booting/resetting it, hence the order of operations will make a difference here.

I don't believe this is an issue of Extended node workflow vs LAN auto workflow as bringing them up as extended nodes would require deliberate action from @Sylvain_Che, unlike running into "regular PNP" vs LAN auto.

[Sylvain_Che]

Yes PnP is also used in LAN Auto. I know how both LAN Auto. and PnP for Extended nodes are supposed to work.

Actually my client said that the Port-Channel creation was automatic that's why he faced the issue. I need to do further tests. I'll keep you posted.

At least, what I can say for now is that starting LAN Auto. before booting up the switch looks OK.

Again, I'll do further tests about onboarding PnP/extended nodes and the Port-channel creation and I'll keep posted.

So far, already thanks for your inputs.

[andy!doesnt!like!uucp]

"Port-Channel creation was automatic" is not correct unless it's initiated manually from DNAC. if u have your devices getting into PnP section before u start LAN automation & unable to fall under LAN-automation after latter is started, yeah, restart the devices (assuming they are still in factory defaults) & they will be poke up by LAN-automation. Otherwise reset them to f/d just after LAN-automation is started. i have a feeling that some of your settings interferes with LAN-automation enforcing newly attached switches to get into PnP section instead of w8ing for LAN-automation to start. Nevertheless , u still can claim device from PnP & assign it proper SDA site role.
But again, for the switch to become ExNode in Fabric Site this must be explicitly instructed from DNAC. 

[willwetherman · Accepted solution]

Hi @Sylvain_Che 

If the new switch is being onboared automatically as an Extended Node, I'm assuming that you are connecting it directly to another Fabric Edge switch? If so, and if you are using 'None' as the global authentication template for your fabric, a PAgP port-channel will be created automatically on the upsteam Fabric Edge switch (using Autoconf) which will explain the behavior that you are seeing. This is explained in various Extended Node configuration guides such as the following:

https://community.cisco.com/t5/networking-knowledge-base/policy-extended-node-configuration-guide/ta-p/4023978

https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/EE/IG-fabric/ext-ent-fabric-ig/ext-ent-fabric-ig.html

You should also notice that command 'pnp startup-vlan <extended-node VLAN>' has been added to the configuration of the upsteam Fabric Edge switch (which is created when you add the Extended Node IP pool to the INFRA_VN). This will instruct the new switch to use the extended node VLAN for PnP automation.

To prevent this from happening, you will need to ensure that you start a LAN automation session on the upsteam Fabric Edge before physically connecting the new switch. Can you try this and post back? Use command 'pnpa service reset' on the new switch to cleanly reset it before attempting LAN automation again.

Edit: I just tested this with a new C9200CX switch and the above behavior is the same. Without LAN automation running, as soon as the C9200CX is connected to the Fabric Edge switch, it is provisioned using PnP with a PAgP port-channel created on the Fabric Edge switch automatically as a part of the workflow.

Hope that this helps

Will

[andy!doesnt!like!uucp]

Hi Will
thanks for update. i had no chances to test it. could u pls more details on your actions sequence? what was upstream FE's port config? as of now i understand it as follows:
1) u had port config w/ authen template None which basically reflects to config similar to below
interface TenGigabitEthernet1/0/38
switchport mode access
device-tracking attach-policy IPDT_POLICY
spanning-tree portfast
end
2) u connect factory-defaulted C9200CX to the port & it gets transformed into something like this (whilst C9200CX becomes extended node)?
interface TenGigabitEthernet1/0/38
switchport mode trunk
device-tracking attach-policy IPDT_POLICY
channel-group X mode desirable
end
interface PortchannelX
switchport mode trunk
end
also what is the code of FE SW & your DNAC?
thank u in advance

[willwetherman · Accepted solution]

Hi @andy!doesnt!like!uucp 

The upstream/parent FE is a C9300X running IOS-XE version 17.9.4. DNAC is running version 2.3.5.4

This is the default port config on the FE when the global authentication template is set to none.

interface TenGigabitEthernet1/0/1
 device-tracking attach-policy IPDT_POLICY

Upon connecting the C9200CX to the FE, the C9200CX learns of the Extended Node VLAN ID (as a result of command 'pnp startup-vlan 2052' that was already provisioned on the FE). At this point the C9200CX contacts DNAC and starts the PnP process. Note that the port-channel is not provisioned on the FE at this stage.

Once PnP completes, the C9200CX is added to the DNAC inventory, associated to the same fabric site as the FE and provisioned as an Extended Node. It is during this final process that DNAC provisions a PAgP port-channel on the FE connecting to the Extended Node.

This is the config that DNAC applies to the FE at the end of the process. I made no changes in DNAC. This process was completely zero touch.

interface Port-channel1
 switchport mode trunk
end
!
interface TenGigabitEthernet1/0/1
 switchport mode trunk
 cts manual
  policy static sgt 8000 trusted
channel-group 1 mode desirable
end

Edit: I was incorrect in my original reply as the port-channel on the FE is not applied automatically by Autoconf upon connecting the C9200CX. Instead, Autoconf applies built-in template 'SWITCH_INTERFACE_TEMPLATE' to the port to enable it as a trunk (see below). It is DNAC that configures the port-channel on the FE at the end of the Extended Node provisioning process.

show template binding target ten1/0/1

Interface Templates
===================
Interface: Te1/0/1

Method Source Template-Name
------ ------ -------------
dynamic Modified Built-in SWITCH_INTERFACE_TEMPLATE

show derived-config interface ten1/0/1
Derived configuration : 107 bytes
!
interface TenGigabitEthernet1/0/1
switchport mode trunk
device-tracking attach-policy IPDT_POLICY