[LARTC] Problem with routing for multiple uplinks/providers using iproute2
hi all,we were trying to configure our system with 2 ethernet catds connected to two different providers using iproute2 so that it recieves and transmits data from both of them. We have followed the configuration as given on lartc's howto But the most wierd part of the story is that after we restart the system (We have put the script in rc.local) the system works fine and we can ping both our cards from anywhere in the world. But after sometime none of the cards can be pinged from outside but the site running on the system is accessible from everywhere.Does anyone has any idea where or wat we are doing wrong, i will really appreciate your help.Its just so confusing, hopefully its a silly error,(We are running FC-4 with dual Xeon processors)thnx in advance,Mrin Heres a new way to find what you're looking for - Yahoo! Answers ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Weird HTB behaviour in 2.6.17
What kind of network cards do you have? What are the tc stats that you get on the class (anything about giants?)? There's something funny with the intel gig cards. Even if the mtu on them is set to 1500 there's something that breaks / confuses htb. If these are the cards you are using you need to explicitly set the mtu for your classes to 16500. Hello, I've just compiled the kernel 2.6.17 and noticed an odd HTB behaviour. For instance: tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 750Kbit burst 15k tc filter add dev eth0 parent 1:0 protocol ip prio 15 u32 match ip dst 192.168.5.1 classid 1:30 The filter works ok and the traffic to 192.168.5.1 flows through the class 1:30, but the rate gets much higher than 750 Kbps. As far as I realized, the faster the processor is, the higher the traffic gets above the ceiling. I've seen that same behaviour in several machines with this kernel, both with Intel and AMD processors. With a dual Xeon 3 GHz, when my ceiling is 750 Kbps, I get the traffic about 5 Mbps. It seems to be something related to clock. http://mailman.ds9a.nl/pipermail/lartc/2005q3/016981.html In that post, there is another guy with the same problem, but with 2.6.11. Any clues? _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Weird HTB behaviour in 2.6.17
Hello, I've just compiled the kernel 2.6.17 and noticed an odd HTB behaviour. For instance: tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 750Kbit burst 15k tc filter add dev eth0 parent 1:0 protocol ip prio 15 u32 match ip dst 192.168.5.1 classid 1:30 The filter works ok and the traffic to 192.168.5.1 flows through the class 1:30, but the rate gets much higher than 750 Kbps. As far as I realized, the faster the processor is, the higher the traffic gets above the ceiling. I've seen that same behaviour in several machines with this kernel, both with Intel and AMD processors. With a dual Xeon 3 GHz, when my ceiling is 750 Kbps, I get the traffic about 5 Mbps. It seems to be something related to clock. http://mailman.ds9a.nl/pipermail/lartc/2005q3/016981.html In that post, there is another guy with the same problem, but with 2.6.11. Any clues? -- Marlon ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: What am I missing?
Follow-up to my own post here: http://marc.theaimsgroup.com/?l=lartc&m=115332794424197&w=2 Problem ended up being that the tc included in the iproute RPM in Fedora Core 2 was built specifically against the headers in the glibc-kernheaders RPM. When I switched to a custom kernel (for built-in MPPE support), apparently some symbols referenced in the glibc-kernheaders package are not present in the non-RH kernel. This was causing my issue. Solution was to modify the .spec file for iproute and tell it to compile against my custom kernel's headers specifically. Specifically I had to make the following changes to the .spec file to get things to work: - Modify iproute2-2.4.7-kernel.patch to point to /usr/src/linux/include - Do not apply iproute2-2.4.7-misc.patch - Do not apply iproute2-2.4.7-in_port_t.patch This makes everything happy once again! I'm not sure what the consequenes are of not applying those RedHat patches, but the tool still works normally as far as I can tell. Ray ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] SRR qdisc
Hi all, I wrote new qdisc SRR (Simple Round Robin). This is just another reimplementation of round robin packets distributions. I'm not using SQF/ESFQ source code and algorithms in this scheduler. The main goal of this work is not given multistream download managers give all bandwidth resource. Please testing this: http://mordor.strace.net/sched-srr/ -- /bye -- Dmitry U.Labutcky System administrator of Swift Trace mail to: [EMAIL PROTECTED]Simferopol, Crimea, Ukraine phone: +380-652-516546 Yaltinskaya 20, office 502 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
