Hello again, Ok, I think we are getting closer to a resolution. I like the loopback solution (never thought of that), it should work for udp at least since it is connection-less, and it would work for my scenario and netflow alike. Then you could add multiple loopbacks to "subscribe" to different snmp traps.
Tomorrow I will test this, and I will let you know how I got on. If one were to request a new features from the OBSD developers, how would one go about it? Regarding whether or not it is the right tool to use, I agree, should be up to the developers, but I thought it would be a natural place, since it can be combined with a lot of other features, such as carp for redundancy etc, ...TBC... Russell and Damian also suggested sending traps as multicast, which I will give a try too. So long, and thanks for all the help so far ! Cheers, Simon. On Wed Nov 5 16:29 , Damian Gerow sent: Simen Stavdal wrote: : Worth submitting a feature request? : --- I looks like this would be the best solution --- Sounds like you have your desired solution. So long as the OBSD developers accept your request as valid. : --- 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 --- Right, so I was led to believe that the context of your question was limited to re-mapping SNMP destinations. In other words, you had a specific problem on hand to solve, and that SNMP trap multiplexing was that problem. : 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 --- Let's not argue over words. You need a resolution that can be applied to any number of situations. You need a resolution that is sufficiently abstracted such that it addresses the root problem, not the specific use case you supplied. This is where I went wrong, and my apologies: I addressed the specific instance of the problem, and not the underlying challenge. : --- There is a very usable syntax in place, which is also the : beauty of pf --- Whether or not it's the right tool for the job, I leave it up to the OBSD developers to decide. : --- A multicast sends traps to all listening devices, which : excludes the opportunity to filter destinations in pf --- Not entirely true. A multicast packet is destined towards a single address, for which multiple (physically separate hosts) are listening. Network gear duplicates the packet as needed, to ensure it reaches all members of that multicast group. I'm arguing semantics here, but there's a very important distinction: your SNMP client only sends out *one* packet per trap. : 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 --- Not explicitly, but you implied it with your use case. Or maybe I misread you. Either way, you've established that you don't care to fix this specific SNMP problem, you want PF to be modified to do what you need. (Speaking of which, there's Yet Another Alternative. Set your trap destination to be some arbitrary address. Assign that address to the loopback interface of *all* SNMP receivers. Assign unique IPs to their external interfaces. That way, when you use pf's dup-to, each machine will actually receive the packet. It's clean, uses the functionality that currently exists, is only a mild abuse of best practices, and requires no network reconfiguration. This approach can be duplicated as needed.) - Damian ------------------------------------------------------------------------- FC% din egen, gratis e-postadresse pC% Start.no
