Re: How to obtain fixed packet loss ?
On Mon, Jan 03, 2011 at 06:22:54PM +, nangergong wrote: Hi, all: As far as I know, in dummynet, plr is prabability-based, namely, when a packet is processed, it will be discarded according to the probability. So, if I have 100 packets and the plr is 5%, eventually I may just discard 3 packets or even 1 packets. So, the real packet loss is not consitent with the plr-set value. Is there any good method that can give me a consistent packet loss? Thank you! you would need to modify the prob option in ipfw so that e.g. you specify a bitmap indicating the pattern of packet pass/drop (this was the way i originally implemented packet loss back in 1995!) cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Transparent Squid and traffic control
On Jan 4, 2011, at 8:01 AM, Fazal Ahmed Malik wrote: I have problem in running transparent squid along with dummynet on FreeBSD 7. I have mpd5 for dialin pppoe which is working perfect along with ipfw dummynet traffic control. Now i want to setup transparent squid using ipfw fwd rule. if i place fwd rule before dummynet rule transparent squid start working but than traffic is not being controlled. Than i placed fwd rule after the dummynet pipe here traffic controlled but transparent squid stop working.Any body have experience in such configuration where both work simultaneously please gave me some hints. I have done this successfully in the past. You need to remember that for every web request there are potentially two TCP conversations: one between the client and the proxy and one between the proxy and the server. You probably do not want to pipe the first type of conversation--requests that can be served from the proxy's cache do not use WAN bandwidth and should be served at full speed over the LAN. You DO want to pipe the second type of conversation. Requests from the proxy to web servers over the WAN will compete with other traffic for bandwidth. So leave your fwd rule before the dummynet rule(s) and be sure that LAN traffic is not piped. Then add rules to pipe requests from the proxy's external IP to non-LAN addresses on port 80. Something like these: Downstream: ipfw add skipto $ACCEPT tcp from $LAN 80 to me ipfw add pipe $M tcp from any 80 to $EXTIP Upstream: ipfw add skipto $ACCEPT tcp from me to $LAN 80 ipfw add pipe $N tcp from $EXTIP to any 80 If you post a specific ruleset you can get specific advice. :) JN ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Transparent Squid and traffic control
On 1/4/11 5:01 AM, Fazal Ahmed Malik wrote:
Hi,
I have problem in running transparent squid along with dummynet on FreeBSD 7. I
have mpd5 for dialin pppoe which is working perfect along with ipfw dummynet
traffic control. Now i want to setup transparent squid using ipfw fwd rule. if
i place fwd rule before dummynet rule transparent squid start working but than
traffic is not being controlled. Than i placed fwd rule after the dummynet pipe
here traffic controlled but transparent squid stop working.Any body have
experience in such configuration where both work simultaneously please gave me
some hints.
Best regards,
Fazal Ahmed
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
in your ipfw rules separate out the incoming and outgoing work on each
inteface to different sets of rules..
As a simple example I attach a copy of a sanitased ipfw ruleset that
does that with mpd..
Noteh that there are two different NAT points.. one for incoming and
one for outgoing data
You may do your forwarding at the appropriate point for each direction
independently.
In fact you probably should do it so that you forward incoming packets
on both the local and remote interfaces
and never forward outgoing packets..
this means you would add a new set of rules for the local interface
that are not in
my file but you should get the idea..
when you say 'transparent squid, do you mean transparent to the client
or the server, or both?
basically you should do fwds on incoming packets (fwd to squid locally)
(incoming from the point of view of the firewall itself.)
#!/bin/sh
fwcmd=/sbin/ipfw
# Suck in the configuration variables.
if [ -z ${source_rc_confs_defined} ]; then
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
fi
# set these to your outside interface network and netmask and ip
oif=tun0
onet=192.168.36.0
omask=24
oip=A.A.A.A
# set these to your inside interface network and netmask and ip
iif=vr0
inet=192.168.2.0
imask=255.255.255.0
iip=192.168.2.21
# for not the natd target is us but change this if you
# change that in natd.conf
natd_target=${oip}
work_vpnserver=B.B.B.B
INCOMING=4000
OUTGOING=8000
sysctl net.inet.ip.fw.enable=0
${fwcmd} -q flush
${fwcmd} -q table 1 flush
${fwcmd} -q table 2 flush
${fwcmd} -q table 3 flush
${fwcmd} -q table 4 flush
# Addresses we should never talk to outside our firewall
${fwcmd} table 1 add 10.0.0.0/8
${fwcmd} table 1 add 172.16.0.0/12
${fwcmd} table 1 add 192.168.0.0/16
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
# RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class D),
# and class E) on the outside interface
${fwcmd} table 1 add 0.0.0.0/8
${fwcmd} table 1 add 169.254.0.0/16
${fwcmd} table 1 add 192.0.2.0/24
${fwcmd} table 1 add 224.0.0.0/4
${fwcmd} table 1 add 240.0.0.0/4
# add legit sources of ssh.. DNS is not up yet so use IPs
# could add to /etc/hosts I guess.
# frienly server
${fwcmd} table 2 add C.C.C.C
# work
${fwcmd} table 2 add D.D.D.D
# vps1
${fwcmd} table 2 add E.E.EE
# add legit DNS tcp (zone) sources
# my.first.dns.server
${fwcmd} table 3 add F.F.F.F
# my.second.dns.server
${fwcmd} table 3 add G.G.G.G
# my.third.dns.server
${fwcmd} table 3 add H.H.H.H
# Add our local networks here
${fwcmd} table 4 add 192.168.2.0/24
${fwcmd} table 4 add 172.16.15.0/24
# common spoofing code
# --- ALL PACKETS START HERE.
# Stop localhost spoofing
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny log all from any to 127.0.0.0/8
${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any
# If we've already decided on it. keep our word.
${fwcmd} add check-state
# Select direction and interface class
${fwcmd} add skipto ${INCOMING} ip from any to any in recv ${oif}
${fwcmd} add skipto ${OUTGOING} ip from any to any out xmit ${oif}
# Internal traffic. generally don't care
# except to stop spoofing.
# make extra sure we don't block DHCP to our server
# as initial request will be from 0.0.0.0/0
${fwcmd} add allow udp from any to any 67 in recv ${iif}
${fwcmd} add allow udp from any 67 to any out xmit ${iif}
#
soft-cap,
Dear friends, linux/ipfw/dummynet/transparent-bridge, am trying to cap users to upload/TX rates, but allow them to go over if the link is not congested. The example below limits each src-ip mask-IP's TX from 10.10.0.0/20 to 128Kbp/s, and from 10.20.0.0/20 to 1024Kbp/s. - ipfw pipe 1 config bw 128Kbit/s mask src-ip 0x ipfw pipe 2 config bw 1024Kbit/s mask src-ip 0x ipfw 10001 add pipe 1 ip from 10.10.0.0/20 to any out xmit br0 ipfw 10001 add pipe 2 ip from 10.20.0.0/20 to any out xmit br0 ?How to define total link size 100/100Mbit/s and allow individual ip's to exceed rate limit when link is not full? - This simply places a HARD CAP on each IP. My question is, how to allow each IP to exceed that hard limit if the bandwidth on the up-link is available. IE. If there is free bandwidth let them use it; if not scale users exceeding their subscibed data rate down until they are down to their subscribed limit? My WAN uplink is 100Mbp/s I want to give the clients the benefit of exceeding their TX dynamic pipe cap-limit, when the system has spare bandwdith. I welcome any feedback. Thanks -Mike 1-214-901-3232 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: soft-cap,
On Tue, Jan 4, 2011 at 2:33 PM, Michael Spratt m...@magicislandtechnologies.com wrote: Dear friends, linux/ipfw/dummynet/transparent-bridge, am trying to cap users to upload/TX rates, but allow them to go over if the link is not congested. The example below limits each src-ip mask-IP's TX from 10.10.0.0/20 to 128Kbp/s, and from 10.20.0.0/20 to 1024Kbp/s. - ipfw pipe 1 config bw 128Kbit/s mask src-ip 0x ipfw pipe 2 config bw 1024Kbit/s mask src-ip 0x Create 1 pipe of 1024+128 Kbps. Then create 2 queues, one with weight 1 (the slow queue) and the other with weight 8 (the fast queue). That will guarantee that traffic sent through queue 1 gets at least 128 Kbps of bandwidth, even when the pipe is full. And traffic sent through queue 2 gets at least 1024 Kbps of bandwidth, even when the pipe is full. The beauty of queues, though, is that either queue can expand to fill the full pipe, if there's no traffic in the other queues. Thus, queue 1 is guaranteed 128 Kbps of bandwidth, but can use up to the full pipe worth if queue 2 is empty. And queue 2 is guaranteed 1024 Kbps of bandwidth, but can use up to the full pipe worth if queue 1 is empty. ipfw 10001 add pipe 1 ip from 10.10.0.0/20 to any out xmit br0 ipfw 10001 add pipe 2 ip from 10.20.0.0/20 to any out xmit br0 Then, change the above rules to use the queues instead. The way dummynet works, is that pipes set hard limits on the bandwidth. And queues provide minimum guarantees for bandwidth inside of that pipe. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: kern/148928: [ipfw] Problem with loading of ipfw NAT rules during system startup
Synopsis: [ipfw] Problem with loading of ipfw NAT rules during system startup Responsible-Changed-From-To: freebsd-ipfw-hrs Responsible-Changed-By: hrs Responsible-Changed-When: Wed Jan 5 01:05:33 UTC 2011 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=148928 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: conf/153155: [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled
Synopsis: [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled Responsible-Changed-From-To: freebsd-ipfw-hrs Responsible-Changed-By: hrs Responsible-Changed-When: Wed Jan 5 01:06:05 UTC 2011 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=153155 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
