Temporär 2 VLANs verbinden

[test]

Hallo Netzwerker,

ich habe folgendes Problem:
Ich sitze hier vor einer alten Konfiguration bei der 2 Netze im gleichen VLAN (VLAN 1)sind.

Das möchte ich nun bereinigen, jedoch hängen in beiden Netzen sehr viele Clients und das über 15 Switches verteilt.
Somit ist es relativ schwer möglich alle Geräte auf einmal zu migrieren.
Es wurde ein zusätliches VLAN mit der ID 100 einrichten und ein Netz soll da hinein wandern.
Gibt es eine Möglichkeit 2 VLANs temporär zu verbinden? Routing ist wahrscheinlich keine Option.

Danke und schöne Grüße aus Österreich!

 

[MetalForLive]

Kommt drauf an was der Switch kann ?
Kann er nur Layer 2 ? Dann nicht.
Wenn es ein Layer 3 Switch ist, routet er in der Regel die VLANs untereinander.

Fakt ist, du brauchst auf jeden Fall einen Router der die beiden Netze verbindet.

Was für ein Gerät ist das Gateway genau ?

 

[Ic3HanDs]

Also normal kannst die doch einfach Verbinden. Problem sind dann eher deine DHCP Server etc. die ja für jedes Netz einzeln laufen. Ansonsten sehe ich nämlich nicht wo genau dein Problem ist. Die Switche MÜSSEN zur Zeit ja noch getrennt voneinander sein, sonst wären es nicht wirklich zwei Netze.

Daher kannst du eigentlich das eine komplett auf das neue Umstellen und dann die Switche über einen Trunk verbinden. Wird ja wohl eh alles Untagged sein, zumindest ziemlich wahrscheinlich bei VLan 1.

Anders wäre es garnicht möglich zweimal VLan 1 gleichzeitig zu haben wenn nicht durch komplett getrennte Switche.

Edit:
Glaube ich hab es falsch verstanden?

Wenn es so ist wie ich es jetzt verstehe, hast du 2 Subnetze in einem VLan? Dann musst du wie die anderen sagen Routen, das kann ein L3 Switch sein oder eben ein Router welcher VLans beherrscht.

Falls Routing keine Option ist, bleibt dir wahrscheinlich nur die Option einen Teil des Netzes ausfallen zu lassen um eine Migration vornehmen zu können. Denn irgendwie musst du ja die Switche entsprechend einrichten.

 

[Raijin]

Um VLANs über mehrere Switches hinweg (vermischt) zu verteilen, müssen alle beteiligten Switches ebenfalls VLAN beherrschen. Nur dann, wenn an einem "Ast" lediglich ein einzelnes VLAN läuft, könnte man es am zentralen VLAN-Switch als untagged laufen lassen und dann über den Ast herkömmlich ohne VLAN-id verteilen verteilen.

Zum Thema Routing: Ein L3-Switch kann wie MetalForLive schon schrieb zwischen den VLANs routen. Das ist wohlgemerkt nicht mit einem 20€ VLAN-Switch möglich, der lediglich Ports taggen kann, weil diese Kisten keinerlei Routing-Funktionalität haben. Alternativ zu einem L3-Switch kann man jedoch auch einen VLAN-fähigen Router nehmen, zB EdgeRouter oder MikroTiks. Ein ER-X kostet beispielsweise ~50€ und bietet 5 LAN-interfaces, die beliebig mit VLANs belegt werden können. Sofern keine Firewall nötig ist, funktioniert das sogar mehr oder weniger out-of-the-box nachdem man den Ports VLAN+IP zugewiesen hat.

 

[conf_t]

Wegen dem DHCP-Problem gibt es IP-Helper.

Aber den Ist und Soll Zustand finde ich etwas diffus dargestellt, um dazu Stellung zu nehmen. Grundsätzlich gibt es aber Inter-VLAN-Routing und das Native Access VLAN am Switchport juckt den PC erst mal auch nicht - deswegen ist es ja untagged. Access VLAN umstellen, Port reseten und der PC holt sich per DHCP schon eine neue IP -ferddisch. Gibt für den Anwender einen kurzen Wackler von 15 Sekunden o.ä. Machste dann halt mal nach 17 Uhr oder vor 7 Uhr, wenn wenige Leute betroffen sind.

 

