Verbindungsabbrüche durch route-to Regel

[KBr]

Moin zusammen,

ich habe neben anderen Dingen folgende Konstruktion in meiner pf.conf:

table <INT> { 172.16.0.0/16, 192.168.0.0/24, 192.168.1.0/24 }
pass in on vlan7 inet from {vlan7:network} to !<INT> route-to (vlan7 192.168.1.254)

Sinn der Konstruktion ist, allen Netzwerktraffik, der aus dem Subnetz 192.168.1.0 kommt und nicht für das lokale Netz bestimmt ist, auf deren eigene DSL-Box umzubiegen. Das ist so nötig, weil ich die (autonome) Abteilung nachträglich in das übrige Netz integriert habe und die Wert darauf legen, sich beim Internetzugang nicht zu verschlechtern. Alle anderen müssen sich leider eine relativ schmalbrüstige Internetverbindung teilen.
Das funktioniert (dank dieses Forums übrigens) auch soweit ganz gut.
Nur: wenn die in dem Subnetz größere Downloads machen oder youtube-Videos gucken, führt das zu Verbindungsabbrüchen. Videos ruckeln nur, aber Downloads brechen regelmäßig ab.
Kann mir da jemand auf die Sprünge helfen?

Herzliche Grüße

 

[morph]

Tach,

wäre es möglich dem DSL-Router der Abteilung ein eigenes Interface an deinem PF-Gateway zu geben? Ich könnte mir nämlich vorstellen, dass deine Anwendung von route-to nicht 100% das ist, was sich die Entwickler dabei gedacht haben. Das war so meine erste Idee.

Die zweite Idee wäre, mit einem Sniffer im lokalen Netz nach ungewöhnlichen ICMP-Redirects zu schauen. Vielleicht bringt dich das auf die richtige Spur. Eventuell auch mal am PF-Gateway tcpdump benutzen.

MfG
morph

 

[KBr]

Tach,

wäre es möglich dem DSL-Router der Abteilung ein eigenes Interface an deinem PF-Gateway zu geben? Ich könnte mir nämlich vorstellen, dass deine Anwendung von route-to nicht 100% das ist, was sich die Entwickler dabei gedacht haben. Das war so meine erste Idee.

Das wäre ja einfach. Dann könnte ich einfach queues einrichten und fertig. Leider geht das nicht, weil die räumlich weit getrennt sind und ich nur eine Leitung in die Abteilung habe.

Die zweite Idee wäre, mit einem Sniffer im lokalen Netz nach ungewöhnlichen ICMP-Redirects zu schauen. Vielleicht bringt dich das auf die richtige Spur. Eventuell auch mal am PF-Gateway tcpdump benutzen.

MfG
morph

Mein Problem ist, dass ich mir nicht vorstellen kann, was mein Router überhaupt mit den Downloads der Abteilung zu tun hat.
Auf den Hosts der Abteilung ist mein Router als default gateway eingetragen, damit die in die übrigen Subnetze kommen. Mal angenommen 192.168.1.10 schickt ein Paket mit einer Download-Anforderung raus, dann entfernt mein Router (192.168.1.5) nur den Frame, erzeugt einen neuen mit der MAC des Abteilungsrouters als Zieladresse und schickt den wieder raus, ohne das Paket anzufassen.
Der Abteilungsrouter entfernt den Frame, ändert die Absende-IP in seine eigene und schickt das Paket ins Internet. Kommt ein Antwortpaket, wird seine Zieladresse durch die ursprüngliche Zieladresse (192.168.1.10) ersetzt und ein Frame drum rum gemacht, was das Paket direkt an 192.168.1.10 zustellt. Der default router ist an dem einlaufenden Traffic nicht mehr beteiligt.
Ich kann mir im Moment nur vorstellen, dass es in der Flusssteuerung durch den Redirect des ausgehenden Verkehrs zu einem Timingproblem kommt. Wobei mir die Fantasie fehlt, mir vorzustellen, wodurch das verursacht wird.

 

