BlueAllyBlueAlly
Blog

Migration to SD-Access

Networking, Security

PETER WELCHER | Solutions Architect 


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

Previous blogs in this series include: 

Defining SD-Access and Cisco Catalyst Center: Why You Should Care 

Cisco Catalyst Center: Pros and Cons 

SD-Access Concepts: The Big Picture 

Managing SD-Access Segmentation 

Securing SD-Access Traffic 

SD-Access Single-Site Design 

SD-Access Multi-Site Design 

SD-Access Multi-Site Lab 

SD-Access Multi-Site Lab Tasks 

SD-Access and IP Pools 

SD-Access and E911 Services 

SD-Access and Wireless 

 

This blog series has covered a lot of design and prep work. The present blog examines SD-Access deployment planning and migration to SD-Access, analyzing prior topics from a different perspective while providing new suggestions.  

If you need additional information, there are at least three prior Cisco Live 2020 presentations that provide copious details and way too much information for inclusion here. See the References section at the end for links to them. They do date back to 2020, but they are fairly complete and still relevant.  

SD-Access Deployment Planning 

Almost everybody has an existing network. That means when you’re migrating to SDA, you will want to be very well-prepared to avoid disrupting users in the process. 

Let’s look at what preparations for deploying SD-Access might involve. Amazingly (not!), this may have some overlap with tasks I suggested for SDA lab work.  

Here are some of the suggested major prep steps. There are, of course, lots of details in each of them. 

  • Build ISE skills if you haven’t done so already, and don’t have someone with ISE skills available. Take a course or three. The Cisco Continuing Education ISE online self-study course is affordable if your budget is thin. Ditto Cisco Press books about ISE. Yes, they’re very thick books – there’s lots of material to cover! 
  • Consider deploying at least basic 802.1x authentication in your existing network to build hands-on ISE experience. Two people with solid ISE skills is the advisable end goal here.  
  • Consider taking an SD-Access course. At least download relevant Cisco Live slide decks and go through them. You may have to go as far back as 2020 since COVID caused shorter online talks, and then SDA talks since then have somewhat tended to focus a bit more on new features, etc.  
  • Unless you have to replace equipment quickly, it would be ideal (as in less stressful) to incrementally ease into SD-Access. If you do need to move quickly, plan for a minimal SDA deployment, with Wireless support and more SDA functionality layered on later.  
  • Draft an initial design and plan. What’s the network topology going to look like? Where are your BNs, CNs, FE/ENs? How would you be doing wireless? IP Transit or SDA Transit or what between sites? 
  • What is the minimal set of VNs for your initial build? What is the minimum number of VNs you’ll eventually need? Start small then add later! Bare minimum, then major segmentation needs only, then add more segmentation if (still) desired! (Your energy may be required elsewhere, or you may be fed up with more segmentation!) 
  • 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. Make sure the deployment timeline leaves a couple of months for learning, experimenting, and starting over. Caution: most new sites end up in a rush to get users into the building. Pre-building a separate SDA buildout in an existing building with sufficient spare closet space might give you time for hands-on and errors before migrating users over.  
  • Build SDA / CCC skills. Walk through 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 employees with solid SDA / CCC 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 your VAR and Cisco to build a full deployment 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. Doing a starter buy also reduces risk if you discover BOM problems (switch model choices, quantities, etc.) or other snags or gaps during that initial buildout.  
  • Plan your migration (see also below).  
  • Bring production datacenter functions up full-scale production ISE, full-scale CCC cluster(s), fusion firewalls, TCN’s.  
  • 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: https://cabots.com/img/party_sundaes_800x240.jpg. How big is your appetite (for change all at once)? 

  1. 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 all Layer 2 VLANs extend up to SVI’s on the distribution or core switches? Or is it Layer 3 to the access layer?  
  • Cisco highly recommends that you do SD-Access with a 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. SDA templates / LAN Automation is your friend for this! 

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 pros and cons): 

  • If you keep your existing infrastructure as underlay per Option 1 above, you carry forward any instability or configuration errors.  
  • The 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.  
  • Option 2 just stretches VLANs from old to new by trunking the old switches into the overlay. Your new fabric can be built based on CCC 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 

A 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 Cisco Live slideware (below) says to talk to Cisco about workarounds for the near term. A solution may have been shipped later in 2020. (I haven’t had to deal with this so haven’t been tracking it.) 

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.  

Conclusion 

Migration to SD-Access is best done incrementally. For the best results, plan it well, and lab test everything before committing.  

References 

  • See also Cisco Community post-2020 by Scott Hodgdon. I include three specific very useful CiscoLive links immediately below: 

 

You might also want to take a look at this Best Practices session: 

 

Some older references (“oldies but goodies”): 

 

 

Disclosure Statement

Contact BlueAlly

Connect with BlueAlly today to learn more.