[M@tze]

bei der 2 Netze im gleichen VLAN (VLAN 1)sind.

Es wurde ein zusätliches VLAN mit der ID 100 einrichten und ein Netz soll da hinein wandern.
Gibt es eine Möglichkeit 2 VLANs temporär zu verbinden? Routing ist wahrscheinlich keine Option.

Mir ist Deine Konfiguration nicht so ganz klar?!? Fuer das komplexe Thema sind das etwas wenig Infos. Das habe ich verstanden:

Du hast 2 "Netze", welche über 15 Switche verteilt sind. Also zBsp:

192.168.178.0/24 auf 8 Switchen
200.200.200.0/23 auf 7 Switchen

Alle Switche und Ports laufen untagged, also als normale Access Ports? Du hast momentan also überhaupt gar kein VLAN laufen, da VLAN1 am Switch das Default VLAN ist (gibt es immer)? Jeder Switch hat ein eigenes VLAN Interface (IP im jeweiligen Netz)?

Sind die Netze momentan verbunden (routing) oder laufen die nebeneinander her ohne direkte Verbindung in das andere LAN?

Was soll jetzt das Ziel sein? Du willst beide Netze auf allen Switchen haben, aber per VLAN getrennt oder willst Du beide Netze in ein gemeinsames Netz migrieren?

 

[test]

Puhh, da gibt es ja schon viele Antworten.

Hardware: HP Procurve der Serie 2500, 2600 und als Core ein 5406zl.
Also durchaus Layer 3 / routing fähig.
Routing möchte ich vermeiden, das geschieht aktuell für beide Netze im VLAN 1 über die Firewall.
Und ja, es sind wirklich 2 Netze in einem VLAN: 192.168.1.0/ 24 und 10.10.10.0 /24

Die Client sind großteils Maschinen-PC mit fixen IP-Adressen, diese IP-Adressen können nicht verändert werden.

Eine Idee?

Mir ist Deine Konfiguration nicht so ganz klar?!? Fuer das komplexe Thema sind das etwas wenig Infos. Das habe ich verstanden:

Du hast 2 "Netze", welche über 15 Switche verteilt sind. Also zBsp:

192.168.178.0/24 auf 8 Switchen
200.200.200.0/23 auf 7 Switchen

Alle Switche und Ports laufen untagged, also als normale Access Ports? Du hast momentan also überhaupt gar kein VLAN laufen, da VLAN1 am Switch das Default VLAN ist (gibt es immer)? Jeder Switch hat ein eigenes VLAN Interface (IP im jeweiligen Netz)?

Sind die Netze momentan verbunden (routing) oder laufen die nebeneinander her ohne direkte Verbindung in das andere LAN?

Was soll jetzt das Ziel sein? Du willst beide Netze auf allen Switchen haben, aber per VLAN getrennt oder willst Du beide Netze in ein gemeinsames Netz migrieren?

Nein, es sind 2 Netze auf der VLAN ID 1 verteilt über alle Switches.
Es existieren durchaus noch weiter VLANs auf allen Switches.

Ziel ist es VLAN 1 und VLAN 100 auf Layer 2 zu verbinden.
Somit könnte ich die Clients Stück für Stück von einem ins andere VLAN migrieren.

 

[conf_t]

Dann wird der Ausfall halt solange für eine einzelne Maschine dauern, bis alles umgestellt ist.
Alle Ports mit z.B. 10.0.0.0er Netz setzt du ins z.B. VLAN 2 und schaust, dass auf der Firewall das entsprechende Netz im VLAN 2 geroutet wird. Die Uplinks richtest du als .1Q Trunk ein und legst auf allen Switchen das VLAN 2 an. (Aber nicht in der Reihenfolge).

Aber an die Endgeräte musst du so auch nicht

Reihenfolge:

1. Zweites VLAN auf allen Switchen anlegen.
2. .1Q-Trunk auf allen Switche im Uplink anlegen
3. An der Firewall das eine Netz in das neue VLAN Routen (Endgeräte nicht mehr erreichbar)
4. Accessports mit Endgeräten mit IPs aus dem neuen Netz auf native VLAN z.B. 2 (oder was du wählst) schwenken (Endgeräte wieder erreichbar)

