Re: [LARTC] ipip/gre tunnel behind NAT environments.
On 5/19/07, shetravel [EMAIL PROTECTED] wrote: Hi, Does anyone tried to get ipip or gre tunnel behind NAT environments. ? i'm trying to make both side tunneling with ipip or gre with private address just like belows.. A ---FIRWWAL ---INET --- B PRIVATEPUBLIC PUBLIC (10.100.0.1) (211.xxx.xxx.xxx) (211.xxx.xxx.xxx) is it possible to make both side connections with IPIP or GRE tunnels ? thanks in advance. If the firewall is a linux system, you should be able to easily use DNAT to forward the ipip or gre packets to host 'A'. Something like... iptables -t nat -A PREROUTING -i [Firewall's internet facing interface] -s [Host B's IP] -d [Firewall's public IP] -p ipip -j DNAT --to-destination [Host A's IP] I'm not sure if connection tracking will do any of this automatically, but if it were going to work, A would have to send packets to B over the tunnel first before B could send to A. -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Virtual Interface
You can do this with vlans, but this may not be a suitable solution, as if you want to make them work normaly, you will need to tie this to a vlan capable switch. I don't belive that alias interfaces support setting seperate mac addresses, however, you might want to look at ebtables, it has some mac address rewriting functionality which may meet your needs. On 2/2/06, Roger Singh [EMAIL PROTECTED] wrote: Hi Guys, I want to create multiple virtual interfaces on a system running linux 2.6. The main requirment being, to assign unique MAC address fo each of the virtual interfaces. I need to know, if this is possible and will really appriciate if someone can provide me pointer in this direction. Thanks a lot. R. Singh ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Ryan Castellucci http://ryanc.org/ -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Load Balancing with Instant Messenger traffic?
I've seen this issue as well, it has something to do with route cacheing, you loose connections every 5 or 10 minutes, right? You have a couple options Use iproute to create rules to tie each user to a specific connection. I've done this before and it works ok. Another idea I just had would be to use the iptables CONNMARK and MARK extensions to tag connections with what interface they initialy went out on, then use iproute rules to make routing decisions based on the packet mark. I can probably whip up some example stuff if you need it. On 1/16/06, Jared Ballou [EMAIL PROTECTED] wrote: Hi, I have a box set up to distribute load over 4 satellite connections. I cannot use Instant Messenger programs with it as it stands, I believe that using iproute2, the path to the server is not being locked to one interface, so the IM servers are getting user traffic from multiple IPs. When I set just one default gateway, IMs work great. When I use the scope global/nexthop method of load balancing, IM programs will keep disconnecting and needing to reconnect. Is there a way (besides bonding) to make IM traffic locked into a certain interface? I'd like to do it balanced too since Yahoo webcams take up 30% of the bandwidth here, but if I have to I guess I could forward all that traffic out one modem and everything else out another. Thanks. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: UDP transfer speed exceeding the ceil by about 4x
Even more interesting details; This seems to only happen when the packets are fragmented. On 11/15/05, Ryan Castellucci [EMAIL PROTECTED] wrote: A bit more detail. I have the following htb classes set up... class htb 1:356 parent 1:4 leaf 356: prio 4 quantum 1600 rate 12800bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:357 parent 1:4 leaf 357: prio 4 quantum 1600 rate 12800bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:2 root rate 51200bit ceil 54400bit burst 64Kb/8 mpu 0b overhead 0b cburst 1667b/8 mpu 0b overhead 0b level 7 class htb 1:3 parent 1:2 leaf 3: prio 2 quantum 10400 rate 83200bit ceil 88640bit burst 64Kb/8 mpu 0b overhead 0b cburst 1709b/8 mpu 0b overhead 0b level 0 class htb 1:614 parent 1:5 leaf 614: prio 6 quantum 1500 rate 10240bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:4 parent 1:2 rate 25600bit ceil 51680bit burst 64Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 6 class htb 1:613 parent 1:5 leaf 612: prio 6 quantum 1500 rate 10240bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:5 parent 1:2 rate 20480bit ceil 51680bit burst 64Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 6 class htb 1:612 parent 1:5 leaf 612: prio 6 quantum 1500 rate 10240bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:6 parent 1:2 rate 5120bit ceil 43520bit burst 64Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 6 class htb 1:868 parent 1:6 leaf 868: prio 7 quantum 1500 rate 2560bit ceil 43520bit burst 15Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 0 class htb 1:869 parent 1:6 leaf 869: prio 7 quantum 1500 rate 2560bit ceil 43520bit burst 15Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 0 class htb 1:358 parent 1:4 leaf 358: prio 4 quantum 1600 rate 12800bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:870 parent 1:6 leaf 870: prio 7 quantum 1500 rate 2560bit ceil 43520bit burst 15Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 0 and my traffic is being classified properly, however, UDP traffic is able to exceed the ceiling rate on 1:613 and it's parents, and tops out at about 4x whatever I set that ceil to (I tried several values, and the UDP transfer rate always settled at about 4x the ceil). It manages to throttle TCP traffic just fine. ICMP exceeds the ceil slighlty, but not enough to really worry me (about 3%) I've read through the documentation several times, but I don't see a whole lot. I also tried messing with the quantum, burst, and cburst, but that didn't really help. If anyone has any other ideas of what to try, i'd really appreciate it, as I'm kinda stuck here :( On 11/14/05, Ryan Castellucci [EMAIL PROTECTED] wrote: What's going on here? I'm spewing UDP traffic at this thing, and it is exceeding the ceil. Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 -- Ryan Castellucci http://ryanc.org/ -- Ryan Castellucci http://ryanc.org/ -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Transfer speed exceeding the ceil
Upon futher examination, traffic seems to flow at about 4x whatever the ceil is set to. On 11/14/05, Ryan Castellucci [EMAIL PROTECTED] wrote: What's going on here? I'm spewing UDP traffic at this thing, and it is exceeding the ceil. Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 -- Ryan Castellucci http://ryanc.org/ -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Transfer speed exceeding the ceil
On 11/16/05, Andy Furniss [EMAIL PROTECTED] wrote: Ryan Castellucci wrote: What's going on here? I'm spewing UDP traffic at this thing, and it is exceeding the ceil. Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 Try and verify rate of udp arrival at the target machine with tcpdump -ttt. The sent counter is actually an enqueue rather than dequeue count so blatting with udp may cause bogus rates (not that I've checked how exactly htb does rate calculations). Andy. I checked it with iftop, which confirms what tc is showing. I had determined that this is an issue with fragmented packets rather then specificly UDP, take a look at the other messages i posted to the mailing list. is the is bug in tc/htb? or is this perhpse something that could be corrected by enlarging the quantum? -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Transfer speed exceeding the ceil
On 11/16/05, Andy Furniss [EMAIL PROTECTED] wrote: Ryan Castellucci wrote: On 11/16/05, Andy Furniss [EMAIL PROTECTED] wrote: Ryan Castellucci wrote: What's going on here? I'm spewing UDP traffic at this thing, and it is exceeding the ceil. Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 Try and verify rate of udp arrival at the target machine with tcpdump -ttt. The sent counter is actually an enqueue rather than dequeue count so blatting with udp may cause bogus rates (not that I've checked how exactly htb does rate calculations). Andy. I checked it with iftop, which confirms what tc is showing. I had determined that this is an issue with fragmented packets rather then specificly UDP, take a look at the other messages i posted to the mailing list. is the is bug in tc/htb? or is this perhpse something that could be corrected by enlarging the quantum? I tried fragged udp and it seemed OK for me - whats the mtu on the interface - if it's bigger than normal then try specifying it along with rate/ceils to htb - Looking as I type I can see giants 1748 above (I should have noticed that earlier) - htb does not shape big packets properly unless you use the mtu option. The list is down for me today. I was not manualy setting the MTU. The interfaces I'm using have MTU of 1500, but I'll try setting the MTU for my classes to 1500 and see if that resolves the problem. Thanks! -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] UDP transfer speed exceeding the ceil by about 4x
A bit more detail. I have the following htb classes set up... class htb 1:356 parent 1:4 leaf 356: prio 4 quantum 1600 rate 12800bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:357 parent 1:4 leaf 357: prio 4 quantum 1600 rate 12800bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:2 root rate 51200bit ceil 54400bit burst 64Kb/8 mpu 0b overhead 0b cburst 1667b/8 mpu 0b overhead 0b level 7 class htb 1:3 parent 1:2 leaf 3: prio 2 quantum 10400 rate 83200bit ceil 88640bit burst 64Kb/8 mpu 0b overhead 0b cburst 1709b/8 mpu 0b overhead 0b level 0 class htb 1:614 parent 1:5 leaf 614: prio 6 quantum 1500 rate 10240bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:4 parent 1:2 rate 25600bit ceil 51680bit burst 64Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 6 class htb 1:613 parent 1:5 leaf 612: prio 6 quantum 1500 rate 10240bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:5 parent 1:2 rate 20480bit ceil 51680bit burst 64Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 6 class htb 1:612 parent 1:5 leaf 612: prio 6 quantum 1500 rate 10240bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:6 parent 1:2 rate 5120bit ceil 43520bit burst 64Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 6 class htb 1:868 parent 1:6 leaf 868: prio 7 quantum 1500 rate 2560bit ceil 43520bit burst 15Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 0 class htb 1:869 parent 1:6 leaf 869: prio 7 quantum 1500 rate 2560bit ceil 43520bit burst 15Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 0 class htb 1:358 parent 1:4 leaf 358: prio 4 quantum 1600 rate 12800bit ceil 51680bit burst 15Kb/8 mpu 0b overhead 0b cburst 1663b/8 mpu 0b overhead 0b level 0 class htb 1:870 parent 1:6 leaf 870: prio 7 quantum 1500 rate 2560bit ceil 43520bit burst 15Kb/8 mpu 0b overhead 0b cburst 1653b/8 mpu 0b overhead 0b level 0 and my traffic is being classified properly, however, UDP traffic is able to exceed the ceiling rate on 1:613 and it's parents, and tops out at about 4x whatever I set that ceil to (I tried several values, and the UDP transfer rate always settled at about 4x the ceil). It manages to throttle TCP traffic just fine. ICMP exceeds the ceil slighlty, but not enough to really worry me (about 3%) I've read through the documentation several times, but I don't see a whole lot. I also tried messing with the quantum, burst, and cburst, but that didn't really help. If anyone has any other ideas of what to try, i'd really appreciate it, as I'm kinda stuck here :( On 11/14/05, Ryan Castellucci [EMAIL PROTECTED] wrote: What's going on here? I'm spewing UDP traffic at this thing, and it is exceeding the ceil. Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 -- Ryan Castellucci http://ryanc.org/ -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] UDP traffic going through leaf faster then ceil...
What's going on here? I'm spewing UDP traffic at this thing, and it is exceeding the ceil, (i watched it for a few minutes, it didn't slow down). Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Transfer speed exceeding the ceil
What's going on here? I'm spewing UDP traffic at this thing, and it is exceeding the ceil. Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Borrowing between HTB classes not working as expectd.
On 11/13/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quoting Ryan Castellucci [EMAIL PROTECTED]: I did not mix these up. I'm using the 1:2 class for TCP and ICMP control packets, such as TCP acks which need an amount of bandwidth proportinate to the maximum download rate. There seems to be a misunderstanding of some kind. You say you're using the 1:2 class for control packets; but in the output you've sent, the 1:2 class is the root HTB class, so it should be (indirectly) used for everything. Erp, I ment 1:3. The only classes you can use directly (that means classify packets to) are the leaf classes (HTB classes which don't have any more children), in your setup that would be one of the 1:3,356-361,612-617,869-873 leaf classes. Class 1:2 has a rate/ceil of 217kbit. Children of this class are 1:3 (124/149), 1:4 (128/243), 1:5 (102/243), and 1:6 (25/204). As I said before, the problem is that the rates of these classes don't add up. These child classes added together for example use 124+128+102+25=379kbit, although the parent provides only 217kbit. Classes 1:4 and 1:5 in particular can borrow up to 243kbit each, although the parent class can provide only 217kbit in total. So how exactly do you expect the borrowing to work? Unless you have an understanding of the inner workings of HTB in great detail, the results of this setup are pretty much unpredictable. The same problem can be found further down the tree; for example, the class 1:4 has a rate of 128kbit. Children of this class are 1:356-361, with a rate of 128kbit each. Added together, they require a rate of 768kbit, but the parent class only provides 128kbit (or it would if the parent class of this parent class could provide as much). Same story with 1:5 and 1:6. The first thing you have to do is calculate the class rates so they add up properly. Otherwise you will never get anywhere near a predictable borrowing behaviour. I'll go though and make sure everything adds up, and try it again. -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Borrowing between HTB classes not working as expectd.
I'm using a fairly large number of classes, andf borrowing is not
working as expected... I've called this setting it up on an IMQ device
with speed 1200/256 on a 1536/384 line. I'm then throwing a UDP data
transfer at it that gets tossed in one of the class under parent 1:6.
The classification is working fine, but when I try to ping out, ping
times are in the 900ms range, even though pings are classified in the
classes under 1:5, and speeds in classes under 1:4 are well under the
60% they should be getting. Any idea what I've done wrong here? Perl
code to set everything up below, if you comment out the system call,
it'll list off all the tc commands executed. How I wanted this to work
is higher priority classes to get a shot at bandwidth first in excess
of the base rates on all the other classes.
#!/usr/bin/perl -w
use strict;
my $dev = $ARGV[0];
my $speed_down = $ARGV[1];
my $speed_up = $ARGV[2];
my $tc_bin = /sbin/tc;
tc(qdisc del dev $dev root);
tc(qdisc add dev $dev root handle 1:0 htb r2q 1 default 4);
tc(class add dev $dev parent 1:0 classid 1:2 htb .
rate . int($speed_up * 0.85) . kbit .
ceil . int($speed_up * 0.85) . kbit .
prio 1 burst 64k);
tc(qdisc add dev $dev parent 1:2 handle 2: sfq perturb 10);
# Critical class
tc(class add dev $dev parent 1:2 classid 1:3 htb .
rate . int($speed_down * 0.05 + 64) . kbit .
ceil . int($speed_down * 0.05 + 64 +
($speed_up * 0.10)) . kbit .
prio 2 burst 64k);
tc(qdisc add dev $dev parent 1:3 handle 3: sfq perturb 10);
# High class
tc(class add dev $dev parent 1:2 classid 1:4 htb .
rate . int($speed_up * 0.50) . kbit .
ceil . int($speed_up * 0.95) . kbit .
prio 3 burst 64k);
tc(qdisc add dev $dev parent 1:4 handle 4: sfq perturb 10);
# Med class
tc(class add dev $dev parent 1:2 classid 1:5 htb .
rate . int($speed_up * 0.40) . kbit .
ceil . int($speed_up * 0.95) . kbit .
prio 5 burst 64k);
tc(qdisc add dev $dev parent 1:5 handle 5: sfq perturb 10);
# Low class
tc(class add dev $dev parent 1:2 classid 1:6 htb .
rate . int($speed_up * 0.10) . kbit .
ceil . int($speed_up * 0.80) . kbit .
prio 7 burst 64k);
tc(qdisc add dev $dev parent 1:6 handle 6: sfq perturb 10);
for (my $i=100;$i = 110;$i++)
{
# High class
tc(class add dev $dev parent 1:4 classid 1: . ($i + 256) . htb .
rate . int($speed_up * 0.50) . kbit .
ceil . int($speed_up * 0.95) . kbit .
prio 4 burst 15k);
tc(qdisc add dev $dev parent 1: . ($i + 256) . handle . ($i +
256) . : sfq perturb 10);
tc(filter add dev $dev protocol ip parent 1: prio 5 handle .
tohex($i + 256) . fw flowid 1: . ($i + 256));
# Med class
tc(class add dev $dev parent 1:5 classid 1: . ($i + 512) . htb .
rate . int($speed_up * 0.40) . kbit .
ceil . int($speed_up * 0.95) . kbit .
prio 6 burst 15k);
tc(qdisc add dev $dev parent 1: . ($i + 512) . handle . ($i +
512) . : sfq perturb 10);
tc(filter add dev $dev protocol ip parent 1: prio 5 handle .
tohex($i + 512) . fw flowid 1: . ($i + 512));
# Low class
tc(class add dev $dev parent 1:6 classid 1: . ($i + 768) . htb .
rate . int($speed_up * 0.10) . kbit .
ceil . int($speed_up * 0.80) . kbit .
prio 8 burst 15k);
tc(qdisc add dev $dev parent 1: . ($i + 768) . handle . ($i +
768) . : sfq perturb 10);
tc(filter add dev $dev protocol ip parent 1: prio 5 handle .
tohex($i + 768) . fw flowid 1: . ($i + 768));
}
tc(filter add dev $dev protocol ip parent 1: prio 5 handle 0x3 fw flowid 1:3);
sub tc
{
my $arg = shift;
print $tc_bin $arg\n;
system($tc_bin,split(/ /,$arg));
}
sub tohex
{
return '0x' . sprintf(%2.2x,shift);
}
--
Ryan Castellucci http://ryanc.org/
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Borrowing between HTB classes not working as expectd.
I did not mix these up. I'm using the 1:2 class for TCP and ICMP control packets, such as TCP acks which need an amount of bandwidth proportinat to the makimum download rate. On 11/12/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quoting Ryan Castellucci [EMAIL PROTECTED]: I've called this setting it up on an IMQ device with speed 1200/256 on a 1536/384 line. Perl code to set everything up below, if you comment out the system call, it'll list off all the tc commands executed. Hmmm, the output it produces for me is really weird. Could you post the output of 'tc -d qdisc show dev device' and 'tc -d class show dev device' somewhere, it's easier to understand and maybe that will make more sense to me. The main problems in the output I get is that rates do not add up; children class rates added up together is higher than parent class rate, which means the children take more bandwidth for guaranteed than the parent can offer. Sometimes child class ceil rates is greater than parent class ceil rate, which should not be exceeded in any case (at least to my understanding of HTB). By looking at your Perl code, you seem to be mixing up $speed_up and $speed_down quite a lot; at least to me it makes no sense to have a download class as child of an upload class, especially not with that much difference in available download/upload rate. But I'm not really a Perl programmer, so maybe I misunderstood this part. I did not mix these up. I'm using the 1:2 class for TCP and ICMP control packets, such as TCP acks which need an amount of bandwidth proportinate to the maximum download rate. The tc show output is attached. -- Ryan Castellucci http://ryanc.org/ # tc -d qdisc show dev imq0;tc -d class show dev imq0 qdisc htb 1: r2q 1 default 4 direct_packets_stat 0 ver 3.17 qdisc sfq 3: parent 1:3 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 356: parent 1:356 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 612: parent 1:612 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 868: parent 1:868 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 357: parent 1:357 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 613: parent 1:613 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 869: parent 1:869 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 358: parent 1:358 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 614: parent 1:614 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 870: parent 1:870 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 359: parent 1:359 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 615: parent 1:615 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 871: parent 1:871 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 360: parent 1:360 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 616: parent 1:616 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 872: parent 1:872 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 361: parent 1:361 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 617: parent 1:617 limit 128p quantum 1500b flows 128/1024 perturb 10sec qdisc sfq 873: parent 1:873 limit 128p quantum 1500b flows 128/1024 perturb 10sec class htb 1:356 parent 1:4 leaf 356: prio 4 quantum 16000 rate 128000bit ceil 243000bit burst 15Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 0 class htb 1:617 parent 1:5 leaf 617: prio 6 quantum 12750 rate 102000bit ceil 243000bit burst 15Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 0 class htb 1:357 parent 1:4 leaf 357: prio 4 quantum 16000 rate 128000bit ceil 243000bit burst 15Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 0 class htb 1:616 parent 1:5 leaf 616: prio 6 quantum 12750 rate 102000bit ceil 243000bit burst 15Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 0 class htb 1:2 root rate 217000bit ceil 217000bit burst 64Kb/8 mpu 0b overhead 0b cburst 1870b/8 mpu 0b overhead 0b level 7 class htb 1:615 parent 1:5 leaf 615: prio 6 quantum 12750 rate 102000bit ceil 243000bit burst 15Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 0 class htb 1:3 parent 1:2 leaf 3: prio 2 quantum 15500 rate 124000bit ceil 149000bit burst 64Kb/8 mpu 0b overhead 0b cburst 1785b/8 mpu 0b overhead 0b level 0 class htb 1:614 parent 1:5 leaf 614: prio 6 quantum 12750 rate 102000bit ceil 243000bit burst 15Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 0 class htb 1:4 parent 1:2 rate 128000bit ceil 243000bit burst 64Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 6 class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 12750 rate 102000bit ceil 243000bit burst 15Kb/8 mpu 0b overhead 0b cburst 1902b/8 mpu 0b overhead 0b level 0 class htb 1:361 parent 1:4 leaf 361: prio 4
Re: [LARTC] MSN keeps disconnecting with load balancing
This problem is caused by the cached route to MSN expiring, and the kernel trying to route the existing connection over the other internet connection. If you're doing SNAT, this will result in the source IP address changing, and MSN will reset the connection. On 11/12/05, Corey Hickey [EMAIL PROTECTED] wrote: ro0ot wrote: Hi, I have the my gateway with load balancing traffic going out over two providers. Web browsing is fine...working great. But, my clients (office staff) complains that MSN keeps disconnecting (in 5 mins). Why? Do you mean MSN instant messenger? I've never used it, but I can give you a few generic steps to take when you want to figure out what's going wrong with a connection. Are you familiar with tcpdump and/or ethereal? 1. Go to the computer of a client who is complaining about disconnection. 2. ssh into your gateway and run: # tcpdump -i eth0 host 123.123.123.123 and port not ssh Change eth0 to the inside interface and 123.123.123.123 to the IP address of your client. 3. See if tcpdump is catching lots and lots of packets. If it is, either stop programs on your clients machine that access the Internet or use more filters (like and port not imaps). 4. Once you're not catching lots of extraneous packets, kill tcpdump and run: # tcpdump -s 1500 -w log -i eth0 host 123.123.123.123 and port not ssh Include any other filters you have to use. 5. Have your client start up their program, and then sit there and wait. Don't do anything else that would send packets through the gateway; you don't want to clutter up the log. 6. See if the problem manifests. Most likely it won't, because that's just the way things are :) , but if it does you'll have a log. Kill tcpdump and examine the file with: # tcpdump -r log If you want more verbosity, use -v, -vv, or -vvv. Or, if you want to use a gui, copy the log file to some machine with X11 and use: # ethereal -r log -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Ryan Castellucci http://ryanc.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Routing through dummy interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a linux system with 4 ethernet interfaces, eth0 goes to the internet, eth1, eth2, and eth3 are NAT'd LANs. I want to use an ingress filter to prioritize bandwidth (downstream from internet) to various IPs. I want to sett it up something like this eth0 --[NAT]-- dummy0 --- dummy1 --- eth1,eth2,eth3 dummy1 should have an ingress filter on it controling outbound bandwidth to the internet dummy0 should have an ingress filter on it controling inbound bandwidth from the internet Let's say... eth0 is 10.53.62.2/30 dummy0 is 192.168.255.1/24 dummy1 is 192.168.255.254/24 eth1 is 192.168.1.1/24 eth2 is 192.168.2.1/24 eth3 is 192.168.3.1/24 How do I set up routing so traffic to/from the internet gets routed through the dummy interfaces? If this is not possible, how might i achive a simmilar effect? - -- Any mail sent to the address this message was posted from will be bounced. PGP/GPG Fingerprint: 3B30 C6BE B1C6 9526 7A90 34E7 11DF 44F3 7217 7BC7 On pgp.mit.edu, import with `gpg --keyserver pgp.mit.edu --recv-key 72177BC7` Also available at http://www.cal.net/~ryan/ryan_at_mother_dot_com.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAcJt7Ed9E83IXe8cRAmDhAJkBGUOBWjWU9j1+i3Umf/ahQroGvQCfb4a3 9jHTZdXlv1mrGyRc+m29KFQ= =TTb/ -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
