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?
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.
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.
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):
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.
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.
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.
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.
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