[LARTC] traffic shaping with NAT: IFB as IMQ replacement?
Hello, Sorry for the many Ccs, but I hope to reach all parties involved. I want to do traffic shaping with NAT and I wanted to do it with IFB instead of IMQ [1]. I tried a lot of things but now I am stuck (and maybe confused). The setup: eth0 eth1 WAN/(Internet) - Linux Router - LAN Linux router: - does NAT for the LANs - runs local processes communicating with the WAN/Internet Incoming and outgoing traffic on eth0 should be subject to traffic shaping. I put quotes here, because it seems the term policing would be used for the incoming traffic directed at the router itself. It is not an ideal solution to drop incoming packets, but assuming TCP, intelligent dropping (shaping) is still much better than plain rate limiting or no action at all. (see also parts of [2]). If there is a better solution than ingress shaping available or being worked on, please tell me. First of all: Why is it difficult? Because you can't use the advanced qdics (htb, cbq, ...) on ingres directly (only the ingress qdisc). Using IMQ it is quite straightforward to work around this limitation. It seems IFB is intented as IMQ replacement [3] I managed to use IFB as IMQ replacement in a setup without NAT. But when NAT is involved I am in trouble because when I want to classify the packets they still have the translated addresses. I could live with the translated addresses if I could use netfilter connection tracking information to classify the packets [4]. This was also discussed in the thread [3]: Jamal Hadi Salim writes: [...] Instead the plan is to have a contrack related action. This action will selectively either query/create contrack state on incoming packets. Packets could then be redirected to dummy based on what happens - eg on incoming packets; if we find they are of known state we could send to a different queue than one which didnt have existing state. This all however is dependent on whatever rules the admin enters. [...] I tried something like: tc filter add dev ... match all ... \ action ipt -j CONNMARK --restore-mark \ action ipt -j LOG --log-prefix ... \ action continue tc filter add dev ... handle some-mark \ action ipt -j LOG --log-prefix ... to no avail. I couldn't find any information whether this is possible now or what steps it would take to implement this? Greetings Jens PS: similar threads on the LARTC mailing list: http://thread.gmane.org/gmane.linux.network.routing/25922 http://www.spinics.net/lists/lartc/msg19965.html (many more) [1] IMQ: http://www.linuximq.net/ [2] shaping: http://mailman.ds9a.nl/pipermail/lartc/2004q3/013093.html [3] IFB: netdev mailing list thread dummy as IMQ replacement Message-Id: [EMAIL PROTECTED] http://marc.info/?l=linux-netdevm=110712327422706w=2 [4] Note: I think using the old policer [Symbol: NET_CLS_POLICE [=n] Prompt: Traffic Policing (obsolete)] this maybe works? It seems ingress policing happens after netfilter PREROUTING if you use NET_CLS_POLICE but using NET_CLS_ACT it happens before netfilter PREROUTING? (see also: sch_ingress.c and http://mailman.ds9a.nl/pipermail/lartc/2005q4/017782.html) But then again it is marked as obsolete and I need NET_CLS_ACT to redirect to the IFB?! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] wondershaper and dmzs
I have a pretty simple setup. I've got a linux nat box, with some internal hosts. I've also got some servers in a dmz. It looks something like this: Internet | (external network) | | | | linuxdmz nathosts | | (office network) | | office hosts I'd like to shape the office traffic that's going out to the internet, while leaving the office traffic to the dmz alone. After all, the network link the dmz fast. I've been using wondershaper, since it's easy and works well, but I'm not sure how to add in an exception for the dmz hosts. Can I do this with tc, or is the entire interface shaped? It seems like I might be able to create a more explicate filter, but I'm having trouble getting it to work. seph ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] wondershaper and dmzs
On Thu, Mar 29, 2007 at 12:16:20 -0400, seph [EMAIL PROTECTED] wrote: Can I do this with tc, or is the entire interface shaped? It seems like I might be able to create a more explicate filter, but I'm having trouble getting it to work. You can filter on the destination ip address. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] RE: IFB setup was no subject
Leigh Sharpe wrote: Nup. Well, not directly. This is going on our backbone, so I'm not taking traffic straight off the wireless. Ultimately, it will be delivered to a customer over a wireless link, but there's lots of ethernet between the QOS box and the wireless. By the way, wireless != 802.11, there's plenty of other flavours which all taste just like ethernet. It was the numifbs 1000 and your sig that made me think wireless customers. I just saw a patch go in for ifb that fixes a potential crash. http://www.spinics.net/lists/netdev/msg28168.html Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] traffic shaping with NAT: IFB as IMQ replacement?
Here's what Jamal said for those only on LARTC ... I understand this requirement; unfortunately when i polled for features majority of people who emailed back were asking for the other things. I have changed my opinion a little since last time because the netfilter/contracking code now does netlink. I believe this could all be achieved in user space. Infact i have started writting some code - the problem is my time has become intermittent. If i can get someone who can work with me to complete the work, I will be more than happy to get that last bastion of IMQ done. So if you are a fireman willing to be a hero (I guess all firemen want to be heroes, why else would they be firemen?) email me privately and we can get this done. cheers, jamal PS:- i have removed lartc from the list because it bounces my emails and i refuse to subscribe. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Fairness queuing across a range of IP addresses
Oscar Mechanic wrote: On Tue, 2007-03-20 at 20:09 +0100, Ales Klok wrote: Derek Sims wrote: I have a block of IP addresses (2048) used for ADSL connections to customers. In order to provide a fair slice of available bandwidth on the contended services I would like to be able to set up some kind of SFQ filter, but using a hash of the destination IP address rather than the the full source and destination ip and port. This would be done at the Internet side gateway for traffic being sent towards the customer's IP address. Can anybody suggest how this could be done with qdiscs? TIA Derek Hi Derek, if i understand what you wanna do then i think you are looking for ESFQ. With ESFQ you can choose hash type from classic, dest IP or src IP. /ak As an ISP with 800 clients I found the hashs difficult to manage after time. Also when dealing with clients who want subnet /29 mapping back to a billing entry was hard. I wrote some PHP so other could use web front end and used ipset (both hash and net sets) and combining with marks to do the traffic control for different levels of service. As the client requirements grew changed this ended in allot of panic PHP. So i use 3rd party vendor device. My advice would be to use 2 devices 1 to mark traffic and do access control and use ds_shed to control traffic on other device. I think I went wrong in trying to do all on one device. The latest esfq used jhash - so should be better than the old hash. http://fatooh.org/esfq-2.6/ Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem attaching htb class to a htb qdisc
Ruben Porras wrote:
I'm trying to build a QoS system that would divide the outgoing traffic
into four categories, each one also subdivided into two more categories.
For that I chose a htb root qdisc subdivided into four classes, each of
these classes contains also a htb qdisc. Until these point everything
goes well, but when I try to attach a new class to the leaf htb qdisc a
problem with the sintaxis arises. Code follows:
tc qdisc add dev $DEV root handle 1: htb default 30
Remember if $DEV is eth arp will go here.
tc class add dev $DEV parent 1: classid 1:1 htb rate
${UPLINK}kbit
tc class add dev $DEV parent 1:1 classid 1:10 htb rate
${UPLINK}kbit
tc class add dev $DEV parent 1:1 classid 1:20 htb rate
${UPLINK}kbit
tc class add dev $DEV parent 1:1 classid 1:30 htb rate
${UPLINK}kbit
tc class add dev $DEV parent 1:1 classid 1:40 htb rate
${UPLINK}kbit
If you want UPLNK to be the max then children need UPLINK/4 - the parent
will not cap it. Use ceil UPLINK aswell if you want each to be able to
reach max when other classes are empty.
tc qdisc add dev $DEV parent 1:10 handle 10: htb default 12
This is strange, not sure if it's what you want - you don't need another
htb here, though it is possible it's not normal. If you just want a
child under 1:10 then do as you do below with parent 1:10, but remember
parents don't cap rate of children.
tc class add dev $DEV parent 10: classid 1:11 htb rate
${UPLINK}kbit
prio 1
If you really want htb under htb then classid 10:11 may work.
Andy.
RTNETLINK answers: Invalid argument
tc class add dev $DEV parent 10: classid 1:12 htb rate
${UPLINK}kbit
prio 2
RTNETLINK answers: Invalid argument
tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 10
tc qdisc add dev $DEV parent 1:12 handle 12: sfq perturb 10
...
If I attach the classes to 1: instead of 10: everything goes well, but I
do not understand why I can't attach a class to 10:
Any help would be appreciated.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Please Help: applying multiple different delays with netem
I'm trying to use tc and netem to delay packets from several different machines as they exit via eth0. Assume two source IPs, 10.0.0.122 and 10.0.0.133. I'd like to delay packets from the first one by 200ms, and packets from the second one by 300 ms. Any other traffic should be sent out normally. Here's what I tried: # make three classes, 1:1, 1:2, and 1:3: tc qdisc add dev eth0 root handle 1: prio # attach netem with 200ms delay to priority 2 hook: tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 200ms # attach netem with 300ms delay to priority 3 hook: tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 300ms # classify packets from .122 as priority 2: tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 \ match ip src 10.0.0.122/32 flowid 10:2 # classify packets from .133 as priority 3: tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 \ match ip src 10.0.0.133/32 flowid 10:3 This works, except unclassified traffic (e.g., from another machine 10.0.0.111) will ALWAYS be delayed by 200 ms (same as traffic matched to priority 2). How do I make unmatched traffic go through normally ? Do I need to attach a qdisc to priority 1, or is there an assumed default qdisc already there ? Is there something magic about priority 2, and do I need to understand and modify the priomap to fix this? Would this way of doing things generalize for more classes with different delays applied to them ? This is the first time I've dealt with this, and I'm somewhat shocked and awed :) Any help is much appreciated ! Thanks, Gabriel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
TC Protocols was RE: [LARTC] RE: IFB setup was no subject
Try protocol 8021q or whatever its number is - Thanks Andy, this did the trick. And now for the next question. 802.1q is protocol number 0x8100. Therefore my filter lines look like this: Tc filter add dev eth3 parent : protocol 0x8100 prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0 What is the u32 matching on? Is it matching on IP headers, or is it matching on the protocol specified, ie the VLAN header? For my particular application, I need to decide which IFB to redirect to based on combinations of both VLAN ID and IP src/dst addresses. Can I specify matches for the VLAN ID here? If so, I would presume that I can then use an Iptables mark to filter on, with that mark based on IP address? (ebtables can't match the IP address of a tagged packet, unfortunately.) Otherwise, I'm going to have to mark the packets with a VLAN ID using ebtables and then another mark from Iptables based on src/dst IP address. What a sodding nightmare. Regards, Leigh Leigh Sharpe Network Systems Engineer Pacific Wireless Ph +61 3 9584 8966 Mob 0408 009 502 Helpdesk 1300 300 616 email [EMAIL PROTECTED] web www.pacificwireless.com.au -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 12:33 PM To: Leigh Sharpe Cc: lartc Subject: Re: [LARTC] RE: IFB setup was no subject Leigh Sharpe wrote: Seems that the example I gave actually works, but not the way I'm using it. I am bridging VLAN tagged packets, Try protocol 8021q or whatever its number is - if there are other protocol filters you will need a different prio or you will get an error. but for some reason they are not being subjected to the rate limit. If I pass normal, untagged packets through this setup, it behaves as expected. However, once I put tagged packets through the bridge, it fails to shape traffic. I don't want to have to use VLAN sub-interfaces, because the VLAN code strips the 802.1q tag from packets before they can be examined, which causes me problems in other areas. Are these wireless customers? I've never shaped wireless - do you get alot of extra loss from link layer, what's the bandwidth, single duplex or is it round robin type? I wonder if htb tweaked/untweaked/hfsc/policers could be better than cbq - you may be able to get things better for link latyer, tcpdumps will show you how bursty things are for users. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
