Re: [LARTC] general shaping rules
On Saturday, 15 October 2005, at 20:29:20 +0200, Jorge Sanchez wrote: Any router performing a shaping function should be the bottleneck on the link, and should be shaping slightly below the maximum available link bandwidth. This prevents queues from forming in other routers, affording maximum control of packet latency/deferral to the shaping device. In the Internet, traffic flows through a number of router between source and destination, routers you can not control. In the router closest to your network (if using ADSL, the local telephone witching central with DSLAM adapters) sometimes the ISP or telco applies buffering to each subscriber. That is, to get tranfer rates up it is very easy to allocate and indeterminate (but usually large) buffer for incoming traffic. This way, when you download at full speed you get, well, full speed, but the telco is getting more data at a rate greater than you can, so it buffers traffic in excess. So, if the sending box somewhat slows down (network congestion), your telco still has data to send and keep your line 100% full. So statistics show you get a fantastic service bandwitdh wise, but not so good with respect to latency. The only way to prevent those buffer to even start filling is shaping traffic to/from your network some Kbps bellow your nominal maximun transfer rate. You have to be the bottelneck to be able to control bandwidth allocation and keep latency to a minumun. Hope I made an understandable explanation. Greetings, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.14-rc3-git7) signature.asc Description: Digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Traffic Balance
On Friday, 01 October 2004, at 20:26:55 -0300, [EMAIL PROTECTED] wrote: list members: if u don?t wanna help, dont disturb! damn god! everybody here know that LARTC tutorial to load balance is incomplete! From the information provided by the original poster it doesn't seem very clear that he knows the existence of lartc.org, or maybe he has not done any kind of searching for information regarding what he is supposed trying to achieve. With respect to the completeness of the LARTC tutorial, Bert is always willing to take patches and additional documentation from contributors. Have you submitted _any_? Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.9-rc1) signature.asc Description: Digital signature
Re: [LARTC] ARP daemon
On Monday, 09 August 2004, at 14:51:55 +0200, Damjan wrote: What I want to accomplish is deny the possibility of users changing their IP address, once its set. Then make it impossible for users to become root or equivalent in their boxes, to prevent them from changing their interfaces MAC addresses. This way users won't be able to do so, and even in the event they try to boot with some sort of live Linux CD and change the MAC, this change won't persist after reboot. If you prefer/need to control this changes from your Linux box, then you can play with iptables and its mac match (to bind together IP/MAC pairs) or install arpwatch. The latter won't prevent users from (maybe) succeeding in their attemps to gain access to places where they shouldn't be allowed to go, but you will be inmediately notified if someone is not playing nice in your network. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.8-rc2-mm2) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: [ANNOUCE] iproute2 update
On Tuesday, 08 June 2004, at 18:42:46 -0400, [EMAIL PROTECTED] wrote: That does makes sense for entering data, however, for display of results, they need to be in one format. That of units, their use and meaning is a common topic at some places, including linux-kernel. There seems to be several international standards with respect to units, both base-2 (2^n) an base-10 (10^n). Maybe you have around units(7), a man page that gives a bit of information on the subject. In my opinion, data should always be shown correct, that is, 1048576 will be eiher 1024 kibi (1024 Ki), or 1048.576 kilo (1048.576 k), but not anything else. The possible change in suffixes could break existing scripts in a (hopefully) minor way, but changing rate specification in tc should be thought for longer, the breakage here can be important. Just my two euro cents ;-) -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.7-rc1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] routing with multiple uplinks problem
On Monday, 24 May 2004, at 09:44:43 +0200, Rafal Krzewski wrote: +-+ +-+ |actaea | eth0 |ilex | | 192.168.1.4 |-- localnet --| 192.168.1.1 | +-+192.168.1.0/24+-+ eth1 / | ppp0 80.72.34.162 83.31.149.159 / | wlnettpsa 80.72.34.160/24 | / | +--+ ++ | 80.72.34.161 | | 213.25.2.3 | +--+ ++ \ / \---, / +--+ \ |salix |/ Internet | 212.87.7.182 |'-, ,- +--+ I want ilex to respond to any incoming trafic on 80.72.34.162 address (it is running a DNS server). All outgoing trafic from localnet should go through tpsa link (faster but non-static IP). Resposnses to the latter should also return through tpsa link. For the localnet traffic to exit your premises through tpsa you must route this traffic through 213.25.2.3 as next hop with outgoing device ppp0. You _must_ SNAT this traffic to 83.31.149.159, this way return traffic will always come back from the Internet trhrough this same link. after running: ip route del default ip route add default via 213.25.2.3 localnet traffic flows fine, BUT ilex no longer responds to pings from salix on 80.72.34.162 address The problem seems clear to me: your routing table at ilex will only have entries for the directly connected networks and the default route you have just show. So every traffic coming from a network different from the local connected ones will get routed through the default gateway. Maybe traffic arrives at its destination, but in its way back gets routed along a different path (asymmetric routing) and is dropped or lost somewhere. 4. What I did to diagnose the problem: Tried pinging ilex from salix tracing the traffic with iptables -j LOG (settings below). I'm able to see ping request packets, but no ping response packets. I also tried monitoring the trafic with ethereal, both on the virtuall 'all' interface, and also on each of the physical interface (well, ppp0 isn't actually physical, but you get the idea) in promiscous mode. Only ping request packets are visible. I think tcpdump or ethereal is the way to go. Try to detect the traffic from its source to its destination, and at each point see if packets are as expected with respect to IP addresses. It seems traffic arrives OK at ilex but this box doesn't reply to this traffic, whether this is ICMP or even TCP connections (ssh). Put a tcpdump/ethereal on the incoming interface, note down IP addresses and ports (if applicable), and then have a look at: http://www.docum.org/stef.coene/qos/kptd/ Try to depict the path the traffic would theoretically follow inside the kernel paying attention both to iptables rules as well as the routing policy database (both ip rules and ip routes). Traffic should end up being received by the kernel, and a reply should come back. Even if it is not the case the kernel should log something, check with dmesg. ilex:~# ip rule show 0: from all lookup local 32764: from 213.25.2.3 lookup tpsa 32765: from 80.72.34.161 lookup wlnet 32766: from all lookup main 32767: from all lookup default ip rules 32764 and 32765 will only apply to traffic with source IP addresses as shown, but not to traffic coming through any of the associated routers (except this routers also do SNAT to traffic coming from the Internet). So packets from salix (212.87.7.182) will be routed looking first at table local (the one that should apply to traffic ending at ilex itself), and then loooking at table main. The good thing about table local is that should be ok with no administrator intervention, so the problem must be somewhere. I apologize for not reading and checking the whole email to see if I find the problem, but I am convinced this is a simple problem with routing. The strange thing is traffic arriving at ilex, but this box no replying back to the source. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.6) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Dual Redundant Network routing [Question]
On Tuesday, 18 May 2004, at 13:36:21 -0700, Daniel Chemko wrote: If you're rolling your own, the most well used technique to detect a dead link is pinging static hosts located on each network segment. Since you are dual-redundant of the same network, you'll need top do a little source routing. If you have a ping with the -j or the -I options, you can cheat and socket bind ping to each physical network segement to test the common IP's. In the past I have implemented a Linux policy router with link failure detection, but instead of pinging a remote host I use hping to make a TCP connection request to a remote IP at port 80. If this remote IP address is known to be always up (for example, www.google.com's IP) this can be a good level-7 health check. Yo can do this from the router itself on any number of links. Just make sure you understand Linux policy routing, and just before sendind the probe packets make them go trhough the link you are trying to test. Couple the above with a state machine to prevent considering a link down when just one probe fails, and to make a link up again when it has been so for long enough. Once you detect a failure, you need to handle the outage. This can be done with marking a route dead or changing the default route to the other interface. This shouldn't be too hard. In my setup I have a routing table for each link to the Internet, each table with just a default route to the Internet through this link. So when I detect the link has gone down, I just make a ip route change table linkX default via ... to reroute all traffic to another link. Hope this helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.6) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Real IP behind SNAT
On Tuesday, 27 April 2004, at 09:13:58 -0500, Nelson E. Castillo wrote: Internet (gateway) | | | eth0 = real IP - L I N U X ROUTER - eth1 = private IP | | | eth0 = real IP - Wireless Access Point - I was asked to put a real ip (not to do static NAT) in the Ethernet interface of the WAP. How can I do it? I suppose the real IP you have to assing to your WAP ethernet interface is in the same range as the real IP address assigned to the external interface of your Linux router. I think you can set up a proxy ARP entry on this Linux router for the real IP to put on your WAP. The external interface in the Linux router will reply to ARP requests with its own MAC address, and will receive the incoming traffic. Then you must have adequate routing entries to direct traffic going to the internal real IP address through the internal (private) interface in the Linux router, and hopefully it will arrive at the WAP. The best way to avoid missing something in the process of configuring everything is to take a paper and a pen, and draw the path of the IP packets through your network. Do everything as the operating system would do, and do what is needed to make packets arrive at the correct place in your network. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] First Post: Question on Ip Aliasing
On Thursday, 08 April 2004, at 06:53:27 -0700, Discussion Lists wrote: I did a google search on this and didn't find exactly what I was looking for. Suppose I have a machine that has an IP alias eth0:0. I have set up HTB.init so that it properly throttles bandwidth on eth0, however when I use eth0:0, it doesn't work. I read elsewhere that it should work at the PHYSICAL device layer, and should therefore work for both at once. This is not happening though. Just wanted to find out if I think that the hack of alias interfaces in Linux has been one major source of conceptual problems with respect to Linux routing and the like in past years :-). I have always believed that it is much better to think of IP addresses in Linux as assigned to physical interfaces rather than associated to some kind of a virtual one. The ip address show command shows very clearly this fact. Each interface has zero or more IP addresses assigned to it, and with ip you will never see alias interfaces again, because this tool is modern enough to understand the fact. I encourage everyone to make the move to ip from old ifconfig and related tools as soon as possible. In the ip world you just have physical (or not so physical, like bond? or VLAN interfaces) interfaces and IP assigned to them. And when you want to refer to IP addresses, you just use them. And when you want to refer to interfaces, use the one you need. Also, have a look at the Stef Coene's excellent KPTD at: http://www.docum.org/stef.coene/qos/kptd/ Couple the above diagram with the previous explanation about IP and interfaces and maybe all will now be simpler to you. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Private Address Routing via Tunnels
On Monday, 02 February 2004, at 11:26:48 +, Alan Ford wrote: They can route from the public to the private blocks, because they get to the router and the router knows to send it down the IPIP tunnel. But how can I configure the router at the other end to know to send responses from the private block to the public block down the tunnel? I think that's what I am needing to do here, does that make sense? Traditional routing is always based solely on the destination IP address of packages arriving at a router. With Linux policy routing you can route based on both destination and source IP address, and based on more parameters, for example, any parameter selectable via iptables. The router on the other end already has a working routing table based on both information from IP addresses for each interface and static routes you should have added manually. If the router on the other end doesn't know how to route packets back to the other router , then the routing table on the distant router is not correct. As the two internal networks are far away and connected by a tunnel using public IP addressing, I guess what is missing in the remote router is a route that sends traffic directed to the other private network through the tunnel. Exactly the same you seem to have done on your local router to make traffic directed to the remote LAN be encapsulated through the IPIP tunnel. Just for completeness, in this setup I don't think policy routing (based on source IP addresses) is the correct way to handle the problem. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.2-bk3) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Private Address Routing via Tunnels
On Sunday, 01 February 2004, at 17:09:39 +, Alan Ford wrote: My problem is routing from *public* addresses on network A to *private* addresses on network B, or vice versa. (Private - private is fine). The routing table on both gateways apply to all traffic that arrives to them, so if traffic from one gateway's private network can reach the other remote private network correctly, I think the same should happen to the public IP ranges from both networks. The IPIP tunnel should encapsulate whole packets inside newly created ones, which will be using public IP addressing, in fact the tunnel is working nice because you can reach from one private network to the other. You should try to troubleshoot the problem with the usual tools, for example ping, traceroute, ip route get, tcpdump, ethereal, telnet, etc. Try to see the path that take your packets, maybe they are not being tunneled, maybe there is a route missing from some router, maybe just a typo prevents it from working. Am I right in that assumption? If so, is policy routing the way to go there, or is there some other way? I don't think your setup needs policy routing to work ok, so first check routing tables and do some tests to see where packets go and die :-) Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.1-rc3) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc classes limit
On Friday, 30 January 2004, at 19:40:44 -0300, Gerardo Arceri wrote: What's the limit on number of traffic classes (classid) you can define on Linux ? Digging in the source code of Linux kernel 2.6.1 it seems that internal data structures for the classful queuing disciplines use a u32 (unsigned 32-bit long integer) to store the class ID. Maybe there is a lower limit around there though. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.2-bk3) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] iproute2 and Kernel 2.6
On Thursday, 18 December 2003, at 13:47:48 -, Remus wrote: I have a linux box with three NICs (two for external ISP, and one local). Today I tried to use 2.6.0 kernel and somethings is wrong because iproute2 does not work corretly. No routed packets go via second ISP NIC. With 2.4.22 kernel I have no problems at all with packet routing. If I recall correctly, this same issue popped up on the list some time ago, and I seem to remember that the fix was as simple as to recompile iproute2 agains current (2.6.0) kernel sources. As a hint, Debian Sid iproute package works by default on 2.6.x kernels. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Traffic shapper and bridge
On Tuesday, 09 December 2003, at 16:01:44 -0600, Viaris wrote: The university is like a ISP to give access to Internet to several faculties, but we want to restrict the traffic, we needed a traffic shaper to do this, I wanted to have something like (Packeteer INTEL NETSTRUCTURE 7370 aplication server) which it is a bridge where I not need IP for my networks cards. First, don't try to compare a high-end product from Packeteer to what you are able to achieve with Linux + iptables + tc + l7-filter + brctl + ebtables + whatnot. Maybe hacking these and some more utilities together you can get something similar to the commercial product, but maybe you should take into account some other things apart from technically feasible. A recent Linux kernel compiled with bridge support, patched and compiled with with ebtables (iptables for bridges), plus ip/tc, plus userspace ebtables, plus l7-filter, plus quite a bit of configuration, plus a good and fasta hardware, plus many spare hours to configure and maintain everything is all what you need. Try to be more specific, although the feature in Packeteer's products of behave transparently when the box fails is not something you can do with Linux, as far as I know. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test10-mm1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Aliases and Multipath
On Thursday, 04 December 2003, at 11:06:58 -0400, Guillermo Gomez wrote: Does anyone know if i can use ethernet aliases like eth0:1 in advanced routing like multipath routing in order to avoid to have nxEthernet interfaces in my Linux box. I think it is always better to think in ip terms instead of in ifconfig terms with respect to multiple IP addresses assigned to the same network interface. I don't know exactly for ifconfig, but the syntax for ip address states clearly what seems to be happening behind the scenes: # ip address add 172.16.1.1/24 broad + dev eth1 # ip address add 172.16.2.1/24 broad + dev eth1 # ip address add 172.16.3.1/24 broad + dev eth1 So what you are doing is assigning several IP to the same physical interface, and you deal just with IP, anything else. # ip address show dev eth1 2: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:05:1c:09:f2:14 brd ff:ff:ff:ff:ff:ff inet 192.168.1.12/24 brd 192.168.1.255 scope global eth0 inet 172.16.1.1/24 brd 172.16.1.255 scope global eth0 inet 172.16.2.1/24 brd 172.16.2.255 scope global eth0 inet 172.16.3.1/24 brd 172.16.3.255 scope global eth0 Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test10-mm1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] mangle
On Monday, 08 December 2003, at 15:39:48 +0200, Eddie wrote: I have a linux gateway box,eth1 internet and eth0 lan Now I made my qdisk for eth1 but now I want to mark them with iptables. The thing it I dont now wht to use,-A FORWARD or PREROUTING? Check for the Kernel Packet Traveling Diagram at: http://www.docum.org/stef.coene/qos/kptd/ You will see very clearly the path of packets traversing your Linux box, and will be able to know the exact place where to mark traffic. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test10-mm1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] mangle
On Monday, 08 December 2003, at 17:18:52 +0100, Ronnie Garcia wrote: Please note that this diagram is not valid for iptables. I think you did not interpret the diagram correctly. For iptables you will have to focus just on the BLUE boxes with the CAPITAL names, and forget about the lowercase ones, that are for ipchains. And each packet entering the box will follow just one path, and this path is determined after the routing stage: any packet going through the box (neither generated nor destined to it) will go the path on the right, though the FORWARD chain of iptables. From then on the travel is simple to follow. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test10-mm1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc and kernel 2.6.0
On Wednesday, 26 November 2003, at 15:12:16 +0100, [EMAIL PROTECTED] wrote: I successfully used the latest tc tool (version 3.12) with a linux 2.4 kernel. Now I switched to 2.6.0 and had the problem that I could'nt define any queues with tc. Do I need to download a newer version or is there anything like a patch? I have used tc in Linux kernels 2.6.x without problems, using the iproute package that comes standard with Debian Sid. This package contains a compiled version of iproute-20010824, maybe just a recompile against current 2.6.x headers is what you need. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test10-mm1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb rate 30mbit not working
On Wednesday, 12 November 2003, at 02:48:26 +0100, Damjan wrote: Anyway you can run 2.6 its not that bad. There was a report some time ago about HTB not shaping to the specified bandwidth in 2.6.x when traffics consists of small-sized packages. See: http://bugzilla.kernel.org/show_bug.cgi?id=657 This supposed bug has yet to be acknowledged by some developers. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test9-mm2) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Question about iptables and maximum file size
On Friday, 31 October 2003, at 12:15:54 +0200, The Codrinus wrote: I would like to know if there is any possibility to select from iptables the files with maximum size of 300 kbytes and send them to a proxy server. As I know until now you can only mark files with maximum size of 64 kbytes. iptables only knows about layer 2, 3 and 4. Files and their sizes is a layer 7 thing, and depends entirely on the application protocol used to transfer them (SMB, CIFS, NFS, FTP, HTTP, SSH, etc.). So the short answer is no, you can't select packages based on file sizes, it doesn't make any sense. But you obviously can select IP packages based on their size (match length). However, remember that MTU in normal layer 2 networks, typically ethernet, have a value of 1500 bytes, so I think in normal conditions you will not see any packages larger than that (except if you use jumboframes, FR or the like). -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test9-mm1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 10Mbit on HTB
On Saturday, 11 October 2003, at 20:01:04 +0700, Kristiadi Himawan wrote: I want to try to shape 20-30Mbps traffic using HTB. It's possible? Anyone already try this? Very well possible, and you don't need great hardware for this, if you don't have a rather complex classification scenario. Just for the record, in the middle of some network performance test for some sort of appliance I capped outgoing speed to 25 Mbps on my PIII 600 MHz with a 3Com 100 Mbps card, and the box barely spends 1-2 % of CPU transmitting at full speed (full = 25 Mbps). Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test6-mm4-lirc) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 10Mbit on HTB
On Saturday, 11 October 2003, at 21:28:10 +0700, Kristiadi Himawan wrote: Below is the script: [snipped] The script seems correct, and very similar to what I use, except I don't even need to set up a filter to direct traffic, because in my tests I just need to limit the output to some speed. When i try to shape 20Mbit, there's dropped packet but i see the bandwidth not shaped to 20Mbit. But when shape to 10Mbit, i see the bandwidth down to 13Mbit. Some time ago there was a report from someone who tried HTB in 2.5.x kernels and saw a strange behaviour. For details, check: http://bugme.osdl.org/show_bug.cgi?id=657 In short, it seems bandwidth limiting behaves strange for different outgoing packet sizes. Regards. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test6-mm4-lirc) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IP Failover
On Tuesday, 30 September 2003, at 08:40:12 +0300, Andrew Kozachenko wrote: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN Ugh !. Please configure your mail client to send outgoing messages only in plain text, preferably wrapped at 75 characters or less. Thank you. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test5-mm3) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Simple PRIO + TBF at high rates
On Tuesday, 23 September 2003, at 19:02:21 +0200, Javier Martin wrote: I'm trying to slow down http traffic on Gigabit link. The outbound rates on that interface range 0 .. 400 Mbit/s and I would like to throttle accurately to any rate between these while keeping non-http traffic unthrottled. What I do is to create a PRIO qdisc with the 3 usual bands (default prio mask) and a 4th band with a TBF attached with the desired rate. Like this (for 300 mbit/s): Well, I am in no way an expert, but it seems to me that you could use simply HTB on your outgoing ethernet link, create a class with rate equal to ceil and equal to the greater bandwidth you will ever HTTP allow to eat. Create another class to be the default one and let it grow up to your link's bandwidth borrowing from HTTP traffic when there is not 400 Mbps of them. Then create a couple of filters to send traffic to the correct classes and, maybe, attach a sfq qdisc to your HTTP and default leaves to guarantee fairness for individual connections. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test5-mm3) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] source-based-routing
On Monday, 08 September 2003, at 11:50:53 -, vadiraj c s wrote: I need information on source-based-routing in detail. Please help in getting this to me as soon as possible. As you are in a hurry, run to http://lartc.org. Period. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test4-mm4) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Classifying IPv6 tunnel traffic
On Monday, 01 September 2003, at 19:25:13 +0200, Thilo Schulz wrote: Currently, I have got an ipv6 tunnel, that has sit0 as interface. Since the Tunnel wrapping stuff is still ipv4 traffic that goes over the ppp0 interface, i wondered whether I can classify this kind of traffic and put into a class. (i dont need to do any ipv6 shaping), So I wondered, whether someone here can give me the filter directive to match these tunnel packets. 6to4 IP traffic (I think this is its name, IPv6 traffic encapsulated into IPv4 packets) can be easily identified. They are regular IPv4 packets, with a protocol field of 0x29, or decimal 41. So use iptables and match packets on protocol. What you can't do (to the best of my knowledge) if going deeper into the packets, and see if IPv6 pakects inside the IPv4 ones are of some kind or another. Regards, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test4-mm4) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] about fw marks on netfilter
On Saturday, 26 July 2003, at 11:56:55 +0700, Rio Martin. wrote: Is it okay if i put many different rules on single mark. iptables -t mangle -A PREROUTING -p tcp -s 192.168.1.0/24 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p tcp -s 192.168.2.0/24 -j MARK --set-mark 1 ... iptables -t mangle -A PREROUTING -p tcp -s 192.168.10.0/24 -j MARK--set-mark 1 What you show is perfectly legal with iptables/netfilter. MARK target just associates some number (the mark) to the packets it applies to, and this mark travels along the (inmodified) packet all its way through the linux kernel (that it, marks won't propagate trough the network, the have just local significance). Don't forget to do iptables --match mark --mark 1 --jump ACCEPT or whatever as soon as possible, because a later --set-mark 2 would overwrite the previously set mark. Regards, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] the difference between kernel ipsec with frees/wan
On Monday, 30 June 2003, at 09:10:32 +0800, Yuan ChunYang wrote: In kenel 2.5.47, ipsec is implemented . Can some body tell me the difference between kernel ipsec with frees/wan? Two implementations of the same protocol suite, IPsec. FreeS/WAN works (at least) for 2.4.x and older kernels, native 2.5.x implementations speaks for itself :-). The seem to interoperate well, though. It seems FreeS/WAN was never accepted by Linus for some reason (sure, there must be a reason :), and for the upcoming 2.6.x kernel some people did a brand-new implementation, included in the standard kernel sources. Native kernel 2.5.x IPsec implementation uses user space tools from the KAME project (*BSD), whereas FreeS/WAN uses its own. You can learn more about IPsec in 2.5.x at lartc.org. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.5.73) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ip utility
On Monday, 16 June 2003, at 14:55:59 +0200, M.F. PSIkappa wrote: Hello, for this purpose is mii-tool. Both mii-tool _and_ ethtool. It seems mii-tool is the old one, and works for some ethernet cards. ethtool is newer (and supposedly better), and works for some ethernet cards. Some cards are tunable with both commands, others with just one of them, others... don't work :-) Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.5.71-bk1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Mark packets based on nexthop?
On Wednesday, 29 January 2003, at 14:35:41 +0200, Anton Yurchenko wrote: is there a patch or a way to mark packets with IPtables marking based on the nexthop for the packet? You can mark packets on the FORWARD chain (mangle table), based on the outgoing interface (there should be a one-to-one association of outgoing interface to nexthop IP). iptables -t mangle -A FORWARD --out-interface eth0 --jump MARK --set-mark 1 Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.4.20-xfsip) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Configuring a redundant ethernet connection
On Thursday, 23 January 2003, at 09:13:10 +, Doug Kingston wrote: It turns out that the bonding driver does indeed handle interface redundancy to two separate switches. Martin was right and the kernel documentation file (networking/bonding.txt) is packed full of useful All I have to say is that you are obviously right, and I hope nobody on this list was fooled by my post. Next time I'll try to be more precise, sorry for the inconvenience :-( -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Configuring a redundant ethernet connection
On Wednesday, 22 January 2003, at 10:07:32 -0600, Martin A. Brown wrote: : I am interested in setting up a host with dual ethernet connections to : the same IP subnet (but different switches) for redundancy. We need : reasonably transparent failover if an interface fails. Linux supports channel bonding which should do what you want. There is little documentation outside the kernel for this, but what documentation exists is very good. This can be found in a linux source tree in the following file: As far as I know ethernet bonding (trunking) is a layer-2 point-to-point thing. So you need compatible bonding implementations at both sides, and every cable in the trunk on each end must go to the same box. The original poster said dual ethernet connections to the same IP subnet (but different switches), so I'm afraid bonding is not an option. Regards, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can I Classify Non-IP Traffic?
On Thursday, 02 January 2003, at 16:40:34 +, Griff@BP3Web wrote: My question is can classify the non-IP traffic? Ideally I'd like to be able create a queue for IPX traffic.I know the tc filters command has a protocol statement but I can't find any information about setting this to anything but ip or ipv6. Well, you seem to be already using iptables and the fw filter to mark and categorize traffic. iptables can also match non-IP protocols, using --protocolo PROTOCOL. You can't go deeper into these non-IP packets, but you can mark them by protocol, using any of the protocols in the /etc/protocols file. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [Fwd: Traffic shaping problem]
On Sunday, 29 December 2002, at 20:04:57 +0100, Andre Meij wrote: (he wrote something, but I was unable to see it due to a broken MUA) Please, fix you MUA configuration and send plain text messages to the list, and everyone here will be able to read your mails. As far as I remember you can configure your Squirrelmail's user setting to send mail in plain text and not HTML easily. Thanks. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Traffic shaping problem
On Sunday, 29 December 2002, at 22:04:28 +0100, Andre Meij wrote: (well, my squirrelmail seems to be working again so this is the final attempt to send a readable mail :) ) Yes, now it works OK :) # both get Stochastic Fairness: tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10 Return: RTNETLINK answers: Invalid argument Maybe you don't have SFQ compiled in your kernel, or available as a loadable module. If any command that sets a sfq qdisc fails, and any other command works, this could be the problem. Or it could be some kind of syntax error, or reference to a non-existent parent. Also remember that standard kernel version 2.4.19 doesn't have support for HTB, if this is what the script is trying to use. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] WonderShaper on LAN link kills to-host speed
On Tuesday, 17 December 2002, at 14:15:39 -0800, Kenneth Porter wrote: What about the ingress policer would do that? As far as I know, inbound traffic (ingress) can only police packets, that is, discard traffic on excess hoping the other end will notice it and slow down a bit. If you want to classify incoming traffic, create classes, attach queuing disciplines, and those nice things available in the outgoing traffic, you must: a) Patch your kernel with IMQ, redirect incoming traffic to it, and treat this device as you would any outgoing traffic, or... b) ...manage bandwidth in the outgoing direction on the other network card attached to the router (if this is a router). I'm sure somebody in this list can explain himslef much better, and provide links to information and example code, but hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB on IMQ
On Thursday, 05 December 2002, at 10:04:23 +0100, Thomas Jalsovsky wrote: could somebody check my IMQ+HTB config? Is it OK? Why am I asking for this? I got kernel panic and I don't know what is wrong in my config/system. Kernel panics are not the consequence of bad configuration on the user or administrator part (except attempts to overflow some kernel buffer to do Very Bad Things (tm)). If the kernel crashes, process the resulting panic() through ksymoops to decode the functions and symbols, and post it to the appropiate mailing list. It will be a bug from some developer, not you :-) Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] CBQ affected by squid?
On Friday, 29 November 2002, at 13:54:17 -, Shane Purtill wrote: The question is that if my http traffic goes through squid then when it is seen by the Linux Traffic Controller (the TC is on the outgoing Interface i.e. the Internet connection, so that it can see the actual bandwidth usage of the outgoing link i.e. we have examined the cache to see f we have it stored and found we need to fetch it) the http packets are wrapped in TCP packets and the TC sees all the http traffic as coming from squid i.e. a connection between Squid and say Yahoo.com, and cannot distinguish which user sent what request as they all seem to be packets with Squid as the source IP address. Is this understanding correct? If not what am I seeing wrong? If this is the case how am I going to share the bandwidth as I state above as all the users on the LAN are being anonymised by Squid before they reach the TC?? Squid is a HTTP proxy, and the behaviour you describe is exactly what it is supposed to do: to proxy client connections. Clients contact the Squid box and ask it a page, and then Squid creates a new page request based on the one from the client, that sends to the final web server. The comunication is from the client to Squid, and from Squid to the real web server. So all outgoing HTTP traffic in the Squid box itself is coming from the squid process, and I don't know if recent Squid versions have some way of signalling the operating system about a way to distinguish traffic coming from one client or another. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] owner based policy routing
On Friday, 11 October 2002, at 09:34:38 +0530, Arindam Haldar wrote: THE SCENARIO: we are connected to 2 isp, both having their large network.. isp A has gateway with ofc network while ispB has satellite gateway hence there are advantages to take specific routes thru specific isp. I suppose this box has three network connections, one to the internal network, and one for each Internet connection. So, for the traffic coming from the internal network, this box is a router. THE RULES DEFINED: 10: from all lookup main ip rule are checked from lower to higher numbers, so once visited table local (prio 0) all your traffic (from all) visits table main. I suppose table main doesn't have a default route of some sort, because that would stop packet routing at that point, turning the rest of ip rule useless. WHAT WE TRIED: we tried using iptables owner based rules marked packets( as one can see in rules above), but it didnt help. iptables -I OUTPUT -t mangle -m owner --uid-owner squid -d 202.0.0.0/8 -j MARK --set-mark 50 but packets were not marked as seen by iptables -nvL -t mangle hence owner based pilicy routing not working If iptable -t mangle -L -vn shows no matches, it can be for two reasons: either destination address doesn't match, or uid-owner doesn't match. I have never used --match owner myself, but a quick try here seems to work, at least for a simple network application. Maybe squid runs as user squid (or whatever), but netfilter sees them as originating from another user, maybe root, maybe no user at all. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.18-586tsc) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Iptables, SNAT/MASQ, Multiple gateways
On Sunday, 29 September 2002, at 22:18:30 -0700, Don Cohen wrote: ip route add default nexthop via $CONN1_IP dev $ETHX weight $X \ nexthop via $CONN2_IP dev $ETHX weight $Y Note that this only shapes outgoing traffic and also relies on your ISPs to NOT do the ingress filtering that they're really supposed to do. Just a note. The above routing doesn't prevent you from applying SNAT/MASQ to the outgoing traffic, at least not when you have an ethernet card for each connection (not the case) and you can know through each one the traffic will go out. So adding another ethernet card and a couple of iptables rules can avoid problems with ISPs filtering alien incoming traffic :) -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] iptable for multiple ip address
On Thursday, 12 September 2002, at 16:54:03 +0200, Juan Antonio Morillas Cerezo wrote: Yes, with iptables you can have more than one IP address for each physical interface, both in local and external places, then you have to add them as aliases with ip, and do some NAT to connect each side, if there are private IPs involved. I would add the following. If what the original poster wants is to somehow give a LAN with private IP addressing access to the Internet using not a simple public IP address, but a pool of them, you easily can. Just create an iptables rule with a SNAT target like this: iptables -t nat -A POSTROUTING --out-interface $WAN_IF \ --jump SNAT --to-source $START_PUB_IP-$END_PUB_IP The only limitation I see with this approach is that IP addresses must be contiguous, but I think this is a typical scenario, because our ISP tend to give addresses in blocks :) Hope this helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Content based Routing
On Thursday, 12 September 2002, at 23:07:46 +0800, Andrew J. Barbara wrote: Just a quick question... Is there a way to do content based routing (i.e. routing based on a TCP or UDP port) without using iptables, i.e. using the ip command? It doesn't seem to be possible with just ip, as neither ip rule nor ip route have selectors for transport-level port. But you have ipchains/iptables to mark packets and ip to route them based on the mark put on them. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 4 nic advanced routing question
On Tuesday, 10 September 2002, at 12:34:10 -0400, Michael T. Babcock wrote: I'm not sure why you're having a problem: His document was encoded properly ... Yes, multipart/alternative, but I think what the reader was trying to say us that the ASCII version of the email seems to include some kind of ASCII-art that depicts the sender's network. But at least in my email client the drawing seems broken and gives no clues about topology. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] imq0 not being detected
On Sunday, 08 September 2002, at 09:37:18 +1200, mdew wrote: HTB init, kernel part version 3.6 HTB: need tc/htb version 3 (minor is 6), you have 10 As the messages say, it seems like a version mismatch between the kernel an userspace (tc) side of HTB. Get HTB3 from: http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz The tarball includes two patches, one for the kernel and the other for tc (as well as a precompiled tc binary): -rw-rw-r-- devik/devik 53438 2002-05-25 11:15:45 htb3.6_2.4.17.diff -rw-rw-r-- devik/devik9302 2002-05-25 11:11:58 htb3.6_tc.diff -rwxrwxr-x devik/devik 101992 2002-05-12 22:26:53 tc Kernel versions 2.4.20-pre1 and up include HTB3 by default. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Examples from HTB home page...
On Friday, 06 September 2002, at 15:39:16 +0300, eth wrote: tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 match ip dport 80 0x flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 flowid 1:11 ... chokes at the tc filter add with: RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument As far as I can tell this *should* work, it did 6 months ago on a 2.4.17. Maybe your kernel configuration changed in the meantime, and with the new version you didn't compile some necessary features. Have just tried your exact configuration with a 2.4.20-pre1 kernel and it works OK. It seems you missed U32 classifier support either compiled in or as a module. My box show the following modules loaded after trying your config: Module Size Used byNot tainted cls_u32 4484 1 (autoclean) sch_htb18016 1 (autoclean) pcnet3213120 1 (autoclean) mii 1104 0 (autoclean) [pcnet32] -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] How to match all packets with a tc filter
On Wednesday, 04 September 2002, at 20:27:27 +0200, Stef Coene wrote: Yeah I know, but I use several different qdiscs and would prefer to have a general way to do it with filters. The I think the u32 trick is the best you can do. Or tag all traffic with ipchains/iptables and add a tc filter of type fwmark matching this tag. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
