DX Spectrum is not handling snmp traps on all server interfaces

[Rui castro]

Hello Community,

 

I have a SS with two nics, one for frontend (FE) and the other one for backend (BackEnd) communications. I need to receive and process SNMP traps from one source placed on FE network and other placed on the BackEnd network. For this purpose,  We have created two EvendAdmin Models one with the Source FE ip address and the other one with the Source BackEnd ip address.

The snmp traps received by the FE interface are being processes and assert on the right EvendAdmin model, but the snmp traps received by the backend interface are not being processed by the SS! With tcpdump utility, we can see both FE and BackEnd traps arriving to the box.

The snmp deamon initiated by the SS is running to listen on any server interface (udp        0      0 0.0.0.0:162             0.0.0.0:*                           -                    off (0.00/0/0)) and we sent both FE and BackEnd snmptraps with same configuration.

 
Does anyone have any idea about what could be happening?

Thank you in advanced

[Catalin Farcasanu]

Why would you create 2 EventAdmin models for this? AFAIK it should work, by default, no EventAdmin being created. SS listens for traps on all addresses it gets from the OS, unless asked for listening on specific address. 

What you should see is if the VNM is configured to process traps from unknown sources, under VNM->Trap Management. This could result in not processed traps.

EventAdmin requires specific trap definition/configuration in order for correct processing of alarms and forwarding to correct existing model or newly created EventModels. I'm assuming that everything is correctly configured on the SBGW side, because you say that some traps are sent to correct models.

EventAdmin is a SouthBoundGateway integration configuration that is described in the documentation. If the traps are not in required format and should be used for integrating 3rd party NMSs into the system or by managing elements without any management capabilities.

------------------------------
Cătălin Fărcășanu
Senior Consultant
SolvIT Networks
------------------------------

[Rui castro]

Hello Fărcășanu,

 

Thank you very much for your answer.

 

I'm sending exactly the same snmp trap from both sources (FE and BackEnd).

Example:  snmptrap -v 1 -c public FE ip address  .1.3.6.1.4.1.2789.2500 "" 6 3003 "" .1.3.6.1.4.1.2789.2500.3003.1 s "TEST" .1.3.6.1.4.1.2789.2500.3003.2 s "1.1.1.1" .1.3.6.1.4.1.2789.2500.3003.3 s "Up" .1.3.6.1.4.1.2789.2500.3003.4 s "TEST" .1.3.6.1.4.1.2789.2500.3003.5 s "TEST.1234"

I can see the event inside the Eventadmin for the snmp trap sent from FE but not in the EventAdmin configured to receive snmp traps for the Backend Source


snmptrap -v 1 -c public "Backend ip address"  .1.3.6.1.4.1.2789.2500 "" 6 3003 "" .1.3.6.1.4.1.2789.2500.3003.1 s "TEST" .1.3.6.1.4.1.2789.2500.3003.2 s "1.1.1.1" .1.3.6.1.4.1.2789.2500.3003.3 s "Up" .1.3.6.1.4.1.2789.2500.3003.4 s "TEST" .1.3.6.1.4.1.2789.2500.3003.5 s "TEST.1234"

[Glenn Weavind]

Just to be clear, both set of traps are already mapped to Events (usually using MIB tools)?  You don't have traps that are, as yet, unmapped to Events being received and then disappearing (although you might find evidence of them in VNM.out).?
SS always used to show unrecognised traps against the VNM, or, if an EventAdmin model had been created for the trap source, then against the EventAdmin model - but I hear that Engineering have changed this and now, any unrecognised traps are discarded, apparently silently, once EventAdmin model(s) exist in the landscape.  Not sure if that's *any* EventAdmin model, or just one that matches the trap source.
Apparently it's caused some difficulties for Support as it's not documented (yet) and wasn't communicated effectively.  Major change in product behaviour.

[Rui castro]

Hello Glenn,

 Thank you very much for your answer.

 We are sending a generic snmp trap, and we have created a new event 0xfff000cc  

 
{d "%w- %d %m-, %Y - %T"} - A "SSAlarmTrap" event has occurred, from {t} device, named {m}.

 

