![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Zurück: Anker] [Inhalt] [Weiter: Adress-Pools und Load Balancing]
Etwas einzureihen heißt, es in Reihe aufzubewahren, während es darauf wartet, verarbeitet zu werden. Wenn Daten-Pakete in einem Computer-Netzwerk von einem Host ausgesendet werden, treten sie eine Warteschlange ein, wo sie darauf warten, vom Betriebssystem verarbeitet zu werden. Das Betriebssystem entscheidet dann, welche Warteschlange und welche(e) Paket(e) von der Warteschlange verarbeitet werden sollten. Die Reihenfolge, in der das Betriebssystem die zu verarbeitenden Pakete auswählt, kann die Leistung vom Netzwerk beeinflussen. Stell dir zum Beispiel vor, ein Benutzer lässt zwei Netzwerk-Anwendungen laufen: SSH und FTP. Idealerweise sollten die SSH-Pakete vor den FTP-Paketen wegen der Zeit-sensiblen Natur von SSH verarbeitet werden; wenn eine Taste im SSH-Client gedrückt wird, wird eine unverzügliche Antwort erwartet, aber wenn eine FTP-Übertragung um ein paar Sekunden verzögert wird, wird es wohl kaum auffallen. Aber was passiert, wenn der Router, der diese Verbindungen handhabt, eine große Portion an Paketen von der FTP-Verbindung verarbeitet, bevor die SSH-Verbindung verarbeitet wird? Pakete von der SSH-Verbindung werden in der Warteschlange verweilen (oder vielleicht sogar vom Router fallengelassen, wenn die Warteschlange nicht groß genug ist, um alle Pakete zu beinhalten) und die SSH-Sitzung wirkt, als wenn sie ,laggt' oder verlangsamt ist. Durch das Modifizieren der Warteschlangen-Strategie, die verwendet wird, kann Netzwerk-Bandbreite gerecht zwischen unterschiedlichen Applikationen, Benutzern und Computern aufgeteilt werden.
Bedenke, dass das Einreihen nur nützlich für Pakete in die ausgehende Richtung ist. Sobald ein Paket auf dem Interface in einer eingehenden Richtung ankommt, ist es bereits zu spät, dieses einzureihen - es hat bereits Netzwerk-Bandbreite verbraucht, um auf dem Interface anzukommen, das es aufgenommen hat. Die einzige Lösung ist, das Einreihen auf dem angrenzenden Router zu aktivieren oder, wenn der Host, der das Paket erhalten hat, als Router fungiert, das Einreihen auf dem internen Interface zu aktiveren, von dem Pakete den Router verlassen.
OpenBSD unterstützt zwei zusätzliche ,scheduler':
CBQ-Warteschlangen werden in einer hierarchischen Manier angeordnet. An oberster Stelle dieser Hierarchie ist die root-Warteschlange, welche die Gesamtgröße der verfügbaren Bandbreite angibt. ,Child'-Warteschlangen werden unter der root-Warteschlange angelegt, der jeder ein Teil der Bandbreite der root-Warteschlange zugewiesen werden kann. Zum Beispiel können Warteschlangen wie folgt definiert werden:
In diesem Fall wird die gesamt verfügbare Bandbreite auf 2 Megabits pro Sekunde (Mbps) gesetzt. Diese Bandbreite wird dann auf drei ,child'-Warteschlangen aufgeteilt.
Die Hierarchie kann weiter aufgegliedert werden, indem Warteschlangen in Warteschlangen definiert werden. Um die Bandbreite auf mehrere verschiedene Benutzer gleich aufzuteilen und ebenfalls ihren Verkehr zu klassifizieren, sodass bestimmte Protokolle anderen nicht Bandbreite wegnehmen, kann eine Warteschlangen-Struktur wie diese definiert werden:
Bedenke, dass die Summe der Bandbreite für jedes Level nicht höher ist, als was der Eltern-Warteschlange zugewiesen wurde.
Eine Warteschlange kann konfiguriert werden, um Bandbreite von seinen Eltern zu leihen, wenn die Eltern genügend Bandbreite zur Verfügung haben, wenn die ,child'-Warteschlangen diesen nicht verwenden. Siehe dir eine Warteschlangen-Einrichtung wie die folgende an:
Wenn Verkehr in der ftp-Warteschlange größer ist als 900 Kbps und Verkehr in der BenutzerA-Queue kleiner ist als 1 Mbps (weil die ssh-Warteschlange weniger als die zugewiesenen 100 Kbps verwendet), wird sich die ftp-Warteschlange die zusätzliche Bandbreite von BenutzerA ausleihen. Auf diesem Weg ist die ftp-Warteschlange in der Lage, mehr Bandbreite zu nutzen, als ihr zugewiesen wurde, wenn eine Überladung stattfindet. Wenn die ssh-Warteschlange nun ihre Last erhöht, wird die geliehene Bandbreite zurückgegeben.
CBQ weist jeder Warteschlange ein Prioritäts-Level zu. Warteschlangen mit einer höheren Priorität werden während der Anhäufung gegenüber den Warteschlangen mit einer geringen Priorität bevorzugt, so lange beide Warteschlangen die gleichen Eltern-Warteschlange haben (mit anderen Worten, so lange beide Warteschlangen im gleichen Zweig der Hierarchie sind). Warteschlangen mit der gleichen Priorität werden in einer ,round-robin'-Manier verarbeitet. Zum Beispiel:
CBQ wird die BenutzerA- und BenutzerB-Warteschlangen in einer ,round-robin'-Manier verarbeiten - keine Warteschlange wird der anderen bevorzugt. Während der Zeit, in der die BenutzerA-Warteschlange verarbeitet wird, wird CBQ ebenfalls die ,child'-Warteschlangen verarbeiten. In diesem Fall hat die ssh-Warteschlange eine höhere Priorität und wird gegenüber der ftp-Warteschlange somit bevorzugt behandelt, wenn das Netzwerk überladen ist. Bedenke, wie die ssh- und ftp-Warteschlangen ihre Prioritäten nicht mit den BenutzerA- und BenutzerB-Warteschlangen vergleichen, weil sie sich nicht auf dem gleichen Ast in der Hierarchie befinden.
Für eine detaillierte Betrachtung der Theorie hinter CBQ, siehe bitte Reference on CBQ.
Die Einreihe-Struktur in PRIQ ist flach - du kannst keine Warteschlangen in Warteschlangen definieren. Die root-Warteschlange, welche die Gesamtgröße der Bandbreite angibt, wird definiert und Unterwarteschlangen werden unter root definiert. Betrachte folgendes Beispiel:
Die root-Warteschlange wurde so definiert, dass ihr 2 Mbps der Bandbreite zur Verfügung stehen und drei Unterwarteschlangen wurden definiert. Die Warteschlange mit der höchsten Priorität (die höchste Prioritätennummer) wird zuerst bedient. Sobald alle Pakete in der Warteschlange verarbeitet wurden, oder wenn festgestellt wird, dass die Warteschlange leer ist, wird PRIQ zur nächsten Warteschlange mit der nächst höchsten Priorität gehen. Innerhalb einer gegebenen Warteschlange werden Pakete in einer ,First in First Out'- (FIFO) Manier verarbeitet.
Es ist wichtig, daran zu denken, dass du, wenn PRIQ verwendet wird, deine Warteschlangen sehr sorgfältig planen musst. Weil PRIQ immer eine höher priorisierte Warteschlange vor einer niedrigeren verarbeitet, ist es möglich für eine höher priorisierte Warteschlange, dazu zu führen, dass Pakete einer niedriger priorisierten Warteschlange verzögert oder fallen gelassen werden, wenn die höher priorisierte Warteschlange einen konstanten Fluss an Paketen erhält.
RED ist nützlich, da es eine Situation verhindert, die als globale Synchronisation bekannt ist, und ist in der Lage, das Anstürmen von Verkehr in Einklang zu bringen. Globale Synchronisation verweist auf den Verlust des gesamten Durchsatzes, weil Pakete von vielen Verbindungen zur gleichen Zeit fallengelassen werden. Wenn zum Beispiel eine Anhäufung auf einem Router eintritt, der den Verkehr für 10 FTP-Verbindungen trägt und Pakete von allen (oder fast allen) dieser Verbindungen fallengelassen werden (wie es der Fall in FIFO-Warteschlangen ist), wird der gesamte Durchsatz drastisch fallen. Dies ist keine ideale Situation, da es dazu führt, dass alle FTP-Verbindungen ihren Durchsatz reduzieren und das dann bedeutet, dass das Netzwerk nicht mehr länger völlig ausgereizt wird. RED verhindert dies, indem die Verbindung, von der Pakete fallengelassen werden sollen, zufällig auswählt, statt alle dafür auszuwählen. Verbindungen, die sehr viel der Bandbreite in Anspruch nehmen, werden wahrscheinlicher Pakete durch das Fallen lassen genommen. Auf diesem Weg werden Verbindungen mit hoher Bandbreite gedrosselt, Anhäufung wird verhindert und das rapide reduzieren des gesamten Durchsatzes wird nicht eintreten. Zusätzlich ist RED in der Lage, das Anstürmen von Verkehr handzuhaben, da er beginnt, Pakete fallen zu lassen, bevor die Warteschlange voll wird. Wenn ein Ansturm an Verkehr durchkommt, wird dort genug Platz in der Warteschlange sein, um die neuen Pakete zu halten.
RED sollte nur benutzt werden, wenn das Transport-Protokoll in der Lage ist, auf Anhäufungs-Anzeichen vom Netzwerk zu antworten. In den meisten Fällen bedeutet das, dass RED nur in einer Warteschlange für TCP-Verkehr und nicht für UDP- oder ICMP-Verkehr genutzt werden sollte.
Für einen detaillierteren Blick auf die Theorie hinter RED, siehe bitte References on RED.
Für weitere Informationen über ECN, lies bitte RFC 3168.
Weil ALTQ mit PF verbunden wurde, muss PF aktiviert werden, damit ,queueing' funktioniert. Anweisungen, wie man PF aktiviert, können in den Ersten Schritten gefunden werden.
,Queueing' wird in pf.conf konfiguriert. Dort gibt es zwei Arten an Direktiven, die genutzt werden, um ,queueing' zu konfigurieren.
Die Syntax für die altq on-Direktive ist:
altq on interface scheduler bandwidth bw qlimit qlim \
tbrsize size queue { queue_list }
Zum Beispiel:
altq on fxp0 cbq bandwidth 2Mb queue { std, ssh, ftp }Dies aktiviert CBQ auf dem fxp0-Interface. Die gesamte verfügbare Bandbreite wird auf 2 Mbps gesetzt. Drei ,child'-Warteschlangen werden definiert: std, ssh und ftp.
Die Syntax für die queue-Direktive ist:
queue name [on interface] bandwidth bw [priority pri] [qlimit qlim] \
scheduler ( sched_options ) { queue_list }
Das oben angegebene Beispiel weiterführend:
queue std bandwidth 50% cbq(default)
queue ssh bandwidth 25% { ssh_login, ssh_bulk }
queue ssh_login bandwidth 25% priority 4 cbq(ecn)
queue ssh_bulk bandwidth 75% cbq(ecn)
queue ftp bandwidth 500Kb priority 3 cbq(borrow red)
Hier werden die Parameter der zuvor definierten ,child'-Warteschlangen gesetzt. Der std-Warteschlange wird eine Bandbreite von 50% der Bandbreite der root-Warteschlange (oder 1 Mbps) zugewiesen und als standardmäßige Warteschlange definiert. Der ssh-Warteschlange werden 25% der Bandbreite der ,root'-Warteschlange (500kb) zugewiesen und beinhaltet ebenfalls zwei ,child'-Warteschlangen, ssh_login und ssh_bulk. Der ssh_login-Warteschlange wird eine höhere Priorität als ssh_bulk gegeben und für beide ist ECN aktiv. Der ftp-Warteschlange wird eine Bandbreite von 500 Kbps zugewiesen und eine Priorität von 3. Sie kann ebenfalls Bandbreite leihen, wenn weitere verfügbar ist, und hat RED aktiviert.
HINWEIS: Jede ,child'-Warteschlange hat ihre eigene Bandbreite angegeben. Ohne Angabe der Bandbreite wird PF der Warteschlange 100% der Bandbreite der Eltern-Warteschlange zuweisen. In diesem Fall wird dies einen Fehler verursachen, wenn die Regeln geladen werden, da, falls eine Warteschlange existiert, die 100% der Bandbreite nutzt, keine weitere Warteschlange auf diesem Level angegeben werden kann, da keine weitere Bandbreite genutzt werden kann.
Um Verkehr einer Warteschlange zuzuweisen, wird das queue-Schlüsselwort in Verbindung mit PFs Filterregeln verwendet. Siehe dir zum Beispiel einen Satz an Filterregeln an, der eine Zeile wie folgende beinhaltet:
pass out on fxp0 proto tcp to port 22
Pakete, die zu dieser Regel zutreffen, können einer bestimmten Warteschlange zugewiesen werden, unter Verwendung des queue-Schlüsselworts:
pass out on fxp0 proto tcp to port 22 queue ssh
Wird von dieser Regel ein Statustabelleneintrag erzeugt, so wird PF die Warteschlange im Statustabelleneintrag erfassen; dies wird für andere Pakete benutzt, die von diesem Eintrag als statthaft erkannt werden:
pass in on fxp0 proto tcp to port 80 queue httpMit dieser Regel werden Pakete, die über fxp0 ausreisen und die der zustandsorientierten Verbindung entsprechen, der http-Warteschlange zugeordnet. Beachte das, obwohl das Schlüsselwort queue mit einer Regel benutzt wird, die eingehenden Datenverkehr filtert, das Ziel darin besteht, eine Warteschlange für ausgehenden Datenverkehr zu spezifizieren; die oben gezeigte Regel reiht nicht einkommende Pakete in die Warteschlange ein.
Wenn das queue-Schlüsselwort mit block-Direktiven verwendet wird, werden jegliche resultierende ,TCP RST'- oder ,ICMP Unreachable'-Pakete dieser angegebenen Warteschlange zugewiesen.
Bedenke, dass das Bestimmen der Warteschlangen auf einem anderen Interface stattfinden kann als auf dem, auf dem die altq on-Direktive angegeben wurde:
altq on fxp0 cbq bandwidth 2Mb queue { std, ftp }
queue std bandwidth 500Kb cbq(default)
queue ftp bandwidth 1.5Mb
pass in on dc0 proto tcp to port 21 queue ftp
»Queueing« wird auf fxp0 aktiviert, aber die Designierung findet auf dc0 statt. Wenn Pakete, die dieser pass-Regel (oder dem vom ihr erzeugten Zustand) entsprechen die Schnittstelle fxp0 verlassen, so werden sie in die Warteschlange ftp eingereiht. Diese Art Warteschlange kann auf Routern sehr nützlich sein.
Normalerweise wird nur ein Warteschlangen-Name mit dem queue-Schlüsselwort angegeben, aber wenn ein zweiter Name angegeben wurde, dann wird diese Warteschlange für Pakete mit einem Type of Service (ToS) von ,low-delay' und für ,TCP ACK'-Pakete mit keinem Daten-,payload' verwendet. Ein gutes Beispiel hierfür kann in der Verwendung von SSH gefunden werden. SSH-Login-Sitzungen werden das ToS auf ,low-delay' setzen, während SCP- und SFTP-Sitzungen das nicht machen. PF kann diese Information verwenden, um Warteschlangen-Pakete, die zu einer Login-Verbindung gehören, in eine andere Warteschlange zu stecken, als sie für Nicht-Login-Verbindungen genutzt werden. Dies kann nützlich sein, um Login-Verbindungspakete gegenüber Dateitransfer-Paketen zu bevorzugen.
pass out on fxp0 from any to any port 22 queue(ssh_bulk, ssh_login)
Dies weist Pakete, die zu einer SSH-Login-Sitzung gehören, zu der ssh_login-Warteschlange zu und Pakete, die zu SCP- und SFTP-Sitzungen gehören, zu der ssh_bulk-Warteschlange. SSH-Login-Verbindungen werden dann ihre Pakete früher verarbeitet bekommen als SCP- und SFTP-Verbindungen, da die ssh_login-Warteschlange eine höhere Priorität hat.
,TCP ACK'-Pakete einer höher priorisierten Warteschlange hinzuzufügen ist sinnvoll, wenn man asymmetrische Verbindungen hat, das heißt, Verbindungen, die eine andere Upload- als Download-Bandbreite haben, wie zum Beispiel ADSL-Verbindungen. Wenn bei einer ADSL-Verbindung der Upload-Kanal ausgereizt ist und ein Download gestartet wird, wird der Download benachteiligt, da die ,TCP ACK'-Pakete, die gesendet werden müssen, in eine Anhäufung geraten, wenn sie durch den Upload-Kanal gelangen wollen. Tests haben gezeigt, dass das beste Resultat erzielt werden kann, wenn die Bandbreite für die Upload-Warteschlange auf einen kleineren Wert gesetzt wird, als die Verbindung hergeben könnte. Wenn zum Beispiel eine ADSL-Verbindung einen maximalen Upload von 640 Kbps hat, wird das Setzen von bandwith der root-Warteschlange auf einen Wert wie zum Beispiel 600 Kb bessere Leistung erbringen. Versuch und Irrtum werden die beste bandwidth-Einstellung liefern.
[ Alice ] [ Charlie ]
| | ADSL
---+-----+-------+------ dc0 [ OpenBSD ] fxp0 -------- ( Internet )
|
[ Bob ]
In diesem Beispiel wird OpenBSD auf einem Internet-Gateway für ein kleines Heim-Netzwerk mit drei Workstations verwendet. Das Gateway führt das Filtern von Paketen und NAT-Dienste aus. Die Internetverbindung ist ein ADSL-Anschluss, der mit 2 Mbps ,down' und 640 Kbps ,up' läuft.
Die ,queueing'-Richtlinie für dieses Netzwerk:
Es folgt der Regelsatz, der dieser Netzwerk-Richtlinie entspricht. Beachte, dass nur jene pf.conf-Direktiven, die direkt obiger Richtlinie entsprechen, dargestellt werden.
# enable queueing on the external interface to control traffic going to
# the Internet. use the priq scheduler to control only priorities. set
# the bandwidth to 610Kbps to get the best performance out of the TCP
# ACK queue.
altq on fxp0 priq bandwidth 610Kb queue { std_out, ssh_im_out, dns_out, \
tcp_ack_out }
# define the parameters for the child queues.
# std_out - the standard queue. any filter rule below that does not
# explicitly specify a queue will have its traffic added
# to this queue.
# ssh_im_out - interactive SSH and various instant message traffic.
# dns_out - DNS queries.
# tcp_ack_out - TCP ACK packets with no data payload.
queue std_out priq(default)
queue ssh_im_out priority 4 priq(red)
queue dns_out priority 5
queue tcp_ack_out priority 6
# enable queueing on the internal interface to control traffic coming in
# from the Internet. use the cbq scheduler to control bandwidth. max
# bandwidth is 2Mbps.
altq on dc0 cbq bandwidth 2Mb queue { std_in, ssh_im_in, dns_in, bob_in }
# define the parameters for the child queues.
# std_in - the standard queue. any filter rule below that does not
# explicitly specify a queue will have its traffic added
# to this queue.
# ssh_im_in - interactive SSH and various instant message traffic.
# dns_in - DNS replies.
# bob_in - bandwidth reserved for Bob's workstation. allow him to
# borrow.
queue std_in bandwidth 1.6Mb cbq(default)
queue ssh_im_in bandwidth 200Kb priority 4
queue dns_in bandwidth 120Kb priority 5
queue bob_in bandwidth 80Kb cbq(borrow)
# ... in the filtering section of pf.conf ...
alice = "192.168.0.2"
bob = "192.168.0.3"
charlie = "192.168.0.4"
local_net = "192.168.0.0/24"
ssh_ports = "{ 22 2022 }"
im_ports = "{ 1863 5190 5222 }"
# filter rules for fxp0 inbound
block in on fxp0 all
# filter rules for fxp0 outbound
block out on fxp0 all
pass out on fxp0 inet proto tcp from (fxp0) queue(std_out, tcp_ack_out)
pass out on fxp0 inet proto { udp icmp } from (fxp0)
pass out on fxp0 inet proto { tcp udp } from (fxp0) to port domain \
queue dns_out
pass out on fxp0 inet proto tcp from (fxp0) to port $ssh_ports \
queue(std_out, ssh_im_out)
pass out on fxp0 inet proto tcp from (fxp0) to port $im_ports \
queue(ssh_im_out, tcp_ack_out)
# filter rules for dc0 inbound
block in on dc0 all
pass in on dc0 from $local_net
# filter rules for dc0 outbound
block out on dc0 all
pass out on dc0 to $local_net
pass out on dc0 proto { tcp udp } from port domain to $local_net \
queue dns_in
pass out on dc0 proto tcp from port $ssh_ports to $local_net \
queue(std_in, ssh_im_in)
pass out on dc0 proto tcp from port $im_ports to $local_net \
queue ssh_im_in
pass out on dc0 to $bob queue bob_in
|
( IT Abt ) [ PC vom Chef ]
| | T1
--+----+-----+---------- dc0 [ OpenBSD ] fxp0 -------- ( Internet )
| fxp1
[ COMP1 ] [ WWW ] /
| /
--+----------'
In diesem Beispiel fungiert der OpenBSD-Host als eine Firewall für ein Firmen-Netzwerk. Die Firma betreibt einen WWW-Server in dem DMZ-Bereich ihres Netzwerks, in dem Kunden ihre Webseiten per FTP hochladen können. Die IT-Abteilung hat ihr eigenes Subnetz zum Haupt-Netzwerk verbunden und der Chef hat einen PC auf seinem Schreibtisch, der für E-Mails und zum Surfen im Web verwendet wird. Die Verbindung zum Internet ist über einen T1-Anschluss realisiert, der mit 1.5 Mbps in beide Richtungen läuft. Alle anderen Netzwerksegmente verwenden Fast Ethernet (100 Mbps).
Der Netzwerkadministrator hat sich für die folgende Richtlinie entschieden:
Weiter unten ist der Regelsatz, der dieser Netzwerk-Richtlinie entspricht. Bedenke, dass nur die pf.conf-Direktiven, die direkt für diese Richtlinie gelten, vorhanden sind; nat, rdr, Optionen etc. werden nicht gezeigt.
# enable queueing on the external interface to queue packets going out
# to the Internet. use the cbq scheduler so that the bandwidth use of
# each queue can be controlled. the max outgoing bandwidth is 1.5Mbps.
altq on fxp0 cbq bandwidth 1.5Mb queue { std_ext, www_ext, boss_ext }
# define the parameters for the child queues.
# std_ext - the standard queue. also the default queue for
# outgoing traffic on fxp0.
# www_ext - container queue for WWW server queues. limit to
# 500Kbps.
# www_ext_http - http traffic from the WWW server; higher priority.
# www_ext_misc - all non-http traffic from the WWW server.
# boss_ext - traffic coming from the boss's computer.
queue std_ext bandwidth 500Kb cbq(default borrow)
queue www_ext bandwidth 500Kb { www_ext_http, www_ext_misc }
queue www_ext_http bandwidth 50% priority 3 cbq(red borrow)
queue www_ext_misc bandwidth 50% priority 1 cbq(borrow)
queue boss_ext bandwidth 500Kb priority 3 cbq(borrow)
# enable queueing on the internal interface to control traffic coming
# from the Internet or the DMZ. use the cbq scheduler to control the
# bandwidth of each queue. bandwidth on this interface is set to the
# maximum. traffic coming from the DMZ will be able to use all of this
# bandwidth while traffic coming from the Internet will be limited to
# 1.0Mbps (because 0.5Mbps (500Kbps) is being allocated to fxp1).
altq on dc0 cbq bandwidth 100% queue { net_int, www_int }
# define the parameters for the child queues.
# net_int - container queue for traffic from the Internet. bandwidth
# is 1.0Mbps.
# std_int - the standard queue. also the default queue for outgoing
# traffic on dc0.
# it_int - traffic to the IT Dept network; reserve them 500Kbps.
# boss_int - traffic to the boss's PC; assign a higher priority.
# www_int - traffic from the WWW server in the DMZ; full speed.
queue net_int bandwidth 1.0Mb { std_int, it_int, boss_int }
queue std_int bandwidth 250Kb cbq(default borrow)
queue it_int bandwidth 500Kb cbq(borrow)
queue boss_int bandwidth 250Kb priority 3 cbq(borrow)
queue www_int bandwidth 99Mb cbq(red borrow)
# enable queueing on the DMZ interface to control traffic destined for
# the WWW server. cbq will be used on this interface since detailed
# control of bandwidth is necessary. bandwidth on this interface is set
# to the maximum. traffic from the internal network will be able to use
# all of this bandwidth while traffic from the Internet will be limited
# to 500Kbps.
altq on fxp1 cbq bandwidth 100% queue { internal_dmz, net_dmz }
# define the parameters for the child queues.
# internal_dmz - traffic from the internal network.
# net_dmz - container queue for traffic from the Internet.
# net_dmz_http - http traffic; higher priority.
# net_dmz_misc - all non-http traffic. this is also the default queue.
queue internal_dmz bandwidth 99Mb cbq(borrow)
queue net_dmz bandwidth 500Kb { net_dmz_http, net_dmz_misc }
queue net_dmz_http bandwidth 50% priority 3 cbq(red borrow)
queue net_dmz_misc bandwidth 50% priority 1 cbq(default borrow)
# ... in the filtering section of pf.conf ...
main_net = "192.168.0.0/24"
it_net = "192.168.1.0/24"
int_nets = "{ 192.168.0.0/24, 192.168.1.0/24 }"
dmz_net = "10.0.0.0/24"
boss = "192.168.0.200"
wwwserv = "10.0.0.100"
# default deny
block on { fxp0, fxp1, dc0 } all
# filter rules for fxp0 inbound
pass in on fxp0 proto tcp from any to $wwwserv port { 21, \
> 49151 } queue www_ext_misc
pass in on fxp0 proto tcp from any to $wwwserv port 80 queue www_ext_http
# filter rules for fxp0 outbound
pass out on fxp0 from $int_nets
pass out on fxp0 from $boss queue boss_ext
# filter rules for dc0 inbound
pass in on dc0 from $int_nets
pass in on dc0 from $it_net queue it_int
pass in on dc0 from $boss queue boss_int
pass in on dc0 proto tcp from $int_nets to $wwwserv port { 21, 80, \
> 49151 } queue www_int
# filter rules for dc0 outbound
pass out on dc0 from dc0 to $int_nets
# filter rules for fxp1 inbound
pass in on fxp1 proto { tcp, udp } from $wwwserv to port 53
# filter rules for fxp1 outbound
pass out on fxp1 proto tcp to $wwwserv port { 21, \
> 49151 } queue net_dmz_misc
pass out on fxp1 proto tcp to $wwwserv port 80 queue net_dmz_http
pass out on fxp1 proto tcp from $int_nets to $wwwserv port { 80, \
21, > 49151 } queue internal_dmz
|
[Zurück: Anker] [Inhalt] [Weiter: Adress-Pools und Load Balancing]
![[zurück]](../../../images/back.gif){kind=small}
www@openbsd.org