Seed Device

The seed device is a predeployed system in the network and is the initial point through which Cisco LAN automation discovers and onboards new switches downstream. The seed device can be automated through technologies such as Cisco Plug n Play (PnP) and zero-touch provisioning, or configured manually. The following figure shows the seed device network boundaries between the Cisco DNA Center connection in the IP core and the to-be-discovered underlay network using LAN automation.

The peer seed (Seed-2 in the following figure) can also be automated via LAN automation. Only one seed device is required.

PnP Agent

The PnP agent is a Cisco Catalyst switch with factory-default settings. The switch leverages the built-in day-0 mechanism to communicate with Cisco DNA Center and support the integrated PnP server function. Cisco DNA Center dynamically builds the PnP profile and configuration sets that enable complete day-0 automation. The following figure shows the PnP agent physical connection to the seed device.

Automation Boundary

In general, we recommend building structured and hierarchical network designs in enterprise networks to provide scalability and redundancy at every network tier. While the three-tier architecture is proven in large-scale enterprise campus networks, the network design varies based on the overall network size, physical connections, and so on. As part of the initial planning, the network admin must determine the physical topology to automate with Cisco LAN automation.

LAN automation in Cisco DNA Center supports a maximum of two hops from the initial automation boundary point device. In other words, to build the underlay network up to the access layer, the network admin must start the automation boundary from the core or distribution layer. Any additional network devices beyond two hops might be discovered but cannot be automated.

LAN automation initiates only on directly connected neighbors. Consider two scenarios:

• Scenario 1: You have a three-tier network and you want to LAN automate distribution- and access-layer switches. Because distribution-layer switches (which are directly connected to the seed) participate in LAN automation, both distribution- and access-layer switches will be discovered and LAN automated.

• Scenario 2: You have a three-tier network and you want to LAN automate distribution- and access-layer switches. You already LAN automated the distribution layer. Later, you add access-layer switches to your network and you want to LAN automate these switches. Because the distribution switches are already LAN automated and links converted to Layer 3, Tier 1 switches cannot be used as the seed. You must choose distribution as the seed in this scenario.

The following figure shows the automation boundary that Cisco LAN automation supports.

The following figure shows a two-tier and three-tier network design.

The following figure shows supported device families for the seed and PnP agent at different layers.

Cisco LAN Automation Product Support Matrix

Use the Cisco DNA Center Design application to create the required sites, buildings, and floors. Consider how the primary seed and peer seed will be connected to the new devices—for example, will they all belong to the same site or follow a hierarchy? Consider also how to share IP pools across different sites, buildings, and floors. One option is to have a pool specific to a site. Another option is to share a common LAN pool for all sites in the hierarchy. If the devices are onboarded across multiple LAN automation sessions, ensure that the required IP pools are available across the various sites in the hierarchy.

Note the following constraints:

• In Release 1.1.x, LAN automation lets you choose only one site for the seed, peer seed, and PnP devices, meaning all devices must belong to a single site.

• After devices are provisioned, the site cannot be changed. For this reason, we recommend that you complete LAN automation before you provision devices.

IP pools for LAN automation are created by first creating a global pool in Cisco DNA Center, followed by a site-specific LAN IP pool, which LAN automation allocates internally, as follows:

1. One part of the IP pool is reserved for a temporary DHCP server. The size of this pool depends on the size of the parent LAN pool. For example, if the parent pool is 192.168.10.0/24, a subpool of size /26 is allocated for the DHCP server. If the pool size is larger than /24, the algorithm keeps increasing the size of the DHCP pool, up to a maximum of a /23 subpool (512 IP addresses). Therefore, a /24 pool reserves 64; a /23 pool reserves 128; a /22 pool reserves 256; and anything larger reserves 512 IP addresses for the DHCP server. The minimum pool size to start LAN automation is /25; that reserves /27 or 32 IP addresses for the DHCP pool. This IP pool is reserved temporarily for the duration of the LAN automation discovery session. After the LAN automation discovery session completes, the DHCP pool is released and the IPs are returned to the LAN pool. Because the DHCP pool is usually the largest contiguous segment of IPs required, the pool should have at least one such segment available. If the pool is too fragmented, it cannot allocate the DHCP pool and the LAN automation session ends with an IP pool allocation error.

2. The second part of the IP pool is used for link configuration between connected devices that participate in the discovery session. Participating devices are primary seed, peer seed, and discovered devices in the discovery session. All links between these devices are configured with Layer 3 as required for IS-IS routing. The only exceptions are the links connected to the primary seed device that are not selected while starting discovery. These links could be links between seed devices or links between seed and discovered devices. For each configured link, a /30 subpool (4 IP addresses) is allocated. For example, in a topology that contains four links, LAN automation allocates 16 IP addresses for the Layer 3 link configuration.

