Event Policy Framework—Use Cases

Let us learn about certain use cases of the event policy framework.
A few of the use cases of the event policy framework are discussed. Read on to understand each use case for your business requirement.
  • Business intent defined event priority
    The default priority of system generated alarms can be changed by you to priority levels defined by your business requirements.
    For example, using an event policy rule, you can change the severity of the
    BGP peer down
    critical alarm for Branch sites to be a P1 instead of the default P2.
  • Escalate priority of standing alarms
    When certain alarms are left standing for a long time, you can specify an escalation policy rule to increase the priority of the alarm.
    For example, if the
    Device Disconnected from controller alarm
    is standing for more than 24 hours there should be an escalation rule in place to alert you and to ensure that you fix this condition.
  • Suppress alarms during a maintenance window
    When you bring down a site during a scheduled maintenance window, all alarms generated during this period can be suppressed using a policy rule.
    Example, when a Data Center site goes down for scheduled maintenance, it will cause a series of alarms to be generated like
    Secure Fabric Down
    BGP peer down
    Interface down
    , etc. You can easily configure an event policy to suppress all alerts and alarms originating at this Data Center site during the time period when the maintenance window is scheduled.
  • System rules to suppress alarms during internet outage at a site
    When there is an Internet outage, a series of alarms may be generated because of VPNs going down. Since this is an expected issue, you can choose to suppress alarms until the Service Provider fixes the outage situation.
  • Escalate Priority when Core BGP peer flaps at Data Center site
    There are some scenarios where the alarms raised and cleared are in quick succession multiple times within a short time period.  However, since the condition is cleared you are blind to such an event in your network. You can now be aware of such flaps happening in the network, by creating a flap rule and a new
    Flap rate exceeded
    alarm will also be generated to alert you.
    For example, if the standard VPN to Prisma Access flapped 3 times in 1 hour, you can be alerted for all such events across all Branch sites so that they can investigate if there is an underlying provider issue or if there is something else contributing to the flapping and take corrective action before becoming a reported problem.
  • Suppress alarms during staging
    An event policy rule can be used to suppresses particular alarm codes that you may not be interested in being alerted about.
    For example, you may not care to see the
    Site Circuit Missing
    alarm across all sites, or may want to suppress BGP down alarms for particular branch sites, since the devices are still being staged.
  • Suppress alarms on unstable LTE circuit
    If you are aware of an unstable LTE circuit at a branch site, you can choose to suppress all alarms arising at the site or reduce the priority of these alarms. This allows you to only focus on unexpected issues in the network.

Recommended For You