Dummynet on 64 bit systems
Hello, I was interested in knowing if Dummynet is supported on Windows 7 x64. I tried on 32 bit Windows 7 and works good. If it should work on 64 bit Windoows 7, can you let me know the install procedure. Or do you have a digitally signed ipfw.sys ? Thanks Rama ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dummynet on 64 bit systems
http://info.iet.unipi.it/~luigi/dummynet/#58be I wanted to do http://lmgtfy.com/?q=dummynet first, but it'll still help for other issues that might come up when using it on windows. On 5/7/2013 4:17 PM, Rama Varma wrote: Hello, I was interested in knowing if Dummynet is supported on Windows 7 x64. I tried on 32 bit Windows 7 and works good. If it should work on 64 bit Windoows 7, can you let me know the install procedure. Or do you have a digitally signed ipfw.sys ? Thanks Rama ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
doesn't dummynet work with vlan ?
Hello there I use freebsd8.2 I added dummynet and other followings into the kernel; options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about options IPFIREWALL_FORWARD #enable trasparent proxy support options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options HZ=1000 options DUMMYNET options IPDIVERT options DEVICE_POLLING I have 4 networks which seperate from eachother with vlan. I wish to bandlimit for every vlan network using dummynet. I have 2 ethernet cards for that. one of them is wan other one is inbound is tagged. vlan works well I configured a network to limit using dummynet; ipfw.sh ### ipfw -f flush ipfw pipe 11 config bw 2Mbit/s # Vlan104 ipfw pipe 12 config bw 2Mbit/s # 6.Port on the switch ipfw add pipe 11 ip from any to 10.12.4.0/24 in via em0 ipfw add pipe 12 ip from 10.12.4.0/24 to any out xmit em0 ### em0 is for outside in the server. as a client my pc is in vlan104 namely i am behind the firewall when i execute the ipfw.sh, I can't reach to the internet. ipfw add pipe 12 ip from 10.12.4.0/24 to any out xmit em0 above line works it actually limits but ; ipfw add pipe 11 ip from any to 10.12.4.0/24 in via em0 above line doesn't work properly it obstructs my http and icmp requests. so i can't reach to internet. Whereas i remove ipfw add pipe 11 ip from any to 10.12.4.0/24 in via em0 from ipfw.sh I can either ping at outbound or reach to internet. I tried vlan104 instead of em0 in via em0 that doesn't help me. I don't use proxy. I use nat What can be the problem ? Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFW transparent VS dummynet rules
On Sun, Jan 8, 2012 at 1:00 PM, Ian Smith smi...@nimnet.asn.au wrote: On Sat, 7 Jan 2012, budsz wrote: [..] keyword instead of an explicit address. The search terminates if this rule matches. Note particularly the last sentence. You'll have to do your dummynet piping first, if it is to apply also to forwarded packets. (sysctl) net.inet.ip.fw.one_pass: 1 When set, the packet exiting from the dummynet pipe or from ng_ipfw(4) node is not passed though the firewall again. Other- wise, after an action, the packet is reinjected into the firewall at the next rule. It seems that you may have one_pass set to 1. Set to 0, packets will continue through the ruleset on exit from pipe/s, so to your fwd rule. cheers, Ian Thank you very much, lazy to read ipfw(8) :) pipe pipe_nr Pass packet to a dummynet ``pipe'' (for bandwidth limitation, delay, etc.). See the TRAFFIC SHAPER (DUMMYNET) CONFIGURATION Section for further information. The search terminates; however, on exit from the pipe and if the sysctl(8) variable net.inet.ip.fw.one_pass is not set, the packet is passed again to the firewall code starting from the next rule. -- budsz No problem. However it's considered good form to also copy responses cc'd back to the two lists this thread appears on, for the archives. Not that I need the credit, but it shows that the advice was useful, and that other list members need not also respond, thinking it unresolved. cheers, Ian OK,thank you for reminding me :) TIA -- budsz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
IPFW transparent VS dummynet rules
Hi folks,
I already found the mistake of my ruleset sequence on my box, for ex:
${fwcmd} add 30 fwd ${ipproxy},${portproxy} tcp from ${ipclproxy} to
any dst-port ${porthttp} in via ${ifint0}
${fwcmd} add 52 pipe 2 ip from any to ${ipclient} via ${ifint0}
${fwcmd} add 53 pipe 3 ip from ${ipclient} to any via ${ifint0}
${fwcmd} pipe 2 config bw ${bwcldown} mask dst-ip 0x
${fwcmd} pipe 3 config bw ${bwclup} mask src-ip 0x
With this ruleset sequence, the limiter didn't work but fwd rules working.
If I switching like:
${fwcmd} add 52 pipe 2 ip from any to ${ipclient} via ${ifint0}
${fwcmd} add 53 pipe 3 ip from ${ipclient} to any via ${ifint0}
${fwcmd} pipe 2 config bw ${bwcldown} mask dst-ip 0x
${fwcmd} pipe 3 config bw ${bwclup} mask src-ip 0x
${fwcmd} add 70 fwd ${ipproxy},${portproxy} tcp from ${ipclproxy} to
any dst-port ${porthttp} in via ${ifint0}
The limiter working but fwd didn't work. Anyone have a clue for fix
this dilemma?
Thank You
--
budsz
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFW transparent VS dummynet rules
On Sat, 7 Jan 2012, budsz wrote:
Hi folks,
I already found the mistake of my ruleset sequence on my box, for ex:
${fwcmd} add 30 fwd ${ipproxy},${portproxy} tcp from ${ipclproxy} to
any dst-port ${porthttp} in via ${ifint0}
${fwcmd} add 52 pipe 2 ip from any to ${ipclient} via ${ifint0}
${fwcmd} add 53 pipe 3 ip from ${ipclient} to any via ${ifint0}
${fwcmd} pipe 2 config bw ${bwcldown} mask dst-ip 0x
${fwcmd} pipe 3 config bw ${bwclup} mask src-ip 0x
With this ruleset sequence, the limiter didn't work but fwd rules working.
If I switching like:
${fwcmd} add 52 pipe 2 ip from any to ${ipclient} via ${ifint0}
${fwcmd} add 53 pipe 3 ip from ${ipclient} to any via ${ifint0}
${fwcmd} pipe 2 config bw ${bwcldown} mask dst-ip 0x
${fwcmd} pipe 3 config bw ${bwclup} mask src-ip 0x
${fwcmd} add 70 fwd ${ipproxy},${portproxy} tcp from ${ipclproxy} to
any dst-port ${porthttp} in via ${ifint0}
The limiter working but fwd didn't work. Anyone have a clue for fix
this dilemma?
Quoting ipfw(8):
fwd | forward ipaddr | tablearg[,port]
Change the next-hop on matching packets to ipaddr, which can be
an IP address or a host name. The next hop can also be supplied
by the last table looked up for the packet by using the tablearg
keyword instead of an explicit address. The search terminates if
this rule matches.
Note particularly the last sentence. You'll have to do your dummynet
piping first, if it is to apply also to forwarded packets.
(sysctl)
net.inet.ip.fw.one_pass: 1
When set, the packet exiting from the dummynet pipe or from
ng_ipfw(4) node is not passed though the firewall again. Other-
wise, after an action, the packet is reinjected into the firewall
at the next rule.
It seems that you may have one_pass set to 1. Set to 0, packets will
continue through the ruleset on exit from pipe/s, so to your fwd rule.
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
dummynet in 8.1
Hi, I've read in the release notes that ipfw and dummynet have been improved. I've wonder if with 8.1 will it be possible to bridge a VLAN Trunk and filter VLAN tagged frames (actually, send packets to a dummynet queue for traffic shapping). I've tried this with 8.0 but seems like ipfw does not understand vlan tagged frames. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dummynet in 8.1
Re: freebsd-questions Digest, Vol 320, Issue 18, Message: 7 On Sun, 25 Jul 2010 13:56:04 +0200 Matias matiassu...@gmail.com wrote: I've read in the release notes that ipfw and dummynet have been improved. I've wonder if with 8.1 will it be possible to bridge a VLAN Trunk and filter VLAN tagged frames (actually, send packets to a dummynet queue for traffic shapping). I've tried this with 8.0 but seems like ipfw does not understand vlan tagged frames. Try the freebsd-ipfw list; they're likely too busy to read this one .. perhaps with more detail of what you want to do, and what you've tried. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Traffic Shaping Bridge with Dummynet
I am trying to do traffic shaping using a bridge on FreeBSD 7.1. I have the bridge configured and it works fine. It looks like this: rest of network - xl0 - bridge0 - xl1 - side to be shaped It works with the following set of ipfw rules (pipes in but unlimited bw): network=10.10.10.0/24 limit=0 ipfw -q -f flush ipfw -q pipe 1000 config mask dst-ip 0x00ff bw $limit ipfw -q add pipe 1000 ip from any to $network via xl1 ipfw -q pipe 1001 config mask src-ip 0x00ff bw $limit ipfw -q add pipe 1001 ip from $network to any via xl1 ipfw -q add 6 allow all from any to any If I change the limit to 1Mbit/s (or anything else) it stops passing traffic. I used tcpdump and I can see the traffic on the bridge but I cannot see it after the bridge. However ipfw -a list shows the counts for the pipe going up, which doesn't make sense to me. I've tried adding: ipfw -q add allow all from any to any via bridge0 ipfw -q add allow all from any to any via xl0 before the pipes. I also tried moving the pipes to bridge0 and xl0. The docs on bridging (http://www.freebsd.org/doc/en/books/handbook/network-bridging.html) says The bridge can be used as a traffic shaper with altq(4) or dummynet(4). So what am I doing wrong? What else do I need to do to limit the bandwidth over a bridge? Thanks, Dan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
IPFW/Dummynet/Bridging with VLAN trunks?
I'm trying to use Dummynet+IPFW and bridging to make a packet shaper that runs across multiple VLANs. So my intended set up is: [users]-[Aggregate Switch]=[FreeBSD]=[Upstream Switch (with IP interfaces for each vlan)]-The World where - is a single VLAN, and = is a tagged dot1q trunk. The aim is to drop the FreeBSD box in the middle, in one trunked uplink, and cover all the VLANs downstream of that. Should this work? In practice, the bridging seems to work OK, but as soon as I add rules to match traffic passing through and apply it to pipes, everything stops. I can use tcpdump's vlan option to filter traffic on em0, em1 or bridge0 and it does show only traffic for that vlan, so tags are being preserved... Ideally, I'd like to use the dot1q tag in ipfw rules directly, and avoid ip ranges, but I don't think that's possible. Is there some special incantation to make ipfw vlan-aware? Has anyone else done this successfully? Best Regards, Howie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFW/Dummynet/Bridging with VLAN trunks?
Howard Jones wrote: I'm trying to use Dummynet+IPFW and bridging to make a packet shaper that runs across multiple VLANs. So my intended set up is: [users]-[Aggregate Switch]=[FreeBSD]=[Upstream Switch (with IP interfaces for each vlan)]-The World where - is a single VLAN, and = is a tagged dot1q trunk. The aim is to drop the FreeBSD box in the middle, in one trunked uplink, and cover all the VLANs downstream of that. Should this work? In practice, the bridging seems to work OK, but as soon as I add rules to match traffic passing through and apply it to pipes, everything stops. I can use tcpdump's vlan option to filter traffic on em0, em1 or bridge0 and it does show only traffic for that vlan, so tags are being preserved... Ideally, I'd like to use the dot1q tag in ipfw rules directly, and avoid ip ranges, but I don't think that's possible. Is there some special incantation to make ipfw vlan-aware? Has anyone else done this successfully? This is how I do it: ipfw pipe 1 all from any to any in via vlan20 ipfw pipe 2 all from any to any in via vlan40 But in my configuration, bridge0 has members vlan20 and vlan40. I would create a separate bridge with vlan21 and vlan41. I don't think ipfw can filter on dot1q tags yet, though. There was a lot of layer 2 filtering capability in a patch floating around for 8-CURRENT, but I'm not sure of its status, nor whether dot1q filtering was implemented. -- Chris Cowart Network Technical Lead Network Infrastructure Services, RSSP-IT UC Berkeley pgpZHyHXxvV8v.pgp Description: PGP signature
Re[2]: IPFW DUMMYNET: Several pipes after each other
Здравствуйте, Ian. May be this will be usefull for you #1. ping -D -S 10.10.16.16 -s 1472 -i 0.01 10.0.16.1 #2. ping -S 10.10.16.17 10.0.16.1 ### --- ### --- ### --- ### --- ### --- ### --- # 111 ### --- ### --- ### --- ### --- ### --- ### --- #Put each flow to different pipes #1 do not affect 2. Each flow goes through its own pipe. #c add 10 pipe 1 proto icmp out xmit nfe0 #c add 11 pipe 2 proto icmp in recv nfe0 #c pipe 1 config bw 64k mask src-ip 0x gred 0.002/10/30/0.1 #c pipe 2 config bw 64k mask dst-ip 0x gred 0.002/10/30/0.1 #1: 64.000 Kbit/s0 ms 50 sl. 2 queues (64 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #mask: 0x00 0x/0x - 0x/0x #BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp # 40 ip 10.10.16.17/0 0.0.0.0/0 10 840 00 0 # 44 ip 10.10.16.19/0 0.0.0.0/0 1143 1714500 49 73500 1030 0 #2: 64.000 Kbit/s0 ms 50 sl. 2 queues (64 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #mask: 0x00 0x/0x - 0x/0x #BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp # 5 ip 0.0.0.0/0 10.10.16.17/0 10 840 00 0 # 7 ip 0.0.0.0/0 10.10.16.19/0 6496000 1 1500 0 ### --- ### --- ### --- ### --- ### --- ### --- # 222 ### --- ### --- ### --- ### --- ### --- ### --- #Put each flow to the same pipe. #1 affect 2. There are packets drop as for 1 as for 2 #c add 10 pipe 1 proto icmp out xmit nfe0 #c add 11 pipe 2 proto icmp in recv nfe0 #c pipe 1 config bw 64k mask src-ip 0x gred 0.002/10/30/0.1 #c pipe 2 config bw 64k mask dst-ip 0x gred 0.002/10/30/0.1 #1: 64.000 Kbit/s0 ms 50 sl. 1 queues (1 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #mask: 0x00 0x/0x - 0x/0x #BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp # 0 icmp 10.10.16.17/0 10.0.16.1/0 879 1159908 49 70668 293 #2: 64.000 Kbit/s0 ms 50 sl. 1 queues (1 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #mask: 0x00 0x/0x - 0x/0x #BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp # 0 icmp 10.0.16.1/0 10.10.16.17/0 537 706380 1 1500 0 ### --- ### --- ### --- ### --- ### --- ### --- # 333 ### --- ### --- ### --- ### --- ### --- ### --- #Put each flow to same queue. # 1 affect 2. There is drops for 1 and 99% drop for 2. #c add 10 queue 1 proto icmp out xmit nfe0 #c add 11 queue 2 proto icmp in recv nfe0 #c pipe 1 config bw 64k mask src-ip 0x gred 0.002/10/30/0.1 #c pipe 2 config bw 64k mask dst-ip 0x gred 0.002/10/30/0.1 #c queue 1 config pipe 1 mask src-ip 0x gred 0.002/10/30/0.1 #c queue 2 config pipe 2 mask dst-ip 0x gred 0.002/10/30/0.1 #1: 64.000 Kbit/s0 ms 50 sl. 0 queues (1 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #2: 64.000 Kbit/s0 ms 50 sl. 0 queues (1 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #q1: weight 1 pipe 1 50 sl. 1 queues (1 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #mask: 0x00 0x/0x - 0x/0x #BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp # 0 icmp 10.10.16.19/0 10.0.16.1/0 40854 61184712 00 40241 #q2: weight 1 pipe 2 50 sl. 1 queues (1 buckets) # GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 #mask: 0x00 0x/0x - 0x/0x #BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp # 0 icmp 10.0.16.1/0 10.10.16.19/0 613 909588 00 0 ### --- ### --- ### --- ### --- ### --- ### --- # 444 ### --- ### --- ### --- ### --- ### --- ### --- #!Put each flow to different queue. These queues share same pipe #1 affect 2. There are packets drop for 1 and no drops for 2. There is only dellay for 2. #c add 10 queue 1 proto icmp out xmit nfe0 #c add 11 queue 2 proto icmp in recv nfe0 #c pipe 1 config bw 64k mask src-ip 0x gred 0.002/10/30/0.1 #c pipe 2 config bw 64k mask dst-ip 0x gred 0.002/10/30/0.1 #c queue 1 config pipe 1 mask src-ip 0x gred 0.002/10/30/0.1 #c queue 2 config pipe 2 mask dst-ip 0x gred 0.002/10/30/0.1 #1: 64.000 Kbit/s0
Re[2]: IPFW DUMMYNET: Several pipes after each other
On Wed, 28 Jan 2009, KES wrote: , Ian. May be this will be usefull for you Yes, but I need to read it more times :) Nicely answers the question about stats per flow/queue anyway, not too hard to parse for logging. #1. ping -D -S 10.10.16.16 -s 1472 -i 0.01 10.0.16.1 #2. ping -S 10.10.16.17 10.0.16.1 Results suggest that #1 was -S 10.10.16.19 ? A script running the same number of #2 before killing #1 (or such) would make comparisons between different runs easier to follow maybe? Thanks, lots of useful info; hoping to try some weighted queueing soon. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re[3]: IPFW DUMMYNET: Several pipes after each other
Здравствуйте, Ian. Вы писали 28 января 2009 г., 18:01:45: IS On Wed, 28 Jan 2009, KES wrote: , Ian. May be this will be usefull for you IS Yes, but I need to read it more times :) Nicely answers the question IS about stats per flow/queue anyway, not too hard to parse for logging. #1. ping -D -S 10.10.16.16 -s 1472 -i 0.01 10.0.16.1 #2. ping -S 10.10.16.17 10.0.16.1 IS Results suggest that #1 was -S 10.10.16.19 ? A script running the same IS number of #2 before killing #1 (or such) would make comparisons between IS different runs easier to follow maybe? IS Thanks, lots of useful info; hoping to try some weighted queueing soon. Yes, you are right -S 10.10.16.19. both ping are run simulteneously I have experimented with pipes after pipes. With dummy it is possible to do next: put two flows to pipe 512Kbit, pipe will be devided by equal parts: 256. in case the only one flow is active it will be 320Kbit pipe 1 bw 512kbit queue 1 pipe 1 pipe 2 bw 320kbit ipfw add 1 pipe 2 all from any to any ipfw add 2 queue 1 all from any to any First of all packets will be piped to 320Kbit/s then they will be queued to 512Kbit. Because of flow of 320 is less then 512kbit packets will leave queue with speed of 320. In case two flows both will be piped to 320 kbit in sum this will be 640kbit, Because of queue bw is 512kbit some packets will be droped. This will down each flow speed to 256 NOTICE: A) you must create its own pipe for each flow so you must use mask 0x. I use: pipe 1 config bw 512k mask src-ip 0x gred 0.002/10/30/0.1 pipe 2 config bw 320k mask src-ip 0x gred 0.002/10/30/0.1 B) you must put all flows to one queue so they share available bw so you must use mask 0x I use: queue 1 config pipe 1 mask src-ip 0x gred 0.002/10/30/0.1 keep in mind IPFW.man: In practice, pipes can be used to set hard limits to the bandwidth that a flow can use, whereas queues can be used to determine how different flow share the available bandwidth. So when you give user some bandwidth to user you must put its flow to pipe If users will share some bandwidth then put their flows to queue Suggestion: What queue inherit from pipe? It seems queue inherit only bandwidth parameter from pipe. If so then it is boring to create useless pipe to inherit only bw parameter. It will be handy directly write this parameter in queue and remove DEPRECATED (I think so) 'pipe' opts from queue. In any case this is black box how pipe is coupled with queue. This is unclear section in man. Also I notice next BUG: There are two modes of dummynet operation: normal and fast. Normal mode tries to emulate real link: dummynet scheduler ensures packet will not leave pipe faster than it would be on real link with given bandwidth. Fast mode allows certain packets to bypass dummynet scheduler (if packet flow does not exceed pipe's bandwidth). Thus fast mode requires less cpu cycles per packet (in average) but packet latency can be significantly lower comparing to real link with same bandwidth. Default is normal mode, fast mode can be enabled by setting net.inet.ip.dummynet.io_fast sysctl(8) variable to non-zero value. kes# ping 10.10.16.18 PING 10.10.16.18 (10.10.16.18): 56 data bytes 64 bytes from 10.10.16.18: icmp_seq=0 ttl=128 time=18.441 ms 64 bytes from 10.10.16.18: icmp_seq=1 ttl=128 time=11.501 ms 64 bytes from 10.10.16.18: icmp_seq=2 ttl=128 time=11.516 ms 64 bytes from 10.10.16.18: icmp_seq=3 ttl=128 time=11.557 ms 64 bytes from 10.10.16.18: icmp_seq=4 ttl=128 time=11.534 ms ^C --- 10.10.16.18 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 11.501/12.910/18.441/2.766 ms #ipfw pipe 1 show 1: 65.536 Kbit/s0 ms5 sl. 12 queues (64 buckets) GRED w_q 0.001999 min_th 10 max_th 30 max_p 0.01 mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp kes# ipfw add 1 pipe 1 all from 10.10.16.1 to 10.10.16.18 1 pipe 1 ip from 10.10.16.1 to 10.10.16.18 kes# ping -s 1472 10.10.16.18 PING 10.10.16.18 (10.10.16.18): 1472 data bytes 1480 bytes from 10.10.16.18: icmp_seq=0 ttl=128 time=192.354 ms 1480 bytes from 10.10.16.18: icmp_seq=1 ttl=128 time=184.393 ms 1480 bytes from 10.10.16.18: icmp_seq=2 ttl=128 time=184.614 ms 1480 bytes from 10.10.16.18: icmp_seq=3 ttl=128 time=184.217 ms 1480 bytes from 10.10.16.18: icmp_seq=4 ttl=128 time=184.402 ms ^C --- 10.10.16.18 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 184.217/185.996/192.354/3.181 ms As I describe earlier: bw capability of this pipe is 8Kbytes/sec. It means 8Kb will be trasfered with timeout of 1sec. 1500bytes will be trasfered with timeout: 1500/8000 ~0.187sec You can see time=184 in ping result. All is Ok. Now when I: kes# sysctl
Re: IPFW DUMMYNET: Several pipes after each other
On Mon, 26 Jan 2009, Sebastian Mellmann wrote: Ian Smith wrote: On Thu, 22 Jan 2009 08:10:09 +0100 (CET) So far I've got those rules: in_if=em0 out_if=em1 management_if=em2 in_ip=100.100.100.1 out_ip=200.200.200.1 management_ip=172.16.0.201 client1_subnet=192.168.5.0/26 client2_subnet=192.168.6.0/26 server_subnet=192.168.7.0/24 download_bandwidth=6144Kbit/s upload_bandwidth=1024Kbit/s delay=0 queue_size=10 10 slots ie packets is likely too small a queue size at these rates. You want to check the dropped packet stats from 'ipfw pipe show' re that; see the section in ipfw(8) about calculating sizes / delays. I had a look at the ipfw howto on the freebsd site [1], but I'm not 100% sure how to choose a good value for the queue size. Neither am I :) but I'm using some values that seem to work ok. Well actually, on checking since we went from 1500/256kbps to 8192/384k, I might play a bit more, noticing 0.6% or so drops on a couple of pipes. [1] http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO That's a very good ipfw tutorial, given parts of it are a bit outdated (FreeBSD 4.x) but it covers a lot of useful background. I just skimmed lots of it now but nothing I read jarred, unlike the Handbook section. If I choose the default (50 packets) it means that it takes approx. 100ms (600kbits / 6144kbits) to fill the queue. So the question is: Which value to choose for the queue? It's going to depend on lots of things, your workload, upstream push .. you could start with more like the default and adjust as necessary? I suggest using 'in recv' and 'out xmit' rather than via for these, for the sake of clarity. 'in recv' and 'in via' come to the same thing, as only the receive interface is known on inbound packets, but 'out via' applies to packets that were *received* on the specified interface as well as those going out on that interface after routing, which can lead to surprising results sometimes, and being more specific never hurts .. Thanks for the hint. I'll change that. Also, I'd take both that howto's and ipfw(8)'s advice about your faster inside pipe, and use one pipe per flow/direction (ie full duplex). But when I have a look at the pipes with 'ipfw show' I can only see packets go through the pipe 50 and nothing goes through the other pipes (which makes sense actually since IPFW work that way?). IPFW works that way if you (likely) have net.inet.ip.fw.one_pass=1 .. so that packets exiting from pipes aren't seen by the firewall again. If you set one_pass=0, packets are reinjected into the firewall at the rule following the pipe (or queue) action, which is what you want to do here. Actually this is also described in the manpage of ipfw(8). Shame on me ;-) As penance, read 7 times before sleeping with it under your pillow :) And you'll surely need a much larger queue for this pipe, at 100Mbit/s. As already asked above: How do I know the queue is large or small enough for my needs? I'm never sure, so tend to experiment. How fast your hardware is and kern.hz setting could be significant factors, as could be TCP/UDP mix and other factors I know little about. Reducing reported packet drops is about all I've used for a guide so far. This one is a FreeBSd 4.8 box, a 2.4GHz P4 doing little but being a filtering bridge between a 8192/384kbps ADSL link and nests of mostly XP boxes in 3 LAN groups: !ipfw pipe show | egrep 'tcp|bit' 00010: 256.000 Kbit/s0 ms 30 KB 1 queues (1 buckets) droptail 0 tcp 192.168.0.23/1043 207.46.17.61/807196387 2897628161 00 9706 00020: 5.120 Mbit/s0 ms 50 KB 1 queues (1 buckets) droptail 0 tcp 207.46.17.61/80 192.168.0.23/1043 9977802 12858014698 0 0 63260 00040: 96.000 Kbit/s0 ms 20 KB 1 queues (1 buckets) droptail 0 tcp 192.168.0.45/103766.249.89.147/443 2315107 299340364 00 2086 00050: 1.536 Mbit/s0 ms 40 KB 1 queues (1 buckets) droptail 0 tcp66.249.89.147/443 192.168.0.45/1037 3279021 3802388928 00 22433 00060: 192.000 Kbit/s0 ms 30 KB 1 queues (1 buckets) droptail 0 tcp 192.168.0.64/1032207.46.106.36/1863 1847947 563209421 00 141 00070: 3.072 Mbit/s0 ms 40 KB 1 queues (1 buckets) droptail 0 tcp207.46.106.36/1863 192.168.0.64/1032 2438211 3075075035 00 4550 It's nearly all streaming rather than more interactive traffic, so pipe latency isn't so much of a concern. Anyway, I rarely actually catch any traffic still in-queue, which you can stare at for tuning. Also, that's aggregate traffic, not per IP as with your masks (which look maybe wider than necessary, 0x covers a /16) so you may wind up with lots of separate queues sharing a pipe, which may look very different. How many hosts, how much memory to spare for each?
Re: IPFW DUMMYNET: Several pipes after each other
Ian Smith wrote: That's a very good ipfw tutorial, given parts of it are a bit outdated (FreeBSD 4.x) but it covers a lot of useful background. I just skimmed lots of it now but nothing I read jarred, unlike the Handbook section. If I choose the default (50 packets) it means that it takes approx. 100ms (600kbits / 6144kbits) to fill the queue. So the question is: Which value to choose for the queue? It's going to depend on lots of things, your workload, upstream push .. you could start with more like the default and adjust as necessary? Sounds like a good idea. I'll just start with the default and see if works in my setup. And you'll surely need a much larger queue for this pipe, at 100Mbit/s. As already asked above: How do I know the queue is large or small enough for my needs? I'm never sure, so tend to experiment. How fast your hardware is and kern.hz setting could be significant factors, as could be TCP/UDP mix and other factors I know little about. Reducing reported packet drops is about all I've used for a guide so far. This one is a FreeBSd 4.8 box, a 2.4GHz P4 doing little but being a filtering bridge between a 8192/384kbps ADSL link and nests of mostly XP boxes in 3 LAN groups: !ipfw pipe show | egrep 'tcp|bit' 00010: 256.000 Kbit/s0 ms 30 KB 1 queues (1 buckets) droptail 0 tcp 192.168.0.23/1043 207.46.17.61/807196387 2897628161 0 0 9706 00020: 5.120 Mbit/s0 ms 50 KB 1 queues (1 buckets) droptail 0 tcp 207.46.17.61/80 192.168.0.23/1043 9977802 12858014698 00 63260 00040: 96.000 Kbit/s0 ms 20 KB 1 queues (1 buckets) droptail 0 tcp 192.168.0.45/103766.249.89.147/443 2315107 299340364 0 0 2086 00050: 1.536 Mbit/s0 ms 40 KB 1 queues (1 buckets) droptail 0 tcp66.249.89.147/443 192.168.0.45/1037 3279021 3802388928 0 0 22433 00060: 192.000 Kbit/s0 ms 30 KB 1 queues (1 buckets) droptail 0 tcp 192.168.0.64/1032207.46.106.36/1863 1847947 563209421 0 0 141 00070: 3.072 Mbit/s0 ms 40 KB 1 queues (1 buckets) droptail 0 tcp207.46.106.36/1863 192.168.0.64/1032 2438211 3075075035 0 0 4550 It's nearly all streaming rather than more interactive traffic, so pipe latency isn't so much of a concern. Anyway, I rarely actually catch any traffic still in-queue, which you can stare at for tuning. Also, that's aggregate traffic, not per IP as with your masks (which look maybe wider than necessary, 0x covers a /16) so you may wind up with lots of separate queues sharing a pipe, which may look very different. How many hosts, how much memory to spare for each? Is there any chance to get the dropped packets for _each_ queue (e.g. logged to a file for further investigation)? Does ipfw provide something here? I'm mainly doing experiments with different kinds of settings (bandwidth limitations, variable delay, dropped packets probability etcpp.) and I want to see how many packets are actually dropped by ipfw. HTH, Ian Regards and thanks for the help so far, Sebastian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re[2]: IPFW DUMMYNET: Several pipes after each other
Здравствуйте, Sebastian. Вы писали 26 января 2009 г., 12:16:18: SM Ian Smith wrote: SM On Thu, 22 Jan 2009 08:10:09 +0100 (CET) So far I've got those rules: in_if=em0 out_if=em1 management_if=em2 in_ip=100.100.100.1 out_ip=200.200.200.1 management_ip=172.16.0.201 client1_subnet=192.168.5.0/26 client2_subnet=192.168.6.0/26 server_subnet=192.168.7.0/24 download_bandwidth=6144Kbit/s upload_bandwidth=1024Kbit/s delay=0 queue_size=10 10 slots ie packets is likely too small a queue size at these rates. You want to check the dropped packet stats from 'ipfw pipe show' re that; see the section in ipfw(8) about calculating sizes / delays. SM I had a look at the ipfw howto on the freebsd site [1], but I'm not 100% SM sure how to choose a good value for the queue size. SM If I choose the default (50 packets) it means that it takes approx. 100ms SM (600kbits / 6144kbits) to fill the queue. SM So the question is: Which value to choose for the queue? I suggest using 'in recv' and 'out xmit' rather than via for these, for the sake of clarity. 'in recv' and 'in via' come to the same thing, as only the receive interface is known on inbound packets, but 'out via' applies to packets that were *received* on the specified interface as well as those going out on that interface after routing, which can lead to surprising results sometimes, and being more specific never hurts .. SM Thanks for the hint. SM I'll change that. But when I have a look at the pipes with 'ipfw show' I can only see packets go through the pipe 50 and nothing goes through the other pipes (which makes sense actually since IPFW work that way?). IPFW works that way if you (likely) have net.inet.ip.fw.one_pass=1 .. so that packets exiting from pipes aren't seen by the firewall again. If you set one_pass=0, packets are reinjected into the firewall at the rule following the pipe (or queue) action, which is what you want to do here. SM Actually this is also described in the manpage of ipfw(8). SM Shame on me ;-) And you'll surely need a much larger queue for this pipe, at 100Mbit/s. SM As already asked above: SM How do I know the queue is large or small enough for my needs? How calculate queue length for your link speed: suggest link speed is 64kbit/s = 8KB/s 50pkts in queue is 75000bytes (50*1500) ~73KB 73KB/8KB = 9sec so for bandwidth 64kbit you will have timeout 9000ms if queue is full. For example you want to have only 1000ms timeouts (ping) 1 * 8KB = 8KB. This max information transmited before queue will overflow for given timeout. 8Kb/1500= 5 -- value for your queue size For links with speed 512Kbit your queue size 50 I use next values for queues: c pipe 1 config bw 65536bit/s queue 5 mask src-ip 0x gred 0.002/10/30/0.1 c pipe 2 config bw 65536bit/s queue 5 mask dst-ip 0x gred 0.002/10/30/0.1 c queue 1 config pipe 1 queue 5 mask src-ip 0x gred 0.002/10/30/0.1 c queue 2 config pipe 2 queue 5 mask dst-ip 0x gred 0.002/10/30/0.1 c pipe 3 config bw 131072bit/s mask src-ip 0x gred 0.002/10/30/0.1 c pipe 4 config bw 131072bit/s mask dst-ip 0x gred 0.002/10/30/0.1 c queue 3 config pipe 3 queue 10 mask src-ip 0x gred 0.002/10/30/0.1 c queue 4 config pipe 4 queue 10 mask dst-ip 0x gred 0.002/10/30/0.1 c pipe 5 config bw 262144bit/s mask src-ip 0x gred 0.002/10/30/0.1 c pipe 6 config bw 262144bit/s mask dst-ip 0x gred 0.002/10/30/0.1 c queue 5 config pipe 5 queue 20 mask src-ip 0x gred 0.002/10/30/0.1 c queue 6 config pipe 6 queue 20 mask dst-ip 0x gred 0.002/10/30/0.1 c pipe 7 config bw 524288bit/s mask src-ip 0x gred 0.002/10/30/0.1 c pipe 8 config bw 524288bit/s mask dst-ip 0x gred 0.002/10/30/0.1 c queue 7 config pipe 7 queue 40 mask src-ip 0x gred 0.002/10/30/0.1 c queue 8 config pipe 8 queue 40 mask dst-ip 0x gred 0.002/10/30/0.1 c pipe 9 config bw 1048576bit/s mask src-ip 0x gred 0.002/10/30/0.1 c pipe 10 config bw 1048576bit/s mask dst-ip 0x gred 0.002/10/30/0.1 c queue 9 config pipe 9 queue 50 mask src-ip 0x gred 0.002/10/30/0.1 c queue 10 config pipe 10 queue 50 mask dst-ip 0x gred 0.002/10/30/0.1 c pipe 11 config bw 2097152bit/s mask src-ip 0x gred 0.002/10/30/0.1 c pipe 12 config bw 2097152bit/s mask dst-ip 0x gred 0.002/10/30/0.1 c queue 11 config pipe 11 queue 50 mask src-ip 0x gred 0.002/10/30/0.1 c queue 12 config pipe 12 queue 50 mask dst-ip 0x gred 0.002/10/30/0.1 WARNING!!! you must use own queue/pipe for in/out traffic. In case you put in and out traffic to one pipe/queue you will simulate asyncrounous link!!! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFW DUMMYNET: Several pipes after each other
On Tue, 27 Jan 2009, Sebastian Mellmann wrote: Ian Smith wrote: [..] 00060: 192.000 Kbit/s0 ms 30 KB 1 queues (1 buckets) droptail 0 tcp 192.168.0.64/1032207.46.106.36/1863 1847947 563209421 0 0 141 00070: 3.072 Mbit/s0 ms 40 KB 1 queues (1 buckets) droptail 0 tcp207.46.106.36/1863 192.168.0.64/1032 2438211 3075075035 0 0 4550 It's nearly all streaming rather than more interactive traffic, so pipe latency isn't so much of a concern. Anyway, I rarely actually catch any traffic still in-queue, which you can stare at for tuning. Just for reference re KES' message re ping times with a full queue: we only put established TCP traffic through these pipes; ICMP always, and UDP so far - unless/until it becomes an issue - are free-flowing here. Also, that's aggregate traffic, not per IP as with your masks (which look maybe wider than necessary, 0x covers a /16) so you may wind up with lots of separate queues sharing a pipe, which may look very different. How many hosts, how much memory to spare for each? Is there any chance to get the dropped packets for _each_ queue (e.g. logged to a file for further investigation)? Does ipfw provide something here? I don't know, I've only seen 'ipfw pipe show' results here. If you have numbered queues specified too, I guess 'ipfw queue show' would be what to try; if that's any use you could append results to a file/s by cron? I'm mainly doing experiments with different kinds of settings (bandwidth limitations, variable delay, dropped packets probability etcpp.) and I want to see how many packets are actually dropped by ipfw. Happy experimenting .. soon you'll be the expert we can all consult :) If you want to get deeper into it, freebsd-net is the appropriate list. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFW DUMMYNET: Several pipes after each other
Ian Smith wrote: On Thu, 22 Jan 2009 08:10:09 +0100 (CET) So far I've got those rules: in_if=em0 out_if=em1 management_if=em2 in_ip=100.100.100.1 out_ip=200.200.200.1 management_ip=172.16.0.201 client1_subnet=192.168.5.0/26 client2_subnet=192.168.6.0/26 server_subnet=192.168.7.0/24 download_bandwidth=6144Kbit/s upload_bandwidth=1024Kbit/s delay=0 queue_size=10 10 slots ie packets is likely too small a queue size at these rates. You want to check the dropped packet stats from 'ipfw pipe show' re that; see the section in ipfw(8) about calculating sizes / delays. I had a look at the ipfw howto on the freebsd site [1], but I'm not 100% sure how to choose a good value for the queue size. If I choose the default (50 packets) it means that it takes approx. 100ms (600kbits / 6144kbits) to fill the queue. So the question is: Which value to choose for the queue? I suggest using 'in recv' and 'out xmit' rather than via for these, for the sake of clarity. 'in recv' and 'in via' come to the same thing, as only the receive interface is known on inbound packets, but 'out via' applies to packets that were *received* on the specified interface as well as those going out on that interface after routing, which can lead to surprising results sometimes, and being more specific never hurts .. Thanks for the hint. I'll change that. But when I have a look at the pipes with 'ipfw show' I can only see packets go through the pipe 50 and nothing goes through the other pipes (which makes sense actually since IPFW work that way?). IPFW works that way if you (likely) have net.inet.ip.fw.one_pass=1 .. so that packets exiting from pipes aren't seen by the firewall again. If you set one_pass=0, packets are reinjected into the firewall at the rule following the pipe (or queue) action, which is what you want to do here. Actually this is also described in the manpage of ipfw(8). Shame on me ;-) And you'll surely need a much larger queue for this pipe, at 100Mbit/s. As already asked above: How do I know the queue is large or small enough for my needs? cheers, Ian Regards, Sebastian [1] http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFW DUMMYNET: Several pipes after each other
On Thu, 22 Jan 2009 08:10:09 +0100 (CET) Sebastian Mellmann sebastian.mellm...@net.t-labs.tu-berlin.de wrote: I'm using FreeBSD 7.0 with IPFW DUMMYNET enabled. I've got a problem with creating a ruleset which allows me to limit the overall bandwidth of a link and afterwards pass the packets to another pipe for processing. So far I've got those rules: in_if=em0 out_if=em1 management_if=em2 in_ip=100.100.100.1 out_ip=200.200.200.1 management_ip=172.16.0.201 client1_subnet=192.168.5.0/26 client2_subnet=192.168.6.0/26 server_subnet=192.168.7.0/24 download_bandwidth=6144Kbit/s upload_bandwidth=1024Kbit/s delay=0 queue_size=10 10 slots ie packets is likely too small a queue size at these rates. You want to check the dropped packet stats from 'ipfw pipe show' re that; see the section in ipfw(8) about calculating sizes / delays. On the other hand, depending on how many hosts you're running individual queues for (mask 0x), you may need to trade with memory used .. cmd=ipfw $cmd add 10 allow all from any to any via lo0 $cmd pipe 100 config mask src-ip 0x bw $upload_bandwidth queue $queue_size delay $delay $cmd pipe 200 config mask dst-ip 0x bw $download_bandwidth queue $queue_size $cmd add pipe 100 all from $client1_subnet to $server_subnet in via $in_if $cmd add pipe 200 all from $server_subnet to $client1_subnet out via $in_if $cmd add pipe 100 all from $client2_subnet to $server_subnet in via $in_if $cmd add pipe 200 all from $server_subnet to $client2_subnet out via $in_if I suggest using 'in recv' and 'out xmit' rather than via for these, for the sake of clarity. 'in recv' and 'in via' come to the same thing, as only the receive interface is known on inbound packets, but 'out via' applies to packets that were *received* on the specified interface as well as those going out on that interface after routing, which can lead to surprising results sometimes, and being more specific never hurts .. $cmd add 1 allow all from any to any via $management_if $cmd add 2 allow all from any to any via $in_if $cmd add 3 allow all from any to any via $out_if --- What I want to add now, is the possibility to limit the bandwidth of the whole link, e.g. 100Mbit/s. I've tried to add a pipe: $cmd pipe 50 config bw 100Mbit/s queue $queue_size $cmd add pipe 50 all from any to any via $in_if But when I have a look at the pipes with 'ipfw show' I can only see packets go through the pipe 50 and nothing goes through the other pipes (which makes sense actually since IPFW work that way?). IPFW works that way if you (likely) have net.inet.ip.fw.one_pass=1 .. so that packets exiting from pipes aren't seen by the firewall again. If you set one_pass=0, packets are reinjected into the firewall at the rule following the pipe (or queue) action, which is what you want to do here. And you'll surely need a much larger queue for this pipe, at 100Mbit/s. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
IPFW DUMMYNET: Several pipes after each other
Hi! I'm using FreeBSD 7.0 with IPFW DUMMYNET enabled. I've got a problem with creating a ruleset which allows me to limit the overall bandwidth of a link and afterwards pass the packets to another pipe for processing. So far I've got those rules: in_if=em0 out_if=em1 management_if=em2 in_ip=100.100.100.1 out_ip=200.200.200.1 management_ip=172.16.0.201 client1_subnet=192.168.5.0/26 client2_subnet=192.168.6.0/26 server_subnet=192.168.7.0/24 download_bandwidth=6144Kbit/s upload_bandwidth=1024Kbit/s delay=0 queue_size=10 cmd=ipfw $cmd add 10 allow all from any to any via lo0 $cmd pipe 100 config mask src-ip 0x bw $upload_bandwidth queue $queue_size delay $delay $cmd pipe 200 config mask dst-ip 0x bw $download_bandwidth queue $queue_size $cmd add pipe 100 all from $client1_subnet to $server_subnet in via $in_if $cmd add pipe 200 all from $server_subnet to $client1_subnet out via $in_if $cmd add pipe 100 all from $client2_subnet to $server_subnet in via $in_if $cmd add pipe 200 all from $server_subnet to $client2_subnet out via $in_if $cmd add 1 allow all from any to any via $management_if $cmd add 2 allow all from any to any via $in_if $cmd add 3 allow all from any to any via $out_if --- What I want to add now, is the possibility to limit the bandwidth of the whole link, e.g. 100Mbit/s. I've tried to add a pipe: $cmd pipe 50 config bw 100Mbit/s queue $queue_size $cmd add pipe 50 all from any to any via $in_if But when I have a look at the pipes with 'ipfw show' I can only see packets go through the pipe 50 and nothing goes through the other pipes (which makes sense actually since IPFW work that way?). Any help is much appreciated. Thanks in advance. Sebastian M. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Strange hang with dummynet
On 16 Sep 2008, at 14:38 , Nikola Kne?evi? wrote: I'm running FreeBSD 7.1-PRERELEASE with custom kernel on my box, and when I did: kldload dummynet kldload ipfw the machine just hanged - I couldn't access it over ssh, and current sessions were blocked. This happens also with GENERIC. I didn't touch anything related to ipfw or dummynet's configuration (that I know). Any thoughts? How can I debug this? To reply to myself, for future reference :) dummynet loads ipfw, which has the default rule of drop all. Thus machines shows as inaccessible/unresponsive. Cheers, Nikola ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Bidirectional traffic control with PF and altq or dummynet
I have been using PF for several years now and used IPFW previous to PF that I've grown more and more fond of. I now need to manage bidirectional traffic I have used Dummynet before to do similar things but it is my understanding that Altq can only manage outgoing traffic. My questions are: Am I correct in saying that Altq can not manage bidirectional traffic? if not I understand the dummynet can be used with pf and if so does anyone know of a howto to get me started? Thanks, ed ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Bidirectional traffic control with PF and altq or dummynet
I have been using PF for several years now and used IPFW previous to PF that I've grown more and more fond of. I now need to manage bidirectional traffic I have used Dummynet before to do similar things but it is my understanding that Altq can only manage outgoing traffic although I find the occasional example of it managing incoming like one to limit window's email assuming that I'm reading it properly. My questions are: Am I correct in saying that Altq can not manage bidirectional traffic? if not I understand the dummynet can be used with pf and if so does anyone know of a howto to get me started? I would rather not switch to IPFW right now. Thanks, ed ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bidirectional traffic control with PF and altq or dummynet
Edwin L. Culp wrote: I have been using PF for several years now and used IPFW previous to PF that I've grown more and more fond of. I now need to manage bidirectional traffic I have used Dummynet before to do similar things but it is my understanding that Altq can only manage outgoing traffic although I find the occasional example of it managing incoming like one to limit window's email assuming that I'm reading it properly. My questions are: Am I correct in saying that Altq can not manage bidirectional traffic? based on what I have read of man pf.conf, I'd say nup. 'The interfaces on which queueing should be activated are declared' If you can set it on multiple devices then applying altq bidirectionaly on traffic going through should be no prob. If its traffic to and from the box in question I don't know. HTH cya Andrew if not I understand the dummynet can be used with pf and if so does anyone know of a howto to get me started? I would rather not switch to IPFW right now. Thanks, ed ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 7.0 and DummyNet
It's been a long time since I have tried to get dummynet working. I have a FreeBSD 7.0 box ready to go. Do I still need to recompile the kernel and all that stuff or is there any easier way to do this now? -- Ray Seals - Office: 314-594-0150 (St. Louis Area) 866-875-8863 (toll free) Fax: 253-681-9982 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0 and DummyNet
Ray Seals wrote: It's been a long time since I have tried to get dummynet working. I have a FreeBSD 7.0 box ready to go. Do I still need to recompile the kernel and all that stuff or is there any easier way to do this now? I tend to use pf/altq but dummynet and ipfw seem to exist as modules [EMAIL PROTECTED] (19:09:46 /usr/src/sys/amd64/conf) 0 # ls /boot/kernel/dummynet.ko /boot/kernel/dummynet.ko* [EMAIL PROTECTED] (19:10:08 /usr/src/sys/amd64/conf) 0 # ls /boot/kernel/ipfw.ko /boot/kernel/ipfw.ko* so kldload dummynet kldload ipfw should do the job. Vince ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0 and DummyNet
Vince Hoffman wrote: Ray Seals wrote: It's been a long time since I have tried to get dummynet working. I have a FreeBSD 7.0 box ready to go. Do I still need to recompile the kernel and all that stuff or is there any easier way to do this now? I tend to use pf/altq but dummynet and ipfw seem to exist as modules [EMAIL PROTECTED] (19:09:46 /usr/src/sys/amd64/conf) 0 # ls /boot/kernel/dummynet.ko /boot/kernel/dummynet.ko* [EMAIL PROTECTED] (19:10:08 /usr/src/sys/amd64/conf) 0 # ls /boot/kernel/ipfw.ko /boot/kernel/ipfw.ko* so kldload dummynet kldload ipfw should do the job. Oh and remember that if you do just kldload ipfw (like i just did to test) it defaults to deny all ;) Vince Vince ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW / Dummynet problem
Hi, My FreeBSD machine is configured as a bridge between two networks: |-||-| | LAN | --- vr0 --bridge0-- vr1 -- | WAN | |-||-| The following firewall ruleset works fine: add 00600 allow all from any to any via vr0 keep-state add 00610 allow tcp from any to any 22 in via vr1 setup keep-state add 00611 allow tcp from any to any 23 in via vr1 setup keep-state add 00612 allow tcp from any to any 113 in via vr1 setup keep-state add 00613 allow icmp from any to any icmptypes 11 add 00620 check-state add 00630 deny all from any to any via vr1 add 00640 allow all from 192.168.1.30 to any add 00641 allow all from any to 192.168.1.30 I then add the following dummynet rules before these. The LAN continues to work (queueing is only applied to the vr1 WAN interface), the WAN continues to work from the bridge machine itself (192.168.1.30) but outbound HTTP connections from any client on the LAN fail. pipe 1 config bw 2Mbit/s queue 1 pipe 2 config bw 256Kbit/s queue 1 queue 1 config weight 10 pipe 1 queue 20 mask dst-ip 0x queue 2 config weight 10 pipe 2 queue 20 mask src-ip 0x queue 3 config weight 2 pipe 1 queue 100 mask dst-ip 0x queue 4 config weight 2 pipe 2 queue 10 mask src-ip 0x queue 5 config weight 1 pipe 1 queue 100 mask dst-ip 0x queue 6 config weight 1 pipe 2 queue 10 mask src-ip 0x add 00500 queue 1 tcp from any to any in via vr1 tcpflags ack iplen 0-52 add 00501 queue 2 tcp from any to any out via vr1 tcpflags ack iplen 0-52 add 00510 queue 3 udp from any to any in via vr1 add 00511 queue 4 udp from any to any out via vr1 add 00512 queue 3 tcp from any to any 22 in via vr1 add 00513 queue 4 tcp from any to any 22 out via vr1 add 00514 queue 3 tcp from any to any 993 in via vr1 add 00515 queue 4 tcp from any to any 993 out via vr1 add 00520 queue 5 all from any to any in via vr1 add 00521 queue 6 all from any to any out via vr1 I don't understand how queueing rules could affect the passing of any packet, except in delay? They do seem to match the queueing rules, e.g. rules 00520 and 00521 accumulate packets as connection attempts are made. Outbound packets even seem to pass to the WAN, so I can only assume it is an inbound/stateful problem? 00100 52 4548 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00500 30 1420 queue 1 tcp from any to any in via vr1 tcpflags ack iplen 0-52 00501 9390 queue 2 tcp from any to any out via vr1 tcpflags ack iplen 0-52 00510 2152 queue 3 udp from any to any in via vr1 00511 7528 queue 4 udp from any to any out via vr1 00512 0 0 queue 3 tcp from any to any dst-port 22 in via vr1 00513 0 0 queue 4 tcp from any to any dst-port 22 out via vr1 00514 0 0 queue 3 tcp from any to any dst-port 993 in via vr1 00515 18 1228 queue 4 tcp from any to any dst-port 993 out via vr1 00520 26 1988 queue 5 ip from any to any in via vr1 00521 17964 queue 6 ip from any to any out via vr1 00600 163 10082 allow ip from any to any via vr0 keep-state 00610 0 0 allow tcp from any to any dst-port 22 in via vr1 setup keep-state 00611 0 0 allow tcp from any to any dst-port 23 in via vr1 setup keep-state 00612 0 0 allow tcp from any to any dst-port 113 in via vr1 setup keep-state 00613 0 0 allow icmp from any to any icmptypes 11 00620 0 0 check-state 00630 0 0 deny ip from any to any via vr1 00640 405 102681 allow ip from 192.168.1.30 to any 00641 647 48255 allow ip from any to 192.168.1.30 65535 18 3086 deny ip from any to any Thanks for any light you can shed on this. -- Jay L. T. Cornwall http://www.jcornwall.me.uk/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dummynet lag
Is it normal to have +10msec ping times when pinging through dummynet (ipfw pipes)? If yes, why? If not, WTF? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet lag
Is it normal to have +10msec ping times when pinging through dummynet (ipfw depends how exactly it's configured pipes)? If yes, why? If not, WTF? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet lag
On Aug 31, 2007, at 6:34 AM, [EMAIL PROTECTED] wrote: Is it normal to have +10msec ping times when pinging through dummynet (ipfw pipes)? If yes, why? If not, WTF? If your HZ is 100, then, yes, it's common for the packets to be delayed by 10+ msec. Set HZ to 1000 or higher and you'll have the latency drop to circa 1 ms. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Bandwidth limiting with ipfw and dummynet
I'd like to limit him to 384Kbit/sec.Can someone help me get bandwidth limiting working? I've tried all the examples I could find via google but none of them work. My roomate is frequently uploading stuff to his office, and when he does, it completely saturates our outbound link and makes everything very pokey. His IP address is 10.0.2.195 and we've got FreeBSD set up as a router for our cable modem, with natd. I added the pipe to limit the bw: ipfw pipe 1 config bw 384Kbit I added a rule for his IP: ipfw add 10 pipe 1 tcp from 10.0.2.195 to any Doing ipfw show doesn't show any packets ever matching that rule. # ipfw show 00010 00 pipe 1 tcp from 10.0.2.195 to any 00015 00 pipe 1 tcp from any to 10.0.2.195 00050 21745 18784920 divert 8668 ip from any to any via dc0 00100 8 1036 allow ip from any to any via lo0 00200 00 deny ip from any to 127.0.0.0/8 00300 00 deny ip from 127.0.0.0/8 to any 65000 44051 37589386 allow ip from any to any 65535 00 deny ip from any to any Is the natd divert rule somehow interfering? -jsd- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
On 06/02/07, Justin Robertson [EMAIL PROTECTED] wrote: I've actually already done everything you've suggested with little or no impact at all. One point where we have different results is with ADAPTIVE_GIANT, I actually noticed a drop of about 50kpps thruput when disabling it. Hmm I am surprised not more attention has been brought by your observations, I have noticed myself freebsd 4.x holds up much better during ddos then 5.x and 6.x probably due its better robustness and lighter code. I do hope but will probably be dissapointed stability and robustness is on the todo list for the devs in aiming to get 6.x to where 4.x was. Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
At 08:03 AM 2/6/2007, Chris wrote: On 06/02/07, Justin Robertson [EMAIL PROTECTED] wrote: I've actually already done everything you've suggested with little or no impact at all. One point where we have different results is with ADAPTIVE_GIANT, I actually noticed a drop of about 50kpps thruput when disabling it. Hmm I am surprised not more attention has been brought by your observations, I have noticed myself freebsd 4.x holds up much better during ddos then 5.x and 6.x probably due its better robustness and lighter code. When I ran through the tests with pmc compiled in there wasnt any obvious areas where it was spending a lot of time. What I was told was that the locking overhead was a big penalty and more emphasis was put on correctness than speed going from RELENG_4 to RELENG_5 and above. Supposedly the payoff will come as more CPU cores get added as there is better potential to scale with this design. While I did see some improvement in the box with SMP compiled in, it still has a ways to go for this application I do hope but will probably be dissapointed stability and robustness is on the todo list for the devs in aiming to get 6.x to where 4.x was. I have found stability to be quite good. But certainly as a firewall or router, the speed is not there yet. ---Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
6.x, 4.x ipfw/dummynet pf/altq - network performance issues
So, this may be the wrong list to post to, but it seemed the most appropriate. If someone could suggest a better location to move/cross post to let me know. I've been running some tests with using FreeBSD to filter and rate limit traffic. My first thoughts were to goto the latest stable release, which was 6.1 at the time. I've since done the same test under 6.2 and haven't seen any difference. I later migrated to running 4.11 to get away from these issues, but have discovered others. I've tested on an AMD 3200+ system with dual Intel 1000 series NICs, an AMD Opteron 165 with the same, and a Xeon 2.8 with the same. I've used both stock and intel drivers. 6.x; Normal traffic isn't a problem. The second you get into the realm of abusive traffic, such a DoS/DDoS (over 100mbps) UDP floods the machine falls over. Little packets with ip lengths of 28-29 bytes seem to do the most damage. I've tried playing with various sysctl values and have seen no difference at all. By falls over I mean stops sending all traffic in any direction. TCP syn packets have the same effect, tho not quite as rapidly (200~230mbps). I then tried moving filtering off to a transparent bridge. This improved the situation somewhat, but an extra 30-40mbps of UDP data and it would ultimately crumble. Overall the machine would be able to move between 300k-600k PPS before becoming a cripple, depending on packet length, protocol, and any flags. Without a specific pf or ipfw rule to deal with a packet the box would fall over, with specific block rules it would manage an extra 30-40mbps and then fall over. 4.11; Again, normal traffic isn't a problem. When routing filtering on the same system some of the problems found in 6.x are still apparent, but to a lesser degree. Splitting the task into a transparent filtering bridge with a separate routing box appears to clear it up entirely. UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). TCP syn attacks are also better handled, again a block rule makes it seem as if there were no attack at all. The system also appears to be able to move 800-900k PPS of any one protocol at a time. However, the second you try and queue abusive traffic the machine will fall over. Inbound floods appear to cause ALL inbound traffic to lag horrifically (while rate limiting/piping), which inherently causes a lot of outbound loss due to broken TCP. Now, I'm not sure if this is something to do with dummynet being horribly inefficient, or if there's some sysctl value to deal with inbound that I'm missing. I suppose my concerns are two-fold. Why is 6.x collapsing under traffic that 4.11 could easily block and run merrily along with, and is there a queueing mechanism in place that doesn't tie up the box so much on inbound flows that it ignores all other relevant traffic? (as a note, all tests were done with device polling enabled. Without it systems fall over pretty quickly. I also tried tests using 3com cards and had the same results) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
On Mon, 05 Feb 2007 14:03:41 -0800, in sentex.lists.freebsd.questions you wrote: I suppose my concerns are two-fold. Why is 6.x collapsing under traffic that 4.11 could easily block and run merrily along with, and is there a queueing mechanism in place that doesn't tie up the box so much on inbound flows that it ignores all other relevant traffic? (as a note, all tests were done with device polling enabled. Without it systems fall over pretty quickly. I also tried tests using 3com cards and had the same results) On the 6.x box, try enabling adding to /etc/sysctl.conf kern.polling.enable=1 net.inet.ip.fastforwarding=1 kern.polling.idle_poll=1 kern.random.sys.harvest.ethernet=0 and in /boot/loader.conf, add kern.hz=2000 Also removing options ADAPTIVE_GIANT # Giant mutex is adaptive. from the kernel helps a bit as well. with kern.polling.idle_poll=1 your load avg will be messed up but it should help performance a bit. As for firewall rules, things really seem to fall down performance wise, as compared to RELENG_4. I havent found a way to improve that performance However, on the plus side, an extra core does seem to help a bit with the box remaining responsive. For NICs, stay with em or bge nics for now in RELENG_6 I have some misc test results at http://www.tancsa.com/blast.html ---Mike Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 [EMAIL PROTECTED], (http://www.tancsa.com) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
I've actually already done everything you've suggested with little or no impact at all. One point where we have different results is with ADAPTIVE_GIANT, I actually noticed a drop of about 50kpps thruput when disabling it. Mike Tancsa wrote: On Mon, 05 Feb 2007 14:03:41 -0800, in sentex.lists.freebsd.questions you wrote: I suppose my concerns are two-fold. Why is 6.x collapsing under traffic that 4.11 could easily block and run merrily along with, and is there a queueing mechanism in place that doesn't tie up the box so much on inbound flows that it ignores all other relevant traffic? (as a note, all tests were done with device polling enabled. Without it systems fall over pretty quickly. I also tried tests using 3com cards and had the same results) On the 6.x box, try enabling adding to /etc/sysctl.conf kern.polling.enable=1 net.inet.ip.fastforwarding=1 kern.polling.idle_poll=1 kern.random.sys.harvest.ethernet=0 and in /boot/loader.conf, add kern.hz=2000 Also removing options ADAPTIVE_GIANT # Giant mutex is adaptive. from the kernel helps a bit as well. with kern.polling.idle_poll=1 your load avg will be messed up but it should help performance a bit. As for firewall rules, things really seem to fall down performance wise, as compared to RELENG_4. I havent found a way to improve that performance However, on the plus side, an extra core does seem to help a bit with the box remaining responsive. For NICs, stay with em or bge nics for now in RELENG_6 I have some misc test results at http://www.tancsa.com/blast.html ---Mike Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 [EMAIL PROTECTED], (http://www.tancsa.com) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
At 09:53 PM 2/5/2007, Justin Robertson wrote: I've actually already done everything you've suggested with little or no impact at all. Are you sure you had kern.polling.idle_poll=1 enabled ? It makes a big difference in RELENG_6 with it on or off in my tests. ---Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet howto?
Hey all, In dummynet, what's an appropriate queue size for a 50 Megabit pipe? And is there a general rule-of-thumb or calcluation I should be doing (i.e. limitation size times some number or something?) -Dan -- Hitler, Satan, those Hanson kids, anything. Just not the curious anteater. -Peter Scolari, as Wayne Szalinki in Honey, I Shrunk The Kids--The Series Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet with vlans
Hey all, Note: I'm cc'ing Luigi Rizzo because, well, he's authoritative. This is NOT the same issue I asked about a couple years ago (which related to vlans, and bridging -- there is no bridge in play here). Anyway... We have a machine playing vlan aggregator. Gigabit nics (intels). em0 is the uplink to the core router. Straight gigabit link over copper to a 6500-series cisco switch (speaks OSPF using quagga). em1 is the downlink (over fiber) to the switch, and has no interface on it, but it IS a parent interface to 48 vlan entries, numbered vlan101 through vlan148 (where each is relative to a switch port). This setup works fine. Each vlan entry has it's own /29 IP address. That said, what is the proper syntax for adding dummynet rules to this? For example, to constrain one of those ports to (say) 50 megabits. I'm using pipe 440 config bw 50mbit/s pipe 441 config bw 50mbit/s add 44000 pipe 440 ip from any to any recv vlan144 in add 44001 pipe 441 ip from any to any xmit vlan144 out But this seems not to work. Do I need to define queues as well? The manpage cites examples similar to this, but I can't find any definitive reference. Should I just not use the vlan interfaces, and instead go by IP on the outside interface? -Dan -- It's buttery kettle ASS corn! -Dan Mahoney, Ezzi Computers, 10/22/03, 2AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Override dummynet delay limit
Hello,
I'm trying to override the 10 second limit to a dummynet pipe delay,
and allow it to be unlimited (or at least several minutes).
I found this email in the achives:
http://lists.freebsd.org/pipermail/freebsd-net/2004-March/003370.html
Following the email I modified /usr/src/sbin/ipfw/ipfw2.c
I changed:
if (do_pipe == 1) {
if (p.pipe_nr == 0)
errx(EX_DATAERR, pipe_nr must be 0);
if (p.delay 1)
errx(EX_DATAERR, delay must be 1);
} else { /* do_pipe == 2, queue */
to
if (do_pipe == 1) {
if (p.pipe_nr == 0)
errx(EX_DATAERR, pipe_nr must be 0);
//if (p.delay 1)
// errx(EX_DATAERR, delay must be 1);
} else { /* do_pipe == 2, queue */
and I recompiled via
in the /usr/src directory
make buildkernel KERNCONF=DUMMYNET
make installkernel KERNCONF=DUMMYNET
but I still get
prompt$ ipfw pipe 1 config delay 6
ipfw: delay must be 1
I've also tried changing that message in the source code to say something
different, but the changes aren't updated at the command line message, so it
seems my changes aren't actually be taken into effect via my approach. I've
also tried doing a recursive grep on delay must be in the /usr/src
directory thinking I might be changing the wrong file, but this is the only
place that it's logical for me to need to change to get the desired effect.
What am I doing wrong, please help?
Thank you kindly for your time,
Ryan
research assistant at Lehigh University
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Override dummynet delay limit
In the last episode (Dec 27), ryan m said: Hello, I'm trying to override the 10 second limit to a dummynet pipe delay, and allow it to be unlimited (or at least several minutes). I found this email in the achives: http://lists.freebsd.org/pipermail/freebsd-net/2004-March/003370.html Following the email I modified /usr/src/sbin/ipfw/ipfw2.c which is the source to /sbin/ipfw and I recompiled via in the /usr/src directory make buildkernel KERNCONF=DUMMYNET make installkernel KERNCONF=DUMMYNET which rebuilt the kernel and left /sbin/ipfw untouched but I still get prompt$ ipfw pipe 1 config delay 6 ipfw: delay must be 1 You need to rebuild ipfw :) cd to /usr/src/sbin/ipfw, run make obj make depend make make install . -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet fragmenting packets
In response to Mike Murphree [EMAIL PROTECTED]: Having an issue on a 5.3 system using ipfw and dummynet to create a bandwidth limited and large latency pipe for a mpeg video stream. If I pass the packets between the two NICs without routing through a dummynet pipe, it's fine. If I route it through a pipe, it's fragmenting each packet (client requested 1468 byte packets) into two packets, the second packet with an offset of 1440 bytes. Does anyone have any idea why it's doing this, and have a solution to this problem? As a general rule, fragmenting occurs when packets move between different networks with different MTUs. I.e. the originating network has a larger MTU, so the packet must be broken up in order to pass it on to the network with the smaller MTU. Now that that's out of the way, I can see 3 possibilities as to why dummynet is fragmenting packets: 1) Dummynet has the wrong information about what the MTUs are on your networks and is fragmenting the packets needlessly. 2) Dummynet is altering the packets, they become larger and then no longer fit in the MTU. 3) The endpoints are doing path-MTU-discovery, but when you put dummynet between them you somehow break PMTUD. To narrow this down, you'll need to determine what the MTUs are on each network and whether they're being respected, is the total size of the reassembled fragments the same as when the packet came in, and whether or not PMTUD is in use, and whether something in dummynet or any related filtering rules is breaking it. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet fragmenting packets
Having an issue on a 5.3 system using ipfw and dummynet to create a bandwidth limited and large latency pipe for a mpeg video stream. If I pass the packets between the two NICs without routing through a dummynet pipe, it's fine. If I route it through a pipe, it's fragmenting each packet (client requested 1468 byte packets) into two packets, the second packet with an offset of 1440 bytes. Does anyone have any idea why it's doing this, and have a solution to this problem? Thanks, Mike (please cc directly) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dummynet
Hello I want to ask You: when i configure my dummynet router with large delay time, then can packet loss happen? ,and can you show me how to increase network buffer size in dummynet router for overcoming it. ---Tuan--- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet Question
On Tuesday 26 September 2006 05:00, Sushant Sharma wrote: Hi all, I have installed dummynet on a machine-2 which I am using to introduce delay between the packets that I'll be sending from machine-1 to machine-3. I am using ping to confirm that ICMP/TCP packets are getting delayed. I know both UDP/TCP fall under ip, so UDP packets should also be getting delayed but just to confirm, do you guys know of any utility that I can use to check if UDP packets are also getting delayed. Use traceroute. Or you could run tcpdump on both ingress and egress interfaces and check the timestamps. netcat can send udp packets, bash can(if it's built this way) cat /dev/udp/192.168.0.1/snmp for example Or you could simply trust dummynet/ipfw. They work:) HTH, Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet Question
Hi all, I have installed dummynet on a machine-2 which I am using to introduce delay between the packets that I'll be sending from machine-1 to machine-3. I am using ping to confirm that ICMP/TCP packets are getting delayed. I know both UDP/TCP fall under ip, so UDP packets should also be getting delayed but just to confirm, do you guys know of any utility that I can use to check if UDP packets are also getting delayed. ipfw shows pipe 1 and queue 1 as pipe 1 ip from any to any queue 1 ip from any to any I am running linux on machine-1 and machine-3. TIA -Sushant ps: please cc the reply to me also as I am not subscribed to the list. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Help about dynamic rule dummynet
Hi,
I've old problem with dynamic rule dummynet. I've internet cafe and of
couse they could using download accelerator for download large file
from HTTP/FTP server. In this case they use Freshget or something like
that. In /etc/rc.firewall I have rule like:
# Downstream for client
ipcl=192.168.0.0/24{1,10,11,12,13,14,50}
bwdown=68Kbit/s
${fwcmd} add 52 queue 1 ip from any to ${ipcl} out via ${ifint}
${fwcmd} queue 1 config weight 5 pipe 2 mask dst-ip 0x00ff
${fwcmd} pipe 2 config bw ${bwdown}
# Upstream for client
bwup=36Kbit/s
${fwcmd} add 53 queue 2 ip from ${ipcl} to any in via ${ifint}
${fwcmd} queue 2 config weight 5 pipe 3 mask src-ip 0x00ff
${fwcmd} pipe 3 config bw ${bwup}
My LAN using private ip address block C (192.168.0.0/24), my client's
ip address 192.168.0.1, 192.168.0.10 - 192.168.0.14, ${ifint} is
inside interface, also I use 4.10-STABLE FreeBSD.
This illustration with output iftop:
www.yahoo.com= client10.example.com 1.91Kb 1.93Kb 1.82Kb
www.hotmail.com = client11.example.com 1.90Kb 1.91Kb 1.80Kb
www.friendster.com = client12.example.com 1.50Kb 1.52Kb 1.51Kb
www.geocities.com= client13.example.com 1.60Kb 1.64Kb 1.61Kb
www.geocities.com= client14.example.com 1.54Kb 1.57Kb 1.53Kb
ftp.freebsd.org = client01.example.com 10.92Kb 10.90Kb 10.89Kb
ftp.freebsd.org = client01.example.com 11.87Kb 11.91Kb 11.90Kb
ftp.freebsd.org = client01.example.com 12.88Kb 12.91Kb 12.89Kb
ftp.freebsd.org = client01.example.com 10.70Kb 10.72Kb 10.71Kb
ftp.freebsd.org = client01.example.com 10.75Kb 10.78Kb 10.77Kb
If 192.168.0.1 using accelerator to download large file and splited to
5 file simultantly, the client's (192.168.0.10 - 192.168.0.14) will
exhausted bandwidht.
How to resolve this problem, any suggestion?
TIA
--
budsz
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet in an IPFilter setup
Hiya,
Since freebsd-ipfw is dead and mostly for spammers, let me try my luck
here once more ;)
I am trying to prove a point to a customer - that he can save the cost
of expensive routing hardware by just having a FreeBSD box on their LAN.
Unfortunately, this also means that I need to spend days reading about
IPFW, which, sincerely, is not one of those firewall implementations
that is easy for me. I therefore need help to prove a point and keep
a customer..
The scenario:
I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
interfaces at the moment, external interface connected to the hostile
Internet and internal interface connected to a switch for the LAN.
The ISP gives 256Kbit/s on the external interface. Out of this, I
need to dedicate/guarantee 128Kbit/s to just one machine.
A streaming server has been introduced on the LAN, and it is considered
a VIP host as far as bandwidth allocation is concerned.
The problem is that p2p is also officially allowed on the LAN. I hate
it but it is allowed. Period. No argument about it.
I need to guarantee 128Kbit/s of the available bandwidth to the
streaming host (server, if you can call it).
My thinking/plan:
1. Add one more NIC to the FreeBSD box (it's also the router,
firewall, _everything_ server) and put this on a separate IP block.
To this NIC I will connect the VIP host, which needs the guaranteed
bandwidth. I will therefore NAT traffic to/from it.
2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
this means that:
(a) They cannot go beyond 128Kbit/s
(b) The VIP box will go above 128K/bit's in case the throttled
LAN is not using all of the 128Kbit/s
I need to control bandwidth on the external interface only, not on the
LAN (internal interfaces).
Is this rightful thinking or sheer imagination which is not practical?
My problem:
Most important is being dumb when it comes to IPFW and hence the pipes
and all that pertains to it.
Here is my ipfw configuration, in black and white (firewall_type=OPEN)
# Outside interface network and netmask and ip
oif=bfe0
iif=xl0
onet=62.8.68.0
omask=255.255.255.252
oip=62.8.68.22
# Inside interface network and netmask and ip
iif=xl0
inet=10.0.0.0
imask=255.255.255.0
iip=10.0.0.2
ipfw pipe 1 config bw 128Kbit/s
# Allow any traffic to or from my own net.
${fwcmd} add pass all from ${iip} to ${inet}:${imask}
${fwcmd} add pass all from ${inet}:${imask} to ${iip}
# Throttle now
ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif} state
${fwcmd} add 65000 pass all from any to any
With this configuration, it seems like even LAN-LAN communication is
being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
Can someone tell me why that is happening?
Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
bandwidth limitation configuration, is it not true that I will have
achieved my goal?
I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
have a static route for the VIP box, with NAT for any connections
to/from it.
I'll really appreciate any help/advise towards a perfect configuration
for the firewall, and how I can get this to work.
Thanks in advance.
-Wash
http://www.netmeister.org/news/learn2quote.html
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--
+==+
|\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED]
Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com
|,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922
'---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121
+==+
Minnie Mouse is a slow maze learner.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
In response to Odhiambo Washington [EMAIL PROTECTED]:
[snip]
The scenario:
I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
interfaces at the moment, external interface connected to the hostile
Internet and internal interface connected to a switch for the LAN.
The ISP gives 256Kbit/s on the external interface. Out of this, I
need to dedicate/guarantee 128Kbit/s to just one machine.
A streaming server has been introduced on the LAN, and it is considered
a VIP host as far as bandwidth allocation is concerned.
The problem is that p2p is also officially allowed on the LAN. I hate
it but it is allowed. Period. No argument about it.
I need to guarantee 128Kbit/s of the available bandwidth to the
streaming host (server, if you can call it).
My thinking/plan:
1. Add one more NIC to the FreeBSD box (it's also the router,
firewall, _everything_ server) and put this on a separate IP block.
To this NIC I will connect the VIP host, which needs the guaranteed
bandwidth. I will therefore NAT traffic to/from it.
2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
this means that:
(a) They cannot go beyond 128Kbit/s
(b) The VIP box will go above 128K/bit's in case the throttled
LAN is not using all of the 128Kbit/s
I need to control bandwidth on the external interface only, not on the
LAN (internal interfaces).
Is this rightful thinking or sheer imagination which is not practical?
Seems reasonable. See below ...
My problem:
Most important is being dumb when it comes to IPFW and hence the pipes
and all that pertains to it.
Here is my ipfw configuration, in black and white (firewall_type=OPEN)
# Outside interface network and netmask and ip
oif=bfe0
iif=xl0
onet=62.8.68.0
omask=255.255.255.252
oip=62.8.68.22
# Inside interface network and netmask and ip
iif=xl0
inet=10.0.0.0
imask=255.255.255.0
iip=10.0.0.2
ipfw pipe 1 config bw 128Kbit/s
# Allow any traffic to or from my own net.
${fwcmd} add pass all from ${iip} to ${inet}:${imask}
${fwcmd} add pass all from ${inet}:${imask} to ${iip}
# Throttle now
ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif} state
^^
Is this direct cut/paste? If so, you've got a sticky $ key.
${fwcmd} add 65000 pass all from any to any
With this configuration, it seems like even LAN-LAN communication is
being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
Can someone tell me why that is happening?
Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
bandwidth limitation configuration, is it not true that I will have
achieved my goal?
I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
have a static route for the VIP box, with NAT for any connections
to/from it.
I'll really appreciate any help/advise towards a perfect configuration
for the firewall, and how I can get this to work.
Thanks in advance.
--
Bill Moran
Collaborative Fusion Inc.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
Odhiambo Washington wrote: I need to control bandwidth on the external interface only, not on the LAN (internal interfaces). Is this rightful thinking or sheer imagination which is not practical? If you're happy with IPFilter and need to ensure minimum bandwidth for some network segment, take a look at packet filter, you can take much of your knowledge with you and then set up queues that will ensure the minimum bandwidth. And you don't need extra interfaces. Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
* On 20/09/06 11:16 -0400, Bill Moran wrote:
| In response to Odhiambo Washington [EMAIL PROTECTED]:
|
| [snip]
|
| The scenario:
|
| I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
| interfaces at the moment, external interface connected to the hostile
| Internet and internal interface connected to a switch for the LAN.
|
| The ISP gives 256Kbit/s on the external interface. Out of this, I
| need to dedicate/guarantee 128Kbit/s to just one machine.
|
| A streaming server has been introduced on the LAN, and it is considered
| a VIP host as far as bandwidth allocation is concerned.
| The problem is that p2p is also officially allowed on the LAN. I hate
| it but it is allowed. Period. No argument about it.
|
| I need to guarantee 128Kbit/s of the available bandwidth to the
| streaming host (server, if you can call it).
|
|
| My thinking/plan:
|
| 1. Add one more NIC to the FreeBSD box (it's also the router,
|firewall, _everything_ server) and put this on a separate IP block.
|To this NIC I will connect the VIP host, which needs the guaranteed
|bandwidth. I will therefore NAT traffic to/from it.
|
| 2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
| this means that:
| (a) They cannot go beyond 128Kbit/s
| (b) The VIP box will go above 128K/bit's in case the throttled
| LAN is not using all of the 128Kbit/s
|
| I need to control bandwidth on the external interface only, not on the
| LAN (internal interfaces).
|
| Is this rightful thinking or sheer imagination which is not practical?
|
| Seems reasonable. See below ...
Thanks, Bill for that verification.
| My problem:
|
|
| Most important is being dumb when it comes to IPFW and hence the pipes
| and all that pertains to it.
|
| Here is my ipfw configuration, in black and white (firewall_type=OPEN)
|
|
| # Outside interface network and netmask and ip
| oif=bfe0
| iif=xl0
| onet=62.8.68.0
| omask=255.255.255.252
| oip=62.8.68.22
|
| # Inside interface network and netmask and ip
| iif=xl0
| inet=10.0.0.0
| imask=255.255.255.0
| iip=10.0.0.2
|
| ipfw pipe 1 config bw 128Kbit/s
|
| # Allow any traffic to or from my own net.
| ${fwcmd} add pass all from ${iip} to ${inet}:${imask}
| ${fwcmd} add pass all from ${inet}:${imask} to ${iip}
|
| # Throttle now
| ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif}
state
|^^
|
| Is this direct cut/paste? If so, you've got a sticky $ key.
Yes, it was a paste in the process of modifying ;)
Noted with thanks.
|
| ${fwcmd} add 65000 pass all from any to any
|
|
| With this configuration, it seems like even LAN-LAN communication is
| being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
| Can someone tell me why that is happening?
|
| Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
| bandwidth limitation configuration, is it not true that I will have
| achieved my goal?
|
| I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
| have a static route for the VIP box, with NAT for any connections
| to/from it.
|
|
| I'll really appreciate any help/advise towards a perfect configuration
| for the firewall, and how I can get this to work.
|
| Thanks in advance.
Bill, you did not say anything on my problem with intra-LAN traffic.
Does that mean this configuration is okay, and should not at all affect
traffic within the LAN?
Best regards,
Odhiambo Washington
Systems Admin,
Wananchi Online Ltd.
Are you hosting your domain name with the leaders??:
See http://webhosting.info/webhosts/tophosts/Country/KE
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--+-
Odhiambo WASHINGTON. WANANCHI ONLINE LTD (Nairobi, KE)
http://www.wananchi.com/email/ . 1ere Etage, Laptrust Plaza, Loita St.,
Mobile: (+254) 722 743 223 . # 10286, 00100 NAIROBI
--+-
Many are the plans in a man's heart,
but it is the Lord's purpose that prevails.
Proverbs 19:21
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
* On 20/09/06 17:16 +0200, Erik Norgaard wrote: | Odhiambo Washington wrote: | | I need to control bandwidth on the external interface only, not on the | LAN (internal interfaces). | | Is this rightful thinking or sheer imagination which is not practical? | | If you're happy with IPFilter and need to ensure minimum bandwidth for | some network segment, take a look at packet filter, you can take much of | your knowledge with you and then set up queues that will ensure the | minimum bandwidth. And you don't need extra interfaces. That is the way to go ultimately, but I am still a newbie with PF. I would not want to transfer my newbie-ness into a customers network ;) I am happy with IPFilter, yes, but I am gradually shifting to PF, but I have to graduate before I can put that out there. At the moment, I just want to solve an immediate problem which has presented itself. -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +==+ |\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED] Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ A university is what a college becomes when the faculty loses interest in students. -- John Ciardi ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
In response to Odhiambo Washington [EMAIL PROTECTED]:
* On 20/09/06 11:16 -0400, Bill Moran wrote:
| In response to Odhiambo Washington [EMAIL PROTECTED]:
|
| [snip]
|
| The scenario:
|
| I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
| interfaces at the moment, external interface connected to the hostile
| Internet and internal interface connected to a switch for the LAN.
|
| The ISP gives 256Kbit/s on the external interface. Out of this, I
| need to dedicate/guarantee 128Kbit/s to just one machine.
|
| A streaming server has been introduced on the LAN, and it is considered
| a VIP host as far as bandwidth allocation is concerned.
| The problem is that p2p is also officially allowed on the LAN. I hate
| it but it is allowed. Period. No argument about it.
|
| I need to guarantee 128Kbit/s of the available bandwidth to the
| streaming host (server, if you can call it).
|
|
| My thinking/plan:
|
| 1. Add one more NIC to the FreeBSD box (it's also the router,
|firewall, _everything_ server) and put this on a separate IP block.
|To this NIC I will connect the VIP host, which needs the guaranteed
|bandwidth. I will therefore NAT traffic to/from it.
|
| 2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
| this means that:
| (a) They cannot go beyond 128Kbit/s
| (b) The VIP box will go above 128K/bit's in case the throttled
| LAN is not using all of the 128Kbit/s
|
| I need to control bandwidth on the external interface only, not on the
| LAN (internal interfaces).
|
| Is this rightful thinking or sheer imagination which is not practical?
|
| Seems reasonable. See below ...
Thanks, Bill for that verification.
| My problem:
|
|
| Most important is being dumb when it comes to IPFW and hence the pipes
| and all that pertains to it.
|
| Here is my ipfw configuration, in black and white (firewall_type=OPEN)
|
|
| # Outside interface network and netmask and ip
| oif=bfe0
| iif=xl0
| onet=62.8.68.0
| omask=255.255.255.252
| oip=62.8.68.22
|
| # Inside interface network and netmask and ip
| iif=xl0
| inet=10.0.0.0
| imask=255.255.255.0
| iip=10.0.0.2
|
| ipfw pipe 1 config bw 128Kbit/s
|
| # Allow any traffic to or from my own net.
| ${fwcmd} add pass all from ${iip} to ${inet}:${imask}
| ${fwcmd} add pass all from ${inet}:${imask} to ${iip}
|
| # Throttle now
| ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif}
state
|^^
|
| Is this direct cut/paste? If so, you've got a sticky $ key.
Yes, it was a paste in the process of modifying ;)
Noted with thanks.
|
| ${fwcmd} add 65000 pass all from any to any
|
|
| With this configuration, it seems like even LAN-LAN communication is
| being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
| Can someone tell me why that is happening?
|
| Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
| bandwidth limitation configuration, is it not true that I will have
| achieved my goal?
|
| I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
| have a static route for the VIP box, with NAT for any connections
| to/from it.
|
|
| I'll really appreciate any help/advise towards a perfect configuration
| for the firewall, and how I can get this to work.
|
| Thanks in advance.
Bill, you did not say anything on my problem with intra-LAN traffic.
Does that mean this configuration is okay, and should not at all affect
traffic within the LAN?
I assumed that any problems you were seeing were a result of the typo.
Seems to me that the config you propose will do what you want, but I
haven't spent a lot of time thinking about it.
Besides, these kind of configs rarely work perfectly on the first try,
it usually takes a bit of tweaking after you implement them, as a result
of unforseen consequences. I think you've got a good starting point
and you should just monitor the set up for a while after implementation.
--
Bill Moran
Collaborative Fusion Inc.
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure
Re: Traffic shaping with ipfw/DUMMYNET when using natd
On Wed, May 24, 2006 at 08:32:53AM -0600, G-der wrote: I've been setting up ipfw and DUMMYNET to do some traffic shaping on my network. Right now to test things out I've basicly put everything into two categories. There's traffic from 10.0.10.10 which is lower priority (this is a download machine) and then there's everything else. The biggest problem I've runinto is that because natd gets the packets first thing the only way to catch outgoing traffic is on the internal network interface. That is if you want to limit based on which internal machine is generating the traffic like in my case. After the divert rule for natd the src-ip field gets changed to my external ip address. This has a side effect of limiting all the traffic on that internal interface, even stuff that is not bound for the internet. I've tried playing around a little bit with the bridged, diverted, and diverted-output commands but can't get any of them to catch the packets. Is there a way to limit outgoing traffic based on which machine owns the traffic internally that doesn't have to be done on the internal interface? Would it be better practice to scan outgoing traffic before the divert rules for natd? I do it on the internal nic. I just have the internal traffic skip those rules. You could do it on the external nic, but this is more complex. You should remeber that the diverd rule changes the ip adress. Scanning outgoing traffic before the divert rule and incomming afther it should work to. -- Alex Please copy the original recipients, otherwise I may not read your reply. Howtos based on my personal use, including information about setting up a firewall and creating traffic graphs with MRTG http://alex.kruijff.org/FreeBSD/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Traffic shaping with ipfw/DUMMYNET when using natd
I've been setting up ipfw and DUMMYNET to do some traffic shaping on my
network. Right now to test things out I've basicly put everything into two
categories. There's traffic from 10.0.10.10 which is lower priority (this
is a download machine) and then there's everything else.
The biggest problem I've runinto is that because natd gets the packets first
thing the only way to catch outgoing traffic is on the internal network
interface. That is if you want to limit based on which internal machine is
generating the traffic like in my case. After the divert rule for natd the
src-ip field gets changed to my external ip address. This has a side effect
of limiting all the traffic on that internal interface, even stuff that is
not bound for the internet.
I've tried playing around a little bit with the bridged, diverted, and
diverted-output commands but can't get any of them to catch the packets.
Is there a way to limit outgoing traffic based on which machine owns the
traffic internally that doesn't have to be done on the internal interface?
Would it be better practice to scan outgoing traffic before the divert rules
for natd?
extif=rl0
intif=rl1
#INCOMING TRAFFIC
#Tested max incoming at 5914Kbit/s
${fwcmd} pipe 1 config bw 5800Kbit/s
${fwcmd} queue 1 config pipe 1 weight 2 #for torrent traffic
${fwcmd} queue 5 config pipe 1 weight 10#for everything else
${fwcmd} add 1000 queue 1 ip from any to 10.0.10.10 in via ${extif}
${fwcmd} add 5000 queue 5 ip from any to any in via ${extif}
#OUTGOING TRAFFIC
#Tested max outgoing at 390Kbit/s
${fwcmd} pipe 2 config bw 360Kbit/s
${fwcmd} queue 6 config pipe 2 weight 2
${fwcmd} queue 10 config pipe 2 weight 10
${fwcmd} add 6000 queue 6 ip from 10.0.10.10 to any in via ${intif}
${fwcmd} add 8000 queue 10 ip from any to any in via ${intif}
Here's the rules, I appreciate the assistance. Please cc me on reply, I'm
not a regular subscriber.
Thank you
Gene Dinkey
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
dummynet on vlan parent interfaces
Hi, I am attempting to set up contended bandwidth of varying levels, using vlans and dummynet. I have 3 nics, one for each level of service, and am simply setting the parent interface of each vlan device to the correct nic for required level. I was then hoping to limit the whole real nic as a whole, to produce contention. Initially I tried:- pipe 300 ip from any to any in via ste0 pipe 1300 ip from any to any out via ste0 But saw no packets hitting these rules. After a read of the ipfw manpage i thought enabling the sysctl variable net.link.ether.ipfw might help, which did indeed get me hits in one direction, but I still get no hits in the outbound direction. I'm guessing this is something to do with where dummynet sits in the whole scheme of things, but basically just want to know if there is a way to do what I'm trying or am I going about this the wrong way? Cheers, Dunc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Simluating a satellite connection using dummynet?
I've been reading up on it and best I can tell I'm looking at 1000ms round trips... at *best*. Most of what I do I can do on servers at home, but there will be the occasional ssh, etc. Supposedly, the round trip should be only 500 ms: the time for the signal to go from earth to the satellite and back to earth, then the same time for the reply packet to come back. On the machine directly connected to the satellite modem, a ping to the machine at the other end, directly connected to the satellite modem (so the 2 machine as close as possible to the satellite equipment) I get a ping round trip of 800 ms. That speed is pretty workable for ssh/telnet, even for a full screen editor. Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Simluating a satellite connection using dummynet?
Dan Busarow wrote: On Apr 22, 2006, at 9:40 PM, Philip Hallstrom wrote: Hi all - Odd question for you. I have the opportunity to work from home, but it would require using a sat internet connection (no cable or dsl anywhere close). I've been reading up on it and best I can tell I'm looking at 1000ms round trips... at *best*. Most of what I do I can do on servers at home, but there will be the occasional ssh, etc. I recently setup ipfw/dummynet with a pipe and a 750ms delay both in and out and it wasn't as bad as I thought it would be -- at least for ssh/text. Reminds me of my days on a 9600 baud modem. heh. I'm curious though whether this is a realistic test. Thoughts? Any of you use satellite? How do you find it? I had StarBand for about two years. 1000ms RTT are the best you will see. pushing 2000ms is more like it. While it is possible to work via an SSH session it will try your patience. It is doable, and it allowed me to move out to the country, but that's about it. I now have a terrestrial radio link into the nearest town, 15 miles away, and it's beautiful. My wife's employer had a Hughes connection for something over a year. Generally speaking, they weren't impressed. Their operation is a small insurance office, and they needed quick https service to the home office in Iowa, for a web app that seems to take a pretty quick pipe to operate well. I never ran a sniffer, but it seemed as if their OS (Microsoft) had some trouble with this setup, particularly with https traffic. You'd wait a good long time (few seconds), then get a big burst of data ... if you weren't cluttering things up with retries. Since this HTTPS traffic was his business, he decided it was more important to keep his employees happy, so he later decided to devote a portion of his disposable income to a local outfit that provides a T1 instead. TCP/IP being as it is, it's likely that MSFT QoS was dropping the packet sizes to help deal with the congestion ;-), but I was never sure. I'd concur that 1000 ms was a pretty normal RTT for ICMP, and it could, and often did go higher, a la 2500+. Much like Dan, I use an 11Mbps LOS radio connection to the water tower about 4 miles away. Nice, except I really need to raise my receiver so I can maintain good QoS when the foilage gets going I think grog@ has satellite service in AUS. You might see if you can turn up anything on his site. Kevin Kinsey -- And do you think (fop that I am) that I could be the Scarlet Pumpernickel? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Simluating a satellite connection using dummynet?
From: Kevin Kinsey [EMAIL PROTECTED]
Dan Busarow wrote:
On Apr 22, 2006, at 9:40 PM, Philip Hallstrom wrote:
Hi all -
Odd question for you. I have the opportunity to work
from home, but it would require using a sat internet
connection (no cable or dsl anywhere close).
I've been reading up on it and best I can tell I'm looking
at 1000ms round trips... at *best*. Most of what I do
I can do on servers at home, but there will be the
occasional ssh, etc.
I recently setup ipfw/dummynet with a pipe and a 750ms
delay both in and out and it wasn't as bad as I thought
it would be -- at least for ssh/text. Reminds me of my
days on a 9600 baud modem. heh.
I'm curious though whether this is a realistic test.
Thoughts?
Any of you use satellite? How do you find it?
I had StarBand for about two years. 1000ms RTT are the
best you will see. pushing 2000ms is more like it.
While it is possible to work via an SSH session it will
try your patience.
It is doable, and it allowed me to move out to the
country, but that's about it. I now have a terrestrial
radio link into the nearest town, 15 miles away, and
it's beautiful.
My wife's employer had a Hughes connection for something
over a year. Generally speaking, they weren't impressed.
Their operation is a small insurance office, and they needed
quick https service to the home office in Iowa, for a web app
that seems to take a pretty quick pipe to operate well.
I never ran a sniffer, but it seemed as if their OS (Microsoft)
had some trouble with this setup, particularly with https
traffic. You'd wait a good long time (few seconds), then get a
big burst of data ... if you weren't cluttering things up with
retries. Since this HTTPS traffic was his business, he
decided it was more important to keep his employees
happy, so he later decided to devote a portion of his
disposable income to a local outfit that provides a
T1 instead. TCP/IP being as it is, it's likely that MSFT
QoS was dropping the packet sizes to help deal
with the congestion ;-), but I was never sure.
I'd concur that 1000 ms was a pretty normal RTT for
ICMP, and it could, and often did go higher, a la
2500+.
Much like Dan, I use an 11Mbps LOS radio connection
to the water tower about 4 miles away. Nice, except
I really need to raise my receiver so I can maintain
good QoS when the foilage gets going
I think grog@ has satellite service in AUS. You might
see if you can turn up anything on his site.
Kevin Kinsey
Four round trips of as much as 25,000 miles is a bit more than
half a second. The typically employed interleaving/deinterleaving
and error correction coding means you can easily add another half
a second to the path.
(Of course, for something like the data mode operation on Inmarsat-M,
which is 2400bps max, it was pretty bad. As part of testing the
implementation I ran an interesting test. Satellite from Torrance to
the Atlantic sat to Goonhilly England (the only ground station that
was useable for the testing) back to LAX by unknown path thence
tymnet to a service in Mass to connect to the Internet and then
connect back to itself via TCP/IP was a LONG SLOW interactive session.
Then I made a 1 megabyte file transfer. It worked. It was signed off.
And quite a few units presold with data mode option suddenly grew the
implementation, one of the first units to have it. Then I entered
burnout Anyway - by the time that was all connected turn around
varied from 2.5 to 5 seconds on typed characters.)
{o.o} Joanne
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Simluating a satellite connection using dummynet?
Hi all - Odd question for you. I have the opportunity to work from home, but it would require using a sat internet connection (no cable or dsl anywhere close). I've been reading up on it and best I can tell I'm looking at 1000ms round trips... at *best*. Most of what I do I can do on servers at home, but there will be the occasional ssh, etc. I recently setup ipfw/dummynet with a pipe and a 750ms delay both in and out and it wasn't as bad as I thought it would be -- at least for ssh/text. Reminds me of my days on a 9600 baud modem. heh. I'm curious though whether this is a realistic test. Thoughts? Any of you use satellite? How do you find it? Thanks! -philip ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Simluating a satellite connection using dummynet?
On Apr 22, 2006, at 9:40 PM, Philip Hallstrom wrote: Hi all - Odd question for you. I have the opportunity to work from home, but it would require using a sat internet connection (no cable or dsl anywhere close). I've been reading up on it and best I can tell I'm looking at 1000ms round trips... at *best*. Most of what I do I can do on servers at home, but there will be the occasional ssh, etc. I recently setup ipfw/dummynet with a pipe and a 750ms delay both in and out and it wasn't as bad as I thought it would be -- at least for ssh/text. Reminds me of my days on a 9600 baud modem. heh. I'm curious though whether this is a realistic test. Thoughts? Any of you use satellite? How do you find it? I had StarBand for about two years. 1000ms RTT are the best you will see. pushing 2000ms is more like it. While it is possible to work via an SSH session it will try your patience. It is doable, and it allowed me to move out to the country, but that's about it. I now have a terrestrial radio link into the nearest town, 15 miles away, and it's beautiful. Dan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet with Dynamic IPFW Rules
I've been looking into using Dummynet for outgoing traffic, and I've found it hard going because the tutorials and how-to's deal with it in isolation, without indicating how it would be used in a real firewall. They generally suggest setting net.inet.ip.fw.one_pass=1, which as I understand it, implies that any packet passed into dummynet is passed statically though the firewall. I want to keep my existing dynamic rules, and it seems that one way would be to keep net.inet.ip.fw.one_pass=0 and follow each dummynet rule with a skipto rule that uses an identical test. So when the packet emerges from dummynet it skips the other pipe and queue rules, and hits the check-state. Something like this: -- ... #prioritize small ack packets 0500 queue 1 tcp from any to any out via vr0 tcpflags ack iplen 0-80 0501 skipto 1000 tcp from any to any out via vr0 tcpflags ack iplen 0-80 #prioritize ntp 0600 queue 1 tcp from any to any out ntp via vr0 0601 skipto 1000 tcp from any to any out ntp via vr0 other queuing rules 1000 check-state 1010 deny tcp from any to any in established 1020 allow tcp from any to any out setup keep-state 1030 allow udp from any to any ntp out keep-state other statefull rules -- Will this work? And is it the best way to handle this problem? It seems a bit clumsy. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Submit a bug for broken PicoBSD Dummynet/bridge?
On 23 Jan 2006, at 21:27, Tyler T wrote: I posted about this earlier but no replies. Since then I wiped my hard drive and reinstalled FreeBSD 6 from scratch. I still get this error when trying to make a PicoBSD Dummynet bridge floppy http://i1.tinypic.com/mhwvux.gif Should I go ahead and submit a bug for it? That depends if you rolled your own crunchgen configuration or not. Are you following a standard document to do this? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere PGP.sig Description: This is a digitally signed message part
Re: Submit a bug for broken PicoBSD Dummynet/bridge?
I still get this error when trying to make a PicoBSD Dummynet bridge floppy http://i1.tinypic.com/mhwvux.gif That depends if you rolled your own crunchgen configuration or not. Are you following a standard document to do this? Thanks for the reply!! I'm using http://people.freebsd.org/~picobsd/picobsd/doc/how2build.html and http://63.249.85.132/pico_notes.htm If there is a better document, I'll certainly try it. I didn't do anything with crunchgen, I just left everything at the default settings. Basically, I installed FreeBSD and then ran the 'picobsd bridge' script, and finally chose Build it from the menu without doing or changing anything else. Thanks again! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Submit a bug for broken PicoBSD Dummynet/bridge?
On Tue, Jan 24, 2006 at 09:24:00AM -0700, Tyler T wrote: I still get this error when trying to make a PicoBSD Dummynet bridge floppy http://i1.tinypic.com/mhwvux.gif That depends if you rolled your own crunchgen configuration or not. Are you following a standard document to do this? Thanks for the reply!! I'm using http://people.freebsd.org/~picobsd/picobsd/doc/how2build.html That document could do with deleting. Could you take a look at http://www.freebsd.org/projects/nanobsd/index.html and see if it fits any better; PicoBSD should be considered obsolete. Cheers, Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpzKhxWith3G.pgp Description: PGP signature
Re: Submit a bug for broken PicoBSD Dummynet/bridge?
I still get this error when trying to make a PicoBSD Dummynet bridge floppy http://i1.tinypic.com/mhwvux.gif Are you following a standard document to do this? Thanks for the reply!! I'm using http://people.freebsd.org/~picobsd/picobsd/doc/how2build.html That document could do with deleting. Could you take a look at http://www.freebsd.org/projects/nanobsd/index.html and see if it fits any better; PicoBSD should be considered obsolete. Well, then perhaps PicoBSD should be entirely removed from FreeBSD to prevent confusing the newbies (like myself ;) ). I'll give NanoBSD a shot. Thanks again. Regards, ___ /yler ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Submit a bug for broken PicoBSD Dummynet/bridge?
I posted about this earlier but no replies. Since then I wiped my hard drive and reinstalled FreeBSD 6 from scratch. I still get this error when trying to make a PicoBSD Dummynet bridge floppy http://i1.tinypic.com/mhwvux.gif Should I go ahead and submit a bug for it? Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
PicoBSD Dummynet/bridge errors
Hi, I just did a default installation of FreeBSD 6.0-RELEASE. I ran the PicoBSD script in an attempt to create a DummyNet floppy, but I got the following error: http://tinypic.com/kcmjnt.gif It says I have lots of undefined references such as gctl_getr_handle, gctl_ro_param, gctl_issue, and gctl_free. I tried it again and got pretty much the same thing: http://tinypic.com/kcmjq8.gif Also, if I try to use the menu to edit the kernel or crunch files, after I edit (whether I change anything or not) and exit vi I get: http://tinypic.com/kcmjic.gif Says rm: /tmp/reply.[UID]: No such file or directory and dumps me out of the menu system. I've used Linux quite a bit but this is my first time with FreeBSD. Like I said, I just did a default installation of FreeBSD 6.0. Is there something special I have to do when installing FreeBSD to get the PicoBSD/DummyNet script to work, or are these bugs? I am logged in as root. Alternatively, if someone has a premade DummyNet floppy image with the 'fxp' Intel PCI NIC drivers built into it, that's all I really need. The prebuilt DummyNet images I've found online are all very old and don't recognize my Intel PCI NICs. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge with dummynet+ipfw
Hi,
[ please try to avoid cross-posting on FreeBSD lists ]
I want to organize my bandwith in this mode
# download section
1000kbit/s
|
|
||
||
||
hight low
priorized traffic priorized
||
512kbit/s |
||
user |---|
share same | |
bandwith | |
300 kbit/s 512kbit/s
| |
| |
| |
users share users share
same bandwith same bandwith
I want to use ipfw+dummynet. Solutions is to pass traffic that match
an rule to multiple pipe or queue with different weights. But how?
What is the precedence? (need sysctl net.inet.ip.fw.one_pass=0)
If any have an solutions please be explicity. I dont want to be easy,
but is significant in this case, in wich order apply rule, and how is
configured pipe and queue. For this reason, solutions please put in this form
(example):
#section pipe and queue configuration
ipfw pipe 1 config .
ipfw queue 8 config weight 3 pipe 6
..
#section ipfw rules
ipfw add pipe 1 {match hight pri.}
ipfw add pipe 5 {match low pri. 300k same bandwith}
ipfw add queue 3 {match for hight pri. 512k same share}
...
I work for a time with dummynet. In this
example have an important to build some hierarchy with dummy.
P.S. this scheme is not changeable. Please refer to this situation.
Note that queue's weight do not implement priorities. The rule is
quite simple : sum up all weight of all queues connected to one pipe
and then each queue will be assigned the following bandwidth :
queuebw = totalbw * queueweight / totalweight
ALTQ does prioritize the traffic. This means that packets with high
priority are placed before lower prioritized packets in the device
output FIFO.
Regards,
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
challenge with dummynet+ipfw
Hi!
I want to organize my bandwith in this mode
# download section
1000kbit/s
|
|
||
||
||
hight low
priorized traffic priorized
||
512kbit/s |
||
user |---|
share same | |
bandwith | |
300 kbit/s 512kbit/s
| |
| |
| |
users share users share
same bandwith same bandwith
I want to use ipfw+dummynet. Solutions is to pass traffic that match
an rule to multiple pipe or queue with different weights. But how?
What is the precedence? (need sysctl net.inet.ip.fw.one_pass=0)
If any have an solutions please be explicity. I dont want to be easy,
but is significant in this case, in wich order apply rule, and how is
configured pipe and queue. For this reason, solutions please put in this form
(example):
#section pipe and queue configuration
ipfw pipe 1 config .
ipfw queue 8 config weight 3 pipe 6
..
#section ipfw rules
ipfw add pipe 1 {match hight pri.}
ipfw add pipe 5 {match low pri. 300k same bandwith}
ipfw add queue 3 {match for hight pri. 512k same share}
...
I work for a time with dummynet. In this
example have an important to build some hierarchy with dummy.
P.S. this scheme is not changeable. Please refer to this situation.
Thanks in advance!
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge with dummynet+ipfw
At 02:19 PM 8/28/2005, vladone wrote:
Hi!
I want to organize my bandwith in this mode
# download section
1000kbit/s
|
|
||
||
||
hight low
priorized traffic priorized
||
512kbit/s |
||
user |---|
share same | |
bandwith | |
300 kbit/s 512kbit/s
| |
| |
| |
users share users share
same bandwith same bandwith
I want to use ipfw+dummynet. Solutions is to pass traffic that match
an rule to multiple pipe or queue with different weights. But how?
What is the precedence? (need sysctl net.inet.ip.fw.one_pass=0)
If any have an solutions please be explicity. I dont want to be easy,
but is significant in this case, in wich order apply rule, and how is
configured pipe and queue. For this reason, solutions please put in
this form (example):
You'd probably be better of using the altq features in pf.
-Glenn
#section pipe and queue configuration
ipfw pipe 1 config .
ipfw queue 8 config weight 3 pipe 6
..
#section ipfw rules
ipfw add pipe 1 {match hight pri.}
ipfw add pipe 5 {match low pri. 300k same bandwith}
ipfw add queue 3 {match for hight pri. 512k same share}
...
I work for a time with dummynet. In this
example have an important to build some hierarchy with dummy.
P.S. this scheme is not changeable. Please refer to this situation.
Thanks in advance!
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: challenge with dummynet+ipfw
I know about pf+altq. I can use even ipfw+altw. But i'm fun dummynet, and i want to use'it. :) My work at moment is: #download total $cmd pipe 1 config bw 1000kbits/s #download agregate (low pri. 300kbits/s agregate) $cmd pipe 2 config bw 300kbits/s $cmd queue 2 config weight 1 pipe 1 $cmd queue 3 config weight 1 pipe 2 mask dst-ip 0xff # down agregate games (hight priorized due flow reason) $cmd pipe 4 config bw 512kbit/s $cmd queue 4 config weight 100 pipe 1 mask dst-ip 0xff $cmd queue 8 config weight 1 pipe 4 mask dst-ip 0xff #download agregate net (low pri. 512kbit/s agregate) $cmd pipe 6 config bw 512kbit/s $cmd queue 5 config weight 1 pipe 1 $cmd queue 6 config weight 1 pipe 6 mask dst-ip 0xff and ipfw rules: #traffic hight priorized $cmd add 700 queue 4 ip any $games_ports to $local_net in recv $pif $cmd add 700 pipe 4 ip any $games_ports to $local_net in recv $pif $cmd add 700 queue 8 ip any $games_ports to $local_net in recv $pif $cmd add 700 skipto 65000 ip from any $games_ports to $local_net in recv $pif #traffic from special ip (low pri. 300kbit/s agregate) $cmd add 700 queue 2 ip from $ip_list to $local_net in recv $pif $cmd add 700 pipe 2 ip from $ip_list to $local_net in recv $pif $cmd add 700 queue 3 ip from $ip_list to $local_net in recv $pif $cmd add 700 skipto 65000 ip from $ip_list to $local_net in recv $pif #traffic from internet (low pri. 512kbit/s agregate) $cmd add 700 queue 5 ip from any to $local_net in recv $pif $cmd add 700 pipe 6 ip from any to $local_net in recv $pif $cmd add 700 queue 6 ip from any to $local_net in recv $pif $cmd add 700 skipto 65000 ip from any to $local_net in recv $pif This set work but i dont know if is corect. If any have experience plase help me! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
moving from ipfw/dummynet to pf/altq
I need help moving from ipfw and dummynet to pf and altq. So far I have converted most ipfw rules to pf. Can someone tell me if there is something for altq like this for dummynet # ipfw add 1 pipe 1 config bw 64Kbit/s queue 10Kbytes mask src-ip 0x # ipfw add 2 pipe 2 confg bw 128Kbit/s queue 20Kbytes mask dst-ip 0x Or is there a better way to do it. -- Kind regards Abu Khaled ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
any problems using dummynet as a module?
I need to traffic shape a remote box that runs IPF, and I have taken the time to learn to use IPFW with dummynet, and also that I can run IPFW wide open as IPF is the firewall. The box is 5.4 stable (generic) and I can't get around doing a reboot, from all the testing I have done. Must reboot unfortunately. Loading the ipfw.ko and/or the dummynet.ko with kldload locks me out of an identical test box which is bad news for me. This box is in a colo center with just one ethernet interface. So my procedure works, but I am wondering if I should just suck it up and compile all this stuff into the kernel, or if my procedure below is somewhat safe? (it works, but I am looking for any hidden issues?) 1. Add this to /boot/loader.conf dummynet_load=YES 2. Add this to rc.conf: firewall_enable=YES firewall_quiet=YES firewall_logging=YES firewall_script=/etc/ipfw.rules 3. Edit /etc/ipfw.rules with these entries: ipfw -q -f flush ipfw -q add 100 pass all from any to any via lo0 ipfw -q add 200 deny all from any to 127.0.0.0/8 ipfw -q add 300 deny ip from 127.0.0.0/8 to any ipfw -q add 65000 pass all from any to any ipfw -q add 1 pipe 1 ip from any to any out xmit ed0 ipfw -q pipe 1 config bw 128kbits/s - REBOOT ...and the rate limiting works and I can also change the speed on the fly which is a good thing Thanks for any comments! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Rule dummynet.
Hi, I use FreeBSD 4.X using traffic shapper with dummynet, I've some questions about implementation rule for my box, for example: I've 4 client computer let's say A, B, C, and D. I've total bandwith 1 Mbps. If client A online and the other offline (B, C, D), client A should get 100% bandwidht (In this case 1 Mbps), if client A B online then A should get = 50% (500 kbps), B = 50% (500 kbps). If client A, B, C online then they should get 33,33% of 1 Mbps, If all user online they should get 25% of 1 Mbps. Dummynet can do this?, Would you give me an example rule? Thank You. -- budsz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Traffic Shapping (IPFW + DUMMYNET) Question
On Thursday 14 April 2005 14:53, Timothy Radigan wrote: Hi all, I'm new to the entire idea of traffic shaping and I came up with some rules for my BSD firewall/router/VoIP gateway ... Does this seem like it will perform as I am thinking it will? I've not tried this kind of thing myself, but I wouldn't be very optimistic about what you are trying to do. AFAIK dummynet works through IP packet queueing. That means that it can do a good job of shaping outgoing traffic, but the only control it has on incoming traffic is through dropping packets that have already been received, which isn't very efficient. To achieve what you want would really need some something that can hook into the tcp/ip stack and affect tcp window sizes. I dont know of anything that would do that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Traffic Shapping (IPFW + DUMMYNET) Question
On Thu, 2005-04-14 at 09:53 -0400, Timothy Radigan wrote: Hi all, I'm new to the entire idea of traffic shaping and I came up with some rules for my BSD firewall/router/VoIP gateway and I just wanted to make sure that what I am trying to accomplish is actually going to happen with these rules in place. Currently, my broadband connection is a 4Mb down and 384Mb up pipe. My VoIP service requires 90Kb up and down. I have 3 separate internal networks at my house. I have my wired 100Mb switched LAN (192.168.15.0/24), I have my IPSec enabled Wireless LAN (192.168.20.0/24), and I have my VoIP LAN (192.168.10.0/30). What I want to do with these traffic shaping rules, is dedicate 100Kb up and down to the VoIP LAN, and then I want to have equally shared bandwidth (the remaining speeds of my broadband connection) for the wired and wireless LANs. Here are the rules I have come up with so far: Can you post your ifconfig output of your BSD box? How about the output of this: sysctl -a | grep net.inet.ip.fw.one_pass Chris --- (START) /etc/ipfw.rules # flush all rules ipfw -f flush # configure the pipe main pipes - have 4000kbits/s down 384kbits/s up # define 200kbits/s for the voip pipes ipfw pipe 1 config bw 100Kbits/s ipfw pipe 2 config bw 100Kbits/s # wired / wifi lans - get all but 100kbits/s for both up and down ipfw pipe 3 config bw 3900Kbits/s ipfw pipe 4 config bw 284Kbits/s # wired/wifi LAN internal transmission ipfw pipe 5 config bw 100Mbits/s mask dst-ip 0x ipfw pipe 6 config bw 100Mbits/s mask dst-ip 0x ipfw pipe 7 config bw 100Mbits/s mask dst-ip 0x ipfw pipe 8 config bw 100Mbits/s mask dst-ip 0x # make sure the voip gets all of the bandwidth for the pipes ipfw add 1 pipe 1 ip from 192.168.10.2 to any ipfw add 1 pipe 2 ip from any to 192.168.10.2 # make sure the wired and wifi lans get all of the bandwidth for those pipes ipfw add 2 pipe 5 ip from 192.168.15.0/24 to 192.168.0.0/16 ipfw add 2 pipe 6 ip from 192.168.0.0/16 to 192.168.15.0/24 ipfw add 3 pipe 7 ip from 192.168.20.0/24 to 192.168.0.0/16 ipfw add 3 pipe 8 ip from 192.168.0.0/16 to 192.168.20.0/24 # the wired / wifi lans will split the up and down pipes ipfw queue 3 config weight 50 pipe 3 mask dst-ip 0x00ff ipfw queue 4 config weight 50 pipe 3 mask dst-ip 0x00ff ipfw queue 5 config weight 50 pipe 4 mask dst-ip 0x00ff ipfw queue 6 config weight 50 pipe 4 mask dst-ip 0x00ff # add inbound/outbound queues for the wired lan ipfw add 100 queue 3 ip from any to 192.168.15.0/24 ipfw add 105 queue 5 ip from 192.168.15.0/24 to any # add inbound/outbound queues for the wifi lan ipfw add 200 queue 4 ip from any to 192.168.20.0/24 ipfw add 205 queue 6 ip from 192.168.20.0/24 to any (END) /etc/ipfw.rules - Does this seem like it will perform as I am thinking it will? Thanks --Tim ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Traffic Shapping (IPFW + DUMMYNET) Question
Hi all, I'm new to the entire idea of traffic shaping and I came up with some rules for my BSD firewall/router/VoIP gateway and I just wanted to make sure that what I am trying to accomplish is actually going to happen with these rules in place. Currently, my broadband connection is a 4Mb down and 384Mb up pipe. My VoIP service requires 90Kb up and down. I have 3 separate internal networks at my house. I have my wired 100Mb switched LAN (192.168.15.0/24), I have my IPSec enabled Wireless LAN (192.168.20.0/24), and I have my VoIP LAN (192.168.10.0/30). What I want to do with these traffic shaping rules, is dedicate 100Kb up and down to the VoIP LAN, and then I want to have equally shared bandwidth (the remaining speeds of my broadband connection) for the wired and wireless LANs. Here are the rules I have come up with so far: --- (START) /etc/ipfw.rules # flush all rules ipfw -f flush # configure the pipe main pipes - have 4000kbits/s down 384kbits/s up # define 200kbits/s for the voip pipes ipfw pipe 1 config bw 100Kbits/s ipfw pipe 2 config bw 100Kbits/s # wired / wifi lans - get all but 100kbits/s for both up and down ipfw pipe 3 config bw 3900Kbits/s ipfw pipe 4 config bw 284Kbits/s # wired/wifi LAN internal transmission ipfw pipe 5 config bw 100Mbits/s mask dst-ip 0x ipfw pipe 6 config bw 100Mbits/s mask dst-ip 0x ipfw pipe 7 config bw 100Mbits/s mask dst-ip 0x ipfw pipe 8 config bw 100Mbits/s mask dst-ip 0x # make sure the voip gets all of the bandwidth for the pipes ipfw add 1 pipe 1 ip from 192.168.10.2 to any ipfw add 1 pipe 2 ip from any to 192.168.10.2 # make sure the wired and wifi lans get all of the bandwidth for those pipes ipfw add 2 pipe 5 ip from 192.168.15.0/24 to 192.168.0.0/16 ipfw add 2 pipe 6 ip from 192.168.0.0/16 to 192.168.15.0/24 ipfw add 3 pipe 7 ip from 192.168.20.0/24 to 192.168.0.0/16 ipfw add 3 pipe 8 ip from 192.168.0.0/16 to 192.168.20.0/24 # the wired / wifi lans will split the up and down pipes ipfw queue 3 config weight 50 pipe 3 mask dst-ip 0x00ff ipfw queue 4 config weight 50 pipe 3 mask dst-ip 0x00ff ipfw queue 5 config weight 50 pipe 4 mask dst-ip 0x00ff ipfw queue 6 config weight 50 pipe 4 mask dst-ip 0x00ff # add inbound/outbound queues for the wired lan ipfw add 100 queue 3 ip from any to 192.168.15.0/24 ipfw add 105 queue 5 ip from 192.168.15.0/24 to any # add inbound/outbound queues for the wifi lan ipfw add 200 queue 4 ip from any to 192.168.20.0/24 ipfw add 205 queue 6 ip from 192.168.20.0/24 to any (END) /etc/ipfw.rules - Does this seem like it will perform as I am thinking it will? Thanks --Tim ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet problems
I don't use dummynet myself, but surely it would be easier to help you
if you described what the actual problem is?
Well, actual problem description:
FreeBSD-5.3 router;
rl0 - internal interface
rl1 - external.
rl1 is connected to ADSL modem from provider;
The link bandwidth is 64kbps.
${fwcmd} -f flush
${fwcmd} -f pipe flush
${fwcmd} pipe 1 config bw 64Kbit/s queue 10KBytes
${fwcmd} queue 4 config pipe 1 weight 1 mask dst-ip 0x buckets
10 queue 9 gred 0.002/7/21/0.1
${fwcmd} add 780 queue 4 log logamount 10 tcp from any to
192.168.0.30/32 out via rl0
${fwcmd} queue 10 config pipe 1 weight 100 mask dst-ip 0x
queue 9 gred 0.002/7/21/0.1
${fwcmd} add 790 queue 10 log logamount 10 tcp from any to
192.168.0.99/32 out via rl0
${fwcmd} queue 25 config pipe 1 weight 30 mask dst-ip 0x
buckets 15 queue 10 gred 0.002/7/21/0.1
${fwcmd} queue 20 config pipe 1 weight 100 mask dst-ip 0x
buckets 100 queue 9 gred 0.002/7/21/0.1
${fwcmd} queue 30 config pipe 1 weight 20 mask dst-ip 0x
buckets 100 queue 9 gred 0.002/7/21/0.1
${fwcmd} queue 40 config pipe 1 weight 10 mask dst-ip 0x
buckets 100 queue 9 gred 0.002/7/21/0.1
${fwcmd} add 891 queue 20 log logamount 10 tcp from any 5190 to
192.168.0.1/25 out via rl0
${fwcmd} add 892 queue 25 log logamount 10 tcp from any to 192.168.0.6
out via rl0
${fwcmd} add 893 queue 25 log logamount 10 tcp from any to
192.168.0.29 out via rl0
${fwcmd} add 894 queue 25 log logamount 10 tcp from any to
192.168.0.62 out via rl0
${fwcmd} add 895 queue 25 log logamount 10 tcp from any to
192.168.0.27 out via rl0
${fwcmd} add 898 queue 30 log logamount 10 tcp from any
25,110,43,53,119,123,143,953 to
192.168.0.1/25{1-3,5,7-26,28,31-61,63-98,100} out via rl0
${fwcmd} add 897 queue 40 log logamount 10 tcp from any
80,443,3128,21,20 to 192.168.0.1/25{1-3,5,7-26,28,31-61,63-98,100}
out via rl0
ipfw pipe show:
1: 99.000 Kbit/s0 ms 10 KB 0 queues (1 buckets) droptail
mask: 0x00 0x/0x - 0x/0x
q4: weight 1 pipe 19 sl. 1 queues (10 buckets)
GRED w_q 0.001999 min_th 7 max_th 21 max_p 0.01
mask: 0x00 0x/0x - 0x/0x
BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp
2 ip 0.0.0.0/0192.168.0.30/0 2198 1821083 00 43
q00010: weight 100 pipe 19 sl. 1 queues (64 buckets)
GRED w_q 0.001999 min_th 7 max_th 21 max_p 0.01
mask: 0x00 0x/0x - 0x/0x
BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp
51 ip 0.0.0.0/0192.168.0.99/09 813 00 0
q00020: weight 100 pipe 19 sl. 13 queues (100 buckets)
GRED w_q 0.001999 min_th 7 max_th 21 max_p 0.01
mask: 0x00 0x/0x - 0x/0x
BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp
2 ip 0.0.0.0/0192.168.0.30/0 42 6662 00 0
5 ip 0.0.0.0/0 192.168.0.1/0 36 6054 00 0
13 ip 0.0.0.0/0 192.168.0.9/0 37 5021 00 0
15 ip 0.0.0.0/0192.168.0.11/0 6116333 00 0
25 ip 0.0.0.0/0192.168.0.53/0 23 3463 00 0
29 ip 0.0.0.0/0192.168.0.85/0 20123807 00 0
33 ip 0.0.0.0/0192.168.0.61/0 65 6704 00 0
34 ip 0.0.0.0/0192.168.0.62/0 16639971 00 0
38 ip 0.0.0.0/0192.168.0.94/0 36 7726 00 0
39 ip 0.0.0.0/0192.168.0.35/0 15162681 00 0
47 ip 0.0.0.0/0192.168.0.71/0 20717475 00 0
88 ip 0.0.0.0/0192.168.0.16/0 25 4751 00 0
98 ip 0.0.0.0/0192.168.0.26/0 44 8235 00 0
q00025: weight 30 pipe 1 10 sl. 2 queues (15 buckets)
GRED w_q 0.001999 min_th 7 max_th 21 max_p 0.01
mask: 0x00 0x/0x - 0x/0x
BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp
5 ip 0.0.0.0/0 192.168.0.6/0 1093 518028 00 51
14 ip 0.0.0.0/0192.168.0.62/0 3604 2254945 4 3098 50
q00030: weight 20 pipe 19 sl. 8 queues (100 buckets)
GRED w_q 0.001999 min_th 7 max_th 21 max_p 0.01
mask: 0x00 0x/0x - 0x/0x
BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp
15 ip 0.0.0.0/0192.168.0.11/0 20 1081 00 0
33 ip 0.0.0.0/0192.168.0.61/0 14224203 00 0
38 ip 0.0.0.0/0192.168.0.94/0 21 1008 00 0
39 ip 0.0.0.0/0192.168.0.35/0 21 3090 00 0
53 ip 0.0.0.0/0192.168.0.77/0 848
Re: dummynet problems
Sergey Lapin [EMAIL PROTECTED] writes:
Hi, all!
Here I have a problem with dummynet. System is FreeBSD-5.3-STABLE month ago.
we have very small bandwidth from LAN.
rl0 is internal interface.
ipfw rukes are (fwcmd=/sbin/ipfw):
${fwcmd} pipe 1 config bw 60Kbit/s
${fwcmd} add 778 pipe 1 tcp from any
25,43,53,80,110,119,123,143,953,5190 to 192.168.0.0/25 out via rl0
${fwcmd} queue 1 config pipe 1 weight 100 mask dst-ip 0x queue 5
${fwcmd} add 790 queue 1 log logamount 10 tcp from any to 192.168.0.99
out via rl0
${fwcmd} queue 2 config pipe 1 weight 100 mask dst-ip 0x0fff
buckets 150 queue 10
${fwcmd} queue 3 config pipe 1 weight 30 mask dst-ip 0x0fff
buckets 150 queue 10
${fwcmd} queue 4 config pipe 1 weight 70 mask dst-ip 0x0fff
buckets 150 queue 10
${fwcmd} add 791 queue 2 log logamount 10 tcp from any 5190 to
192.168.0.0/25 out via rl0
${fwcmd} add 795 queue 3 log logamount 10 tcp from any 80,3128,21,20
to 192.168.0.0/25 out via rl0
${fwcmd} add 792 queue 4 log logamount 10 tcp from any
25,110,43,53,119,123,143,953 to 192.168.0.0/25 out via rl0
Thanks a lot!
I don't use dummynet myself, but surely it would be easier to help you
if you described what the actual problem is?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
dummynet problems
Hi, all!
Here I have a problem with dummynet. System is FreeBSD-5.3-STABLE month ago.
we have very small bandwidth from LAN.
rl0 is internal interface.
ipfw rukes are (fwcmd=/sbin/ipfw):
${fwcmd} pipe 1 config bw 60Kbit/s
${fwcmd} add 778 pipe 1 tcp from any
25,43,53,80,110,119,123,143,953,5190 to 192.168.0.0/25 out via rl0
${fwcmd} queue 1 config pipe 1 weight 100 mask dst-ip 0x queue 5
${fwcmd} add 790 queue 1 log logamount 10 tcp from any to 192.168.0.99
out via rl0
${fwcmd} queue 2 config pipe 1 weight 100 mask dst-ip 0x0fff
buckets 150 queue 10
${fwcmd} queue 3 config pipe 1 weight 30 mask dst-ip 0x0fff
buckets 150 queue 10
${fwcmd} queue 4 config pipe 1 weight 70 mask dst-ip 0x0fff
buckets 150 queue 10
${fwcmd} add 791 queue 2 log logamount 10 tcp from any 5190 to
192.168.0.0/25 out via rl0
${fwcmd} add 795 queue 3 log logamount 10 tcp from any 80,3128,21,20
to 192.168.0.0/25 out via rl0
${fwcmd} add 792 queue 4 log logamount 10 tcp from any
25,110,43,53,119,123,143,953 to 192.168.0.0/25 out via rl0
Thanks a lot!
S.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
dummynet trick
Hello, This is the beginning of my script: ipfw -q flush ipfw pipe 1 config bw 729kbit/s ipfw pipe 2 config bw 121kbit/s ipfw queue 1 config pipe 1 weight 94 ipfw queue 2 config pipe 1 weight 5 ipfw queue 3 config pipe 1 weight 1 ipfw queue 4 config pipe 2 weight 94 ipfw queue 5 config pipe 2 weight 5 ipfw queue 6 config pipe 2 weight 1 Everything runs okay except this: ipfw queue 3 config pipe 1 weight 1 results in: ipfw: setsockopt(IP_DUMMYNET_CONFIGURE): Invalid argument But when I change to this: ipfw queue 22 config pipe 1 weight 1 then it works just fine. What the hell is this? Laci p.s.: FreeBSD 4.8-p27 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Bridge and dummynet
Good Day Guys. I installed FreeBSD 5.3 and everything worked fine . i recompiled the kernel included options for IPDIVERT IPFIREWALL IPFIREWALL_VERBOSE BRIDGE everything went fine i did the systcl to load the two network cards as should be sysctl net.link.ether.bridge.config=rl0:0,rl1:0 sysctl net.link.ether.bridge.ipfw=1 sysctl net.link.ether.bridge.enable=1 schema client 1 FreeBSD bridge /--\ /---\ /\ a.b.c.d|--|rl0 - -rl1|-| external network| \--/ \---/ \/ so far everything is working fine . now my internal network is connected physically to rl0. i want to rate limit ip a.b.c.d from internal network to 32Kbit uplink and 128Kbit downlink . in the manual and documention given on the sites it helps but not on the same network card as needed in here ! i was successfull to rate limit uplink but not downlink ! as such ipfw pipe 1 config bw 32Kbit/s queue 4Kbyte ipfw add pipe 1 all from a.b.c.d to any in recv rl0 # uplink limitation works fine ipfw pipe 2 config bw 128Kbit/s queue 4Kbyte ipfw add pipe 2 all from any to a.b.c.d out xmit rl0 # downlink doesn't match if there is something i missed then feel free to guide me . else if its possible for someone parse his/her connfiguration Thanks F. B. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dummynet problem, kernel options checked
Hello, I'm running FreeBSD 5.3 Stable, installed from an iso on one of the dutch ftp mirrors. Everything works fine, installation went as expected. After a while I wanted some simple traffic shaping, and since the machine I wanted that for isn't the fastest, I chose to use ipfw with dummynet. From what I read that was not very resource-intensive. I recompiled the kernel, copied the GENERIC and added the following options: options IPFIREWALL #ipfw options DUMMYNET#dummynet options HZ=1000 #strongly recommended I looked into both the ipfw and dummynet manpages, and I under- stood this would be all that was needed. The compiling went fine, ipfw works, dummynet doesn't. I can add pipes, but configurating bandwith (or actually, just ipfw pipe 1 config is enough), gives me the following error: ipfw: setsockopt(IP_DUMMYNET_CONFIGURE): Protocol not available I tried the usual, looking into the handbook, faq, and searching newsgroups and the web. Everything there tells me that DUMMYNET isn't in my kernel options. I checked numerous times, and it is really there. Is there any way I could check if it really compiled? I vaguely remember something containing the word dummynet flashing by while compiling. Any advice is appreciated, Lucas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet problem, kernel options checked
Lucas wrote: [ ... ] Is there any way I could check if it really compiled? I vaguely remember something containing the word dummynet flashing by while compiling. If you check `dmesg`, you should see a line like: DUMMYNET initialized (011031) However, your problem sounds like your kernel and world are out-of-sync. If you've updated your sources and reinstalled the kernel, you'll also need to reinstall the world, too. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet problem, kernel options checked
Lucas wrote: [ ... ] Is there any way I could check if it really compiled? I vaguely remember something containing the word dummynet flashing by while compiling. If you check `dmesg`, you should see a line like: DUMMYNET initialized (011031) However, your problem sounds like your kernel and world are out-of-sync. If you've updated your sources and reinstalled the kernel, you'll also need to reinstall the world, too. I didn't install any sources when installing freebsd, I was in a hurry and didn't bother, then I installed the sources from ftp because it would be easier then fiddling with cdroms, but only installed sys.. I know, dumb. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet traffic shaping question (TCP-ACK prioritization)
(question at the end)
I have a server that sits on a medium speed link (10Mbit, full duplex) that
under certain network loads starts to show what looks like TCP-ACK delay
problems. At full upstream saturation the downstream speed is reduced.
I modded the firewall rules to prioritize TCP-ACKs into one queue and all
other outgoing traffic into another queue. Something like this:
${fwcmd} pipe 1 config
${fwcmd} queue 1 config pipe 1 weight 100
${fwcmd} queue 2 config pipe 1 weight 1
# Route all outgoing TCP traffic with the ACK flag through the high priority
queue
${fwcmd} add queue 1 tcp from any to any out via ${ext_if} tcpflags ack
iplen 0-80
# Route all other (established) outgoing TCP traffic through the low
priority queue
${fwcmd} add queue 2 tcp from any to any out via ${ext_if} established
Looking at the output of 'ipfw show' seems to indicate the queues are
getting the packets they should get:
00100 1738731 69778250 queue 1 tcp from any to any out via em0 tcpflags
ack iplen 0-80
00200 5133634 7689253633 queue 2 tcp from any to any out via em0 established
Even though everything looks OK, the results have not been what I hoped for
(same problem with downstream speed during full upstream saturation).
My question is: Do I need to tell the pipe how fat it is (${fwcmd} pipe 1
config bw 10Mbit/s) to get the queue prioritization to work properly, or is
it OK to leave out the speed and just let it run full tilt?
/Daniel Eriksson
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet bw cumulative limit
I've changed the list to questions@ On Wed, Nov 10, 2004 at 01:08:04PM -0500, Bob Ababurko wrote: HEllo all- We are interested in limiting the bandwidth of a newly setup connection. We are on a 100 Mb/s switch port and want to keep it to 1 Mb/s for now. Forgive my ignorance, but do they measure this cumulative(inbound + outbound)?I would assume so, but I would like to confirm this since the rate for overage is not within the budget for now. The firewall rules determen what dummynets monitors. If you combine inbound and outbound then it monitors that. You can also just monitor http traffic. Its up to you. Assuming the conservative, how does the dummynet config have to be setup fpor thsi to occur?...or can it be configured for both inbound and ^ I don't understand the question. outbound? Right now, I have the below config and since I have not put the box on the network yet, I have not been able to look at the MRTG to figure the answer. I am thinking that this config may limit to 1 meg in both directionsI am just not looking forward to overage fees right off the bat! btw, this config is for the priority of the udp/tcp acks in both directions. I am not sure if this is going to work so any comments on it would be appreciated. There is no real priority only a weithed ruby round You want you're fxp0 to limit in + out to 1MBit/s rigth? ipfw -f flush ipfw pipe 1 config bw 1000kbits/s ipfw queue 1 config pipe 1 weight 100 ipfw queue 2 config pipe 1 weight 1 mask all ipfw queue 3 config pipe 1 weight 100 ipfw queue 4 config pipe 1 weight 1 mask all ipfw add 100 queue 1 udp from any to any out via fxp0 ipfw add 101 skipto 1000 udp from any to any out via fxp0 ipfw add 100 queue 3 udp from any to any in via fxp0 ipfw add 101 skipto 1000 udp from any to any in via fxp0 ipfw add 110 queue 1 tcp from any to any out via fxp0 tcpflags ack ipfw add 111 skipto 1000 tcp from any to any out via fxp0 tcpflags ack ipfw add 110 queue 3 tcp from any to any in via fxp0 tcpflags ack ipfw add 111 skipto 1000 tcp from any to in out via fxp0 tcpflags ack I've also tried with this, but was not pleased with this. A number of packets where to big than I expected. You migth want to give iplen a try instead. ipfw add queue 2 ip from any to any out via fxp0 ipfw add queue 4 ip from any to any out via fxp0 ^^^ this is wrong. ipfw add 1000 allow all from any to any Except for you mistake, everything looks ok. -- Alex Please copy the original recipients, otherwise I may not read your reply. WWW: http://www.kruijff.org/alex/FreeBSD/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
yeah, I also didn't notice his return address at first. That already explains much :). I think I actually sorta, kinda got it working. I'll do some tests and update if my observations are valid. Drew Tomlinson wrote: On 10/28/2004 9:30 AM [EMAIL PROTECTED] wrote: Why don't you guys stop torturing yourself and wasting $1000s worth of your time and get yourself some real bandwidth management software? Its cheaper in the long run. FWIW, I've taken this suggestion with a grain of salt, based upon the general tone of this person's previous posts on a variety of subjects. I suggest you search the archives and draw your own conclusion. Drew Well kinda, sorta is the best you can hope for. Enjoy! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
yeah, I also didn't notice his return address at first. That already explains much :). I think I actually sorta, kinda got it working. I'll do some tests and update if my observations are valid. Drew Tomlinson wrote: On 10/28/2004 9:30 AM [EMAIL PROTECTED] wrote: Why don't you guys stop torturing yourself and wasting $1000s worth of your time and get yourself some real bandwidth management software? Its cheaper in the long run. FWIW, I've taken this suggestion with a grain of salt, based upon the general tone of this person's previous posts on a variety of subjects. I suggest you search the archives and draw your own conclusion. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: dummynet
s yeah, I also didn't notice his return s address at first. That already explains much :). s I think I actually sorta, kinda got it working. s I'll do some tests and update if my observations s are valid. - if your tests show positive results I would be very glad if you coud post your ipfw rules (with pipes and queues) to this list or send them to me, as I just can't seem to get sensible results out of anything more complex than a simple pipe bw. And a functioning real world example would help me that much. Thank you :) Greetz Hexren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
On Thu, 28 Oct 2004 17:18:19 -0400 (EDT), James Skinner [EMAIL PROTECTED] wrote: If you look further, you'll the wink (I was ribbing you). Similar to another one of threads. Obviously, you can dish it out, but can't take it. I have seen your past replys; you offer nothing but abuse. Do you sit around and wait for a newbie to ask a question so you can make him/her feel stupid for asking it? I entirely support this. Abusing a newbie and making him/her feel that she is a stupid wont get you anything. The only thing which may happen is, the newbie would just shy off leading to another Windows admin who does everything but knows nothing. BTW if you really wanna fight on your knowledge dare to do it with the gurus. Thx Something for you james, these guyz and not worth saying thanks and I mean it. So kindly stop thanking them. Regards S. -- Subhro Sankha Kar School of Information Technology Block AQ-13/1 Sector V ZIP 700091 India ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
I know it is about time for this thread to die, but I couldn't resist responding this once. On 10/28/2004 at 18:13 [EMAIL PROTECTED] wrote: I agree with some of that, but unless the person has the money to spend, then using dummnynet is acceptable. Not everyone can drop 10+ grand on a nokia firewall that has everything packaged into a nice gui. A commercial add-on for FreeBSD is $800. Half a weeks salary for a marginal programmer, and it actually works. Unless you live in Russia (or the Russian Federation or whatever the heck they call it now) and make $22/week I dont see the point of turturing yourself. The boss pays his sysadmin every week, no matter what. The Boss expects that the systems will runs with the least overall cost. Sometimes that means buying something, sometimes that means configuring what is there. There is always a point in learning. However there is not enough time in the world to learn everything, so you need to choose what you will learn. Just the fact that you know all the details of configuring something is valuable, because at sometime in the future your needs will change. Complex configuration is normally the cost of flexibility, so if you needs change all the time you are better of learning how to configure the free solution because in the long run the time spent learning configuration means you can jump in and reconfigure it as needed. If your needs rarely change then maybe you are better off learning something else with your time. (note that there are free things that are hard to configure without being flexable, but in generally free software is hard to configure because it is flexable) If your needs are such that you would need 10 commercial licenses, then by your numbers you are looking at $8000. For a company trying to deal with several offices this is possible. Now we are looking at a month or more worth of salary for our sysadmin. It is suddenly a lot easier to justify time spent learning. (in the case of hardware solutions it isn't unheard of for companies to have two of each machine, next to each other, but one off, just so any idiot can turn the spare on if things go wrong, we can easily add more licenses unless the legalese is right) If the commercial solution does what you need, and the free one doesn't, then you have to evaluate the cost of buying, vs the cost of implementing something. Managers should be good at this. Generally it will come down to buy, but there are exceptions. If your company is just on the edge justifying a full time sysadmin, but doesn't have 40/hours a week worth of stuff for him to do, then the sysadmin should be saving money by using free stuff wherever it works. If your company has hundreds of sysadmins, and is so complex that despite their best efforts nobody can really keep track of everything, then you should be more inclined to buying something that is easy to use. I'm sure there are more considerations too. Any argument for or against free software that ignores the above is flawed! Since you have stated a generalization that ignores the above, your argument is flawed, even if it is correct in nearly all cases. P.S. Note I'm using the term sysadmin, not programer. Programs can often admin, and sysadmins can often program, but the skill sets are different. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
In a message dated 10/29/04 8:26:51 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: The boss pays his sysadmin every week, no matter what. The Boss expects that the systems will runs with the least overall cost. Sometimes that means buying something, sometimes that means configuring what is there. Unfortunately most ISPs don't know much about business, so I guess explaining the concept of opportunity costs to you would be a waste of time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
The problem with dummynet is that once you do all the work and figure it all out, its still only marginally functional compared to something relatively inexpensive. So instead of buying the $3500 box that is everything you need, you've spend $800 on hardware, $2000 worth of time, and you still have something not nearly as good. One question, have you ever used dummynet? If so, I'm curious as to why you find it only marginal. Not to be rude, but if you've not used it, please stop trolling. -- Micheal Patterson TSG Network Administration 405-917-0600 One can tell by looking at the code that it won't scale. And I know more than 20 people who've been bitten on the butt by trying to use it, and then buying something when they hit the wall with it, or finding out it can't do what they need. The question is, have YOU used anything else? Or are you like the old woman who still washes her clothes in the river because those darned mechanical things aren't worth it? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
On 10/28/2004 9:30 AM [EMAIL PROTECTED] wrote: Why don't you guys stop torturing yourself and wasting $1000s worth of your time and get yourself some real bandwidth management software? Its cheaper in the long run. FWIW, I've taken this suggestion with a grain of salt, based upon the general tone of this person's previous posts on a variety of subjects. I suggest you search the archives and draw your own conclusion. Drew -- Visit The Alchemist's Warehouse Magic Tricks, DVDs, Videos, Books, More! http://www.alchemistswarehouse.com smime.p7s Description: S/MIME Cryptographic Signature
Re: dummynet
Why don't you guys stop torturing yourself and wasting $1000s worth of your time and get yourself some real bandwidth management software? Its cheaper in the long run. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dummynet
Why don't you guys stop torturing yourself and wasting $1000s worth of your time and get yourself some real bandwidth management software? Its cheaper in the long run. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Funny, I thought that's what Dummynet did. It seems that you wouldn't want to steer a user into a horribly overpriced closed-source rate-limiting solutuion when it's available for free in the OS. BTW: Nice email addr. ;) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
