Description

In the current implement of Junos, there is a throttling mechanism, which limits the number of OSPF SNMP traps being send out in the a fixed period of time for the same OSPF instance. With this implementation, the following scenarios can be considered as expected Junos behavior:

  • Limited OSPF SNMP trapping sending out on the same event:

    For example:

    a physical interface configures with multiple sub-interfaces and these sub-interfaces are in the same OSPF instance. If the physical interface link goes down, some of the sub-interface's OSPF traps may not be recorded to SNMP.

  • Missing OSPF SNMP trapping on different events:

    For example:

    When multiple ospfTxRetransmit traps for the same OSPF instance are sent out in the same time interval, certain OSPF traps may not be recorded to SNMP.

  • OspfNbrStateChange consecutively recorded the same state:

    According to the definition, The OspfNbrStateChange trap is reported only when there is a change in the state of a non- virtual OSPF neighbor. OspfNbrStateChange should not consecutively record the same event:

For example:

for the same OSPF neighbor, the OspfNbrStatechange trap consecutively recorded the ospfNbrState field as Full State (8) or Down (1).

Symptoms

In the current Junos implementation:

  • After the first OSPF trap is sent out, a maximum of 5 additional traps in a window of 5 seconds (per OSPF instance) will be recorded to SNMP (a total of 6 traps in 5 seconds).
  • After the first 6 traps, subsequent OSPF traps for the same OSPF instance will not forward to SNMP, until the 5-seconds timer expires. 
  • There are no logs recorded in syslog, SNMP traceoption, or OSPF traceoption for the traps that get suppressed by the throttling mechanism.

Solution

Why did the Junos OS choose this behavior?

As per RFC1850 , section 4.4, the recommendation for Throttling Traps is to have 7 traps with a window time of 10 seconds:

"4.4. Throttling Traps

The mechanism for throttling the traps is similar to the mechanism explained in RFC 1224 [11], section 5. The basic idea is that there is a sliding window in seconds and an upper bound on the number of traps that may be generated within this window. Unlike RFC 1224, traps are not sent to inform the network manager that the throttling
mechanism has kicked in.

A single window should be used to throttle all OSPF traps types except for the ospfLsdbOverflow and the ospfLsdbApproachingOverflow trap which should not be throttled. For example, if the window time is 3, the upper bound is 3 and the events that would cause trap types 1,3,5 and 7 occur within a 3 second period, the type 7 trap should not be generated.

Appropriate values are 7 traps with a window time of 10 seconds. "

If you notice missing OSPF traps in the network, perform the following procedure:

  1. Identify which OSPF trap is missing, how often it is missing, and the first time it occurred.
  2. Enable both OSPF and SNMP traceoption with flag all. 
  3. Confirm that OSPF traceoption recorded the event.
  4. Review the SNMP traceoption and counts the number of OSPF traps, which occurred within the previous 5 seconds, prior to the missing OSPF trap.

To confirm the results, contact JTAC.

Related Information