Migration to SD-Access

This blog is part of a series covering various SD-Access topics.

Previous blogs in this series:

Let’s take a look at SD-Access deployment planning and migration to SD-Access. We’ll take them in turn. I’ll go over what comes to my mind.

If you’re looking for additional information, there are three CiscoLive 2020 presentations that provide copious details and way too much information for inclusion here. (Plus, my repeating what’s already available in print does not add value.) See the References section at the end.

SD-Access Deployment Planning

Almost everybody has an existing network. That means you’re going to want to have your act in order so as to not disrupt users.

Let’s take a look at what your preparation for deploying SD-Access might involve.

Here are some suggested major steps. There will, of course, be lots of details to each of them.

Build ISE skills if you haven’t done so already. Take a course. The Cisco Continuing Education SISE online self-study course is fairly affordable if your budget is thin.
Consider deploying at least basic 802.1x authentication in your existing network to build a hands-on ISE experience. (Two people with solid ISE skills is the advisable goal here.) Unless you have to replace equipment quickly, it would be good (less stressful?) to incrementally ease into SD-Access.
Consider taking an SD-Access course. At least download CiscoLive slide decks and go through them.

Draft an initial design. What’s the network topology going to look like? Where are your BNs, CNs, ENs? How would you be doing wireless? IP Transit or SDA Transit or what?
Build a BOM, buy, and build an SD-Access lab (see prior blog). Alternatively, if you’re deploying a new standalone SDA site, buy what you’ll need, double-check the BOM with your favorite VAR and Cisco, etc. And make sure the deployment timeline leaves a couple of months for learn, experiment, and start over. (Caution: Most new sites end up in a rush to get users into the building.)
Build SDA / DNAC skills. Walkthrough what you’re going to use in your future network, also your migration plan (see below). Note: As with ISE, you’d be best served to have two people with solid SDA / DNAC skills. Whether those are the same people as your two ISE people is a choice.
If you’re going to use LAN automation, you’ll want to practice doing it and troubleshooting it with the staff who will be deploying most of your switches.
Revise your design document. Start working with VAR and Cisco to build a BOM. If you’re doing multiple sites, consider a staged plan / staged buy so you don’t end up warehousing a lot of boxes with aging switches inside them.

Plan your migration (see below).
Bring production datacenter functions up full-scale production ISE, full-scale DNAC cluster(s), fusion firewalls, TCNs.
Then start migrating sites.
Add functionality incrementally.

Perhaps migrate WLAN separately after wired is done. Per-site or overall. Start/continue with “Over The Top” (traditional WLAN), later migrate to Fabric Enabled Wireless (“FEW”).

If doing SDA Transit, start putting ACL rules into the fusion firewall (FFW), if initially it was just doing routing + “permit any any.”
Add one or two more VNs or start adding some SG segments and putting policies in place.
Consider ramping up functionality, e.g., ISE posture assessment coupled with SDA authorization.

Etc. (“YMMV”).

The short version of that is, slog through the details, one small bite-sized piece at a time. The following image off the web may help you visualize the need to do that:

Source: https://cabots.com/img/party_sundaes_800x240.jpg

How big is your appetite (for change all at once)?

Migrating to SD-Access

When planning your SDA migration, you’ll need to consider a couple of factors (at least) in your planning:

Is your current network basically all Layer 2 VLANs extend up to SVIs on the distribution or core switches? Or is it Layer 3 to the access layer?
Cisco highly recommends that you end up doing SD-Access with an L3 to the edge underlay.
Do your closets or closet racks have room and power to hold both the new and the old switches? Do you have sufficient fiber or uplinks to connect the new closet switches to the distribution or core layer, etc.?
Do you have hard deadlines, e.g., E-rate funding for schools, or hard-core End of Life for your existing switches?
Note: You do need to think about MTU. The important number is 9100 throughout the underlay. Miss one interface and things will break. (Templates / LAN Automation is your friend?)

There are several ways you could migrate to SD-Access. The following two are well-documented by Cisco:

Option 1 (Incremental): Replace or re-use switches in place, keeping the current network infrastructure. Add SD-Access over the top, migrate users and devices to new overlay subnets. This option uses routing to handle traffic for legacy versus migrated users and devices.
Option 2 (Parallel): Build out a new network in parallel. Extend (trunk) Layer 2 between old and new at the border, gradually swap out switches, and/or migrate users to the overlay. This option uses extended VLANs, so devices do not know they have been moved. If necessary (fiber, power, or space constraints), you can conceptually do parallel but incrementally instead of full buildout beforehand.

There are pros/cons for each of these (of course, when does networking not have them):

If you keep your existing infrastructure as underlay, you carry forward any instability or configuration errors.

This first option above works best if you already have L3 to the access layer. You can always go through that, add BFD, check for inconsistencies, etc., to make the underlay more robust. If you have mostly L2, then the 2nd option above is probably a better idea.
If you have L2 to the access layer, you really ought to consider a swap-out approach and the second migration option above.

The second item just stretches VLANs from old to new by trunking the old switches into the overlay. Your new fabric can be built based on DNAC LAN automation to get a fully automated, correct L3 to the access layer underlay. This approach assumes your subnets are big enough to be site-wide – but then our starting assumption was that they are already site-wide. (You can probably later leverage DHCP and secondary addressing to shift users in a VLAN to a larger subnet if you have to. Be sure to try that in the lab if you think you’ll need to do so later.)

If you’re in a rush to replace your current equipment and/or need time to a lab and build SDA skills, you might deploy the new switches as swap-out replacements for what’s already there. A variant of that is to manually deploy L3 to the access layer to increase network stability while migrating. This can work for smaller sites, where at the time of replacement, you also DHCP users into the new (temporary) access layer VLANs and subnets.

Complicating Factors

The previous blog discussed E-911.

I’ve always enjoyed IP multicast because it can be so different. It is something else to plan for. See the Cisco slide decks in References below.

Another factor to consider is Wake On LAN (“WoL”). Local WoL works, as it is just local broadcast forwarding. Remote WoL is a potential issue. The CiscoLive slideware (below) says to talk to Cisco about workarounds for the near term. A solution may be shipped later in 2020.

PXE Boot: add the PXE server to the IP helper list.

L2 Border: note that only one BN can be active. Having two is not supported.