In recent years, the concepts of Artificial Intelligence (AI) and Machine Learning (ML)...
1.2.14 Notifications and Events
IRP produces a huge number of various events and some of them are critical for customer’s awareness. Notifications allow customers to subscribe to any of the available events using the following channels:
- SMS
- Slack (via Webhook)
- SNMP Traps
IRP service Irppushd provides this feature. In order for Notifications to be delivered correctly the corresponding channel configuration shall be provided. By default only email notifications can be delivered since IRP uses the embedded system email service to send them.
More so,users should subscribe for specific events.
Only events for valid subscriptions using correctly configured channels will be delivered.Refer section SNMP hosts configuration for details about configuring, subscribing and contents of notifications.
Refer section Notification and events for details about individual configuration parameter.
Events #
The list of events monitored by IRP that can generate notifications is provided below.
When one of the IRP components detects a transition form normal to abnormal traffic behavior or back it fires these events:
-
Abnormal correction: irpflowd
-
Abnormal correction: irpspand
-
Inbound traffic low: SPAN
-
Inbound traffic low: Flow
-
Inbound traffic normal: Flow
-
Inbound traffic normal: SPAN
-
Outbound traffic low: SPAN
-
Outbound traffic low: Flow
-
Outbound traffic normal: Flow
-
Outbound traffic normal: SPAN
When Commit Control limits are exceeded per provider or overall one of the following events fires. Refer Notification and events for configuring the actual limits of the events.
-
Commit Control overload by X Mbps
-
Commit Control overload by X%
-
Commit Control provider X overloaded by Y Mbps
-
Commit Control provider X overloaded by Y%
When an IRP component (re)loads the configuration it validates it and depending on results fires one of the following events:
-
Configuration Invalid: Bgpd
-
Configuration Invalid: Core
-
Configuration Invalid: Explorer
-
Configuration Invalid: Irpapid
-
Configuration Invalid: Irpflowd
-
Configuration Invalid: Irpspand
-
Configuration Ok: Bgpd
-
Configuration Ok: Core
-
Configuration Ok: Explorer
-
Configuration Ok: Irpapid
-
Configuration Ok: Irpflowd
-
Configuration Ok: Irpspand
Outage detection algorithm fires one of the following events when it confirms congestion or outage problems and reroutes traffic around it:
-
Congestion or Outage
-
Outage: Confirmed and rerouted
Explorer periodically checks the PBRs and its expected probing performance and triggers the following events:
-
Failed PBR (IPv6) check for provider
-
Failed PBR (IPv4) check for provider
-
Successful PBR (IPv4) check for provider
-
Successful PBR (IPv6) check for provider
-
Explorer performance low
-
High number of VIP prefixes degrades IRP performance
IRP BGP Internal and External monitors fire the following events:
-
ExternalMonitor (IPv4) Failed status for a provider. All improvements towards the provider will be withdrawn.
-
ExternalMonitor (IPv4) OK status for a provider. All improvements towards the provider will be announced.
-
ExternalMonitor (IPv6) Failed status for a provider. All improvements towards the provider will be withdrawn.
-
ExternalMonitor (IPv6) OK status for a provider. All improvements towards the provider will be announced.
-
InternalMonitor (IPv4) Failed status for a provider. All improvements towards the provider will be withdrawn.
-
InternalMonitor (IPv4) OK status for a provider. All improvements towards the provider will be announced.
-
InternalMonitor (IPv6) Failed status for a provider. All improvements towards the provider will be withdrawn.
-
InternalMonitor (IPv6) OK status for a provider. All improvements towards the provider will be announced.
When statistics collection over SNMP is up or down IRP fires the following events:
-
Provider SNMP stats down: X
-
Provider SNMP stats up: X
Bgpd raises these events when BGP sessions are established/disconnected:
-
IRP BGP session disconnected
-
IRP BGP session established
When IRP identifies conditions to re-route traffic (make an improvement) and additionally it considers the differences to be excessive it raises these events:
-
Excessive packet latency for prefix
-
Excessive packet loss for prefix
-
Improvements spike
-
Low rate of announced IPv4 improvements
-
Low rate of announced IPv6 improvements
-
New improvement
Once an IRP component is started, stopped or restarted it raises the following events:
-
Service started: Bgpd
-
Service started: Core
-
Service started: Explorer
-
Service started: Irpapid
-
Service started: Irpflowd
-
Service started: Irpspand
-
Service stopped: Bgpd
-
Service stopped: Core
-
Service stopped: Explorer
-
Service stopped: Irpapid
-
Service stopped: Irpflowd
-
Service stopped: Irpspand
SNMP Traps #
SNMP traps is a widely used mechanism to alert about and monitor a system’s activity.
IRP SNMP traps not only notify about some IRP platform event but also include the list of varbinds which contain detailed information related to the thrown trap. The complete list of traps and varbinds with their descriptions can be found at /usr/share/doc/irp/NOCTION-IRP.mib