[LARTC] RED question.
Hi, How does the RED algorithm detect that a queue enter the idle period? It seems there must be a mechanism.Can anybody explain it to me? Thank you in advance. Cong Lu ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] LIST_FIND in netfilter_ipv4/listhelp.h
Hi * jeremie le-hen [EMAIL PROTECTED] 2003-10-06 16:44 Unless I really drank too much yesterday evening, I'm pretty sure this algorithm will fail if the list has only one element, returning NULL immediately without even trying to compare the element. On the other hand, it seems to work pretty well for months, since it is widely used accross the NetFilter conntrack code. So where am I wrong ? The code is correct. Check include/linux/list.h, it's a cyclic list: head-next points to first element head-prev points to last element the list iteration code will make it clear: #define __list_for_each(pos, head) \ for (pos = (head)-next; pos != (head); pos = pos-next) Regards -- Thomas GRAF [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IP Failover
If anyone is interested, in my quest for a networking solution which provides IP Failover on heterogenous redundant networks, I have listed the solutions I found below. I would welcome comments from anyone who is familiar with these. faild - I have included a description below of a program daemon which monitors the Ethernet connections and changes the routing tables when a failure is detected. IP Failover is all this simple program does. Being simple, however, makes it small and easy to port. High Availability Linux Project (HAL) (http://linux-ha.org/) has code available for FreeBsd and Solaris (and probably reasonably portably to other UNIX platforms. It supports virtual (redundant) servers but could probably therefore be configured to support redundant LANs. Advanced Network Services (ANS 2.3.x) for Linux* Operating Systems. which is available from Intel on both PCs and UNIX OS's. ANS provides IP Failover and much more, such as switch failover, load leveling, etc. See: http://www.intel.com/support/network/adapter/onlineguide/PRO1000/DOCS/SERVER/index.htm. Linux Virtual Server Project (LVS) - VRRPD, Virtual Router Redundancy Protocol (http://off.net/~jme/vrrpd/) which also provides IP Failover. It implements RFC2338 but is only available on Linux but may be portable. As with HAL, it is probably configureable to provide redundant LAN. It seems the days of industry-wide standards and interoperability are becoming casualties of war. John Klingler Automatic IP Failover: faild Figure 1 shows a typical redundant network configuration where all nodes are connected to two, separate Ethernet LANs (here referred to as Ethernet A and Ethernet B). Each node must have two Ethernet interfaces, one for each LAN. Distinct IP addresses are assigned to all Ethernet interfaces. _ . . . | | Host 1 Host 2 | __|__ . . . Figure 1: Typical Redundant Network Configuration A route monitor daemon is started on all nodes. Each daemon is configured to be either a responder or both a requestor and responder. Typically the host daemons are requestor/responders. Requestor daemons broadcast inquiry (INQ) packets on all available networks at a specified interval. Upon receiving an INQ each responder daemon sends back an acknowledgment (ACK) via the same route. These packets are all sent using UDP (Unreliable Datagram Protocol) so the daemons can quickly detect if a route is active. If the requestor daemon does not get ACKs from a given node and if the responder daemon does not get INQs as expected, then each daemon independently determines that the particular route has become unreliable, or more likely, has gone dead. Each daemon then changes its local system routing tables so future traffic will be routed over the alternate (and presumably healthy) LAN. This detection and failover occurs very quickly, in a matter of a few seconds, depending on how the daemon's timing parameters are set. When a route fails, network traffic carried by reliable protocols (such as X Window traffic via TCP -- Transmission Control Protocol) is held in abeyance until the IP stack recognizes that packets are not getting through. When the IP stack times out packets waiting for delivery will be retransmitted. Since the daemon has changed the routing tables the retransmitted packets will go via the new route. The IP time-out time is the critical parameter determining how long it will take from initial route failure to establishing communication over the new route. This parameter may or may not be user-settable on your system. Field experience so far indicates lag times of 20-40 seconds before communication resumes. As soon as the original route becomes reliable again, the daemon will restore the routing tables and communication resumes over the original interface. There should be no noticeable delay on the switchback. Request packet interval, failover interval, and switchback interval are all configurable. To initiate a failover daemon on your host system, use the following convention: faild [-r] [-t n] [-f n] [-s n] [-p n] [-l p] -r should launch requestor -t n : timer interval (in secs) for sending of pkts -f n : num missed pkts before if is invalidated -s n : num good pkts before if is revalidated -p n : port number to use -l p : full path to message log file Note: This daemon currently runs on VxWorks, Digital UNIX and Solaris, and is being ported to OpenVMS. Any other platforms would require porting the daemon to the target OS.
Re: [LARTC] Connection timeout on multipath
Cant anyons help on this ? -- Lasse B. Jensen On Mon, 6 Oct 2003, Lasse B. Jensen wrote: Hey all I have 5 adsl lines and have the following setup INTERNET ADSL lines 192.168.1.1-5 | | | | | - switch - | - eth1 linux nat box eth0 - | - LAN Right now i do the following, which are working correctly: I mark incoming packets via mark in iptables, connection are marked 1-5 Then i via 5 ip route tables adsl1-5 in each of them i specify the gateway (one of the adsl lines 192.168.1.1-5) This all works correctly. However i would like to have all adsllines i on multipath. i have tried: Marking all traffic with mark 1 ip route table adsl1 ip route add table adsl1 default equalize proto static nexthop via 192.168.1.1 dev eth1 nexthop via 192.168.1.2 dev eth1 nexthop via 192.168.1.3 dev eth1 nexthop via 192.168.1.4 dev eth1 nexthop via 192.168.1.5 dev eth1 I have applied the patches to the kernel from http://www.ssi.bg/~ja/#routes I have a ping-operation in the background as descripted in the dgd-usage.txt All traffic now is now sent via on of the adsl lines, everything seems to work, but Programs from the lan-computer seems to timeout, i have tried quite some thing but nothing seems to work! Please help ;) -- Lasse B. Jensen ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] What's wrong here? HELP PLEASE!!!!
(this is a repost, nobody said anything about this so maybe it did not go throu the list) I downloaded iproute2-2.4.7-now-ss010824.tar.gz and I did patched tc with the htb3.6_tc.diff from htb3.6-020525.tgz and when I try to use a htb script I get just errors. I did not patch the kernel, since I use kernel 2.4.22 and I saw on - HTB Homepage that I need to patch it only if I run version 2.4.20 or earlier. Do also need the kernel patch ? Or maybe is something else wrong? (I also used the precompiled tc but the situation is the same) Errors: --- RTNETLINK answers: No such file or directory Deleted old root disk on eth1 Unknown filter flowid, hence option 1:10 is unparsable Unknown filter flowid, hence option 1:2 is unparsable RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument .etc (same error over and over...) Part of my script (the full script is accesible on http://retea.hostingcenter.ro/htb.txt ..is too long to post here) : --- /sbin/tc qdisc add dev eth1 root handle 1: htb default 10 /sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit /sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5mbit /sbin/tc filter add dev eth1 protocol ip parent 1:10 prio 5 handle 6 flowid 1:10 /sbin/tc class add dev eth1 parent 1:1 classid 1:2 htb rate 5mbit /sbin/tc filter add dev eth1 protocol ip parent 1:10 prio 5 handle 5 flowid 1:2 /sbin/tc class add dev eth1 parent 1:10 classid 4:11 htb rate 128kbit ceil 256kbit prio 5 /sbin/tc filter add dev eth1 parent 1:10 protocol ip prio 5 u32 match ip dst 192.168.254.10 flowid 4:11 /sbin/tc class add dev eth1 parent 1:10 classid 4:12 htb rate 128kbit ceil 256kbit prio 5 /sbin/tc filter add dev eth1 parent 1:10 protocol ip prio 5 u32 match ip dst 192.168.254.11 flowid 4:12 etc (full script at http://retea.hostingcenter.ro/htb.txt) Thanks! Alex ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] What's wrong here? HELP PLEASE!!!!
On Tuesday 07 October 2003 23:13, Alex wrote: (this is a repost, nobody said anything about this so maybe it did not go throu the list) I downloaded iproute2-2.4.7-now-ss010824.tar.gz and I did patched tc with the htb3.6_tc.diff from htb3.6-020525.tgz and when I try to use a htb script I get just errors. I did not patch the kernel, since I use kernel 2.4.22 and I saw on - HTB Homepage that I need to patch it only if I run version 2.4.20 or earlier. Do also need the kernel patch ? Or maybe is something else wrong? (I also used the precompiled tc but the situation is the same) Try to add set -x to your script on the second line. This will display all commands executed so you know exactly which command is going wrong. You miss something in your filter statement. You have to specify the type of filter you want to use and in your case, that's the fw filter. See lartc.org and/or docum.org for fw filter examples. Stef Errors: --- RTNETLINK answers: No such file or directory Deleted old root disk on eth1 Unknown filter flowid, hence option 1:10 is unparsable Unknown filter flowid, hence option 1:2 is unparsable RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument .etc (same error over and over...) Part of my script (the full script is accesible on http://retea.hostingcenter.ro/htb.txt ..is too long to post here) : --- /sbin/tc qdisc add dev eth1 root handle 1: htb default 10 /sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit /sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5mbit /sbin/tc filter add dev eth1 protocol ip parent 1:10 prio 5 handle 6 flowid 1:10 /sbin/tc class add dev eth1 parent 1:1 classid 1:2 htb rate 5mbit /sbin/tc filter add dev eth1 protocol ip parent 1:10 prio 5 handle 5 flowid 1:2 /sbin/tc class add dev eth1 parent 1:10 classid 4:11 htb rate 128kbit ceil 256kbit prio 5 /sbin/tc filter add dev eth1 parent 1:10 protocol ip prio 5 u32 match ip dst 192.168.254.10 flowid 4:11 /sbin/tc class add dev eth1 parent 1:10 classid 4:12 htb rate 128kbit ceil 256kbit prio 5 /sbin/tc filter add dev eth1 parent 1:10 protocol ip prio 5 u32 match ip dst 192.168.254.11 flowid 4:12 etc (full script at http://retea.hostingcenter.ro/htb.txt) Thanks! Alex ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IP Failover
On Tuesday 07 October 2003 21:55, John Klingler wrote: If anyone is interested, in my quest for a networking solution which provides IP Failover on heterogenous redundant networks, I have listed the solutions I found below. I would welcome comments from anyone who is familiar with these. 1. faild - I have included a description below of a program daemon which monitors the Ethernet connections and changes the routing tables when a failure is detected. IP Failover is all this simple program does. Being simple, however, makes it small and easy to port. 2. High Availability Linux Project (HAL) (http://linux-ha.org/) has code available for FreeBsd and Solaris (and probably reasonably portably to other UNIX platforms. It supports virtual (redundant) servers but could probably therefore be configured to support redundant LANs. 3. Advanced Network Services (ANS 2.3.x) for Linux* Operating Systems. which is available from Intel on both PCs and UNIX OS's. ANS provides IP Failover and much more, such as switch failover, load leveling, etc. See: http://www.intel.com/support/network/adapter/onlineguide/PRO1000/DOCS/SERVE R/index.htm. 4. Linux Virtual Server Project (LVS) - VRRPD, Virtual Router Redundancy Protocol (http://off.net/~jme/vrrpd/) which also provides IP Failover. It implements RFC2338 but is only available on Linux but may be portable. As with HAL, it is probably configureable to provide redundant LAN. If I was you, I should go for keepalived. This is part of LVS but you can also use it just for the ip Failover. Companies like IBM, RH, are using this so I think it can be trusted. http://freshmeat.net/projects/keepalived/ In addition, it implements a VRRPv2 stack to handle director failover. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Layer 7 support for tcng ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 07 October 2003 21:15, Matthew Strait wrote: The plan is to port l7-filter to Netfilter. Once this is done, Netfilter can put marks on the packets that the pre-existing fw filter can use. This approach requires no changes to tcng (or tc). However, it does complicate shaping, since two steps are needed rather than one (i.e. mark HTTP as 6; limit 6 to 1mbps, rather than limit HTTP to 1mbps). In the long term, I'd like to have full layer7 support in both QoS and Netfilter. This would be perfect. It doesn't really complicate my setup since i already use shorewall as firewall and that has support for marking packets already. Is this anywhere near to being usable ? Will it be 2.6 only ? - -- +-+ |PGP Public Key: http://sys49152.net/pubkey.asc | +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/g0bjRslfH2ZQjFARAkgzAKCOuq5likCa+mSomisEAmBHw6+xlQCeMcSU UqsaFBqzpqWMw1v2/QWHi0Y= =FWZT -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Scenario
Gents, I've been thinking about shit for awhile, but thought I might defer to the group: What is the best wat to establish per-user bandwidth throttles in an ISP-like environment using TC? I am going to have to support something like 4000 users and I get kernel panics if I create that many QDISCs :) -Paul ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ADSL with PPP failover
Hi - I've been looking around for simple answers to this for a while now, but haven't been able to find any HOW-TO type documentation. I am administering a site with a remote location connected primarily via a cipe tunnel over a SHDSL connection. We also have a direct PSTN connection between the sites. Seeing as phone calls here are not timed I plan to keep the PSTN connection alive even when the cipe tunel is active. I am looking for information as to the best way to set up this network, so that if the cipe connection goes down all traffic is automatically routed over the ppp connection, and when the cipe connection comes back up the traffic is once again routed via the cipe connection. We currently only have one remote location to worry about, but may soon be expanding to multiple sites, with multiple links. I originally thought that I'd be setting this up using weighting in the routing table, but now believe that methodology is out of date even if it would work - more recently I have been thinking that this sort of failover setup would best be implemented using RIP (or is that out of date too?). I was hoping that someone could tell me if I was headed in the right direction before I set out reconfiguring the routing on all our servers. I'd also be grateful for any pointers towards relevant reading or HOW-TOs that relate. Using Linux 2.4 (Redhat 9) Thanks in advance! - Dan. __ Euroluce Lighting Australia PTY LTD 92-94 Tennyson Road, Mortlake, NSW 2137 Ph: (02) 9743 6099 Fx: (02) 9743 6406 http://www.euroluce.com.au/ The contents of this email are confidential. If you are not, or believe you may not be, the intended recipient of this email, please let us know by reply and then delete it from your system. You should not copy the message or disclose its contents to anyone. No warranty or other assurance is given by us that this email is free of any virus or any other defect or error. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. If verification is required please request a hard-copy version. Scanned by Inflex - Queries to: [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Scenario (I should learn to proof read!)
Uh, yeah...that word was supposed to be this'. *blush* Sorry about that :) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