3. The third part of the IP pool is used to allocate a single loopback IP per discovered device. If the seed device or peer seed devices do not have loopback IPs configured, they are also configured with the loopback IPs. Internally, the IPAM library allocates a /27 pool for single IPs. For example, when the LAN pool requests the first loopback IP for a device, the IPAM library allocates a /27 pool (32 IP addresses) and returns one IP from this pool. On subsequent requests, the library continues to give IPs from the previously allocated /27 pool until it runs out of IPs. So for a /27 IP, the same internal pool is used for the 30 IP allocation. Currently, only 30 of the 32 IPs in the internal pool can be used for loopbacks. If the internal pool cannot be used for IP allocation, another /27 pool is allocated for additional single IP allocation. In this case, loopback allocation for discovered device number 31 results in a new /27 subpool allocation.

IP Pool Usage Example

Imagine you want to LAN automate 10 devices using the same pool, where each device has one link to the primary seed and another link to the secondary.

Consider a 192.168.199.0/24 pool. When LAN automation starts, a /26 pool is reserved for the DHCP addresses. In this example, 192.168.199.1 to 192.168.199.63 are reserved and assigned to VLAN 1 for the 10 devices.

Next, a /30 pool is reserved for the point-to-point links, and a /27 pool is reserved for loopback addresses. Because there are 10 devices with two links each, a total of 2*10*4 = 80 IP addresses are reserved for point-to-point links and 10 loopback addresses are reserved.

In total, 100 IP addresses are reserved for the 10 devices: 10 for each VLAN 1, 10 for each loopback, and 80 for the point-to-point links between devices and seeds.

After LAN automation stops, the VLAN 1 IP addresses are released back to the pool, and 90 addresses are allocated for the LAN automation session.

Note the following:

• The same IP pool can be used for multiple discovery sessions. For example, you can run one discovery session and discover the first set of devices. After discovery completes, you can provide the same IP pool for a subsequent LAN automation session. Similarly, you can choose one LAN pool for one discovery session and another LAN pool for a second discovery session.

• Every time you start LAN automation, it checks for 128 available IP addresses in the IP pool. If you decide to run LAN automation multiple times with the same pool, use at least a /24 pool. If you plan to LAN automate only once for the IP pool, a /25 pool suffices.

• Don't use an address pool that is in use elsewhere in the network, such as an address pool that belongs to the loopback or to other addresses configured on the device.

To start LAN automation, a site-specific CLI and SNMPv2 read/write or SNMPv3 configuration is required. Use the Cisco DNA Center Design application to configure the site-specific CLI and SNMP. Save the configuration for the site that is used for LAN automation. If you configure the credentials at the global level, they are visible at the site level. You must click the radio button for the specific site and then save the configuration to make it available for LAN automation.

When configuring the seed devices, follow these guidelines:

• The system maximum transmission unit (MTU) value must be at least 9100.

• Turn on IP routing on the seed devices.

• Set up routing between the seed service and Cisco DNA Center so that Cisco DNA Center has IP reachability to the LAN IP pool subnet.

• We recommend that you use the default interfaces connected to PnP agents. If the peer seed device has IP interfaces configured on the interfaces connected to PnP agents, those links don't get configured. If you want to configure the peer device interfaces connected to PnP agents, use the default interfaces and perform an inventory synchronization on the peer seed device. LAN automation works only when the ports are Layer 2. The ports on Cisco Catalyst 6000 and Cisco Catalyst 9500H devices are Layer 3 by default. Convert the ports to Layer 2 before starting LAN automation.

• Configure device credentials and SNMP credentials on the seed devices.

• If the seed devices have Layer 3 interfaces configured, ensure that there are no conflicts with any of the IP pools provided in Cisco DNA Center.

• Ensure that the seed devices don't have any other interfaces connected to another DHCP server running in VLAN 1.

• If loopback is not configured on the seed devices, LAN automation configures loopback on the seed.

• If any configuration changes are made on the seed devices before running LAN automation, synchronize the seed devices with the Cisco DNA Center inventory.

