Applications covered in course

 In this course I'm going to demonstrate Multiple Solar Winds Applications including
network performance monitor or NPM, Kiwi Syslog server, Kiwi CatTools tools and
others that may be of interest to you.
 Please give feedback if there's any tools that you'd like to add to the course. But
before we get into the demonstrations it's important that you understand the
protocols that these applications rely on, to manage the network.
 ->So, you need a knowledge of protocols such as ICMP, SNMP or simple network
management protocol, SNMP traps, syslog and WMI. These protocols enable
applications such as NPM to access devices in GNS3 or in a production topology and
to extract information from those devices.
 So, it's important that you as a network engineer or network manager have an
understanding of these protocols.
 If you already know what SNMP is or what a syslog is. Feel free to skip ahead. But in
this video, I'm going to discuss some of these protocols.
 ->In addition to those protocols. You should know what a MIB is, or a management
information base, and what an OID is or object identifier. You should also know what
a performance counter.
 ->Now they are two main types of network management protocols that you should
be aware of when studying network management protocols and how to manage
your network. Always think about how the protocols work, and the advantages and
disadvantages of the two main types of network management protocols.
 The two types of Query based, which means that the network management
station or NMS asks a question from a device and then waits for a response.
 And then you have event-based protocols where the network management
station simply listens for announcements or events from the network.
 So, with query based the network management station is sending a query to a
Router to extract information from that Router,
 whereas with event-based protocols, a router switch would inform the network
management station of an issue or something taking place.
 as an example, an interface goes down that's an event, and a message is sent to
the network management station to inform the network management station of
that event taking place.
 ->There are several advantages and disadvantages to why you'd want to use a
query-based network management protocol.
 Firstly, query-based protocols are reliable, because its query based, the network
management station is queering or asking for information from a network device.
 If the NMS doesn't receive a response from the device that indicates a problem.
The fact that the NMS made inquiry and didn't get back a response, indicates
that there's a problem on the network.
 so, no response equates to a problem.
 ->Query based also called polling-based network management protocols can be
scheduled and you can set how frequently that's done.
 So, you could poll the network on a very frequent basis or polled the network
less frequently to reduce the impact of the queries on the network.
  As an example, you may not necessarily want to query a network device every
five seconds, because of the overhead that you are putting on the network.
 Now in Orion Network Performance Monitor or Orion NPM. Also referred in this
course too as solar winds NPM.
 The default setting is two minutes for Query based poles for status information and
9 minutes for Query based polling for statistics.
 Orion NPM uses both query and event-based protocols.

Event Based Network Management Protocols and best

practices
 In 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 Syslog based, or SNMP 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 Router, 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 sent to your
syslog server.
 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 polls the router every five minutes. It will
receive back a positive response from the Router, confirming that the interface is up
as an example.
 That's typically done using a network management protocols such as SNMP.
 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 an Event based system, an SNMP trap or Syslog 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 Router 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 interface went down, that prevents the Syslog
message or an SNMP 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.
 Now 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 build 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 Router has a utilization of 70 percent, is that
good or 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, to 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 or 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.

Network Management Planning

 Before you rush out and deploy a network management system in a production
environment.
 Think about network management planning, in a 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 N.P.M.
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 you a 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 metric 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 are 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 percent utilization and then goes up to 50 percent
utilization. You may not want to be notified of that, but when it goes to 90
percent 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 and NPM. NPM of course has many options and settings that you
can change based on your network as well as your business requirements.

Reporting, Network Overhead and Impact of Network

Topology

 Another key area of network management planning is knowing how to build and
leverage reports.
 Now the NPM report writer makes it quite easy to create various types of reports. but
it's worthwhile having a look, at seeing which reports are available for you and how
you can customize those for different business requirements.
 Now baselines are important when you're doing capacity planning or doing service
level agreement or SLA management.
 You also want to think about things such as availability, which means how much a
network is up during that period of measurement.
 You also want to think about performance and capacity planning.
 As an example, with availability. You need to understand the term 59s or 49s.
 what 59s simply means is that during the period of a year as an example. the
network is up 99.999% of the time. In other words, they are five nines in that
number, that equates to about five minutes of downtime per year.
 When you deploy a network management system. it's typically going to add an
overhead to your network. This is especially true if you are using a query-based
system that's polling the network using a very short interval.
 So, you should determine the scope and impact on the network that the network
management system will have.
 So, as mentioned, one of the things you need to think about is polling frequency.
This means how often you're going to poll devices to collect data.
 The more often that you poll devices the more granular and the more detailed
