Netzwerk funktioniert nur teilweise wenn VM auf demselben Host sind

[chipmonk]

'Nabend

Ich hab hier etwas merkwürdiges Phänomen das ich mir nicht so recht erklären kann.
Gegeben ist ein Cluster mit 5 Hosts. Das Netzwerk ist auf allen gleich konfiguriert. Die Firewall ist aus.
Über SDN ist eine Zone mit einfachen VLANS konfiguriert.
Vor dem Cluster sitzt noch eine Hardware-Firewall. Diese macht im wesentlichen NAT.

Um einige Dinge zu testen, wollte ich mir eine Testumgebung bauen, die separat von allem anderen ist.
Dazu habe ich einen einfachen "Router" aufgesetzt. Das Teil ist eine FreeBSD Minimalinstallation mit (zunöchst) 2 virtuellen NICs und IP-Forwarding = an. Keine Firewall, NAT oder sonstwas. Es soll einfach nur die Testnetze miteinander verbinden und als Uplink zur Firewall fungieren. Entsprechend ist eine NIC an der Firewall (VLAN ID 1000).
Die Andere NIC ist im VLAN mit der ID 1100. Dort habe ich einen "Test PC" im selben VLAN.

Ich hänge ein Bild an aus dem ersichtlich wird wie das ganze "logisch gestrickt" ist:



Hardwareseitig sind die 5 Hosts über einen vlan-fähigen Switch verbunden. Die Ports an denen die jeweiligen "Uplinks" der Server hängen sind identisch (und korrekt) konfiguriert.

Nun kannich folgendes beobachten:
Sind beide VM auf unterschiedliche Hosts verteilt, funktioniert alles wie es soll, das heißt der Client kommt über den Router und die Firewall ins Internet.
Sind beide VM jedoch auf demselben Host, funktioniert der "Client" nicht mehr richtig.
Außer "ping" geht nichts mehr durch. Alles andere läuft in "Timeout".

Da es funktioniert wenn die VM auf unterschiedlichen Hosts sind und "ping" noch "durchgeht" schließe ich Fehler im Routing und den VLANS aus.
Geprüft habe ich die natürlich dennoch - mehrfach. Ebenso würde ich, aus demselben Grund, die Firewall ausschließen. Auch hier habe ich intensiv das Regelset geprüft und mit tcpdump versucht herauszufinden wo meine Pakete verschwinden. Interessanterweise sehe ich auch die ausgehenden Pakete vom Client auf den beteiligten Geräten im Pfad, es kommt aber nie eine Antwort.

Es ist auch egal auf welche Hosts ich die beiden VM verteile - solange es zwei unterschiedliche sind, funktioniert es.

Nun bin ich mit meinem Latein etwas am Ende und wäre dankbar für Ideen wo ich ansetzen könnte.

Grüße,
Chip

 

[pixelpeter]

Hi,

Du schreibst wenn die VM auf dem selben Host läuft geht Ping.
Was pingst du an?
Ein Ziel im Internet oder Lokal.
Ansonsten wäre die Netzwerkkonfiguration der beiden VM interessant.

Peter

 

[chipmonk]

Moin

Beides.
Lokal den Router (beide IP Adressen) und die Firewall oder auch "irgendwas anderes" im Netz.
Im Internet teste ich mit 1.1.1.1, 8.8.8.8 und 9.9.9.9


Netzwerkconfig der Linux Mint VM:



Netzwerk Config der FreeBSD Router VM:




Falls was fehlt einfach Bescheid sagen.

Grüße,
Chip

 

[pixelpeter]

Ok.
Wenn die beiden VM auf verschiedenen Hosts laufen kann 10.100.0.3 keinen Ping ins Internet absetzen. Richtig?
Kann es in dem Zustand der 10.100.0.1?
Wie sehen die Routingtabellen auf beiden aus?

Peter

 

[chipmonk]

Wenn die beiden VM auf verschiedenen Hosts laufen kann 10.100.0.3 keinen Ping ins Internet absetzen. Richtig?

Nein. Ping geht immer durch. Egal wo die VM laufen. Alles andere geht nicht wenn sie auf demselbern Host laufen.
Ich mach mal nur mit 2 Hosts - Ist einfacher zu veranschaulichen

Client & Router auf Host 1: Ping geht, nichts anderes
Client auf Host 1, Router auf Host 2: Alles tut wie es soll
Router auf Host 2, Client auf Host 1: Alles tut wie es soll
Client & Router auf Host 2: : Ping geht, nichts anderes

Analog dasselbe mit den anderen Hosts.

Da ich mit ssh nicht rankomme muss ich hier leider mit Screenshots arbeiten. Sonst hätte ich den Text rauskopiert.
Rotuingtabelle Client:


Und Router:


Grüße,
Chip

(Edit: Irgendwie auf den Absendenknopf gekommen, Screenshots angefügt)

 

[pixelpeter]

