Script...
Geizhals » Forum » Netzwerk » TC unter Linux (28 Beiträge, 305 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
TC unter Linux
14.11.2005, 19:48:53
Hi, Folks!

Heute bin mal ich mit Fragen dran.... Wie einige wissen, habe ich im Haus 64KBit-ISDN, und mehrere parallel arbeitende PC's... Und nein, es /gibt/ einfach nix schnelleres in meiner Ortschaft 30km von Wien (außer Sat up- und down, und das ist mir mit 1GB p.m. zu teuer, außerdem ist die Latenzzeit wohl schlimmer als bei ISDN ;-)).

Mir schwebt jetzt folgendes vor:
tc einzusetzen um zu priorisieren... Nachdem ISDN ja 64bit up- und down hat (und ich up keinen Streß habe), hatte ich folgende Idee:

HTB qdisc einsetzen (scheint mir simpel und clever) um mal outgoing grob wie folgt zu konfigurieren:


tc qdisc add dev ippp0 root handle 1: htb default 30


Maximale Priorität für Interaktiv(ssh)

tc class add dev ippp0 parent 1: classid 1:10 htb rate 50 kbit ceil 64kbit priority 10


Mittlere Priorität für Arbeitsserver-https und POP-Arbeit

tc class add dev ippp0 parent 1: classid 1:20 htb rate 12 kbit ceil 64kbit priority 10


tc class add dev ippp0 parent 1:20 classid 1:21 htb rate 11 kbit ceil 64kbit


tc class add dev ippp0 parent 1:20 classid 1:22 htb rate 1 kbit ceil 64kbit


normale Priorität für rest

tc qdisc add dev ippp0 parent 1: classid 1:30 htb rate 1 kbit ceil 64kbit priority 10


Die schlechteste Priorität - nur wenn NIX anderes upstream anliegt - Erklärung folgt

tc qdisc add dev ippp0 parent 1: classid 1:50 htb rate 1 kbit ceil 64kbit priority 50


Dann hätte ich
alles mit dport ssh in 1:10 gelegt,
alles mit https zum Arbeitsserver in die 1:21,
ssh zum Arbeitsserver und pop/smtp zu Arbeitsmailserver in 1:22
und der Rest würde in 1:30 kommen.

Nachdem ich ja Probs downstream habe, war die Idee wie folgt:
Bei denen, die Asynchron sind, findet man öfters die Empfehlung, daß sie die SYN/ACK und ACK höchst priorisieren, damit sie i.d.F. ihren Downstream immer voll bekommen. Meine Idee war nun, alle
ACKs, die nicht zum Arbeitsserver oder den Mail-Servern gehen, automatisch via iptables getagged werden - und dann in die allerletzte Queue kommen. Dadurch müßten die Downloads "außerhalb" der "ArbeitsIPs" langsamer kommen - weil sie seltener ACKs bekommen und daher drosseln müßten.

Ist das eine verfolgbare Idee, oder stellt sich klein-gepeinigter_aon_neukunde wieder mal alles zu einfach vor ?

Antworten PM Alle Chronologisch
 
Melden nicht möglich
.  Re: TC unter Linux  (MidiFan am 14.11.2005, 19:51:22)
..  Re(2): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 19:52:03)
...  Re(3): TC unter Linux  (MidiFan am 14.11.2005, 19:53:34)
....  Re(4): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 20:05:53)
.....  Re(5): TC unter Linux  (MidiFan am 14.11.2005, 20:24:30)
......  Re(6): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 20:29:48)
.......  Re(7): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 20:30:37)
........  Re(8): TC unter Linux  (MidiFan am 14.11.2005, 21:03:07)
.......  Re(7): TC unter Linux  (MidiFan am 14.11.2005, 21:00:31)
.......  Re(7): TC unter Linux  (patos am 14.11.2005, 21:20:09)
........  Re(8): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 21:50:37)
.........  Re(9): TC unter Linux  (patos am 14.11.2005, 21:53:29)
.  Re: TC unter Linux  (patos am 14.11.2005, 20:10:54)
..  Re(2): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 20:16:16)
...  Re(3): TC unter Linux  (patos am 14.11.2005, 20:20:51)
....  Re(4): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 20:27:22)
.....  Re(5): TC unter Linux  (MidiFan am 14.11.2005, 21:04:39)
......  Re(6): TC unter Linux  (gepeinigter_aon_neukunde am 14.11.2005, 21:09:45)
.....  Re(5): TC unter Linux  (patos am 14.11.2005, 21:18:35)
.  Re: TC unter Linux  (mIstA am 17.11.2005, 09:26:33)
..  Re(2): TC unter Linux  (gepeinigter_aon_neukunde am 17.11.2005, 09:46:29)
...  Re(3): TC unter Linux  (mIstA am 17.11.2005, 10:22:43)
....  Re(4): TC unter Linux  (gepeinigter_aon_neukunde am 17.11.2005, 11:05:27)
....
Script...
19.11.2005, 22:21:38
Anbei mein Script... Ich habe reingeschrieben, was man evtl. dazubraucht.
Ich stell's unter GPL - also darf es jeder weiterverwenden...

