TC unter Linux
Geizhals » Forum » Netzwerk » TC unter Linux (28 Beiträge, 306 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 Übersicht Chronologisch
 
Melden nicht möglich
.
Re: TC unter Linux
17.11.2005, 09:26:33
Dadurch müßten die Downloads "außerhalb" der "ArbeitsIPs" langsamer kommen -weil sie seltener ACKs bekommen und daher drosseln müßten.


Allerdings wird die Priorisierung nur dann greifen, wenn Dein Upstream überlastet oder zumindest an der Auslastungsgrenze arbeitet, denk ich.


Was eventuell klapen könnte, wäre den Downstream (also konkret die Bandbreite die Du in Dein LAN rein eralubst) für alle nicht-priorisierten Verbindungen drosselst; allerdings geht das vermutlich nur statisch, also unabhängig davon, obs im Moment überhaupt aktive Verbindungen gibt, die Priorität haben sollen - außer indem Du die Drosselung immer von Hand (de)aktivierst.

Ein wesentlicher Nachteil dieses Ansatz ist aber leider, daß damit letztlich bewußt Pakete verworfen werden, die bereits über die (ohnehin überlastete) ISDN-Leitung übertragen wurden. Das wird vermutlich vor allem dann zum Problem werden, wenn die jeweilige Verbindung nicht lang genug besteht, daß sich der Server auf die niedrige Geschwindigkeit einregeln kann. Zusätzliche Probleme könnts eventuell auch durch einen providerseitigen Buffer geben.


Jadenfalls kannst ja ohne Probleme testen, ob bestimmte Shaping-Regeln was bringen; einfach den Downstream mit einem Download blockieren und schauen obs für die interaktiven Verbindungen was bringt.  ;-)

Aber wirklich effizient kannst eine Priorisierung für Deinen Downstram (wahrscheinlich) nur auf der sendenden Seite - also beim Provider; vielleicht gibts ja einen Provider, der das zumindest auf Anfrage als Service anbieten kann.  

lg
 mIstA
Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
....
Re(4): TC unter Linux
17.11.2005, 11:05:27
Natürlich krieg ich kein richtiges QoS hin mit der Bandbreite und ohne eingriff beim Provider...

Ach ja, noch eine blöde Frage:

ISDN bekommt bei mir default MTU (ich vermute im Rahmen der chap-Anmeldung) von 1500 - also dasselbe wie bei ethernet.

Aus dem Bauch raus kommt mir eine MTU von 1500 bei 64KBit extrem hoch vor...

Meine Überlegung war wie folgt:
Die kleinsten MTU's die ich gesehen habe, waren bei AFAIK 536 (Modems vor langer Zeit)... Also könnte es ja Sinn machen, wenn ich die MTU auf viel. 768 reduziere ? Natürlich steigt dann mein Netzwerk-Overhead bei größeren Paketen an - andererseits könnte ich ja doch Interaktivität gewinnen.

Meine größte Sorge dabei ist, daß diverse Clients (Windows) ziemlich sicher bei ihren Paketen das "Don't Fragment"-Bit setzen... Und evtl. keine gute PMTU-Discovery machen.

Ich könnte also:
1.) Bei den Clients fix eine MTU von 768 eintragen - ungut weil Papi's rechner
2.) via iptables folgende Regel bauen:
- wenn ein Paket von eth0 kommt
- und das DF-Bit gesetzt hat
- dann lösche /PREROUTING/ das DF-Bit - und füge es /POSTROUTING/ wieder an
3.) Auf MTU-Modifikationen wegen möglicher Probleme verzichten - und stattdessen via iptables fix postroutung auf ippp0 bei SYN-Paketen eine MSS von 768 anbieten.

Wenn ich es richtig verstanden habe, würde mir dann die Gegenstelle - auf tcp-Verbindungen [udp kann ich mal ignorieren, da kommt bei mir nix so großes her] - nie mehr als 768 bytes auf einmal senden - so als ob ich die MTU gesetzt hätte... Nun denn, dann wird's aber auch nicht gegen das DF-Bit helfen, oder ?

ARGH!
Vor ewigkeiten hab' ich mich mal mit MTU's herumgespielt (wg. TR und ETH im selben Netz)... Dunkel erinner ich mich, daß das die Hölle war... Was huhn ?

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
....
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 Übersicht 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