I'm playing with pf/altq code for a project of mine, and some of it may
be of interest to people here. The diffs are for -current only.
http://homepage.mac.com/quension/pf/qexp0.diff
The first diff gives pf DiffServ and ECN awareness (IP level; TCP level
ECN is already present). The
If you have a default deny firewall policy, but allow
incoming synproxy'd http connections, are the packets
that are generated and sent out by pf (to verify the
existence of the initial syn's source IP) treated as
part of the current stream on the client side of the
connection? In other
Hi list,
I'm sure anyone here knows about the linux virtual
server (layer 4 load-balancer).
I searched the web for an equivalent for *bsd, but
found none.
The only thing which looks like something like a
load-balancer is the FreeBSD loadd,
which requires packets to copied from kernel-space
On Fri, Jun 20, 2003 at 06:53:08PM +0200, Stefan Sonnenberg-Carstens wrote:
Hi list,
I'm sure anyone here knows about the linux virtual server (layer 4 load-balancer).
I searched the web for an equivalent for *bsd, but found none.
The only thing which looks like something like a load-balancer
Hello all,
I was reading the archives from October 2002 on load-balancing with
pf[1], and it seems that adding the ability to redirect to hosts from a
dynamic table would make building userland health monitoring
substantially easier.
For example, if we have the following pf.conf:
# pf.conf
Jonathan S. Keim wrote:
Hello all,
I was reading the archives from October 2002 on load-balancing with
pf[1], and it seems that adding the ability to redirect to hosts from a
dynamic table would make building userland health monitoring
substantially easier.
For example, if we have the following
On Friday, Jun 20, 2003, at 06:59 US/Pacific, David Chubb wrote:
However to connect to a remote RDP (Remote Desktop Client)
connection I have
to disable the Packet filter before it will allow the connection to
go
through. The remote site looks at the logs and it shows the incoming
connection
On Friday, Jun 20, 2003, at 10:07 US/Pacific, Stefan
Sonnenberg-Carstens wrote:
I think you would not have to blow up the pf code itself too much.
Simply put, take a look at the packet in ip_input.c.
Look, if it should be destinated to some of your real server.
Calculate the next real server to
I'm having some problems with queueing using pf on a bridge (3.3 i386
GENERIC).
I'm using priority queuing with 10 queues, the default queue being the
lowest priority one. It appears as though arp request frames going through
the bridge are being put into the default queue, and that it is not
I think you would not have to blow up the pf code
itself too much.
Simply put, take a look at the packet in
ip_input.c.
Look, if it should be destinated to some of your
real server.
Calculate the next real server to give to packet to
based
on some infos (connections, load,
etc).
Create a
10 matches
Mail list logo