#!/bin/bash

# (c) Grünwald Michael 2005 - GPLled.
# Nach Muster aus lartc.pdf

# Benötigt wurde:
# iproute2-2.4.7-now-ss020116-try.tar.gz
# htb3.6-020525.tgz
# Getestet bei SuSE8.0, Kernel 2.4.28

# Speeds: Immer etwas geringer als die "reale" um Queues im Modem zu vermeiden
DOWNLINK=63     # ISDN: 63KBit. Modem: 50KBit.
UPLINK=63       # ISDN: 63KBit. Modem: 32KBit
DEV=ippp0       # ISDN: ippp0. Modem: ppp0

#
# Klassen
#
# THEMA         RATE    CEIL    RATE    PRIO    Garantiert      Max
#               Punkte  KBit    KBit            in Byte/sec     in Byte/sec
# HIGH-Prio     50      63      33      1       4224            8064
# ARBEIT        25      56      16      2       2048            7168
# DEFAULT       20      51      13      2       1664            6528
# FTP,MAIL      1       40      1       3       128             5120
# SUMME         93              63
#
# Selber Berechnen wie folgt:
#       - Spreadsheet anlegen
#       - Ratenpunkte Vergeben
#       - CEIL und PRIO manuell festlegen.
#       - RATE berechnet:
#         RATE_KBit(x) = RUNDEN(RATE_Punkte(x)*UPLINK/SUMME_RATE_Punkte.
# Ansatz Prio: Nur das allerwichtigste PRIO1, das allerunwichtigste PRIO3

# --- ROOT ---
ROOT_QDISC=1:
ROOT_CLASS=1:1
ROOT_DEFAULT=50         # Unklassifiziertes nach 1:50

# ---- HIGH_PRIORITY: ACK, ICMP und interacive ---
HIGH_PRIO_CLS=1:10
HIGH_PRIO_RATE=33kbit
HIGH_PRIO_CEIL=63kbit   # Hohe CEIL unnötig. Wenn hier viel landet,
                        # dann war was falsch konfiguriert.
HIGH_PRIO_PRIO=1
HIGH_PRIO_SFQ=10:

# --- ARBEIT: Wichtiger => Arbeit soll schneller fertig sein
ARBEIT_CLS=1:20
ARBEIT_RATE=16kbit
ARBEIT_CEIL=56kbit
ARBEIT_PRIO=2
ARBEIT_SFQ=20:

# --- DEFAULT: Alles unklassifizierte ---
DEFAULT_CLS=1:50
DEFAULT_RATE=13kbit
DEFAULT_CEIL=51kbit
DEFAULT_PRIO=2
DEFAULT_SFQ=50:

# --- MAIL: So langsam wie geht... Hier sparen wir Performance, die wir bei
# priorisierten Diensten gewinnen
MAIL_CLS=1:70
MAIL_RATE=1kbit
MAIL_CEIL=40kbit
MAIL_PRIO=3
MAIL_SFQ=70:

