Re: [LARTC] tc qdisc for interface alias
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Deepak, : Can we create TC rules for an interface alias? Sadly, no, it is not possible. : /sbin/ifconfig eth0 add ip.ad.dr.ss netmask m.a.s.k up : : tc qdisc show dev eth0:0 The traffic control structures apply (more or less) to link layer devices, since you are changing the queueing mechanism(s) for packets/frames just before they get dequeued to the hardware, so the only devices available to you (for traffic control) are the devices which show up when you type: ip link show It may be instructive for you to also try typing: ip address show This will provide you a more accurate presentation of the separation of link layer (L2) devices and network layer (L3) interfaces and addresses. You will then see what a sham ifconfig's aliases are. : Last command throws error can't find device. Is there any way : to define tc rules on alias or is it simply a limitation? So, basically, if you wish to apply some sort of traffic control to a secondary (aliased) address, then you'll need to include the IP in your tc filter rules. Best of luck! - -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/) iD8DBQFHA7jjHEoZD1iZ+YcRAotYAKCr0VObLEXOx947Gzm0UDNRl4QH3wCglaXu ejgXnsPAPIfbichEHm9TjFQ= =cKox -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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
Re: [LARTC] Question about how TC enforces bandwidth limiting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings again Vadtec, : After another two days of trying to get this to work like I think : it should, I've still hit a brick wall. This can be frustrating, I know. [ snip ] (I admit, I didn't look at the rules very closely, but fundamentally the rules themselves look good.) You do use an ingress filter with a policer. Since the policer applies equally to all inbound traffic flows, it doesn't really do you any good here. : Regardless of the values I use for any of the rates, I still have : the same problem. I do not classify ANY traffic with iptables for : this set of tc filters, so any traffic that is generated is : solely shaped by tc in this case. : : The problem I have is this, whenever I allow any torrent client : to use above 20k of outgoing bandwidth, *everything* becomes : laggy for some reason. Most notable is SSH. While I have no : accurate way to time the lag, as near as I can tell it lags about : 2 seconds. When I press a key on my keyboard it takes ~2 seconds : to show up in the SSH client. Or, if I enter lets say ls and : press enter, it takes roughly 2 seconds for the ls output to : reach me, and while its being displayed, its choppy appearing (as : in it comes in chunks rather than a nice stream). : : I see absolutely no reason for this to be happening. Why should : anything lag when I'm using more outgoing bandwidth? Why would : more outgoing bandwidth cause a slow down on incoming bandwidth. : Or, why would more outgoing bandwidth slow down the filters/tc? : I've verified that this happens on more than just my modem. I've : used two different routers and a cable modem. All suffer from the : same symptoms. You are neglecting one important consideration, and that is the download traffic. You may well be shaping the upstream traffic, but the queues transmitting downstream are also full. So, once again--I'd suggest that you consider what it takes for your ls keystrokes and then the output to make it back to you. * you press a key (l), your ssh client transmits a packet * this packet goes across your congested link (probably significantly delayed, because there's congestion here) * the packet arrives on the ultimate destination * the sshd on the remote side receives the packet, passes it to the application layer (blah blah, bash, fork, exec, ls) * the sshd receives data from the application layer and transmits a packet * your traffic control structures take this inbound ssh packet and give it its dedicated slot (however you have built your queues) * packet returns quickly to your system So, your shaping is great, but you aren't shaping all of the paths through which your application flow must pass. : For the record, my router PC is built as such: : CentOS 5 64bit : AMD Sempron 2800+ (64bit, 1.6Ghz) : 2GB of DDR : 2GB of swap : : As you can see, this PC is more than capable of acting as my router. And then some. Very reasonable looking box. Good luck, - -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/) iD8DBQFG32pfHEoZD1iZ+YcRAp8DAKDDb7eO6/cNZp+lLg8tyO07QffzuQCfcTA3 DnHkDHC/Ea09qNsuEBhi+vs= =VBjg -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Question about how TC enforces bandwidth limiting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Good morning,
: By classifier I think you mean:
: iptables -t mangle -A POSTROUTING -o ${IFext} -p tcp --dport 1:1 -j
: CLASSIFY --set-class 1:100
Exactly.
: And having looked at that, I see part of my problem. --dport should be
: --sport as I have no way to control what port
: the other client wishes to use, but I do have control over what ports I use
: to send my data stream.
Yes. We think about services (at TCP) as being on a standard port,
but iptables operates at L3 (even though it can examine higher
layers). So, if the packet in question is a return packet from an
HTTP server to a client, then as far as iptables is concerned, the
source port is tcp/80.
: I ran tc filter on the command line, but received no output in
: return. I read the man page and it leads me to believe that it's
: not meant for viewing the filters.
Depends, but yes, the tc filter output is not necessarily
attractive. You can classify with tc filter instead of iptables,
but if you reach your goal, it doesn't matter which mechanism you
use to classify your packets.
: One thing I did notice was, while I did see traffic in class 100
: for the first time, my torrent client still showed outgoing
: bandwidth of more than 20kbit.
Well, a typical torrent client will use a number of connections.
Perhaps some of the connections are classified correctly and some
are not?
: Is this simply a function of the router actually limiting the
: traffic and the torrent client simply not knowing? Or (and I
: assume this is incorrect thinking) should the torrent client
: visibly indicate to me that it can only send at X rate because
: its limited?
I would expect the torrent client to be reporting the actual
speed(s), so I would expect it to be reporting 20kbit rates.
: To make this much simpler, I will paste my tc rules and iptables
: rules (which classify my traffic) at the bottom of this e-mail. I
: hope you can find something (related specifically to bit torrent)
: that will allow me to limit torrent traffic without the need to
: limit each client by hand.
You are getting there.
: So I am at a total loss as to why (outgoing) SSH traffic would
: become so slow, because it has access to more bandwidth than
: torrent (at least in my thinking).
Are you sure that it's outgoing SSH traffic that is slow? Consider
the following scenario:
* your outgoing queues are configured completely correctly
* outgoing ssh IP packet gets into correct queue
* inbound return IP packet from ssh server is delayed inbound
because you are not shaping downstream traffic
So, before you conclude that your shaping isn't working, I think
you'll need to apply some sort of mechanisms also on your internal
interface.
Snipped iptables classification. Nothing looks fishy to me there
(though I haven't used the iptables CLASSIFY target).
: $IFext is of course eth0 (link to the modem), $QUANTUM is 1490
: (due to, if I assume correctly, my MTU being 1492, in the modem),
: $MAX_RATE is 360kbit (360kbps conventional talk)
I wouldn't set quantum unless you need to do so. HTB will calculate
this for you. If you do need to set the quantum, I'd recommend
setting it just a bit larger than the MTU...so 1500 or 1536 in your
pppoe situation.
Good luck,
- -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/)
iD8DBQFG3Vd1HEoZD1iZ+YcRAv0pAKDZ0qtpxyOkGJJQ7H5rWtFi3HlM2gCgrugd
WyARMeCjVI9TD/1CcTTDAsw=
=RKrP
-END PGP SIGNATURE-
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] NAT-aware traffic analysis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, : I have tried using iptraf for my NAT firewall to analyse the IP : traffic. Basically I am faced with this difficulty of related the : source IP to the outgoing interface to the internet, so I am : wondering if anyone has a suggestion for a different ways to do : it, or a suggestion for a better tool. I don't know of a flow analysis tool that records internal and external addresses at the NAT boundary. Without knowing how you separate your traffic outbound, it'd be hard for us to guess what the shortcomings of any of these solutions might be, but here are a few ideas: * Record the state of /proc/net/ip_conntrack and your flow information snapshots at exactly the same time. Use the ip_conntrack state information (programmatically) to yield the answers you want about usage information. * Use a flow analysis tool (e.g., argus) to record the flow information on your internal interface. Since you built the rules for distributing traffic and selecting the path for outbound flows, you should be able to map this same logic onto your recorded flows. In short, I think you may have better luck approaching the problem as a flow-analysis problem than a statistical summarization of traffic on any specific interface. Good luck, - -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/) iD8DBQFG3i65HEoZD1iZ+YcRAkqiAJ4rp7p3Sg+b4i0PYvpXRlHZtrm/ogCfe52L 00fFE3OOeNHP8QIiTRuB9LM= =Egrt -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] 2 ISP connection sharing problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arman, : I have divided my network into 2 parts now that is : 193.168.3.127/25 and 192.168.3.128/25. According to this output, below, you have not divided your /24 into two different networks, and it's really not clear exactly what you are asking. Neither of these show up in your routing table: 192.168.3.0/25 (netmask 255.255.255.128) 192.168.3.128/25 (netmask 255.255.255.128) : Destination Gateway Genmask Flags Metric RefUse : Iface : 192.168.3.0 * 255.255.255.0 U 0 00 eth0 : 203.81.213.0* 255.255.255.0 U 0 00 eth2 : 192.168.1.0 * 255.255.255.0 U 0 00 eth1 : 169.254.0.0 * 255.255.0.0 U 0 00 eth2 : default 203.81.213.10.0.0.0 UG0 00 eth2 : I want to route part1 to ISP1 and Part 2 to ISP2. Without further data (ip rule show, ip route show table $ALT) we cannot know which interface your ISP2 is reachable through. : I have made changes into rules. But I think my Tables T1,T2 are : not used and default table is in use. How can I command to use : tables T1,T2 instead of default table. route command output is There are a number of resources you might wish to examine first. I would recommend first understanding the RPDB lookup mechanism [0] and then following the steps for multiple uplinks in the (venerable) LARTC documentation [1]. You may find it fruitful to simulate the route lookup on a packet by packet basis by learning how to use the ip route get command: # ip route get iif eth4 70.14.115.3 from XX.YY.204.58 70.14.115.3 from XX.YY.204.58 via XX.YY.204.1 dev eth8 src 192.168.4.1 cache src-direct mtu 1500 advmss 1460 metric10 64 iif eth4 # ip route get iif eth3 70.14.115.3 from 192.168.3.117 70.14.115.3 from 192.168.3.117 via XX.YY.204.1 dev eth7 src 192.168.3.1 cache src-direct mtu 1500 advmss 1460 metric10 64 iif eth3 Good luck, - -Martin [0] http://linux-ip.net/html/routing-selection.html http://linux-ip.net/html/routing-selection.html#routing-selection-adv [1] http://lartc.org/howto/lartc.rpdb.multiple-links.html - -- 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/) iD8DBQFG3E3iHEoZD1iZ+YcRApZPAJwNhRk25oxC17Zmgy2sLNtBq7HRoACdGk/P p07vvD2W9yfFK+Ws/wPAjT0= =BAoI -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Question about how TC enforces bandwidth limiting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vadtec, I think you may be making two of the most common problems facing novices working with traffic control, so I hope you don't mind my picking on you! Problem #0 - -- You are applying your shaping on the outbound traffic (presuming that $IFext is your external interface. Unless you also have shaping on your inbound traffic ($IFint?), then you are only applying shaping characteristics to the upload traffic. This brings us back to two fundamental rules of traffic shaping: * For optimal results, your shaping device should be the bottleneck, so that it can act as the traffic flow valve. * You can only shape what you transmit. If your edge device is performing shaping, then it should shape upload traffic by a policy applied to the external interface and it should shape download traffic by policy applied to the internal interface. In short, add a similar set of HTB + SFQ queues to your internal interface, along with the appropriate classifiers and try again. : While I understand how/why TC enforces minimum bandwidth for a : given class, why is it that for class 100 TC is not enforcing the : cap of 20kbps to traffic that it is classified at? Is there : something else I need to do to make TC also enforce arbitrary : maximum limits for a given classification? : : I am on DSL internet with rates 1.5Mbps/384kbps. That 1.5Mbps (conventional networking terminology and units) is written as 1.5Mbit in terms used by tc. Problem #1 - -- I think you may be making an error in your units. This is one of the most frequent problems when people start using tc. Since tc sprang from the primordial soup, the following units are used: bps = bytes per second bit = bits per second The unfortunate problem with this marking for units is that we say many other places in networking that bits per second is bps. This is not true with tc. So, if I look at your rate specifications below, they look off by a factor of 8. Please try altering all instances of kbps to kbit and try your script again. See also these URLs [0] [1] [2]. : I do not make complete use of my pipe just in case of a massive : burst. I know I will probably not burst such a massive burst, but : its better to be safe than sorry. This is wise. : Class 90 is the default. Class 100 is a special class, and what : my question specifically relates to. Class 100 is for bit : torrent. I do not like the other people in my house using very : much bandwidth for torrenting as it has a tendency to slow things : down to greatly. If you place FIFOs in any of your HTB leaf classes, you can vary the depth of the FIFO queue to help control latency, in addition to that class's total throughput. This is a cheap and dirty way to accomplish this task. : The problem I have is this: when I disable a given torrent : clients upload limits, the bandwidth climbs to above the 20kbps : limit I have set for it. When I classify the traffic in iptables, : i put it into class 100, so it shouldn't getting put into the : default class. While you are starting and stopping your torrent client, you should also take a look at the class statistics: watch -n 1 tc -s class show dev $INTERFACE_NAME This will allow you to see which class is being used to carry that traffic. Good luck, - -Martin [0] http://www.docum.org/docum.org/faq/cache/74.html [1] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010826.html [2] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm - -- 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/) iD8DBQFG3FYGHEoZD1iZ+YcRAr3NAKC2Iq1mtkEwd3edzU8mY6CQx/PuKgCggE0F hcIyU0L25TYNwMkXGcjusWw= =ifyk -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Question about how TC enforces bandwidth limiting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings again, : $IFext is eth0, and is my link to my DSL Modem. $IFint would be : eth1, which is my interface to my LAN (though I am not shaping : traffic on it in any way). Yes, exactly. You grasped this below, too. Recall that you can only shape what you transmit? Think about why. If you already have a packet, you can delay the transmission. This is the fundamental behaviour of all non-work conserving queues. To introduce a delay to a packet involves work. : So you are saying I have to not only do traffic shaping, but also : traffic policing on my internal device? Or do I have to do : traffic shaping on both devices and no traffic policing? In other : words, how much traffic shaping/policing do I need to put into : effect, and on which interfaces. Be careful. Shaping and policing are two very different things. I probably could have chosen a word other than policy to make this clear. I'll restate this. If you wish to shape upload traffic, then you must put your traffic control structures on the the device closest to the Internet. If you wish to shape download traffic, then you must put your traffic control structures on the device closest to the internal network(s). ( If you would like to see how you can break this basic rule, see some advanced traffic control structures called imq and ifb [*]. ) : So, what you are saying is, its just a matter of different : naming. In essence, 368kbps (conventional) is the same as 368kbit : (tc), right? Bingo. : I have no idea what that means. How do I vary the depth of the : FIFO to help control latency? OK, in order to vary the exact depth of the fifo to suit your fancy, you'd need to use terminal FIFOs instead of using terminal SFQs: tc qdisc add dev $INTERFACE parent 10:1 handle 100:0 pfifo limit 10 Assuming your HTB tree has a leaf class of 10:1, into which you have classified some of your traffic, you now have a very short queue there. If a burst of traffic involving more than ten packets arrives, the traffic will tail drop. In heavily congested situations, this can be useful, although this still allows for a single dominating UDP flow, so I'd probably prefer the SFQ solution, and maybe I shouldn't have brought up this little trick. : I ran both watch -n 1 tc -s class show dev eth0 and watch -n 1 tc : -s qdisc show eth0. (When I ran class show, i did not have enough : room to see classes 80 and 90. When I ran qdisc show, I was able : to see all the classes.) During my runs of tc in this manner, I : saw zero traffic going to class 100 when running, starting, or : stopping bit torrent. If you expect that the torrential traffic to appear in class 100, and it does not, then you have done something wrong in your classifier. Look there. : Almost all the traffic was going to class 10 and 90 (default) : with the exception of my ICMP and UDP traffic which was going to : class 70 and class 60 which I have set aside for IRC traffic. : Class 100 saw absolutely zero traffic. : : Is this a case where the default class (90) is getting all the : traffic because it can handle it as my LAN has very little : other traffic most of the time to deal with, so there is no : need to throttle it back? If so, how can I force a particular : class to be used regardless of the default, so that I can control : individual apps by them selves? Try looking at your classifiers (tc filter statements) to determine where the problem is. If you can't figure it out, then send the list your classifiers and class structure (tc commands). I'd skip playing with terminal FIFOs at first (if ever). Try working on the following: * switch the units to kbit * fix the classifiers and verify that you are seeing all traffic in the class you want to see the traffic in * turn the torrent client up to insane and watch how your IRC or ssh latency is very low Good luck, - -Martin [*] IMQ, intermediate queuing device http://www.linuximq.net/ IFB, intermediate functional block http://linux-net.osdl.org/index.php/IFB - -- 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/) iD4DBQFG3L5sHEoZD1iZ+YcRAso6AJjnbMjcso8t4+GugFC6eHQOyqJQAJ9kpWbZ sOS369AbZkPQ9rg3rhiawg== =gvDh -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, : 1) when I add custom rules like : #ip rule add from $BOX_B_ETH1 lookup 3 : it does not take effect for at least 1 minute, perhaps 2-3. : : Why is that? It's quite simple. There is a routing cache. Recently used routes are stored here for faster access. If you would like to empty the routing cache, then you must make your changes to the routing tables and then empty the routing cache: ip route flush cache Be very careful not to omit the word cache. You will have a nice little surprise if you forget the word cache. : This is confusing, since it makes one think that the rule does : not work, while in reality it just has not taken effect. If you'd like to view the route cache: ip route show cache Do you want to see a particular entry? ip route show cache 72.14.203.104 - -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/) iD8DBQFF8YC/HEoZD1iZ+YcRAkfFAJ9zYzVRCVMTGE619avs4hZVe+yi2gCgtGRi iCnX/HpQS3PiGIvlaJi7nlo= =S+EQ -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Simple route 2nd look please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, : I want B to route (temporarily) to both the .65 gw and eventually : move to xxx.xxx.xxx.83 being the default gw, but I can't add that : route.. : : I'm missing some obvious, but if someone would take a 2nd look it : would be appreciated. I also have requested to get access to the : switch ,but that's still waiting. This is an L3 problem. After reading your description, I'm guessing that each of your servers has two physical connections to the same L2 (broadcast domain) and you have made modifications to the routing table (at least on Server B) before you tried to solve this problem below. : Server B : ip a s : 1: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 100 :link/ether 00:0b:db:91:84:53 brd ff:ff:ff:ff:ff:ff :inet xxx.xxx.xxx.87/26 brd xxx.xxx.xxx.127 scope global eth0 : 2: eth1: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 100 :link/ether 00:0b:db:91:84:54 brd ff:ff:ff:ff:ff:ff :inet xxx.xxx.xxx.84/32 scope global eth1 : : arping -I eth1 xxx.xxx.xxx.83 : ARPING xxx.xxx.xxx.83 from xxx.xxx.xxx.84 eth1 : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C0] 0.956ms -- Correct interface : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C1] 1.210ms -- Incorrect : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C1] 0.712ms : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C1] 0.711ms I call the above problem ARP flux [0]. It's an extraordinarily common problem when you have multiple connections to the same Ethernet. : ip r s : 127.0.0.0/8 dev lo scope link : default via xxx.xxx.xxx.65 dev eth0 : Unless you are running some weirdo networking startup scripts you have made changes to the routing table or lost routes on this box since you brought up the interface on eth0. Note! The ip address output for eth0 shows that you have an L3 address of 207.135.120.87/26. This means you should have had a network route that looked like this: 207.135.120.64/26 dev eth0 proto kernel scope link src 207.135.120.87 Since this route is missing on Server B, something has removed it. : ip route add default via xxx.xxx.xxx.83 dev eth1 table T1 : RTNETLINK answers: Network is unreachable : eris ~ # route add -net xxx.xxx.xxx.84/31 gw xxx.xxx.xxx.83 : SIOCADDRT: Network is unreachable RTNETLINK is telling you that it has no way to reach 207.135.120.83. You can do two things: * restore the network route, 207.135.120.64/26: ip route add 207.135.120.64/26 dev eth0 src 207.135.120.87 * create a host route to the L3 address you want to use as a next hop: ip route add 207.135.120.83 dev eth0 Good luck! - -Martin [0] http://linux-ip.net/html/ether-arp.html#ether-arp-flux (Sorry for the character encoding mismatch.) - -- 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/) iD8DBQFF8hdAHEoZD1iZ+YcRAnMNAJ4y+0/GKY3sUEx85IshFuKrCQ4mXwCfeQLO YmGSNeQgmGX8LDGqGySG9CA= =hYRK -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec, : I tried implementing DNAT as you indicated: : : iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 : : After that, I can see SYN packets arriving on BOX_B_ETH1, having : the original client's IP. OK, that means DNAT + routing on your BOX_A is working correctly. : Only half of the connection gets established after this: I cannot : see ACK packets from box B anywhere (neither on BOX_B_ETH0, nor : on BOX_A_ETH0). This is where your problem lies now. You need to find out why the SYN (which you said was transmitted to BOX_B_ETH1) is not getting accepted by this IP stack. * reverse path filtering (net.ipv4.conf.*.rp_filter) * packet filtering rules on BOX_B? : I think the reason is that since box A never sends a SYN packet : itself, it never classifies the connection as ESTABLISHED, so all : further traffic gets rejected. It's still a mystery to me what : happens to SYN packets from be in this scenario however. BOX_A will never have a socket in ESTABLISHED state. BOX_A will have a state entry in the /proc/net/ip_conntrack table. Examine /proc/net/ip_conntrack after sending a SYN to BOX_B. : It turns out that I have to supplement DNAT with SNAT for this to work : correctly. : On box A: : iptables -t nat -i eth0 -p tcp -m tcp --dport $SERVER_PORT -j DNAT : --to-destination $BOX_B_ETH1 : iptables -t nat -A POSTROUTING -d $BOX_B_ETH1 -p tcp -m tcp --dport : $SERVER_PORT -j SNAT --to-source $BOX_A_ETH1 If this works, then I think you problem may be reverse path filtering. : in this case, the clients can connect, however the server on B : sees only IP of BOX_A_ETH1, not the original client IPs. [ tproxy recommendation snipped ] - -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/) iD8DBQFF8OURHEoZD1iZ+YcRAoenAJ9XCZyMf4K7TVCTs28bzIGeu3EEewCg07Cw Spk8a+T/th+ESyPN4hSTjYs= =k+5E -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] routing TCP to another box preserving ORIGINAL client IPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Alec, : My TCP clients connect to box A. I need to forward those : connections to a server on box B, such that the original client : IPs are visible to the server on B. : : Each box has two Ethernet ports. One port on each box is : connected to WAN, and they are cross-connected in a LAN via : remaining ports: : : --- --- : WAN -- |eth0 Box A eth1|---LAN---|eth1 Box B eth0| -- WAN : --- --- : : : Is there a way to do this with iproute2 and iptables tools ONLY? : Can you provide an example? Nothing in Google after more than a : week of searching. An additional requirement is to reduce the : load on box A as much as possible (I guess the server on B would : still have to reply to the client via A, not using B's own WAN : interface however..) You need to provide us a bit more information to help you figure out the right way to solve this problem. Why is DNAT not sufficient? Given your description, you should simply be able to: iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 If it were that simple, though, you shouldn't have spent a week looking for the answer. Do you have a TCP service on Box A which is providing services to the client across the WAN? If so, then you are looking for something called transparent proxying in the Linux networking world. You will want to examine the tproxy patches to iptables [0]. If you go with the transparent proxying method, it's helpful to remember: * the client thinks it's connected to Box A * Box A knows its connected to the client * Box A uses client's source address to initiate traffic to Box B * Box B thinks it's connected to client In either case, you are correct about routing. Box B must send its traffic back to Box A to forward back across the LAN. Good luck, - -Martin [0] http://www.balabit.com/products/oss/tproxy/ http://www.balabit.com/downloads/tproxy/linux-2.4/ - -- 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/) iD8DBQFF74/JHEoZD1iZ+YcRAlRaAJ4wf2fIc3oBJnGstjUBdpKWn1wOsQCbB2Ee 5Q7zrssGkA02Pq+298i9tEA= =O3sf -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Multiple uplinks, ssh connections hang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello there, : The 192.168.200.x (lan) network gets to the internet via another : gateway (192.168.200.1). Client machines on the 200.x network : work ok except for ssh connections to machines on the internet : hanging. It asks for a password and hangs. Any ideas? Thanks Yes. Vincent Jaussaud had a very similar problem (though much larger than yours) several years ago [0]. If you run tcpdump on the client and watch for the ToS to change (just after authentication), it should become very clear what is happening. You must remember that the the tuple on which a route is selected includes the ToS. So, after you have tried to connect to the ssh server in the public Internet from the inside (watching with tcpdump, of course), run ip route show cache $DEST_IP and compare the set of results. If that's at all unclear, maybe this will also help [1]. Good luck, - -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2002q4/005653.html [1] http://linux-ip.net/html/routing-selection.html#tb-routing-selection-adv - -- 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/) iD8DBQFF42TLHEoZD1iZ+YcRAlZqAKCrpGmNKdyCUUwExGW2MWLUQqMzzwCgiKY6 czRMryHmcM9HBGdKkFfWUgg= =Pgu8 -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Need big buffer!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Bob, : I've been trying to read up, and still not coming up with : concrete info on queue sizes. Right now, my code for limiting to : 300k is: : : tc qdisc add dev eth0 root handle 1: htb default 21 : tc class add dev eth0 parent 1: classid 1:1 htb rate 300kbit : tc class add dev eth0 parent 1:1 classid 1:20 htb prio 0 rate 100kbit : tc class add dev eth0 parent 1:1 classid 1:21 htb prio 1 rate 100kbit ceil 300k : : ..with some matches for prioritizing other traffic into class : 1:20. : : I assume there is something I need to add to the first line, but : everything I've read about never mentions htb. Here are pointers to HTB documentation that I have written [0], and, of course, the author's own documentation [1]. Stef Coene, who used to be extraordinarily active on this list has some useful (if not currently maintained) documentation at [2]. See also Leonardo Balliache's thorough examination of traffic control under Linux [3]. As I see it, your problem is not that you haven't found the right HTB setting, but rather that you haven't embedded a (b)FIFO in the right place. Try adding a fifo of the appropriate size (in bytes) to the class which is handling your bursty traffic. This FIFO will hold your queued packets while HTB dequeues them at the ceil rate. Trial and error will probably help you determine the optimal depth of the FIFO for your purposes. tc qdisc add dev eth0 parent 1:21 bfifo limit 256000 Best of luck, - -Martin [0] [1] http://luxik.cdi.cz/~devik/qos/htb/ [2] http://www.docum.org/docum.org/ [3] http://www.opalsoft.net/qos/DS-28.htm - -- 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/) iD8DBQFFzJqeHEoZD1iZ+YcRAvFyAJ9ARFRk02h1tY0COJnHvEvHs1HkwgCgpQwF 9AWk9kTyPSGmdxPtFYpFpGg= =Y0gF -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Advanced Policy Routing not working properly
test $STABLE = STABLE=main ip route flush table $DTABLE ip route show table $STABLE | grep -Ev '^default' \ | while read ROUTE ; do ip route add table $DTABLE $ROUTE done } [1] http://linux-ip.net/html/routing-selection.html - -- 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/) iD8DBQFFrOT/HEoZD1iZ+YcRAgwTAJ4qOm6DECDdvmAyk2qQ2FkSWClzAwCgiTiP hZRW7ypLM65/pj+D0JmlMcA= =hZeL -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Linux as T1 router
Greetings, : I am thinking about using a linux server as a T1 router. I have : searched the list, but have not found a discussion about what I'm : trying to do. I have a situation where the Cisco router I'm using : will not handle the additional bandwidth I added recently. : Unfortunately, I cannot afford the Cisco unit that will. I would : like to know if anyone has successfully done this. I have been : looking at the Sangoma T1 cards. Would anyone be so kind as to : share their experience in this area. Any advice would be much : appreciated. I can recommend the Sangoma T1 cards. I have been using the S508 (ISA) and S514 (PCI) models since 1999. These cards and the (open source) drivers and management software are easy to use. The company is responsive and supportive of their product. The Sangoma crew have worked over the years to contribute their drivers into the stock kernel, so it is likely (unless the card you choose is a newly released card) that your card will be supported by your default distribution of choice. The software management tools are provided by a separate package, including tools for configuring the (optional) onboard CSU/DSU and diagnosing the frames received by the unit. Best of all, I can report that I have only ever found one bug in working with their software and drivers, and this was a corner-case bug that they had identified before I reported it to them (several years ago). In short, the software and hardware is very reliable. -Martin -- 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] Curious situation of htb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Y.K. Peng, : But it confuses me that what is the accurate definition of the : argument rate? In order to understand the HTB concept of rate, you must understand buckets. Read about either token buckets (e.g. Linux TBF [0]) or leaky buckets (the generic idea) [1]. : It seems to be the minimum rate which is guaranteed for a class : in the user guide of HTB Home, but in the manpage of lartc.org it : is defined as the maximun rate quaranteed for a class. The difference is merely a matter of perspective. You may think of it as you find most fitting for your understanding. To understand the term in the context of HTB, it helps to understand the entire borrowing model: * HTB will always allow a packet in a leaf class to be dequeued if that class has not yet exceeded its rate. (This leaf class is guaranteed a minimum rate of packet transmission.) * HTB may attempt to transmit a packet from a leaf class if that leaf class is above rate but below ceil. In order to transmit a packet when transmission of that packet will exceed rate, the leaf class will ask its parent class (which may ask its parent class (which may ask ...) ) if it may borrow (properly, use) a token to dequeue the pending packet. If the entire hierarchy of classes has an available token, then that token is counted. * HTB will never attempt to transmit a packet from a leaf class which has exceeded its ceil, an administrative absolute maximum for this leaf class. This borrowing logic holds true for all intermediate and root classes, but packets are only dequeued from leaf HTB classes. : First I setup the qos configuration by tc, and classification is : done by the u32 classifier. In this case, no matter how the : classes' rate set, the total bandwidth of 100Mbps will always be : about 75Mbps and each class is assigned the bandwidth in the : scale. : : To work with some tunnel or random-port transmission, another : program was applied to set the priority value of the structure : sk_buff as the classid the packet belongs to. In this case, the : total bandwidth is limited at the rate we set, so do all the : classes set. : : My question is that, why it differs from the two mechanism? Which : one will be the correct result? Unfortunately, I'm unable to interpret what your experiment was, so will not be able to address this question. I can only guess that you didn't use the default parameter on your HTB qdisc itself: tc qdisc add dev $DEV root handle 1:0 default $DEFAULT_CLASS If you do not specify a default class for otherwise unclassified traffic AND if you do not include a classifier as a catch-all: # -- catch all classifier # tc filter add dev eth0 parent 1:0 protocol ip prio 1 \ u32 match ip src 0.0.0.0/0 then any unclassified traffic will be dequeued as fast as the hardware allows [2]. Good luck, - -Martin [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html#qs-tbf http://lartc.org/howto/lartc.qdisc.classless.html [1] http://linux-ip.net/gl/tcng/node54.html http://en.wikipedia.org/wiki/Leaky_bucket [2] http://www.docum.org/docum.org/docs/htb/ - -- 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/) iD8DBQFFkuinHEoZD1iZ+YcRAlgCAKC8WUFHfSMpj513SrXk6PXvRFtaEACgtDvV EaUDBj5i+vPdBjafnq7idLc= =dg5o -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Andrew McGill, : I want to use the netmask 255.255.255.255 to insulate (not quite : isolate) machines on a shared subnet from each other. This works : just fine on win XP, but Linux iproute will not acccept the : gateway address in one step -- neither on the command line nor : via DHCP: Try using the onlink nexthop flag for your route: # ip route add onlink default via 192.168.1.17 This marks the route for entry even though the local routing table may not have a route to the nexthop destination. In your case, this is a valid parameter, and should prevent the need for you to add the host route only to remove it. : So why did we need that host route? You need the host route to the destination as a simple sanity check. - From the perspective of the kernel, there's no route to 192.168.1.17 if the IP bound to your interface is a /32. When you add the route, the sanity check succeeds. Essentially, you are suppressing this sanity check by using the onlink parameter, which says Yes, I know there's no route to IP 192.168.1.17 out this interface, but I know the IP is there on this link layer anyway, so set the route anyway and stop griping.* Good luck, - -Martin * RTNETLINK answers: Network is unreachable - -- 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/) iD8DBQFFWnH+HEoZD1iZ+YcRAsu2AKDixJF7A0LMClN8snQVq1zk9DV4dQCeIW7R HMtOMud8Kt5yQLskMK7HwDY= =PVyl -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB has 2 bucket?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetinsg Thossapron, : in HTB use 2 bucket for manage 2 rate??? first bucket - keep : token for sending with rate second bucket - keep ctoken for : sending with ceil rate Is it true?? may be i'm misunderstand : about token/bucket thoery Yes, there are two different buckets used. One bucket is for tokens, another bucket is for ctokens. Brief picture of association of parameters: rate: burst, tokens ceil: cburst, ctokens See the upper right corner of this diagram [0]. In particular, I should warn you that the SFQ qdisc in this diagram is the one which is granted the dequeue opportunity, so although packets mostly flow from left to right in this diagram, the SFQ is displayed to the left of the HTB rate/ceil buckets, even though logically this is reversed. Good luck, - -Martin [0] http://linux-ip.net/traffic-control/htb-class.png - -- 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/) iD8DBQFFL4zmHEoZD1iZ+YcRAm1mAJ42tQy4cRL88JnuwR2/YR3zrRoTOACfbLtu ccrh3V/7eBzDlpRvWTgOtZs= =RqAV -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] QoS HTB burst and cburst parameters-FLEX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Jon, : Does anyone know what the burst and cburst parameter do? Consider the burst parameter the bucket used until an HTB class is transmitting at its rate. Consider the cburst parameter the bucket used when an HTB class is transmitting at or above rate, but below ceil. : * I see a lot of different definitions on the web. It seems like : burst is the number of bytes sent before serving other : queues/classes. So if burst was 1000 bytes and class rate was : 100kibit per second. It would send 1000 bytes each time the : scheduler service that queue to a rate of 100 kbit per second? Here's how I would succinctly describe the interrelationships between burst, quantum, cburst and the scheduling algorithm: A given leaf class is transmitting below rate = Each time our leaf class has the opportunity to dequeue packets, it will dequeue as many packets as possible until it reaches burst. A given leaf class is transmitting above rate = Each time our leaf class has the opportunity to dequeue packets, it will dequeue quantum packets and yield its turn to the next class. This prevents a single class from starving its sibling classes for borrowing from the parent. : Also does anyone know how the burst and cburst parameters are : configured by default? This, I cannot answer for you. You may find my longer description of the borrowing model and HTB in general useful [0], and in particular, the diagram may be helpful for visualizing the system, however, for your needs I would recommend that you study the results that Stef Coene posted several years ago on the use of burst and cburst [2]. Best of luck, - -Martin [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb [1] http://linux-ip.net/traffic-control/htb-class.png http://linux-ip.net/traffic-control/htb-class.pdf [2] http://www.docum.org/docum.org/tests/htb/burst/ - -- 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/) iD8DBQFFJFhbHEoZD1iZ+YcRAk0SAJ9ecaU4oxNtEitM1Uwjwor9a8uXEQCfWscM ka5Cf1RKFW6eFb84wbzkJTU= =Jynq -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Can i attach another qdisc under classes or root qdisc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello again Raku, : you mean we can define nested qdisc but algorithm in nested : qdisc must same as parent class i'm not clear it and Is we : can define nested qdisc with algorithm different from parent : class? Next try at explaining the concept: - qdiscs can be attached to egress (default), ingress and any class - classes may only be defined underneath (as children of) existing classful qdiscs (CBQ, HTB, PRIO, HFSC) - a classful qdisc may only have children classes of the same type (e.g., HTB qdisc can only have HTB classes; HFSC qdisc can only have HFSC classes) - classless qdiscs are leaf branches on the tree Be careful to distinguish classes from qdiscs. : tc qdisc add dev eth0 root handle 1: htb : //this left node hierachy for manage general package : tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps : //this right node hierachy for manage real time package : tc class add dev eth0 parent 1: classid 1:2 htb rate 100kbps ceil 100kbps : // from your adivse at step 4, attach brand-new after define class : but Is it true??? because algorithm new qdisc are different from : class algorithm that qdisc attach it. : tc qdisc add dev eth0 parent 1:2 classid 10:11 hfsc rate 100kbps : tc class add dev eth0 parent 10:11 classid 1:111 hfsc rate 100kbps ceil : 100kbps : tc class add dev eth0 parent 10:11 classid 1:112 hfsc rate 100kbps ceil : 100kbps Structurally speaking, there's nothing wrong with your hierarchy. When you try it out, however, you'll discover that you are not using the correct parameters for the hfsc qdisc and class specifications. : and Can somebody advise me about HOW TO do later in this topic. i : want to have got traffic shaper and my solotion is ... i want to : manage different traffic package (general package use and real : time package) so now i think about have got a problem with tc : command, ... i think it can't setting to manage different package : with different algorithm HTB and HFSC Do you have any idea about : how to setting tc command example thank you Raku, I don't know whether HTB or HFSC would be better for your application, but I can tell you that HTB is better-understood by a larger number of people. In the grand scheme of things, HFSC has seen far less use. It's an excellent concept, and if you'd like to know more about the concepts behind the queuing discipline, I'd suggest the HFSC article by Klaus Rechert and Patrick McHardy [0]. I think a simple hierarchy almost exactly like the one detailed in their article is probably what you want. It sounds like you have realtime traffic (e.g., VoIP) and bulk traffic. So, read their documentation, and try to configure your traffic control structures as they suggest. Once you have configured the traffic control structures, then add the filters to separate traffic into the appropriate classes, e.g.: FILTR=tc filter add dev $INTERFACE # -- structure is built, now select some packets # $FILTR parent 1:0protocol all prio 1 \ u32 match ip src 192.168.7.0/24 flowid 1:10 # -- example for grabbing anything at all # $FILTR parent 1:0protocol all prio 1 \ u32 match u32 0x0 0x0 at 0classid 1:11 # -- example for identifying all UDP traffic # $FILTR parent 1:0protocol all prio 1 \ u32 match u8 0x11 0xff at 9 classid 1:12 These are just example filters (and probably not great examples at that). You should write your filters to select the traffic you want to place into each class. Finally, let me recommend that you keep your class structure as simple as possible. - -Martin [0] http://linux-ip.net/tc/hfsc.en/ - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEt7zjHEoZD1iZ+YcRAqBEAKCnuuyDblK9pKvG4Og12HJovGt3HQCcD3LD u0rdSUkjmgmBJtJ/gpIfc0M= =V1fF -END PGP SIGNATURE-___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] how different qdisc at root and leaf working???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raku, : /bin/false qdisc add dev eth1 handle 1: root htb default 1 : /bin/false class add dev eth1 parent 1: classid 1:1 htb rate 2048Kbit : /bin/false class add dev eth1 parent 1:1 classid 1:21 htb rate 128Kbit ceil 512Kbit prio 2 quantum 1532 : /bin/false class add dev eth1 parent 1:21 classid 1:299 htb rate 256Kbit ceil 256Kbit prio 4 quantum 1532 : /bin/false qdisc add dev eth1 handle 299: parent 1:299 hfsc You must have renamed tc to false. :) : use HTB only for shaper bandwidth in each sevice with setting parameter : rate??? : : use HFSC only for manage dequeue traffic after shaper bandwidth from : inner class??? In the above traffic control structure, you have not specified any classes for the HFSC qdisc. That means it's effectively doing nothing (useful). Check out my earlier mail--and good luck, - -Martin P.S., Can you convince your hotmail account not to send HTML mail? - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEt728HEoZD1iZ+YcRAvocAJ9A1rMrv+ubsILi0g5rymI0zO2yWwCfQ3ME KmUumYYQYm01olICddwvCpg= =/BSx -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 and lowest prio for all : others. : : The advantage is that, the setup would be simply a couple of : iptables lines, because the default pfifo_fast qdisc already : implements priorities. In your proposed system, is still possible for a flood of DNS queries to cause queue depths upstream (and queue depths translate directly to queue backups and delays). : For this case, what is the recommended way to limit the outgoing : rate to ensure that nothing is queued on the modem? The answer depends on what you are trying to do. Consider HTB and/or HFSC. Although you might find that TBF is sufficient, you are already talking about ToS, so TBF probably won't cut the mustard in your situation. : Can this be done with pfifo_fast? Not really. Although, the actual qdisc proposed is different, please see this recent exchange [0] about prio qdisc. If you are using a work-conserving qdisc (i.e., a qdisc that performs no shaping), you'll not really be able to guarantee anything about the quality of traffic from one point to another. In order to offer some sort of guarantees on any link, your device must be the bottleneck. This requires shaping or, at least, some sort of non-work-conserving qdisc. Good luck, - -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2006q2/019130.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019143.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019158.html - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEsryFHEoZD1iZ+YcRAmUAAKDb74IxaBWmCgHA8sd1Sy1SVXS4ZACfYkvD 5NhD00yJMOG5CeFTTFPPk+s= =RmHf -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 see how it fares. It might fare very well 90% of the time. If so, then you have an OK solution. : 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 is not congested, there's no problem with using priorities. The question is not whether priorities are useless, but rather, how often do you expect your link to be congested? : What I was initially looking for was just TOS marking + plus : simple interface throtlling, i.e, the simplest form of shapping. : If it can't be done with pfifo_fast, my next idea was something : like: : : tc qdisc add dev eth0 root handle 1: htb default 10 : tc class add dev eth0 parent 1: classid 1:1 htb rate 7000kbps ceil 7000kbps : tc class add dev eth0 parent 1:1 classid 1:10 prio : : + : : iptables rules for setting TOS values : : Is this right? This seems to be similar to what you proposed : here: : : http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html Well, indeed, I did post that! While that may solve the problem of the bottleneck, I have to confess, it's not a very good solution either! I'll post a follow-up to that thread shortly. : For a not so simple approach but which seems to be working well, : I have an adaption of Dan Singletary's script here: : : http://downloads.angulosolido.pt/QoS/ : : It uses directly HTB on both directions, for a setup with only 2 : network interfaces which is very common (no kernel patching is : needed). HTB in both directions is probably the best way to go (shaping upload and shaping download). I haven't examined the HTB_shaper.sh assiduously, but from a quick review, it seems quite reasonable (and better than my off the cuff remark in the earlier thread). I'm not crazy about the dropping of the MTU, but otherwise, the script seems to make sense. Basically divide up link capacity into components and limit the total transmission rate to the link capacity (so we are the bottleneck). Then, put some packets in each class. It's so far the best (and most general) solution in this thread. : Still, I want to test the simplest possible solution and see how : far one can go with only a few lines of bash, for both practical : and pedagogical purposes. I think it's important to have a simple : solution that works for typical scenarios (2 interfaces, linux : router with NAT) on stock kernels. ** : : ** nothing wrong about patching and compiling kernels, but it :brings maintenance overhead everytime there is system upgrade :for whatever reason Understood on the kernel patching/compiling business. That's not usually something you want to throw at beginners. Well, if the goal is practical administration and pedagogy, I'd suggest tcng [0], since the beauty of tc is hidden from the user. The language of tcng feels more like a programming language than the arcana of tc. Good luck, - -Martin [0] http://tcng.sourceforge.net/ - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEswsEHEoZD1iZ+YcRAhwGAJkBlygjpO6dfT9s+1/yHq91pSAJCQCg8E2a LRjKTkGjSvQHTLaFReomSlk= =ikoL -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 maybe somebody on this list will : make a recommendation to you for how s/he solved this problem. This is a correction/clarification for posterity. There is still a problem with the above, and I'd like to correct it and thank Gustavo Homem [0] for pointing out my possibly misleading advice here. Mike indicated that he was willing to let VoIP traffic out regardless of the cost to other flows. This means that the above solution might work acceptably for his needs in this situation... However, this is not a good general solution! When evaluating a traffic control mechanism for a particular solution, there are a number of different network characteristics that we need to keep in mind. The big three are throughput, delay and jitter. Each traffic control mechanism that we might employ affects at least one (and almost always more than one) of the above network characteristics. Selecting the correct mechanism for a given application depends on what we are willing to trade. Some people are willing to trade total throughput for delay (those of us who like responsive ssh sessions, for example). Some people MUST trade delay and jitter for throughput (VoIP applications). So, to return to the problem of a single PRIO qdisc (a work-conserving queuing discipline), how can we add some sort of non-work-conserving mechanism (shaping) and still take advantage of some prioritization. There are a number of ways to solve this problem, but let's look at the following options (+ = good, - = not-so-good): A. HTB qdisc, one class, with child PRIO qdisc + HTB shapes total dequeued traffic rate to the specified maximum rate. + PRIO qdisc ensures that traffic you classify as high priority always has preferential access to full link bandwidth (as limited by HTB's rate) - high priority flows can completely starve low priority flows B. PRIO qdisc, each class contains a TBF qdisc specifying transmisison rate + each class gets up to its TBF of throughput before it gets shaped. + each class gets is completely isolated from the other classes so if the sum of the rates of the TBF qdiscs does not exceed link bandwidth, you should see predictable delay and jitter - any given class could become backlogged easily and there's no sharing between classes C. HTB qdisc, HTB children classes[, children sfq or fifo qdiscs] + HTB shapes total dequeued traffic rate to the specified maximum rate. + HTB children classes can borrow from parent classes, if some bandwidth goes unused - must write filters to specify which class receives which packets The above is just an outline to point out some of the tradeoffs that need to be examined and understood when choosing a traffic control mechanism for any particular situation. I was probably a bit facile in my answer to Mike, so I hope this post clears up the ambiguity of the recommendation. Good luck and happy QoS! - -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2006q3/019232.html - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEsxDdHEoZD1iZ+YcRAormAJsGkouYrqoM0q8Zgw0aCaXpZTMKkQCfbc+E UruTl/GvAVMHqGRqzUwwc0Q= =Sk64 -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 DSL uploads available a single connection will : saturate it - we currently have 20Mbs/400kbps (!) services, for : example. Strange ratio--20 to 1, but I don't know a great deal about DSL provisioning. : Meanwhile, I just finished my first trial on this approach. The : result is here: : : http://downloads.angulosolido.pt/QoS/PRIO_shaper.sh : : For SSH interactive traffic and Web Browsing while uploading and : downloading, seems to work as well as HTB_shaper, it tested on a : single machine. : : Of course there is no fairness on each prio band, so tests with : multiple workstations should reveal the advantadges of : HTB_shaper. Well, good luck with it. You could consider following the lartc.org HOWTO on PRIO qdiscs with embedded SFQs [0]. : I'm not crazy about the dropping of the MTU, but otherwise, : : I found that it was causing problems, so that part is gone. While it's not a bad idea from a traffic control perspective, there are so many ramifications of changing the MTU that I don't find it worthwhile. : (OT: I wonder, if the kernel team doesn't want to include IMQ, : what's their recommended solution for this problem, on a router : with more than 2 interfaces) The developers have recently been working on something called ifb, which is intended to be a replacement for IMQ. I don't know too much about it, but there are snippets of documentation about the 'net if you are on good terms with google. - -Martin [0] http://lartc.org/howto/lartc.qdisc.classful.html#AEN903 - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEsxPRHEoZD1iZ+YcRAsmrAJ9TkcLnQ2TpzJCxHtdk2ACHHN/D+QCfcBof 3aOuyJi5+ZWjlq45ES9xjfE= =CpY+ -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Advanced routing routing table limits and rule design
Good morning LARTC and, specifically, Wayne, : : I am trying to determine how to best increase the number of : : routing tables available in linux 2.6 to more than 255. : : You are in good company. The question seems to come up with some : frequency [0]...I'm beginning to think that it needs to be an : FAQ. Perhaps this will no longer be an FAQ. Since I just answered this question late last week, and my answer is now wrong, I thought I would post a followup message. : Sadly, I haven't heard of anybody yet having done this, although : one of the key developers of the kernel VLAN code (Ben Greear) : has recently requested development on this point [1]. Just today, Patrick McHardy has posted a set of patches [0] [1] which accommodate the desire for more routing tables. Good luck and enjoy! -Martin [0] http://marc.theaimsgroup.com/?t=11519133472r=1w=2 [1] http://marc.theaimsgroup.com/?l=linux-netdevm=115191325909208w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=115191325901440w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=115191326012390w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=115191325901420w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=115191325911007w=2 -- 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] Advanced routing routing table limits and rule design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Wayne, : I am trying to determine how to best increase the number of : routing tables available in linux 2.6 to more than 255. You are in good company. The question seems to come up with some frequency [0]...I'm beginning to think that it needs to be an FAQ. : I realize this involves increasing the storage of some messages : to and from the kernel in addition to kernel changes (from : browsing the code), and was hopeful that someone might know what : the correct solution would be or could point me in the right : direction (like existing patches or a highlevel of what I need to : change in the code). Sadly, I haven't heard of anybody yet having done this, although one of the key developers of the kernel VLAN code (Ben Greear) has recently requested development on this point [1]. : Additionally, I was curious how the ip *rule* system works in : regards to matching -- is it a linear search or optimized in some : way. Basically what I'm asking is if adding rules to a machine : adds time to the whole system passing over various rules that : don't match. While I'm not certain of this, I believe that any route lookup which fails the routing cache (you do know about the routing cache, right) will traverse the rule policy database in a linear fashion. (Sorry, don't know which part of the kernel C to examine.) : This all comes down to a seutp I have that has a lot of routing : tables and at least one or two rules to get into each routing : table. I don't want to increase the number of routing tables if : also increasing the number of rules on the box is going to do : more harm than good. I am not aware of any performance comparisons of typically routing configurations against full RPDBs. It seems like you'd get some benefit from your own sort of least recently used (LRU) sort before inserting rules into the RPDB, though. I hope somebody else out there will comment on: - whether s/he is working on patches which would support up to 2 ** 16 routing tables (as opposed to 2 ** 8). - performance metrics/routing comparison, Linux with one routing table and a given load as against Linux with RPDB + many routing tables Good luck in getting your answer(s), Wayne, - -Martin [0] http://oss.sgi.com/archives/netdev/2005-08/msg00163.html http://mailman.ds9a.nl/pipermail/lartc/2001q2/001073.html http://mailman.ds9a.nl/pipermail/lartc/2004q1/011670.html http://mailman.ds9a.nl/pipermail/lartc/2004q4/014125.html http://mailman.ds9a.nl/pipermail/lartc/2005q4/017094.html [1] http://marc.theaimsgroup.com/?l=linux-netdevm=115029279428349w=4 - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFEpYiSki79Zb8hnmwRAhGpAJ0aLU24s0US28hd+gamGFpnbtRfIgCfRUqY aE+XF2YAIPKHKJykfLCOwNM= =G6vh -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Can i attach another qdisc under classes or root qdisc?
Greetings, : now, i'm learning and try to read a lot of article about tc : command in linux for setting traffic shaper. but i'm doubt about : In the theory about tc command ... In general, we define class : under root qdisc but Is it can be possible If we define : another qdisc under root qdisc, Can i do it? because i have just : read tc command syntax and i found this point ... [ snip mangled tc qdisc help output ] : from above syntax at [handle][root /ingress/ parent CLASSID] : Is parent CLASSID mean we can define qdisc under class so : this is my assumption about that. and Could you advise me about : Is it can do for real If I understand your question correctly, the answer is yes. It is possible to have nested qdiscs. Note that you can nest qdiscs if you are using a classful qdisc [0]. See also my list at the bottom of this message. : //first .. define root qdisc : : tc qdisc add dev eth0 root handle 1: fifo Bzzzt! Sadly, you can't do this. A fifo qdisc is a classless qdisc, meaning that it cannot have any children. (Poor barren thing!) : //second ... define class under root qdisc but algorithm's not same like root qdisc algorithm : : tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps : tc class add dev eth0 parent 1: classid 1:2 hfsc rate 100kbps ceil 100kbps Well, you can't quite mix and match classes without having a parent qdisc of the type you want. An HTB parent qdisc can have any number of children arranged in a tree structure below the parent. Similarly, an HFSC class structure needs to attach to an HFSC qdisc itself. Note, though, you cannot simply change the class name from htb to hfsc and supply the same parameters. HTB uses the rate and ceil parameters, but HFSC uses different parameters (rt, sc and ul). : //later attach qdisc to those classes : : tc qdisc add dev eth0 parent 1:1 classid 10:11 htb rate 100kbps ceil 100kbps : tc qdisc add dev eth0 parent 1:2 classid 10:21 hfsc rate 100kbps ceil 100kbps OK, now, let's pretend that you have a classful qdisc (e.g. HTB) with two classes, 1:1 and 1:2, AND that you have a good reason for adding a nested qdisc to one of these classes. If that were the case, then you could add the qdiscs to the parent classes in the following fashion: # -- create a new qdisc, attached inside an existing class #hierarchy below class 1:1 # $qdisc_add parent 1:1 handle 10:0 htb # # -- add a class to our newly created qdisc, and set the #rate and ceil parameters # $class_add parent 10:0 classid 10:1 htb rate 100kbps ceil 100kbps Note, that you'd still need filters. If I were you, I'd review the documentation for both HTB and HFSC after understanding the entire Linux traffic control model. Here's a crash course, starting at the root qdisc: 1. The qdisc can be - classless (e.g., FIFO, SFQ, ESFQ, TBF, GRED) - classful (e.g., HTB, HFSC, CBQ, PRIO) 2. If the qdisc is classful, keep reading. If the root qdisc is classless, stop here. 3. You may add classes to your classful qdisc. If your qdisc is HTB, you can only add HTB classes. If your qdisc is CBQ, you can only add CBQ classes. If your qdisc is HFSC... 4. Now, you may attach a brand-new classful or classless qdisc to one of your existing classes. Repeat from step 1 for each new qdisc. 5. You may add filters to any of your classes (best starting behaviour is to add them to 1:0) Very complex hierarchies are quite possible, even if not always understandable or advisable. Best of luck, -Martin [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html (N.B., this documentation was written without any reference to HFSC, a newer classful qdisc. You may also use HFSC with child qdiscs.) -- 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] TCNG question
Paul, : I have used tcng to help start me with some tc code that i can : put into a bash script and call from a c program. I have to : dynamically : : 1. Add filters for communications between different nodes. : 2. Delete these filters as communications cease between the : nodes and : 3. Make sure they have enough bandwidth by limiting everything : else. : : e.g Node 1 wants to make a voip call to Node 2. My c program : recieves both ip's, both ports and the bw that the call requires. : I then have to add/change the tc rules/filters to allow this to : happen. Then i recieve a request for another call, same thing. : Then call 1 hangs up, i delete that filter and change other : necessary info. I have seen a number of people try dynamic class and filter insertion. I can't say that I've ever seen it work particularly elegantly. I hope somebody will also show you what s/he has done to deal with this problem, but here's how I'd solve the problem: Build a class hierarchy that accommodates the total number of VoIP calls that your network can support at any one time. class $root, rate $MAX, ceil $MAX | +- classes $voip,rate $VOIPMAX, ceil $VOIPMAX || |+ class $voip.0 rate $PCR, ceil $PCR |+ class $voip.1 rate $PCR, ceil $PCR | [ ... ] |+ class $voip.N rate $PCR, ceil $PCR | +- class $rest, rate $RESTMIN, ceil $MAX N = total number of VoIP clients PCR = per call rate (64kbit?) VOIPMAX = PCR * N MAX = total bandwidth available to you RESTMIN = minimum guaranteed bandwidth for bulk, should, roughly MAX - VOIPMAX - a little bit You simply classify any VoIP UDP flows into the $voip.0, $voip.1 ... $voip.N classes and you forget about it. (See also toward the bottom of this message.) Now every one of your N-VoIP clients can have guaranteed access at per-call-rate (PCR). This is most distinctly not dynamic, and probably rather hackish by comparison to something more RSVP-like. What's the beauty of the above model? First, you don't have to fiddle with it at all once it's installed. Second, HTB will take care of sharing the bandwidth between your VoIP callers and the rest of the traffic ($rest). What's the shortcoming of the model? You have to have enough bandwidth to allocate one VoIP class to each of your VoIP users without hitting your $MAX rate. Viewed from another angle, you must not have more potential VoIP callers than you have available bandwidth. : I am finding this extremely difficult. i.e I have : little/nothing working. The concept of dynamic traffic control structures has come up periodically on this list, and you may find some benefit to trawling the archives for earlier discussions. I'm quite certain there are some nuggets of knowledge available in the archive. : Do you know what might be the best way to approach this problem ? : : Currently i'm simply trying to write a bash script containing tc : commands and call that bash script from my c code. One other thing you could consider is building the above structure, but not installing any filters. While I have not used the netfilter CLASSIFY target, you could have your bash script insert CLASSIFY rules into a custom chain. Then, you have a set of traffic control structures in the kernel and you use netfilter rules to select which flows go into the VoIP classes. Good luck, -Martin -- Martin A. Brown http://linux-ip.net/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]
Mike, : I'm not trying to be obstinate, I'm just trying to understand : this more fully. But I sure appreciate the time you spent : answering my question. : : But, I'm still missing something. No worries--that's what mailing lists are for. A bit of back and forth. : You mention below that during a VoIP session, another user could : start up a large, high bandwidth, transfer and that this will : affect the queueing... If the VoIP traffic always gets out the : door first, how can this affect the jitter and latency of the : VoIP session; I understand it may devistate the other transfer... : Is this what you are trying to avoid by using HTB? Different flows expect different behaviour from the network. Bulk flows generally expect high throughput. Media applications frequently expect low delay and low jitter from the network. Here's the question I think you might be missing: Where are the queues building up? To make this as concrete as possible, I want to talk about about only one half of our VoIP session. I want to talk about the flows outbound from your network. Think of this as upload traffic. Let's assume: 1. V = VoIP client (inside your network) 2. R = VoIP receiver (outside) 3. F = bulk upload client (inside your network, greedy!) 4. L = Linux router 5. 256 kbit max upload speed Here's what we're watching. Remember that your prio qdisc will always prefer to transmit the VoIP packets first. Here's what's happening on your Linux router: - V establishes 64kbit flow with R - F starts sending as fast as possible - L always transmits (dequeues) packets from V's flow first, but will transmit packets from F's flow as fast as it can - somewhere upstream at the choke point, a router or bridge will see increasing queue depths as a result of F's flows - the variable queue depth on this upstream device will mean that V's packets will see increased delay and much higher jitter* So, yes, you can use a prio qdisc on the Linux router, but it doesn't really solve the problem for you. The Linux router may always dequeue your VoIP packets before it dequeues the packets of your other flows. Assuming the device through which you are transmitting is an Ethernet card, the Linux router can dequeue packets at a much higher rate than your link to the net can accommodate. Thus, you need to use shaping to control the total flow rate transmitted by the router. It is for this reason that one of the key rules of traffic control is for you to ensure that your host is the bottleneck. I hope that does a better job of explaining the problem, Mike. Volley! -Martin * VoIP is really sensitive to delay and somewhat sensitive to jitter. -- 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] TCNG issue - parent class restrictions are not honored
Greetings Rens,
: I've been migrating an existing htb-based traffic shaper from a
: hideous (I'm allowed to call it that - I wrote the damn atrocity
: myself) tc shell script into a TCNG configuration file, and after
: a few false starts I think I managed to get the syntax right.
I know what you mean about hideous shell scripts to manage traffic
control. They can quickly become rather horrid-looking. I'm a big
fan of tcng for its simpler syntax. OK, so your problem actually
has nothing to do with tcng, though. It is strictly an HTB-related
matter.
Summary of your problem? In HTB, rate is guaranteed.
Longer description follows.
: However, during tests it looks like some of the tiers aren't
: passing their restrictions on to lower levels.
In fact, it is quite the opposite. The embedded (or nested) tiers
are taking more than you wish them to take. This will require a
slight change in your configuration.
: $business = class ( rate 20Mbps, ceil 20Mbps ) {
: // list of business-class clients, including
: $client1 = class ( rate 2Mbps, ceil 2Mbps ) { sfq; }
: $client2 = class ( rate 2Mbps, ceil 2Mbps ) { sfq; }
: }
The above configuration basically says the following:
$business is guaranteed access to 20Mbps, and no more than 20Mbps.
$client1 is guaranteed access to 2Mbps, but no more than 2Mbps.
$client2 is guaranteed access to 2Mbps, but no more than 2Mbps.
This means that HTB is not even going to bother checking any
dequeued rates against a borrowing model until $client1 or $client2
(each individually) reach 2Mbps usage. That's a total of 2Mbps per
client. You have overcommitted.
[ As a side note, when you set a child classes rate and ceil to the
same value, you don't get the benefit of the bandwidth sharing. ]
Now, what you describe tells me something very different.
: When this setup was tested, both client 1 and client 2 received 2
: Mbps of bandwidth, so the attached filters worked properly. But
: when the rate and ceil of $business was lowered to 2Mbps, both
: client 1 and client 2 *still* received 2 Mbps, even when they
: were simultaneously downloading.
This is probably what you actually want:
$business is guaranteed access to 2Mbps, and no more than 2Mbps.
$client1 is guaranteed access to 800kbps, but no more than 2Mbps.
$client2 is guaranteed access to 800kbps, but no more than 2Mbps.
First, the two clients will each be guaranteed 800kbps. If they are
both transmitting as fast as possible, then they are implicitly
competing for the remaining 400kbps of the total 2Mbps.
In HTB, an inner class (in your case, $business) will divide up the
remaining available bandwidth between the various children, all the
way up to its own ceiling (ceil).
Now, try the following, and see how this works for you:
$business = class ( rate 2Mbps, ceil 2Mbps ) {
// list of business-class clients, including
$client1 = class ( rate 800kbps, ceil 2Mbps ) { sfq; }
$client2 = class ( rate 800kbps, ceil 2Mbps ) { sfq; }
}
I hope I have clarified the behaviour for you, but you may find more
detail on the HTB borrowing (sharing) model in the user guide [0]
and in a section in my Traffic Control HOWTO [1].
Good luck and happy shaping!
-Martin
[0] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#sharing
[1]
http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb-borrowing
--
Martin A. Brown
http://linux-ip.net/
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good morning, Mike, : I need a sanity check. I'm trying to setup my network to handle : VoIP. I'm thinking that all I need to do is prioritize the : realtime traffic above the interactive and bulk traffic. I see : so much discussion about traffic shapping, but I don't THINK this : is needed, right? I understand the problem with bandwidth : starvation, but for my application, the voip traffic has to get : out at whatever cost. In fact, you will need shaping, but you may be able to use a combination of an HTB class (to address the shaping) and a contained prio qdisc to handle your VoIP traffic. I'm going to assume for the remainder of my answer that you are talking about a leaf network, so you have Internet access through a single provider over some sort of broadband connection and you have a handful of potential VoIP and bulk Internet traffic inside that leaf network. Q: Why can't I just use a prio qdisc to handle my VoIP traffic? A: VoIP traffic is sensitive to latency and jitter. Without some sort of limitation on the total amount of traffic you push through your Internet pipe, even a single bulk upload or download can affect the latency and jitter of traffic transmitted or received. Let's say you have a 768 down/256 up (kbit) link, now, assume that somebody builds a connection into or out of your network and pushes data as fast as possible out of the network. With a prio qdisc, your outbound VoIP packets will indeed always be transmitted first, but the queue is outside your control. This queueing may be happening on an upstream router or bridge. That's a problem for your VoIP call, because you do not have control over delay or jitter. The above is a verbose explanation of one of the rules of traffic control. Make sure that your machine is the bottleneck. 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 maybe somebody on this list will make a recommendation to you for how s/he solved this problem. - -Martin - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFEn+7Wki79Zb8hnmwRAvH+AJ9smcUUXr/Ly8f1MaGsxjSsAX7gJgCfSb+C ENDJX7a5RWRgaK+WMY0Q3u0= =PH0T -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] English translation of article on HFSC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings all, Working in concert with the original authors, Klaus Rechert and Patrick McHardy, I have translated their article HFSC Scheduling mit Linux [0] on Hierarchical Fair Service Curve (HFSC) into English [1]. http://linux-ip.net/tc/hfsc.en/ Although the original content is not available directly from their website, Linux Magazin published the German article in 2/2005 [2]. The article is apparently slated for republication in special edition 3 of 2006 [3] (I don't know whether it is available yet). The HFSC queueing discipline itself was written by Patrick McHardy and added to the Linux kernel over two years ago, yet there isn't a great deal of documentation in English on the implementation itself, as he himself observes. I undertook this effort as a result of a posting on this list [4] from several weeks ago, inquiring about further documentation on HSFC. Thanks very much to Klaus Rechert for reviewing the translation and Linux Magazin for allowing the English translation to be distributed. The academic work underlying HFSC was submitted as an ACM paper [5] in 1997, and is available in English to illustrate the conceptual underpinnings of HFSC. The article announced here is a translation of a practical explanation of a typical usage case for the Linux HFSC implementation. I welcome comments and questions, - -Martin [0] http://klaus.geekserver.net/hfsc/hfsc.html [1] http://linux-ip.net/tc/hfsc.en/ [2] http://www.linux-magazin.de/Artikel/ausgabe/2005/02 [3] http://www.linux-magazin.de/Produkte/lms_2006_3.html [4] http://mailman.ds9a.nl/pipermail/lartc/2006q2/018857.html [5] http://www.acm.org/sigs/sigcomm/sigcomm97/papers/p011.html - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFEm+6Fki79Zb8hnmwRAhSdAJ9DXD6ZcD91XLi/Pl7ZWKbauThFCwCfYG1y O7xH+iYev2iCHnWfjxt5m44= =DHJJ -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] English translation of article on HFSC
Greetings Nickola! : Just a question - wasn't Mr. Kenjiro Cho [1] the original writer : of the HFSC queueing discipline, following the work of Mr. Hui : Zhang [2], et al.? snip/ In fact, I was probably not quite exact enough in my introduction. I meant this remark to be understood specifically with regard to the Linux HFSC implementation. You are quite correct to allude to the *BSD altq HFSC implementation which preceded Patrick McHardy's work. Thanks for the point of clarification, Nickola. Other history on HFSC would probably need to be introduced by somebody who knows this topic better than I do. Best regards, -Martin -- 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] tc filter change (Please)
Paul, : The filter - tc filter add dev eth1 parent 1:0 protocol all prio : 1 u32 match u8 0x6 0xff at 9 match u32 0xa640105 0x at 16 : offset at 0 mask 0f00 shift 6 eat link 5:0:0 : : Can anyone please tell me how to change it ? : : I've being searching and trying to make sense of the man pages : all day. Is this related at all to your prior question [0]? The above 'tc filter' command looks like something created by the tcng processor (tcc). If indeed you are using tcng, I would suggest solving the problem with that tool, rather than trying to understand the masking, shifting, matching and eating with a bare 'tc filter' command. -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2006q2/019106.html -- 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] TCNG question
Greetings again Paul, : class ( $call1 ) if ip_dst == 10.100.1.6 tcp_dport == 22 : if ip_src == 10.100.1.4 tcp_sport == 22 :; : : Now when i apply this traffic TO 6 on port 22 is indeed limited : to the speed i specify BUT it doesn't seem to take the src into : account at all. If i change the src to anything, even an address : that doesn't exist it still limits the speed. : : I need this class to only apply is both source and destination : ips are satisfied. Are you using tcng class selection paths in your configuration file? Could you show us a bit more of your config file? Tell us a bit about your networking configuration. Is this a device acting as a router (L3) or a bridge (L2)? Is there any NAT involved? In order to help you solve this problem, we'll need to know a bit more about your networking configuration. -Martin -- 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] Not understanding network setup!!
Visham, : By the way, do you know if there's a way to distinguish between : the ACK packet sent during the connection establishment phase of : a TCP connection and subsequent ACK packets sent during the data : transfer phase. : : I now that the ACK number sent during the connection : establishment will be equal to the 'sequence number for the SYN : in the SYN/ACK packet' + 1 : : Is there a way to distinguish between this 3rd packet and any : other ACK packet during data transfer w/o having to keep track of : sequence numbers? Are there other characteristics or options that : are set in the former and not in the latter? : : Basically I want to capture the three packets sent during the : connection establishment phase of TCP. How can I do that? How many times (or how quickly) do you need to do this? I have a somewhat simple-minded solution for you, but it doesn't scale, and may not actually solve you problem(s). If you have anything more than a few connections on which you wish to snoop (to see that they have successfully completed the handshake) my solution will not work for you. I have used this to capture the first three packets exchanged on a particular TCP connection: tcpdump -nni $INTERFACE -c 3 host $TARGET and port $DPORT and \ '( tcp[tcpflags] tcp-syn = tcp-syn or tcp[tcpflags] tcp-ack = tcp-ack )' If you are looking at inbound traffic to one of your servers, that can be a bit trickier. You could, however tcpdump the entire stream line-bufferered and write a filter (sed/perl) that prints out only lines showing SYN flag and lines containing 'ack 1 win'. 10:16:11.232505 IP xx.yy.zz.44.7284 aa.bb.cc.130.25: S 2114067570:2114067570(0) win 5840 mss 1460,sackOK,timestamp 906238871 0,nop,wscale 2 10:16:11.257184 IP aa.bb.cc.130.25 xx.yy.zz.44.7284: S 1756590593:1756590593(0) ack 2114067571 win 5792 mss 1380,sackOK,timestamp 3428194314 906238871,nop,wscale 2 10:16:11.257242 IP xx.yy.zz.44.7284 aa.bb.cc.130.25: . ack 1 win 1460 nop,nop,timestamp 906238896 3428194314 Good luck, -Martin -- 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] sangoma cards in linux
Hello there, : we only have a /29 internet routable network from our ISP and a : Cisco 1601 router with serial interface doing all the routing. : : I was thinking of replacing that cisco with a linux box with a : sangoma card, also using quagga with ospf on for my internel : networks I can't speak directly to quagga and ospf, but I can provide an encomium for the Sangoma cards. I have used the Sangoma cards (since 2000 or so, starting with the S508/FT1) and found them to be extraordinarily reliable. Their technical support is also very good. I have seen these cards used in Australia and the U.S. and recommend them wholeheartedly. Good luck, -Martin -- 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] Not understanding network setup!!
Visham, : I have to capture those three packets for each and every TCP : stream that is initiated. Also, I'm looking only for outbound : communication, i.e emanating from the PC on which I'm trying to : catch the packets. So the ACK packet will be generated on the PC : itself. But the problem how do I capture that particular ACK : packet and not the other ACK packets during data transfer phase, : w/o keeping track of IP address/port no. pairs. It sounds like argus [0] may provide a better solution to your problem. You will get much more information than you'd get with tcpdump, but you'll get at least what you describe. -Martin [0] http://www.qosient.com/argus/ -- 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] Routing based on source address
Joost,
: Is it possible to create a routing rule that depends on the
: source host/network, besides the target host/network?
:
: E.g. route everything from 192.168.0.x to 10.0.0.1, and route
: everything from 192.168.1.x to 10.0.0.1.
Yes. If I understand your question correctly, you have described a
classic case of policy routing. Policy routing allows you to use
packet attributes and meta-attributes other than the destination
IP/network for route selection. These documents [0] and [1] are a
few years old, but everything described still functions this way.
You will want to learn about how to use the routing policy database
(RPDB) and then you'll need to create multiple routing tables. The
RPDB controls whether and which of the routing tables is selected
based on things like Type of Service (ToS), source address,
netfilter mark and/or ingress interface.
And here are two tips:
A. turn off reverse path filtering [2]
B. think about the return path of packets, too
Forgetting to account for the return path of packets seems to be a
commonly encountered problem when implementing policy routing
solutions. I suggest the copy_routing_table shell function [3],
which can be run like this:
# printf %s %s\n 5 provider_b /etc/iproute2/rt_tables
# copy_routing_table provider_b
Now, there's an exact copy of the main routing table in the routing
table provider_b (number 5). Next step is to change the default
route for that routing table:
# ip route change default table provider_b via 10.0.0.1
# ip rule add from 192.168.0.0/24 table provider_b
# ip rule add from 192.168.1.0/24 table provider_b
Good luck,
-Martin
[0] http://linux-ip.net/html/routing-rpdb.html
[1] http://linux-ip.net/html/routing-selection.html
[2] http://lartc.org/howto/lartc.kernel.html#LARTC.KERNEL.RPF
[3] function for copying a routing table
# - - - - - - - - - - -
copy_routing_table () {
# - - - - - - - - - - -
#
# -- accepts at least one parameter:
#
#$1: table identifier for the routing table to create
#$2: optional source table identifier
#
test $# -lt 1 return
DTABLE=$1
test $# -gt 1 STABLE=$2
test $STABLE = STABLE=main
ip route flush table $DTABLE
ip route show table $STABLE | while read ROUTE ; do
ip route add table $DTABLE $ROUTE
done
}
--
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
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] Issue with ip aliases and routing
Hello Jon-david Geier, : After setting these adresses up I tested that they were : functional ( at least to the local machine ) by pinging each : adress all of which responded from the local machine. If you can ping the addresses from the machine itself, then they have been successfully added to the interface (eth0). You can confirm this, of course by listing all of the addresses on eth0: # ip address show dev eth0 This should show all of your addresses. Note that the term alias for additional IP addresses on an interface is deprecated. The use of the label (e.g., eth0:1, eth0:4) is simply a backwards-compatible convenience for ifconfig. The iproute tools show a slightly more accurate picture of the networking stack. (xref also, for some possibly unexpected behaviour of the IP stack when an interface is down [0] FAQ) : The next thing I did was I set a : route statement to set the primary ( x.x.214.162 ) as the gateway for the : x.x.6.224 network via this statement: route add -net x.x.6.224 netmask : 255.255.255.224 gw x.x.214.162. This is probably not necessary. Let's use your eth0:1 as an example. When the network startup scripts bring up this IP, you'll see the address appear on the interface (ip address show), and you should see a route to the network appear. Here's roughly what I would expect to see on your machine (different link layer address for sure): # ip addr show dev eth0 2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:1b:af:78:51 brd ff:ff:ff:ff:ff:ff inet 38.99.214.162/30 brd 38.99.214.163 scope global eth0 inet 38.98.6.230/27 brd 38.98.6.255 scope global eth0:1 inet 38.98.6.235/27 brd 38.98.6.255 scope global secondary eth0:2 inet 38.98.6.240/27 brd 38.98.6.255 scope global secondary eth0:3 inet 38.98.6.245/27 brd 38.98.6.255 scope global secondary eth0:4 inet 38.98.6.250/27 brd 38.98.6.255 scope global secondary eth0:5 inet6 fe80::230:1bff:feaf:7851/64 scope link valid_lft forever preferred_lft forever # ip route show dev eth0 38.98.6.224/27 proto kernel scope link src 38.98.6.230 38.99.214.160/30 proto kernel scope link src 38.98.6.230 default via 38.99.214.161 Note the following potential pitfall. If you were to remove the IP address 38.98.6.230 from eth0, all of the other ones would also be removed [1]. : I thought this was all I needed in order to be able to access the : aliased adresses externaly from the machine. Unfortunatley this : is not the case. I have ensured that ip forwarding is enabled and : that the adresses are setup correctly. Is the machine a router? If landuconsulting is not a router, then you do not need (nor want) IP forwarding enabled. : I have also atempted to use the same route statment with iproute2 : via : ip route add 38.98.6.224/27 dev eth0 proto kernel scope : link src 38.99.214.162 and I am still unable to access the : adresses externaly from the machine. So, you are testing to see if you can reach 38.98.214.162 and 38.98.6.230 (and friends) from a remote location? Are you sure the upstream route exists? Here's how to use tcpdump to test on landuconsulting: # tcpdump -nn -i eth0 net 38.98.6.224/27 or arp Now, generate your inbound traffic to any of your additional addresses. Watch for ARP requests. Is your machine answering them? It is quite possible that your upstream router does not have a route to 38.98.6.224/27 to your local Ethernet. That's something you need to fix on the upstream router, not on the host you are configuring with many IP addresses. : I have even brought down iptables to test that there is no : conflict there. Here are the configuration files. [ config files snipped, summary retained ] eth0 38.99.214.162 eth0:1 38.98.6.230 eth0:2 38.98.6.235 eth0:3 38.98.6.240 eth0:4 38.98.6.245 eth0:5 38.98.6.250 [ snipped sysctl.conf; nothing unusual-looking there ] : [EMAIL PROTECTED] ~]# cat /etc/rc.local : # !/bin/sh : # : # This script will be executed *after* all the other init scripts. : # You can put your own initialization stuff in here if you don't : # want to do the full Sys V style init stuff. : : touch /var/lock/subsys/local : route add -net 38.98.6.224 netmask 255.255.255.224 gw 38.99.214.162 Yank this line. It is not required. : I'm pretty sure that I'm missing just some small detail but for : some reason it evades my notice. Any assitance you can provide me : with would be grately appreciated. Thank you for your time. Good luck, -Martin [0] http://linux-net.osdl.org/index.php/IPv4 [1] http://linux-ip.net/html/tools-ip-address.html#tools-ip-address-del -- 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] EBTables, iproute, etc.
Ron, : Today: To get traffic for our IDS sensors and a billing system, : we collect everything at our core switches (2) by connecting a : SPAN port from each switch to a server (so, 2 interfaces : collecting traffic). That server changes the destination MAC : address on all traffic to that of another server running iproute : and sends it out a third interface. The server running iproute : collects the traffic on one interface, and sends traffic to : different sub interfaces depending on the network; a switch : connected to the outgoing traffic allows connection of the IDS : sensors, billing system, etc. This, right? --- two SPAN ports / +--+ / +--+ +--+ | switch |-| | | | +==+ | eth_rewr |-| p_router |- other systems | switch |-| | | | +--+ +--+ +--+ So, you essentially want to conflate the eth_rewr box and the p_router box, correct? : 1. Just run iproute, having it take the traffic from the SPAN :ports and policy route without having to have the first server :change destination MAC addresses. : a. Can iproute do policy routing on traffic not destined for it in :the first place (i.e. by having the interfaces in :promiscuous mode)? : b. If not, then does iproute contain functionality that would allow :it to sense all traffic and change the destination MAC :address or IP address? Strictly speaking, the problem here doesn't have anything at all to do with iproute. The switch is transmitting frames with ethernet headers bound for their real destinations. The eth_rewr box simply rewrites the ethernet frame headers so that they have the MAC address of the p_router interface. I can't see how this proposed solution will be viable for you. : 2. Have EBTables and iproute running on the same box if #1 above isn't :possible. : : a. Can we do this without having to have more interfaces in the :box, connected to each other with crossover cables? I think this approach is much more likely to yield fruit. Although I have not yet done anything like this. Consider using the ebtables broute/BROUTING table/chain. You may find this documentation [0] helpful in looking at the problem again. In particular, Joshua Snyder's diagram [1] should be able to illustrate to you a possible solution where ebtables and iproute are running on the same box. To quote from the ebtables manpage: The targets DROP and ACCEPT have special meaning in the broute table. DROP actually means the frame has to be routed, while ACCEPT means the frame has to be bridged. Thus, you should be able to do something like the following on the policy router (assume your MAC on eth1/br0 is 00:80:c8:e8:1e:fc): ebtables --table broute \ --append BROUTING\ --in-if eth1 \ --dst ! 00:80:c8:e8:1e:fc\ --jump redirect --redirect-target DROP So, now you have frames leaping happily up to the IP stack and your policy router. I don't know what the performance implications are of running both ebtables and policy routing on the same machine. Good luck, -Martin [0] http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png -- 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] Forwarding connections/packets across interfaces
Greetings Alan, : I have a mail server (and a test program as well) that binds to : an address on eth1, and tries to connect to an address on eth0's : network. Connections just time out. I've tested connections : where I did not bind to a specific interface and I can make the : connection. : : I've set ip_forward=1, and rp_filter=0 on all interfaces, and : still cannot get a connection from eth1's address to something : off of eth0's networks. Firewalls are disabled on the host. WellI don't think you should need to remove rp_filter unless you are performing policy routing in addition to the simple routing configuration you describe. : Is there additional voodoo that needs to be set to allow traffic : to cross from one interface to the other? Did you pay your semi-annual chicken-sacrificing bill? If not, I may not be able to help you. OK, seriously, I have just tested exactly this sort of connection on a similarly configured network. It works exactly as you want it to. I'm guessing that you have some packet filter somewhere which is interfering. How would you be able to tell? First, watch traffic to see if it is ever leaving your router, and watch on your mailserver to see that traffic is arriving: router# tcpdump -nn -i eth0 host $MAILSERVER_IP mailserver# tcpdump -nn -i eth0 host $ROUTER_IP_0 or host $ROUTER_IP_1 Now, make those connections from your router (with your TCP testing tool of choice): router# socat - TCP4:$MAILSERVER_IP:$SERVICE,bind=$eth0_IP router# nc -vvs $eth1_IP $MAILSERVER_IP $SERVICE If you don't see any traffic leaving your router, is it possible that you have a strange POSTROUTING rule which does not refer to output interface? Good luck, -Martin -- 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 do probabilistic packet loss in kernel?
Greetings George, : I am using iproute2 to setup fowarding, adding routes like ip : route add 192.168.1.3 via 192.168.1.2 : : I was wondering where in the kernel I can insert probabilistic : packet loss only for forwarded packets? So that for instance I : can drop 5% of all forwarded packets? : : I don't need help with the actual code, just need help finding : where to insert this code :) I believe you are looking for the netem qdisc [0]. Here's just a snippet from Stephen Hemminger's wiki page to help you imagine how you could use netem to introduce probabilistic packet loss. # tc qdisc add dev eth0 parent 1:3 handle 30: netem \ delay 200ms 10ms distribution normal Good luck, -Martin [0] http://linux-net.osdl.org/index.php/Netem -- Martin A. Brown --- http://linux-ip.net/ --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] how to do probabilistic packet loss in kernel?
Hello again, : I have a question for you though... in terms of adding loss like : this, this will not interact with hardware layer rate control of : wireless cards right? : : For instance... dropping from 54Mbit to 11Mbit on an 802.11g card : when loss certain loss begins occuring Outgoing packets pass through the traffic control system (netem qdisc, in this case) just before being dequeued to the driver. The actual behaviour of the kernel, in this case, depends on a sanely coded driver. I assume a sanely coded driver, in which case this is what you should see when the hardware cannot accept packet for transmission: 0. netem (or any other qdisc, for that matter) will operate as configured (inducing loss, delaying, reordering or prioritizing your outgoing packets) 1. eventually qdisc_restart() will call hardware driver 2A. [if success] packet is transmitted 2B. [if failure] the hardware driver cannot handle the packet for some reason (TX ring full, link failure or other problem); it will propagate an error condition to higher layer 3. qdisc_restart(), receiving such an error will cause the packet to be requeued [0] 4. goto step 1 My source for this answer documents kernel 2.4, although the code in the networking stack seems to be fundamentally the same in this case. See the DataTAG report entitled A Map of the Networking Code in Linux Kernel 2.4.20 [1]. On page 19, Section 4.3.1, the authors refer to the function net/sched/sch_generic.c which includes qdisc_restart(). So, strictly speaking, there should be no interaction between your use of the netem qdisc and lower layer rate control (lossy transmissions and any compensatory mechanisms between radios). Note! Both of the sources for my answer are from old documentation (and, of course, ongoing general knowledge of the traffic control system). I believe that the kernel still operates in this fashion, but would absolutely welcome any corrections from those who are more intimately familiar with the kernel and hardware perspective. Good luck, George, -Martin [0] http://qos.ittc.ku.edu/howto/node11.html http://qos.ittc.ku.edu/howto/ [1] http://datatag.web.cern.ch/datatag/papers/tr-datatag-2004-1.pdf -- Martin A. Brown --- http://linux-ip.net/ --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping per IP in PPPoE borrowing or sharing Uplink or Downlink
Hello again Rani, : helo again. I think this question i am asking is worth: : : we know that pppoe-server creates a pppX device on each : connection done to it. So, when i have to shape, i have to shape : each pppX connection device on itself alone. What i know is that : the borrowing method on one device by itself, e.g. ppp0, alone : using HTB or the like. this means that i have to create for : another device, e.g. ppp1, its own HTB or CBQ tree. : : So, how can i in PPPoE technology setup sharing or borrowing : between all the pppX devices so it won't let network starvation : problem float on surface? You should probably consider IMQ [0] or the new-ish IFB [1]. With either tool, you'll be able to create a traffic control structure which spans multiple output devices. Good luck, -Martin [0] IMQ = Intermediate Queuing Device http://www.linuximq.net/ http://lartc.org/howto/lartc.imq.html http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/HowToInstall [1] IFB = Intermediate Functional Block http://mailman.ds9a.nl/pipermail/lartc/2006q2/018641.html http://marc.theaimsgroup.com/?l=linux-netdevm=113674224714758w=2 -- Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping per IP in PPPoE
Hello Rani,
: i am currently now serving PPPoE in my area. i had a script
: generated from tcng that worked perfectly before i started
: serving PPPoE. the issue is not in the script it self BUT in that
: tc code is not shaping on the ethernet anymore BUT INSTEAD on
: the pppX devices. I tested it and talking jargon, what should i
: do?
:
: The issue is that for each PPPoE login, PPPoE-server creates on
: the server a pppX device. that is 10 logins means 10 ppp devices.
: from ppp0 till ppp9. and one might die upon disconnection.
I'd suggest simply using the pppoe ip-up configuration scripts to
call the appropriate tc or tcng commands. Since ip-up should be
called something like this:
ip-up ppp0 $TTY $SPEED 192.168.0.4 10.0.0.4 $OTHER
Is ip-up called by YOUR pppoe-server binary? I am not able to test
this.
you should be able to create a script that would either execute tc
commands or a create tcng file on the fly. I created the basic
structure of such a script below, although you could probably
add/replace your own shell functions (tc_sfq, tc_my_complex_config)
with a much more complex traffic control configuration.
Good luck,
-Martin
#! /bin/bash
#
# -- add queuing to an interface brought up by pppd, 2006-04-11; -MAB
#GPL
#
# ip-up iface tty speed local-IP remote-IP ipparm
dev=$1 shift
pty=$1 shift
spd=$1 shift
lip=$1 shift
rip=$1 shift
logger () { command logger -it ${0##*/} -- $@ ; }
abort () { logger $@ ; exit 1 ; }
tc_tbf () {
local dev=$1 shift
local lip=$1 shift
local rip=$1 shift
test $dev =abort ${FUNCNAME}() called with no device name
test $lip =abort ${FUNCNAME}() called with no local IP
test $rip =abort ${FUNCNAME}() called with no remote IP
cat -EOTC
tc qdisc add dev $dev root handle 1:0 tbf rate 1544kbit limit 20kB
burst 3kB
EOTC
}
# -- run all commands in a single shell that we instruct to quit on any error
#
tc_tbf $dev $lip $rip | bash -e
# -- did the shell complete successfully?
#
test $? -gt 0 abort Could not install traffic control on $dev.
logger Installed traffic control configuration on $dev.
# -- end of file
--
Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] I dont want to shape a host
Nataniel, There are probably a handful of ways to solve this problem. Two pop to mind right away. : I am still reading about my QoS rules and I need that one of my : servers (that is into my LAN but has an routing ip address) did : not get into the qos rules I have. So I want that all traffic : coming or going to that specifc host did not get shapped by any : traffic control and do not get even into a QoS class. How can I : do this? Option A: specify default 0 in your HTB qdisc declaration If you install the HTB qdisc with a default 0 parameter, you are telling HTB to dequeue unclassified packets as fast as the hardware will accept the packets. Here's an example: tc qdisc add dev eth0 root handle 1:0 htb default 0 Now, any unclassified packets will simply be dequeued as fast as your hardware can do it. If you are trying to remain the bottleneck between you and the Internet, it is quite likely that this configuration will defeat your goal. Option B: make a deeper HTB tree Build the following: class 1:0, rate = ceil = hardware maximum bitrate class 2:0, rate = low, ceil = hardware maximum bitrate class 3:0, rate = low, ceil = maximum for everybody else root +--- HTB 2:0 --- your routing ip (public | / server?) goes here +-- HTB 1:0 --- \ +--- HTB 3:0 | +--- HTB 3:1 +--- HTB 3:2 +--- HTB 3:3 |... +--- HTB 3:N Now, you simply attach your filters to 1:0, like you did before, and put all traffic for your routing ip into the 2:0 class. If the rate on class 2:0 stays low, but its ceiling is the same as the rate/ceil on 1:0, then you'll effectively get borrowing up to maximum available throughput for HTB 2:0. Good luck, -Martin -- Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Tocken Bucket with priority?
Hi there Emanuele, : I tried your solution and it seems to work. Yet i'm experiencing : an unexpected behaviour: when i try to fill the highest priority : queue (expecting the lower priority traffic to starve), i see : that the higher priority queue starts to grow, while some lower : priority packets are served. This means that upon congestion of : the link, the shaper stops working properly and does not apply a : strict priority policy. : : I was wondering about the granularity of the service: in fact it : may happen that, if the granularity is, say, 5 packets, the : scheduler sees the higher priority queue empty, and it serves a : train of 5 packets from the lower priority queue; while it is : serving those packets, new packets arrive in the high priority : queue, and have to wait until the scheuler have fully served the : lower priority train. To avoid such a behaviour, i looked for a : parameter that sets the granularity, but the documentation is not : that clear about it: what are the parameters that set the : granularity? Is it a problem of prio or of htb? I realize I'm jumping in a bit late on this item, but I don't quite understand why HTB as below should not work for you. Have you tried a configuration like the below? You must know your available bandwidth for this trick to work, but the following configuration approximates a PRIO qdisc, but gives you the benefit of shaping. class $parent, rate $MAX, ceil $MAX | +- class $voip, rate ( 0.95 * $MAX), ceil $MAX | +- class $other, rate ( 0.05 * $MAX), ceil $MAX Remember that all the shaping and prioritizing in the world will not help you if you are not the bottleneck. Your shaping/prioritizing device must be the choke point. While I don't have any direct experience with VoIP, I can imagine that you might see an increased latency as a result of queuing delay in your VoIP class. To limit latency induced by queuing delay, you could create a child of the $voip class with bfifo or pfifo qdisc of a specified depth/size. If, however, this is necessary, you may simply need more bandwidth. And, as an attempt to answer your question aboveperhaps you could try fiddling with the quantum setting on a given class. When a given class has exceeded its rate, it can only transmit quantum bytes per dequeue opportunity. Good luck, -Martin -- Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Multiple providers routing
Greetings Sameer,
: I have a linux router connected to two separate internet
: connection from an ISP. There is a third interface ( ip -
: 192.168.1.1 ) in the router connected to the local network.
: Configured the routing tables and added the rules and everything
: seems to be working fine from the routing box. Traceroute to
: external internet sites reveal that traffic is being routed
: correctly and that the failover mechanism is working.
:
: Now in my internal machines the gateway address is the set to the
: third interface of the router and the internal machines can ping
: the router ( 192.168.1.1 ). The problem is that the internal
: machines cant connect to the net. A quick check with pings and
: tcpdump revealed that the packets from the internal machines are
: arriving at the router and are being routed correctly... but are
: not coming BACK from the router to the internal machines.
:
: Any pointers as to why this is happening would be useful
Quick, experienced guess:
# sysctl net.ipv4.conf.default.rp_filter
If the answer provided is:
net.ipv4.conf.default.rp_filter = 1
Then, you'll need to flip the reverse path filtering toggle [0].
When this sysctl is set to 1, the kernel automatically drops packets
incoming from the wrong interface according to the primary
('main') routing table.
Good luck,
-Martin
[0]
http://ipsysctl-tutorial.frozentux.net/chunkyhtml/theconfvariables.html#AEN634
--
Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] question about traffic control
Michiel, : I have the following situation: : 1 gateway box with 2 WAN interfaces (eth1 and eth2). : 1 LAN interface eth0 : default gateway is eth2 : I want to route all traffic with destination protocol tcp 22 (ssh) NOT : over the default gateway eth2 but force them to find it's route over : eth1. : All other traffic must go the normal way over eth2. : : Is this possible with tc or an other tool? You already have an answer from Markus Schulz, but I thought I might add a bit of help, too. You are describing a problem that can be solved with policy routing. Linux has long supported policy routing. Although I have not updated my documentation in quite some time, you may find this document [0] helpful in untangling the possible configurations to support policy routing. In short, one solution involves: - [optional] making an entry in the /etc/iproute2/rt_tables file grep -q secondary /etc/iproute2/rt_tables \ || echo 3 secondary /etc/iproute2/rt_tables - adding a routing table with its default route pointed out eth1 ip route add default via $ETH1_GW dev eth1 table secondary - marking the traffic you wish to handle differently iptables [ ... selectors ... ] -j MARK --set-mark 3 - modifying the RPDB to include select your secondary routing table for traffic with fwmark 3 ip rule add fwmark 3 table secondary That should get you most of the way there. Remember a few additional tips which often stump beginners with policy routing: - Think about the return packets. Are they handled according to your plan? - Turn off reverse path filtering (rp_filter) [1] - Make sure your (S)NAT rules are correct for packets leaving via eth1 (the other interface). Good luck, -Martin [0] http://linux-ip.net/html/adv-multi-internet.html [1] http://ipsysctl-tutorial.frozentux.net/chunkyhtml/theconfvariables.html#AEN634 -- Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: ¿how do burst/cburst work exactly?
: However I have a doubt on [1]. When packets arrive to an HTB : filter, it first checks to see if there are ctokens available. : How come if there are, it then checks for tokens instead of just : dequeuing at full speed. And if there are none: shouldn´t it THEN : check for tokens instead of discarding right away? I would like to quibble about terminology here. A filter selects a destination class (which contains a qdisc). Filters have absolutely nothing to do with tokens. Once a packet has been filtered, it enters its destination class. Roughly speaking, the class does the following: 1. check to see if there are tokens availabledequeue 2. check to see if there are ctokens available dequeue 3. wait until tokens become availablegoto 2 (1?) Once a packet is in an HTB class, the packet will not get discarded by the class until the class itself has a tremendous backlog and needs to drop the packet. An HTB class will delay the transmission of the packet until tokens are available. This is the core feature which provides the shaping capability. : Also, could you give me an advice or reference on the following? : I need a child class to allow passage to a video stream that I : KNOW has mean X kbps and seldom peaks of Y kbps and T seconds. : Would the best way be to just configure mean=X, ceil=Y? Or should : I configure mean=ceil=X and calculate a cburst that´ll allow : passage of the peaks? Or maybe a third option. I cannot recommend an optimal calculation method, though I would start with X kbps as the rate and Y kbps * T as the burst. After that, I'd increase rate and decrease burst until there was no choppiness in the transmitted video stream. Good luck, -Martin : - Original Message - From: Martin A. Brown : [EMAIL PROTECTED] : To: VideoIP [EMAIL PROTECTED] : Cc: lartc lartc@mailman.ds9a.nl : Sent: Wednesday, July 13, 2005 2:14 AM : Subject: Re: [LARTC] HTB: ¿how do burst/cburst work exactly? : : : : Hello, : : : I´ve read all the definitions of burst and cburst and I´ve tried : : playing with the parameters and graphing the output of the filter : : to see its effects, but STILL I can´t figure out how the : : parameters work exactly. : : : : Could anyone give a better explanation than the manpage? : : Have you tried Stef's site? He has a good page [0] that talks about : the various tests he did while experimenting with HTB burst and : cburst parameters? : : Some time ago, I took a stab at creating a visual representation [1] : of a hypothetical HTB configuration [2]. In order to understand : when cburst is used, look for the diamond-shaped boxes in the : diagram which talk about tokens and ctokens. : : Every HTB class has two buckets. : : rate bucket is of burst size, traffic uses tokens : ceil bucket is of cburst size, traffic uses ctokens : : My diagram may give you the framework to understand exactly how they : are used if it's still unclear to you, but Stef's site will give you : much better detail on the results of using burst and cburst. Of the : scenarios he describes, I like the results of Test 7 the best. The : only guideline that struck me after reading his results was to : prefer burst and cburst usage on parent classes. : : Good luck, : : -Martin : : [0] http://www.docum.org/docum.org/tests/htb/burst/ : [1] http://linux-ip.net/traffic-control/htb-class.png : [2] http://linux-ip.net/traffic-control/diagram.html : : -- Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tbf initial burst
Greetings, : I am using tbf to do bandwidth limitation. i found that when i : start passing traffic there is a burst and then the rate goes : down to what is configured. is this a known issue or do i need to : change some parameters? The behaviour you have described is exactly the theoretical goal of a token bucket filter, and also the practical behaviour of the TBF queueing discipline. In other words, congratulations, you are using a TBF! You probably wish to tweak parameters. -Martin -- Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: ¿how do burst/cburst work exactl y?
Hello, : I´ve read all the definitions of burst and cburst and I´ve tried : playing with the parameters and graphing the output of the filter : to see its effects, but STILL I can´t figure out how the : parameters work exactly. : : Could anyone give a better explanation than the manpage? Have you tried Stef's site? He has a good page [0] that talks about the various tests he did while experimenting with HTB burst and cburst parameters? Some time ago, I took a stab at creating a visual representation [1] of a hypothetical HTB configuration [2]. In order to understand when cburst is used, look for the diamond-shaped boxes in the diagram which talk about tokens and ctokens. Every HTB class has two buckets. rate bucket is of burst size, traffic uses tokens ceil bucket is of cburst size, traffic uses ctokens My diagram may give you the framework to understand exactly how they are used if it's still unclear to you, but Stef's site will give you much better detail on the results of using burst and cburst. Of the scenarios he describes, I like the results of Test 7 the best. The only guideline that struck me after reading his results was to prefer burst and cburst usage on parent classes. Good luck, -Martin [0] http://www.docum.org/docum.org/tests/htb/burst/ [1] http://linux-ip.net/traffic-control/htb-class.png [2] http://linux-ip.net/traffic-control/diagram.html -- Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] QOS HELP PLEASE
Dariusz, : so the sum of all rates of speeds of classes for the clients should be : less than the rate of the class 1:2 ? or i understand it badly ? Indeed, you understand correctly. Your client classes are leaf classes. - An HTB leaf class guarantees rate access. - Above rate, the leaf class will borrow (from parents) up to ceil. This bears repetition: the guaranteed total of bandwidth, before HTB shaping and borrowing begins, is the sum of the rates of the leaf classes. - If you want to make sure that the borrowing and shaping works correctly, be certain to configure HTB so that the leaf (and child) classes can never send more traffic than the parent has in ceil. - For best results, configure HTB so that the leaf (and child) classes can never send more traffic than the parent has in rate. Good luck, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] QOS HELP PLEASE
Greetings Dariusz, : ive got problems with my network (120 people) : ive got big pings (300ms)m whereas there are normally about 19ms. : i do not know if my qos is proper (fast i mean). : : www.tdi.pozman.pl/fir2 - my qos : www.tdi.pozman.pl/rules - my firewall After examining 'fir2', which shows an HTB class structure listed below, I think you don't quite understand the guarantees and the borrowing model of HTB. your Internet bound traffic (1:2) -- - - - -- rate ceil | +++++---+ 1:N | 1:7 |1:6 |1:5 | 1:4 | | [ lots of ||| +-- 128kbit 256kbit | classes ||+-- - - - - 128kbit 256kbit |here ] |+- - - - - - - - - - 128kbit 256kbit | +-- - - - - - - - - - - - - - 128kbit 256kbit | ... ... +-- - - - - - - - - - - - - - - - - - - - - - - 128kbit 256kbit In your case, N=163 (although I didn't check that every class was created with the same rate/bandwidth). The problem you are having is that the borrowing (and hence, shaping) model never gets a chance to go into effect. Every leaf class (1:4 through 1:166) is guaranteed 128kbit. Your QoS setup is actually not helping you at all! It's configured to guarantee around 19mbit (128kbit * 163 guarantees). Given your available Internet bandwidth, it should work out a bit better for you if you slim down the total number of classes and lump a few handfuls of users in each class with an embedded SFQ. You may find that Stef's rules for HTB shaping are quite handy [0], and also my HTB description [1]. Good luck, -Martin [0] http://www.docum.org/docum.org/faq/cache/10.html [1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ip rule to remove
Hi there Askar, : and when i tried ip rule del 32742 it gives me error : so how to get get of these extra rules? Try: ip rule del prio 32742 from all fwmark 0x2 lookup squid.out -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] how to remove rules
Hello all!
: I've had the same problem. I sorta wish there was an ip rule flush
: command that would leave only the default rules.
I have a function called flush which flushes all tables and all rules
other than the main routing table. Here's the rule flush portion. It
won't win any points for elegance, but it should get the job done:
ip rule show | grep -Ev '^(0|32766|32767):' \
| while read PRIO RULE; do
ip rule del prio ${PRIO%%:*} $( echo $RULE | sed 's|all|0/0|' )
done
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] question re ip rules logic
-tutorial.frozentux.net/chunkyhtml/theconfvariables.html#AEN634 [2] http://linux-ip.net/gl/ip-cref/ [3] http://linux-ip.net/html/routing-selection.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] netlink api
Morgan, [ good question snipped ] : I'm more than happy to RTFM, but I need to know which fine manual to : read. Please, any pointer would be greatly appreciated. Perhaps you have not found this yet? http://qos.ittc.ukans.edu/netlink/html/ I'm not sure that it answers your questions, but if you haven't run across this document, it should help some. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] rp_filter and fib_validate_source sequence in KPTD
Hello all, My question: - - - - - - - Does anybody know when the reverse path filtering occurs as the packet traverses the kernel? Does it happen before NF_IP_PRE_ROUTING (PREROUTING) or not? Does it only happen at route selection time? What I have tried to do to find the answer: - - - - - - - - - - - - - - - - - - - - - - I find a posting (from many years ago) [0], which suggests that this happens in fib_validate_source() (in fib_frontend.c) which is only called by route.c. I tried following the diagram by Mathieu Lafon to see if fib_validate_source() is called in ip_rcv() (in ip_input.c), but I don't read C very well, so I could well be missing where the rp_filter validation is occurring. If I understand the path correctly, the functions are traversed in this order (from most deeply nested first): fib_validate_source() ip_route_input_slow() ip_route_input() ip_rcv_finish() ip_rcv() It seems that ip_rcv() (in ip_input.c) calls the following, and I simply do not understand what this means: return NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, dev, NULL, ip_rcv_finish); I'm guessing that NF_IP_PRE_ROUTING (the PREROUTING hooks) are called before ip_rcv_finish is called, which means that the rp_filter action doesn't occur until after the PREROUTING hooks. Is this accurate? Can anybody shed some light? Is my interpretation accurate? Thank you very much, -Martin [0] http://www.ussg.iu.edu/hypermail/linux/kernel/0002.1/1522.html [1] http://open-source.arkoon.net/kernel/kernel_net.png -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] NAT tc filter addresses
Bill,
: Is there a flow diagram as to where tc actions take place with
: respect to NAT and other iptables functions on a multihomed box
: (private public NICs) ? Are tc filter rules consulted before or
: after NATing?
For simplicity's sake, let's just talk about packets leaving the box
(transmit only). All iptables functions have taken place by the
time the traffic control functions are called.
There are a number of different diagrams which cover this in
different ways. The KPTD [0], which Stef has already mentioned, the
Packet Flow diagram [1], which deal with the bridging, brouting
stuff as well, an older 2.4 packet traversal diagram [2], and my
recent diagram of just the netfilter system [3].
: My real interest is in basic understanding first, and then
: solving a real problem second.
Well...further on the self-promotion front--if understanding is what
you seek, then maybe also my Traffic Control HOWTO would be handy.
It's available at TLDP [4].
: Example:
: Firewall Public NIC 123.123.123.1
: Firewall Private NIC 192.168.168.1
: Dedicated Video Conferencing equipment @ 192.168.168.100
:
: I'd like to write a rule that says any traffic emanating from the
: private .100 box gets 128kbit of bandwidth out of a T1's total 1.55mbit
: as the traffic heads out on to the Internet to find the other end of the
: Video Conference.
:
: The shaping occurs on the Public NIC, but the only address I have to
: work with is a private address. By time the traffic hits the public NIC
: and tc rules are applied, I suspect the packet no longer has a source IP
: of private .100, but has been NAT'd to the public NIC address. There's
: no way to distinguish private .100's traffic via IP address. by time the
: tc filters are queried. Is that correct?
That is correct, but you can always use the fwmark.
: What methods are available to do this? I can think of marking all
: the packets on the private side then looking for the marks on the
: public side. Or, NAT private.100 to a specific Public IP and then
: write rules for that new Public IP. What other options are there?
As far as I know, these are the two best options. If you don't wish
to mess around with marking, the NAT option seems a very good and
sensible way to go.
If you haven't used tc much, I'd recommend tcng [5]. It's far
simpler to use (and more intuitive) once you have it installed.
Though I haven't tested the below, I could see something like this
as a starting point for your experimentation. If you wished to cap
the video bandwidth at 128k, you could simply use the same parameter
for the rate and ceil (videobw).
#define private eth0
#define publiceth1
/* assume that the NAT for the video server is separate from
the source IP of the remainder of the traffic */
#define videobox 192.168.168.100
#define videopub 123.123.123.100
#define videobw128000 bps
#define halft1 772000 bps
#define fullt11544000 bps
/* this should take care of shaping download traffic */
dev private {
egress {
class ( $video ) if ip_src == videobox ;
class ( $other ) if 1 ;
htb {
class ( rate fullt1, ceil fullt1 ) {
/* guarantee videobw to $video, allow full usage */
$video = class ( rate videobw, ceil fullt1 ) ;
/* guarantee half the t1 to other traffic */
$other = class ( rate halft1, ceil fullt1 ) ;
}
}
}
}
/* this should take care of shaping upload traffic */
dev public {
egress {
class ( $video ) if ip_src == videopub ;
class ( $other ) if 1 ;
htb {
class ( rate fullt1, ceil fullt1 ) {
$video = class ( rate videobw, ceil fullt1 ) ;
$other = class ( rate halft1, ceil fullt1 ) ;
}
}
}
}
Good luck!
-Martin
[0] http://www.docum.org/docum.org/kptd/
[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
[2] http://open-source.arkoon.net/kernel/kernel_net.png
[3] http://linux-ip.net/nf/nfk-traversal.png
[4] http://tldp.org/HOWTO/Traffic-Control-HOWTO/
[5] http://tcng.sourceforge.net/
--
Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb and fw problems
Dear Isianto Istiadi, Here are your class creation statements: : [ snip ] 1: classid 1:1 htb rate 65kbps ceil 65kbps : [ snip ] 1:1 classid 1:10 htb rate 20kbps ceil 35kbps prio 3 : [ snip ] 1:1 classid 1:20 htb rate 5kbps ceil 10kbps prio 0 : [ snip ] 1:1 classid 1:30 htb rate 8kbps ceil 11kbps prio 2 : [ snip ] 1:1 classid 1:40 htb rate 23kbps ceil 40kbps prio 1 : [ snip ] 1:1 classid 1:80 htb rate 8kbps ceil 10kbps prio 4 You are configuring HTB to guarantee exactly 64kbps to the children classes. - Leaf class rate is guaranteed. HTB does not check parent classes. This may be non-intuitive or even counter-intuitive. - Your rates, then total 64kbps: 20 + 5 + 8 + 23 + 8 = 64 Perhaps you could try dropping the guaranteed bandwidth (sum of rates of leaf classes) below 60kbps. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Route policy preference value
Ming-Ching, :http://linux-ip.net/html/routing-selection.html#routing-selection-adv : : Ghee a simple illustration will explain it much better than : such a train of words. Well...in that case...how do you feel about my pseudo-code locomotive? You may well be right--I sometimes have a tendency to be verbose. I'll see what I can do to imagine an accurate and intuitive diagram. Thanks for the feedback, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tables and default
Hello Sandro, : * 1 adsl (ppp0) : * 1 more tables in rt_tables (200 ping) called bluff All OK! : * table 'bluff *has not* a default route This is the problem. :[EMAIL PROTECTED] root # ip ro li table bluff :192.168.5.0/24 dev eth1 scope link : : * ip rule add from 192.168.5.2 table bluff prio 50 : :[EMAIL PROTECTED] root # ip ru li :0: from all lookup local :50: from 192.168.5.0/24 lookup bluff :32766: from all lookup main :32767: from all lookup default : : Now I would think that pinging from 192.168.5.2 outside the LAN : should not work and in fact: : : [EMAIL PROTECTED] root # ip ro get 62.207.143.51 from 192.168.5.2 : RTNETLINK answers: Invalid argument : : but if I try I can flawlessly get out. First thing--I don't know why you are seeing this error from 'ip route get'. This should return the real route chosen. You could always try the ping and then check the route cache. This should help you identify the actual route chosen. Here's what's happening. - kernel gets packet and needs to select a route - according to rule 0, we look up in table local - perform route lookup in table local--no match! - according to rule 50, we look up in table bluff - perform route lookup in table local--no match! - according to rule 32767, we look up in table main - perform route lookup in table main-- MATCH! - route packet out default gateway If you add a route to table bluff as follows, you should effectively prevent 192.168.5.0/24 from reaching any network other than 192.168.5.0/24. ip route add blackhole default table bluff Now, any packets addressed from 192.168.5.0/24 will be blackholed. This may not be quite what you desire, particularly if packets addressed from 192.168.5.0/24 are created by your own router, so you could always say: ip rule del prio 50 from 192.168.5.0/24 table bluff ip rule add prio 50 from 192.168.5.0/24 iif eth1 table bluff Then again, you don't describe your network completely, so I could be steering you wrong here. And by the way, unless you have some very strange (but not inconceivable) routes on your hosts inside the 192.168.5.0/24 network, you won't need to specify the route 192.168.5.0/24 dev eth1 scope link in table bluff. : Is this related to SNAT? In my opinion that should come : afterwords since SNAT in in the POSTrouting chain. Nope! No SNAT problem here! -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB classifying
Hello Mpourtounis, : When i start downloading from node, its http taffic for examle is : really shaped at 50. When i start downloading via sftp (port 22), : its sftp traffic is really shaped at 30. But, if when there is an : http as well as an sftp session at the same time, total bandwidth is at : 80. You are missing one key piece in your understanding of HTB and that is the difference between using rate and using ceil. : /sbin/tc qdisc add dev wlan0 root handle 1:0 htb r2q 100 : /sbin/tc class add dev wlan0 parent 1: classid 1:10 htb rate 50 : : /sbin/tc class add dev wlan0 parent 1:10 classid 1:11 htb rate 30 : /sbin/tc filter add dev wlan0 parent 1:0 protocol ip prio 100 u32 \ : match ip src 192.168.2.224/32 \ : match ip sport 80 0x classid 1:11 : : /sbin/tc class add dev wlan0 parent 1:10 classid 1:12 htb rate 50 : /sbin/tc filter add dev wlan0 parent 1:0 protocol ip prio 100 u32 match \ : ip src 192.168.2.224/32 classid 1:12 You have a class structure which looks roughly like this: class 1:10, rate 50 [ ceil 50 ] | +-class 1:11, rate 30 [ ceil 30 ] (rate M) \ class 1:12, rate 50 [ ceil 50 ] (rate L) Because you have specified a rate in each leaf class (1:11 and 1:12), your two leaf classes are getting the guaranteed 'rate'. You have guaranteed rate M, 30 (units???) (seems to be 37500bps with my tc) to your class 1:11. You have guaranteed rate L to your class 1:12. HTB will dequeue packets entering this class until rate without examining any other parent class. Because each class is getting its guaranteed rate, HTB is effectively transmitting (dequeuing) packets at 80 (30 + 50). I believe you wish to do the following. Note that I have used the same ratios, but have eliminated some zeroes and changed the units, but simply for readability. class 1:10, rate 500 kbps, ceil 500 kbps | +-class 1:11, rate 100 kbps, ceil 300 kbps \ class 1:12, rate 400 kbps, ceil 500 kbps Thes means that classes 1:11 and 1:12 can transmit up to rates 100 kbps and 400 kbps respectively before HTB starts to calculate borrowing. For more on the borrowing model, see [0], [1] and [2]. The rule you are unwittingly violating is this rule [3]. In short, since HTB will not check any rates or perform any shaping or borrowing until rate is met (exceeded), you must make sure that the sum of the rates of your leaf classes does not exceed the parent classes. As a final note, if you wish to limit your total outgoing bandwidth to only 50 and let HTB help a bit with the borrowing, I would recommend the following model: class 1:10, rate 50, ceil 50 | +-class 1:11, rate 10, ceil 30 \ class 1:12, rate 20, ceil 50 Best of luck, -Martin [0] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#hsharing [1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb-borrowing [2] http://opalsoft.net/qos/DS-28.htm [3] http://www.docum.org/docum.org/faq/cache/13.html P.S. Just a reminder that with the command line tc, kbps means kilobytes per second. If you want to talk about kilobits per second, use kbit. -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Newbie question - RPDB, policy routing etc...
Greetings Rajkumar, : I am going through the LARTC howto to understand how the iproute2 : works. But some concepts like Policy Routing, RPDB etc are not clear : to me. I am pretty new to iproute, beeing using route command for : long... : : From what I understand : : 1. rules (ip rule) tell how to select packets for routing and route (ip : route) tell where to route the selected packets. Rules can do a few different things: - most significantly, a rule (in the RPDB) can select a routing table based on the characteristics of the packet - a rule can rewrite the source addresses on (outbound) packets - a rule can be of type blackhole (effectively drop), prohibit (ICMP prohibit) or unreachable (ICMP unreachable) : 2. A collection of rules is RPDB The collection of rules is the routing policy database (RPDB). : 3. Policy routing is routing using rules. In linux-think, yes, policy routing requires the use of rules (RPDB). In more general terms, policy routing is a technique of routing based on characteristics of a packet other than the destination address, which is the only selection criteria in conventional routing systems. : 4. rules can specify a packet on various parameters, like source dest, : fwmark, interface etc... True enough. I have written a little bit about the RPDB [0], but you may find that Matthew Marsh's policy routing book is a good resource [1]. And if you need a crash course in how linux selects a route [2]. : 5. route can tell only dst interface or next hop. [ diagram and description snipped ] : I hope my dig is legible. This is what I want to do. I would much : appreciate if some one can give a clear picture as to how iproute : works. I tried to understand what you were trying to do, but found myself confused. Perhaps you don't need policy routing? Anyway, best of luck...try describing the problem again, and maybe it'll be more obvious to me (and others?) next time around. -Martin [0] http://linux-ip.net/html/routing-rpdb.html http://linux-ip.net/html/ch-routing.html [1] http://www.policyrouting.org/ [2] http://linux-ip.net/html/routing-selection.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ISP users limit BW
Diego, : First, sorry about my english. I work in a ISP and I need a BW control. : I have users with 512 256 and 128 kbits services. I use a Linux Redhat : 7.1, but I am working in a new Server. I think building a new server for this service is a great idea. : So, what do you think that can I use for BW control ??? I'd recommend tcng [0]. : Now, I use RSHAPER, very easy and very stable, but I have 2 problem: 1- : Only download control and 2- is fixed, I put only the top BW. I have : about 150 users. What can I read ?? Thank you for all, and sorry about : my english. Regards, So, tcng [0] is Traffic Control Next Generation, and represents an effort to simplify the complexity involved with the configuration of the traffic control system. The language developed for tcng is clear and intuitive IF you understand the traffic control system. There are several resources for learning about traffic control techniques under Linux. My introduction [1] provides a starting point, after which the LARTC HOWTO is fruitful [2], and finally I'd recommend several additional sources of information, such as Leonardo Balliache's pages [3] and Werner Almesberger's tcng manual [4]. If you decide you would like to try using tcng and HTB together, I have a more hand-on document which may be useful [5]. Good luck! -Martin [0] http://tcng.sourceforge.net/ [1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/ [2] http://lartc.org/howto/ [3] http://opalsoft.net/qos/DS.htm [4] http://linux-ip.net/gl/tcng/ [5] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Several interfaces same gateway. Arp flux problem? Any idea?
the same
hardware address mapping for a given IP address, not the least significant
of which could be that they are all handled on a single device. Really,
this is immaterial to your machine.
By the time the kernel is looking up the link layer address of the gateway
IP, it already knows the output interface. This is why for purposes of
sending packets (frames), you can have the same IP and/or link layer
address occur on multiple interfaces, and there's no problem.
Your problem is answering for IP1 only on eth0 and IP2 only on eth1. This
is exactly the reason for the hidden patch.
: There are a lot of question without answers, I couldn'f find them:
:
: Should I remove the dafult gateway?
Which one? You have many default routes, one in each routing table.
Try:
for rtable in cablemodem{1,2,3} ; do
echo -e \n[ -- $rtable -- ]
ip route show table $rtable
done
: If I should, how could I make the router itself to reach internet?
Conventional rules for source address selection apply. [1]
: Maybe marking locally generated packets and assigning a route to that
: fwmark? I tried this, but no success.
Your lack of success is not surprising.
Locally generated packets and marking for output route selection has been
discussed many times on this list. There are probably other solutions,
but it seems that the netfilter -j ROUTE patch-o-matic target is the ideal
solution to this problem. [2]
: When I run this in my script
:
: ip ro add 62.42.a.b dev eth2 src 62.42.yy.yy
: RTNETLINK answers: File exists
Probably because the route already exists, created by the kernel when the
device came up. I wouldn't panic at all about this.
: Ok, thats, because both devices use the same gateway, and so, I suppose
: a shouldn't univocally bind that address to any? Correct?
I'm not sure what you mean.
Best of luck!
-Martin
[0] http://linux-ip.net/html/ether-arp.html#ether-arp-flux
[1] http://linux-ip.net/gl/ip-cref/node155.html
[2] http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-ROUTE
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Newbie question
Aravind, : I am new to this mailing list. My doubt is Is it possible to mark QOS : bits in IP header using tc? I marked using iptables. I saw your post on linux-diffserv as well. I wonder if you have yet found Leonardo Balliache's pages on using DiffServ with Linux. [0] With all good luck, this will be the jumpstart you need. If not, try Werner Almesberger's slightly denser papers. [1] -Martin [0] http://opalsoft.net/qos/DS.htm [1] http://www.almesberger.net/cv/papers.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] iproute2 and ethX:X subdevices
Alan, : Quick question -- is it possible to create eth0:0 - style : psuedo-devices using the 'ip' tool? They aren't really pseudo-devices, but we understand what you mean. In the days prior to the iproute2 tools, when a device would have one interface, which would have one IP address, they were called IP aliases. : I see they recognise them when using 'ip addr show': : : 5: eth2: BROADCAST,MULTICAST,ALLMULTI,UP mtu 1500 qdisc pfifo_fast qlen 1000 : inet 192.168.0.1/24 brd 192.168.0.255 scope global eth2:0 : : But I can't see a way of creating them. Is it possible? The answer is yes, there is a way to create interfaces using the ip address tool, so that they are recognizable to ifconfig. You are looking for the label keyword to the ip address add command [0]. : (I know somebody may say why would I want to -- it's just for : neatness, so that people using 'ifconfig' can still see all the : addresses in use.) I know exactly why an administrator would wish to do this. Some administrators, who a) have not joined the 21st century with Linux, or b) do not commonly use Linux, but rather other UNIX-like operating systems, may not know about the ip utility, but they certainly know about ifconfig! So, if only for the humans, this can be helpful. -Martin [0] http://linux-ip.net/html/tools-ip-address.html#ex-tools-ip-address-del -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs
Aron, I do not understand your network. In a prior note, I thought I understood that you had multiple serial (T1) interfaces. If you have multiple interfaces, then your statement about having one physical WAN interface is misleading. You may have only one T1 card (physical device), with several logical interfaces (for example, wan0, wan1 ...), which is not an uncommon configuration. Anyway, I don't understand your network, so cannot help. Please give ip addr and a small ASCII netmap. : The scenario I am working on is the second one - there is one internal : network and two ISPs. Then you have two WAN interfaces? : How can I do fwmark based on the outgoing interface? iptables -t mangle -A POSTROUTING -o wan0 -j MARK --set-mark $wan0_mark iptables -t mangle -A POSTROUTING -o wan1 -j MARK --set-mark $wan1_mark : Remember that there is just one physical WAN interface, with two IP : addresses. Is it possible to fwmark somehow based on the routing : decision? I'm not sure. Maybe somebody else can pick up that question. It's certainly possible to use -j ROUTE based on the fwmark, though [0]. I don't really think that will be required in your situation, but I won't know until I understand your network better. Best of luck, -Martin [0] http://netfilter.gnumonks.org/documentation/pomlist/pom-extra.html#ROUTE -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs
Aron,
: If I understand whay you are suggesting, there is a problem in your
: design: It will only work if you use Hide NAT.
...and multiple public IPs.
: The problem is that the ip_src == IP0 rule is wrong: The ip_src is not
: changed by the router and it is not equal to the IP of any of the
: machine interfaces.
OK--maybe the 'ip_src == IP0' rule is not applicable to your situation,
but that doesn't make it wrong. You describe a different network
configuration than I was envisioning based on Gordan's description.
: Can you think of a solution that will work in the following reasonable
: scenario:
I can try!
: Lets say I have two T1 internet connections connected to one ethernet
: interface. I do not use Hide-NAT. I want to guarantee at least 512kbps
: to HTTP traffic on each line (separately) in the 'virtual circuit'
: method that you mentioned.
Are you pushing different networks across each T1? If you have Network-A
from ISP-A and Network-B from ISP-B, then you have different addresses to
use in your configuration.
See an untested configuration with some fabricated addresses and netmasks
below.
#define NETA 216.109.118.64
#define NETAMASK 28
#define NETB 63.209.4.192
#define NETBMASK 27
dev eth0 {
egress {
class ( $neta ) if ip_src:NETAMASK == NETA/NETAMASK ;
class ( $netb ) if ip_src:NETBMASK == NETB/NETBMASK ;
htb () {
$neta = class ( rate 512kbps, ceil 512kbps ) ;
$netb = class ( rate 512kbps, ceil 512kbps ) ;
}
}
}
I would think this should provide a skeleton configuration for limiting
outbound (transmitted) traffic originating from separate IP networks on
the same host.
: I see no way do do this unless I can attach a qdisc to a specific
: virtual interface.
If you are using a single IP network and you have two different providers
(you're using BGP or similar), then you could consider marking the packets
(fwmark) based on outgoing interface, and perform traffic control based on
this mechanism.
These are just some thoughts based on how I interpret your description of
your network.
Good luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Shaping Device Aliases
Gordan,
I've noticed that you are trying to use aliased IP addresses and traffic
control together, and you are a bit frustrated that tc doesn't handle
aliased interface names.
: I understand that device aliases (e.g. eth2:3) are not shapeable.
: Does anybody know if this functionality is planned in the future?
:
: None of the new(er) networking tools recognise device aliases,
: because on all recent linux releases, aliases don't exist.
: the ethX:X notation is a legacy notation used only by the ifconfig
: program. everything else just sees a ethX with more than one IP
: address.
:
: So you just run your shaping rules on the real interfaces, and
: restrict it's operation with IP address filtering.
:
: Yes, I am aware of that. However, that makes shaping multiple
: independent streams going through one interface much more difficult.
I don't understand why this becomes much more difficult--it just becomes a
little more difficult, depending on the number of IP addresses you have
active on a given interface. If you can handle multiple addresses on an
interface, then shaping traffic on these (known) addresses shouldn't be
much more difficult than managing each address.
: The only other thing I can think of is setting up a dummy network
: device and giving it the IP addresses on all the non-primary subnets
: (e.g. multiple DSL lines), and setting up the arp and routing to make
: the packet actually go via the primary interface.
This sounds like a very confused idea. I'm not sure it's worth the
hassle--as I hope I can convince you below.
[ more stuff snipped ]
: Has anybody got any thoughts on this?
I have some thoughts, which I hope can help you understand why you will be
able to use the traffic control tools to accomplish your filtering. For
posterity, I'll reiterate some of what has come before.
IP aliases don't exist. This is a convention for ifconfig. ip addr
show will display all IP addresses active on a given interface.
Traffic control is the last thing performed before turning the packet over
to the device driver and hardware. Similarly, it is the first thing
called on receipt of a packet. See diagrams KPTD [0] and ebtables packet
flow [1].
In this case, you can use any number of techniques to identify the packets
with tc tools based on their IP addresses--the convenience of the aliased
interface naming is simply an obstruction of the real path the packet
takes.
: If this would work, maybe it should be documented in the advanced
: routing howto, as I can see how there might be a lot of people out
: there who would find it useful.
Let me suggest a possibility, if we assume a nested configuration. Let's
say you have IP0 and IP1 active on interface eth3 and you want to make
sure that bandwidth is split 75/25 between these two and you want them to
share bandwidth. Classic bandwidth-sharing situationin the tcng
config below, you'd need to #define IP0 and IP1, but then you'd have a
simple configuration. If you needed to further subdivide traffic within
each of the IP0 and IP1 classes, you'd have an easy way to do so.
dev eth0 {
egress {
class ( $ip0 ) if ip_src == IP0 ;
class ( $ip1 ) if ip_src == IP1 ;
htb () {
class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */
$ip0 = class ( rate 1024kbps, ceil 1544kbps ) ;
$ip1 = class ( rate 384kbps, ceil 1544kbps ) ;
}
}
}
}
Alternately, you may wish to simulate virtual circuits with each of the IP
addresses on a machine. In this case, you could use separate root
classes attached to the HTB qdisc, or another class. You can prevent the
two classes from competing with each other by setting the rate and ceil to
the same value. Here's a very simple permutation of the above.
dev eth0 {
egress {
class ( $ip0 ) if ip_src == IP0 ;
class ( $ip1 ) if ip_src == IP1 ;
htb () {
class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */
$ip0 = class ( rate 1024kbps, ceil 1024kbps ) ;
$ip1 = class ( rate 384kbps, ceil 384kbps ) ;
}
}
}
}
Best of luck, Gordan!
-Martin
[0] http://www.docum.org/stef.coene/qos/kptd/
[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tncg and bandwidth limiting
Scott,
: Basically ignore that last message.
Earlier message ignored.
: I'm trying to do some very simple rate-shaping on an interface. I want
: to limit my 100baseT interface to 7 megs both ingress and egress of the
: interface.
You'll notice that Rubens suggested you use a TBF. This would be
perfectly adequate solution for your transmitted traffic. Note that an
HTB class and a TBF qdisc are essentially performing the same function.
Shaping!
Note there is a difference in the traffic control structures created by
your tcng configuration. Your egress section will actually be two HTB
classes inside an HTB qdisc attached to the INTERFACE in question. In
your situation, you do not need both classes (created as siblings), since
you are classifying everything into class $all.
: I'm curious if some of the other experts out there wouldn't have a
: better way to do what I'm doing. I'd like to do HTB ingress as well,
: but it complains that the the ingress qdisc doesn't allow inside
: classes or something like that. I think this will work for me, I just
: want to make sure this is the best way to do things.
This is a limitation of traffic control under Linux. You can only shape
what you transmit [ see IMQ if you want to know how to break this rule ].
So, unless you are going to use IMQ, you'll not be able to shape your
local input traffic (if you are a router, you should be able to slow down
conversations by artificially delaying the packets on the internal
interface).
However, you don't need to care that you are not shaping on your inbound
traffic. You can police the traffic. For the difference between shaping
and policing, try here [0].
[ snip ]
:htb () {
: class ( rate 100Mbps, ceil 100Mbps ) ; /* remove this */
: $all = class ( rate 7Mbps, ceil 7Mbps ) ;
:}
: ingress {
:$p = bucket(rate 7Mbps, burst 100kB, mpu 200B);
:class (1) if (conform $p count $p) || drop;
: }
After you run your tcng config file through tcc (tcc $FILE | less),
you should see (lines broken for readability) the following for the
ingress traffic control. I left INTERFACE in the config file--obviously
you have #defined it someplace else.
tc qdisc add dev INTERFACE ingress
tc filter add dev INTERFACE parent :0 protocol all prio 1 \
u32 match u32 0x0 0x0 at 0 classid :1 \
police index 2 rate 875000bps burst 102400 mpu 200 action drop/pass
^^
Note that the policer will (somewhat harshly) accommodate your desires to
limit the traffic accepted inbound on an interface.
Best of luck,
-Martin
[0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-shaping
http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-policing
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Bandwidth Control Tolerances
Hello Patrick, Please excuse my suggestion if you have already considered the issue I indicate below from Stef's FAQ. : I have measured the performance of HTB with iperf and found it to be : very close to expected (i.e., within 5%). I have a colleague who is : measuring the performance by ftp'ing large files and recording the time : required to make the transfer. He is seeing an average throughput that : is nearly 10% away from the theoretical, with occasional excursions to : nearly 30%. How have you defined your PSCHED_CLOCK_SOURCE? See this URL: http://www.docum.org/stef.coene/qos/faq/cache/40.html : My colleague is now questioning the quality of the traffic control : algorithms and wondering two things: Let's be careful with the baby and the bathwater. The algorithms have been vetted. The implementation may not be ideal, but implementations always suffer from compromises, right? : 1) What tolerance can we guarantee and advertise? Measure the deviations from your specified bandwidth after changing your setting for PSCHED_CLOCK_SOURCE. Advertise your measured tolerance accordingly. : 2) Can the tolerance be improved, since the values he has measured are : unacceptable? I don't know--see the above link, and check how your kernel was compiled. Others on this list may have further suggestions for you. Good luck, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB - default class is used only
Hello Dan, : i have very simple script to control upload in network with 3 IP : addresses. Problem is, that rule for default class is used only and : filtering by IPs doesn't work. I am going to guess that this is a masquerading or SNAT host. Is this accurate? : I have RH9 with kernel 2.4.20-24.9, htb script starts without errors, : iproute-2.4.7-7.90.1 installed (shouldn't I uninstall iproute and : install iproute2?) RedHat calls the iproute2 package iproute. It has the tools you need--tcalthough, I believe their RH9 iproute package is not patched to handle HTB. I imagine, though that you must have figured this out already if you are generating the below output. You appear to be adding your HTB mechanisms to one interface, eth0. This means that you are shaping traffic transmitted outbound on eth0. You are not shaping any traffic received on eth0. Do you have another interface on the machine? I presume that your other interface is the external or Internet-facing interface. This is the interface on which you should add the HTB classes for shaping upload traffic. Is this also a masquerading (SNAT) box? If so, the source IP address will no longer be 192.168.1.0/24 but rather the public IP on your box. You'll need to use marking. You may benefit from my HOWTO [0]. Just remember that you can only shape what you transmit, and readjust your installation accordingly. -Martin [0] http://www.tldp.org/HOWTO/Traffic-Control-HOWTO/ -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Changing default route for an entire subnet/NIC
Brian, : Oops, made a mistake in my example, : I actually enter : ip rule add from 192.168.0.0/24 table John : : As soon as I do this, that subnet loses all contact with my firewall, : so it can't DHCP an address, do DNS servers, ping, anything.. Perhaps what you wish to do is copy the entire main routing table to the table John [0] and then change the default route in that table. Try: # copy_routing_table John # ip route change table John default via $OTHER_GATEWAY This is a simple application of policy routing. Another possibility is to exclude 192.168.0.0/24 from the rule itself: # ip rule add from 192.168.0.0/24 table John # ip rule add from 192.168.0.0/24 to 192.168.0.0/24 table main You may wish to consider adding the prio keyword explicitly. See also some documents I have written in which I attempt to explain the policy routing system in plain terms [1]. Good luck, -Martin [0] http://linux-ip.net/html/scripts/copy-routing-table.sh [1] http://linux-ip.net/html/ch-routing.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] pptp, vpn traffic control
Hello Doug, : Before I got your message I spent a couple of hours reading chapter 9 : of the how to at lartc.org. The HTB option makes sense in concept to : me... Rightgood...LARTC doc is quite good, though occasionally dense. : Can you provide some example syntax for me given the following... I'll refrain until you have a more fully-formed scenario. Since you are new to Linux traffic control, let me suggest that you consider using tcng (I'm a big fan--it's much more human-legible than raw tc syntax). See my tcng and HTB HOWTO [0]. [ snip ] : As I understand it the HTB works by limited the 'outgoing' data and not : the incomming data and the limits will be placed on the ppp sessions : and not the eth0. Premise: You can only shape what you transmit [1]. (Yes, exceptions to this rule exist.) : How do I make the limiting start when the ppp session comes up? Good question.this will probably require some glue code. Shell, perl, whatever you like. Others may have better suggestions. In short, the traffic control structures inside the kernel are static--they can be manipulated (added/removed), although my impression (and my own usage) relies on creating a static traffic control configuration. Regardless, if you can hook into an ip-up or if-up script on your PPTP server, then you can write raw tc commands which create the traffic control structures (and iptables, hint...hint) for each connection. : I'm using Rethat 9 with kernel 2.4.20-8. Retchhat? (I never stop with the teasing, do I?) If you choose to use tcng, you may end up needing dsmark. That's easy with RedHat boxen in the post 2.4.20 world. modprobe dsmark works very well. Almost everything you'll need is built as a module for your use. You will, however need a custom tc. I have a now-outdated SRPM you can use as a template for rebuilding against the recently issued iproute errata package [2], or you can use the binary provided by Martin Devera (author of HTB) [3]. -Martin [0] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ [1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/rules.html [2] http://linux-ip.net/traffic-control/iproute-2.4.7-7.src.rpm * [3] http://luxik.cdi.cz/~devik/qos/htb/ http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz * You can use this as an example, but please understand that it is grossly out of date. If you don't know how to build SRPMS, just skip it and grab Martin Devera's tc. -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] general shaping recommendations
Damion, : I am wondering, what is the best way to do some 'generic shaping' on a : firewall/gateway box. Currently, I'm just running a wondershaper : variant on the WAN interface. htb qdiscs for outbound, and ingress : policer for inbound. The wondershaper is well-designed for the standalone box connected to a DSL link. You can also use it (usually) very well on a masquerading box, but if you want to do fancier things, you may wish to consider ditching wondershaper entirely. : Now, assuming most traffic (except DNS requests etc) goes through the : firewall, I could shape on the LAN side as well. In a conventional masquerading firewall situation, - shaping on the LAN interface will shape your usage of download bandwidth (inbound packets). - shaping on the WAN interface will shape your usage of upload bandwidth (outbound packets). : Should I put htb qdiscs on WAN as well as LAN and not use any ingress : policers ? or should I use them as well? There's no reason not to use ingress policers if you wish. I would recommend, however, shaping on both the inbound and outbound traffic. : tc qdisc add dev ppp0 root handle 1: htb default 20 : [ snip ] classid 1:1 htb rate 512kbit burst 6k : [ snip ] classid 1:10 htb rate 512kbit burst 6k prio 1 : [ snip ] classid 1:20 htb rate 460kbit burst 6k prio 2 : [ snip ] classid 1:30 htb rate 409kbit burst 6k prio 2 : : Will the slower queues be able to borrow extra bandwidth from the : faster ones (when they're not in use), or do I need to specify the : ceiling parameter to allow that? I'm fairly certain that the above is not what you desire. When you specify a rate in a class, that class will ALWAYS consume up to that available amount of bandwidth before checking to see if the parent has any bandwidth to lend. So, you will want to change this. I think this is probably closer to what you wish to do, although your numbers may be different. [ snip ] classid 1:1 htb rate 512kbit burst 6k [ snip ] classid 1:10 htb rate 256kbit ceil 512kbit burst 6k prio 1 [ snip ] classid 1:20 htb rate 96kbit ceil 460kbit burst 6k prio 2 [ snip ] classid 1:30 htb rate 96kbit ceil 409kbit burst 6k prio 2 Look at the sum of the rates of the children classes, this is class 1:10 1:20 1:30 $ expr 256 + 96 + 96 448 This means that if all three classes are going full bore, you'll use 448kbit. When a class reaches its rate, it will try to borrow tokens from the parent class (rate=ceil=512kbit). The parent will dole out the tokens to each child class which requests tokens in quantum increments. Maybe the diagram I drew will help you [0]. Once a child class (which is now exceeding rate) reaches ceil, it will cease attempting to borrow tokens and will buffer/delay packets (this is the shaping effect). Nota bene: A child class will simply consume bandwidth until it reaches its specified rate. Only after reaching the rate will the class begin to consult the parent class and (potentially) delay packets. : I'm a bit unsure of the default behaviour of the htb qdisc. I don't know if my explanation will help, but check out my description of the HTB model [1]. Be sure to read Martin Devera's description [2], and also consider Stef Coene's documentation [3] and tests [4]. His tests show how bandwidth is distributed/allocated under various conditions--essentially these graphs provide a good way to understand the behaviour of HTB. -Martin [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/diagram.html#d-general [1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb [2] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm [3] http://www.docum.org/stef.coene/qos/docs/htb/ [4] http://www.docum.org/stef.coene/qos/tests/htb/index.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] pptp, vpn traffic control
Don, : I want to set up some traffic control and don't know where to start... I'll copy my own comments from the LARTC FAQ (o-Matic) [0]. [ begin from FAQ ] In addition to the lartc.org HOWTO itself, I'd suggest some introductory readingfirst my own traffic control overview (and some links to other documentation): http://tldp.org/HOWTO/Traffic-Control-HOWTO/ http://tldp.org/HOWTO/Traffic-Control-HOWTO/links.html An alternative introduction is Leonardo Balliache's pages: http://opalsoft.net/qos/DS.htm Werner Almesberger's still relevant implementation overview of 1999 warrants (and rewards) careful study: http://www.almesberger.net/cv/papers.html http://www.almesberger.net/cv/papers/tcio8.pdf Once you have an understanding of the entire traffic control system, the easiest way to some practical configurations is with the tcng software: http://tcng.sourceforge.net/ The tcng software reads a structured configuration file, where the tc command line utility is documented in parts of documents all over the 'net. [ end from FAQ ] I'd suggest my Traffic Control HOWTO and Werner's pages for you until you have a rough idea of the entire system. Once you understand the system, head over to the LARTC site [1] to get some detailed help on what commands to use. Also never forget that Stef Coene has a large set of pages [2] which detail HTB and traffic control generally in an excellent fashion. : (ie: Each user connects to the VPN server then connects netmeeting from : point to point using the private ip that the poptop pptp vpn assigns : each client) Neat idea. : Netmeeting will use up as much bandwidth as it can. (As I understand : it) So will a bulk file download. ;-) : I want to be able to restrict each vpn tunnel to xk (where xk might be : 128kbits or less). You'll probably want to use an HTB tree with a child class where rate=ceil=128kbit for each of your clients...but you'll probably get some ideas of your own as you familiarize yourself with the tools. : I also want to be able to stop users from using any ports on the vpn : tunnel other than the ones required by netmeeting and port 80. Use iptables. The iptables tutorial [3] will help you here. : I have read all about compiling kernels but I still haven't got this : sused. This makes no sense to me. What means this verb sused? Is that what happens when an admin leaves, dropping a lousy old crufty SuSe box in your lap? ( I've been Sused! ?? ) In seriousness, though, what distribution and kernel are you using? It is likely if you have a recent installation that you have everything you need already (with the possible exception of an HTB-capable tc). -Martin [0] http://www.docum.org/stef.coene/qos/faq/cache/ http://www.docum.org/stef.coene/qos/faq/cache/46.html [1] http://lartc.org/ http://lartc.org/howto/ [2] http://docum.org/ [3] http://iptables-tutorial.frozentux.net/ -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Source routing two services in the intranet
Hello, : This solution above has a drawback. If i have to provide a different : service on a different computer in the internal network I can't, since : every package that reaches the linux router is being redirected to the : same computer in the internal network. Assume that besides the web : service in 192.168.100.10-192.168.100.17 (IP alias used here) we want : to to provide ssh service on 192.168.100.20-192.168.100.21 and want to : source routing both services in the linux. I believe that to solve this : i need to operate with iptables and iproute together and DNAT the : requests according to the port it is addressed to. It seems that : iproute by itself cannot do that. But to accomplish this i thing that a : solid knowledge of how the packages traverse the kernel is necessary : and that is what I am not sure about. So I would really appreciate if : anyone could help me write the iptables and iproute rules for the : example just mentioned. That would be a great help. With regard to describing how a packet traverses the kernel, you will find the KPTD and docum.org very helpful [0]. I would also suggest considering (for your described application of the technology) that you look at the --ctorigdst conntrack patch to netfilter [1]. -Martin [0] http://www.docum.org/stef.coene/qos/kptd/ [1] http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.3 Try googling for ctorigdst also! http://www.google.com/search?q=ctorigdst -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Newbie HTB shaping question
: As you can see from the command and wget output i limited the : outgoing bandwidth to 100kbps but i am still getting 1Mbps. Is : this what I am supposed to get or did I do some thing really stupid? : : yes, you limit the outgoing bandwidth,.. not the incomming ;) What Jan is suggesting is that you might not understand what you'll need to understand to get the shaping working as you desire. [ I assume your Internet connected router is a Linux box. If that's not accurate, then just assume where I say Internet connected router that I'm saying the router/bridge you are using to shape Internet-bound traffic. ] It's key that you understand that shaping only functions correctly on transmitted packets (frames), so you'll need to make sure that you are shaping the packets forwarded from your Internet connected gateway onto the LAN. This means that the gateway may well have the packet(s) already, but it delays transmitting them to meet a certain bandwidth. Shaping your outgoing traffic, which is mostly very small TCP ACK packets, will do little to shape the much larger packets on the download side of the stream. Check out the rules I have written [0], the rules that Stef has written [1], and maybe a tidbit about shaping [2]. Now, do you understand why you need to shape the packets transmitted from your Internet connected router to your internal hosts? -Martin [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/rules.html [1] http://www.docum.org/stef.coene/qos/faq/cache/9.html [2] http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-shaping -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] mangle
Whoa!! Back up the truck! : Check for the Kernel Packet Traveling Diagram at: : http://www.docum.org/stef.coene/qos/kptd/ : : Please note that this diagram is not valid for iptables. I think I disagree. : When using iptables, packets that are traversing the linux box : (forwarded trafic) do not go thru the INPUT and OUTPUT chains. The KPTD hosted on docum.org certainly does accurately reflect the traversal of iptables. Please send corrections if you find something wrong with the KPTD. This was a collective effort by Leonardo Balliache, Stef Coene, and some others on this very list. It doesn't depict the relationship between iptables and bridging, but that is a well-known exception to this diagram. : You'll find an iptable packet traversal diagram at : : http://www.knowplace.org/netfilter/packet_traversal.gif This is a fine picture, too, though, Ron. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] bandwidth lang
Eddie, : Well the thing is I need to learn bandwidth management,fast. : Well I've read a few stuff but the thing is,as I understand,there is : lots of ways and languages to use,cbq,htb ens.What is the best and you : now of a howto just for that specific one? This gives some references: http://www.docum.org/stef.coene/qos/faq/cache/46.html I'd recommend learning tcng and using HTB...here's a slightly more hands-on document I have written: http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Split bandwidth equally per IP
Hello all (again), : ESFQ allows this to be per ip address, which solves the problem. : : I have not seen applications that grab many ip addresses for a single : host, although this is possible. Would WRR be a better candidate for Mihai's problem? I have no experience with WRR. Others? -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Split bandwidth equally per IP
Hello Mihai,
: Can you post a real script using esfq, that splits the bandwidth
: equally per IP?
I wish I had an example script to lend you
To my recollection your issue was an obnoxious piece of software which was
generating many outbound flows. This sort of a technique should prevent
any single IP from dominating your bandwidth (without your allowing that
domination):
tc qdisc add dev $LAN_DEV parent $HTB_CLASS handle $ESFQ_HANDLE \
esfq perturb 10 depth $UNIQUE_CLIENTS hash dst
This attaches an esfq qdisc to the class which contains competing
workstations/users for download bandwidth (in your environment).
Reminder! We have already deNATted (is that a word) the inbound packets,
so the destination is the real workstation IP, and the
Here's the help string [from the README]
Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]
[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]
Where:
HASHTYPE := { classic | src | dst }
I'd agree that the easily available documentation for ESFQ is minimalI
would love to remedy that, so let me know how your experimentation with
the qdisc goes. In your case, I'd suggest starting with a hash dst.
When I cautioned about Jon Zeeff's patch [0], I didn't necessarily mean to
scare you away from it. It may be a very good patch--I simply wanted to
point out that there already exists a tool to solve the problem you
appeared to need to solve. Note also the recent list activity (by
Chijioke Kalu) with regard to kernel-2.6 and ESFQ [1].
Also, the section of my text (from tldp.org) you quoted was specifically
about the very same download accelerators which were giving you fits.
These tools simultaneously create a large number of TCP connections for a
single application-layer function (usually fetching a large file) in order
to (attempt to) defeat per-connection byte-rate limits. The design of SFQ
did not anticipate this deliberate flooding attempt. ESFQ takes a step
toward correcting this.
Again, I don't know if ESFQ will solve your problem--I hope it does, and I
hope to hear a report from you that this was the tool you needed.
Best of luck,
-Martin
[0] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010919.html
[1] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010939.html
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Split bandwidth equally per IP
Hello, : In fact letting HTB calculate itself the burst parameter, and : hard-coding the quantum parameter for each leaf class (as Stef : suggested), made the traffic shaping much more accurate than it was : before. (especially the quantum settings 1500). That Stef guy! Always making good suggestions. : I will make the changes in sch_sfq.c and keeep you all informed with : the results. Achtung! There is already an esfq qdisc [0] which does this! This patch may be a good one, but since esfq already exists, perhaps you could try that instead. -Martin [0] http://www.ssi.bg/~alex/esfq/index.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Bandwidth and traffic priotization and throttling
Good morning, Leon, : I'm trying to setup my server to bandwidth control. Where we live : bandwidth is very expensive and we need to closely monitor it. We'll : buy 512kbps and this will have to be shared between 4 companies. Thus : giving everybody a minimum if 128kbps but it must be burstable to : 512Kbps if availible. It is absolutely possible to do this. I would recommend using HTB (for bandwidth shaping and sharing) in conjunction with tcng (for easier configuration). I have an article [0] that covers this combination in particular, although you'll still need to gain an understanding of the system before you can work with these tools [1]. : Can you please give me a good article or howto, explaining the steps : required. I'd suggest starting with the links describing the entire traffic control systetm [1], and then read the more specific content. Don't forget to consult (search through) the LARTC archive [2] and Stef Coene's pages [3]. : I'll have 4 network cards for internal traffic and 1 for the internet. : Can I set bandwidth throttling per network card? Yes. Absolutely. -Martin [0] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ [1] http://www.docum.org/stef.coene/qos/faq/cache/46.html [2] http://mailman.ds9a.nl/pipermail/lartc/ [3] http://docum.org/ -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Routing problem !!!
Hello again, : Martin, as you can see in my last post i have route to 10.0.0.1 in the : main routing table , so i have ping to the gateway but i can't connect : to inet. OK. So, you can ping the gateway.can you ping the gateway from the source IPs you want to have Internet access? But, before we cover that, we need to back up to the Why? question. You don't explain enough for me to understand why you need the second routing table. In looking at your two routing tables, I don't see any reason for two. : #ip r l t main : 10.0.0.0/16 dev eth0 scope link : : : The only way to connect to inet is adding: : : ip r a default via 10.0.0.1 t main : : If i add the default gw in table main , i can connect to inet but i'd : like to do this in other table. I have some questions, then: - Are the packets initiated from the Linux box? - What is the source IP on a packet which is not leaving the box in the manner you desire? Can you add an ip rule to define the characteristics of this packet? - Are you trying to force packets to be sourced from a particular IP? - Are you trying to block particular packets from getting to the Internet? : Can you help me ? I'll most certainly try. : eth0: 10.0.0.2/16 : eth1: 10.0.0.1(inet gateway) : : #ip ru l : : : 0: from all lookup local : 32765: from 10.0.0.2 lookup tabla1 : 32766: from all lookup main : 32767: from all lookup default : : : #ip r l t tabla1 : : : 10.0.0.0/16 dev eth0 scope link src 10.0.0.2 : 127.0.0.0/8 dev lo scope link : default via 10.0.0.1 dev eth0 : : #ip r l t main : : 10.0.0.0/16 dev eth0 scope link [ snipped some of my earlier ravings ] -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Where have my all my TC filters gone??
Hi there Robert,
: I have snipped out part of a script to load balance and bandwidth shape
: upload traffic to a NIC (eth0/ETH_WAN) on a 2mbit/256kbit ADSL line.
: The balancing will be carried out for 3 users with 1+ PCs connected on
: another NIC. There are iptables instructions (not shown in the script)
: to mark packets based on PORT and TOS. These are snipped as the marking
: appears to work its just the TC FILTERs that just disappear :-(
They should be there.the command you posted just doesn't ask the
kernel the question which would show your filters!
: Stef (or anyone else :-) can you please explain why:
:
: # tc filter show dev eth0
: #
Try tc filter show dev eth0 parent 1:1 and tc filter show dev eth0
parent 1:10. This should present you with your filters.
: shows no filters are in place on eth0 after running the script below???
If no handle in particular is specified in the tc filter show dev $DEV
command, then the default (root) handle 1:0 is displayed.
: Is this a problem with having a 2-level deep HTB class tree?? When my
: HTB tree is only 1 level deep the TC filters get fed back properely
: with the above command!!
:
: BTW I don't get any errors when running the script from a CLI.
[ snipped stuff ]
: tc filter add dev $ETH_WAN parent 1:1 protocol ip prio 1 u32 match ip src ${ROB_IP}
flowid 1:10
: tc filter add dev $ETH_WAN parent 1:1 protocol ip prio 1 u32 match ip src
${DAVE_IP} flowid 1:20
: tc filter add dev $ETH_WAN parent 1:1 protocol ip prio 1 u32 match ip src
${MIKE_IP} flowid 1:30
Here you'll see that your script is attaching these filters to handle 1:1,
and below
: tc filter add dev $ETH_WAN parent 1:10 protocol ip prio 1 handle 1 fw classid 1:11
: tc filter add dev $ETH_WAN parent 1:10 protocol ip prio 2 handle 2 fw classid 1:12
: tc filter add dev $ETH_WAN parent 1:10 protocol ip prio 3 handle 3 fw classid 1:13
: tc filter add dev $ETH_WAN parent 1:10 protocol ip prio 4 handle 4 fw classid 1:14
: tc filter add dev $ETH_WAN parent 1:10 protocol ip prio 5 handle 5 fw classid 1:15
: tc filter add dev $ETH_WAN parent 1:10 protocol ip prio 6 handle 6 fw classid 1:16
your script attaches these filters to 1:10! This means that you'll only
be able to see them if you explicitly list the filters attached to this
handle.
This doesn't really solve your problem, thoughin order to solve your
problem, (I think) you should be able to alter the handle on all of your
tc filter statements to 1:0. Then try running your script again.
That should put you much closer to your goal.
Good luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Upload restriction problem
Joel, : Is this list is died? or any one dont want to help. No, the list is not dead. Yes, there are people here who wish to help. So get in the queue and have some patience. : I am facing problem in restricting upload traffic on fake ip address : 10.0.0.0/8 network. I can easily restrict upload traffic on my real ip : address. : : eth0 --wan port connected to internet : eth1 --lan port connect to local network : : my script on eth1 is working properly bcoz it is for downlink traffic OK. Fair enough. : this is the script which is having problem. : : tc qdisc del dev eth0 root : tc qdisc add dev eth0 root handle 1: htb : tc class add dev eth0 parent 1: classid 1:1 htb rate 80kbit ceil 80kbit quantum 1514 : ### Fake ip address : tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10kbit ceil 15kbit quantum 1514 : tc qdisc add dev eth0 parent 1:10 handle 10 pfifo limit 2 : tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 10.2.5.15 flowid 1:10 When you say fake IP address, I presume you mean an RFC 1918 address, which is not routable on public networks. If so, then you should probably read Stef Coene's FAQ note about this very situation [0]. : ### Real ip address : tc class add dev eth0 parent 1:1 classid 1:11 htb rate 20kbit ceil 25kbit quantum 1514 : tc qdisc add dev eth0 parent 1:11 handle 11 pfifo limit 2 : tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src x.x.x.x flowid 1:11 I presume that the x.x.x.x is a public IP address you are calling the Real ip address. : This scipt can restrict the upload for Real ip address but Cant : restrict upload for Fake ip address. : I have checked this by # tc -s -d class ls dev eth0 Have you tried watching tc -s -d class show dev eth0 at the same time as you are watching tcpdump -nn -i eth0 host 10.2.5.15? Do you see any packets leaving your box with a source address of 10.2.5.15? If not, then you should be able to figure out what you need to do. : tc filter cant match fake ip address ?? Well, frankly, tc filter only deigns to match on real addresses of transmitted packets*. And please don't tap the glass. This generally leads to irritated beasts. -Martin [0] http://www.docum.org/stef.coene/qos/faq/cache/59.html * This is humour. -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] TOS Header
Alan, : I notice the ultimate traffic shaper script suggests using: : : tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ : match ip tos 0x10 0xff flowid 1:10 : : To find high-priority SSH etc traffic by matching on certain flags in : the TOS header. Frankly, it only finds packets that an ssh implementation (at least openssh) has marked as interactive. Even telnet marks packets as interactive with a TOS value of 0x10. : However, I was under the impression that the TOS header is no longer : used, instead replaced by DSCP. Is this correct? No. I'd recommend a tcpdump to prove this to yourself. Or you can examine mine [0]. But see also PSIkappa's corrective note that clever users will create ssh tunnels to get the 0x10 TOS for non-interactive traffic as well [1]. If you want to read an interesting story about ssh and TOS from last year at about this time, see this note in the archive for a great introduction to the sorts of troubles that TOS-mangling can bring with it [2]. The DSCP is a mark a packet receives as it enters a DiffServ domain. There is no pretension (as with the TOS bits) that other network providers are going to honour the DSCP bits. In fact, I would be rather surprised if a network provider using DiffServ failed to strip off (or replace) the DSCP on all inbound packets. : If so, does the above command actually work? I've certainly not found : it to be a particular improvmeent, nothing like the improvement I get : if I match on dport 22. I've found that the above command works for me, although you appear to have missed the important TCP dest (or src) port match in your example. tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ match ip dport 0x16 0x \ match ip tos0x10 0xff \ flowid 1:10 I imagine that was just an oversight on your part. : Is it possible to do similar matching on the DS header? Does anybody : have a reference for what the DS header contains? I'm rather confused : about what it is and whether it's of any use. I've found the IANA DSCP : header allocation list, but the codes given don't mean anything to me I presume you are talking about this site [3]. Well, be prepared for a little mountain of reading if you want to understand the DiffServ architecture. I find Leonardo Balliache's pages an excellent introduction to DiffServ under Linux [4]. -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2002q4/006145.html [1] http://mailman.ds9a.nl/pipermail/lartc/2002q4/006146.html [2] http://mailman.ds9a.nl/pipermail/lartc/2002q4/005640.html [3] http://www.iana.org/assignments/dscp-registry [4] http://www.opalsoft.net/qos/DS.htm -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [LARTC]Routing problem !!!
: This is my configuration: : : : eth0: 10.0.0.2/16 : eth1: 10.0.0.1(inet gateway) : : #ip ru l : : : 0: from all lookup local : 32765: from 10.0.0.2 lookup tabla1 : 32766: from all lookup main : 32767: from all lookup default : : : #ip r l t tabla1 : : : 10.0.0.0/16 dev eth0 scope link src 10.0.0.2 : 127.0.0.0/8 dev lo scope link : default via 10.0.0.1 dev eth0 : : #ip r l t main : : 10.0.0.0/16 dev eth0 scope link [ local routing table snipped ] : why can't i connect to inet ?? Probably because your router doesn't have a way to send packets to 10.0.0.1 even if the source address on the outbound packet is 10.0.0.2. Add one more route to tabla1: # ip route add 10.0.0.1 dev eth1 table tabla1 # ip route change default via 10.0.0.1 dev eth1 table tabla1 Once you can ping 10.0.0.1 from your policy routing device, then you should be able to hit the Internet from the same device. You didn't explain anything about what applications or functions this box hosts, so there's nothing more to say here. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] interface making
Hello Cheongseng, : before this, when we want to setup the gateway to provide QoS. we need : to go though LARTC, follow the step configuration. finally, we need to : write the config. file using bash. then we execute the file to complete : the setting, m i rite? The process is very much like this, although the exact procedure depends on the nature of the tools you are using. : i suggest to make this complex steps more easier. how i make it?? i m : trying to make a form using JAVA, that form is for the adminstritor to : control the traffic. for example, : : at the beginning the adminstritor set the http higher priority. after : some times, he want to make charging. the adminstritor must have some : knowledge about the LARTC only he able to make the charging. because he : must charge the value in the config. file and execute it again. To my knowledge, this is true now, and to a certain extent cannot be otherwise. Here's what I mean. Each traffic control structure created in the kernel is static, and would require changing a configuration file or setting. To minimize the administrative hassle of running a traffic control device, you could use the tcng language [0]. This provides a much more approachable way to discuss and manage traffic control systems. The tcng distribution comes with some good example configuration files, but you can also consult a HOWTO I have written [1]. : if we make a form to replace all this jobs. when we make changes in the : form, then the value in the config.file will be change follow the value : inside the form. It sounds to me as though you wish to have a form front end (D/HTML) which allows an admin to configure the traffic control system on the fly. There would doubtless be quite a niche market for this sort of an interface on the traffic control system. I certainly wouldn't want to tackle this job. : the adminstritor can make the charges by using the form. then the QoS : will become more user friendly, am i rite?? QoS is not a particularly user friendly topic, though, because of the complexity of the systems involved. Not only does the administrator need to understand how burstiness and latency can be affected by different QoS mechanisms, but this same person needs to understand a great deal about the contents of IP packets. I'd suggest examining tcng to see if it meets your needs for sufficiently demystifying traffic control under Linux. Good luck! -Martin [0] http://tcng.sourceforge.net/ [1] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Coding for Linux Traffic Controller
Hello Kalaiselvan, : I am trying to do Linux Traffic Controller. I am struggling how to : start how to proceed. Help me in sample codings or some useful linux : web sites. I'd suggest some introductory readingfirst my own traffic control overview (and some links to other documentation): http://tldp.org/HOWTO/Traffic-Control-HOWTO/ http://tldp.org/HOWTO/Traffic-Control-HOWTO/links.html An alternative introduction is Leonardo Balliache's pages: http://opalsoft.net/qos/DS.htm Werner Almesberger's still relevant implementation overview of 1999 warrants (and rewards) careful study: http://www.almesberger.net/cv/papers.html http://www.almesberger.net/cv/papers/tcio8.pdf Once you have an understanding of the entire traffic control system, the easiest way to some practical configurations is with the tcng software: http://tcng.sourceforge.net/ I have a few annotated examples of tcng configurations available: http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ There are quite a few lurkers here who use tcng and will help you out as you get your feet wet. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Coding for Linux Traffic Controller
Hi again, Kalaiselvan, : I am trying to do Linux Traffic Controller. I am struggling : how to start how to proceed. Help me in sample codings : or some useful linux web sites. It occurs to me that you may mean you wish to write your own queuing discipline. If so, you'll find the resources at the University of Kansas QoS research site quite handy [0]. If you are doing this, I'd still recommend all of the reference material I pointed out in my earlier mail [1]. -Martin [0] http://qos.ittc.ukans.edu/ [1] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010850.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] newer iproute2: no support for ip link set dev $DEV promisc on
Greetings all, I have tried to find a discussion of the removal of support for the PROMISC interface flag with the iproute2 tools. - it used to work (iproute2-2.2.4-$ANCIENT) - there's a comment about it in the iproute docs [0] - (un-)setting the flag with ifconfig still works Can anybody point me to the discussion (linux-net, maybe?) where support for setting the PROMISC flag was pulled from the ip utility. I'd like t understand a bit better why this is so. Thanks for any answers, -Martin [0] http://www.detached.net/ip-routing/ip-cref/node10.html -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
