The Challenge
Operating a network can be a daunting task. Especially when you find yourself manually repeating ordinary work on a regular basis. As a network engineer you are likely to enjoy challenges with protocols and designs rather than unboxing, mounting, and installing hardware. The time spent on this everyday work should be kept at a minimum. In a streamlined network design, the configuration of new equipment should be based on a template with few variables, such as hostname and IP addressing. Many companies already practice using templates, but for the most part the engineer must still manually adjust these variables, or at best some advanced excel spreadsheet or flat text file is used with a manual search and replace to build new configurations. Next, the device is powered up, connected to with a console cable and the newly build configuration is pasted into the device before installing it in its final location. Oh, and now both software upgrade and licensing tasks must be performed to be compliant. The workflow is manual, time consuming, and worst of all error prone due to the inevitable human factor.
Introduction
Companies seek ways to eliminate manual intervention when it comes to network operations. It brings great value to a business to be able to automate as many repeating tasks as possible. At a minimum to provide a solution that minimizes time spent on these tasks while ensuring a consistent outcome – every time. This should help lower OPEX. Cisco DNA Center is a product that offers such a solution. In particular the automation of onboarding of new devices for the purpose of either bringing up a new network or expand an existing network, is addressed in the following sections.
LAN Automation
DNA Center features LAN automation which can build the underlay used for an SD-Access deployment – or if you simply want a quick way to build a routed network using ISIS. The general idea is to leverage PnP to bring up a routed network – automated by DNAC. The user need not think about or have any experience with configuring routing protocols, or how PnP works. In a few steps an entire network can be provisioned in very little time. Minutes.
Below topology is used to demonstrate how LAN automation works.
Some restrictions and limitations exist for LAN automation:
- Seed device cannot be an SVL device
- No support for stack renumbering
- No image upgrade of the devices
Whenever using PnP we must have a way to provide IP reachability for DNAC. Besides IP connectivity, the PnP device must also know how to contact DNAC for onboarding. More information about PnP can be found here
Luckily LAN automation automates this configuration for us using an IP pool of type “LAN”:
This IP pool is used by DNAC for the following functions:
- Temporary DHCP server
- ¼ of the IP pool is allocated for DHCP
- IP pool must be between /23 and /25 (inclusive)
- Linknets for P2P links
- With DNAC 2.1.2.5 these are configured as /31s
- Loopback addresses for management of the nodes and SDA fabric operation (LISP RLOC and VXLAN VTEP)
You still need to configure and add a seed device for DNAC. On this device, DNAC will configure the DHCP pool and routing. I’ve configured BGP for initial reachability between my fusion switch and the border node which will act as my seed device. BGP is needed for SDA on the border for L3 handoff anyways. Note that the IP address of the seed device will be in a different IP subnet than the LAN automation IP pool. If you want a very strict IP addressing plan with all loopbacks in a site belonging to the same subnet allocation, you must either use regular PnP, or manually change it once LAN automation is complete.
I’ve configured this on the border (seed):
router bgp 65001 bgp log-neighbor-changes neighbor 100.64.1.249 remote-as 65000 ! address-family ipv4 network 100.64.1.254 mask 255.255.255.255 redistribute connected redistribute isis level-1-2 neighbor 100.64.1.249 activate exit-address-family border#
This will ensure that when DNAC configures VLAN1 for 100.64.0.0/25 it will be redistributed (connected) and when it finishes with ISIS, this too will be redistributed. This is a must to ensure reachability during and after LAN automation.
To see what happens on my seed device during LAN automation, I’ve configured this:
event manager applet catchall event cli pattern ".*" sync no skip no action 1 syslog msg "$_cli_msg"
The EEM applet will log any command entered to the device. Here is an example:
border#sh run int lo0 Building configuration... Current configuration : 68 bytes ! interface Loopback0 ip address 100.64.1.254 255.255.255.255 end border# *Jan 30 15:28:48.690: %HA_EM-6-LOG: catchall: show running-config interface Loopback0 border#
Start LAN automation
Below are my settings for starting LAN automation:
The primary device (seed) is our pre-configured border and its downstream ports (where the edge nodes connect). The LAN pool is selected along with an ISIS domain password and a hostname prefix for our edge nodes.
Here is the log with the output of what DNAC does to the seed device upon starting LAN automation:
Highlights are:
! MTU system mtu 9100 ! Multicast ip multicast-routing ip pim ssm default ! interface Loopback0 ip pim sparse-mode ! interface Loopback60000 ip address 100.64.0.33 255.255.255.255 ip pim sparse-mode ! ip pim rp-address 100.64.0.33 ip pim register-source Loopback0 ! ISIS router isis net 49.0000.1000.6400.1254.00 domain-password zartmann metric-style wide nsf ietf log-adjacency-changes bfd all-interfaces passive-interface Loopback0 default-information originate ! interface Loopback0 ip router isis clns mtu 1400 ! interface Loopback60000 ip router isis ! DHCP ip dhcp excluded-address 100.64.0.1 ! ip dhcp pool nw_orchestration_pool network 100.64.0.0 255.255.255.224 option 43 ascii 5A1D;B2;K4;I10.181.15.10;J80; default-router 100.64.0.1 class ciscopnp address range 100.64.0.2 100.64.0.30 ! ip dhcp class ciscopnp option 60 ^ciscopnp ! VLAN1 interface Vlan1 ip address 100.64.0.1 255.255.255.224 no shutdown ip router isis clns mtu 1400 bfd interval 500 min_rx 500 multiplier 3 no ip redirects
Now the seed device is ready to onboard the edge nodes. Here are some screenshots to verify the progress:
We can see that LAN automation in fact uses PnP to onboard devices.
Once devices have been claimed and onboarded, the state of LAN automation changes to “Completed”. Now it is safe to stop LAN automation, and this is what happens to our seed device:
Highlights for the stop process:
! EEM to configure downlinks (only Gi1/0/2 shown) event manager applet _L3Applet_GigabitEthernet1/0/2 authorization bypass event timer countdown time 1 action 1.0 cli command "enable" action 1.1 cli command "config t" action 1.2 cli command "interface GigabitEthernet1/0/2" action 1.3 cli command "no switchport" action 1.4 cli command "ip address 100.64.0.38 255.255.255.254" action 1.5 cli command "ip router isis" action 1.6 cli command "isis network point-to-point" action 1.7 cli command "no shutdown" action 1.8 cli command "bfd interval 100 min_rx 100 multiplier 3" action 1.9 cli command "no ip redirects" action 2.0 cli command "dampening" action 2.1 cli command "logging event link-status" action 2.2 cli command "load-interval 30" action 2.3 cli command "description Fabric Physical Link" action 2.6 cli command "clns mtu 1400" action 2.7 cli command "exit" action 2.8 cli command "no event manager applet _L3Applet_GigabitEthernet1/0/2 authorization bypass" action 4.1 cli command "interface GigabitEthernet1/0/2" action 4.2 cli command "ip pim sparse-mode" action 4.4 cli command "do write memory" action 4.5 cli command "end" action 4.6 cli command "exit" ! VLAN1 interface Vlan1 no ip router isis no clns mtu no ip address no bfd interval ip redirects ! DHCP no ip dhcp pool nw_orchestration_pool no ip dhcp excluded-address 100.64.0.1 no ip dhcp class ciscopnp
The magic of converting VLAN1 to routed links is done using an EEM applet.
That is how LAN automation works. You might discuss the un-modifiable configuration template that DNAC uses. Especially its ISIS configuration that features legacy clear text authentication and the fact that it configures L1L2 routing. Also, no protocol tweaking is done in terms of lsp and spf optimizations that you usually do with ISIS. But, if the case is to just create a routed network in an automated way with no knowledge, LAN automation does it for you.
PnP
Compared to LAN automation, PnP gives you complete control of the configuration via the template you provide. Also, PnP has these advantages over LAN automation:
- Stack renumbering capability
- Image upgrade during PnP
On the other hand, you’ll not be able to provision a three-tier network in one go with PnP. This LAN automation supports due to its clever EEM applet that finishes the PnP process off by migrating VLAN1 to routed links.
To return to the ISIS configuration that LAN automation does. Here is the template I usually use for ISIS:
key chain isis-keys key 1 key-string zartmann ! interface Loopback0 ip address 100.127.127.1 255.255.255.255 ! router isis 1 net 49.0001.1001.2712.7001.00 is-type level-2-only authentication mode md5 authentication key-chain isis-keys metric-style wide max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 1 20 prc-interval 5 1 20 lsp-gen-interval 5 1 20 no hello padding nsf ietf bfd all-interfaces log-adjacency-changes passive-interface Loopback0 ! interface Gi1/1/1 ip address 100.126.1.1 255.255.255.254 isis network point-to-point isis metric 40 level-2 isis authentication mode md5 isis authentication key-chain isis-keys ip router isis 1
With the above configuration we have an optimal ISIS configuration in terms of lsp and sfp tuning. Also, it is more secure with MD5 type passwords for both IIHs and LSPs. My template configured the router as a L2 IS. There is no need to have both L1 and L2 adjacencies.
Offbox Automation
Rich APIs make it possible to interact with DNAC. You can script your templates and use APIs to send it to DNAC and create a planned PnP task containing necessary information such as hostname, serial number, stack renumbering, and software version required for the device along with its placement in the site hierarchy after successful onboarding. This is the way to go if bringing up new devices happens on a regular basis, or you want to be able to do bulk provisioning of new sites with many devices.
DNAC itself has a template editor which now features Jinja2. A tempate language with dynamic capabilities to bring intelligence to your configurations.
Conclusion
With DNAC it is now possible to create an automated routed network in minutes – not hours. No knowledge of how to configure routing protocols is needed. LAN automation can be used to bring up a routed network. The feature is intended for provisioning an underlay network for SD-Access, but can be used just to create a routed network. Some limitations exist with LAN automation, but it is an easy way to start an SD-Access implementation.
If custom configurations are required, or you simply do not need a routed network, but just want to be able to add devices to your network, Cisco PnP can be used. Here you have full control over the configuration and even the ability to upgrade software and renumber a stack during onboarding.
Offbox automation can be used with DNAC’s APIs which will use DNAC as an engine towards the network.
There is no longer a reason to manually configure new devices using a console cable. A method that belongs in the past. The future relies on automation which DNAC provides for us. And device onboarding is just one of its use cases.