cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10889
Views
0
Helpful
8
Replies

IP SLA events will not show up in the router logs

west33637
Level 1
Level 1

Hello all. I have a Cisco 7609 and am running IOS version 12.2(33)SRC4. I have an IP SLA instance configured for ICMPECHO with a remote device. Everything works fine and the sh ip sla statistics shows that the SLA instance is active and working as designed.

I am also able to simulate an outage and see the debug trace output.

My question is why can I not get the IP SLA events to show up in the logs? Whenever I simulate an outage, I do not see any IP SLA events in the logs. What am I doing wrong?

I have configured the following

ip sla monitor logging traps

snmp-server enable traps syslog

1 Accepted Solution

Accepted Solutions

It doesn't look like you've configured a reaction trigger.  Add the following:

ip sla reaction-configuration 1 react timeout action-type trapOnly threshold-type immediate

Then repeat the timeout, and see if you see syslog messages.

View solution in original post

8 Replies 8

yjdabear
VIP Alumni
VIP Alumni

http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsthresh.html

"The ip sla monitor logging traps command is used to enable the generation of these IP SLAs specific traps. The generation of IP SLAs specific logging messages is dependant on the configuration of the standard set of logging commands (for example, logging on). IP SLAs logging messages are generated at the "informational" system logging severity level. "

http://www.cisco.com/en/US/docs/ios/12_3/configfun/command/reference/cfr_1g11.html#wp1031027

"To enable the sending of system logging message Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps syslog command in global configuration mode. To disable system logging message SNMP notifications, use the no form of this command.

snmp-server enable traps syslog

no snmp-server enable traps syslog"

So the two lines you configured are actually generating SNMP traps rather than syslogs.

As far as why you're not seeing IP SLA events in the "logs" (syslog), the first quote above notes that it depends on how you've configured the logging level. Post the output of "show run | include logging" will help zero in on what's going there. Specifically, how's "logging buffered" configured?

the IOS that Im running (12.2(33)SRC4) does not have the monitor part of the command - ip sla monitor logging traps.  I will send you my logging commands first thing tomorrow morning. I can already tell you though that its configured for logging buffered debugging.

I do see the debug ip sla trace output in the logs whenever I simulate an outage, but when debugging is turned off I do not see any informational logs related to IP SLA. I do however see other informational logs like OSPF adjacency changes and such.

I will send you the show run | inc logging first thing in the morning. Thanks,

Do you have any reaction configuration?  You will need to define some kind of reaction trigger in order to see logging events when a collector fails (e.g. a timeout).  It would be helpful to see your entire IP SLA configuration.

LAB#sh run | inc logging
no logging console
ip sla logging traps
logging trap debugging
logging synchronous

When I simulate an outage on the other end, heres what the logs show. you can see that no IP SLA events are contained in the logs, BGP events and OSPF only.

LAB#sh log  
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.


    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged, xml disabled,
                     filtering disabled
    Buffer logging:  level debugging, 698 messages logged, xml disabled,
                    filtering disabled
    Exception Logging: size (4096 bytes)
    Count and timestamp logging messages: disabled
    Persistent logging: disabled

No active filter modules.

    Trap logging: level debugging, 454648 message lines logged
         
Log Buffer (8192 bytes):

Apr 30 10:28:43.229: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet1/27 from FULL to DOWN, Neighbor Down: BFD node down
Apr 30 10:28:43.545: %OSPFv3-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet1/27 from FULL to DOWN, Neighbor Down: Interface down or detached
Apr 30 10:28:49.041: %BGP-3-NOTIFICATION: received from neighbor 2001:470:E092:100::3 4/0 (hold time expired) 0 bytes
Apr 30 10:28:49.041: %BGP-5-ADJCHANGE: neighbor 2001:470:E092:100::3 Down BGP protocol initialization
Apr 30 10:28:49.041: %BGP_SESSION-5-ADJCHANGE: neighbor 2001:470:E092:100::3 IPv6 Unicast topology base removed from session  Unknown path error
Apr 30 10:28:49.753: %BGP-5-ADJCHANGE: neighbor 2001:470:E092:100::3 Up
Apr 30 10:28:58.709: %OSPFv3-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet1/27 from LOADING to FULL, Loading Done

The frequency was configured for 2 seconds, the timeout value is configured for 1700 ms.

LAB#sh ip sla configuration 1
IP SLAs, Infrastructure Engine-II.

Entry number: 1
Owner:
Tag:
Type of operation to perform: echo
Target address/Source address: 10.96.2.2/10.96.2.1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 1700
Verify data: No
Vrf Name:
Schedule:
    Operation frequency (seconds): 2
    Next Scheduled Start Time: Start Time already passed
    Group Scheduled : FALSE
    Randomly Scheduled : FALSE
    Life (seconds): Forever
    Entry Ageout (seconds): never
    Recurring (Starting Everyday): FALSE
    Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
    Number of statistic hours kept: 2
    Number of statistic distribution buckets kept: 1
    Statistic distribution interval (milliseconds): 20
History Statistics:
    Number of history Lives kept: 0
    Number of history Buckets kept: 15
    History Filter Type: None
Enhanced History:

It doesn't look like you've configured a reaction trigger.  Add the following:

ip sla reaction-configuration 1 react timeout action-type trapOnly threshold-type immediate

Then repeat the timeout, and see if you see syslog messages.

Hello. Please see attached the sh run | inc logging output and the show log after I triggered an event from the remote end. You will see that the OSPF and BGP adjacency alerts show up in the logs, but nothing on IP SLA.

What about the full IP SLA configuration?  What reaction configurations do you have in place?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: