Reingucker

Könnte vielleicht an den Änderungen im Polling/clock-update des Server 2016 liegen https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/windows-time-service/accurate-time#introduction

Also einer der besseren Blogs zu ADFS ist der von Herr Sichel. Da ist einiges Grundlegendes abgedeckt und vielleicht hilfts bei der Konfiguration und/oder beim Entdecken des Fehlers https://asichel.de/2017/06/14/adfs-4-0-mit-exchange-2016-konfigurationsuebersicht/

Wobei der hier nicht untergehen sollte :)

Verstehe ich das richtig: Du hast Server 2016 mit Hyper-V (Server1) installiert, dann dort in eine VM nocheinmal Server 2016 mit Hyper-V (Server 2) und dann dort in eine VM einen Client? Und dieser Client kommt nicht ins Internet, aber Server 2 kommt ins Internet?

Ja, hab ich gelesen. Damit kann man auf bestimmten Switches von HP einen statischen Eintrag für eine MAC-Adresse machen.

Man könnte es ja mal damit probieren https://www.manualslib.com/manual/73007/Hp-Procurve-6208m-Sx.html?page=216

Kann man an diesen ProCurves und MikroTik nicht Mac-Adressen fest auf Ports legen? Also wie bei Cisco mit port-security.

Nur ein Router verbindet Subnetze/Netze mit unterschiedlichen Netzadressen. NAT ist POSTROUTING. Der Broadcast kommt nicht über den Router, da der Router die sogenannten Broadcastdomänen trennt. Broadcast ist Layer2, Routing ist Layer3. Wie schon erwähnt braucht man ein DHCP-Relay um den DHCP-Broadcast zu einem DHCP-Server in einem anderen Netz zu bringen. Bei z.B. Cisco-Router benutzt man das IP-Helper-Command, welches sich über das IP Forward Protokoll so programmieren lässt, dass es Broadcasts zu bestimmten Ports an eine bestimmte IP-Adresse weiter leitet. Wobei hier standardmäßig Table 2-10 Default Forward UDP Services Service Port Time 37 TACACS 49 DNS 53 BOOTP/DHCP Server 67 BOOTP/DHCP Client 68 TFTP 69 NetBIOS name service 137 NetBIOS datagram service 138 Aber das führt jetzt etwas zu weit.

Netze werden nicht durch NAT verbunden. Router verbinden Netze.

Könnte auch sein daß der Standby gar nicht mitbekommt daß der SO2 nicht mehr da ist. Ah, lese gerade daß schon geprüft und funktioniert. Dann ein Sniff auf dem Standby um zu sehen was wirklich ankommt.

Hmm, 10.146.32.0 ist wo?

Ist ja vom Standbyserver ins log eingetragen. War also zu einem Zeitpunkt als beide Server up waren und der SO2 war DHCP-Server.

https://technet.microsoft.com/en-us/library/dn338988(v=ws.11).aspx

Bintec kenn ich nicht. Ich vermute die untagged auf dem Bintec brauch eine IP aus der gleichen Range wie die untagged Schnittstelle auf dem Router und Router ist Gateway. Die SSID-VLan reichen die Pakete wahrscheinlich getagged durch und die AP-Clients nehmen dann als Gateway die entsprechende tagged Vlan-Schnittstelle auf dem Router.

Ja, so habe ich HP verstanden.

Es sind ja auch einige NAT dazwischen. Der Weg für den Relay zu den DHCP-Servern muß natürlich frei sein. Auf dem router brauchst da nix machen da der Relay ja von innen nach außen geht dabei genattet wird. Und die zurück kommenden Antworten sind ja in der Porttable des NAT hinterlegt und können also wieder rein. Aber die NAT beim Eingang RZ und den dortigen DHCP-Server z.B., da kommen ja die Relay-Pakete von außen auf den NAT. Da müsstest ein Loch aufmachen für auf der 67. Oder du machst vom Relay-Router einen Tunnel in das RZ und umgehst damit dieses NAT-Loch. Am Besten einen SSL-Tunnel um sich das eventuelle NAT-T zu sparen.

Hmm, in dieser Konstellation wie sie bei dir ist hab ich noch nie ins Log geschaut. Stehen denn die Anfragen des Relay drin?

Du hast doch schon ein untagged Vlan: Das Vlan1.

Ich vermute mal der Hot-Standby-Rechner hat eine andere IP-Adresse. Müsstest also im Relay den auch noch angeben.

Also wäre es beim Port vom Switch zum AP Vlan 10: tagged [Port vom Switch zum AP] Vlan 20: tagged [Port vom Switch zum AP] Und dazu auf dem Port vom Switch zum AP ein Vlan mit untagged, also z.B. Vlan 100: untagged [Port vom Switch zum AP] Auf dem Port vom AP Bintec sollten genau die gleichen Vlan sein und auch gleich getagged und untagged. Wobei hier die Frage ist was du mit diesem untagged machen möchtest. Ich vermute mal für den Zugriff auf die Managementconsole des Bintec. Aber dann mußt du dieses "Vlan 100 untagged" auch weiter führen bis hin zum Router und dort eine Vlan-Schnittstelle für bereit stellen. Edit: Wobei es auf der Verbindung zwischen Router+Switch und zwischen Switch+bintec nur 1 untagged Vlan geben kann. Müsstest also auf beiden Verbindungen das gleiche untagged Vlan nehmen. Edit2: Wenn da schon Jemand die Verbindung zwischen Router und Switch konfiguriert hat, dann hat er wahrscheinlich schon ein untagged Vlan angelegt über das er den Switch remote konfiguriert. Könntest also genau dieses untagged Vlan auch für die Verbindung Switch+Bintec nehmen und würdest dir Arbeit ersparen.

Wie man bemerkt hat kenne ich nur Cisco. Kann Andere also nur aus diesem Blickwinkel betrachten und kann beim Flamewar nicht mitmachen da....ich kenn nur Cisco. :)

Auf jeden Fall hab ich mich mal selbst aufgeklärt :D Ist schon ziemlich verwirrend bei HP wenn man von Cisco kommt. Bei Cisco geht alles zuerst Port und dann was der Port können soll. Bei HP definiert man irgendwie das "können soll" vorher und teilt es dann den Ports zu. Und ganz verwirrend wird es dann bei "no untagged" Ports. Das entspricht wohl dem nativen VLAN bei Cisco. Edit: Neee, "no untagged" sind anscheinend nur Ports die nicht in einem definierten VLAN enthalten sind. Oh Mann! Irgendwie chaotisch bei HP :(

Ist Cisco. Soweit ich das verstanden habe ist "native" bei Cisco das Gleiche wie "untagged" bei HP. Edit: Ich hab mir jetzt doch mal so einen HP-Switch angesehen. Ein untagged Port in HP ist ein access Port in Cisco.

Ich denke eher er sucht das "Native VLAN"...

Das hört sich für mich nach einer Portkonfiguration wie für VoIP + Data an. Also VoIP ist tagged und Data is untagged. Wie das bei HP genau konfiguriert wird weiß ich aber nicht.