[LARTC] traffic controlling
Please help me with few of my doubts - 1. difference b/w traffic controlling using TOS and using qdiscs. 2. Where does Diffserv comes into picture. 3. If I say, we can do TOS using iptables command and qdiscs using TC, am I right. Thanks and regards, Arshad ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Multipath routing + traffic separation problem.
Your settings seem to be correct, I just don't know why you don't want to balance http, https and ftp traffic between both connections? About the bug, I haven't used linux 2.4 for a long time, for 2.6, fwmark is in hexa, so be careful with 10 vs. 0xa, you'd better use values less than 0xa to avoid confusing. Also make sure that no default route is added to your main table. On Wed, 2005-04-06 at 12:09 +0200, Laurent LAVAUD wrote: Hello, I have set up a multipath gateway. System is a linux 2.4.29 kernel, iproute 20010824, iptables 1.2.11. here is the setup: firewall:/# ip rule 0: from all lookup local 100:from all lookup main 152:from all fwmark 10 lookup wan1 153:from all fwmark 20 lookup wan2 201:from 213.223.96.121 lookup wan1 202:from 82.236.230.217 lookup wan2 1000: from all lookup away Fw-cgarp:/etc/firegate# ip route ls table wan1 default via 213.223.96.122 dev eth0 src 213.223.96.121 prohibit default metric 1 Fw-cgarp:/etc/firegate# ip route ls table wan2 default via 82.236.230.254 dev eth3 src 82.236.230.217 prohibit default metric 1 Fw-cgarp:/etc/firegate# ip route ls table away default nexthop via 82.236.230.254 dev eth3 weight 1 nexthop via 213.223.96.122 dev eth0 weight 1 Fw-cgarp:/etc/firegate# iptables-save -t mangle # Generated by iptables-save v1.2.11 on Wed Apr 6 11:57:06 2005 *mangle :PREROUTING ACCEPT [3281:1066576] :INPUT ACCEPT [411:32992] :FORWARD ACCEPT [2870:1033584] :OUTPUT ACCEPT [339:63745] :POSTROUTING ACCEPT [3195:1096657] -A PREROUTING -p tcp -m tcp --dport 25 -j MARK --set-mark 0xa -A PREROUTING -p tcp -m mport --dports 80,443,21 -j MARK --set-mark 0x14 COMMIT # Completed on Wed Apr 6 11:57:06 2005 So with this configuration all the http,https and ftp traffic must be routed by the 'wan2' connection. I have done severals tests and it dont work, i have also had a realms mark to my routing rule and with the "rtacct" command i saw that traffic going through the correct rule, but http traffic continues to be balanced between the two connections... If someone see the problem ? Thx in advance. ___ 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] Re: [Netem] netem with prio hangs on duplicate
Try this alternative, it changes where netem does the delaying and doesn't
do queuing in the timer routine. It is stable for the basic tests, but I still
consider
it experimental and needs more testing.
Patch against the version of sch_netem.c in 2.6.12-rc2
--- linux-2.6.12-rc2/net/sched/sch_netem.c 2005-04-04 09:39:41.0
-0700
+++ netem-2.6.12-rc2/net/sched/sch_netem.c 2005-04-06 15:39:16.0
-0700
@@ -138,38 +138,78 @@ static long tabledist(unsigned long mu,
}
/* Put skb in the private delayed queue. */
-static int delay_skb(struct Qdisc *sch, struct sk_buff *skb)
+static int netem_delay(struct Qdisc *sch, struct sk_buff *skb)
{
struct netem_sched_data *q = qdisc_priv(sch);
- struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb;
psched_tdiff_t td;
psched_time_t now;
PSCHED_GET_TIME(now);
td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist);
- PSCHED_TADD2(now, td, cb->time_to_send);
/* Always queue at tail to keep packets in order */
if (likely(q->delayed.qlen < q->limit)) {
+ struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb;
+
+ PSCHED_TADD2(now, td, cb->time_to_send);
+
+ pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb,
+now, cb->time_to_send);
+
__skb_queue_tail(&q->delayed, skb);
- if (!timer_pending(&q->timer)) {
- q->timer.expires = jiffies + PSCHED_US2JIFFIE(td);
- add_timer(&q->timer);
- }
return NET_XMIT_SUCCESS;
}
+ pr_debug("netem_delay: queue over limit %d\n", q->limit);
+ sch->qstats.overlimits++;
kfree_skb(skb);
return NET_XMIT_DROP;
}
+/*
+ * Move a packet that is ready to send from the delay holding
+ * list to the underlying qdisc.
+ */
+static int netem_run(struct Qdisc *sch)
+{
+ struct netem_sched_data *q = qdisc_priv(sch);
+ struct sk_buff *skb;
+ psched_time_t now;
+
+ PSCHED_GET_TIME(now);
+
+ skb = skb_peek(&q->delayed);
+ if (skb) {
+ const struct netem_skb_cb *cb
+ = (const struct netem_skb_cb *)skb->cb;
+ long delay
+ = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now));
+ pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay);
+
+ /* if more time remaining? */
+ if (delay > 0) {
+ mod_timer(&q->timer, jiffies + delay);
+ return 1;
+ }
+
+ __skb_unlink(skb, &q->delayed);
+
+ if (q->qdisc->enqueue(skb, q->qdisc)) {
+ sch->q.qlen--;
+ sch->qstats.drops++;
+ }
+ }
+
+ return 0;
+}
+
static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
struct netem_sched_data *q = qdisc_priv(sch);
struct sk_buff *skb2;
int ret;
- pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies);
+ pr_debug("netem_enqueue skb=%p\n", skb);
/* Random packet drop 0 => none, ~0 => all */
if (q->loss && q->loss >= get_crandom(&q->loss_cor)) {
@@ -184,7 +224,7 @@ static int netem_enqueue(struct sk_buff
&& (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) {
pr_debug("netem_enqueue: dup %p\n", skb2);
- if (delay_skb(sch, skb2)) {
+ if (netem_delay(sch, skb2)) {
sch->q.qlen++;
sch->bstats.bytes += skb2->len;
sch->bstats.packets++;
@@ -202,7 +242,8 @@ static int netem_enqueue(struct sk_buff
ret = q->qdisc->enqueue(skb, q->qdisc);
} else {
q->counter = 0;
- ret = delay_skb(sch, skb);
+ ret = netem_delay(sch, skb);
+ netem_run(sch);
}
if (likely(ret == NET_XMIT_SUCCESS)) {
@@ -241,56 +282,35 @@ static unsigned int netem_drop(struct Qd
return len;
}
-/* Dequeue packet.
- * Move all packets that are ready to send from the delay holding
- * list to the underlying qdisc, then just call dequeue
- */
static struct sk_buff *netem_dequeue(struct Qdisc *sch)
{
struct netem_sched_data *q = qdisc_priv(sch);
struct sk_buff *skb;
+ int pending;
+
+ pending = netem_run(sch);
skb = q->qdisc->dequeue(q->qdisc);
- if (skb)
+ if (skb) {
+ pr_debug("netem_dequeue: return skb=%p\n", skb);
sch->q.qlen--;
+ sch->flags &= ~TCQ_F_THROTTLED;
+ }
+ else if (pending) {
+ pr_debug("netem_dequeue: throttling\n");
+ sch->flags |= TCQ_F_THROTTLED;
+ }
+
return skb;
}
static void netem_watchdog(un
Re: [LARTC] Games and QOS on share connection line
Ludek Horak wrote: > Hello. I'm newbie with QoS. I read some articles and I have a question on > You. If you have time to spare, it would be great > if you reply. Here is my problem. I'm on wireless network(no earnig > comunity). We got 2/2Mbit(soon 4/4) for 100 people(sharing link). Not long > ago people start > screaming that their games don't work good(lagging). So I add to our qos > class games with highest prio. I don't know much about game traffic. So I add > this class: > $TC class add dev eth0 parent 1:1 classid 1:3 htb rate 64kbit ceil 256kbit > burst 6k cburst 6k prio 0 > Then I add every game port(War3 6112,CS 27015-6, OU, Quake3 etc.) : > $TC filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 6112 > 0x match ip protocol 0x11 0xff flowid 1:3 > > What do you think about this configuration? Do you know better setting for > gaming traffic on share connection line? I'd like to know your opinions. I'm > appreciating your comments. > Thank you in advance I came to a similar conclusion with regard to games, and set up something similar myself. So far it's worked ok. The only thing to watch out for is what happens to your latency as bandwidth levels approach the full capacity of your connection. Even if game traffic has high priority that won't save you from high latency when the connection is saturated. You may have to reduce your overall ceil from 2048 to, say, 1900. Experiment to find a good value. -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [OBORONA-SPAM] [LARTC] ppp+vpn+htb
On Wed, 6 Apr 2005 00:44:55 +0200 "mail.cat-net.co.yu" <[EMAIL PROTECTED]> wrote: > please, help, i have build vpn server (suse 9 + poptop), i have managed to > implement tc htb in ip-up script, but every client has own ppp interface > (ppp0, ppp1, ppp2...), and my idea is to share available bandwidth, not to > limit connection, > > how to build root tc rule, when I have more then one interface?... please any > one width experiance > > regards Few month ago I have such trable too. Now I subscribed to this mail list in hope to resolve problem :). My workaround done in a following way: 1.Difference is that I use pptpd. 2.The idea is to drive all traffic to unlim on a dev eth0, except "gre 1723". The traffic I wish to control I classify as default! 3.The rules a here: /sbin/tc qdisc del dev eth0 root /sbin/tc qdisc add dev eth0 root handle 1 htb default 30 r2q 100 /sbin/tc class add dev eth0 parent 1: classid 1:2 htb rate 100Mbit burst 15K /sbin/tc class add dev eth0 parent 1:2 classid 1:10 htb rate 50Mbit burst 5K prio 5 /sbin/tc qdisc add dev eth0 parent 1:10 handle 10 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 80 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 110 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 110 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 25 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 139 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 139 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 137 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 137 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 138 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 138 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 445 0x classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 445 0x classid 1:10 /sbin/tc class add dev eth0 parent 1:2 classid 1:30 htb rate 200Kbit ceil 200Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:30 handle 30 sfq perturb 10 /sbin/tc class add dev eth0 parent 1:30 classid 1:1010 htb rate 10Kbit ceil 80Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:1010 handle 1010 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.19.10 classid 1:1010 /sbin/tc class add dev eth0 parent 1:30 classid 1:1011 htb rate 10Kbit ceil 80Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:1011 handle 1011 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.19.11 classid 1:1011 /sbin/tc class add dev eth0 parent 1:30 classid 1:1012 htb rate 10Kbit ceil 80Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:1012 handle 1012 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.19.12 classid 1:1012 And so on. This rules were compiled with help of shapecfg-2.2.12-15asp. Command - htb. But all of this is wrong, only workaround. Month of searching of ability to bridge (brctl), eql, teql etc. - bring nothing. What I have to do :) - C, sources and compiler. I made little change to eql.c making this module only transparent transit device. It's working... But I have some bugs, and now need help and testing. As I understood - qdisc and class can not apply to more then one device... Is it wrong? Be free for asking more and feeding back. And I am sorry if I have many mistakes in my English. -- With best regards, Pan'ko Alexzender. [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Suspicious Attachment
-- Warning: Message delivery wasn't performed. Reason: Our virus scanner detected very suspicious code in the attachment of a mail addressed to a user of our system. The following message will not be delivered: From: [EMAIL PROTECTED] To: LARTC@mailman.ds9a.nl Subj: [LARTC] Re: Date: Wed, 06 Apr 2005 23:26:43 +0530 Virus: Worm.Bagle.Gen-zippwd Feel free to contact no_one if you can't cope with it. -- This mail was automatically generated by TrashScan v0.12 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] SQLiaison E-Mail Virus Alert
SQLiaison Mail Server: GroupShield™ Alert The email server has discovered a problem with the following email. Please note that the sender of the email will not be notified with this message. > More information : Date/Time sent: 06 Apr 2005 14:00:42 Subject line: [LARTC] Re: From: [EMAIL PROTECTED] To: LARTC Action taken: Deleted Virus Found: W32/[EMAIL PROTECTED] Reason: Anti-Virus Rule Group: For additional information, please contact SQLiaison Support Team [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] [ANNOUNCE] ESFQ for Linux 2.6.12-rc1
On Wed, 06 Apr 2005 09:22:13 +0100 Andy Furniss <[EMAIL PROTECTED]> wrote: > Corey Hickey wrote: > > http://fatooh.org/esfq-2.6/ > > http://fatooh.org/esfq-2.6/esfq-2.6.12-rc1.tar.gz > > > > This version no longer interferes with the original SFQ; unlike previous > > versions, you can still use an unpatched tc with SFQ. Patching tc is > > still needed for ESFQ, though. I've tested this patch with Linux 2.6.11 > > as well. > > > > Please tell me if you have any problems. I'm subscribed to lartc again. > > Thanks Corey - maybe this version will get in kernel one day. It will if someone submits it for review to [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK vs CLASSIFY with tc
Hi Wang Jian, On Wed 06 Apr 2005 17:18, Wang Jian wrote: > ... > It depends. You must consider the ruleset size and ruleset pattern. > > For a large ruleset. It is not good to let every packet goes through the > rule and gets matched on some class. Think about 200 rules as an example. > > It is better to have some kind of memory on a flow. If first packet of a > flow is classified as class C1, then it good to remember it and every > following packet of this flow is classified as class C1. > > iptables/netfilter has CONNMARK support, which can be used to remember > an u32 number, and then set packet's mark from this CONNMARK. > > You can use such scheme > > # if the flag is set, then restore connmark to mark > iptables -m connmark --mark value/mask -j CONNMARK --restore-mark --mask >mask Do you know if this mask here is able to match more then one mark? Like if say, to mach the marks range from 1 (0x2710) to 2 (0x4e20) the above will be: iptables ... -m connmark --mark 0x2710/0xb1df -j CONNMARK --restore-mask --mask 0xb1df where 0xb1df is (65535 XOR 2). I guess is just XOR not XOR then +1 (this will give a mask value of 0xb1e0) which I saw in some examples (google) of using the masking bits. > # else, do the various match > iptables -j CONNMARK --set-mark value/mask > iptables -j RETURN > iptables -j CONNMARK --set-mark value/mask > iptables -j RETURN > it makes a lot of sense (have to review a bit the netfilter/iptables docs to bring myself up to speed) > Using this method, first packet is matched in O(N), but following > packets are matched in O(1). > > So it is good to use iptables CONNMARK + MARK and tc fw filter. > > But, if the ruleset is small, the difference should be small. You then > should choose the better one for you: > > 1. netfilter is more flexible; > 2. tc filter is expected to be a little faster (I am not sure); > Thanks a lot, Adrian ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: ADSL overhead patch
Jesper Dangaard Brouer wrote: Hmm, I just googled/looked at Ed Wildgoose's patch, and I is not correct/precise. You can read why my patch is correct/precise in Section 6.1.2 of the Thesis (which gives a description of the patch). Yes it was always not quite perfect - but it was safe - a cell too safe Ed knew this. I just made one for UK like you do it - but nowhere near as comprehensivly - It doesnt do mpu/overhead as just assumes you already hacked whatever calls rtab to be aal5_len - 1, which as you say is just one line in htb. Mine is for UK pppoatm but if you know your overheads it's easy to modify - Do you? there are tables in the doc linked to. In Chapter 5, I have tried to summarize the different types of encapsulation methods and their according overheads, for easy reference. Is is still a problem figuring out, which type of encapsulation your specific ADSL connection is using... Yes I agree it can look confusing, life is easier if like me you have a modem that gives a cell count and a quiet link. It's just a case of sending various sized pings then. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Games and QOS on share connection line
Hello. I'm newbie with QoS. I read some articles and I have a question on You. If you have time to spare, it would be great if you reply. Here is my problem. I'm on wireless network(no earnig comunity). We got 2/2Mbit(soon 4/4) for 100 people(sharing link). Not long ago people start screaming that their games don't work good(lagging). So I add to our qos class games with highest prio. I don't know much about game traffic. So I add this class: $TC class add dev eth0 parent 1:1 classid 1:3 htb rate 64kbit ceil 256kbit burst 6k cburst 6k prio 0 Then I add every game port(War3 6112,CS 27015-6, OU, Quake3 etc.) : $TC filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 6112 0x match ip protocol 0x11 0xff flowid 1:3 What do you think about this configuration? Do you know better setting for gaming traffic on share connection line? I'd like to know your opinions. I'm appreciating your comments. Thank you in advance Main part of script: $TC qdisc add dev eth0 root handle 1: htb default 300 r2q 2 $TC class add dev eth0 parent 1: classid 1:1 htb rate 1024kbit ceil 2048kbit burst 15k $TC class add dev eth0 parent 1:1 classid 1:3 htb rate 64kbit ceil 256kbit burst 6k cburst 6k prio 0 # Games class $TC class add dev eth0 parent 1:1 classid 1:5 htb rate 64kbit ceil 256kbit burst 5k prio 0# SSH class $TC class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit ceil 2048kbit burst 5k prio 1 # interactive class $TC class add dev eth0 parent 1:1 classid 1:20 htb rate 32kbit ceil 64kbit burst 5k prio 1 # ping class $TC class add dev eth0 parent 1:1 classid 1:40 htb rate 32kbit ceil 1024kbit burst 5k prio 3 # data transfer class $TC class add dev eth0 parent 1:1 classid 1:50 htb rate 32kbit ceil 1024kbit burst 9k prio 4 # email class $TC class add dev eth0 parent 1:1 classid 1:60 htb rate 32kbit ceil 1024kbit burst 8k prio 3 # squid class $TC class add dev eth0 parent 1:1 classid 1:300 htb rate 32kbit ceil 1024kbit burst 1k prio 4 # default trafic class $TC qdisc add dev eth0 parent 1:3 handle 3: $STOCHASIS # Games class $TC qdisc add dev eth0 parent 1:5 handle 5: $STOCHASIS # SSH sub-classes $TC qdisc add dev eth0 parent 1:10 handle 10: $STOCHASIS# interactive sub-classes $TC qdisc add dev eth0 parent 1:20 handle 20: $STOCHASIS# ping $TC qdisc add dev eth0 parent 1:30 handle 30: $STOCHASIS# routing $TC qdisc add dev eth0 parent 1:40 handle 40: $STOCHASIS# data transfer $TC qdisc add dev eth0 parent 1:50 handle 50: $STOCHASIS# email $TC qdisc add dev eth0 parent 1:60 handle 60: $STOCHASIS# squid $TC qdisc add dev eth0 parent 1:300 handle 300: $STOCHASIS # default class # Warcraft 3 $TC filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 6112 0x match ip protocol 0x11 0xff flowid 1:3 $TC filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 6112 0x match ip protocol 0x11 0xff flowid 1:3 $TC filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 6112 0x match ip protocol 0x6 0xff flowid 1:3 $TC filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 6112 0x match ip protocol 0x6 0xff flowid 1:3 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ADSL overhead patch (was: Qos with 2 internet connections problems)
On Wed, 6 Apr 2005, Andy Furniss wrote: Jason Boxman wrote: On Tuesday 05 April 2005 18:36, Francisco Pereira wrote: I would recommend reading the masters thesis of Jesper Dangaard Brouer at http://www.adsl-optimizer.dk/thesis/ Altough he didnt release software yet (there is some code & patches in the pdf file) which could lead to the best solution, you could estimate the adsl overhead with real knowledge, and not like it says in some scripts (put x kbit less than the link bandwith, or 5% less,...) I have been eagerly awaiting the release of that software myself. (see my other excuse mail... ;-) I am testing a version at the moment based on Ed Wildgoose's - if that didn't work for you though, I can't see why this one should. Hmm, I just googled/looked at Ed Wildgoose's patch, and I is not correct/precise. You can read why my patch is correct/precise in Section 6.1.2 of the Thesis (which gives a description of the patch). Mine is for UK pppoatm but if you know your overheads it's easy to modify - Do you? there are tables in the doc linked to. In Chapter 5, I have tried to summarize the different types of encapsulation methods and their according overheads, for easy reference. Is is still a problem figuring out, which type of encapsulation your specific ADSL connection is using... Hilsen Jesper Brouer -- --- Research Assistant Dept. of Computer Science, University of Copenhagen E-mail: [EMAIL PROTECTED], Direct Tel.: 353 21438 --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK vs CLASSIFY with tc
Hi Adrian Turcu, On Wed, 6 Apr 2005 16:28:30 +0100, Adrian Turcu <[EMAIL PROTECTED]> wrote: > Hello list, > > I just wonder if someone did any performance tests (speed of processing the > packets) or maybe could advise about this two scenario: > > 1. packets are marked with iptables and processed by tc using filters > 2. packets are sent by iptables directly to tc using CLASSIFY chain, thus > avoiding the tc filters > > I had some thinking about these two ways of dealing with egress traffic and > my > logic says that the second should be faster to process the packets, but I > might be wrong (I guess that being an iproute list there will be a lot of > people in favour of the first - going even further by skipping iptables all > together and using detailed filtering with tc). > It depends. You must consider the ruleset size and ruleset pattern. For a large ruleset. It is not good to let every packet goes through the rule and gets matched on some class. Think about 200 rules as an example. It is better to have some kind of memory on a flow. If first packet of a flow is classified as class C1, then it good to remember it and every following packet of this flow is classified as class C1. iptables/netfilter has CONNMARK support, which can be used to remember an u32 number, and then set packet's mark from this CONNMARK. You can use such scheme # if the flag is set, then restore connmark to mark iptables -m connmark --mark value/mask -j CONNMARK --restore-mark --mask mask # else, do the various match iptables -j CONNMARK --set-mark value/mask iptables -j RETURN iptables -j CONNMARK --set-mark value/mask iptables -j RETURN Using this method, first packet is matched in O(N), but following packets are matched in O(1). So it is good to use iptables CONNMARK + MARK and tc fw filter. But, if the ruleset is small, the difference should be small. You then should choose the better one for you: 1. netfilter is more flexible; 2. tc filter is expected to be a little faster (I am not sure); > This came up not just for fun nor that I saw some noticeable differences (not > with the volume of traffic I'm having at the moment). I want to regulate the > traffic from a multimedia server (RTSP) and everybody knows that audio/video > traffic is very sensitive to variable latency and jitter with terrible > end-user experience. > > BTW I'm using HTB with SFQ, kernel 2.6.11.6, iproute2 ss050318 and iptables > 1.3.1. I used PFIFO before SFQ, but it seems that it takes quite a lot for > the per stream bandwidth to be re-adjusted in case a new session opens and > I'm already at the limit with the allocated slice from the total available > pipe. > > Thanks for taking your time thinking about this, > Adrian > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- lark ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Qos with 2 internet connections problems
On Tue, 5 Apr 2005, Jason Boxman wrote: On Tuesday 05 April 2005 18:36, Francisco Pereira wrote: I would recommend reading the masters thesis of Jesper Dangaard Brouer at http://www.adsl-optimizer.dk/thesis/ Altough he didnt release software yet (there is some code & patches in the pdf file) which could lead to the best solution, you could estimate the adsl overhead with real knowledge, and not like it says in some scripts (put x kbit less than the link bandwith, or 5% less,...) I have been eagerly awaiting the release of that software myself. Sorry, I have not released the software yet... I have been delayed by the birth of my little new daughter... have not gotten much sleep lately. (http://www.trykdenaf.dk/gallery/silke_fodsel) I can release the patches and a "beta" version of the scripts, if people will give me some feedback on the tar.gz distribution file and can live with too much debug information/output from the graph-module. One of my friends are trying out the tar.gz distribution file today. He will hopefully give me some positive feedback tomorrow, wether he succesfully can follow the install instruction and have a functional system. Hilsen Jesper Brouer -- --- Research Assistant and Network Administrator Dept. of Computer Science, University of Copenhagen E-mail: [EMAIL PROTECTED], Direct Tel.: 353 21438 --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] MARK vs CLASSIFY with tc
Hello list, I just wonder if someone did any performance tests (speed of processing the packets) or maybe could advise about this two scenario: 1. packets are marked with iptables and processed by tc using filters 2. packets are sent by iptables directly to tc using CLASSIFY chain, thus avoiding the tc filters I had some thinking about these two ways of dealing with egress traffic and my logic says that the second should be faster to process the packets, but I might be wrong (I guess that being an iproute list there will be a lot of people in favour of the first - going even further by skipping iptables all together and using detailed filtering with tc). This came up not just for fun nor that I saw some noticeable differences (not with the volume of traffic I'm having at the moment). I want to regulate the traffic from a multimedia server (RTSP) and everybody knows that audio/video traffic is very sensitive to variable latency and jitter with terrible end-user experience. BTW I'm using HTB with SFQ, kernel 2.6.11.6, iproute2 ss050318 and iptables 1.3.1. I used PFIFO before SFQ, but it seems that it takes quite a lot for the per stream bandwidth to be re-adjusted in case a new session opens and I'm already at the limit with the allocated slice from the total available pipe. Thanks for taking your time thinking about this, Adrian ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] tbf latency problems!
Hi i have found a problem related with tbf and the latency that the tbf calculates.. I have used the following parameters for burst and limit burst 100Kbit limit 500Kbit lat81.8ms burst 6Kbit limit 6Kbitlat 0us burst 200Kbit limit 100Kbit lat 4294.9s As u can see in the 3rd column the latency for 100Kbit burst and 500Kbit limit is 81.8ms but for 200Kbit and limit 100Kbit is 4294.9s!!! How could be possible??? I want to find a way to caclulate the latency for a packet entering my tbf.. What do u suggest me to do? Ah! I use the tc -s qdisc ls dev eth1 command for the tbf statistics __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem
Hi John E. Peterson, Yes. My stupid typo. On Wed, 6 Apr 2005 10:08:20 -0400, "John E. Peterson" <[EMAIL PROTECTED]> wrote: > Did you mean POSTROUTING to PREROUTING? That looked wierd. > > - Original Message - > From: "Wang Jian" <[EMAIL PROTECTED]> > To: "Remus" <[EMAIL PROTECTED]> > Cc: ; <[EMAIL PROTECTED]> > Sent: Wednesday, April 06, 2005 10:03 AM > Subject: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem > > > > Hi Remus, > > > > > > On Wed, 6 Apr 2005 14:48:03 +0100, "Remus" <[EMAIL PROTECTED]> wrote: > > > >> Wang, > >> > >> That solution does not suite me: > >> >ip route add default via $DEFAULTGW dev eth1 > >> >ip route add xxx.xxx.xxx.xxx/32 via $ANOTHERGW dev eth0 > >> Because only UPD 1194 has to be routed via eth0 to OpenVPN server IP, > >> everything else > >> to same Ip has to go via eth1. > > > > I see. So you need policy routing. Change your netfilter rule from > > POSTROUTING to POSTROUTING. > > > > > >> > >> > >> - Original Message - > >> From: "Wang Jian" <[EMAIL PROTECTED]> > >> To: "Remus" <[EMAIL PROTECTED]> > >> Cc: ; <[EMAIL PROTECTED]> > >> Sent: Wednesday, April 06, 2005 1:38 PM > >> Subject: Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing > >> problem > >> > >> > >> > Hi Remus, > >> > > >> > I means: don't use policy routing, because you can use much simpler > >> > solution. > >> > > >> > Example: > >> > > >> > ip route add default via $DEFAULTGW dev eth1 > >> > ip route add xxx.xxx.xxx.xxx/32 via $ANOTHERGW dev eth0 > >> > > >> > The second, send all your traffic to IP xxx.xxx.xxx.xxx via eth0. When > >> > your box acts as your intranet's gateway, you can SNAT or MASQUERADE on > >> > eth0, like > >> > > >> > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. > >> > > >> > > >> > For you openvpn configuration, you can either bind openvpn to eth0's > >> > ip, > >> > or let system chooose the IP, in most case the output interface. > >> > > >> > > >> > On Wed, 6 Apr 2005 12:54:53 +0100, "Remus" <[EMAIL PROTECTED]> > >> > wrote: > >> > > >> >> Hi Wang, > >> >> > >> >> We specialy got two Internet connections, one is only for the OpenVPN > >> >> (it > >> >> is > >> >> heavily used) and second for everthing else. > >> >> I will give a try to PREROUTING stuff right away. > >> >> > >> >> What do mean : But I don't think you need to use MARK to do policy > >> >> routing. > >> >> It's a little overkill. > >> >> > >> >> Do you another suggestion than iptables/MARK? > >> >> > >> >> Regards > >> >> > >> >> Remus > >> >> > >> >> > >> >> - Original Message - > >> >> From: "Wang Jian" <[EMAIL PROTECTED]> > >> >> To: > >> >> Cc: "Remus" <[EMAIL PROTECTED]>; > >> >> <[EMAIL PROTECTED]> > >> >> Sent: Wednesday, April 06, 2005 12:23 PM > >> >> Subject: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing > >> >> problem > >> >> > >> >> > >> >> > Hi Remus, > >> >> > > >> >> > It seems that > >> >> > > >> >> > iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 1194 -j > >> >> > MARK \ > >> >> >--set-mark 0x990 > >> >> > > >> >> > will not take effect. (didn't you typo -A as -D?) > >> >> > > >> >> > POSTROUTING is looked up after routing decision is made. Because the > >> >> > default route is dev eth1, the output device is eth1, -o eth0 will > >> >> > not > >> >> > match. > >> >> > > >> >> > You should use > >> >> > > >> >> > iptables -t mangle -A PREROUTING -p udp --destination >> >> > \ > >> >> >peer> --dport 1194 -j MARK > >> >> > > >> >> > But I don't think you need to use MARK to do policy routing. It's a > >> >> > little overkill. > >> >> > > >> >> > Why not simply route all traffic to your openvpn peer via device > >> >> > eth0? > >> >> > > >> >> > > >> >> > On Wed, 6 Apr 2005 11:51:16 +0100, "Remus" <[EMAIL PROTECTED]> > >> >> > wrote: > >> >> > > >> >> >> > >> >> >> Hi folks, > >> >> >> > >> >> >> I have OpenVPN (respect for it developers) running on my FW. > >> >> >> Is has two external NICs and on internal everything is fine, except > >> >> >> I want OpenVPN (UDP port 1194) going not via default route/network > >> >> >> interface. > >> >> >> > >> >> >> I use such commands: > >> >> >> > >> >> >> iptables -t mangle -D POSTROUTING -o eth0 -p udp --dport 1194 -j > >> >> >> MARK --set-mark 0x990 > >> >> >> ip rule add fwmark 0x990 table openvpn1 > >> >> >> ip route add default via $P2 dev eth0 table openvpn1 > >> >> >> > >> >> >> eth0 is FW's not default external NIC. > >> >> >> > >> >> >> I have in use very similar iptables rules for my email server (TCP > >> >> >> ports) > >> >> >> and etc. > >> >> >> Everything works fine. > >> >> >> What I'm doing wrong with marking/routing the UDP port? > >> >> >> > >> >> >> Regards > >> >> >> > >> >> >> Remus > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > lark > >> >> > > >> >> > > >> >> > > >> >> > --- > >> >> > SF email is sponsored by - The IT Product Guide > >> >> > Read honest & c
Re: [LARTC] UDP port 1194 marking/routing problem
Hi Remus, On Wed, 6 Apr 2005 14:48:03 +0100, "Remus" <[EMAIL PROTECTED]> wrote: > Wang, > > That solution does not suite me: > >ip route add default via $DEFAULTGW dev eth1 > >ip route add xxx.xxx.xxx.xxx/32 via $ANOTHERGW dev eth0 > Because only UPD 1194 has to be routed via eth0 to OpenVPN server IP, > everything else > to same Ip has to go via eth1. I see. So you need policy routing. Change your netfilter rule from POSTROUTING to POSTROUTING. > > > - Original Message - > From: "Wang Jian" <[EMAIL PROTECTED]> > To: "Remus" <[EMAIL PROTECTED]> > Cc: ; <[EMAIL PROTECTED]> > Sent: Wednesday, April 06, 2005 1:38 PM > Subject: Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing > problem > > > > Hi Remus, > > > > I means: don't use policy routing, because you can use much simpler > > solution. > > > > Example: > > > > ip route add default via $DEFAULTGW dev eth1 > > ip route add xxx.xxx.xxx.xxx/32 via $ANOTHERGW dev eth0 > > > > The second, send all your traffic to IP xxx.xxx.xxx.xxx via eth0. When > > your box acts as your intranet's gateway, you can SNAT or MASQUERADE on > > eth0, like > > > > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. > > > > > > For you openvpn configuration, you can either bind openvpn to eth0's ip, > > or let system chooose the IP, in most case the output interface. > > > > > > On Wed, 6 Apr 2005 12:54:53 +0100, "Remus" <[EMAIL PROTECTED]> wrote: > > > >> Hi Wang, > >> > >> We specialy got two Internet connections, one is only for the OpenVPN (it > >> is > >> heavily used) and second for everthing else. > >> I will give a try to PREROUTING stuff right away. > >> > >> What do mean : But I don't think you need to use MARK to do policy > >> routing. > >> It's a little overkill. > >> > >> Do you another suggestion than iptables/MARK? > >> > >> Regards > >> > >> Remus > >> > >> > >> - Original Message - > >> From: "Wang Jian" <[EMAIL PROTECTED]> > >> To: > >> Cc: "Remus" <[EMAIL PROTECTED]>; > >> <[EMAIL PROTECTED]> > >> Sent: Wednesday, April 06, 2005 12:23 PM > >> Subject: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing > >> problem > >> > >> > >> > Hi Remus, > >> > > >> > It seems that > >> > > >> > iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 1194 -j MARK \ > >> >--set-mark 0x990 > >> > > >> > will not take effect. (didn't you typo -A as -D?) > >> > > >> > POSTROUTING is looked up after routing decision is made. Because the > >> > default route is dev eth1, the output device is eth1, -o eth0 will not > >> > match. > >> > > >> > You should use > >> > > >> > iptables -t mangle -A PREROUTING -p udp --destination >> >peer> --dport 1194 -j MARK > >> > > >> > But I don't think you need to use MARK to do policy routing. It's a > >> > little overkill. > >> > > >> > Why not simply route all traffic to your openvpn peer via device eth0? > >> > > >> > > >> > On Wed, 6 Apr 2005 11:51:16 +0100, "Remus" <[EMAIL PROTECTED]> > >> > wrote: > >> > > >> >> > >> >> Hi folks, > >> >> > >> >> I have OpenVPN (respect for it developers) running on my FW. > >> >> Is has two external NICs and on internal everything is fine, except > >> >> I want OpenVPN (UDP port 1194) going not via default route/network > >> >> interface. > >> >> > >> >> I use such commands: > >> >> > >> >> iptables -t mangle -D POSTROUTING -o eth0 -p udp --dport 1194 -j > >> >> MARK --set-mark 0x990 > >> >> ip rule add fwmark 0x990 table openvpn1 > >> >> ip route add default via $P2 dev eth0 table openvpn1 > >> >> > >> >> eth0 is FW's not default external NIC. > >> >> > >> >> I have in use very similar iptables rules for my email server (TCP > >> >> ports) > >> >> and etc. > >> >> Everything works fine. > >> >> What I'm doing wrong with marking/routing the UDP port? > >> >> > >> >> Regards > >> >> > >> >> Remus > >> >> > >> > > >> > > >> > > >> > -- > >> > lark > >> > > >> > > >> > > >> > --- > >> > SF email is sponsored by - The IT Product Guide > >> > Read honest & candid reviews on hundreds of IT Products from real > >> > users. > >> > Discover which products truly live up to the hype. Start reading now. > >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >> > ___ > >> > Openvpn-users mailing list > >> > [EMAIL PROTECTED] > >> > https://lists.sourceforge.net/lists/listinfo/openvpn-users > >> > > >> > > >> > >> > >> ___ > >> LARTC mailing list > >> LARTC@mailman.ds9a.nl > >> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > > > > > > -- > > lark > > > > > > > > --- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _
Re: [LARTC] DMZ and WAN
Andrew Nady wrote: Hola, I have a question in regards to ignoring traffic shaping for LAN side that connects to a DMZ IMAP server through the WAN interface. The DMZ and the WAN side are both on a 10/100 switch. Is it possible? Should be - think of a way to identify traffic from/to server ipaddress/macaddress etc. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] UDP port 1194 marking/routing problem
Wang, That solution does not suite me: ip route add default via $DEFAULTGW dev eth1 ip route add xxx.xxx.xxx.xxx/32 via $ANOTHERGW dev eth0 Because only UPD 1194 has to be routed via eth0 to OpenVPN server IP, everything else to same Ip has to go via eth1. Any ideas? Regards Remus - Original Message - From: "Wang Jian" <[EMAIL PROTECTED]> To: "Remus" <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]> Sent: Wednesday, April 06, 2005 1:38 PM Subject: Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem Hi Remus, I means: don't use policy routing, because you can use much simpler solution. Example: ip route add default via $DEFAULTGW dev eth1 ip route add xxx.xxx.xxx.xxx/32 via $ANOTHERGW dev eth0 The second, send all your traffic to IP xxx.xxx.xxx.xxx via eth0. When your box acts as your intranet's gateway, you can SNAT or MASQUERADE on eth0, like iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. For you openvpn configuration, you can either bind openvpn to eth0's ip, or let system chooose the IP, in most case the output interface. On Wed, 6 Apr 2005 12:54:53 +0100, "Remus" <[EMAIL PROTECTED]> wrote: Hi Wang, We specialy got two Internet connections, one is only for the OpenVPN (it is heavily used) and second for everthing else. I will give a try to PREROUTING stuff right away. What do mean : But I don't think you need to use MARK to do policy routing. It's a little overkill. Do you another suggestion than iptables/MARK? Regards Remus - Original Message - From: "Wang Jian" <[EMAIL PROTECTED]> To: Cc: "Remus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, April 06, 2005 12:23 PM Subject: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem > Hi Remus, > > It seems that > > iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 1194 -j MARK \ >--set-mark 0x990 > > will not take effect. (didn't you typo -A as -D?) > > POSTROUTING is looked up after routing decision is made. Because the > default route is dev eth1, the output device is eth1, -o eth0 will not > match. > > You should use > > iptables -t mangle -A PREROUTING -p udp --destination >peer> --dport 1194 -j MARK > > But I don't think you need to use MARK to do policy routing. It's a > little overkill. > > Why not simply route all traffic to your openvpn peer via device eth0? > > > On Wed, 6 Apr 2005 11:51:16 +0100, "Remus" <[EMAIL PROTECTED]> > wrote: > >> >> Hi folks, >> >> I have OpenVPN (respect for it developers) running on my FW. >> Is has two external NICs and on internal everything is fine, except >> I want OpenVPN (UDP port 1194) going not via default route/network >> interface. >> >> I use such commands: >> >> iptables -t mangle -D POSTROUTING -o eth0 -p udp --dport 1194 -j >> MARK --set-mark 0x990 >> ip rule add fwmark 0x990 table openvpn1 >> ip route add default via $P2 dev eth0 table openvpn1 >> >> eth0 is FW's not default external NIC. >> >> I have in use very similar iptables rules for my email server (TCP >> ports) >> and etc. >> Everything works fine. >> What I'm doing wrong with marking/routing the UDP port? >> >> Regards >> >> Remus >> > > > > -- > lark > > > > --- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > ___ > Openvpn-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- lark --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Openvpn-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openvpn-users ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Qos with 2 internet connections problems
Anthony Letchet wrote: Lan machines -> Linux Router -> Alcatel Router -> ADSL Lan Machine -> linux router -> alcatel router2 -> ADSL Alcatel router -> Linux router Alcatel router -> mail server etc So not all traffic goes through Linux router? As Francisco says you need to back off from link rates - even if you do perfect calculation you can only max egress - you won't build up a queue if you are upto the limit for ingress. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Qos with 2 internet connections problems
Jason Boxman wrote: On Tuesday 05 April 2005 18:36, Francisco Pereira wrote: I would recommend reading the masters thesis of Jesper Dangaard Brouer at http://www.adsl-optimizer.dk/thesis/ Altough he didnt release software yet (there is some code & patches in the pdf file) which could lead to the best solution, you could estimate the adsl overhead with real knowledge, and not like it says in some scripts (put x kbit less than the link bandwith, or 5% less,...) I have been eagerly awaiting the release of that software myself. I am testing a version at the moment based on Ed Wildgoose's - if that didn't work for you though, I can't see why this one should. Mine is for UK pppoatm but if you know your overheads it's easy to modify - Do you? there are tables in the doc linked to. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ppp+vpn+htb
mail.cat-net.co.yu wrote: please, help, i have build vpn server (suse 9 + poptop), i have managed to implement tc htb in ip-up script, but every client has own ppp interface (ppp0, ppp1, ppp2...), and my idea is to share available bandwidth, not to limit connection, how to build root tc rule, when I have more then one interface?... please any one width experiance regards You may be able to do it on ethx by marking or classifying in forward/postrouting and hoping the marks survive encapsulation. I've never tried so don't know. If that fails there is also a chance you can do it with IMQ or the dummy device (You will need to build a 2.6 and use a different dummy.c I don't think the new one is in kernel yet). Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] new perflow rate control queue
Hi Andy Furniss, On Wed, 06 Apr 2005 13:29:56 +0100, Andy Furniss <[EMAIL PROTECTED]> wrote: > > > > I read back your post and I think the best solution for you is use HTB + > > PRIO. > > I sort of have htb setup like prio but it's more flexable. I am glad to hear that :) > > > > Let interactive but low rate traffic have highest priority, and let bulk > > transfer have lowest priority and constrain them using HTB. > > > > TCP itself has some fairness: slower stream get faster, and faster > > stream get slower. The sliding window is for this. > > TCP can be very unfair in some cases - different window sizes/scale on > off and 56k vs broadband peer. > Yes. This unfairness is generally a good thing (but not always). It is in favour of tcp connection in the fast/wide path, so bandwidth can be used "efficiently" :) > I am rebuilding stuff on my gateway at the moment and noticed the > iproute patch doesn't compile with gcc 2.95.3 it's fine with 3.3. > > q_perflow.c: In function `perflow_print_opt': > q_perflow.c:141: parse error before `char' > q_perflow.c:142: `b1' undeclared (first use in this function) > q_perflow.c:142: (Each undeclared identifier is reported only once > q_perflow.c:142: for each function it appears in.) > make[1]: *** [q_perflow.o] Error 1 > This is due to the included . Regards -- lark ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem
Hi Remus, I means: don't use policy routing, because you can use much simpler solution. Example: ip route add default via $DEFAULTGW dev eth1 ip route add xxx.xxx.xxx.xxx/32 via $ANOTHERGW dev eth0 The second, send all your traffic to IP xxx.xxx.xxx.xxx via eth0. When your box acts as your intranet's gateway, you can SNAT or MASQUERADE on eth0, like iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. For you openvpn configuration, you can either bind openvpn to eth0's ip, or let system chooose the IP, in most case the output interface. On Wed, 6 Apr 2005 12:54:53 +0100, "Remus" <[EMAIL PROTECTED]> wrote: > Hi Wang, > > We specialy got two Internet connections, one is only for the OpenVPN (it is > heavily used) and second for everthing else. > I will give a try to PREROUTING stuff right away. > > What do mean : But I don't think you need to use MARK to do policy routing. > It's a little overkill. > > Do you another suggestion than iptables/MARK? > > Regards > > Remus > > > - Original Message - > From: "Wang Jian" <[EMAIL PROTECTED]> > To: > Cc: "Remus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Wednesday, April 06, 2005 12:23 PM > Subject: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem > > > > Hi Remus, > > > > It seems that > > > > iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 1194 -j MARK \ > >--set-mark 0x990 > > > > will not take effect. (didn't you typo -A as -D?) > > > > POSTROUTING is looked up after routing decision is made. Because the > > default route is dev eth1, the output device is eth1, -o eth0 will not > > match. > > > > You should use > > > > iptables -t mangle -A PREROUTING -p udp --destination >peer> --dport 1194 -j MARK > > > > But I don't think you need to use MARK to do policy routing. It's a > > little overkill. > > > > Why not simply route all traffic to your openvpn peer via device eth0? > > > > > > On Wed, 6 Apr 2005 11:51:16 +0100, "Remus" <[EMAIL PROTECTED]> wrote: > > > >> > >> Hi folks, > >> > >> I have OpenVPN (respect for it developers) running on my FW. > >> Is has two external NICs and on internal everything is fine, except > >> I want OpenVPN (UDP port 1194) going not via default route/network > >> interface. > >> > >> I use such commands: > >> > >> iptables -t mangle -D POSTROUTING -o eth0 -p udp --dport 1194 -j > >> MARK --set-mark 0x990 > >> ip rule add fwmark 0x990 table openvpn1 > >> ip route add default via $P2 dev eth0 table openvpn1 > >> > >> eth0 is FW's not default external NIC. > >> > >> I have in use very similar iptables rules for my email server (TCP ports) > >> and etc. > >> Everything works fine. > >> What I'm doing wrong with marking/routing the UDP port? > >> > >> Regards > >> > >> Remus > >> > > > > > > > > -- > > lark > > > > > > > > --- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > ___ > > Openvpn-users mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > > > > > > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- lark ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] new perflow rate control queue
Wang Jian wrote: I read back your post and I think the best solution for you is use HTB + PRIO. I sort of have htb setup like prio but it's more flexable. Let interactive but low rate traffic have highest priority, and let bulk transfer have lowest priority and constrain them using HTB. TCP itself has some fairness: slower stream get faster, and faster stream get slower. The sliding window is for this. TCP can be very unfair in some cases - different window sizes/scale on off and 56k vs broadband peer. I am rebuilding stuff on my gateway at the moment and noticed the iproute patch doesn't compile with gcc 2.95.3 it's fine with 3.3. q_perflow.c: In function `perflow_print_opt': q_perflow.c:141: parse error before `char' q_perflow.c:142: `b1' undeclared (first use in this function) q_perflow.c:142: (Each undeclared identifier is reported only once q_perflow.c:142: for each function it appears in.) make[1]: *** [q_perflow.o] Error 1 Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ppp+vpn+htb
Hi hiphin, On Wed, 6 Apr 2005 13:39:40 +0200, "hiphin" <[EMAIL PROTECTED]> wrote: > Wang, hi, little of thinking and listen what I found logical > > Q1: Is ppp interface, as only one connection on my real eth0 ? > > If answare is YES, then simple SFQ on eth0 is good ? > ...and main difference SFQ/ESFQ is that SFQ watching connections, and ESFQ > watching host IP... > You didn't tell if you use pptp, but I think you use pptp. ppp interface in this case is a peusdo network interface, under it there is IP connection between client and server. So your control the ip connection's rate, and then you can control the ppp interface. So if you want fairness amongst these interfaces, you can either enforce fairness on connection ( 1 client only has 1 ppp connection) or enforce fairness on host (1 client may have multiple ppp connection but you take the client as one) > Q2: I have 2.4.xx, kernel ESFQ is for 2.6 kernel only ? > > > I need to limit max bandwidth for all users and fair share, do not need to > have guaranteed-minimum > > mathematic is simple: N*user <= 256kbps > > soo if I have one user on vpn, hi gets 256kbps > if I have 2 users on vpn downloading, both is getting max 128kbps > and soo on... > > (this is too simple to be ...) I am not familiar with ESFQ. In my test, SFQ doesn't provide good fairness. ESFQ should have some improvement, I think. Any good implemented fair queue can achieve your goal. -- lark ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Suspicious Attachment
-- Warning: Message delivery wasn't performed. Reason: Our virus scanner detected very suspicious code in the attachment of a mail addressed to a user of our system. The following message will not be delivered: From: [EMAIL PROTECTED] To: LARTC@mailman.ds9a.nl Subj: [LARTC] Re: Date: Wed, 06 Apr 2005 17:40:40 +0530 Virus: Worm.Bagle.AG.2 Feel free to contact no_one if you can't cope with it. -- This mail was automatically generated by TrashScan v0.12 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] SQLiaison E-Mail Virus Alert
SQLiaison Mail Server: GroupShield™ Alert The email server has discovered a problem with the following email. Please note that the sender of the email will not be notified with this message. > More information : Date/Time sent: 06 Apr 2005 08:15:13 Subject line: [LARTC] Re: From: [EMAIL PROTECTED] To: LARTC Action taken: Deleted Virus Found: W32/[EMAIL PROTECTED] Reason: Anti-Virus Rule Group: For additional information, please contact SQLiaison Support Team [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem
Hi Wang, We specialy got two Internet connections, one is only for the OpenVPN (it is heavily used) and second for everthing else. I will give a try to PREROUTING stuff right away. What do mean : But I don't think you need to use MARK to do policy routing. It's a little overkill. Do you another suggestion than iptables/MARK? Regards Remus - Original Message - From: "Wang Jian" <[EMAIL PROTECTED]> To: Cc: "Remus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, April 06, 2005 12:23 PM Subject: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem Hi Remus, It seems that iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 1194 -j MARK \ --set-mark 0x990 will not take effect. (didn't you typo -A as -D?) POSTROUTING is looked up after routing decision is made. Because the default route is dev eth1, the output device is eth1, -o eth0 will not match. You should use iptables -t mangle -A PREROUTING -p udp --destination --dport 1194 -j MARK But I don't think you need to use MARK to do policy routing. It's a little overkill. Why not simply route all traffic to your openvpn peer via device eth0? On Wed, 6 Apr 2005 11:51:16 +0100, "Remus" <[EMAIL PROTECTED]> wrote: Hi folks, I have OpenVPN (respect for it developers) running on my FW. Is has two external NICs and on internal everything is fine, except I want OpenVPN (UDP port 1194) going not via default route/network interface. I use such commands: iptables -t mangle -D POSTROUTING -o eth0 -p udp --dport 1194 -j MARK --set-mark 0x990 ip rule add fwmark 0x990 table openvpn1 ip route add default via $P2 dev eth0 table openvpn1 eth0 is FW's not default external NIC. I have in use very similar iptables rules for my email server (TCP ports) and etc. Everything works fine. What I'm doing wrong with marking/routing the UDP port? Regards Remus -- lark --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Openvpn-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openvpn-users ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ppp+vpn+htb
Wang, hi, little of thinking and listen what I found logical Q1: Is ppp interface, as only one connection on my real eth0 ? If answare is YES, then simple SFQ on eth0 is good ? ...and main difference SFQ/ESFQ is that SFQ watching connections, and ESFQ watching host IP... Q2: I have 2.4.xx, kernel ESFQ is for 2.6 kernel only ? I need to limit max bandwidth for all users and fair share, do not need to have guaranteed-minimum mathematic is simple: N*user <= 256kbps soo if I have one user on vpn, hi gets 256kbps if I have 2 users on vpn downloading, both is getting max 128kbps and soo on... (this is too simple to be ...) ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] UDP port 1194 marking/routing problem
Hi Remus, It seems that iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 1194 -j MARK \ --set-mark 0x990 will not take effect. (didn't you typo -A as -D?) POSTROUTING is looked up after routing decision is made. Because the default route is dev eth1, the output device is eth1, -o eth0 will not match. You should use iptables -t mangle -A PREROUTING -p udp --destination --dport 1194 -j MARK But I don't think you need to use MARK to do policy routing. It's a little overkill. Why not simply route all traffic to your openvpn peer via device eth0? On Wed, 6 Apr 2005 11:51:16 +0100, "Remus" <[EMAIL PROTECTED]> wrote: > > Hi folks, > > I have OpenVPN (respect for it developers) running on my FW. > Is has two external NICs and on internal everything is fine, except > I want OpenVPN (UDP port 1194) going not via default route/network interface. > > I use such commands: > > iptables -t mangle -D POSTROUTING -o eth0 -p udp --dport 1194 -j MARK > --set-mark 0x990 > ip rule add fwmark 0x990 table openvpn1 > > ip route add default via $P2 dev eth0 table openvpn1 > > eth0 is FW's not default external NIC. > > I have in use very similar iptables rules for my email server (TCP ports) and > etc. > Everything works fine. > What I'm doing wrong with marking/routing the UDP port? > > Regards > > Remus > -- lark ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] UDP port 1194 marking/routing problem
Hi folks, I have OpenVPN (respect for it developers) running on my FW. Is has two external NICs and on internal everything is fine, except I want OpenVPN (UDP port 1194) going not via default route/network interface. I use such commands: iptables -t mangle -D POSTROUTING -o eth0 -p udp --dport 1194 -j MARK --set-mark 0x990 ip rule add fwmark 0x990 table openvpn1 ip route add default via $P2 dev eth0 table openvpn1 eth0 is FW's not default external NIC. I have in use very similar iptables rules for my email server (TCP ports) and etc. Everything works fine. What I'm doing wrong with marking/routing the UDP port? Regards Remus ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Multipath routing + traffic separation problem.
Hello, I have set up a multipath gateway. System is a linux 2.4.29 kernel, iproute 20010824, iptables 1.2.11. here is the setup: firewall:/# ip rule 0: from all lookup local 100:from all lookup main 152:from all fwmark 10 lookup wan1 153:from all fwmark 20 lookup wan2 201:from 213.223.96.121 lookup wan1 202:from 82.236.230.217 lookup wan2 1000: from all lookup away Fw-cgarp:/etc/firegate# ip route ls table wan1 default via 213.223.96.122 dev eth0 src 213.223.96.121 prohibit default metric 1 Fw-cgarp:/etc/firegate# ip route ls table wan2 default via 82.236.230.254 dev eth3 src 82.236.230.217 prohibit default metric 1 Fw-cgarp:/etc/firegate# ip route ls table away default nexthop via 82.236.230.254 dev eth3 weight 1 nexthop via 213.223.96.122 dev eth0 weight 1 Fw-cgarp:/etc/firegate# iptables-save -t mangle # Generated by iptables-save v1.2.11 on Wed Apr 6 11:57:06 2005 *mangle :PREROUTING ACCEPT [3281:1066576] :INPUT ACCEPT [411:32992] :FORWARD ACCEPT [2870:1033584] :OUTPUT ACCEPT [339:63745] :POSTROUTING ACCEPT [3195:1096657] -A PREROUTING -p tcp -m tcp --dport 25 -j MARK --set-mark 0xa -A PREROUTING -p tcp -m mport --dports 80,443,21 -j MARK --set-mark 0x14 COMMIT # Completed on Wed Apr 6 11:57:06 2005 So with this configuration all the http,https and ftp traffic must be routed by the 'wan2' connection. I have done severals tests and it dont work, i have also had a realms mark to my routing rule and with the "rtacct" command i saw that traffic going through the correct rule, but http traffic continues to be balanced between the two connections... If someone see the problem ? Thx in advance. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] bridge with packetrate limiter and absolute priority?
Hi. I am trying to bend my brain around 'tc' and friends and am failing so far. I need to set up a bridge which limits the packet rate to 2000 packets/s, but with the added twist that packets with a certain DSCP value must be given absolute priority in both directions. The packet rate limit thing appears to be easy: brcfg addbr br0 brcfg addif br0 eth0 brcfg addif br0 eth1 ifconfig eth0 promisc up ifconfig eth1 promisc up ifconfig br0 192.168.10.1 promisc up ebtables -P FORWARD DROP ebtables -A FORWARD --logical-out br0 --limit 2000/s -j ACCEPT I think this bit works. (A bit difficult to measure. iptraf only reveals packetrates for physical ethernet interfaces. Are there better alternatives to monitor the packetrate on a live interface?) But I need to make sure the packets are prioritized before they enter the bridge device. I was hoping the ingress qdisc could help me here. Something like this: tc qdisc add dev eth0 handle : ingress tc filter add dev eth0 parent : protocol ip prio 1 u32 match ip tos 0xC0 0xff tc filter add dev eth0 parent : protocol ip prio 2 u32 match ip dst 0/0 tc qdisc add dev eth1 handle : ingress tc filter add dev eth1 parent : protocol ip prio 1 u32 match ip tos 0xC0 0xff tc filter add dev eth1 parent : protocol ip prio 2 u32 match ip dst 0/0 I would not be terribly surprised if the lines above make somebody cry. Or laugh. Or both. The idea was to prioritize packets with the "right" DSCP value over all other packets, causing the "other" packets to be dropped first. This does not appear to work. Is what I am trying to do at all doable with the current tools? And by the way: 'man tc' refers to the 'tc-filter' man-page, which I cannot find Regards, Dag B ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ppp+vpn+htb
Hi hiphin, You can also look into ESFQ. Corey Hickey releases esfq for 2.6.12-rc1. On Wed, 06 Apr 2005 16:42:35 +0800, Wang Jian <[EMAIL PROTECTED]> wrote: > Hi hiphin, > > It seems that your network link is eth0. Then > > tc qdisc add dev eth0 root handle 1: htb default 10 > tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 32kbit ceil > 256kbit prio 1 > > Then you can use tc filter to classify all pptp traffic to 1:2. You > don't need to specify different class for every ppp connection. > > But the drawback is no fairness. Not all ppp connections can get 32kbit > assured if they want. > > If you need guaranteed bandwidth for each ppp connection, try my per > flow control queue patch. You can find it in list's archive. > > On Wed, 6 Apr 2005 10:08:40 +0200, "hiphin" <[EMAIL PROTECTED]> wrote: > > > Hi Wang,... > > > > >Because ppp traffic is over your real network link, you can control ppp > > >traffic over that physic device. But I think it have limitation, because > > >with this way you can't look into the ppp layer and differential > > >TCP/IP applications encapsulated in ppp layer > > > > yes, that is my question, if I control eth0 only, I can not have per user > > limmiting... > > > > can I do something simple like this: > > > > /sbin/tc qdisc add dev eth0 root handle 1: htb default 10 > > /sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit > > > > /sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 32kbit ceil \ > >256kbit prio 1 burst 64kbit cburst 96kbit > > /sbin/tc filter add dev ppp0 protocol ip parent 1:0 prio 1 u32 match ip > > dest > > \ > >$REMOTEIP0 folow 1:10 > > > > /sbin/tc class add dev ppp1 parent 1:1 classid 1:20 htb rate 32kbit ceil \ > >256kbit prio 1 burst 64kbit cburst 96kbit > > /sbin/tc filter add dev ppp1 protocol ip parent 1:0 prio 1 u32 match ip > > dest > > \ > >$REMOTEIP1 folow 1:20 > > > > ... > > > > or IMQ must be involved... > > there must be way, to do bandwidth sharing throught vpn-ppp connections > > > > thanks > > > > > > > > -- > lark > > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- lark ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ppp+vpn+htb
Hi hiphin, It seems that your network link is eth0. Then tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 32kbit ceil 256kbit prio 1 Then you can use tc filter to classify all pptp traffic to 1:2. You don't need to specify different class for every ppp connection. But the drawback is no fairness. Not all ppp connections can get 32kbit assured if they want. If you need guaranteed bandwidth for each ppp connection, try my per flow control queue patch. You can find it in list's archive. On Wed, 6 Apr 2005 10:08:40 +0200, "hiphin" <[EMAIL PROTECTED]> wrote: > Hi Wang,... > > >Because ppp traffic is over your real network link, you can control ppp > >traffic over that physic device. But I think it have limitation, because > >with this way you can't look into the ppp layer and differential > >TCP/IP applications encapsulated in ppp layer > > yes, that is my question, if I control eth0 only, I can not have per user > limmiting... > > can I do something simple like this: > > /sbin/tc qdisc add dev eth0 root handle 1: htb default 10 > /sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit > > /sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 32kbit ceil \ >256kbit prio 1 burst 64kbit cburst 96kbit > /sbin/tc filter add dev ppp0 protocol ip parent 1:0 prio 1 u32 match ip dest > \ >$REMOTEIP0 folow 1:10 > > /sbin/tc class add dev ppp1 parent 1:1 classid 1:20 htb rate 32kbit ceil \ >256kbit prio 1 burst 64kbit cburst 96kbit > /sbin/tc filter add dev ppp1 protocol ip parent 1:0 prio 1 u32 match ip dest > \ >$REMOTEIP1 folow 1:20 > > ... > > or IMQ must be involved... > there must be way, to do bandwidth sharing throught vpn-ppp connections > > thanks > > -- lark ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] [ANNOUNCE] ESFQ for Linux 2.6.12-rc1
Corey Hickey wrote: http://fatooh.org/esfq-2.6/ http://fatooh.org/esfq-2.6/esfq-2.6.12-rc1.tar.gz This version no longer interferes with the original SFQ; unlike previous versions, you can still use an unpatched tc with SFQ. Patching tc is still needed for ESFQ, though. I've tested this patch with Linux 2.6.11 as well. Please tell me if you have any problems. I'm subscribed to lartc again. Thanks Corey - maybe this version will get in kernel one day. I haven't tried it yet but will soon. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ppp+vpn+htb
Hi Wang,...>Because ppp traffic is over your real network link, you can control ppp>traffic over that physic device. But I think it have limitation, because>with this way you can't look into the ppp layer and differential>TCP/IP applications encapsulated in ppp layeryes, that is my question, if I control eth0 only, I can not have per user limmiting...can I do something simple like this:/sbin/tc qdisc add dev eth0 root handle 1: htb default 10/sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit/sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 32kbit ceil \ 256kbit prio 1 burst 64kbit cburst 96kbit/sbin/tc filter add dev ppp0 protocol ip parent 1:0 prio 1 u32 match ip dest \ $REMOTEIP0 folow 1:10/sbin/tc class add dev ppp1 parent 1:1 classid 1:20 htb rate 32kbit ceil \ 256kbit prio 1 burst 64kbit cburst 96kbit/sbin/tc filter add dev ppp1 protocol ip parent 1:0 prio 1 u32 match ip dest \ $REMOTEIP1 folow 1:20...or IMQ must be involved... there must be way, to do bandwidth sharing throught vpn-ppp connectionsthanks ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
