Re: Traffic shaping... don't understand the instructions!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2004-07-08 at 17:15, Ow Mun Heng wrote:
> On Thu, 2004-07-08 at 15:59, Ow Mun Heng wrote:
> Currently what I've achieved is to severly limit the Download bandwidth
> on eth1 (eth0=ISP) but I can't seem to make it symmetrical. Upload
> bandwidth is still somehow not being shaped.

All right. it's COOL. I've managed to figure it out. Based on my little
setup, it works.

My Setup
laptop with 2 interface (acting as firewall and QoS of sorts)

eth1 = I-Net
eth0 = Local Lan

Cut and paste to shorewall's tcstart file or just execute from the CLI.

Rodolfo, please report back to me if it _works_
for you or not..

I would like to fine_tune it and incorporate it into my HOWTO. 
BTW, if you read the shapecfg README, I don't think it fits
your needs. 

cat /usr/share/doc/shapecfg-2.2.12/README.shaper

[SNIP]
Maximum is about 256K, it will go above this but get a bit blocky.
[/SNIP]

This is _cool_.



--->8---------shorewall tcstart or CLI-------->8-------
#!/bin/bash
# tcstart file for shorewall/CLI/rc.local
# Look & Feel taken from Wondershaper [3]
# To also implement QoS based on Traffic, refer
# to [4] which was why I originally did it to control
# Bitorrent Downloads

# ####### DISCLAIMER #####################
# This has been tested by me. Your Mileage may
# wary depending upon your implementation.
# #########################################

######## INBOUND Traffic Control ############
# For discussions on how to implement Inbound
# Traffic shaping, please refer to the discussion ongoing
# here which I don't seem to agree with or have not found
# a suitable implementation for it to work effectively without
# losing bandwidth. [5]    
# #########################################

# #########################################
# Script made by Ow Mun Heng 
# <nikeow AT yahoo dot com>
# <ow dot mun dot heng AT wdc dot com>
# July 8 2004 
# #########################################

# ########## WHY #########################
#
# This script was prepared because I wanted to HELP
# or give back to the OSS Community
# 
# This script originated from this Fedora List Thread
# to help out this Bloke [6]
# #########################################

# ########## LICENSE ######################
# Released under the GPL. 
# You may freely copy / redistribute as long as 
#I am credited. SIMPLE right?
# ##########################################

# Declare your eth devices
DEV0=eth1			# ISP
DEV1=eth0			# LAN 1

# Declare what/how much you want to shape or 
# police
DEV0_DN= 5000		# 5Mbit Downlink
DEV0_UP= 5000	  	# 5Mbit Uplink

DEV1_DN=128		#128kbit Downlink
DEV1_UP=128		#128kbit Uplink


########## Start for DEV0 ###########
# Start by adding in a root qdisc for your ISP 
# facing eth and puts a default class (100)
# which default traffic will go trhough (eg: one
# that does not match any other traffic classses)
# Note : handle and classes are arbitary numbers

tc qdisc add dev $DEV0 root handle 1: htb default 100

# Here we declare the default class. 
# I'm not going to add more classes since that's
# not what Rodolfo wanted. But feel free to add/classify
# it as you wish. (eg: 1 class for SMTP/FTP/WWW etc)
# if you do that, you will need to classify those packets 
# either according to FWMARK (firewall marks) or by port numbers
# ceil = MAXimum traffic which it can go. It's a Hard CAP 


tc class add dev $DEV0 parent 1:1 classid 1:100  htb rate ${DEV0_DN}kbit ceil ${DEV0_DN}kbit

######### Finish for DEV0 ############

######### Start for DEV1 ###########
# Start by adding in a root qdisc for your LAN
# facing eth and puts a default class (100)
# which default traffic will go trhough (eg: one
# that does not match any other traffic classses)
# Note : handle and classes are arbitary numbers

tc qdisc add dev $DEV1 root handle 10: htb default 100

# Here we declare the default class. 
# I'm not going to add more classes since that's
# not what Rodolfo wanted. But feel free to add/classify
# it as you wish. (eg: 1 class for SMTP/FTP/WWW etc)

tc class add dev $DEV1 parent 10:1 classid 10:100  htb rate ${DEV1_DN}kbit ceil ${DEV1_DN}kbit

######### Finish for DEV1 ############

# ####### Explanation ################
# Okay. That will set you up for the followin
# DEV0 will get asymetrical 5Mbit Up/Dn
# DEV1 will get Dn badnwidth of 128kbit
# _but_ Upload will still be up to 5Mbit.
# This is because, by default, we can only (theoretically)
# shape/police outbound traffic. What we're seeing as DEV1's Upload
# Speed is actually DEV0's (ISP facing eth) incoming speed.
# So, this is what we do. we create a ingress class on DEV1
# [2] FWIW ingress = the act of entering 
# (PS : I still don't really understand it but.... it works)
# ################# END #####################

# Create the ingress filter so that we can shape downlink
tc qdisc add dev $DEV1 handle ffff: ingress

# create a default filter to catch _all_(0.0.0.0/0) traffic going out of DEV0 
# and filter it
# [1] police = Policing: the process of discarding packets (by a dropper) within 
#              a traffic stream in accordance with the state of a corresponding 
#             meter enforcing a traffic profile.
# [1] Drop = this means, packets violating this rule must be dropped.
# [1] flowid is _very_ important. It creates a path for the packets to go. If you don't
# have it, you'll end up with an unregulated Upload speed. 
# eg: Upload DEV0 = Upload DEV1
tc filter add dev $DEV1 parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DEV1_DN}kbit burst 10k drop flowid :1


# References
# [1] http://www.opalsoft.net/qos/DS-211.htm
# http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
# http://nyc.speakeasy.net/ [ This was used to determine up/dn speed]
# [2] http://www.hyperdictionary.com/dictionary/ingress
# [3] http://lartc.org/wondershaper/
# [4] http://my-opensource.org/howto/qostrafficshaping-shorewall-wondershaper-howto.html
# [5] http://my-opensource.org/lists/myoss/2004-07/msg00051.html
# [5] http://my-opensource.org/lists/myoss/2004-06/msg00167.html
# [6] http://www.redhat.com/archives/fedora-list/2004-July/msg01492.html

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 (Tettnang) on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 18:44:50 up 10:12, 9 users, load average: 0.54, 0.78, 0.88 



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux