All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] shaping outbound ftp traffic
@ 2004-10-08 15:42 nix4me
  2004-10-08 15:46 ` nix4me
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: nix4me @ 2004-10-08 15:42 UTC (permalink / raw)
  To: lartc

>In theory yes, but it is shaping inbound transfers to my server.

>YOu're not doing any other sort of Ingress filters are you??

No

>I dont care about destination port.  That line was commented.  BUT, incoming transfers are being shaped for some reason.

>Could this be shaping on the ISP side?? What >happens when the tc rules
>are shut off??

No, everything works fine

>Can you determine what ports are being used for >inbound data transfers?
>What makes you select those ports you defined as >the outbound??

Same ports, 50000-51000 and 65437. 
I choose these ports because they are the ports that I have passive ftp traffic on and 65437 is the active ftp port.
  
I just dont understand why the inbound traffic is being limited.  The outbound shaping works fine.
 
Script:
I am using the following script to limit my outbound traffic. This scipt runs on a box behind my firewall. It limits my outbound passive ftp traffic to 39K perfectly....just like i want. However, i just noticed that it is also limiting uploads coming to my server.

Is there something I can change to make it not limit uploads to my server?
#!/bin/bash
#shaping passive ftp traffic

# mark the outbound passive ftp packets on ports 50000-51000
iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null

iptables -t mangle -N MYSHAPER-OUT
iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT

iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
# clear it
tc qdisc del dev eth0 root

#add the root qdisk
tc qdisc add dev eth0 root handle 1: htb default 26

#add main rate limit class
tc class add dev eth0 parent 1: classid 1:1 htb rate 10000mbps

#add leaf classes
tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps

#filter traffic into classes
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [LARTC] shaping outbound ftp traffic
  2004-10-08 15:42 [LARTC] shaping outbound ftp traffic nix4me
@ 2004-10-08 15:46 ` nix4me
  2004-10-11  3:06 ` Ow Mun Heng
  2004-10-11  8:47 ` Ow Mun Heng
  2 siblings, 0 replies; 4+ messages in thread
From: nix4me @ 2004-10-08 15:46 UTC (permalink / raw)
  To: lartc

Yes, inbound is affected even though outbound transfers are suspended.  The inbound in shaped to 39K.  This is what totally confuses me.  I thought with my script that only traffic leaving source ports 50000-51000 & 65437 should be shaped.  But it is also shaping traffic entering my machine on the same ports.

.................

Is the inbound rate affected even if there are no outbound transfers?  Is
the speed actually being "limited" to a certain speed, or are you just
noticing that the inbound/upload traffic is slower than it should be.

The reason I ask is because you're tagging all outbound ftp-data traffic
(ports 50000:51000) and directing it to the class with 39kbps.  If you
have outbound/download transfers going, they may be using all the
available outbound bandwidth for that class and causing outbound ACK
packets (for the inbound/upload traffic) to queue and throttle the inbound
speed.

Please don't flame me if I'm way off base...

Assumption:
- data connection is bi-directional.  ie. the data connection is made on
the specified PASV (server) ports (50000:51000) regardless of whether it's
an upload or download.

Test:
- simply kill all downloads and see if the uploads are still affected.
- or you can tag oubound ACK packets and filter them into the faster class.

chris



>>>>Theory is.. You can only shape outbound traffic.
>
>> Inbound is via tcp windowshaping etc..
>>
>> In theory yes, but it is shaping inbound transfers to my server.
>>
>
>>>>>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK
>>>>>> --set-mark 20
>>>>>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK
>>>>>> --set-mark 20
>>>>>> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark
>>>>>> 26
>
>>
>
>>>>Why do you care about destination port?
>>>>AFAIK, it shouldn't affect your wants since you're >not filtering on
>>>>incoming traffic
>
>>
>> I dont care about destination port.  That line was commented.  BUT,
>> incoming transfers are being shaped for some reason.
>>
>
>>>>Is this legal?? 10000mbps?? Wow.. 10000*1E6?
>
>>
>> I just did that to make sure lan traffic was not affected at all.
>>
>>
>> enire script for reference....
>> I am using the following script to limit my outbound traffic. This scipt
>> runs on a box behind my firewall. It limits my outbound passive ftp
>> traffic to 39K perfectly....just like i want. However, i just noticed that
>> it is also limiting uploads coming to my server.
>>
>> Is there something I can change to make it not limit uploads to my server?
>> #!/bin/bash
>> #shaping passive ftp traffic
>>
>> # mark the outbound passive ftp packets on ports 50000-51000
>> iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null >
>> /dev/null
>> iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
>> iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null
>>
>> iptables -t mangle -N MYSHAPER-OUT
>> iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT
>>
>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark
>> 20
>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK
>> --set-mark 20
>> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
>> # clear it
>> tc qdisc del dev eth0 root
>>
>> #add the root qdisk
>> tc qdisc add dev eth0 root handle 1: htb default 26
>>
>> #add main rate limit class
>> tc class add dev eth0 parent 1: classid 1:1 htb rate 10000mbps
>>
>> #add leaf classes
>> tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
>> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps
>>
>> #filter traffic into classes
>> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid
>> 1:20
>> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid
>> 1:26

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LARTC] shaping outbound ftp traffic
  2004-10-08 15:42 [LARTC] shaping outbound ftp traffic nix4me
  2004-10-08 15:46 ` nix4me
@ 2004-10-11  3:06 ` Ow Mun Heng
  2004-10-11  8:47 ` Ow Mun Heng
  2 siblings, 0 replies; 4+ messages in thread
From: Ow Mun Heng @ 2004-10-11  3:06 UTC (permalink / raw)
  To: lartc

On Fri, 2004-10-08 at 23:46, nix4me@cfl.rr.com wrote:
> Yes, inbound is affected even though outbound transfers are suspended.  
> The inbound in shaped to 39K.  This is what totally confuses me.  I thought 
> with my script that only traffic leaving source ports 50000-51000 & 65437 
> should be shaped.  But it is also shaping traffic entering my machine on 
> the same ports.

Dude..

if TC is cleared, and I presume it _Is_ cleared of all rules, then there should _not_ be 
any limitation on inbound transfer rates. (neither will there be any outbound transfer rate
problems either..

Please go to http://nyc.speakeasy.net/ and test your upload and download speeds

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 11:01:52 up 1:45, 10 users, load average: 0.91, 0.89, 0.83 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LARTC] shaping outbound ftp traffic
  2004-10-08 15:42 [LARTC] shaping outbound ftp traffic nix4me
  2004-10-08 15:46 ` nix4me
  2004-10-11  3:06 ` Ow Mun Heng
@ 2004-10-11  8:47 ` Ow Mun Heng
  2 siblings, 0 replies; 4+ messages in thread
From: Ow Mun Heng @ 2004-10-11  8:47 UTC (permalink / raw)
  To: lartc

On Fri, 2004-10-08 at 23:46, nix4me@cfl.rr.com wrote:
> Yes, inbound is affected even though outbound transfers are suspended.  
> The inbound in shaped to 39K.  This is what totally confuses me.  I thought 
> with my script that only traffic leaving source ports 50000-51000 & 65437 
> should be shaped.  But it is also shaping traffic entering my machine on 
> the same ports.

Dude..

if TC is cleared, and I presume it _Is_ cleared of all rules, then there should _not_ be 
any limitation on inbound transfer rates. (neither will there be any outbound transfer rate
problems either..

Please go to http://nyc.speakeasy.net/ and test your upload and download speeds

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 11:01:52 up 1:45, 10 users, load average: 0.91, 0.89, 0.83 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-10-11  8:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-08 15:42 [LARTC] shaping outbound ftp traffic nix4me
2004-10-08 15:46 ` nix4me
2004-10-11  3:06 ` Ow Mun Heng
2004-10-11  8:47 ` Ow Mun Heng

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.