Hi Damian/misc, I appreciate your input -I really do. Please see my comments below.
Cheers, Simon. On Wed Nov 5 14:46 , Damian Gerow sent: 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. I am not trying to escape the fact that one needs systems in place to manage large installations, I am merely looking for what *I* think would be a better way to deploy resources. As a service provider I can provide advice (and hence I posted this question in the first place to see if there was a good way to "multicast" traps to predefined destinations), but it is not in my power to manage a customers network - so this I'm afraid is out of my control - but I do agree with your point "...should *never* be a reason...". : 2) Easier to administer centrally by making profiles based on source : addresses etc. Um, sure? See above. If you have a good addressing/naming scheme, I believe so. : 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). Maybe this could be input for further development of pf? As one can think of many alternative workarounds, can one think of a reason not to implement this feature (technially or otherwise)? 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. I can think of other scenarios too, where this functionality might prove useful, for instance for netflow export which may produce a lot more output than snmp traps, and thereby adding load on the network. Preserving the source address is important to identify the source, and while you can do this in snmp traps, using the i-agent field, or a varbind, it may not be the case for other protocols. 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 ------------------------------------------------------------------------- FC% din egen, gratis e-postadresse pC% Start.no
