Building network automation solutions

9 module online course

This is a guest blog post by Albert Siersema, senior network and cloud engineer at Mediacaster.nl. He’s always busy broadening his horizons and helping his customers in (re)designing and automating their infrastructure deployment and management.

This is the second post in a series focused primarily on brownfield automation principles using 802.1x deployments as an example (you might want to read part 1 first).

Before diving into the specifics of the next 802.1x automation phase, let’s take a step back and think about why we’re going through this effort. Automation is a wonderful tool, but it’s not a goal… and neither is 802.1x a goal - it’s just another tool that can help us realize business benefits like:

More flexibility.

Faster delivery of services.

High(er) quality(*) and predictability of services by lowering complexity and improving stability, consistency, and reproducability.

Efficient management, and thus also less tedium; more interesting work.

Automation playbooks and scripts document the changes. Be sure to save the input and output of the automations tools.

As automation is easier accomplished with generic (templated) configurations it encourages us to clean up the device configuration. Switch and port specific configurations are more complex, less consistent and less reproducable. By moving port specific configuration from the switch to the RADIUS server “source of truth” (e.g. Cisco ISE), 802.1x helps in simplifying device configuration.

Preparing for and implementing 802.1x in a brownfield environment means you will probably have to talk to most, if not all business units, and that’s necessarily a good thing (to reverse a popular phrase). While engaging with various parties, outline the benefits they and the business will reap, and together re-evaluate current practices to see where further improvements can be made. When asking for the functional business requirements, it might turn out there are better approaches than what you’re doing now.

Beware of project scope creep… but as long as those diversions don’t share a critical path you might be able to use a phased approach. Plan and spin off related projects to work on those further improvements.

Examples of possible further improvements for higher quality, more flexibility and scalability are:

Improve mobility and reduce the complexity and brittleness of (large stretched) L2 domain by removing the dependency on jfixed IP addresses:

Migrate from fixed IP addresses to DHCP.

Use DNS or other service discovery and location/identity separation mechanisms.

Move controllers from the edge to stepping stones. For example, instead of using software installed on workstations to control video surveillance cameras, provide a stepping stone with the required software in the data center.

Investigate where it might be possible to provide self-service or automated workflows for e.g. device identity (MAB springs to mind) or ACL’s.

While talking with the business and re-evaluating current requirements don’t miss out on the opportunity to write down the needs and wishes for mobility, functionality, isolation and programmability. This helps in determining if and how technologies like overlays, SGT’s, SD-Access, etc. might be used.

The generic solution to best alignment with functional business needs is (as always) “It Depends (tm)”. More advanced (and complex) technologies might or might not help. I won’t break new ground for avid ipspace.net readers by saying that although you don’t see the complexity, it is there.

The author

Ivan Pepelnjak (CCIE#1354 Emeritus), Independent Network Architect at ipSpace.net, has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced internetworking technologies since 1990.