BGP Monitoring: Alarm not raised for customer circuit peering loss

Products

• Network Observability
• Spectrum

Issue/Introduction

BGP monitoring fails to raise an alarm when customer circuits lose peering connections because the BGP manager does not examine specific trap types for connection problems.

SYMPTOMS:

• No alarm raised when customer circuits lose peering.

• Device status shows idle/connect but no trap indicates the transition from established to idle.

• BGP manager does not examine jnxBGP flavor traps for peering connection problems.

• Missing established trap (6) from MIB 2 Backward transition (event 220011).

CONTEXT: Occurs during BGP peering status changes where specific vendor traps (jnxBGP) are sent instead of the expected MIB2 transitions.

Cause

IMPACT: Network Operations Center (NOC) and network teams are not alerted to circuit failures, leading to "blame the tool" scenarios.

Resolution

Resolution:

STEPS:

1. LOCATE BGP ATTRIBUTE: Access the BGP Manager configuration within Spectrum to identify the handling of incoming traps.

2. ENABLE ALARM_ON_TRAP: Set the alarm_on_trap attribute to "TRUE" to ensure vendor-specific BGP traps trigger alarm generation.

        Path: OneClick > Attributes Tab > Filter for "alarm_on_trap"

   NOTE: This ensures that even if the trap does not match the MIB2 flavor, an alarm is still raised.

3. VALIDATE TRAP MAPPING: Ensure event 220011 is correctly mapped to the backward transition logic.

   EXPECTED: The BGP Manager processes the jnxBGP trap as an established or idle transition.