your statistics are gonna be.
 However, on the flip side that means that it's going to have a larger impact on
your network because there's more traffic being transmitted on the network. The
network management system is polling the network on a more frequent basis
which puts more traffic on the network.
 And in addition, there's a higher load on your network devices because they have
to reply back to the network management station with information that you
trying to gather from that network device.
 So, more polling equates to more detail, and quicker detection of issues but it
puts a higher load on both the network and the devices in your network.
 Now once again the advantage of more polling is that you have more detail and it's
quicker to detect issues. However, on the flip side it can create extra traffic on the
network.
 Now most modern network management systems and a lot of modern network
devices can handle a larger amount of network management traffic than was
possible in the past. The processing power of your network devices and the speed of
interfaces are a lot greater today than they were a few years ago. So, it's not as much
of a problem as it may have once been.
 This is another reason that you want to leverage both event-based and network
management protocols as well as query-based network management protocols.
 Event based protocols once again of a real time unsolicited feedback from your
network devices. A router is going to inform the network management station when
an interface goes down.
 With polling based or query-based protocols. There's a query and response. In other
words, the NMS is queering a device for information and it's responding or
answering back to that query.
 Now less polling equates to less bandwidth utilization, but in addition equates to
smaller storage requirements which is another important thing to think about.
  If you're collecting a large amount of data, you need to think about your disk
requirements for your sequel's server which is where NPM stores data.
 large amounts of data equate to biggest databases which in turn means that you
need more disk space.
 Another important topic to discuss, is the impact of the network topology on your
network monitoring.
 If an interface goes down does it impact the ability of the NMS to collect data
from your network devices.
 So as an example, if you viewed the network topology in something as simple as
Visio or within one of your management tools. how would an outage affect the
ability of your network management system to collect data from devices in your
network?
 If you had devices at a remote site and you wanted to collect statistics from those
devices, how will a link down affect your ability to get to those statistics.
 If there was only a single link to the remote site and you had a central network
management system, and the link went down, the NMS would no longer be able
to access those devices to collect data.
 So, you may need to deploy a network management collector on the remote site to
collect data remotely rather than trying to collect everything from a central site. So,
this would mean as an example that you deploy a distributed network management
architecture rather than having a single centralized network management system.
 This is especially true where you have multiple data centers. In that case you
might want to deploy multiple copies of NPM, one in each data center that then
forward data to an enterprise operation console or EOC.
 So, remember if you can't get to it, you can't monitor it.
So, it's important that you keep track of your network topology because you need to ensure
that you have reachability status when the topology changes.

 ACLs and Firewall rules

Things that may affect your own network reachability are access control lists or ACL and
firewall rules. In many networks that aren't actively being managed, you'll find that security
engineers have blocked protocols such as SNMP and ICMP.

Those two protocols are very important network management protocols, but for security
reasons they may have been blocked in various points in the network by security conscious
engineers.
So, it's important that when you starting to audit the network, in preparation to NMS roll
out. that you pay special attention to where traffic is allowed and where it's denied.
Now from a best practice point of view it's ideal to deploy a management plan which is
separate to the VLAN used for user traffic. So, a separate network or separate VLAN created
and network management traffic is permitted on that VLAN.
So, ACL and firewall rules on network devices would allow network management protocols
on that VLAN and allow an NMS to access the loopback of a router as an example.
Just be aware that if you limit access to network devices from only specific IP addresses. So,
as an example you only allow the IP address of the network management system to access
the router loopback interface using SMP.
When you change things in your network such as expanding the network management
applications. you may need to go back and adjust your access list or just your firewall rules.
So, it may be simpler to permit a subnet access to your network devices rather than locking
it down to an individual IP address.
In the same way when discussing security, you need to pay attention to different security
zones. A customer may have an outside interface on a firewall and inside interface and a
DMZ interface on their firewall.
These security zones can impact your network management systems. So, you need to
understand how you're going to deploy them in a mess and how security rules and firewalls
zones are going to affect overall reachability and the management strategy that you deploy.
Now last but not least, you need to think about overlapping and non-routable addresses in
your network. overlapping and non-routable addresses can be a real headache when
deploying network management systems.
You should audit your network and understand which addresses are reachable and from
when the network and take that into account as you start documenting the systems and
decide where to roll out your network management system.
In many cases if you have overlapping address space and you have devices on each of those
overlapping subnets that you need to monitor. you'll need to create a separate polling
engine for NPM for each duplicate address space zone.