Offloader - Kein FF DHCP im Client Netz


#1

Hallo alle zusammen,

Ich brauch nun doch mal Hilfe, Ich versuche seit mehreren Tagen einen VMOffloader zum laufen zu bekommen.

Der Offloader selber läuft auch ohne Probleme ich konnte ihn Konfigurieren er bekommt eine IP aus meinem Netz und er ist auch offline auf der Map und die GW kann ich auch anpingen. Die VLAN-Konfig am VSwitch stimmt auch. Also von der Seite alles gut. Auch die VLan Konfig dahinter stimmt.

Die VM hatte auch zwei interface beim ersten starten also ist der Stolperstein auch raus.

Nun hab ich aber das Problem das ich keine IP aus dem FF netz bekomme. Ich kann machen was ich will. geht einfach nicht.

Habt ihr da eine Idee wo ich die Suche ansetzen kann oder wo das Problem sein könnte?


#2

Welche Virtualisierungslösung nutzt du?

Bei den meisten muss man für die NICs den Promiscuous Mode erlauben, da das aktuelle Gluon mit dem MAC-Adressen sehr sehr komisch umgeht.


#3

Hab ich schon angepasst. Erst auf einem jetzt auf beiden Interface trotzdem klappt es nicht.

Hab mir dazu auch schon die Finger wund gegoogelt. Nutze VMware vsphere 6.5


#4

Ich muss etwas erweitern ipv6 bekommen die clients wie es scheint aber kein v4. Windows und Linux hängt beides dran. Werden mir nämlich clients angezeigt auf der Mal.


#5

Schau doch mal mit tcpdump auf welchen Interfaces die dhcp requests und Antworten ankommen und wo sie hängen bleiben.

Eventuell eine Eigenschaft des Netzwerkinterfaces, dhcp speziell zu behandlen? Automatisches dhcp nicht vollständig deaktiviert oder etwas ähnliches?


#6

IPv6 macht der Offloader selbst, DHCP kommt über den Uplink. Bist Du sicher, dass der Uplink korrekt funktioniert?


#7

Wie kann ich es am besten testen ob er Korrekt Funktioniert? Die GW kann ich anpingen.

@rgr tcpdump auf dem offloader oder mit einer Linux Kiste im netz?

Ich hab zum test in dieses Vlan mal einen DHCP server gehangen. Alle clients bekammen da auch eine IP ohne irgend welche Probleme. Vielleicht hilft das ja.


#8

Das mit dem DHCP Problem hatte ich in VMware glaube ich bei meinen Experimenten genauso. Kannst ja hier mal nachlesen, ob Du dasselbe Problem hast (auch wenn ich dafür keine wirkliche Lösung habe):


#9

tcpdump vor allem auf dem offloader auf allen Interfaces. Da solltest Du schön sehen können, wie der Request jeweils rein kommt, durchgereicht wird, Antwort kommt und wieder zurück, bzw wo er hängen bleibt.

Wenn Du ins Client-Netz nen dhcp-Server hängst, dann könnte der eventuell auch alle clients antworten, weil ja alles ein layer2-Netz ist. Ich gehe zwar davon aus, dass das bei batman und durch Firewall-Regeln verhindert wird, aber bei sowas bitte ein Auge drauf behalten, nicht andere Netzteilnehmer zu stören.


#10

Das mit der wan ip hab ich gelöst auch mit der Mac Änderung somit DHCP von meinem Router bekommt er. Nur unter verteilt er halt leider nix.

Die Performance ist auch weniger mein Problem der offloader läuft nur daheim als Austausch zu nem ff router.


#11

Ich kann leider auch nicht viel sagen. Eine Verbindung in unser Netz sehe ich und ich kann den Offloader auch erreichen. Das scheint zu gehen. Ich befürchte eher dass das Forwarding irgendwie nicht so ganz sauber läuft. Von daher bräuchte es wirklich einen Mitschnitt der Daten an den verschiedenen Interfaces.


#12

Hat Dein Switch vielleicht DHCP-Server-Screening aktiviert und blockiert aktiv DHCP-Replies der VMware?


#13

Unter VMware vSphere (ESXi) genügt es für Gluon nicht, nur den Promiscous-Modus bei den betroffenen Ports auf dem vSwitch zu aktivieren. Man braucht zusätzlich “Gefälschte Übertragungen: Akzeptieren” (wie das bei englisch-sprachigen Systemen heißt, kann ich nicht sagen - wir haben ein deutsch-sprachiges).

Wenn der vSphere-Host redundant mit dem physischen Switch der Infrastruktur verbunden ist, muss unbedingt noch eine Anpassung gemacht werden, sonst entstehen Doppelpakete:
In den erweiterten Software-Einstellungen des VMWare-Hosts unter “Net” den Wert bei “Net.ReversePathFwdCheckPromisc” auf 1 setzen.

So haben wir bereits seit 2 Jahren (ab Sphere 5.5) eine Offloader-VM erfolgreich am Laufen.


#14

Hallo Alle zusammen,

@ffs-Roland Danke dir, das war der Hacken der nirgends steht. Das hat geholfen nun geht alles und die Clients bekommen IPs.

@ffs-Roland dann aber noch als Frage welche HW Zuteilung habt ihr so? ich bin mal mit 1CPU und 1024MB ram an die sache ran :-P

Danke den anderen für die Lösungsansätze :-)


#15

Hallo @root_otacon

Als Hardware Zuteilung würde ich für ein Optimales Ergebnis minimum 2vCPUs und 1GB RAM geben.
Zwei vCPUs aus dem Grund, dass unser Tunnelprotokoll fastd aktuell nur eine CPU verwenden kann. Die andere CPU wäre dann für alle restlichen Dienste und Arbeiten frei.

Grüße
Nurtic-Vibe


#16

Wir haben 2 CPU-Kerne und 256 MB RAM. Da wir selbst in Spitzenzeiten nicht über eine CPU-Last von 15% kommen (Leistungswert unter VMware) bzw. CPU-Load von 0,2 (Statusseite des Node) bei einer Host-CPU “Intel® Xeon® CPU E5640 @ 2.67GHz”, würde sicher auch ein Kern reichen - ich mache aber prinzipiell immer mindestens zwei Kerne in alle meine VMs.

RAM ist ebenfalls kein Problem. VMWare meldet als maximal belegt 70 MB, die Statusseite des Node aktuell 12,3%

Die Disk hat 64 MB am IDE-Adapter (0:0), die NICs sind E1000, VM-Version = vmx-10