An event based systems the network management protocols work very differently to query based systems.
In any event based system the network management system simply listens for possible announcements or
events to be sent over the wire.
Typically network management protocols that leverage these types of events are either logged based or
a in P-trap based.
Now they are controllable in terms of the amount of detail that you receive from devices on your network.
So as an example on a Cisco Rodda you could enable debugging which produces a very large amount of data.
There's a lot of low level detail that's generated with the debugging.
You may not necessarily want that amount of data pushed to your network management system.
One of the issues here is if you receive a large amount of data who's going to sift through the data
to make meaningful decisions on the data that was received.
So you don't want it just enable lots of event based information that same to assist looks over one
of the advantages of event based systems is that they can react very quickly.
In other words if an event takes place on the network the network management system can act on that
event immediately rather than waiting for a polling interval to expire.
As an example if you are polling a router interface for its status every five minutes then you would
know that that interfaces up whenever the poll is done or query is done in a query based system.
But if the interface goes down just after you've polled it it may take another five minutes for you
to realize that the interface went down when your network management system pulls the router every five
minutes.
It will receive back a positive response from the Rodda confirming that the interface is up as an example.
That's typically done using a network management protocols such as Ace and MP.
So you know the interface is operational because you've queried the router if you don't get a response
from the router then you know there's a problem.
But the downside of a query based system is that you only polling it every five minutes.
If the interface went down immediately after you pulled the router it could take up to five minutes
for you to realize that there's a problem on the interface of that router where as in any event based
system and it's an empty trap log message is sent immediately when the interface goes down.
So in this case the router is informing the network management system that there's a problem rather
than the network management system having to wait a five minute interval to query the Rodda for the
status of an interface.
Now there is a downside to event based systems the network management protocols are not reliable because
the network management system is simply passively waiting and listening for events to be sent to it.
It wouldn't know if there was a problem on the network if that event didn't reach the network management
system.
So if there's a network issue or a need to face went down that prevents the log message or an empty
trap from getting to the network management system the network management system would be unaware of
the problem without explicitly polling the network device.
So what are the best practices what should you be doing in a live environment how best practices state
that you should use both you should use polling based or query based as well as event based network
management protocols as part of your network management solution.
Now it doesn't help just to receive a large amount of data.
You need to make meaningful decisions on that data.
So you also want to bold and leverage alerts and reports so that you both are notified when an issue
occurs whether it was based on a polling based detection mechanism or an event based detection.
And in addition you're going to want some kind of reporting capability which provides you with detail
of performance not only in real time.
At this point in time but over a period of time.
So you want historical data available so that you can make meaningful decisions.
As an example if an interface on a Rodda has a utilization of 70 percent is that good.
What is that bad.
That's difficult to know if you don't have historical data that allows you to build a baseline of what
your network typically runs at.
If that interface in the last three months has been running at 2 percent utilization and now suddenly
it's running at 90 percent utilization you'll know that something has happened on your network that
has changed to the interface utilization dramatically.
So you're going to want reports to give you performance detail over time as well as notify you of issues
and the availability of devices in your network.
You're going to want to at a glance be able to see if there's a problem with a network device such as
a router or if there's a problem with an individual interface on one of your routers.
Don't forget to set the polling frequency and how granular your event notifications are.
This will vary from one environment to another and often depends on the type of typology that you have
the bandwidth available and the resources you have to detect and then act on the information that you're
receiving.
In addition you might need to make decisions on how quickly you need to react to an issue on your network
if something happens on your network and it effects an entire building for the entire organization you're
going to want to act on that quickly.
But if something happens and it only affects a single device that's not important it's probably not
as important that you get woken up at 3 o'clock in the morning to tell you that the port on the switch
has gone down.