Ein Subnetz an zwei verschiedenen Standorten?
Hi,
ich bewege mich seit kurzem in einer neuen Umgebung. Leider ist die Doku - wie sollte es anders sein - gleich 0.
Es gibt eine Co Location und ein eigenes RZ.
An beiden Standorten gibt es diverse Subnetze, DMZs etc. Des weiteren ist ein MPLS was alle Standorte verbindet.
Nun ist mir in der vmware Umgebung etwas komisches aufgefallen.
Die IPs der VMs sind am Standort a z.B. 10.1.1.0/24
Die IPs der VMs sind am Standort b z.B. 10.1.2.0/24
Nun sind die IPs der Hypervisoren am Standort a und b aber aus dem Subnetz 10.1.1.0/24
Ein Tracert auf die IPs unterschiedlicher Hypervisoren am Standort a und b ergibt die gleiche Route. Also mein
Wie kann ein Subnetz an zwei Standorten den gleichen IP-Adressbereich haben wenn dazwischen ein MPLS hängt und dazwischen ein Routing stattfindet?
Irgendwie ist das für mich gerade unlogisch. Kann mir jemand mögliche Szenarien erklären, wie das sein kann?
ich bewege mich seit kurzem in einer neuen Umgebung. Leider ist die Doku - wie sollte es anders sein - gleich 0.
Es gibt eine Co Location und ein eigenes RZ.
An beiden Standorten gibt es diverse Subnetze, DMZs etc. Des weiteren ist ein MPLS was alle Standorte verbindet.
Nun ist mir in der vmware Umgebung etwas komisches aufgefallen.
Die IPs der VMs sind am Standort a z.B. 10.1.1.0/24
Die IPs der VMs sind am Standort b z.B. 10.1.2.0/24
Nun sind die IPs der Hypervisoren am Standort a und b aber aus dem Subnetz 10.1.1.0/24
Ein Tracert auf die IPs unterschiedlicher Hypervisoren am Standort a und b ergibt die gleiche Route. Also mein
Wie kann ein Subnetz an zwei Standorten den gleichen IP-Adressbereich haben wenn dazwischen ein MPLS hängt und dazwischen ein Routing stattfindet?
Irgendwie ist das für mich gerade unlogisch. Kann mir jemand mögliche Szenarien erklären, wie das sein kann?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7451018502
Url: https://administrator.de/forum/ein-subnetz-an-zwei-verschiedenen-standorten-7451018502.html
Ausgedruckt am: 22.12.2024 um 15:12 Uhr
10 Kommentare
Neuester Kommentar
Kann es sein das du übersehen hast das die Hypervisors mit VxLAN eine Layer 2 Kopplung aufgebaut haben und ein gleiches Layer 2 Netz sharen?! Der Tunnel bzw. die VTEPs nutzen Anycast, deshalb die gleiche Routing Regel.
Möglich aber auch das über das MPLS Backbone VPLS benutzt wird um Standort übergreifende L2 Netze zu schaffen?
Beides ist in dem o.a. Setup keine Ausnahme sondern eher die Regel.
Um da aber zielgerichtet antworten zu können reichen die oberflächlichen Angaben oben leider nicht, dafür braucht es ein paar mehr Infos zum Netzwerk Design.
Möglich aber auch das über das MPLS Backbone VPLS benutzt wird um Standort übergreifende L2 Netze zu schaffen?
Beides ist in dem o.a. Setup keine Ausnahme sondern eher die Regel.
Um da aber zielgerichtet antworten zu können reichen die oberflächlichen Angaben oben leider nicht, dafür braucht es ein paar mehr Infos zum Netzwerk Design.
Hi.
Ein ähnliches Szenario hab ich mit Proxy ARP gelöst.
Das Gateway vom Netz a würde sich stellvertretend für den Hypervisor melden.
Ein paar Punkte sind dabei zu beachten.
1) Die Route zu den Hypervisoren sollte beim Gateway im Netzwerk a direkt hinterlegt sein
Angenommen zwei Hypervisoren hätten die Adressen 10.1.1.5 und 10.1.1.6.
| | Netz a | Hypervisor Netz |
| --- | --- | --- |
| Schnitstellennname | eth0 | eth1|
| Gatewayadresse/Netz | 10.1.1.1 / 10.1.1.1/24 | 10.1.1.1/32 / 10.1.1.4/30 |
| ARP Proxy | eingeschaltet | ausgeschaltet |
2) Natürlich sollte in beiden Netzen nicht die selbe Host Adresse aktiv sein. In diesem Fall wird vermutlich ARP Proxy etwas schneller antworten, sodass dieselbe Adresse im Netz a kaum den Weg raus findet.
Also im obigen Beispiel sollte 10.1.1.5 nur im Netz der Hypervisoren aktiv sein.
3) Für das Netz b muss kein ARP Proxy aktiv sein. Da unterscheidet sich das Netz ja eindeutig.
Hier ist der Vorteil, dass alle Clients keine komplexen Konfigurationen benötigen. Der ARP Proxy antwortet nur auf die Adressen 10.1.1.5 und 10.1.1.6.
Warum das so gemacht werden muss, weiß ich auch nicht. Mein innerer Monk möchte gerne eindeutig getrennte Netze.
Ein ähnliches Szenario hab ich mit Proxy ARP gelöst.
Das Gateway vom Netz a würde sich stellvertretend für den Hypervisor melden.
Ein paar Punkte sind dabei zu beachten.
1) Die Route zu den Hypervisoren sollte beim Gateway im Netzwerk a direkt hinterlegt sein
Angenommen zwei Hypervisoren hätten die Adressen 10.1.1.5 und 10.1.1.6.
| | Netz a | Hypervisor Netz |
| --- | --- | --- |
| Schnitstellennname | eth0 | eth1|
| Gatewayadresse/Netz | 10.1.1.1 / 10.1.1.1/24 | 10.1.1.1/32 / 10.1.1.4/30 |
| ARP Proxy | eingeschaltet | ausgeschaltet |
2) Natürlich sollte in beiden Netzen nicht die selbe Host Adresse aktiv sein. In diesem Fall wird vermutlich ARP Proxy etwas schneller antworten, sodass dieselbe Adresse im Netz a kaum den Weg raus findet.
Also im obigen Beispiel sollte 10.1.1.5 nur im Netz der Hypervisoren aktiv sein.
3) Für das Netz b muss kein ARP Proxy aktiv sein. Da unterscheidet sich das Netz ja eindeutig.
Hier ist der Vorteil, dass alle Clients keine komplexen Konfigurationen benötigen. Der ARP Proxy antwortet nur auf die Adressen 10.1.1.5 und 10.1.1.6.
Warum das so gemacht werden muss, weiß ich auch nicht. Mein innerer Monk möchte gerne eindeutig getrennte Netze.
Proxy ARP bleibt aber dennoch ein Routing zw. 2 unterschiedlichen IP Netzen. Man "spielt" hier nur mit inkonsitenten Subnetzmasken zw. Clients und den eigentlichen Routern die die beiden unterschiedlichen IP Netze routen.
https://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation ...
https://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation ...
Vielleicht hab ich das missverstanden. Ich dachte , die Hypervisoren wären in einem dritten gerouteten Netz an den jeweiligen Standorten.
Inkonsistent trifft es. Oder zähe Umstrukturierung.
Wobei in meinem beschriebenen Beispiel und bei meiner Annahme die Clients keiner Konfigurationsänderung bedürfen. Nur eben Server und Router.
Inkonsistent trifft es. Oder zähe Umstrukturierung.
Wobei in meinem beschriebenen Beispiel und bei meiner Annahme die Clients keiner Konfigurationsänderung bedürfen. Nur eben Server und Router.
Wenn es das denn war bitte deinen Thread dann auch als erledigt schliessen!