Network and Server Uptime Calculation Considerations for Monitoring tools
Uptime is one of the most important IT infrastructure operational metrics that gives an overview how “stable” or “reliable” your IT infrastructure is with 99.9999% uptime being a platinum standard.
But how do you calculate an Uptime?
In ideal (continuous and none-discrete) world calculation of Uptime is somewhat simple.
Take number of seconds in monitoring period and number of seconds when monitored object was down and use simple formula:
Uptime = 100 – ((Outage duration / Total time) * 100)
Example:
Monitoring Period: 1 year = 31,536,000 seconds
Total Object Outage Duration: 300 seconds
Object Uptime: 99.999%
Monitored Objects achieving “six nines” uptime should only be “down” for a maximum 31.5 seconds in the 365 days.
| Uptime % |
Downtime per Year |
| 99.99% |
3120 sec |
| 99.999% |
300 sec |
| 99.9999% |
31 sec |
| 99.99999% |
3 sec |
But as you get to “six nines” or higher, capabilities and configuration of monitoring tools starts to play critical role in accuracy of uptime calculations.
Single Server Example
Let’s start with an example of Uptime calculation for a single device such as a Server.
First, we need to define what constitutes a server being up or down and what tools we planning to use to determine its state.
Let assume that we use a classic ICMP v4 probing with ‘Polling Interval” equal to 1 second.
In other words, we will be sending Ping packets from a monitoring agent to the Server every 1 second and if server does not respond we shell consider it down.
Simple enough?
Well, may be in perfect world yes, but we live in real world and packets may get lost for reason other than Server being down.
Packets may get lost due to traffic shaping, CRC errors and many other reasons. So, to prevent influx of false positive Server down events we need to increase number
of consecutive packets that must be missed to consider Server to be “down” to a number greater than 1.
Let’s call this number an “Assurance Multiplier”.
Greater “Assurance Multiplier” values shell result in greater probability that we detect an actual Server down event. But at the same time greater “Assurance Multiplier” will result in slower detection time for Server down events and inability to detect short-lived outages with duration time less than (Assurance Multiplier * Polling interval) seconds.
We also need to introduce two new parameters: “Actual Outage Duration” and “Detected Outage Duration” to reflect the fact that duration of the Server outage calculated by monitoring agent may be slightly greater than actual outage of the Server due to the fact that duration of polling interval is > 0.
Summary
“Polling Interval” – Time between two consecutive state polls.
“Assurance multiplier” – Number of consecutive polling intervals when object’s state must be Down to consider monitored object to be truly down.
“Outage Detection Time” – Time is takes for monitoring Agent to detect an outage of the monitored object after outage has started.
“Actual Outage Duration” – Actual Outage Duration of the monitored object.
“Calculated Outage Duration” – Duration of the Outage as calculated by the monitored object.
Considering that Actual Outage Duration > (Polling Interval * Assurance Multiple) worst case scenarios should be calculated as following:
Outage Detection Time = (Polling Interval * Assurance Multiplier) + Polling Interval
Calculated Outage Duration = (Polling Interval * Assurance Multiplier) + 2 * Polling Interval
Lets do the math with following Monitoring Agent Configuration Example : Polling Interval = 1 Sec and Assurance Multiplier = 3
We get following results:
Outage Detection Time = 4 Seconds
Best Detectable Actual Outage > 3 Seconds
Best Calculated Outage Duration > 5 Seconds
Now we can see that provided example of Monitoring Agent configuration is sufficient for grading Server’s Uptime as 99.9999% but not sufficient for 99.99999% classification.
To classify monitoring tool for 99.99999% accuracy you need to decrease Polling Interval or decrease Assurance Multiplier by at least 30%.
So next time when you see a 99.99999% Uptime calculated by a Monitoring tool with a Polling interval of 5 minutes you know that it is likely not true.
It gets more interesting when we move into calculation of Uptime for a Network rather than a single object like Server.
WHICH US CITY USES THE MOST IPV4 PUBLIC ADDRESSES?
Nectus News, Technical NotesNote: Information is based on Nectus IP geo-location service
Creating Network Outage Dashboards in Nectus with GoogleMaps
Nectus Dashboards, Nectus News, Technical NotesCreate an Outage Map
In this chapter, you’ll learn how to create and use Outage Maps. An Outage Map is a graphical representation of the status of the Sites in your organization. Using real world maps and GPS coordinates, an Outage Map instantly shows you outages for any of your Sites in any region of the world.
This chapter covers how to:
Obtain and Configure a Google Map API Key
Nectus needs an API key to work with Google Maps. Obtaining a Google Map API Key is outside the scope of this guide. Google provides detailed instructions for obtaining a key at:
https://developers.google.com/maps/documentation/javascript/get-api-key
Once you acquire a key, follow these steps to configure Nectus to work with your key:
2. Create an Empty Outage Map
To create an empty Outage Map, go to the Nectus Top Menu then navigate to: Monitoring -> Outage Map Dashboards -> Outage Map Dashboard.
Note: Nectus supports up to 10 maps and can display any or all of them simultaneously. See Section 2.3 for instructions on creating and displaying additional maps.
2.1 Zoom In to the Geographical Area of Interest
2.2 Assign and Save a Map Name
2.3 Display Multiple Maps Simultaneously
It can sometimes be helpful to display multiple Outage Maps simultaneously. Nectus can display up to 10 maps at once. Each map has its own adjustable settings and can be zoomed and configured independently.
3. Place Sites on the Outage Map
To place a Site on the Outage Map, you need to enter the GPS coordinates in the Site Properties. You can either enter the coordinates manually, or you can let Nectus derive the coordinates of the Site from its Address.
3.1 Enter the GPS Coordinates Manually
Enter the GPS coordinates in the GPS Latitude and GPS Longitude fields.
3.2 Derive GPS Coordinates from the Address
If you don’t know the GPS coordinates of the Site, enter the Site Address and click Find GPS from Address. Nectus derives the GPS coordinates from the Address and enters them for you.
3.3 Understand Site Colors
The color of a Site’s icon on the map gives you an easy way to check the status of the Devices at that Site. Each Site icon can have one of three colors:
3.4 Access a Site Context Menu from a Map
If a Site appears on a map, you can open its context menu directly, without having to navigate through the Sites Panel. Simply right-click the icon of the Site.
3.5 Removing a Site from a Map
To remove a Site from any and all maps without removing the Site from the Nectus database, clear its GPS coordinates in its Site Properties.
4. Configure Outage Map Parameters
An Outage Map has several configurable parameters that control how things appear on the map. You can configure each map independently of the others, giving you maximum flexibility to get exactly the information you need. The following sections show you how to configure these parameters.
4.1 Change the Shape and Size of Individual Site Icons
Changing the shape or size of certain Site icons makes it easy to pick out those Sites on a crowded map. You might make your most important Sites larger than the rest, or assign them a different shape.
To change the shape and size of individual Site icons, navigate to Site Properties. In the Outage Map Icon Size field select the icon size in pixels. Use the Outage Map Icon list to select a Circle, Star, or Triangle for the shape.
4.2 Change the Size of All the Site Icons on a Map
To scale all the icons on a map simultaneously navigate to: Map Settings -> General tab. In the Set Circle Radius (%) field enter a scaling factor that will apply to all the Site icons on this particular map. The following figure shows the map from section 4.1 with the icons scaled down to 50% of their original size.
4.3 Show or Hide Site Names
Every Site must have a Site Level Name, but you control whether Nectus displays those names on a map.
To show or hide all the Site Level Names on a map simultaneously navigate to: Map Settings -> General tab and check or uncheck Site Name.
4.4 Display of Hide Map Objects
Outage Maps can display a huge amount of information, not all of which may be useful to you. You can configure a map to display only those objects that are relevant to you.
To show or hide all the Site Level Names on a map simultaneously navigate to: Map Settings -> Google Map tab. Check or uncheck Map Objects as desired.
Network and Server Uptime Calculation Considerations for Monitoring tools
Nectus News, Technical NotesNetwork and Server Uptime Calculation Considerations for Monitoring tools
Uptime is one of the most important IT infrastructure operational metrics that gives an overview how “stable” or “reliable” your IT infrastructure is with 99.9999% uptime being a platinum standard.
But how do you calculate an Uptime?
In ideal (continuous and none-discrete) world calculation of Uptime is somewhat simple.
Take number of seconds in monitoring period and number of seconds when monitored object was down and use simple formula:
Uptime = 100 – ((Outage duration / Total time) * 100)
Example:
Monitoring Period: 1 year = 31,536,000 seconds
Total Object Outage Duration: 300 seconds
Object Uptime: 99.999%
Monitored Objects achieving “six nines” uptime should only be “down” for a maximum 31.5 seconds in the 365 days.
But as you get to “six nines” or higher, capabilities and configuration of monitoring tools starts to play critical role in accuracy of uptime calculations.
Single Server Example
Let’s start with an example of Uptime calculation for a single device such as a Server.
First, we need to define what constitutes a server being up or down and what tools we planning to use to determine its state.
Let assume that we use a classic ICMP v4 probing with ‘Polling Interval” equal to 1 second.
In other words, we will be sending Ping packets from a monitoring agent to the Server every 1 second and if server does not respond we shell consider it down.
Simple enough?
Well, may be in perfect world yes, but we live in real world and packets may get lost for reason other than Server being down.
Packets may get lost due to traffic shaping, CRC errors and many other reasons. So, to prevent influx of false positive Server down events we need to increase number
of consecutive packets that must be missed to consider Server to be “down” to a number greater than 1.
Let’s call this number an “Assurance Multiplier”.
Greater “Assurance Multiplier” values shell result in greater probability that we detect an actual Server down event. But at the same time greater “Assurance Multiplier” will result in slower detection time for Server down events and inability to detect short-lived outages with duration time less than (Assurance Multiplier * Polling interval) seconds.
We also need to introduce two new parameters: “Actual Outage Duration” and “Detected Outage Duration” to reflect the fact that duration of the Server outage calculated by monitoring agent may be slightly greater than actual outage of the Server due to the fact that duration of polling interval is > 0.
Summary
“Polling Interval” – Time between two consecutive state polls.
“Assurance multiplier” – Number of consecutive polling intervals when object’s state must be Down to consider monitored object to be truly down.
“Outage Detection Time” – Time is takes for monitoring Agent to detect an outage of the monitored object after outage has started.
“Actual Outage Duration” – Actual Outage Duration of the monitored object.
“Calculated Outage Duration” – Duration of the Outage as calculated by the monitored object.
Considering that Actual Outage Duration > (Polling Interval * Assurance Multiple) worst case scenarios should be calculated as following:
Outage Detection Time = (Polling Interval * Assurance Multiplier) + Polling Interval
Calculated Outage Duration = (Polling Interval * Assurance Multiplier) + 2 * Polling Interval
Lets do the math with following Monitoring Agent Configuration Example : Polling Interval = 1 Sec and Assurance Multiplier = 3
We get following results:
Outage Detection Time = 4 Seconds
Best Detectable Actual Outage > 3 Seconds
Best Calculated Outage Duration > 5 Seconds
Now we can see that provided example of Monitoring Agent configuration is sufficient for grading Server’s Uptime as 99.9999% but not sufficient for 99.99999% classification.
To classify monitoring tool for 99.99999% accuracy you need to decrease Polling Interval or decrease Assurance Multiplier by at least 30%.
So next time when you see a 99.99999% Uptime calculated by a Monitoring tool with a Polling interval of 5 minutes you know that it is likely not true.
It gets more interesting when we move into calculation of Uptime for a Network rather than a single object like Server.
Creating Hierarchical Site Structure in Nectus
Nectus News, Site Creation and Management, Technical NotesCreating Hierarchical Site Structure in Nectus
In this chapter you’ll learn how to create a Hierarchical Site Structure in Nectus and populate it with Devices. This activity is fundamental to using Nectus.
Specifically, you will learn how to:
Creating a New Site
Like everything in Nectus, creating a Site is fast and simple. Follow these instructions to get it done:
Deleting a Site
Deleting an existing Site is even easier than creating a new one. Follow these steps:
Moving a Site
You can move a Site to a new location in the existing hierarchy. This location can be at the same level in the hierarchy or at any other level. Any Site can be moved to any location within the hierarchy. Follow these instructions to move a Site:
Adding a Device to a Site
Here, we are assuming that you have already added your available Devices to the Unassigned Devices list. Follow these steps to add a Device to a Site by taking it from the Unassigned Devices pool:
Deleting a Device from a Site
Follow these steps to delete a Device from a Site by moving it back to the Unassigned Devices pool:
Moving a Device to a Different Site
Moving a Device between Sites is very similar to deleting a device. Here are the steps:
Editing Site Properties in Nectus
Nectus News, Site Creation and Management, Technical NotesEdit Site Properties
You can easily edit the properties of any existing Site. In this chapter, you’ll learn how to edit the properties of an existing Site. We’ll also discuss the functions of each editable property.
Opening the Edit Site Properties Dialog Box
It takes just a few clicks to open the Edit Site Properties dialog box for any existing Site. Follow these instructions:
Editable Properties
You can edit the following properties from the Edit Site Properties dialog box. Here is a complete explanation of each field:
Aruba Wireless Dashboard added to Nectus 1.2.30
Nectus News, Technical Notes, WirelessSupport for monitoring Aruba wireless controllers was added to most recent release of Nectus NMS. It brings visibility to most loaded wireless APs, SSIDs and controllers.
It displays basic antenna info, current AP channels, gives list of rogue APs and rogue clients and allows generation of Wireless HeatMaps over floorplans.
Cisco Wireless Dashboards
Nectus Dashboards, Nectus News, Technical Notes, WirelessAfter support for wireless devices was added in Nectus, specific monitoring dashboards were created to track any change that can affect the wireless users, controllers or access points.
The wireless dashboards are vendor specific and this is where you can find the dashboard for Cisco wireless devices:
The focus of this article is on Cisco wireless devices, this is how the Cisco wireless dashboard looks like:
Wireless dashboard has multiple sections.
One of the sections covers the controllers and can provide information about the CPU usage, how many APs are Up, Down or Downloading:
As always, you can get device details by selecting the controller:
The interesting things starts when you select the counters related to the number of APs that are up, down or in process of being associated with the controller.
You get a list of APs in that state associated with that specific controller:
To get details about an AP, it is enough to select one of the APs and a window with multiple tabs will provide various information that can help the operator to understand how that specific AP operates.
The first tab provides the name of AP assigned by the operator, the model of AP, the operating system, the IP address and some other useful information about the AP.
The next tab provides technical information about the two frequencies in which the AP operates:
In the next tab, quality of service settings are covered:
The forth tab is about the load in terms of number of clients, receive and transmit utilization for the frequencies supported:
The next tab shows the rogue APs detected:
You can also see the neighbor APs and some of their characteristics:
And the last tab shows the CDP neighbor:
Another section of the wireless dashboard is the SSID Client load which shows how many clients are on each SSID:
The wireless dashboard allows to see how many clients and on which frequency each AP has:
And the last section of the wireless dashboard is the one showing how many clients are on the two frequencies, 2.4Ghz and 5Ghz, in total and you can see some history of how many clients were at some point in time.
Nectus Cisco Wireless dashboard can provide useful information about the wireless devices, controllers and access points.
Cisco Wireless client search and tracking tools
Nectus News, Technical Notes, WirelessIn this post we will cover some new functionality added to Nectus in latest Wireless release.
The “Wireless Client Search” allows the operator to find any wireless client by its MAC, IP address or Username.
The client search is located under main menu “Tools”:
In the menu, you have an option to search for a client based on the MAC, IP or Username. You can also restrict the scope where the search will take place:
Here is how a result of a MAC search looks like. You can search using part of a MAC address as well, but you need to provide at least 3 characters (two numbers and “:” )
You can view the client details by clicking either on MAC address or IP address and the new window will show Client’s basic info like like SSID, RSSI etc.:
The second tab will show the RSSI from various APs that detects client’s signal:
If AP name is clicked, then you will get detailed information about the AP:
Next, you can search for an IP address (again, you do not have to specify full IP address):
The last option is to search using an username:
The username is shown in the client detailed information:
Coming back to the search window, there is the possibility to track a client. You actually track the MAC address of the client to see if and where the client roamed across the wireless network. One or more clients can be tracked in the same time:
You need to specify how often Nectus should check this MAC address and for how long. If you know the client goes on and off often or it moves around the wireless network, then you might want to use an aggressive timer for frequency to get accurate data about availability:
The list of the tracked clients can be seen here:
And the list is this:
A client can be added for tracking from this menu as well:
And here is how the tracking information looks like for a client:
This shows that the client did not move to another AP, so there was no or little movement of the client.
Cisco Wireless Heat Maps
Nectus News, Technical Notes, WirelessIn this post, we will cover the wireless heat maps and how they are created in Nectus.
A heat map will allow to visualize the state of the wireless coverage and help to take decision in order to improve the coverage.
Using the information from APs along with a map of physical location, you can find out where are the hot and cold spots.
A heat map is a L2 topology diagram where you can add access points and optionally the controller to which the access points are associated with.
You can add the controller and the APs from the list of controllers:
If the controller and several APs are added to the topology, it will look like this:
In the topology toolbar settings option, you must check the option to see access points in the topology:
Afterwards, the topology looks like this:
You can see which channel is used on each AP and how many clients are connected to each AP.
Ruckus Wireless Antenna info SNMP OID
SNMP Hints, Technical Notes, WirelessRuckus “Antenna Info” SNMP OIDs
===========================
Antenna Type (0 = 802.11bg, 1 = 802.11a, 2 = 802.11ng, 3 = 802.11na, 4 = 802.11ac)
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.3.[6.108.170.179.26.66.144].[0]’ => “2”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.3.[6.108.170.179.26.66.144].[1]’ => “3”
Antenna Gain (dB)
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.44.[6.108.170.179.26.66.144].[0]’ => “7”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.44.[6.108.170.179.26.66.144].[1]’ => “7”
Tx Power Level (0 = Full, 1 = Half, 2 = Quarter, 3 = Eighth)
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.5.[6.108.170.179.26.66.144].[0]’ => “0”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.5.[6.108.170.179.26.66.144].[1]’ => “0”
Channel Number
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.4.[6.108.170.179.26.66.144].[0]’ => “1”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.4.[6.108.170.179.26.66.144].[1]’ => “36”
Number Of Current Users
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.8.[6.108.170.179.26.66.144].[0]’ => “0”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.8.[6.108.170.179.26.66.144].[1]’ => “0”
Utilization (%)
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.40.[6.108.170.179.26.66.144].[0]’ => “0”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.40.[6.108.170.179.26.66.144].[1]’ => “0”
Average Client RSSI (dBm)
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.9.[6.108.170.179.26.66.144].[0]’ => “0”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.9.[6.108.170.179.26.66.144].[1]’ => “0”
Antenna MAC Address
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.1.[6.108.170.179.26.66.144].[0]’ => “lª³B”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.1.[6.108.170.179.26.66.144].[1]’ => “lª³B”
Antenna Mesh Enabled (1 – Yes, 2 = No)
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.6.[6.108.170.179.26.66.144].[0]’ => “2”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.6.[6.108.170.179.26.66.144].[1]’ => “2”
Power Management Enabled (1 = Yes, 0 = No)
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.18.[6.108.170.179.26.66.144].[0]’ => “1”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.18.[6.108.170.179.26.66.144].[1]’ => “1”
Max. Number of Clients Allowed
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.19.[6.108.170.179.26.66.144].[0]’ => “256”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.19.[6.108.170.179.26.66.144].[1]’ => “256”
Antenna Rx Packets
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.10.[6.108.170.179.26.66.144].[0]’ => “1047794”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.10.[6.108.170.179.26.66.144].[1]’ => “5447”
Antenna Rx Bytes
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.11.[6.108.170.179.26.66.144].[0]’ => “223745214”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.11.[6.108.170.179.26.66.144].[1]’ => “1050697”
Antenna Tx Packets
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.13.[6.108.170.179.26.66.144].[0]’ => “42252”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.13.[6.108.170.179.26.66.144].[1]’ => “6080”
Antenna Tx Bytes
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.14.[6.108.170.179.26.66.144].[0]’ => “8941040”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.14.[6.108.170.179.26.66.144].[1]’ => “921628”
Number of Tx Fails
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.16.[6.108.170.179.26.66.144].[0]’ => “0”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.16.[6.108.170.179.26.66.144].[1]’ => “0”
Number of Tx Retries
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.17.[6.108.170.179.26.66.144].[0]’ => “2875”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.17.[6.108.170.179.26.66.144].[1]’ => “8”
Authentication Requests
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.25.[6.108.170.179.26.66.144].[0]’ => “1”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.25.[6.108.170.179.26.66.144].[1]’ => “0”
Authentication Responses
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.26.[6.108.170.179.26.66.144].[0]’ => “1”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.26.[6.108.170.179.26.66.144].[1]’ => “0”
Authentication Success
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.27.[6.108.170.179.26.66.144].[0]’ => “1”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.27.[6.108.170.179.26.66.144].[1]’ => “0”
Authentication Failed
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.28.[6.108.170.179.26.66.144].[0]’ => “0”
‘1.3.6.1.4.1.25053.1.2.2.1.1.2.2.1.28.[6.108.170.179.26.66.144].[1]’ => “0”
Ruckus Wireless Dashboards now in Nectus
Nectus News, Technical Notes, WirelessSupport for Ruckus Wireless Controllers added to Nectus
Technical Notes, WirelessSupport for Ruckus Wireless Controllers was added to Nectus.
AP Name: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.2
AP Name: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.2
AP Model: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.4
Operation Status: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.3 (0 = Down, 1 = Up, 2,3,4 = Prep)
Connected Clients: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.15
Coverage: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.59 (1 = Indoor, 2 = Indoor-Distribute, 3 = Outdoor)
Connection mode: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.17 (0 = Layer2, 1 = Layer3)
Serial Number: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.5
Software Version: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.7
HW Version: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.8
Uptime: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.6
CPU Utilization: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.29
MAC Address: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.1
IP Address: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.10
Mask: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.100
Gateway: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.101
DNS Server 1: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.105
DNS Server 2: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.106
Max Number of Clients: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.110
Rogue Clients: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.16
Wireless Bytes Rx: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.61
Wireless Bytes Tx: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.62
LAN Bytes Rx: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.21
LAN Bytes Tx: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.25
LAN Drops: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.53
LAN Flaps: 1.3.6.1.4.1.25053.1.2.2.1.1.2.1.1.39
Wireless Heat Map Vizualization added to Nectus starting from build 1.2.24
Nectus News, Technical Notes, WirelessNectus goes wireless. Starting from version 1.2.24 we added support for Cisco Wireless.
Powerful dashboards and RSSI heatmaps now available to all Nectus customers. Download your copy of Nectus
Working with SNMP Traps in Nectus NMS
Network Monitoring, Syslog, Technical NotesOne of the key features of Nectus is ability receive SNMP traps. This allows the operator to quickly detect physical (links failures, flaps) or logical (adjacencies failures, flaps) changes in the network followed by restoration procedures or root cause analysis.
Let’s see how does it work on example of this Layer 2 diagram:
The SNMP traps are located in top menu “Logs” -> “SNMP traps and Syslog”.
More exactly here:
Once the devices starts sending SNMP traps, they appears withing 2-3 minutes in Nectus:
At the time of the writing, the new SNMP traps decoding is added manually by the Nectus support team, but in the future the operator will have the ability to add the traps decoding with no external assistance.
All these traps were sent by R1 and R2 when GigabitEthernet0/1 on R1 was shut down. Because OSPF was running between R1 and R2, disabling the interface lead to OSPF adjacency between the two routers to go down.
As you can see, some OIDs are represented their original format, whereas some OIDs are represented in a more human readable format.
The details of a trap might look like this:
With the above trap details, you can tell that this is “link down” trap.
However, with other traps, you might need additional knowledge to figure what they represent.
Let’s take another example of detailed trap:
This trap was sent by R1 and it is a neighbor state change(.1.3.6.1.2.1.14.16.2.2):
And it can be read like this: Router-ID 192.168.0.2(.1.3.6.1.2.1.14.1.1) declared neighbor 192.168.0.3(.1.3.6.1.2.1.14.10.1.3) with IP address on the interface 10.0.0.14(.1.3.6.1.2.1.14.10.1.1) as Down(.1.3.6.1.2.1.14.10.1.6 with value of 1).
Obviously this is not very intuitive and Nectus should do all the the decoding so that the operator will not go through all the effort to find what each OID means.
In the future releases user will have an option to add the decoding for new or unknown SNMP traps via GUI.
Topology mapping for SDN OpenFlow networks with Nectus
Network Topology Visualization, Technical NotesNectus can monitor OpenFlow capable devices in the same way as the non-OpenFlow devices.
In this article we will show how Nectus can discover and monitor switches that are SDN OpenFlow ready.
We will use following sample topology for demonstration with Floodlight OpenFlow controller and three OpenFlow switches: Read more
Network Engineer Toolset in Nectus NMS
Technical Notes, ToolsUnder the Tools menu, there are quite a few tools that can help the operator to understand better the network, to perform troubleshooting and to gather information from devices.
These are the options: Read more
Syslog server functionality in Nectus NMS
Syslog, Technical NotesThis post will cover the SysLog server functionality of Nectus network monitoring software.
As with any modern network monitoring software Nectus has the ability to receive and store the syslog messages from routers, switches or servers.
Syslog messages can be accessed from Top menu “Logs”: Read more
Which US city uses the most IPv4 public addresses?
Nectus News, Technical NotesNote: Information is based on Nectus IP geo-location service
Meltdown and Spectre bugs in simple words.
Technical NotesMeltdown and Spectre bugs in simple words.
All modern processors have very important feature called “Speculative Execution” where CPU tries to predict all possible operations that might be required to be executed next and actually executing those without knowing for sure which one will be the next.
Those guesses are called Speculative Branches. By the time when next operation is determined CPU already executed it as part of “Speculative Execution” but it also executed all other branches that no longer needed. Not only it executed unneeded operations it also kept the data for those branches. Data that was processed during unneeded Speculative Execution branches remains accessible for some time before it is completely discarded.
But data protection is only enforced for main execution branch, but not for Speculative Execution branches making it possible to access sensitive data that normally should not be accessible. Good intentions causes harm..
View routing tables in Nectus GUI
Technical Notes, ToolsOne of the latest features that was added this week is “Routing Table” view in device context menu. Read more