SD-Access Migration

Are you planning another “SD-Ready” LAN refresh or will you migrate to SD-Access?

When we published the first blog about Software Defined Access in early 2018 many people were still skeptical about the technology and its benefits. Even now, when you talk to many traditional network engineers they still don’t like the idea of using GUI to manage their LAN. Configuring VLANs, access ports, trunks, SVIs, routing and firewall rules is something that people are used to. On the other hand, allowing too much automation may threaten job security but will it? At the end of the day every organization will still require a strong technical team that is able to run the network. The role of an engineer is not going to disappear but it will change.

With SD-Access the connectivity can be provided in minutes rather than hours or days. Regardless of your access method you can get the same experience on the network. Instead of repeatable tasks that can be automated like adding another access switch or defining a new IP subnet, today’s network team can concentrate on things of much greater significance. They can become proactive instead of reactive and preempt problems before they happen. This is possible by working with Analytics and Assurance built-in DNA Center. The policy implementation is far less complex and easy to understand. It doesn’t rely on IP addressing but human readable Scalable Group Tags. This also means that reacting to any network security incidents becomes a lot more effective.

Selling the benefits of SD-Access isn’t our intention here because those are quite obvious. What we would like to concentrate instead is the high level approach and consideration when planning SDA migration approach. At EDNX we have vast experience with SDA and we continue improving our deployment strategy.

Integrate your legacy network with SD-Access and build DNAC cluster

Typical LAN upgrade in most cases requires connecting old and new core switches by L2/L3 link and gradual migration of access layer. Moving towards SD-Access requires a different approach because the new LAN will become a fabric with multiple Virtual Networks. As of December 2019 in order to route between those virtual networks you need to have a fusion device. It can be a router, switch or a firewall but that is essentially how you would start connecting your old and new networks together. The fusion device would need to provide IP reachability between both networks by integrating at Layer 3 in Global Routing Table. At this stage static default route should be enough to achieve it. At the same time the legacy network needs to have Layer 3 connectivity to all addressing space in SDA Fabric. If this addressing is well planned then it could also be covered by a single static route towards the fusion device.

There are many benefits of using a switch as a fusion device that include the following:

It can become a service block that provides physical connectivity to WLC, DNAC Cluster as well as other services like DNS, DHCP
It can also allow firewall integration for traffic flowing between Virtual Networks if required

For the purpose of this illustration lets assume that the fusion device is a switch and that it provides a physical connectivity to DNA Centre.

Build your fabric underlay and add devices to DNA Centre

Once DNAC Cluster has base configuration and the fusion switch have a layer 3 connectivity to the legacy network it is time to add the rest of SD-Access components. There are various possible designs but in a typical Campus LAN there will be two control plane / border nodes and the large number of edge nodes. It is worth noting that not all edge devices will be added at this point unless you can collocate them with the existing access layer. Building the underlay would include the following high level steps:

Physically connect the Border/Control Plane nodes to the fusion switch and to all edge devices. Lets assume there is no other intermediate nodes for simplicity.
Configure Border/Control Plane, fusion and edge devices in a single IS-IS domain. This requires each device to have a hostname, loopback and P2P links to its neighbors
Once all of the infrastructure devices are reachable from DNA Centre, add the relevant SSH credentials and SNMP community that are necessary to on-board them on DNAC
Provision all of the fabric components on DNAC and make sure they are all running the software according to the SD-Access Compatibility Matrix

In the end of this stage you should have your underlay configured and reachable. Any additional edge nodes can join this underlay later as required.

SD-Access design phase

The bulk of any SD-Access deployment revolves around DNA Centre. This is where you need to create IP Pools, Network settings, Wireless SSIDs and configuration templates. You also need to create your network hierarchy by defining sites, buildings and floors. It is not in the scope of this blog to provide an example design because it all depends on the client requirements, legacy services, number of sites and many other factors. The design phase will continue as the network grows over time and needs more IP Pools, additional sites, buildings, APs etc.

Segmentation strategy and ISE integration

Cisco ISE is a critical component of SD-Access solution so the next step is to integrate DNAC with ISE by pxgrid. There is a lot of documentation on that topic including some short videos on Youtube. One of the tricky parts is generating certificates for DNAC using openssl but hopefully this process will be simplified in the future. Second important aspect of the policy implementation is defining Virtual Networks and Scalable Group Tags. Again, this blog isn’t about any specific case so best to check this Software Defined Segmentation Guide that provides a lot of useful information and insights about Macro and Micro segmentation strategy. The policy management isn’t something that you only configure at the beginning. Also, it is best to test IP reachability between various parts of the network before implementing any security on top.

Provision SD-Access Fabric

Final step in building your SD-Access Fabric is configuring Border, Control, Edge Nodes and Fabric Wireless LAN Controllers. All this can be done from the “Provision” section of the DNA Centre. Depending on the number of sites and type of transit between them you also need to “connect” the new fabric to the network by IP Transit or SDA Transit. In this example we have used fusion switches and there is only a single fabric site therefore IP Transit would be required. Although the configuration of IP Transit is automated at the borders, you will need to configure the fusion devices manually. In one of the previous stages the routing protocol between fusion switches and fabric borders was IS-IS. This will now be replaced by BGP in Global Routing Table as well as BGP per VRF to advertise Virtual Network address space.

Test connectivity from the edge nodes and perform steady migration

Once the fabric is configured it is very important to test it before connecting loads of live endpoints to it. The test must include:

Static and dynamic host on-boarding and SGT assignment
Wired & Wireless connectivity
Micro and Macro Segmentation
IP Address allocation by DHCP for various endpoints that belong to different IP Pools
Connectivity between endpoints connected to the fabric and the rest of legacy network, DC and the Internet
Connectivity between Virtual Networks if required at IP level
Component failover testing including: Border/Control Nodes, Fusion devices, DNAC cluster members

This initial testing is very important before migrating many live users and endpoints to the fabric. Of course, no tests and plans are ever going to be perfect. There will be problems that you can only spot during live migrations but trying to preempt as many as possible would greatly improve overall experience for end users.

To sum it all up, implementing SD-Access on your network won’t be a big bang cutover with a flick of a switch. You can plan it really well and execute in controlled manner to minimize any downtime. Both old and new network can work in parallel allowing your organization to get a taste of what the technology is capable off before making decision to fully migrate to SD-Access.