I regularly exchange information with the folks at Chesapeake Netcraftsmen (www.netcraftsmen.net), who often encounter interesting real-world troubleshooting scenarios. This time it was Rick Burts, who happens to be the top Cisco NetPro participant (see background info on Rick below). He described the following scenario:
“The customer contacted me Thursday to say that during the day a problem developed on their VPN concentrator (3000 series). It was no longer accepting any VPN sessions. I was able to establish a management session to the concentrator. In doing some troubleshooting I determined that the problem was that the concentrator was no longer able to communicate with its authentication server. It turns out that their network admin had shut down that server in the morning – not realizing that it was a crucial part of their VPN environment.”
When I read this, I recognized the problem as a regular occurrence. Someone on the staff doesn’t know the set of dependencies between devices that implement a service or application. That’s why dependency mapping is so important. If there had been a dependency map available, the network administrator could have easily checked to see what services and applications depended on that server and taken a different approach that would have avoided the outage.
Similar scenarios occur when critical communications gear is taken down. A similar result would have happened if the switch providing network connectivity to the authentication server was taken out of service for maintenance. Dependency mapping isn’t just about the clients and servers; it is also about the infrastructure supporting the communications between other devices. This is what network analysis is about.
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html