Simen Stavdal wrote: : 1) Less configuration on the devices (and also less load, though not a : big problem anymore). This is not really a problem for small : installations, but once you have 500+ devices to configure, it is easy : to do the maths.
You should always have systems in place to manage your installation. Larger installations require more effort in getting those systems in place. There are umpteen options available at your fingertips with little to no effort, and there's another umpteen products -- both free and paid -- that will help you do this as well. This should *never* be a reason for doing (or not doing, as the case may be) something. And I'm speaking as someone with experience handling large installations. : 2) Easier to administer centrally by making profiles based on source : addresses etc. Um, sure? See above. : 3) Maintaining the source address in the trap udp header. : I have looked at "trap exploders" (my guess is that you are referring : to CA's trap exploder?), but a lot of these store and forward the : traps, thereby issuing new packets with a source address of the trap : exploder. Perhaps Claers idea of proxying with net-snmp is a way to do : it (but I have a feeling this might be store and forward too... I'll : check it out though. No, I wasn't explicitly referring to CA's Trap Exploder, or I would have capitalized it. It's just what we call them in my place of employ. I'll admit that the source issue is a valid one, and one we struggled with (with our internally developed trap exploder). However, if you *really* want to maintain source address, I'd argue that the proper way to do it is have the source send multiple traps. As a workaround, you can try to coax your trap exploder (or proxy or forwarder or whatever you want to call it) to add the original source IP as a varbind, and then configure your NMSs to replace the source with the contents of that varbind. (Alternatively, Net-SNMP can pass the trap on to an external script. From there, the possibilities are endless.) - Damian
