[LARTC] Why did I need strange ceiling settings? (full version)
Sorry I pressed the wrong key and sent the message too early...
-Ursprüngliche Nachricht-
Von: Philipp Leusmann [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 8. November 2006 12:53
An: 'lartc@mailman.ds9a.nl'
Betreff: Why did I need strange ceiling settings?
Hi all,
I recently installed traffic shaping on my ADSL line with a nominal upload
rate of 1MBit. My Modem says it has an upload bitrate of 843 kbits.
So I thought, to use a ceiling of 800kbit for the root qdisc is a good
idea.
But with that setting I only achieved upload rates of around 300kbits
whereas I reached around 650 kbits without traffic shaping.
Yesterday I played a little with the ceiling value and found that
increasing it to 175kBps did the job.
Could anybody please explain this strange behaviour?
My shaping script looks as follows:
UPRATE=175kbps
P2PRATE=20kbps
PRIORATE1=80kbps
PRIORATE2=50kbps
PRIORATE3=40kbps
PRIORATE4=5kbps
MTU=`/sbin/ifconfig $EXTIF | grep 'MTU' | awk '{print $6}' | sed -e
's/.*://'`
# Quantum
QUANTUM1=$(($MTU*4))
QUANTUM2=$(($MTU*3))
QUANTUM3=$(($MTU*2))
QUANTUM4=$MTU
# Burst
## removed bursts
#BURST1=6k
#BURST2=4k
#BURST3=2k
#BURST4=0k
#CBURST1=3k
#CBURST2=2k
#CBURST3=1k
#CBURST4=0k
echo Set queue length for IFACE
# Set queue length for IFACE
ifconfig $IFACE txqueuelen 16
echo Trying to delete old ruleset. Will give error if it does not exist
tc qdisc del dev $IFACE root
echo Specify queue discipline
# Specify queue discipline
tc qdisc add dev $IFACE root handle 1:0 htb default 103
echo Set root class
# Set root class
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate $UPRATE ceil $UPRATE
echo Specify sub classes
# Specify sub classes
tc class add dev $IFACE parent 1:1 classid 1:101 htb rate $PRIORATE1 ceil
$UPRATE quantum $QUANTUM1 prio 0
tc class add dev $IFACE parent 1:1 classid 1:102 htb rate $PRIORATE2 ceil
$UPRATE quantum $QUANTUM2 prio 1
tc class add dev $IFACE parent 1:1 classid 1:103 htb rate $PRIORATE3 ceil
$UPRATE quantum $QUANTUM3 prio 2
tc class add dev $IFACE parent 1:1 classid 1:104 htb rate $PRIORATE4 ceil
$P2PRATE quantum $QUANTUM4 prio 3
echo Filter packets
# Filter packets
tc filter add dev $IFACE parent 1:0 protocol ip prio 0 handle $MARKPRIO1 fw
classid 1:101
tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle $MARKPRIO2 fw
classid 1:102
tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle $MARKPRIO3 fw
classid 1:103
tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle $MARKPRIO4 fw
classid 1:104
UPRATE=175kbps
P2PRATE=20kbps
PRIORATE1=80kbps
PRIORATE2=50kbps
PRIORATE3=40kbps
PRIORATE4=5kbps
MTU=`/sbin/ifconfig $EXTIF | grep 'MTU' | awk '{print $6}' | sed -e
's/.*://'`
# Quantum
QUANTUM1=$(($MTU*4))
QUANTUM2=$(($MTU*3))
QUANTUM3=$(($MTU*2))
QUANTUM4=$MTU
# Burst
## removed bursts
#BURST1=6k
#BURST2=4k
#BURST3=2k
#BURST4=0k
#CBURST1=3k
#CBURST2=2k
#CBURST3=1k
#CBURST4=0k
echo Set queue length for IFACE
# Set queue length for IFACE
ifconfig $IFACE txqueuelen 16
echo Trying to delete old ruleset. Will give error if it does not exist
tc qdisc del dev $IFACE root
echo Specify queue discipline
# Specify queue discipline
tc qdisc add dev $IFACE root handle 1:0 htb default 103
echo Set root class
# Set root class
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate $UPRATE ceil $UPRATE
echo Specify sub classes
# Specify sub classes
tc class add dev $IFACE parent 1:1 classid 1:101 htb rate $PRIORATE1 ceil
$UPRATE quantum $QUANTUM1 prio 0
tc class add dev $IFACE parent 1:1 classid 1:102 htb rate $PRIORATE2 ceil
$UPRATE quantum $QUANTUM2 prio 1
tc class add dev $IFACE parent 1:1 classid 1:103 htb rate $PRIORATE3 ceil
$UPRATE quantum $QUANTUM3 prio 2
tc class add dev $IFACE parent 1:1 classid 1:104 htb rate $PRIORATE4 ceil
$P2PRATE quantum $QUANTUM4 prio 3
echo Filter packets
# Filter packets
tc filter add dev $IFACE parent 1:0 protocol ip prio 0 handle $MARKPRIO1 fw
classid 1:101
tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle $MARKPRIO2 fw
classid 1:102
tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle $MARKPRIO3 fw
classid 1:103
tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle $MARKPRIO4 fw
classid 1:104
Thanks in advance and sorry for the incomplete posting.
Greetings,
Philipp
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Script for get bandwidth statistic from iptable
isearch a lot forum how to get bandwidth statistic such number of packet, total byte in each application protocol by using IPTABLES + netfilter-layer7 but i don't know which script for getting it in log file and use data after get it for plotting graph later my IPTABLES command like this iptables -t mangle -N all iptables -t mangle -A POSTROUTING -j all iptables -t mangle -A POSTROUTING -p udp --sport -j CLASSIFY --set-class 1:11 iptables -t mangle -A POSTROUTING -m layer7 --l7proto mms -j CLASSIFY --set-class 1:12 iptables -t mangle -A POSTROUTING -m layer7 --l7proto telnet -j CLASSIFY --set-class 1:13 iptables -t mangle -A POSTROUTING -m layer7 --l7proto ftp ftp-data -j CLASSIFY --set-class 1:14 iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j CLASSIFY --set-class 1:15 please advise me about perl script ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] bridge stops bridging
I recently upgraded my gateway to a pIII 600 with a zyxel 4 port nic (tulip) and bridge eth0 and eth1, eth0 is a crossover cable to my PC eth1 a switch. I don't have ifconfig on this box (LFS) and couldn't find any examples of bridging using ip - maybe this is relevant maybe not - I've tried a few combinations of different orders of setting things up. Is there a magic one? There is normally no traffic across the bridge - it is all to/from br0 (It's still needed though, for games that use ipx/same subnet and I multicast out of br0 (Don't know how to add a mcast route to more than one if). I expected things to just bridge, but this does not always happen (maybe timeout) eg pinging a box on the switch from box on eth0 fails at ip level - arp passes eth0 both ways, but I can't see any ip with tcpdump on eth0, pinging from a box on the switch however doesn't get arp replies from eth0. I can fix it by running a script on the bridge box to toggle eth0 down/up, which forces learning and all is then OK. brctl showmacs br0 looks no different whether it's working or not - all macs are shown and traffic to/from br0 always works. Kernel (tainted by dsl modem) is 2.6.17.11, iproute2-ss060323, bridge-utils 1.1. STP off (turning on doesn't fix) Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Why did I need strange ceiling settings? (full version)
Philipp Leusmann wrote: You will need to back off from the rates more and use kbit of course. tc qdisc add dev $IFACE root handle 1:0 htb default 103 default is bad if $IFACE is eth your arp will go here, also if eth Quantum should be set to ip mtu + 14. echo Set root class # Set root class tc class add dev $IFACE parent 1:0 classid 1:1 htb rate $UPRATE ceil $UPRATE echo Specify sub classes # Specify sub classes tc class add dev $IFACE parent 1:1 classid 1:101 htb rate $PRIORATE1 ceil $UPRATE quantum $QUANTUM1 prio 0 tc class add dev $IFACE parent 1:1 classid 1:102 htb rate $PRIORATE2 ceil $UPRATE quantum $QUANTUM2 prio 1 tc class add dev $IFACE parent 1:1 classid 1:103 htb rate $PRIORATE3 ceil $UPRATE quantum $QUANTUM3 prio 2 tc class add dev $IFACE parent 1:1 classid 1:104 htb rate $PRIORATE4 ceil $P2PRATE quantum $QUANTUM4 prio 3 Using different quantums makes more sense if classes have the same prio - like this the higher prio classes get all spare anyway if they need it. echo Filter packets # Filter packets tc filter add dev $IFACE parent 1:0 protocol ip prio 0 handle $MARKPRIO1 fw classid 1:101 tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle $MARKPRIO2 fw classid 1:102 tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle $MARKPRIO3 fw classid 1:103 tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle $MARKPRIO4 fw classid 1:104 Makes no difference as such in this case, but highest prio for filters is 1. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Lartc documentation version?
Hans du Plooy wrote: Hi guys, I'm just lurking and learning. Went to the lartc web page to read the howto. The page says the current version is 1.0.0 but in the pdf, on page 2 it says Revision: 1.43 - Which is it? Also, the instructions for cvs checkout gives me this: Logging in to :pserver:[EMAIL PROTECTED]:2401/var/cvsroot CVS password: cvs [login aborted]: connect to outpost.ds9a.nl(213.244.168.210):2401 failed: Connection refused I'm using the password suggested on the page. LARTC hasn't been updated for ages AFAIK - there was talk of setting up a wiki on linux-net.osdl.org but bert said he would do one himself Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Script for get bandwidth statistic from iptable
Thossapron Apinyapanha wrote: i search a lot forum how to get bandwidth statistic such number of packet, total byte in each application protocol by using IPTABLES + netfilter-layer7 but i don't know which script for getting it in log file and use data after get it for plotting graph later my IPTABLES command like this iptables -t mangle -N all iptables -t mangle -A POSTROUTING -j all iptables -t mangle -A POSTROUTING -p udp --sport -j CLASSIFY --set-class 1:11 iptables -t mangle -A POSTROUTING -m layer7 --l7proto mms -j CLASSIFY --set-class 1:12 iptables -t mangle -A POSTROUTING -m layer7 --l7proto telnet -j CLASSIFY --set-class 1:13 iptables -t mangle -A POSTROUTING -m layer7 --l7proto ftp ftp-data -j CLASSIFY --set-class 1:14 iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j CLASSIFY --set-class 1:15 please advise me about perl script Don't know about scripts as such - iptables -Lvn will give stats. I think the above will need connmark aswell to work properly. I haven't tried l7 but suspect the above rules will only classify the first packets of each connection. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Bridge and Router on the same device
I want to configure a device with three network interfaces where two of them would bridge two segments of the LAN subnet and the third one would be connected to the WAN link.eth0 - 10.10.10.2/24 to be connected to the internet gateway having IP 10.10.10.1/24 (also the default gateway for the device)eth1 and eth2 bridged as br0 with IP address 172.16.100.1 connected to different segments of the subnet 172.16.100.0/24. WAN (10.10.10.1) | | eth0 (10.10.10.2)-eth1 eth2-- LAN (172.16.100.0/24) LAN (172.16.100.0/24)I plan to configure the Bridge IP ( 172.16.100.1) as the default gateway for the LAN and also regulate the traffic between the two bridged interfaces (eth1 and eth2) using a user space tool. Further since the traffic meant for internet would pass through eth0, there would be a need to regulate the traffic between eth1 and eth0 and also eth2 and eth0. Is the above arrangement feasible ? Would it be possible to define static routes on this device itself involving hosts reachable through either of the interfaces.Thank you in advance. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Troubles DNATing UDP
В Птн, 10/11/2006 в 16:39 +0100, dAm2K пишет: Once again, all those packets reach INPUT chain, rules in -t nat -I PREROUTING not working. So here is the question: Does the UDP is being DNAT'ed differently comparing with TCP? What is the difference? How can I DNAT them? If your HW UDP pinger's default gateway is your natting firewall, try to ping directly the 192.168.1.2 web server. If default gateway is another router, try adding the route 192.168.1.0/25 to you HW pingers and ping directly 192.168.1.2. That would probably help, but it is not desirable. The topology may change, so it's better ping the closest roouter and to natting in it. If this is not possible (and you are UDP pinging you firewall) open dport 4000 udp in INPUT chain on your firewall and do natting: iptables -t filter -A INPUT -p udp -m udp -s 10.10.0.0/16 -d 10.10.100.1 --dport 4000 -j ACCEPT iptables -t nat -A PREROUTING -p udp -m udp -s 10.10.0.0/16 -d 10.10.100.1 --dport 4000 -j DNAT --to-destination 192.168.1.2 This way 192.168.1.2 host should receive udp packets coming from the firewall. This is what I've done. But, packets are reaching INPUT chain, counters of the first rule are increasing, and packets are not reaching second rule, it's counters are zero all the time. And DNAT'ing not working :/ My setup is running smoothly with UDP and NAT, I'm using with playstation online games... Hope this help. Bye, Dino. -- Покотиленко Костик [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Troubles DNATing UDP
В Птн, 10/11/2006 в 10:31 -0600, Taylor, Grant пишет: Покотиленко Костик wrote: snip As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to redirect them to 192.168.1.2 by: iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT --to-destination 192.168.1.2:4000 iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT (Before morning coffee...) One quick question / point. Your source and destination ports are both 4000 right? (I presuming yes.) Your PREROUTING rule is looking to DNAT any UDP traffic that has a destination port of 4000 to 192.168.1.2. What happens to the reply traffic from 192.168.1.2 that is destined to port 4000 on 10.0.x.y? There is not such traffic as that kind of ping not supposed to do replay. Explain latter. Neither of those rules not catching the packets, they all reach 10.10.100.1 INPUT chain. Those rule counters are zero. Hum. Try adding a rule similar to this: iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j LOG To see if you can match the packets at all. I did that, nothing is matched. This is strange. If I do: iptables -t mangle -I PREROUTING 1 -p udp --dport 4000 this rule catch needed packets, but not in NAT tables! Why? I would expect that you could match the packets any where they traverse the kernel. snip Here is tcpdump from 10.10.100.1: # tcpdump -i br0 port 4000 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 16:36:53.202130 IP 10.10.100.23.4000 10.10.100.1.4000: UDP, length: 74 16:36:54.092413 IP 10.10.100.21.4000 10.10.100.1.4000: UDP, length: 74 16:36:54.143128 IP 10.10.100.22.4000 10.10.100.1.4000: UDP, length: 74 16:36:55.291886 IP 10.10.100.23.4000 10.10.100.1.4000: UDP, length: 74 16:36:55.545621 IP 10.10.100.22.4000 10.10.100.1.4000: UDP, length: 74 16:36:55.743096 IP 10.10.100.21.4000 10.10.100.1.4000: UDP, length: 74 Hum... Once again, all those packets reach INPUT chain, rules in -t nat -I PREROUTING not working. You appear to be using a bridge interface, not a real network interface. (Not that this is a problem.) Do you have the Bridged IP/ARP packets filtering option enabled in the kernel? If you do, this option will enable NetFilter Layer 3 filtering at the EBTables Layer 2 level. I.e. you can use IPTables to filter bridged traffic. In this case you will need to write rules to allow your bridged traffic to flow through, as it is dependent on your Table / CHAIN default policies. There are alot of other udp and tcp traffic already comming through. So here is the question: Does the UDP is being DNAT'ed differently comparing with TCP? What is the difference? How can I DNAT them? I do not think that the problem is with the protocol(s) per say, but rather the filtering that is in place. Will you please do an iptables-save output so that we can see your entire firewall script to better evaluate what is going on. I'll study the situation once again today and send the entire rules if no luck. Thanks in advance. No problem. P.S. This king of UDP ping doesn't require responce, its just to see which remote point is still alive. Sorry, I have to ask. How are you going to be able to tell if a point is active if you do not get a reply? Are you looking for some sort of anomaly in reply / error (or lack there of) traffic to determine if a point is active? You should get 1 packet per second from each HW pinger, if you don't get or get less than 1packet/s from particular HW pinger, then there are problems with the route to that HW pinger. For debugging purpose it's possible to ping clients in between and figure out where the problem starts to take place. -- Покотиленко Костик [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
