Hi Damian, Nothing like a fiery discussion :)
On Wed Nov 5 15:39 , Damian Gerow sent: 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 looks like this would be the best solution --- : 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. --- The subject of my posting is "Duplicating incoming packets to multiple destinations using pf --- --- And I never initially asked a closed question, but I did state a scenario --- 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. --- I wouldn't describe the scenario as arbitrary --- --- There is a very usable syntax in place, which is also the beauty of pf --- --- For example, *if* what I am looking for had existed it would apply to any protocol --- --- Because it doesn't care about the payload, only the headers --- --- Since both Netflow and snmp traps use UDP, I don't see why it shouldn't work --- 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. --- A multicast sends traps to all listening devices, which excludes the opportunity to --- --- filter destinations in pf --- 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. --- I didn't say I was looking for 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.). --- Please see the subject of my message --- --- Now, I don't know the answer to what I am looking for, that is why I am asking --- Cheers, Simon. ------------------------------------------------------------------------- FC% din egen, gratis e-postadresse pC% Start.no
