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.
• Technical, workforce and financial scalability.

(*) IMHO high(er) quality implicitly means high availability and better security, both resulting in higher stability as well.

Let’s see if we’re working towards these goals in the context of brownfield 802.1x automation :

• Scalability, efficient management, faster delivery: automating the (tedious) tasks saves time, the engineering team can focus on other work.
• Higher quality and predictability:
  • Automation produces consistent results, minimizing the possibility of human errors. Automation also offers faster and more consistent rollback.
  • 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.
• Automatic port configuration from RADIUS server makes our deployment more flexible. It also allows us to deliver network connectivity services faster as we’re not touching device configurations.

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.

Keep in mind that striving for a consistent design helps your automation efforts and consequently (as already pointed out) your business.

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.
  • Replace (static) IP-based ‘authentication/authorization’ with better methods.
• Reduce or even remove snowflake deployments.
• 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.
• Gain insight into actual traffic flows. Downloadable per-port ACL’s can be used instead of core/aggregation ACL’s or humongous central firewall policies. Security measures and tools like zero trust, (micro) segmentation, SGT, etc all need accurate traffic flow information.
• 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.