Any idea when is planning to implement mask classifiers into pf?
This really help in dummynet, to simplify rules set.
Adrian Penisoara wrote:
Hi,
On Tue, Mar 4, 2008 at 5:48 PM, Fratiman Vladut <[EMAIL PROTECTED]>
wrote:
With *kgdb* , obtain this:
Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: e13d0000
cpuid = 0
Uptime: 1h8m8s
Physical memory: 882 MB
Dumping 63 MB: 48 32 16
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) Quit
Quite a short stack trace, not sure whether it helps.
I use ipfw with dummynet because can use dynamically rules for shaping.
With altq, need to put rule for every host, in order to share bandwith
equal to all host in lan. If i have hundredth of host, this can be
painful.
This is why i use dummynet with ipfw.
You are probably referring to dummynet's mask classifier. I guess this would
be a good reason to attempt implementing similar mask classifiers into
pf(4).
Regards,
Adrian Penisoara
ROFUG / EnterpriseBSD
Adrian Penisoara wrote:
Hi,
On Mon, Mar 3, 2008 at 10:31 PM, Fratiman Vladut <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi!
I try to implement some load balancing using pf. I use also ipfw for
traffic shaping.
Have you tried to use traffic shaping with ALTQ inside pf ? Perhaps
there is a negative side-effect when combining ipfw and pf this way.
In pf.conf, my rules are this:
nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)
pass in on $int_if route-to { ($ext_if1 $ext_gw1), ($ext_if2
$ext_gw2),
($ext_if2 $ext_gw2) } round-robin from $lan_net to any keep state
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to
any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to
any
All work fine, but after some time , my system reboot. I found with
dmesg, this error:
savecore: reboot after panic: vm_fault: fault on nofault entry,
addr:
e13d0000
Mar 3 21:29:47 server savecore: reboot after panic: vm_fault:
fault on
nofault entry, addr: e13d0000
savecore: writing core to vmcore.1
Have you tried to extract a gdb stack trace from the core file ? See
link below:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html
Regards,
Adrian Penisoara
ROFUG / EnterpriseBSD
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"