• Assign the seed devices to a site. (You don't have to provision the seed devices for LAN automation.)

Additional recommended configurations on seed devices:

• Run multiple discovery sessions for devices across sites connected to the same seed: If you plan to run multiple discovery sessions to onboard devices across different buildings and floors connected to the same seed devices, we recommend that you block the ports for PnP agents that do not participate in the upcoming discovery session.

  For example, imagine that seed devices are in Building-23 and are connected to PnP agents on Floor-1 and Floor-2. Floor-1 devices are connected on interfaces Gig 1/0/10 through Gig 1/0/15. Floor-2 devices are connected on interfaces Gig 1/0/16 through Gig 1/0/20. For the discovery session on Floor-1, we recommend that you shut down ports connected to Gig 1/0/16 to Gig 1/0/20. Otherwise, the PnP agents connected to Floor-2 might also get DHCP IPs from the server running on the primary seed device. Because these interfaces aren't selected for the discovery session, they remain as stale entries in the PnP database. When you run the discovery session for Floor-2, the discovery doesn't function correctly until these devices are deleted from the PnP application and write erase/reloaded. Therefore, we recommend that you shut down other discovery interfaces.

• Endpoint/client integration: For Cisco DNA Center 1.2.8 and earlier, if there are clients connected to a switch that is being discovered, those clients contend for DHCP IP and might exhaust the pool, causing LAN automation to fail. Therefore, we recommend that you connect the client after LAN automation is complete.

  This endpoint/client integration restriction does not apply to Cisco DNA Center 1.2.10 and later. Clients can remain connected while the switch is undergoing LAN automation.

Ensure that the device that you want to LAN automate is running the Advantage license level. Otherwise, some commands are not pushed.

New PnP agents have factory defaults and are ready to start LAN automation.

If you are reusing existing network devices, ensure the following:

• PnP agents must have the required license that can push the LISP, IS-IS routing, and CTS-related CLIs. Use the show license command to see the current license level. If required, upgrade the license.

• PnP agents should be in a clean state. They should not have stale certificate, keys, and so on from the previous runs.

• Bring the device back to the factory defaults by clearing the following from the switch console:

  [CLI config mode]
  
      no pnp profile pnp-zero-touch
      no crypto pki certificate pool
      Also remove any other crypto certs shown by "show run | inc crypto"
      crypto key zeroize
      config-register 0x2102 or 0x0102 (if not already)
      do write
      end

  [CLI exec mode]
  
      delete /force nvram:*.cer
      delete /force stby-nvram:*.cer (if a stack)
      delete /force flash:pnp-reset-config.cfg
      write erase 
      reload (enter no if asked to save)

You stop LAN automation to finish discovering all required devices and to prevent inadvertent discovery of additional devices.

Click Stop.

After you click Stop:

• The remainder of the configuration is pushed to network devices, which includes converting the point-to-point links from Layer 2 to Layer 3.

• The VLAN 1 configuration is removed and the VLAN 1 IP addresses are returned to the LAN automation pool.

• The device is onboarded in Cisco DNA Center and assigned to the site.

After the LAN automation stop process is initiated, the LAN Automation Status changes to STOP in Progress.

After LAN automation stops, the following sample configuration is pushed to the discovered device.

The network orchestration service issues a RESYNC for seed and PnP devices to retrieve the state of all links. After the initial RESYNC completes, it pushes the Layer 3 configuration on all Layer 2 links. Finally, it reissues RESYNC to resynchronize the cluster's link state.

The Layer 3 link configuration is pushed when network orchestration stops. (Each interface pair gets its configuration.)

interface GigabitEthernet1/0/13
 description Fabric Physical Link
 no switchport
 dampening
 ip address 192.168.2.97 255.255.255.252
 ip router isis
 ip lisp source-locator Loopback0
 logging event link-status
 load-interval 30
 bfd interval 500 min_rx 50 multiplier 3
 no bfd echo
 isis network point-to-point

After all the point-to-point links between the seeds and discovered devices—including links between peer seed and discovered devices—are configured, the devices are added to the site and synced to Cisco DNA Center.

The LAN automation process completes and the LAN Automation Status changes to Completed.

Check the LAN automation logs.

This section explains how to add an existing switch that was already present in Cisco DNA Center.

If the switch being added was previously LAN automated (part of another stack/standalone) or was discovered by PnP, to add it, you must first remove the switch physically and then remove its entry from the inventory and PnP application/database.

Remove the Switch from Inventory

If the switch is a standalone, from the Cisco DNA Center home page, click Inventory and select the switch to remove. Choose Actions > Delete Device. If the switch is part of a stack, remove the switch physically, and then resync the original stack. After the sync completes, the removed switch serial number does not appear in the inventory.

Remove the Switch from PnP

• If the switch is a standalone, first unconfigure pnp profile pnp-zero-touch from the switch and then delete the entry from the PnP database under Device.

• If the switch is part of a stack, remove the switch physically. Make sure that the removed switch does not have pnp profile pnp-zero-touch; then, delete the entry from the PnP database under Device.