PF ALTQ Anfängerfragen (3-Way Router)

[namor]

Hi erstmal!

Also, ich habe mir vor wenigen Tagen endlich einen schönen Home-NAT-Router gebaut mit FreeBSD 9.1 (RC2) und möchte damit jetzt Traffic Shaping betreiben.

Etwas belesen in einer Kopie vom Book of PF, pf.conf(5) und diversen Blogposts bin ich nun erfolgreich verwirrt.

Ich fange mal damit an, was ich als Aufbau habe:

<modem> ....(pppoe/tun0)....... <ROUTER> ...(10.77.0.0/16)...... <wlan-ap>
                                        |
                                        | (10.0.0.0/16)
                                        |
                               ___<switch>__
                               |         |           |
                             PC1    PC2      PC3

Nun zum Ziel:
Die WAN/tun0/PPPoE Verbindung ist begrenzt, vor allem der Downstream ist problematisch wenn hier jemand Flash Videos vorlädt oder Downloads macht. Daher möchte ich den _Downstream_ in Klassen unterteilen und einige davon priorisieren.

Ich habe nun gelesen, dass Traffic Shaping mit ALTQ nur bei _ausgehenden_ Verbindungen funktioniert. Das heißt, würde ich die Regeln (altq on $if ...) für tun0 aktivieren, wäre das nur für den _upload_. (raus aus dem Router ins WAN).

Testeshalber habe ich das WLAN ignoriert und das Shaping daher nur auf $if_lan (10.0.0.0) aktiviert:

altq on $lan_if bandwidth 100Mb cbq queue { traffic_local, traffic_nat }
queue traffic_local bandwidth 84Mb priority 1 cbq(default, borrow)
queue traffic_nat   bandwidth 13.5Mb priority 2 cbq \
{ nat_https, nat_flash, nat_http, nat_ssh_bulk, nat_ssh_inter}
... (subqueues mit Prioritäten)

Das hat soweit geklappt. Dazu gibt's noch folgende Queue Regeln, die ich nach der PF FAQ als pass in Regeln erstellt habe, damit die rück (downstream) IP Pakete von den akzeptierten TCP Verbindungen auf dem weg ins LAN gequeued werden:

pass in on $lan_if proto tcp from $lan_net to \
    ! $lan_net queue traffic_nat
pass in on $lan_if proto tcp from $lan_net to \
    ! $lan_net port http queue nat_http
pass in on $lan_if proto tcp from $lan_net to \
    ! $lan_net port https queue nat_https
pass in on $lan_if proto tcp from $lan_net to \
    ! $lan_net port { 1935, 8134, 1111 } queue nat_flash
... (restliche Queues...)

Das hat soweit halbwegs funktioniert. Ich muss wohl noch an den Prioritäten tunen, aber mit

pfctl -vvss

konnte ich zumindest überprüfen, dass die Pakete richtig einsortiert werden.

Natürlich ist das ganze Queueing nicht Sinnvoll, wenn es nur die LAN-Nutzer betrifft. Im WLAN geht immer noch die Post ab und wenn da jemand ein Flash Video lädt oder Bittorrent anschmeist kann niemand mehr SSH nutzen oder online spielen...

Im WLAN alle Queues noch einmal zu duplizieren ist nicht nur unschön, sondern auch sinnlos, da es dann für WLAN und LAN getrennte Bandbreite gäbe - tatsächlich kommen aber alle Pakete von tun0, es gibt also nur einmal Bandbreite. (also braucht es eine Parent Queue für beide..)

Mir kommt in den Sinn mit virtuellen Interfaces zu arbeiten, wo dann alles aus tun0 erstmal hin _rausgeht_ um mit ALTQ bearbeitet zu werden, um dann an WLAN/LAN aufteteilt zu werden, aber das kommt mir extrem unsinnig vor.

Habe ihr einen Vorschlag, wie ich LAN+WLAN Traffic Shapen kann mit ALTQ?
Nochmal zur Erinnerung: Es gibt 3 Interfaces: tun0, $if_lan und $if_wlan. Gesucht ist Shaping vom Downstream von tun0 -> {$if_lan, $if_wlan}.

Vielen Dank für's Lesen!

[Crest]

Es macht in 99,9999% der Fälle keinen Sinn einkommenden Traffic zu filtern, denn die limitierte Ressource wurde bereits verbraucht bevor der der Trafficshaper zur Wirkung kommt. Du müsstest also am anderen Ende shapen. Ein Privatkunden ISP wird dir natürlich dabei nicht entgegenkommen. Du kannst allerdings durch Zurückhalten der ACKs auf TCP Einfluss nehmen.

[namor]

Hallo Crest!

Zitat von Crest

Es macht in 99,9999% der Fälle keinen Sinn einkommenden Traffic zu filtern, denn die limitierte Ressource wurde bereits verbraucht bevor der der Trafficshaper zur Wirkung kommt. Du müsstest also am anderen Ende shapen. Ein Privatkunden ISP wird dir natürlich dabei nicht entgegenkommen. Du kannst allerdings durch Zurückhalten der ACKs auf TCP Einfluss nehmen.

In der ausführlichen Anleitung hier wird dazu folgendes gesagt:

It might come as a surprise that you can only queue packets going out of an interface with PF and ALTQ. Misinformed PF users will tell you that this is because you can't shape inbound traffic, because it has already come in, so what's the point of shaping it? This isn't true, because when packets drop along a connection the sending host will send packets at a slower rate. See my threads on this here and here.

Ich will dich da jetzt nicht transitiv als "misinformed pf user" bezeichnen. :-)
Die Erklärung ist aber für mich sehr plausibel und hat im meinem Test (der das WLAN-IF ignoriert) sogar halbwegs funktioniert: Ich konnte trotz viele gleichzeitiger http-downloads noch vernünftig interaktiv ssh nutzen.

TCP ist halt so konzepiert, dass der Sender drosselt wenn Pakete verloren gehen (das ist ja auch die einzige Mögl. herauszufinden, wie schnell er senden darf). Daher möchte ich sobald das (hart gesetzt Limit von 13.5Mb) erreicht wird Pakete im Downstream droppen nach Priorisierung. Das führt genau zu dem was du beschrieben hast: Die TCP-ACKs bleiben aus und der Sender im Internet drosselt.

Klar wäre es schöner, wenn man drosseln könnte bevor Pakete die PPPoE Leitung durchqueren, aber da müsste der ISP mir Zugriff auf seine pf.conf geben. :-)

[makenoob]

wenn es dir um die ssh-Nutzung geht, dann bevorzuge die ausgehenden Pakete im Router.

[Bummibaer]

Hi,
durch legen eines Feuers in der Ortsvermittlungsstelle kannst Du auch ganz ohne ALTQ Einfluss auf den Traffic und die Bandbreite nehmen

Es war einmal ....
... Brand ...
Hitzemelder -> zu warm -> mehr Lüftung - yeaah!
- OVST abgebrannt -
- OVST neu errichtet -
Fazit: doppelt so viel Bandbreite wie davor

Gruß Bär