IPv4 address pools, LAN automation & Loopbacks & partially configured devices. Chicken-&-Egg scenarios

[andrew.butterworth]

I understand the chicken-&-egg scenario when first deploying DNA centre and starting a LAN automation - i.e. seed device needs to be manually configured and discovered and provisioned by DNA-C.  The IPv4 prefix the seed device uses for the LAN automation on VLAN 1 must be reachable from DNA-C, as well as the IPv4 address pool it uses to assign P2P's and Loopbacks for the Underlay.  However if the seed device is part of the fabric it should be configured by DNA-C and not manually.  So although DNA-C adds the IPv4 address and DHCP scope for VLAN 1 it doesn't do any configuration to the routing on the seed device - this needs to be manually configured or LAN automation fails as DNA-C can't reach the IPv4 prefixes used for the underlay.  So although I understand the logic of what's happening, if we aren't supposed to be manually configuring the fabric devices why doesn't DNA-C do this?

For devices within the fabric that aren't LAN automated from the offset, can any IPv4 addresses be used for the Loopback0's or should these be within the design pools?  For example a fabric-in-a-box Cat9300.  I think this should have some initial configuration in there as there is no seed device.  So should it have IP reachability via a manually configured loopback0 and then basic AAA  so it can be accessed remotely or partial LAN automation - i.e. DHCP with DNA-C Option 43 configured so it gets discovered by DNA-C and drops into Unassigned Devices?  Should Option 43 be configured 'generally' so that any new 'vanilla' Cisco devices get partially configured with PnP?

These are basic questions, but I want to understand the logic and where manual configuration must be done.  The documentation mentions the Fusion device frequently with regards to manual configuration, but not these 'periphery' elements.

Cheers

Andy

[Mike.Cifelli]

I am going to provide my opinion on some of the questions here, and leave you with the link to SDA Access Resources that will provide you with some really good resources.

So although I understand the logic of what's happening, if we aren't supposed to be manually configuring the fabric devices why doesn't DNA-C do this?

-IMO there are certain items that DNAC does not yet do.  However, some items may/could be road-mapped already, which is why your best bet may be to engage your reps and/or submit requests via make-a-wish inside of DNAC.  In these types of scenarios you can rely on the template editor to tweak configs during provisioning devices, or by manually adding configs prior to joining/assigning to SDA fabric.  A perfect example of something DNAC will not currently due (going off of 2.1.2.5) is allow you to configure underlay routing protocol authentication via admin UI network settings. 

Should Option 43 be configured 'generally' so that any new 'vanilla' Cisco devices get partially configured with PnP?

-AFAIK yes.  From my experiences with extended nodes this was the criteria we used pertaining to option43:

Cisco Plug n Play Notes:

Option 43 on DHCP server must be enabled:

5A1N - specifies plug and play
B2 - ipv4 type
I10.X.X.X - connect to dnac ip
J80 - port # to use

Lastly, I strongly recommend taking a peek at these resources if you have not already done so: Cisco SD-Access Resources - Cisco Community

HTH!