[Crest]

Definiere dir Mirroring Ports in den relevanten Switches und guck nach was da passiert. Mein Verdacht wäre das du nur in eine Richtung umleitest und eine unzuverlässige asymetrische Rückroute hast.

 

[KBr]

Definiere dir Mirroring Ports in den relevanten Switches und guck nach was da passiert. Mein Verdacht wäre das du nur in eine Richtung umleitest und eine unzuverlässige asymetrische Rückroute hast.

Ich bin mir jetzt nicht ganz sicher, ob ich verstanden hab, was du meinst.
An der Geschichte sind nur zwei Switches beteiligt. In dem betreffenden Subnetz haben die nur einen dummen Workgroup-Switch, an dem knapp 20 Maschinen und deren Router hängen. Die Verbindung zu meinem Netz läuft auf meinem Switch im Hauptverteiler auf, an dem auch mein Router direkt hängt. Nur auf dem könnte ich mir angucken, was passiert.
Wenn man in dem betreffenden Netz an einen Rechner den default gateway auf deren Router direkt einstellt, geht alles klar. Insofern geh ich davon aus, dass bei denen auf Layer 2 und 3 keine Probleme auftreten. Das könnte jetzt sein, dass mein Switch im Hauptverteiler zickt, aber dann würde ich erwarten, dass ich solche Probleme auch in meinem Netz habe, es sei denn, die treten nur auf dem Port auf, der die Verbindung in die Abteilung hält. Allerdings läuft die Kommunikation nur in Richtung Internet über meinen Router. Der Download erfolgt direkt. Die Flusssteuerung für die bestehende Verbindung läuft dann zuerst auf meinen Router und wird dann an den Router der Abteilung weitergereicht. Erst da passiert dann was mit den Paketen. Mein Router fasst die ja gar nicht erst an.
Ich hab so den Gedanken, dass es da ein Latenz-Problem gibt, das auf deren DSL-Router oder auf deren Rechnern möglicherweise irgendwas überlaufen lässt, bevor die Flusssteuerung die Fenstergröße runter holen kann. Bei normalem Internet-Traffic haben die mit der Konstruktion kein Problem. Das tritt nur bei so Streaming-Sachen wie youtube und bei Downloads auf. Ich hab aber nicht die leiseste Idee, wie man sowas untersuchen könnte.

 

[morph]

Ich glaube, dass du dir mit route-to in deiner Konstellation keinen Gefallen getan hast. Der einfachste Weg das Problem zu lösen sieht für mich so aus.

1. Auf dem DSL Router der Abteilung die Routen ins interne Netz der Firma bekanntgeben. Also so, dass der DSL Router weiß, dass das 172er Netz über dein PF-Gateway zu erreichen ist.
2. Den Clients der Abteilung den DSL-Router als default-gateway bekanntgeben.
3. den route-to Kram vom PF-Gateway nehmen.
4. Den rest macht ICMP redirect für dich.

 

[KBr]

Ich glaube, dass du dir mit route-to in deiner Konstellation keinen Gefallen getan hast. Der einfachste Weg das Problem zu lösen sieht für mich so aus.

1. Auf dem DSL Router der Abteilung die Routen ins interne Netz der Firma bekanntgeben. Also so, dass der DSL Router weiß, dass das 172er Netz über dein PF-Gateway zu erreichen ist.
2. Den Clients der Abteilung den DSL-Router als default-gateway bekanntgeben.
3. den route-to Kram vom PF-Gateway nehmen.
4. Den rest macht ICMP redirect für dich.

Das war auch meine erste Idee, aber leider bietet die eingesetzte Kiste keine Möglichkeit, statische Routen anzulegen. Ich hatte die Hoffnung, die Notwendigkeit einer Neuanschaffung zu umgehen. Aber wahrscheinlich hast Du damit Recht, dass das der einfachere Weg ist. Trotzdem würde ich gerne verstehen, wo das Problem liegt.