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:dan.wh...@devoteam.com] 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 dan.wh...@devoteam.com<mailto:dan.wh...@devoteam.com> [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 lists...@unc.edu<mailto:lists...@unc.edu> with the body: unsubscribe spectrum erwin.de_mun...@atos.net<mailto:erwin.de_mun...@atos.net> --- To unsubscribe from spectrum, send email to lists...@unc.edu with the body: unsubscribe spectrum arch...@mail-archive.com
<<inline: image001.png>>
<<inline: image002.gif>>
![http://www.devoteam.com/images/environment.gif]Please](http://www.devoteam.com/images/environment.gif]Please){kind=link}