Ferddisch.

 

[test]

Dann wird der Ausfall halt solange für eine einzelne Maschine dauern, bis alles umgestellt ist.
Alle Ports mit z.B. 10.0.0.0er Netz setzt du ins z.B. VLAN 2 und schaust, dass auf der Firewall das entsprechende Netz im VLAN 2 geroutet wird. Die Uplinks richtest du als .1Q Trunk ein und legst auf allen Switchen das VLAN 2 an. (Aber nicht in der Reihenfolge).

Aber an die Endgeräte musst du so auch nicht

Reihenfolge:

1. Zweites VLAN auf allen Switchen anlegen.
2. .1Q-Trunk auf allen Switche im Uplink anlegen
3. An der Firewall das eine Netz in das neue VLAN Routen (Endgeräte nicht mehr erreichbar)
4. Accessports mit Endgeräten mit IPs aus dem neuen Netz auf native VLAN z.B. 2 (oder was du wählst) schwenken (Endgeräte wieder erreichbar)

Ferddisch.

Ich gebe dir vollkommen recht!
Bei 15 Switches und über 100 Clients die sich zum Teil gegenseitig erreichen müssen im 24/7 Betrieb jedoch schwierig.
Genau das wollte ich vermeiden.

 

[M@tze]

Bei 15 Switches und über 100 Clients die sich zum Teil gegenseitig erreichen müssen im 24/7 Betrieb jedoch schwierig.
Genau das wollte ich vermeiden.

Das kannst Du aber nicht vermeiden. Lieber ein festes Wartungsfenster definieren, als wenn Du es so versuchst und einem oder mehreren Usern die Sessions wegschiesst oder was sich sonst noch so synchronisieren muss.

Ich habe hier 15 Netze mit über 1000 Usern an 5 Standorten weltweit verteilt. Da sollte auch immer alles untereinander erreichbar sein, aber solche Arbeiten (gerade am Netzwerk) würde ich nur nach Anmeldung, mit Ankündigung von möglichen Netzunterbrechungen, durchführen. Und dann am besten am Wochenende oder als Nachtschicht...

 

[Raijin]

Ich weiß nicht so recht was du erwartest. Ein Netzwerk mit 15 Switches und 100 Clients ist nun mal kein Heimnetzwerk mehr. Es ist vollkommen klar, dass etwaige Änderungen an der Struktur - seien es physische, logische oder virtuelle - eine Menge Arbeit nach sich ziehen.
Mit einem Haken in der Konfiguration des Hauptswitches ist es nun mal nicht getan.

Die Tatsache, das mehrere Subnetze überhaupt ohne VLAN auf derselben Infrastruktur laufen, spricht Bände. Sowas sollte man tunlichst vermeiden und eben mit VLANs und Routing arbeiten. Die Umstellung vom einen zum anderen ist logischerweise nicht in 5 Minuten vollzogen...

 

[test]

Ich will ja nicht ohne Grund die Netze in VLANs splitten.
Mir ist bewusst, dass das eine kumme Lösung ist, jedoch habe es eben so geerbt und scheue die Arbeit auch nicht.

Ein Wartungsfenster von mehreren Stunden für etwas, "das ja eh läuft", ist einem Manager schwer zu erklären.

Daher war meine Frage ob es möglich ist 2 VLANs temporär zu verbinden.

 

[MetalForLive]

Falls es möglichst mit wenig Ausfall gemacht werden soll würde ich wie folgt vor gehen:

- Alle Clients sollten auf DHCP stehen.
- Auf dem Coreswitch zwei neue Layer 3 VLANS mit neuen IP Bereichen anlegen
- Intervlanrouting aktivieren (falls der Switch es nicht automatisch macht)
- Die neuen VLANS logischerweise auf alle Uplinks vom Core zu den anderen Switchen tagged übertragen
- Auf DHCP Server die neuen IP Bereiche anlegen, als Gateway den Core
- Clients Ports nach und nach in die neuen VLANS konfigurieren, vorher natürlich testen ob alles erreichbar ist, was erreichbar sein soll
- falls nötig, Firewallregeln für die neuen Netze erstellen
- ggf. default Route vom Core auf die Firewall setzen


