Skip to Main Content
Cloud Management and AIOps

This is an IBM Automation portal for Cloud Management and AIOps products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Workspace SevOne
Created by Guest
Created on Jan 31, 2024

alerting on the dreaded "broadcast storm" scenario

as I am aware SevOne does not have a preferred way to alert on the  dreaded "broadcast storm" scenario.  This is how I have it configured within my deployment:

Currently I monitor on broadcast storms in the following manner:

-broadcast storm occurs on a single port o a Juniper ex3300 switch.

- the Juniper switch generated a SNMP trap which is then sent to SevOne (this is hard coded in the config)

- SevOne takes the incoming SNMPV3 trap and pass's it thru to the "Trap Event Editor"

- Within the  "Trap Event Editor" the unique OID is denoted for the switch fabric that set off the alert under general and the trigger is hard coding with the following items:

General: JUNIPER-CHASSIS-DEFINES-MIB::jnxProductNameEX3300

Trigger: JUNIPER-SYSLOG-MIB::jnxSyslogTrap

- from here an email is generated and sent to the network team.

That email consists of the following:


Trap received from $dev: $oid -- Bindings: $var

The combined broadcast, multicast and unknown unicast frames received on this port has reached the pre-configured storm control threshold of 1 Mbps. If the user on this port is using IP Multicast to send a traffic stream to receivers then storm control needs to be temporarily disabled on this port for the remainder of the day.

Below are the relevant commands for storm control.

// show if port is error disable
show ethernet-switching interfaces

// re-enable port
clear ethernet-switching port-error interface ge-0/0/0

// show log message to see date/time of port shutdown show log messages | last

** Traffic Statistic Commands **

// clear statistics on port
clear interface statistics ge-0/0/0

// show bandwidth usage in bps
show interface ge-0/0/0

// show traffic statistics (number of broadcast and multicast frames) show interface ge-0/0/0 extensive


Can this be done in an easier way for end users?

If this be added into the NMS as a default feature that is much easer to setup and monitor? It may be be useful to others.

Idea priority Medium