Syslog server functionality in Nectus NMS

This 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”:

The first tab of the menu shows actual syslog messages received from the devices configured to send their syslog to a remote server.

You have the ability to search through all the logs by specifying a string pattern from the hostname field or from the message text itself. The color coded severity of each message is displayed as well.
You can group the messages by severity so you can see first the more critical messages, like in this case where you would like to see first the messages indicating a link went down:

You can acknowledge the messages:

Also, by clicking the message text, you can get the entire log as it was received from the device:

There is an option to filter out Syslog messages based on the source (the IP address of the device sending the syslog message) or based on specific keyword. This is called blacklisting.
To avoid receiving the messages from specific device you  can add sender’s IP address to Blacklist.

You only need to specify the IP address of the host:

For testing purposes, GigabitEthernet0/1 from R2 was shutdown, triggering various syslog messages(like interface going down, OSPF adjacency with R1 going down and various BGP sessions going down as well):

R2(config-if)#shut
R2(config-if)#
*Jan 25 09:39:03.392: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Jan 25 09:39:05.368: %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down
*Jan 25 09:39:06.368: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
*Jan 25 09:41:41.814: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.1 4/0 (hold time expired) 0 bytes
*Jan 25 09:41:41.814: %BGP-5-NBR_RESET: Neighbor 192.168.0.1 reset (BGP Notification sent)
*Jan 25 09:41:41.820: %BGP-5-ADJCHANGE: neighbor 192.168.0.1 Down BGP Notification sent
*Jan 25 09:41:41.820: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.1 IPv4 Unicast topology base removed from session BGP Notification sent
R2(config-if)#

In the same time, on R1 these are the logs that are sent to the syslog server:

R1(config)#
*Jan 25 09:39:39.153: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.2 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jan 25 09:41:17.494: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.3 4/0 (hold time expired) 0 bytes
*Jan 25 09:41:17.494: %BGP-5-NBR_RESET: Neighbor 192.168.0.3 reset (BGP Notification sent)
*Jan 25 09:41:17.494: %BGP-5-ADJCHANGE: neighbor 192.168.0.3 Down BGP Notification sent
*Jan 25 09:41:17.494: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.3 IPv4 Unicast topology base removed from session BGP Notification sent

Now, going back to the Nectus syslog tab, we should not see any message from R2 with this timestamp (see how searching used the hostname of R2):

But we should see messages from R1:

You can filter out even more to discard specific messages from specific sources.
For this, keyword blacklisting is required:

For testing purposes, no OSPF messages will be processed by Nectus:

So in this moment, there are two blacklisting parameters set. Sender IP(R2) and keyword (OSPF-5-ADJCHG). So what will take precedence?
This can be read like this: if any message is matched by the keyword, then discard that message and if the source is matching the sender, then discard all the messages from that sender.
With this in place, let’s see what is happening when GigabitEthernet0/1 from R2 is shutdown again.
This is from R2:

R2(config-if)#
*Jan 25 09:57:34.058: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Jan 25 09:57:36.033: %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down
*Jan 25 09:57:37.033: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
*Jan 25 09:59:52.373: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.1 4/0 (hold time expired) 0 bytes
*Jan 25 09:59:52.373: %BGP-5-NBR_RESET: Neighbor 192.168.0.1 reset (BGP Notification sent)
*Jan 25 09:59:52.374: %BGP-5-ADJCHANGE: neighbor 192.168.0.1 Down BGP Notification sent
*Jan 25 09:59:52.374: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.1 IPv4 Unicast topology base removed from session BGP Notification sent
R2(config-if)#

And this is from R1:

R1#
*Jan 25 09:58:13.962: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.2 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jan 25 09:59:50.581: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.3 4/0 (hold time expired) 0 bytes
*Jan 25 09:59:50.581: %BGP-5-NBR_RESET: Neighbor 192.168.0.3 reset (BGP Notification sent)
*Jan 25 09:59:50.581: %BGP-5-ADJCHANGE: neighbor 192.168.0.3 Down BGP Notification sent
*Jan 25 09:59:50.581: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.3 IPv4 Unicast topology base removed from session BGP Notification sent
*Jan 25 09:59:51.605: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.4 4/0 (hold time expired) 0 bytes
*Jan 25 09:59:51.605: %BGP-5-NBR_RESET: Neighbor 192.168.0.4 reset (BGP Notification sent)
*Jan 25 09:59:51.606: %BGP-5-ADJCHANGE: neighbor 192.168.0.4 Down BGP Notification sent
*Jan 25 09:59:51.606: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.4 IPv4 Unicast topology base removed from session BGP Notification sent
*Jan 25 09:59:58.773: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.2 4/0 (hold time expired) 0 bytes
*Jan 25 09:59:58.773: %BGP-5-NBR_RESET: Neighbor 192.168.0.2 reset (BGP Notification sent)
*Jan 25 09:59:58.774: %BGP-5-ADJCHANGE: neighbor 192.168.0.2 Down BGP Notification sent
*Jan 25 09:59:58.775: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.2 IPv4 Unicast topology base removed from session BGP Notification sent

Observe that on both of them OSPF adjacency messages are seen.
Now, let’s see what Nectus5 is showing.
These should not be any OSPF messages coming from R1 (although this is not shown here, there are no OSPF messages from any of the devices from the topology):

And as expected, there are no messages at all from R2:

You have the ability to control what messages are received and from which source, to group the messages by on severity and even export the messages to a third party application.