Aber wenn bspw. Ping zu www.google.de geht, du die Seite aber nicht ansurfen kannst, dann liegt es ja nicht primär an einer fehlerhaften Netzwerkkonfiguration.
Im Browser ist definitiv kein Proxy eingetragen?
Ich würde jetzt schrittweise vorgehen.
Bspw. Könntest du mit wget eine Datei aus dem Netz holen. Wenn das funktioniert dann ist es schon mal kein Firewallproblem. Aber dann muss es auch mit dem Browser gehen. Eigentlich…
Falls nicht würde ich ein traceroute auf das Ziel machen und dann mit dem funktionierenden Zustand vergleichen.

Peter

 

[dj0Nz]

Ich würde da mal die SDN-Konfiguration anschauen. Ist die SDN Bridge VLAN-Aware? Gibts das VLAN auf dem Switch? Können sich die VMs im VLAN 1100 gegenseitig pingen?

 

[chipmonk]

Ahoi

Es ist kein Proxy eingetragen. Und selbst wenn: Es würde nicht das Fehlerbild erklären das es funktioniert jenachdem wie die VM auf die Hosts verteilt sind. "www.google.de" geht entsprechend auch nicht wenn der Fehler auftritt, schon allein deswegen weil er seinen DNS ja auch nicht erreicht.

traceroute google.com scheitert ebenfalls am DNS wenn beide auf dem ersten Host sind, traceroute 8.8.8.8 kommt nur bis zum Router:

wget www.google.com:

wget 8.8.8.8 (da IST normal eine Webseite drauf:



Zum Vergleich: Nachdem ich die Maschine auf den zweiten Host migriert habe, sieht es so aus:

(Externe IP und ersten externen Hop unkenntlich gemacht)
Die Fehler in Hop 8 und 10 sollten für das aktuelle Thema unerheblich sein.

wget "google.com":


Zum Switch und den VLANS:
Der Switch hat die passenden VLANS:

Relevant sind hier die jeweiligen "-data" Interfaces.


Die VM können sich "pingen" - wie gesagt, ping als solches funktioniert immer.
Die Bridge ist VLAN aware (soweit ich das verstanden habe, müsste sie es aber nicht sein, es macht auch keinen unterschied ob ich das ein- oder ausschalte)

Exemplarisch für den ersten Host, Host 2 ist identisch. Hosts 3,4,5 haben andere Hardware, allerdings mit derselben Konfiguration:


eno1 & eno2 sind nicht verwendet. ens1f0 ist das Management Interface. Da ist auch sonst nichts drauf.
ens1f1 ist das Dateninterface auf dem auch die Bridge vmbr0 liegt.

SDN hat genau eine Zone vom Typ "VLAN":




Im oberen Bereich sind "echte" Namen und teilw. Orte zu sehen, daher unkenntlich gemacht.
Das "Lab" soll später noch mehr "simulierte Standorte" enthalten, daher gibts ein paar mehr VLANs - aktuell konzentriere ich mich aber auf "Central" und hier das was als "External" bezeichnet wird.

Und ja: Ich weiß das das völlig absurd ist. Daher fehlt mir auch absolut ein Ansatz wo ich nachschauen kann....

Grüße,

Chip

 

[pixelpeter]

Der Router kann aber egal auf welchem Host er läuft Adressen im Internet anpingen?
Sprich kannst du sicherstellen das vom Router aus alles sauber funktioniert, egal auf welchem Host er läuft?

Wobei ich sagen muss das ich SDN nicht nutze. Nicht das hier eventuell noch ein Bug ist.

Peter

 

[chipmonk]

Hi

Ja, der Router tut wie er soll:
ping -c1 google.com


d.h. DNS funktioniert - Ping ja sowieso

fetch http://www.google.com:


Beide Befehle durchgeführt während die beiden VM auf Host 1 liefen. Wenn ich sie auf andere Hosts migiriere sieht es ähnlich aus.

Was SDN betrifft:
Ich hatte - bevor ich das Cluster vor ein paar Wochen aufgesetzt habe - einigermaßen intensiv getestet allerdings keine VM "hintereinander". Da habe ich keine Problem feststellen können. Zumal das ja auch nur einfache VLANS sind - kein vxLAN etc.

Grüße,

Chip

 

[dj0Nz]

Krass. Ich bau sowas ziemlich oft (mach das beruflich) und die Konfiguration sieht korrekt aus, hab ich gerade vor 1-2 Wochen fast genau so gebaut. Wahrscheinlich ist das irgendeine Kleinigkeit, was man übersieht oder doch ein Bug. Ich persönlich würde da so vorgehen:

• Prüfen, ob sich die Virtual Clients gegenseitig sehen (ping mit abschließendem arp -an bzw. ip neigh)
• Prüfen, ob der Virtual Router die Clients auf dem richtigen Interface sieht (arp -an)
• Am Uplink Interface des Virtual Router einen tcpdump machen (http) und schauen, ob irgendwo Antwortpakete fehlen
• An der Hardware Firewall (internes Interface) einen tcpdump machen und schauen, ob irgendwo Antwortpakete fehlen

Bin ja mal echt gespannt was das ist...

 

[chipmonk]

Moin

Beruflich komme ich aus der Vmware-Ecke. (ja, ich weiß das tun im Moment ganz viele), privat aber aus der Opensource Ecke. Und auch wenn das 5-Node Cluster im privaten Bereich ein eher großes Setup ist: Das Ding steht bei mir im Keller. Ein virtueller Router mit Client dahinter ist für mich auch nichts ungewöhnliches, ich mache das recht oft um Dinge auszuprobieren. Das ist das erste mal das das nicht so tut wie es soll.

Was die Pakete betrifft: Ich hatte eingangs irgendwo geschrieben das ich die ausgehenden Pakete auf dem kompletten Pfad sehen kann, jedoch eben die Antowrten nicht sehe. Mir fällt aber auch nichts besseres ein ;-)

