Not sure I understand your question exactly, I presume It is not related to the NAT - trapx topic below, but you want to know how you can verify handling of traps by SS ?
I am not aware of any SS log, which is standard enabled for trap handling. There is however a procedure which can be used to debug alertmap / eventdisp behavior. It should be documented in the event configuration manual. I have used it in rare situation in the past. I presume you know how you can verify traps, which are not certified, eg mapped on any event id in vendor / custom mib definitions , via Event view, or even put them in global collections, or export out of the DDM ? For debug of connectivity incoming traps, verify eth/agent source, OID's, varbinds, etc, I have my trapx logs, and for direct to SS traps, my SS server have a continuous SPAN to my wildpackets sniffer infrastructure in the DC, to getting deeper. Not sure it answers your question, if not explain more what you need. Regards, Erwin From: Robert Borowicz [mailto:[email protected]] Sent: vrijdag 9 december 2011 13:24 To: De Munter, Erwin Subject: Re: [spectrum] Spectrum handling traps using IP header source address not Trap PDU Agent address? Erwin, I am going to have to start parsing through the devices that send my SS traps. (a variety of Network devices but also some servers and apps as well). Is there a basic log file or technique you use to see what was parsed correctly and what was not? Or do you simply look for the Event and how it was constructed to understand how well SS parsed the trap? Thanks -Rob Borowicz Austin, Texas On 12/5/2011 12:13 PM, De Munter, Erwin wrote: Hi Dan, 1) Of course, I just listed the filter lines. I have also some "breaks" on oid or type at the start of the line, to drop some traps which are useless, and can not be disabled at the device. Then the others filter * * * * * * file /path/trapsReceived2_beforeNAT.log filter lines... filter * * * * * * file /path/trapsReceived2.log filter * * * * * * forward Spectrum_1 filter * * * * * * forward Spectrum_HA filter * * * * * * forward Spectrum_test 2) Never thought about that. But I presume trapx will always get through the whole list. Based on the trapx manual, the "break" action is not clear. Break -> and to effectively drop and suspend filter processing for them. I presume it will not stop parsing the list. For performance reasons it is really focus on the fine tuning of your configurations, eg which type of traps you enable on your devices, to decrease the number of traps/sec. As I said, I notice almost no delay in handling, or used resources when I have a trapx config with 10000 lines, and in trapx memory. If you have a very large amount of traps/se, you can increase the receive buffer in trapx (so_rcvbuf -> manual). Never changed it myself, but we limit the traps. ( No authentication traps, no link down traps from all Edge(access) switches...., disabled useless trap features,..). For 4000 hosts, I have a continuous trap rate of 1 to 5 traps per second. I know most of them coming from ESX phy hosts. Regards, Erwin From: White Dan [mailto:[email protected]] Sent: maandag 5 december 2011 16:38 To: spectrum Subject: RE:[spectrum] Spectrum handling traps using IP header source address not Trap PDU Agent address? Hi Erwin, and Everyone, Many thanks, Erwin, for your helpful and detailed answer (and also for kindly sharing your CLI mechanism for automatically generating a trapx config file from the Spectrum SSdb - looks great!). I was pleased to hear your experience that your TrapExploders can cope with possibly 1000s of filter lines in their .cf config file. I do have a couple of extra questions - (This thread is turning into a TrapExploder topic!...) (1) I believed that a 'filter.... nat xxxx' would need to be supplemented with another filter...action line to actually forward the trap, as the nat action just does the NAT'ing change and nothing else. (A comment that's in the default trapexploder.cf file says "Note that this action only does the address conversion."). So do you have a line like: filter * * * * * * forward spectroserveraddress near the end of your .cf to make sure the NAT'ed traps actually do get sent on to your Spectrum server(s)! ? (2) For performance reasons, is it not a good idea to prevent TrapExploder from needing to work its way down through the whole list of possible source addresses?... so maybe something like the following entries for each device?... filter * "207\.209\.133\.62$" * * * * nat 207.209.133.62 filter * "207\.209\.133\.62$" * * * * forward spectroserveraddress filter * "207\.209\.133\.62$" * * * * break ...Although I now realise this would actually make the file 3 times as long, too!. Had no answer yet (nor from Support) re handling of SNMPv3 informrequests. Anyone know? Many thanks again, Cheers Dan. Dan White Senior Consultant Service Assurance [Devoteam] Tel. : +44 (0)20 7288 2822 [email protected]<mailto:[email protected]> [http://www.devoteam.com/images/environment.gif]Please consider the environment - do you really need to print this email ? * --To unsubscribe from spectrum, send email to [email protected]<mailto:[email protected]> with the body: unsubscribe spectrum [email protected]<mailto:[email protected]> * --To unsubscribe from spectrum, send email to [email protected]<mailto:[email protected]> with the body: unsubscribe spectrum [email protected]<mailto:[email protected]> --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
<<inline: image001.png>>
<<inline: image002.gif>>
![http://www.devoteam.com/images/environment.gif]Please](http://www.devoteam.com/images/environment.gif]Please){kind=link}