As I mentioned in previous posts, I’d like to discuss a topic that really gets the adrenaline pumping for a certain in-crowd: CA Spectrum topology mapping.
If you’re like me, you’re frustrated by views that show so many tiny device icons that the view is almost useless. When you try to zoom out to see all devices, they are so small that you can’t read their names—or anything else. Is too much of a good thing a good thing? I think not: If you can’t see all the devices in a view, what’s the point in having the view?
Of course, you rely on seeing how your devices are connected to one another: This connectivity mapping is how CA Spectrum accurately determines the root cause of a device not responding to polls. But having too many devices on a single screen can be self-defeating.
Let’s take a closer look.
CA Spectrum lets you create four different device model views: the topological view (aka the universe view), the location view (aka the world view), the TopOrg view (or organizational view) and global collections. As Spectrum’s default view, the topological view places models in OSI Layer 2 and Layer 3 views after an autodiscovery or after a device is modeled. You can copy/paste models from the topological view to other views to achieve your desired look and feel.
Before we dig into the meat and potatoes of topology mapping, here are a few hard and fast fundamental rules that CA Spectrum is built on:
#1: CA Spectrum ALWAYS understands the relationships between devices modeled in CA Spectrum IF those relationships have been built.
#2: CA Spectrum doesn’t have to show users everything it understands about the relationships between devices that have been resolved.
#3: CA Spectrum builds a connectivity map for each resolved device. If the resolved devices are in separate topological views, Spectrum creates off-page references to the devices in another view. (Another tricky situation arises when you have 100s of off-page references in a view—stay tuned for a post on that topic.)
With these fundamental rules in mind, let’s discuss the often hated (but always required) methodology for creating topological views that don’t require users to view all devices in a single view.
When you’re looking to reduce your MTBF, any technique or procedure that allows this to happen is worth taking a second look. To this end, I will give you my take on how to map out your Spectrum topology views to promote an environment that HELPS you troubleshoot issues vs. HINDERS troubleshooting.
Remembering rule #1, Spectrum doesn’t care if a view has 10 device models or 300. But because users have to look at the views, the number of device models does make a difference in how we see the network—and therefore, how we should model our enterprise. Below is a screenshot of an actual Spectrum environment (you’ll immediately see the challenge it presented):
As a matter of fact, I had to use Adobe Photoshop© to get the above image, as I didn’t have a monitor large enough to display a 6128x4280 pixel image! In real life, users would have to use the scroll mechanism to see the entire view.
You may recall that I was a customer long before I was a vendor, so I know what I needed as a customer. That’s why as a vendor, I’ve developed a style that responds to what I needed as a customer. In this case, I want to reorganize the view so that it allows me to quickly see how the devices are interconnected, how they behave, where they have issues and how they correlate with other devices.
To do that, my first requirement is to create smaller views so that a typical user can read them. My second requirement is to logically separate devices so as not to produce more off-page references than I can manage.
Fortunately, my first requirement doesn’t require much knowledge about the environment—I just need to see a logical separation of the devices. From the image above I can see that many routers are connected to a main router right smack in the middle of the view. This is my starting point. Looking at the routers connected to the main router, I notice that they’re in remote locations (like stores or branch offices). With this information I devise a plan to create a view that allows me to see the same information but in an easily readable format.
I grouped the remote routers together (using their assigned numbers) and created containers for them. I then cut and pasted the groups of routers together and placed them in the containers. I added annotations in the view so that I could easily and quickly identify the remote routers and where the problem devices reside. Here is my final view:
Wow! I can read everything on the screen and see how the components are connected, starting from an MPLS provider cloud down to the remote routers. Information is presented in an intuitive dashboard that lets users see the health of the enterprise’s network at a glance. This is a view we can all understand. The outcome? More accurate and rapid problem isolation that can be used to facilitate troubleshooting when those inevitable problems occur. It also lets users prioritize work by criticality and/or the most profitable services.
So, is too much of a good thing a good thing? The answer is a resounding “No!” More importantly, can too much of a good thing be managed so that it becomes a good thing? This time, the answer is “Yes.” Can you do it? Of course! As I’ve shown here, managing topological views isn’t rocket science—it just takes a little investment of your time to make it happen.
Hit me with your thoughts and questions below! Thanks.