# Verkehr zu welchen Servern kommt in die Arbeitsklasse (priorisiert)
SRV1=1.2.3.4  # EGAL
SRV2=131.130.252.18             # UniVPN

#
# ___ENDE CONFIG___

# Alte Qdiscs löschen
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

#
# Wird in /etc/init.d/rc3.d eingehängt (nach ipppd).
# Bei "start" als Parameter - Definiere. Bei anderen anderen - lösche
if [ "$1" != "start" ]
then
        exit
fi

###### uplink

# root-htb: htb - IMHO die beste QDisc. Unqualifizierter Verkehr nach DEFAULT
tc qdisc add dev $DEV root handle $ROOT_QDISC htb default $ROOT_DEFAULT

# Alles nach $UPLINK-Speed shapen. Wir dürfen keine Queues im Modem erzeugen..
# denn dann hätten wir keine Shape-Möglichkeit mehr - und schlimme Latenzzeiten
tc class add dev $DEV parent $ROOT_QDISC classid $ROOT_CLASS \
        htb rate ${UPLINK}kbit

# Klassen nach Definition anlegen
tc class add dev $DEV parent $ROOT_CLASS classid $HIGH_PRIO_CLS htb \
        rate $HIGH_PRIO_RATE ceil $HIGH_PRIO_CEIL prio $HIGH_PRIO_PRIO
tc class add dev $DEV parent $ROOT_CLASS classid $ARBEIT_CLS htb \
        rate $ARBEIT_RATE ceil $ARBEIT_CEIL prio $ARBEIT_PRIO
tc class add dev $DEV parent $ROOT_CLASS classid $DEFAULT_CLS htb \
        rate $DEFAULT_RATE ceil $DEFAULT_CEIL prio $DEFAULT_PRIO
tc class add dev $DEV parent $ROOT_CLASS classid $MAIL_CLS htb \
        rate $MAIL_RATE ceil $MAIL_CEIL prio $MAIL_PRIO

# All Bekommen  Stochastic Fairness Queueing:
tc qdisc add dev $DEV parent $HIGH_PRIO_CLS handle $HIGH_PRIO_SFQ sfq perturb 10
tc qdisc add dev $DEV parent $ARBEIT_CLS handle $ARBEIT_SFQ sfq perturb 10
tc qdisc add dev $DEV parent $DEFAULT_CLS handle $DEFAULT_SFQ sfq perturb 10
tc qdisc add dev $DEV parent $MAIL_CLS handle $MAIL_SFQ sfq perturb 10

#
# Filter-Regeln: Welcher Verkehr kommt in welche Klasse ?
#

# ICMP (ip protocol 1) Kommt in die höchste Klasse...
# Für Messungen und Eindruck schinden bei PING ;-)

tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 \
        match ip protocol 1 0xff flowid 1:10

# Um Downloads zu beschleunigen wärend wir uploaden kommt ACK in die höchste
tc filter add dev $DEV parent 1: protocol ip prio 1 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# TOS Minimum Delay (ssh, NICHT scp): Nur wenn nicht in anderer Queue erledigt
# Komme auch in höchste Queue.
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid $HIGH_PRIO_CLS

# Arbeitsserver in die zweite Klasse
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 2 u32 \
   match ip dst $SRV1 flowid $ARBEIT_CLS
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 2 u32 \
   match ip dst $SRV2 flowid $ARBEIT_CLS

# Mail ganz nach hinten
# SMTP
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 1 u32 \
   match ip dport 25 0xffff flowid $MAIL_CLS
# POP2
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 1 u32 \
   match ip dport 109 0xffff flowid $MAIL_CLS
# POP3
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 1 u32 \
   match ip dport 110 0xffff flowid $MAIL_CLS

#
# Rest landet in DEFAULT-QUEUE


########## downlink #############

# Downlink shapen, damit wir der Engpaß sind (und nicht der ISP)
tc qdisc add dev $DEV handle ffff: ingress

# *ALLES* filtern (0.0.0.0/0), alles Wegwerfen, was zu schnell kommt

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 3K drop flowid :1


Antworten PM Alle Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung