Wenn trotz der Kernel-Parameter “biosdevname=0” und “net.ifnames=0” die Netzwerkkarte dennoch nicht als ethX erkannt wird, könnte es an der initial ramdisk (initramfs) liegen. Mittels einem “dracut -f -v” kann diese neu erstellt werden.
Ich habe gestern meine Intel i350-T2 Karte bekommen (allerdings mit Lenovo Aufkleber). Nach dem Einbau fiel sofort auf, dass das BIOS das Compatibility Support Module (CSM) wieder eingeschaltet hat. Mit Hilfe des Bootutil von Intel, konnte ich dann UEFI aktivieren:
BOOTUTILW64E.EXE -ALL -UP=PXE+EFI -FILE=BootIMG.FLB
Dann kann man das CSM wieder dauerhaft deaktivieren. Allerdings verlängerte sich die Zeit bis zum Booten um ca. 20 Sekunden. Da ich nicht über iSCSI oder FCoE booten will, habe ich das Flash einfach ausgeschaltet:
BOOTUTILW64E.EXE -ALL -FD
Danach war es wieder angenehm schnell…
Das Problem tritt auf, da der systemd in den neueren Distributionen alles parallel startet. So ist z.B. der iSCSI-Dienst noch nicht ganz fertig mit dem Anlegen der devices, aber der ASM sucht schon mal seine Festplatten.
Eine mögliche Lösung hierfür ist einen Helper-Dienst zu installieren, der erst 15 Sekunden wartet, bevor der oracleasm.service angestartet wird.
Die Datei /usr/lib/systemd/system/oracleasm_helper.service anlegen und mit nachfolgendem Inhalt befüllen:
— CUT —
[Unit]
Description=Wait 15 seconds before starting oracleasm.service
After=iscsi.service
Before=oracleasm.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sleep 15
[Install]
WantedBy=multi-user.target
— CUT —
Systemd refreshen und Dienst aktivieren:
systemctl daemon-reload && systemctl enable oracleasm_helper.service
Da AVM es bis heute nicht geschafft hat, das Problem zu lösen, habe ich meinen alten DrayTek Vigor 130 Router aus dem Schrank geholt. Läuft alles einwandfrei. Beim IGMP Proxy musste ich allerdings per telnet eine Einstellung setzen:
ip igmp ppp 1 (Was immer das heißt, eine Doku habe ich nicht gefunden)
Gegenüber dem Zyxel VMG1312 hat der Vigor den Vorteil, dass man eigene DynDNS Profile erzeugen kann. Damit wird dann auch der IPv6 Tunnel nach einem Neustart wieder richtig konfiguriert.
In den Anleitungen ist immer nur dieser Weg beschrieben:
Gerät ausschalten -> Tasten 1,4,7 drücken und einschalten -> Zahlen 4685463 (Hotline) eintippen -> Neustart
Dabei wird aber die angemeldete Basis nicht gelöscht. Das schafft man aber hiermit:
Gerät ausschalten -> Tasten 1,4,7 drücken und einschalten -> Zahlen 76200 (oder 46395) drücken -> nach ganz unten scollen und Reset durchführen
Viel Spaß damit 🙂
Mittlerweile habe ich herausgefunden, dass es wohl an der AVM fritz.box liegt. Gleiches Setup mit einem ZyXEL VMG1312-B30A funktionierte einwandfrei.
AVM sucht den Fehler … ich bin gespannt, was sie so drauf haben 🙂
#define QUESTION ((2b) || !(2b)) /* Shakespeare */
Interessante Sache … Ich betreibe die fritz.box (FB) rein mit IPv4. Die Fortigate (FG) ist als exposed host freigegeben. Die config der FG sieht so aus:
config system sit-tunnel
edit “HE”
set destination 216.xx.yy.zz
set ip6 2001:470:aaaa:bbbb::2/64
set interface “outside”
next
end
config router static6
edit 1
set device “HE”
next
end
Das funktioniert so weit ganz gut, aber NUR wenn ich auf der FB im Support-Interface (/support.lua) einen Paketmitschnitt auf dem Internet-Interface mache.
Hier ein kurzer Trace, was die FG sieht, wenn der Paketmitschnitt aus ist:
id=20085 trace_id=1594 func=resolve_ip6_tuple_fast line=3286 msg=”vd-root received a packet(proto=6, SERVER:22->CLIENT:62426) from HE.”
id=20085 trace_id=1594 func=resolve_ip6_tuple_fast line=3311 msg=”Find an existing session, id-00000149, reply direction”
id=20085 trace_id=1594 func=ipv6_fast_cb line=58 msg=”enter fast path”
id=20085 trace_id=1595 func=resolve_ip6_tuple_fast line=3286 msg=”vd-root received a packet(proto=6, CLIENT:62426->SERVER:22) from lan.”
id=20085 trace_id=1595 func=resolve_ip6_tuple_fast line=3311 msg=”Find an existing session, id-00000149, original direction”
id=20085 trace_id=1595 func=ipv6_fast_cb line=58 msg=”enter fast path”
id=20085 trace_id=1596 func=resolve_ip6_tuple_fast line=3286 msg=”vd-root received a packet(proto=6, SERVER:22->CLIENT:62426) from outside.”
id=20085 trace_id=1596 func=resolve_ip6_tuple_fast line=3311 msg=”Find an existing session, id-00000149, reply direction”
id=20085 trace_id=1596 func=vf_ip6_route_input line=898 msg=”reverse path check failed, drop”
Die FG glaubt, das Paket käme aus dem Interface “outside” anstatt aus dem Interface “HE” (im Gegensatz zu dem ersten Paket, was richtig aus HE kam). Daher greift der Spoofing-Algorithmus und dropped das Paket.
Ein wenig Abhilfe brachte der folgende Workaround:
config system settings
set asymroute6 enable
end
Damit konnte ich mich zumindest per SSH auf dem Server anmelden. Allerdings stirbt die Session nach kurzer Zeit wieder, weil keine Pakete mehr empfangen werden.
Ich vermute, das Ganze hat was damit zu tun, dass der tcpdump auf der FB das Interface in den promiscuous mode setzt. Entsprechende Tickets hab ich bei AVM, Hurricane Electric und Fortigate offen. Mal sehen was zurück kommt 🙂
Fehlermeldungen wie…
MSExchange Front End HTTP Proxy – NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt – Fehlercode 1003
oder
ASP.NET – Fehlercode 3005 – Exception type: NullReferenceException – Exception message: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt
beim Öffnen der Exchange Admin Console können daher kommen, dass man das SSL Zertifikat getauscht hat und Exchange VERGISST es auch im Backend (also im IIS Exchange Back End Port 444) zu ändern!
Der wirkliche Fehlercode ist dann: Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:444 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten. – Fehlercode 15021
Wenn die Migration der öffentlichen Ordner nicht sauber durchläuft:
Update-PublicFolderMailbox –Identity “PF-MBX” -InvokeSynchronizer | ft –autosize -wrap