Amazon Transit VPCs and Transit Gateway
I’ve been working with two large organizations recently on projects which include identifying gaps in network management tools (in the broad sense, including UC management) and related processes. That inspired me to list some best practices that I’ve identified over the past 20+ years. I want to say the tools come and go, but then again, some tools just won’t fade away. For example, I’m beginning to think HP Openview/NNMi will outlive me. Let’s not get into whether any of the other effects of aging apply to either NNMi or me.
Let’s start with some basic facts:
All those items drive the economics for the vendors. It’s a tough market. You need specialized niche programmers, you have to invest a lot to manage each new technology, and the relatively limited revenue will limit your R&D budget.
Results of this:
Another basic factor to bear in mind is the way we technologists have been trained by vendors: buy a new product or technology, and it’ll make things better. Sometimes it does. Sometimes it just adds work, or the labor costs exceed the benefits. Cisco’s Martin Roesch, founder of SourceFire, talked about that a bit at our recent CMUG seminar, concerning security products: as you add new sensors and products, you do not want exponential growth of complexity. Cisco is architecting for that.
The reason I bring this point up is that one common thread across a lot of companies is the lack of ownership and time to maintain and add value by tuning network management products. That is, the tools we have don’t solve our problems, so we add another, making the time constraint worse, so it too fails to add the value we hope for.
To succeed with network management tools, all of the following are needed:
For some reason, people seem to get really attached to a particular network management tool. This might be because there is so much involved in learning any tool, so the tool you know becomes a personal comfort zone. Or maybe people just end up really liking one tool, perhaps the one they chose.
In any case, this can become the enemy of progress. Focusing on requirements helps. Do ask questions like “what do you want the tool to do?” Otherwise, discussion can become a “my tool/your tool” battle, and get very emotional.
Reasonably good network documentation, including diagrams, are the “A No. 1” basic network management tool, the real starting point for network manageability. If you don’t have the basics, you need to fix that.
I’m a fan of a network overview document, oriented around the OSI layers. Physical sites and links. Where are the VLAN extents? how many are there? What’s the big picture IP addressing scheme? Routing scheme? Points of route redistribution? Where do filters live, and what is their purpose? All words and diagrams, not so heavy on tech details. Think “orientation and big picture.”
I also like “rationale” documents. As in “why did we build the routing this way?” These documents explain choices – why certain decisions were made, particularly ones that others might wonder about, and then try to “fix” – breaking something, or running into the problem you cleverly avoided with your undocumented design feature.
In my latest network management tool assessment, I’m realizing I like tightly integrated suites, when done reasonably well. They can do things that isolated products cannot. Some vendors get that, others do not. How to tell: loose integration usually means both tools have a shared web front end, but do not really share much data.
As an example, having both NetScout Infinistream for packet capture, and Riverbed for NetFlow collection at a site creates two islands of information. Users would have to jump back and forth. They are likely to just use one or the other, but not both. Using one vendor for both sources of data increases the tool’s effectiveness, and the user’s as well.
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!
For this blog, I’d love to hear about your favorite (or non-favorite) network management tools, and what you think is good and not so good about them.
Amazon Transit VPCs and Transit Gateway
Aruba Wireless Controllers: Architecture & Configurations
Dealing with Performance Brownouts
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.