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 takeawaysThis key takeaway was generated through LLMs crawling the page and coming up with an overview of the content.The article discusses the importance of network device configuration standardization and practical pitfalls to avoid when implementing it, based on observations from network engineers and customer incidents. It covers specific configuration areas—NTP reachability, external authentication server behavior, SNMPv3, SSH support, hardening side-effects, device backup validation, and out-of-band (OOB) management—within operational network environments and explains how missteps can cause authentication failures, clustering breakages, or failed restorations. The key outcomes recommended are to verify reachability and behavior (not just config values), test backups and OOB links, and apply hardening and external services cautiously to prevent hidden, long-term operational impacts.
Why is simply setting the same NTP server in device configs not sufficient?
Setting the same NTP server in device configuration only ensures uniform configuration values; it does not guarantee devices can actually reach those servers. The article stresses testing reachability because different devices have different mechanisms to verify NTP synchronization. Operational impact includes devices appearing correctly configured while still failing to synchronize time, which can cause debugging and coordination issues across the network. Therefore, beyond configuring the NTP host, include connectivity and synchronization checks to confirm the NTP servers are reachable and functioning from each device.
What risks are associated with configuring many external authentication servers?
The article describes a reported risk where configuring too many external authentication servers can inadvertently cause loss of local authentication if connectivity to those servers is lost. Each external authentication attempt can timeout, and by the time the last server times out the overall login process may have timed out, preventing fallback to local credentials. This creates a practical lockout scenario where administrators cannot log in even though local accounts exist. The guidance is to be careful with the number and behavior of external auth servers and to validate failover behavior so local authentication remains available under network outages.
What operational precautions does the article recommend for device backup and OOB management?
For device backups, the article emphasizes using a solution that verifies backups completed correctly and can test restore integrity; relying on backups that are partial or unverified risks discovering failures only during an urgent restore. For out-of-band (OOB) management, the article notes console or lights-out products using separate DSL or cellular lines are common and tend to be reliable, though more expensive than VRF setups. Crucially, both approaches require active monitoring: ensure backup processes are validated and OOB links are monitored to confirm they remain connected and will be usable during an incident.
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.
- 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.
- 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.
- SNMPv3 – good idea, just be careful of things like this.
- SSH instead of Telnet – undoubtedly a good idea. We do see customers running older IOS’s that don’t support SSH.
- 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.
- 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.
- 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
How to map your network with user-defined links in Integrity X
Map your network with user-defined links in Integrity X to define and manage custom relationships, such as dual-stack and NAT environments.
Automate your DDI modernization path by migrating with Micetro
Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.
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.
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.