Simen Stavdal wrote: : 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.
I'm just going to drop this part of the thread. : 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 ... but I want to keep this in the message. : 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)? Worth submitting a feature request? : 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. Now, we've changed the scope of the problem from "SNMP" to "traffic". And you've already answered your own question. You have a piece of machinery. It's going to send traffic, to a given destination. However, this "destination" may be more than one machine. It may be two. It may be five. And the traffic may be single datagrams, or it may be a constant stream. Who knows. You don't want to update the source when this destination point changes, due to administrative overhead. So, you need an arbitrary resolution that is not protocol-specific, that provides a single point of management (or otherwise incurs a very low administrative overhead), and where the client doesn't need to be modified. Remember way above when you mentioned the word "multicast"? There's absolutely no reason why your trap destinations couldn't be a multicast address. Same with your netflow destinations. Or, heck, your SMTP destinations, if you're feeling adventurous. Granted, this is a network re-architecture, but see below before responding. -- There's two different discussions going on here, that are complicating things. 1) You're looking for a short-term fix for your problem. You've been handed a short-term fix. 2) Because you don't like the short-term fix, the conversation has shifted to looking for a long-term fix (changes to pf, network re-architectures, etc.).
