Re: [LARTC] Shaping of pppoe clients
Kenneth Kalmer wrote: The keyword here is better, and that was my argument for using a bridge in the first place. It would appear to be easier to shape filter away from the messy scripts of pppd radius servers, but this raises the next issue. For the bridge, is the pppoe sessions identifiable using say source destination ips, as opposed to pppoe traffic... I know if I perform a tcpdump on the interface that I connect to my adsl modem I only see the traffic as pppoe... Logic tells me that the bridge would suffer the same consequenses... Yes, that was my concern too. Maybe someone else on the list that has already went trought this may share the experience. I will test it as soon as I get my hands on a spare machine ;-) -- regards, Georgi Alexandrov key server - http://pgp.mit.edu/ :: key id - 0x37B4B3EE key fingerprint - E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] leaky bucket on bursty multicast
Thanks for replying :) I have been playing a bit with the following setup, but unfortunately I amconfused about how to specify the queue length of my multicast class below, to absorb the small bursts seen. It would be great with an example, for example with a megabyte buffer. # QDISCtc qdisc replace dev eth3 root handle 1: htb default 30 # CLASSES # root classtc class replace dev eth3 parent 1: classid 1:1 htb rate 5mbit ceil 5mbit burst 50Kb cburst 100Kb# multicast classtc class replace dev eth3 parent 1:1 classid 1:15 htb rate 5mbit ceil 5mbit burst 50Kb cburst 100Kb # other traffictc class replace dev eth3 parent 1:1 classid 1:30 htb rate 1mbitceil 5mbit #filters here (not shown) Thanks, Oivind On 4/8/06, Andy Furniss [EMAIL PROTECTED] wrote: Oivind wrote: On 3/1/06, Andy Furniss [EMAIL PROTECTED] wrote:Oivind wrote:Hi all,I have an average 2mbit multicast stream that once in a while burstshigh (up to 20mbit/s) in short periods (about 200ms). Could anyone please help me with directions using tc for configuing leaky bucketshaping to this stream? I have a 5mbit/s ceiling.My system is running gentoo linux 2.6.14, and I have compiled in all QoS modules.I suppose it depends what you want to do with the burst ie. propogate it,smooth it without loss or drop packets to maintaina rate. I would like to smooth the bursts out at the ceiling bandwidth without any packet drops (unless an unacceptable lengthy burst of course).Sorry for not replying earlier, I lost this one.What you want should be OK with htb/tbf/hfsc ratelimiting at 5meg - justchoose a leaf queue/buffer length that can absorb the burst. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] poor performance for building route cache
I did a test shown as following diagram. (The DUTis running Linux with NAPI ethernet driver.) I add 1000 routes into DUT then use the Smartbits port1 to send packets (with destinations to all the 1000 networks)to the DUT then receive them back from the port 2. The packets are sending in a rate that is much lower than half of throughput of the DUT. The DUT will lose some packets if the DUT has empty route cache before the packets are sent. Once the DUT buildsthe route cache, the DUT can properly forward all packets to the other port without any loose. Iguess that the issueis caused by heavy loading for building route cache. I just doubt that the system can have suchpoor performance for building route cache. Does anybody have any comment? Thank you. Smartbits port 1 --- DUT Smartbits port2 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] how to debug RTNETLINK invalid argument?
George Nychis wrote:
Luciano Ruete wrote:
El Tuesday 23 May 2006 13:17, George Nychis escribió:
Hey,
I am getting an invalid argument trying to insert a qdisc:
[EMAIL PROTECTED] iproute2]# tc qdisc add dev eth0 root xcp capacity 50Mbit
limit 500
RTNETLINK answers: Invalid argument
I'm not sure whats wrong here, because i can successfully insert this
qdisc on other computers of mine.
How can i debug this?
maybe strace (system calls and signals trace) can give you some clues.
strace tc qdisc add dev eth0 root xcp capacity 50Mbit limit 500
Heres what I get as the output:
execve(/sbin/tc, [tc, qdisc, add, dev, eth0, root, xcp,
capacity, 50Mbit, limit, 500], [/* 22 vars */]) = 0
uname({sys=Linux, node=emu-5, ...}) = 0
set_tid_address(0) = -1 ENOSYS (Function not
implemented)
brk(0) = 0x80705cc
brk(0x8071000) = 0x8071000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=63789, ...}) = 0
old_mmap(NULL, 63789, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000
close(3)= 0
open(/lib/libresolv.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\223...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=81316, ...}) = 0
old_mmap(0x4e2d7000, 80040, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4e2d7000
mprotect(0x4e2e6000, 18600, PROT_NONE) = 0
old_mmap(0x4e2e7000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x4e2e7000
old_mmap(0x4e2e9000, 6312, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4e2e9000
close(3)= 0
open(/lib/i686/libm.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\263G...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=215248, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x4001
old_mmap(0x44478000, 139424, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x44478000
old_mmap(0x44499000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x44499000
close(3)= 0
open(/lib/libdl.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\333...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=16908, ...}) = 0
old_mmap(0x473fd000, 12388, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x473fd000
old_mmap(0x473ff000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x473ff000
close(3)= 0
open(/lib/i686/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p36D4\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1499368, ...}) = 0
old_mmap(0x4434e000, 1211684, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4434e000
mprotect(0x4446f000, 27940, PROT_NONE) = 0
old_mmap(0x4447, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x121000) = 0x4447
old_mmap(0x44474000, 7460, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x44474000
close(3)= 0
mprotect(0x4447, 8192, PROT_READ) = 0
mprotect(0x473ff000, 4096, PROT_READ) = 0
mprotect(0x44499000, 4096, PROT_READ) = 0
mprotect(0x4e2e7000, 4096, PROT_READ) = 0
mprotect(0xb8b000, 4096, PROT_READ) = 0
munmap(0x4000, 63789) = 0
brk(0) = 0x8071000
brk(0x8092000) = 0x8092000
open(/proc/net/psched, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x4000
read(3, 000c8000 000f4240 000f4240 0..., 4096) = 36
close(3)= 0
munmap(0x4000, 4096)= 0
socket(PF_NETLINK, SOCK_RAW, 0) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=5407, groups=}, [12]) = 0
time(NULL) = 1148447549
open(/usr/lib/tc/q_xcp.so, O_RDONLY) = 4
read(4, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\270\5\0...,
512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=4192, ...}) = 0
old_mmap(NULL, 6908, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x4000
old_mmap(0x40001000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0) = 0x40001000
close(4)= 0
sendto(3, \24\0\0\0\22\0\1\3\353sD\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
Re: [LARTC] how to debug RTNETLINK invalid argument?
Well it turns out that the problem may very well be the environment, it seems as though i'm getting a hint in dmesg: [EMAIL PROTECTED] net]# dmesg request_module[sch_xcp]: fork failed, errno 1 that occurs after trying to add the qdisc through tc so it seems to be failing because a fork is failing in the module, which I am guessing is an environment problem. Anyone suggestions? I'll keep trying! - George ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] How to limit bandwidth in iptables -- HELP
Greetings Vikram, : Can anybody help me out, how to manage or limit bandwidth through : iptables while having internet connection on eth0 and working as : a gateway in LAN. Just recently, somebody identified several of the most common resources used to understand the traffic control mechanisms available in the Linux kernel. These mechanisms are quite complex and he was lamenting the distributed nature of these documents. Much is available, however online. Try the following: [0] Jason Boxman's article on Linux QoS [1] my own article on the entire system and select parts [2] Leonardo Balliache's view into the underbelly of the beast [3] the venerable Linux Advanced Routing and Traffic Control HOWTO To provide you a bit of context before you get started, iptables can only help you with traffic control. The traffic control system can function in concert with iptables, but is a completely separate system. Best of luck, -Martin [0] http://edseek.com/~jasonb/articles/traffic_shaping/ [1] http://linux-ip.net/articles/Traffic-Control-HOWTO/ [2] http://www.opalsoft.net/qos/ [3] http://lartc.org/ -- Martin A. Brown http://linux-ip.net/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] How to limit bandwidth in iptables -- HELP
Thanx a lot Martin :) Martin A. Brown wrote: Greetings Vikram, : Can anybody help me out, how to manage or limit bandwidth through : iptables while having internet connection on eth0 and working as : a gateway in LAN. Just recently, somebody identified several of the most common resources used to understand the traffic control mechanisms available in the Linux kernel. These mechanisms are quite complex and he was lamenting the distributed nature of these documents. Much is available, however online. Try the following: [0] Jason Boxman's article on Linux QoS [1] my own article on the entire system and select parts [2] Leonardo Balliache's view into the underbelly of the beast [3] the venerable Linux Advanced Routing and Traffic Control HOWTO To provide you a bit of context before you get started, iptables can only help you with traffic control. The traffic control system can function in concert with iptables, but is a completely separate system. Best of luck, -Martin [0] http://edseek.com/~jasonb/articles/traffic_shaping/ [1] http://linux-ip.net/articles/Traffic-Control-HOWTO/ [2] http://www.opalsoft.net/qos/ [3] http://lartc.org/ smime.p7s Description: S/MIME Cryptographic Signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
