On 3/20/2009 12:59 PM, (private) HKS wrote:
On Wed, Mar 18, 2009 at 8:49 PM, Mail Lists<mail-li...@peachnet.com> wrote:
On Wed, Mar 18, 2009 at 12:33 PM, (private) HKS<hks.priv...@gmail.com> wrote:
On Wed, Mar 18, 2009 at 12:12 PM, Mail Lists<mail-li...@peachnet.com> wrote:
Hello all,
I'm have some issues setting up a bridge. We recently co-located a
router in a data canter. The machine is a a soekris 5501 running
openbsd4.4.
The interfaces use the vr drivers.
A machine belonging to someone in our cabinet is sending out about
100000 packets/second of udp traffic on port 42. When I try to put my
primary interface into bridge mode my machine locks up. I'm assuming
this is because it can't handle the amount of packets flowing past the
interface. Could anyone indicate whether or not this could indeed be
the problem or if I'm completely off base here. The admin at the data
center seems to think my box should be able to handle that amount of
traffic just fine.
The problem is not as pronounced when PF is disabled. The machine
still crawls to a virtual standstill but I can at least do a ctrl-c on
a tcpdump to stop it. The only way to get back at the command line
when PF is enabled is to unplug the ethernet cable.
When I DO a tcpdump I get millions of the following:
23:25:10.082217 00:0b:db:93:fb:70 01:00:5e:00:01:18 0800 60:
74.255.56.30.42> 224.0.1.24.42: udp 16
Cancelling the dump it reports for instance 200000 packets received by filter
198000
packets dropped by kernel
I can provide more details on the box if needed but I would just like
some advice on what I can do about this.
Is there a way to ignore all packets coming from a certain MAC address
on layer 2?
Is there anyway possible that this is 'legitimate' traffic?
Is there any other way to create a filtering bridge without putting
interfaces into promiscuous mode?
Thanks for any advice, would really appreciate it.
Steve
This PR may be related:
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=6072
Try setting up a blackhole route for multicast addresses, see if that
settles things down a bit.
On another note, I'd be blown away to see a Soekris 5501 handle 100k
packets/second without eating shit. Their NICs are Terrible (capital
T), and the low-powered CPU is quickly overwhelmed by interrupts.
-HKS
Thanks, I will try this when I'm next able to drive down there as I've
effectively cut myself off doing exactly what I shouldn't have. I'm
not sure I get why routing these packets to a blackhole would be any
easier on the CPU though.
Would something like this work?
route add IPOFOFFENDINGMACHINE 127.0.0.1 -blackhole
Thanks for the advice!
Oh, I missed the question you asked about why it would be easier. The
PR explains some of that, but I've observed that when multicast
traffic enters an interface in promiscuous mode, if
net.inet.ip.forwarding=1, the host will attempt to route those
packets. This can create a loop where traffic is repeatedly replicated
until the box is paralyzed. I knocked down a couple 5501s in
discovering this problem.
I don't know that this is what you're seeing, but 100k multicast
packets/sec from a single host sounds an awful lot like a traffic
replication loop.
-HKS
OK, I understand. If that were the case I should be able to turn off
forwarding and the bulk of the problem would disappear?
I tried this and this wasn't the case.
I tried the blackhole too - route add IP 127.0.0.1 -blackhole and it
didn't make any apparent difference. I guess that leads me to believe
that these packets are all original packets coming from this IP?
What exactly does the OS do when it receives a multicast packet? Does
the packet get passed all the way down the network stack and back out?
(when in promiscuous mode I suppose). If so why can't you simply tell
the stack not to do this for specific packets? I'm sure there's a real
reason why this isn't possible I'm just trying to get a grasp on what's
hapenning.
Anyways, thanks for all the help, really appreciate it. I think I've
pretty much given up on this situation and am going to approach this on
a physical level (move to a different cabinet probably). I'm mostly
pursuing this for my own edification I suppose.
Thanks,
Steve
