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 (https://ideas.ibm.com).
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 updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Use ENTITYID instead of MAINNODEENTITYID for BGP status polling
This RFE is based on initial observation and detailed discussion with L3 support. The L3 support finally concluded that such BGP event supression is impossible in the current design.
With the current ITNM polling design, "Interface Filter" options are supported only for ifIndex based indexes in the IP network. This means that polling is based on ifIndex for all the IP devices. For BGP policies like "bgpPeerState", poller uses the IP address of BGP session as the index, in its polling. In addition for BGP polling events the NmosEntityId is used as mainnode entity id. Where for instance as in the case of snmpInBandwidth, we can see that NmosEntityId as interface entity id. This is because MONITOREDENTITYID field in the event/alert raised by Poller gets converted as NmosEntityId field in the object server.
Here is an impact and use case:
In an environment where BGP sessions status monitoring for a device is configured via SNMP and Objectserver receives SNMP Link Down/Up traps it results in a situation where the event representing the physical failure of an interface (link down trap) does not suppress the resulting logical failures from related device – the BGP status change event. This is of course unwanted especially when one has multiple BGP sessions in core routers and would like to correlate them.
According to L3 support in order to achieve such functionality ITNM must raise the BGP polling definitions and events on ENTITYID instead of MAINNODEENTITYID.
Do not place IBM confidential, company confidential, or personal information into any field.