Submit a ticketCall us

Have You Auto Renewed? If not, you're missing out.
The SolarWinds Renewal Program comes with a host of benefits including the most recent product updates, 24/7 technical support, virtual instructor-led training and more. Experience all of this with the convenience of Auto Renewal, and never worry about missing any of these great benefits. Learn More.

Home > Success Center > Log & Event Manager (LEM) > Cisco connector best practices

Cisco connector best practices

Table of contents
Created by Justin Rouviere, last modified by Aileen de Lara_ret on Sep 01, 2016

Views: 210 Votes: 1 Revisions: 5

Overview

Some environments use several versions of Cisco devices. Cisco has several operating systems (CatOS, NXOS, and IOS).  As a result, there are connectors to read from each of these in turn.  However, despite their differences, Cisco devices send very similar log data which can cause several issues with LEM.

 

Environment

All LEM versions   

Detail

Below you will find several issues that Cisco devices can cause when different operating systems are sent to the same Local Facility on the LEM (local0 for instance).  The Best Practice for these issues is to have separate Cisco Operating Systems write to their own local facilities.  At times it is best to move a noisy device to its own Local Facility as outlined below:

 

  • Issue One - Unmatched Data

 

Due to these being Cisco devices the data is very similar when it is logged and sent to the LEM.  It is, however, different and unique per operating system.  As a result there are three primary connectors:

 

Cisco PIX and IOS - This covers most modern devices, including ASA firewalls.

Cisco CatOS - For the older Catalyst devices.

Cisco Nexus NX-OS - Collects events from Cisco Nexus Switches (running NX-OS).

 

These connectors will read from each of the log types for the Operating System it's designed for, but due to similarities in the log data it is common to see Unmatched Data if they are all reading from the same Local Facility.  As a result the Best Practice is to have each Operating System type written to a specific log, for example:

 

Cisco PIX and IOS write to local0.

Cisco CatOS write to local1.

Cisco Nexus NX-OS write to local2.

 

The Local Facility number doesn't matter, it could be any of the 0-7 facilities, but they must each write to a separate facility.  That way Unmatched Data can be determined that it is in fact new data due to an update from Cisco's end or new data being injected into the LEM and handled appropriately from there.

 

  • Issue Two - High Throughput

 

Firewalls, specifically Cisco ASAs can log a lot of data.  ASA's can log upwards of 10 GB of data in a day.  If device(s) collectively log in excess of 10 GB in a day the syslog Local Facility can become stuck and no longer rotate daily as it is designed to do.  As a result it is best to have a noisy device such as an ASA moved to its own Local Facility to help relieve this issue.  If several GB of data is logged during the day to a Local Facility this can have performance impact on the LEM and cause several issues.  If even moving the ASA to its own syslog facility doesn't resolve the issue do the following"

     1. Open backend of the LEM by either going to the Vsphere Console or using Putty with cmc user

     2. At the cmc prompt type Appliance

     3. At the prompt type in setlogrotate change it from the default of Daily to Hourly by hitting yes

     4. This allows the LEM to compress the files hourly so if the ASA is logging 1 GB an hour it compresses it to 100 MB and now will also             store only 50 hours of RAW syslog data from the ASA instead of 50 days.

     5. To increase the 50 hour limit use the command limitsyslog and change to max of 100 which would give you 100 hours

 

A secondary option is to reduce the logging on the Cisco device, such as setting a different Trap level (changing from Debug to Informational for instance) or by eliminating unwanted events from the ASA directly.  Please seek out Cisco documentation for assistance with this process.

 

 

Note:

The Local Facility configuration is handled from the Cisco device itself.  The LEM is unable to move the data and the sending device is entirely in control of the configuration.  Once the facility is moved or changed you will want to update the Connector on the LEM so that it is reading from the new facility.

 

 

Last modified

Tags

Classifications

Public