|
|
comp.unix.bsd.openbsd.misc |
* kestas....@gmail.com <kestas....@gmail.com> [2006-04-29]: > "Note that queueing is only useful for packets in the outbound > But this is wrong. It's not too late to queue it; by queueing it and > I know this is possible because IPFW with dummynet doesn't have any If everyone loves PF because of its elegance why can't it do So, you can queue the download traffic, but that really has a minor My $0.02 CDN. Take it for what it's worth, or exchange it for --
> Why can't you queue download traffic on an interface? The reason Are you sure about that? Perhaps a well behaved sending host
> openbsd.org's FAQ gives is:
> direction. Once a packet arrives on an interface in the inbound
> direction it's already too late to queue it -- it's already consumed
> network bandwidth to get to the interface that just received it. The
> only solution is to enable queueing on the adjacent router or, if the
> host that received the packet is acting as a router, to enable queueing
> on the internal interface where packets exit the router."
> dropping some packets of inbound traffic the sending host slows down
> the speed at which it sends.
would, but what if it isn't? Also, if you're being DDOSd, will
this even matter?
> Shaping NAT traffic downloads works fine with this hack, but I also run I haven't heard of any firewall that successfully could. If you're
> some services on the external interface. With downloads queued on the
> internal interface there's no way to queue the services' download
> traffic, which means an external service can hog up all the bandwidth
> and I can't do anything.
being DDOSd, you're being DDOSd. No firewall with any special set
of rules can improve your bandwidth in that case. If the pipe is
filled, it's filled.
I don't use IPFW, so I can't speak on its specific technical merits.
> problems.
Maybe you should ask the IPFW devs how they're able to perform this
magic. Last I heard, the PF devs were technicians, engineers, and
scientists, not a single magic-user among them. (IRL anyhow. :-))
> something as simple as queue download traffic? I think that you _can_ configure PF to do this, but I believe that
what the developers are trying to say is, `What's the point'? We're
talking about trying to control traffic _before_ it hits your
interface. Even if the remote sending host is well-behaved enough
to slow down its sending rate, it still has to interact with PF
before PF can decide whether to pass the packets, drop the packets,
or tell the sending host to `bugger off'.
to no effect on traffic outside of your firewall. The queuing
actually occurs on _your_ side of the external interface.
better currency. :-)
W. Steven Schneider <steven_schnei...@telus.net>