Lartc readers
I have a peculiar problem with shaping and firewalling.
My tc rules work great, below is a smaller version:
#Root
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 100
#Root Class
tc class add dev eth0 parent 1: classid 1:1 htb rate 1024kbit quantum
Kenneth Kalmer wrote:
Lartc readers
I have a peculiar problem with shaping and firewalling.
My tc rules work great, below is a smaller version:
#Root
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 100
#Root Class
tc class add dev eth0 parent 1: classid 1:1 htb rate
If nano-howto doesn't work, you should consult my different approach:
http://selab.edu.ms/twiki/bin/view/Networking/MultihomedLinuxNetworking
the tutorial comes with a completed daemon so you have a handy solution
http://selab.edu.ms/twiki/bin/view/Networking/RoutesKeeperProject
Mailing List
So you have to write a daemon to ping the remote gateway, and if ping
fails, the daemon will remove that nexthop from the multipath route. The
dead gateway detection patch can't help you in this case.
That's why I created this project, download and run it, and everything
solved, it's lack of
Does anyone have any pointers on how other people have implemented tcp
window adjustment to do bandwidth shaping?
Granted the basic idea is to set the window size to be RTT * bandwidth,
but a quick squiz at google turns up mostly papers on how to implement
this at the sender end with a view to
Does anyone have any pointers on how other people have implemented tcp
window adjustment to do bandwidth shaping?
HmmI _heard_ that Packeteer had patents on this and
so nobody else was attempting to do it.
Possibly an incorrect rumor, but it made sense to me.
David Boreham wrote:
Does anyone have any pointers on how other people have implemented tcp
window adjustment to do bandwidth shaping?
HmmI _heard_ that Packeteer had patents on this and
so nobody else was attempting to do it.
Possibly an incorrect rumor, but it made sense to me.
They say
Hi,
when iproute is installed then the default queue that
it is giving to an interface is pfifo_fast. I would
like to ask whether it is possible to disable this
feature and rather have the kernel give by default to
an interface the queue that it would give if iproute
hadn't been installed.
Hi!
In our students' hostel we have 6 DSL lines (dialups to different
providers); we have set up a linux box (currently running 2.6.11-rc2-mm2,
but the problem described hereafter also applies to previous 2.6-series
kernels) with help from
