Network Device Configuration Standardization – Thoughts on Ethan Banks’ post

Network device configuration standardization can be a challenge even for the most experienced network engineer. Check our post on the matter. Read More.

Notice: This blog post was originally published on Indeni before its acquisition by BlueCat.

The content reflects the expertise and perspectives of the Indeni team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog

Key Takeaways
  • Lack of standardized network device configuration is a frequent root cause of operational issues identified in many root-cause analyses.
  • NTP standardization must include verification that devices can actually reach and synchronize with the configured NTP servers, not just share the same settings.
  • Over-configuring external authentication servers can cause login failures if timeouts accumulate and prevent fallback to local authentication when connectivity is lost.
  • Security best practices such as SNMPv3, SSH over Telnet, and configuration hardening must account for platform limitations and side effects, such as dropped GARP packets that can silently break clustering.
  • Device configuration backup solutions must validate backup integrity to avoid discovering incomplete or unusable configs only during a restore event.
  • Out-of-band management should be implemented (e.g., via console or lights-out solutions on separate links) and actively monitored to ensure access when in-band connectivity fails.

Ethan Banks has an interesting newsletter called The Hot Aisle. Worth following if you’re not familiar with it, basically the thoughts of a very experienced network engineer.

In today’s post, Ethan covers the item at the top of his wishlist: network device configuration standardization. Ethan’s wishes are those of many others that I meet with on a regular basis. Many root-cause-analyses that were done over the years pointed to lack of config standardization as the root cause. Get that done well, and you get rid of many of the issues you run into regularly.

But how do you make sure it’s done well? In Ethan’s post he lists a few configurations he’d like standardized. I thought I’d add my $0.02 here on pitfalls people should watch out for. All of these I’ve learned through watching what issues our customers run into.

  1. NTP server best practices – it’s one thing making sure all of your network devices uses the same NTP servers, it’s another to make sure they can actually reach them. Don’t just rely on tools that tell you the NTP config is set to the right host, test it! Different devices have different ways of achieving this.
  2. External authentication – very important and common best practice. Be careful of a situation we’ve received multiple reports of (but found nothing online so far, interestingly): if you configure too many external authentication servers and all connectivity is lost, you might lose local authentication as well. The reason being that by the time the authentication times out with each external server, the entire login process times out.
  3. SNMPv3 – good idea, just be careful of things like this.
  4. SSH instead of Telnet – undoubtedly a good idea. We do see customers running older IOS’s that don’t support SSH.
  5. Hardening – very important, but be very very careful about this. For example, hardening can result in GARP response packets being dropped, thereby breaking clustering of certain products. This means that you might not discover the impact of the hardening until months later.
  6. Device configuration backup – VERY VERY important. Be sure to use a product that tests the backup was done correctly. You don’t want to try and restore a partial backup.
  7. OOB management – one of those things people wish for when they’ve locked themselves out of a network (or a number of networks). The most common solution we see with customers are those console/lights-out products that use a separate DSL or cellular line to access. Expensive usually, much more than just setting up a VRF, but usually fool proof (if you actually monitor them to ensure they are connected).

 

Related content

Three armored figures walking toward a futuristic Las Vegas skyline with pyramids, glowing orb, and "Welcome to Fabulous Las

Your journey to intelligent NetOps begins at Cisco Live

Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.

Read more
Stacked colorful wooden directional arrows on a post by a calm seaside with distant hills and blue sky

Replace BIND and ISC with Micetro DNS/DHCP Server (MDDS)

Tired of patching and manually configuring BIND DNS and ISC DHCP? Discover how Micetro MDDS appliances can replace them for modern DDI.

Read more
Row of orange industrial robotic arms positioned along an automated conveyor belt in a factory setting

Automate it all in Integrity with REST v2 API-first DDI management

Discover API-first DDI with Integrity X by using REST v2 to automate DNS, DHCP, and IPAM for scalable, secure network operations.

Read more
Three colleagues at monitors collaborating, overlaid with network, analytics, cloud, and gear icons.

Agentic AI adoption in network observability propels NetOps teams

Network observability is crucial for today’s networks and even more capable with agentic AI, according to new Omdia and BlueCat research.

Read more

⏳ Cisco Live is almost here. Put BlueCat on your agenda for smarter, more secure networks.