Ausgangssituation: Ich teste mit vhx01 und vhx05.
Router auf vhx01, Client auf vhx05, auf dem Client "wget https://8.8.8.8" ausgeführt.
Auf der Firewall sieht das dann so aus (tcpdump -ni vlan1000 host 10.100.0.3):

Rest abgeschnitten, ich denke ist klar wie es weiter geht

Jetzt migriere ich die Client-VM auf vhx01, der Rotuer bleibt auf vhx01. Dann sieht das auf der Firewall so aus:


Die Anfrage geht raus, aber ich erhalte nie eine Antwort.
Um die Firewall als Ursache auszuschließen habe ich dasselbe mit einer internen Webseite versucht, da sieht das genauso aus.

Wenn ich nun den Router auf vhx05 migriere und den Client auf vhx01 lasse, sieht es wiederum so aus:

(Wieder den Rest der Übertragung abgeschnitten)

Arp auf dem Client nachdem ich jeden (internen) Teil auf dem Pfad einmal gepingt habe:


Macht auch Sinn: Der muss ja in dem Fall nur sein Gateway kennen. Die 10.100.0.2 ist ein anderes Testgerätdas ich gestern im Rahmen der Fehlersuche dazugetan habe. Das sieht er auch und kann es pingen.

Auf dem Router sieht das dann so aus:

Der Rest sieht aus wie erwartet. Das er seine eigenen NICs mit anzeigt ist bei FreeBSD normal.


Grüße,

Chip

 

[dj0Nz]

Hm. Das riecht nach asynchronem Routing. Ist der tcpdump (Client und Router auf vhx01) von der Firewall? Wenn ja, hast Du mal gleichzeitig auf dem externen Interface gesnifft (am besten mit Destination Filter und eine Adresse die sonst niemand aufruft)?

Wenn da Pakete rein und raus gehen, schickt die Firewall das Rückpaket auf dem falschen Interface raus. Wenn da gar keine Syn-Pakete raus gehen, verwirft das die Firewall (warum auch immer) und wenn auf dem externen Interface auch nur Syn-Pakete raus gehen, bin ich noch verwirrter als ich eh schon bin.

Aber ich vermute, die Firewall sieht aus irgendeinem Grund den Vlan 1100 Traffic. Das würde auch erklären, warum der Ping geht und tcp nicht und auch, warum es nicht funktioniert, wenn die VM auf dem gleichen Host wie der Router ist.

 

[chipmonk]

Hi

Ich nehme als Ziel immer noch die 8.8.8.8 - Das ruft bei uns sonst keiner auf. Die externe IP mache ich dabei unkenntlich.
tcpdump aufgerufen mit: tcpdump -ni tun0 host 8.8.8.8

Die drei Abschnitte sind:
1. Ping Test
Ping 8.8.8.8 -> Geht durch

2. DNS Test
nslookup starten,
server 8.8.8.8
google.com
(Wo die Pings dazwischen herkommen weiß ich nicht)

3. http(s) Test:
wget https://8.8.8.8



Ich habe das exakt selbe Verhalten wenn ich als Ziel eine interne Adresse nehme. Dadurch kann ich NAT als Ursache ausschließen.
Das mit dem Routing würde immer noch nicht erklären warum es in der Konstellation "VM auf unterschiedlichen hosts" funktioniert und warum "Ping" durchgeht. Wenn das Routing nicht sauber ist geht ja eigentlich garnix mehr.

Ich hab auch über eine MTU Thematik nachgedacht. Das würde dazu passen das "Ping" (kleine Pakete) durchgehen, große jedoch nicht. Allerdings sind DNS auch kleine Pakete und auch das sollte ja "immer" zutreffen und nicht nur wennVM auf unterschiedliche Hosts verteilt sind. (Für vxLAN muss man an der MTU schrauben, aber das ist ja hier nicht der Fall).

Grüße,

Chip

 

[dj0Nz]

Okay also kann man diverse Dinge ja schon mal ausschließen:

• Kein Layer 2 Problem
• Kein Layer 3 Problem
• Kein Firewall-Problem

Also muss da eigentlich irgendwas in den Paketen selbst "kaputt" sein. Vielleicht mal die MTU am Client auf sagen wir 1300 setzen?

 

[chipmonk]

Moin

Entschuldige bitte die späteAntwort. Mich hats gesundheitlich bissi flach gelegt.
MTU auf 1300 auf allen beteiligten ändert leider auch nichts.



Grüße,
Chip