Re: [LARTC] iproute: add destination route by hostname...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Hever, : How to add a static route to a hostname with iproute2? : : I tried: : ip route add linux.com via 192.168.1.1 : : I got the following reply: : Error: an inet prefix is expected rather than linux.com. : : With route command I do not have problems : route add -host linux.com gw 200.214.148.140 : : As the iproute2 is the standard in the current linus distros, I : would like to know if is possible to use the same resource ... The iproute2 package does not understand names. If you wish to use the iproute2 tools, use the following: ip route add 66.35.250.176 via 192.168.1.1 Some regard iproute's behaviour a misfeature. Some regard route's behaviour a misfeature. - -Martin - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFG4VYHHEoZD1iZ+YcRAjC+AJ9GzND1XDuH+bE4km12sbha/+2oGACeKuAR bn1kVrMaNnpSB7+vmxsdWyk= =TNHN -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Prioritizing VOIP traffic without sacrificing throughput
Hi, I would like to prioritize VOIP traffic when we use the phone, but other times not do traffic shaping at all. Right now I have my openwrt router set up with htb to do shaping. In order to get it to work well I had to set my upload and download speeds much lower than my line speed. With these settings, I get good VOIP reception even while surfing the net and doing a long download. However, even when I'm not using the phone, a long download is more than twice as slow than it is with shaping turned off. Is there some way to configure it to only do shaping when it detects VOIP packets, and otherwise not limit traffic? Thanks, Stefanie ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc filter syntax (and general noobness)
Vadtec wrote: ... protocol 6 match u32 0xff534d42 0x at nexthdr+23 flowid 2:50 ... Using nexthdr+ in as simple way as above won't work. U32 won't automatically adjust for the proper offset, you have to do it manually with another u32 filter, using link option. It's very well explained in http://ace-host.stuart.id.au/russell/files/tc/doc/cls_u32.txt As a side note - don't forget that you can simply mark the traffic in iptables and then use fwmark instead of u32 (or with u32 match mark). Other bits of not so easily to find documentation re. tc, in case you need it later in other cases: 1) In source tarball, check doc subdirectory for info about extended action syntax 2) a bit of info about basic classifiers: http://marc.info/?l=lartcm=117569441229800w=2 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] tc filter syntax (and general noobness)
Ok, After much research and e-mails to the list, I'm finally to the point where I have filtering setup properly. Now, I'm trying to figure out tc filter so that I can classify packets on both eth0 and eth1. So, lets take for example Samba traffic. I want to be sure that its being sent with relative speed so that my shares don't get lagged. And what the heck, its as good a place as any to start. While I understand how to get the protocol number out of the header, I am having difficulty getting the rest of the field. Mostly, it has to do with offsets and which uX to use. So, going off of what I think is correct, I have come up with this: tc filter add dev eth1 parent 2: protocol ip prio 10 u32 match ip protocol 6 match u32 0xff534d42 0x at nexthdr+23 flowid 2:50 I seriously doubt this is the proper way to match a Samba header. So my question is this. How do I identify where the offset is for a given header? I assume that (going off the LARTC How To) I can look at output from wireshark and simply count to the field I am after. (This is how I figured out that tc filter add dev ppp14 parent 1:0 prio 10 u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthdr+13 flowid X:Y uses next header+13 to go from the protocol field to the ACK bit for the flags.) The thing is. When I run this rule, none of the Samba traffic is being routed to 2:50... so obviously I'm not going something right. Thanks for your help, Vadtec ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB does not respect the prio parameter
Is quantum not perhaps a bit high? Try setting it lower, and see what happens? -justin On 2007-08-29 08:06, Martin Björnsson wrote: Hi all, I'm experimenting with HTB and the prio parameter and it does not give me results I expect. I've created 4 HTB classes: 1:10 TCP ACKs (prio 0) 1:20 TCP traffic on dst port 10001 (prio 1) 1:30 TCP traffic on dst port 1 (prio 2) 1:40 Default(prio 3) ceil and rate parameters are the same for all 4 classes (rate is 1000kbit and ceil is 55000kbit). Then I start 2 TCP flows on src/dst ports 1 and 10001. The packets seem to be correctly classified by the filter (I get hits on classes 10, 20 and 30). The problem is that I get the same throughput on both TCP flows. Shouldn't I get about 1000kbit through class 30 and much more through class 20 since it has higher priority? Here's my setup script: #!/bin/sh /bin/tc qdisc add dev eth0 root handle 1: htb default 40 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] About b meaning byte and bit
Hi Andy :) * Andy Furniss [EMAIL PROTECTED] dixit: DervishD wrote: Yes, I already knew that, what I was asking is why SI units are not used and shortcuts are used instead: see my original message, I was not sure if kilobit was being used correctly (meaning 1000 bits) or if it was being used mistakenly for kibibit (1024 bits), and on top of that, why b was being used as byte when the SI prefix for byte is B. It got changed so kbit means 1000 when S.Hemminger took over maintenance IIRC. Ok, thanks :)) I mean, tc doesn't seem to follow any standard except maybe in kilobit (which should be then used as kb, not kbit). I think changing kb and kbit would break too many existing scripts. That's the problem with scripts that insist blindly on parsing command output, specially with commands whose output may (and should) change regularly when improvements are made. I supposed this was the reason. Does tc have another interface, preferably in sys or proc or the only way of getting the information is asking the kernel directly (through tc, for example). Thanks a lot for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