Wenn du dir das nicht zutraust, hol dir lieber einen externen Dienstleister dafür bevor du die halbe Firma lahm legst.

Ergänzung (12. September 2017)

Ein Wartungsfenster von mehreren Stunden für etwas, "das ja eh läuft", ist einem Manager schwer zu erklären.

Dann musst du eben passende Argumente bringen...
Wenn jetzt aus irgendeinem Grund z.B. ein Broadcaststorm im Netz ausbricht, liegt das komplette Netz lahm (Und spätestens dann kommt die Frage, warum sowas nicht verhindert werden konnte).
Hast du verschiedene VLANs, ist nur ein Teil des Netzes betroffen.


Wenn du sowieso am aufsplitten bist, würde ich mir direkt Gedanken machen, was Sinnvoll ist in VLANs aufzuteilen.

Ich würde wie folgt VLANs anlegen:

- Servernetz
- Clientnetz
- Druckernetz
- Falls vorhanden Gast Netz
- WLAN (Für jede SSID ein VLAN)
- falls vorhanden Videoüberwachungsnetz
- falls vorhanden DMZ


Falls man Produktion oder sowas hat, muss man gucken ob es da sinn macht hier auch noch verschiedene VLANs anzulegen.

 

[test]

Falls es möglichst mit wenig Ausfall gemacht werden soll würde ich wie folgt vor gehen:
- Alle Clients sollten auf DHCP stehen.

Leider kann ich nicht alle Clients (PCs/Maschinen/Steuerungen etc.) auf DHCP umstellen.
Wenn es nicht möglich ist 2 VLANs zu verbinden, wird ein Wartungsfenster mit einem harten Schnitt nicht ausbleiben.

Ergänzung (12. September 2017)

Dann musst du eben passende Argumente bringen...
Wenn jetzt aus irgendeinem Grund z.B. ein Broadcaststorm im Netz ausbricht, liegt das komplette Netz lahm (Und spätestens dann kommt die Frage, warum sowas nicht verhindert werden konnte).
Hast du verschiedene VLANs, ist nur ein Teil des Netzes betroffen.


Wenn du sowieso am aufsplitten bist, würde ich mir direkt Gedanken machen, was Sinnvoll ist in VLANs aufzuteilen.

Ich würde wie folgt VLANs anlegen:

- Servernetz
- Clientnetz
- Druckernetz
- Falls vorhanden Gast Netz
- WLAN (Für jede SSID ein VLAN)
- falls vorhanden Videoüberwachungsnetz
- falls vorhanden DMZ


Falls man Produktion oder sowas hat, muss man gucken ob es da sinn macht hier auch noch verschiedene VLANs anzulegen.

Ja, es sind viele weitere VLANs vorhanden und die decken auch deine genannten Netze ab.
Diese 2 sind leider Uraltlasten.

 

[conf_t]

Du kommst um Wartungsfenster nicht umhin Das machen wir so als Netzwerkbetreiber eines großen deutschen Konzerns, etwa ne halbe Millionen Endgeräte an tausenden Standorten auch so. Für Standorte gibt es ein vertraglich definiertes Wartungsfenster für Change, je nach eingekaufter SLA verschiedene Abatufungen. Nur weil was 24/7 läuft, muss es nicht zwingend immer laufen.

 

[test]

Du kommst um Wartungsfenster nicht umhin Das machen wir so als Netzwerkbetreiber eines großen deutschen Konzerns, etwa ne halbe Millionen Endgeräte an tausenden Standorten auch so. Für Standorte gibt es ein vertraglich definiertes Wartungsfenster für Change, je nach eingekaufter SLA verschiedene Abatufungen. Nur weil was 24/7 läuft, muss es nicht zwingend immer laufen.

Ich hätte einfach gehofft, dass es einfacher geht.
Immerhin reden wir hier "nur" von einer Layer 2 Verbindung.

Trotzdem Danke!

 

[conf_t]

