I was tasked with implementing DNA Center into our infrastructure, from the ground up. Let's embark on this journey and see how it plays out.
Completed thus far:
- discovery phase
- hardware/licensing ordered (in hand)
- UCS (3 Servers, 6 Host)
- CIMC Installed
- DNA Center installed on UCS
- Fully built lab that replicates our prod environment
- Templates built for various switches
- golden images loaded based on switch model
- Global hierarchy built out (partially, more on that later)
- Provisioned a switch remotely, locally, and in the lab)
Before I get into my experience with DNA-C Appliance, I want to pre-warn ANYONE that is looking into rolling this out.
- Do NOT under any circumstance, forget:
- CIMC Password
- Maglev Password
- DNA-C Admin Password
Standing DNA up has been frustrating to say the least. I had to build routes from the core to the pizza box. I had to build routes to the lab that only traversed the internet VLAN and nothing else (because of how or environment is set up, if I staged a live switch, it would break one of our sites due to IP conflicts).
Frustration 1:
RADIUS
If you plan on implementing RADIUS to access DNA-C so you do not have to create/use local accounts -think again. This is not possible without ISE (very clever Cisco). I spent countless hours troubleshooting why RADIUS wouldn't work. I followed their documentation to a T (funny, they have documentation for something that doesn't work). I spent hours on the phone, Webex, and email with TAC -to no resolve.
I created a new friendly name on the RADIUS server, used the existing Cisco shared secret that we use with other Cisco gear. I tried creating it from the ground up (to ensure there wasn't a key mismatch)
TAC Resolution (from the guy that created the documentation for RADIUS/DNA) "Implement ISE, RADIUS to the DNAC simply doesn't work" -fantastic!!
Advice: Implement ISE alongside DNA or be prepared to make user accounts and privileges (your own little AD)
Frustration 2:
Templates
Get ready to configure the hell out of some switches. I know with automation comes a lot of manual behind the scenes shit to get it up and running, but my word. Cisco, no baseline templates? You have to build from scratch. Beings we are in the middle of a network refresh, the sentiment of having to configure a switch once (template building), granted the config is correct (DNA yells a lot), I guess it's ok. Once you iron the kinks out and the template is bullet proof, you can go ahead and lock in your Day0 template. After your Day0 is tried and tested, its time to build your DayN template (this is where you will adopt and claim a switch into a site within DNAC), pretty much prod ready.
Templates ARE fickle. The way DNA interprets them is a mystery. I have taken a switch config from one that I was replacing, threw its config into a DNA template, and it error'ed out every single time.
Advice: use variables properly. I found strings worked better on L2 switches (for mgmt interfaces) and integers worked better on L3 switches (for mgmt interfaces and plan interfaces).
Frustration 3:
Global Settings
The hierarchy is downright despicable. It is a mess to say the least. Clunky and certainly not intuitive. The interface was not planned out well, I am not sure what design language they were going for, but I am not a fan. For instance "Provision" contextual menu at the top, houses sub-options, that you wouldn't know, because its not clear. This so happens to be where DNA's bread and butter live "Plug and Play" or "UPnP" to kick of provisioning.
Menu Navigation goes something like this:
- Design
- Network Hierarchy
- Network Settings
- Network
- Device Credentials
- IP Address Pools
- SP Profiles --> QoS
- Wireless
- Image Repository
- Network Profiles
- Authentication Template
- Policy
- Dashboard
- Group-Based Access Control
- Group-Based Access Control Policies
- Scalable Groups
- Access Contract
- IP Based Access Control
- IP Based Access Control Policies
- IP Network Groups
- Access Contract
- Application
- Application Policies
- Applications
- Application Sets
- Queuing Profiles
- Traffic Copy
- Traffic Copy Policies
- Traffic Copy Destination
- Traffic Copy Contract
- Virtual Network
- Provision
- Devices
- Inventory
- Plug and Play
- Fabric
- Services
- Devices
- Assurance
- Health
- Overall
- Network
- Client
- Application
- Dashboards
- Sensor
- Dashboard Library
- Issues
- Global Issues
- All Issues
- Manage
- Sensor-Driven Tests
- Client Intelligent Capture
- AP Intelligent Capture
- Issue Settings
- Platform
- Overview
- Manage --> Bundles --> Configurations
- Developer Toolkit --> APIs --> Integrations Flows --> Data and Reports --> Multivendor Support
- Runtime Dashboard
- Health
As you can see, this is very convoluted. I am used to it now, but you can see why it can be unwelcoming when just beginning.
Frustration 4:
Provisioning
This is what DNA was built for, automating switch configurations by the way of templates. Well, I can tell you, when it works, its amazing -WHEN IT WORKS.
I have had more error then provisioned messages. You claim the switch, select the iOS image you want (upgrade to golden image if you so choose), set the parameters you defined in the templates, set and claim the device to the site in which this will be deployed. Sit back, cross your fingers, and prepare to be pissed.
There is a bug with chrome, while filling out your parameters, you can not scroll down far enough to see "DHCP or default gateway properties".
- Temp work arounds: F11 (sometimes works). Enter the value in notepad, copy it, go to the line above, click then tab and paste. Janky, but works.
Advice: do not interrupt DNA when it is provisioning. you will end up with a blank switch (no image) in ROMMON. If you find yourself in this predicament, console into the switch "wr erase" "wr mem" "sh boot" make sure it is NOT the .bin file, make sure this is pointed to "BOOT variable = flash:packages.conf" if you don't, you will disable UPnP and DNA will not be able to do its job.
I understand that every network is different. Every template will vary. Every use case will vary. This is just MY experience thus far. I do NOT hate DNA (contrary to what I have written). It is a newer product with a lot of bugs. It has a great use case and demographic. I am just giving you my POV (the engineer in the trenches). Others that use DNA, once it is already set up, will think it is the greatest thing since sliced bread -I will probably join them in that consensus. For now, while standing it up, I still think it needs work.
Right now I am fighting a 9200 L2. Let me know if you want to hear about the fun I am having with this....
I hope this didn't deter anyone. I just needed to rant more then anything, and maybe I will run across someone that can give me pointers and help my deployment go a lot smoother then it has been. If you made it this far -CONGRATS!
TL;DR
Cisco DNA is great when it works. It still has a lot of shortcomings and obstacles to overcome. Be prepared to exert a lot of time and energy implementing this into your environments.
-NetworkGnome
No comments:
Post a Comment