Before you rush out and deploy a network management system in a production environment, think about
network management planning.
In the lab, such as with GNS3 this is perhaps not as important, but it's very important when doing
this in the real world.
Network management planning includes translating business requirements into monitoring needs, thresholds,
and network performance monitor or NPM configurations.
Other things to consider with network management planning include building and leveraging reports that
meet the needs of the various stakeholders, as well as determining and monitoring scope and impact
on the network.
And don't forget about the network topology having an impact on the actual monitoring system.
Translating business requirements means doing things such as surveying key stakeholders and departments
for their monitoring and reporting needs.
It also means documenting goals for your network management system, and this really needs to be stressed.
It's very important that you document the goals of your network management system.
Otherwise, how do you determine if the network management system deployment has achieved what you set
out to do?
An organization may have the goal of increasing the availability of the network.
However, if you don't document those goals and don't baseline your network before you deploy your network
management system, how will you determine if the network management system has had a positive effect
on the network?
And what it was originally intended to do.
It's important that your goals be documented before you deploy and in addition, make sure that you
have a baseline of the network.
In other words, you have an indication of what the network looks like in its current form before you
deploy the network management system.
If you don't do that, how will you know three months from today or six months from today, whether
the network management system has had a positive effect on the network and has accomplished what it
was originally intended to do?
Key measures also include things like data granularity, in other words, how granular or detailed should
the data be that you're collecting?
For example, if you are looking at bandwidth utilization on an interface, how often are you importing
that data?
Is it once every five minutes or once every five seconds?
If you only look at the bandwidth utilization of an interface every five minutes, you may miss a spike
during that five minute interval.
On the flip side, if you are collecting data every second, you may end up storing a very large amount
of data.
Another thing to keep in mind when translating business requirements into monitoring needs is data retention,
data retention means how long are you going to keep the data that your network management system collected
before it's either deleted or summarized?
In other words, how long are you going to keep detailed records of your network before it's deemed
unnecessary to keep that data or at least that level of detail of the data?
Other things you're going to want to do in documenting these monitoring needs is to define both the
needs of the teams involved in projects and the thresholds.
Now, what thresholds mean is the level at which you want to start seeing error states or paying more
attention.
If an interface is running at 25% utilization and then goes up to 50% utilization you
may not want to be notified of that.
But when it goes to 90% utilization, you may want to be informed that something's happened on
your network.
So you need to decide the thresholds before you get notified of possible problems on your network.
This becomes important when you build your alerts and configure the different reports available in NPM.
NPM of course has many options and settings that you can change based on your network as well as
your business requirements.