[LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL

On Fri, 2006-07-07 at 10:00 +0200, Patrick McHardy wrote: Russell Stuart wrote: Unfortunately you do things in the wrong order for ATM. See: http://mailman.ds9a.nl/pipermail/lartc/2006q1/018314.html for an overview of the problem, and then the attached email for a detailed description of

[LARTC] Can i attach another qdisc under classes or root qdisc?

thank you so much for your reply, but i doubt about "If I understand your question correctly, the answer is "yes". It ispossible to have nested qdiscs. Note that you can nest qdiscs ifyou are using a classful qdisc [0]. See also my list at the bottomof this message." you mean we can define

[LARTC] simple TOS based setup vs more complex ones

Hi, After reading section 9 of LARTC it seemed to me that a pure TOS based QoS setup with be sufficient for a small newtork. Interactive packets could have the highest priority, second highest for DNS and small HTTP packets and lowest prio for all others. The advantage is that, the setup

[LARTC] learning iptables

Hi I am currently learning iptables and would like to see the output of shorewall rules in iptables format, as I would like to make a script for the rules instead of using shorewall. Kind Regards William ___ LARTC mailing list

Re: [LARTC] learning iptables

Hello, William, You can take a look at the man page of iptables-save. On Mon, 10 Jul 2006 11:41:53 - William Bohannan [EMAIL PROTECTED] wrote: Hi I am currently learning iptables and would like to see the output of shorewall rules in iptables format, as I would like to make a script

Re: [LARTC] simple TOS based setup vs more complex ones

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gustavo, : After reading section 9 of LARTC it seemed to me that a pure TOS : based QoS setup with be sufficient for a small newtork. : Interactive packets could have the highest priority, second : highest for DNS and small HTTP packets

Re: [LARTC] simple TOS based setup vs more complex ones

Hi Martin, On Mon, Jul 10, 2006 at 03:45:49PM -0500, Martin A. Brown wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gustavo, : After reading section 9 of LARTC it seemed to me that a pure TOS : based QoS setup with be sufficient for a small newtork. : Interactive

Re: [LARTC] simple TOS based setup vs more complex ones

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gustavo, : Sure, but I am talking about a simple setup that works for small : networks. In such cases there won't be DNS floods, unless someone : really wants to generate one. Well, perhaps you could give it a try in your example network and

Re: [LARTC] simple TOS based setup vs more complex ones

Hello again Martin, More comments below: : So the priorities are useless in real world with pfifo_fast, is : that it? This is bit surprising, IIUC. This is why I asked. Priorities are useless in the real world on a link that we expect to be congested (e.g. an ADSL link). If the link

Re: VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, : So, instead of trying to use a prio qdisc alone, try using a : single HTB class to limit your traffic to a given rate and then : embed your prio qdisc inside that. There are many other possible : options for nested qdiscs, and

Re: [LARTC] simple TOS based setup vs more complex ones

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's a tennis-game on the LARTC list, Gustavo! :) : The question is not : whether priorities are useless, but rather, how often do you expect : your link to be congested? : : Good point... and the answer is: allways. : : With the low

[LARTC] A multi-isp with priority routing and GRE tunneling network problem.

Hey guys, i have a problem with building a multi-isp gateway using a GNU/Linux box with priority routing enalbed and after all. any ideas what should i do? maybe a step by step intro? thanks in advanced. Deslay ___ LARTC mailing list

[LARTC] re-routing network traffic.

Hello All, The following is what I was trying to do: A packet [Dest: 10.10.10.2, Src: 10.10.10.30] has a route through tunl0. The bigger problem is that tunl0 is a tunnel between 10.10.10.2 and 10.10.10.20... Which means that after encapsulation takes place, the packet would look like