Und gleich das nächste Netzwerk issue!

Hatte doch vorgestern alles sooo schön geklappt: verbinden, weiterspringen, befehle absetzen – alles wunderbar…
Und gestern Abend das ganze nochmal probiert… verbinden, weiterspringen, befehle absetzen, daten bew…f..k. scp läuft sich tot und auf der anderen Seite… nur eine leere datei. Versucht man etwas grösseres anzeigen zu lassen gibt die Verbindung den Geist auf.
Alles was wenig Daten übermittelt… funktionierte immer noch wunderbar.

Eine Frust-fahrt durch München, mit anschliessendem Frust-essen beim Schachtelwirt später…
Nochmal Anleitungen gewälzt, nach vergleichbaren Vorfällen im internet gesucht und… nix gefunden.
Ich konnte es nur auf die vorgestern erstellte Verbindung eingrenzen… aber das hatte ich mir eh schon gedacht.
Also nochmal die Anleitung von vlan/svlan angeschaut:

…Packets transmitted through a vlan or svlan interface will be encapsulated in their respective protocols and transmitted on the specified physical interface…

Moment „encapsulated“… da war doch was… vor ein paar Monaten… mit meinem Teamleader zusammen… an einer pfSense… ich weiss zwar nicht mehr was genau die Symptome waren… aber im Endeffekt waren die Pakete zu gross und blieben deshalb in einem IPSec Tunnel stecken.
Er hatte dann auch noch einen mini Hinweis in den tiefen der pfSense Anleitungen gefunden und den Tipp dazu, man solle es bei so einem Vorfall mit einer kleineren MTU probieren.
Ok… es kann ja nicht schaden das auch mal in meiner Testumgebung zu probieren. Und was soll ich sagen? Bei einer MTU von 1300 und 1400 war das Problem verschwunden und mit einstellen auf 1500 tauchten die Symptome wieder auf.

Eingestellt hatte ich es an den SVLAN Devices direkt. Mit:

ifconfig svlan0 mtu 1400

Es soll auch an der Route funktionieren … das müsste ich allerdings erst ausprobieren, und ist wahrscheinlich etwas mehr Arbeit wenn man mehrere Netzwerke hinter einem Gateway hat.
Da die Nutzlast jetzt verkleinert wurde bewegen sich auch mehr Pakete* durchs diese Route… muss mal gucken ob ich das weiter hinten dann auch identifizieren kann. Oder noch besser vorne.

UPDATE 2018-08-11 09:25:
Die /etc/hostname.svlan0 auf den Routern sehen jetzt so aus:

puffy-2# cat /etc/hostname.svlan0
inet 172.16.56.1 255.255.255.240
parent em0 vnetid 20
mtu 1400
!route add 172.16.71.0/24 172.16.56.2
!route add 172.16.79.0/24 172.16.56.2
!route add 172.16.65.0/24 172.16.56.2
puffy-lab-1# cat /etc/hostname.svlan0
inet 172.16.56.2 255.255.255.240
parent em3 vnetid 20
mtu 1400
!route add <tunnel netzwerk> 172.16.56.1

*Und um mal die Dimensionen zu zeigen bei einem MiB Nutzlast:

for i in 1500 1400 1300; do oh=$((i-28));echo Anzahl der Pakete fuer einen MiB bei MTU $i: $((1024*1024/oh+1));done
Anzahl der Pakete fuer einen MiB bei MTU 1500: 713
Anzahl der Pakete fuer einen MiB bei MTU 1400: 765
Anzahl der Pakete fuer einen MiB bei MTU 1300: 825

Den minimale Rechenfehler (wenn Modulo==0 addiere 0 statt 1) lass ich mal drin.

Dieser Beitrag wurde unter APU4b4, Hardware, Netzwerk, OpenBSD, routing veröffentlicht. Setze ein Lesezeichen auf den Permalink.