Ok,
Here are the first results....
I have set up loopback addresses with the same ip address on two
receivers (for testing). (A.A.A.10)
Each receiver has unique external ip adresses in the same subnet as the
$nms_if
First, I created this rule :
pass in on $int_if dup-to ( $nms_if $nms_broadcastaddress ) proto udp
from 10.10.10.1 to $receiverloopbackaddress port 162
# I have tried to make the macros self-explanatory, so I won't include
their definitions here.
The rule gets accepted, and expands to :
pass in quick on bge1 dup-to (vlan4 A.A.A.15) inet proto udp from
10.10.10.1 to A.A.A.10 port = snmp-trap keep state
# The subnet is /28, hence the broadcast is .15 on network 0.
Although pf accepts the syntax, nothing happens when firing off a trap to
A.A.A.10.
If I replace $nms_broadcastaddress with one of the physical addresses
(f.ex A.A.A.1 or A.A.A.2) I can see the trap coming from 10.10.10.1 and
heading for A.A.A.10 on the receiver.
Since dup-to a broadcast address doesn't seem to work (unless I am doing
something completely wrong), I then need to specify multiple hosts, which
is not supported.
I can add a single address for the dup-to rule, but trying to add
multiple hosts gives me a "syntax error" when trying to load the conf
file.
I tried ( { $nms_if $nms-a, $nms_if $nms-b } ) but apparently this is not
supported (and syntax error is my bane).
So, I am sort of back to square one... broadcast not supported and
multiple individual receivers is not supported....
BTW, Please correct me if anyone has been successful at this, because I
don't want to conclude on this unless it is correct.
That leaves me with multicast, which is yet to be tried, however, I don't
have much experience with this one, so testing may take a little
longer...
Cheers,
Simon.
On Wed Nov 5 17:12 , Damian Gerow sent:
Good luck, and let the list know how this fares out. I'm sure you're
not
the only person who's run into this problem before, and I'm curious
to see
what works out for your setup.
As for submitting a feature request... TBH, I don't know. I'm not
sure if
sendbug is appropriate for feature requests or not. Given the text
under
<http://www.openbsd.org/report.html>, it sounds like sendbug is
appropriate
for feature requests, but you may want to double-check that yourself.
- Damian
Simen Stavdal wrote:
:
: 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
-------------------------------------------------------------------------
FC% din egen, gratis e-postadresse pC% Start.no