Du meinst die Ziffer am OSI Layer macht es einfacher, je niedriger die Schicht ist? Eher weniger.
Denn Layer 1 wäre z.B. umpatchen auf anderen Switch, was nicht remote geht und auch immer einen Ausfall nach sich zieht. Darüber kann alles zentral und remote gelöst werden, oftmals mit wenig oder garkeinem (spürbaren) Ausfall. Man kann das Konfigurieren der Geschichte sogar per Skripttemplate vorbereiten und per SSH/SNMP verbreiten, das ist dann in 5 Minuten erledigt, dumm nur, wenn man nur Weboberfläche hat. Alternativ legt man die fertige Konfig in der Start-Up-config vorladen und startet den Switch neu (ohne zu speichern). Dann kommt er mit der neuen Konfig hochgefahren, dauert aber definitiv 5 Minuten bei L3 Switchen, wäre auch für alle angeschlossenen Endgeräte ein Ausfall, aber hochgradig parallelisierbar, mit sowas wie 'reload at 05:00'

Rede mit den Leuten, die für die Endgeräte verantwortlich sind und den Entscheidern. Erkläre ihnen warum es wichtig ist. Alternativ soll dir die GF unterschreiben, dass sie über die Risiken es so zu lassen aufgeklärt wurde, die Implementierung aber dennoch verweigert.

Sowas braucht je nach Umgebung auch mal ein paar Wochen Vorbereitung, du kannst nicht im stillen Kämmerlein sitzen und dir was überlegen und das den anderen vor die Füße werfen - friss oder stirb.

Und jedem Anwender ist sein PC oder seine Maschine, die er bedient/überwacht am wichtigsten, das muss man zwar respektieren, aber auch um Verständnis für das große ganze werben.

Vielleicht kann man auch Wartungsfenster zusammenlegen, gibt es evtl. für die wichtigen Kisten einen Patchday?

Selbst bei uns gibt es noch ähnliche Altlasten (/22 oder /23er Netze o.ä. aber auch da stellen sich mitunter die Kunden quer und es Bedarf viel überzeugungsarbeit), aber spätestens wenn so Probleme wie von Clients mehrfach falsch beantwortete Gratuitous Arp Anfragen gibt, und es den Betrieb des Kunden stört, kommt das Einverständnis sehr schnell, die B-Cast Domäne zu verkleinern - weil die Kisten mangels freie DHCP-IPs keine PXE-Boot mehr durchführen können, oder der normale PC keine IP bekommt und ein Arbeiten so unmöglich wird. Oder jemand meint sich ein WLAN per mitgrbachter Firtzbox zu bauen und noch munter selbst DHCP spielt. Schlimm genug, wenn 50 Endgeräte betroffen sind, was anderes wenn es 100 sind. Klar es gibt dagegen Mechanismen wie Broadcast Storm Control, IP DHCP Snooping, Port Security, 802.1x,... ich weiß aber nicht, ob ihr alles nutzt.

 

[test]

Man kann das Konfigurieren der Geschichte sogar per Skripttemplate vorbereiten und per SSH/SNMP verbreiten, das ist dann in 5 Minuten erledigt, dumm nur, wenn man nur Weboberfläche hat.

Wer sagt denn, dass ich der HP CLI nicht mächtig bin?
Aber das war ja hier nie die Frage!
Allen bisherigen Antworten nach ist es einfach nicht möglich 2 VLANs zu verbinden.
d.h. ich MUSS den langen Weg nehmen, nicht mehr und nicht weniger.

 

[conf_t]

Sagt niemand. Aber jedes Unternehmen mag vielleicht andere Admintools nutzen? Und es war nur die Einschränkung, dass es eben per HTTP nicht so elegant geht.

 

[razzy]

war jetzt ein wenig Faul alles zu lesen, aber wenn ich mir die Gerätschaften so angucke habt ihr im Unternehmen bestimmt ein vernünftiges Netzwerkdesign, oder ?

Sprich Core -> (Distributed) -> Access -layer ?

Das Layer3 machen die Cores und deine Switche z.b. die 2500er machen den Access mit dem VLAN "untagged".

Auf dem Core werden die L3-VLANs angelegt, eine IP vergeben, die als Gateway der Netze dient.

Damit sollte eigentlich alles fürs erste funktionieren.
für DHCP gibt es den ip-helper


Eigentlich macht man sich um sowas VOR den Betrieb Gedanken
VLAN Strunktur etc