SSForwardTrap Alarm

 

MNAME = {S 101}

ADDR =  {S 102}

STATUS = {S 103}

ALARMTITLE = {S 104}

ALARMDESC = {S 105}

 

 I don't understand the reason why we have different behaviors when the snmp trap is sent from a source in the FE and when the snmp trap is sent from a source in the BackEnd. The snmp trap sent is exactly the same, we only change the SS ip address.

 

Snmp trap sent from the FE:

 snmptrap -v 1 -c public  "SS FE ip address"  .1.3.6.1.4.1.2789.2500 "" 6 3003 "" .1.3.6.1.4.1.2789.2500.3003.1 s "TEST" .1.3.6.1.4.1.2789.2500.3003.2 s "1.1.1.1" .1.3.6.1.4.1.2789.2500.3003.3 s "Up" .1.3.6.1.4.1.2789.2500.3003.4 s "TEST" .1.3.6.1.4.1.2789.2500.3003.5 s "TEST.123"

 

Snmp trap sent from the BackEnd:

 snmptrap -v 1 -c public  "SS Backend ip address"  .1.3.6.1.4.1.2789.2500 "" 6 3003 "" .1.3.6.1.4.1.2789.2500.3003.1 s "TEST" .1.3.6.1.4.1.2789.2500.3003.2 s "1.1.1.1" .1.3.6.1.4.1.2789.2500.3003.3 s "Up" .1.3.6.1.4.1.2789.2500.3003.4 s "TEST" .1.3.6.1.4.1.2789.2500.3003.5 s "TEST.123"

FE EvendAdmin

Backend EvendAdmin

[Catalin Farcasanu]

I think you're sending to the same model, you should be seeing it for the same model. EventAdmin identifies the element by a combination of 6 varbinds. If you just keep the same varbinds an variate the source of the traps, the event should reach the same EventModel, based again on the code obtained by those 6 varbinds. The system is described in the documentation.

------------------------------
Cătălin Fărcășanu
Senior Consultant
SolvIT Networks
------------------------------

[Rui castro]

We are sending the traps from distinct sources and for different models.

[Catalin Farcasanu]

And I think you don't have the correct behavior on any of the interfaces. You have some EventModels created automatically by the system, if you don't send the event/traps over to existing models, again identified by the 6 OIDs. In the case you're not using generic EventModels, the SBGW should be configured to use only targetAddress IP address as identifier.

------------------------------
Cătălin Fărcășanu
Senior Consultant
SolvIT Networks
------------------------------

[Rui castro]

The device A is sending events (snmp traps) to the correct EventAdmin (both have the same ip address). For example the device A have de ip 172.25.0.15 and the EventAdmin A was created with the same ip address. 

The device B is sending events (snmp traps) to a different EventAdmin  (ex: 10.251.212.12). Due the network limitations the snmp traps from device A is arriving on SS in one nic and the snmp traps for device B is arriving on the same SS on a different nic.

SS is processing snmp traps from the Model/EventAdmin A but not the the device/EventAdmin B.

It seems more a SS issue, despite SS listening for snmp traps on all interfaces

[Mukunda Naresh]

Hi All, 

Basically SpectroSERVER listens on all the system interfaces for 162 port for trap processing which was happening on the customer problematic SS landscape. After WebEx with the customer figured out that there was NO proper routing from MLS landscape to the problematic SS landscape and aslo the agent address field was not correct.  Customer added the proper routing information to their boxes and added the agent address to the traps after that events were asserted on the specified event admin models.

Regards
Mukund

[Letha Pickle]

Hello Broadcom,

It sounds like the issue with DX Spectrum not handling SNMP traps on all server interfaces is quite specific. Have you tried adjusting the configurations for the EventAdmin Models to ensure they're correctly set up for receiving SNMP traps from both the FE and BackEnd networks? Maybe checking if there are any filters or settings that could be causing the problem might help. On a different note, if you're into tweaking apps for extra features, you might find it interesting to explore apps like Spotify Vanced APK for enhanced music streaming experiences.

Best of Luck!

[Letha Pickle]

Great Opinion & Very Thanks for Sharing with us!!