Simen Stavdal escreveu:
Hello,

I have the following scenario.

A router (let's call it router A) is sending snmp traps to an nms
(Network Monitoring System).
Between the router A and the nms (let's call it nms-a) is a Dell
PowerEdge 860 running OpenBSD 4.1 i386 (bsd.mp) and pf.
On the same segment as nms-a, is nms-b, nms-c etc.

I am trying to make pf copy the incoming trap, while keeping the source
ip address (of router A), and changing the destination ip for nms-a,b,c
etc,
but I am not even sure if this is the right way about it.

This is a variant of the rule that I have tried :
pass in on $int_if dup-to ($nms_if $nms-b ) proto udp from 10.10.10.1 to
$nms-a port 162

(all macros are defined, and expanded correctly in the ruleset when
issuing pfctl -s all )

The way I have understood the syntax, is that traps destined for nms-a,
will be duplicated to nms-b.
However, when I tcpdump the nms_if, I can only see traps for nms-a (and
none for b).

I mentioned that the rule was a variant, because I have tried several
other options, but to no avail.
Has anyone done this before? Am I barking up the wrong tree?

Here is some more (hopefully) useful information :
tcpdump output (x.x.x.2 is the ip of nms-a, and Y.Y.Y.Y is the agent
address (the source ip of the trap))
12:21:04.798192 10.10.10.1.2074 > X.X.X.2.snmp-trap: Trap(36)
E:cisco.9.41.2 [Y.Y.Y.Y] enterpriseSpecific[specific-trap(1)!=0] 16671316
.iso.org=[|snmp]

The expanded rule from pfctl -s all | grep "dup-to"
pass in on bge1 dup-to (vlan4 Z.Z.Z.1) inet proto udp from 10.10.10.1 to
X.X.X.2 port = snmp-trap keep state
(Z.Z.z.1 is nms-b)

Any input is very welcomed,

Cheers,
Simon Stavdal.

-------------------------------------------------------------------------
Fe din egen, gratis e-postadresse pe Start.no


As the man page states, it literally duplicate the packet. It means that an exact copy of it will be sent to the specified machine. Also, you are not seeing them when you use tcpdump, because they are all the same. If nms-b isn't prepared to receive an packet which wasn't destined for it, it will discard the packet silently. You must check on nms-b if it is receiving the packets.

My regards,

--
Giancarlo Razzolini
http://lock.razzolini.adm.br
Linux User 172199
Red Hat Certified Engineer no:804006389722501
Verify:https://www.redhat.com/certification/rhce/current/
Moleque Sem Conteudo Numero #002
OpenBSD Stable
Ubuntu 8.04 Hardy Heron
4386 2A6F FFD4 4D5F 5842  6EA0 7ABE BBAB 9C0E 6B85

Reply via email to