Netzwerk-Loops über VPN möglich?

[csdragon]

Hi Leute, bei nem Kunden von uns kam grade das Thema Aufbau eines Ausfallsicheren Netzwerkes auf... Da ist auch das Thema "Loops" grade ein wichtiger Punkt, da in letzter Zeit 2x ein Mitarbeiter bei nem Umzug einfach mal Patchdose an Patchdose angesteckt hat und so n "bissl Schaden" an der Datenbank durch nen Netzwerk-Loop verursacht hat...

Meine Frage ist jetzt: Die verschiedenen Zweigstellen sind alle über VPN verbunden. Wenn jetzt in der Zweigstelle 2 jemand einen Loop steckt, ist dann damit automatisch auch das Hauptwerk betroffen?

Sprich: nutzt es was bei der Hauptzweigstelle alles mit Loop-Protection zu konfigurieren, wenn in den Zweigstellen jemand Mist bei der Verkabelung an so nem kleinen Miniswitch betreibt oder kann ein Loop sich nicht über ein VPN ausbreiten?

Thx

Bearbeitet 15. Juli 2010 von csdragon

[lordy]

Ein Loop geschieht auf Layer 2, auf Layer 3 kann er sich nicht verbreiten.

Es hängt also davon ab, welche Art von VPN du verwendest.

[dgr243]

Davon abgesehen kann ich mir grad absolut nicht vorstellen wie durch einen Netzwerkloop (der ja im Ergebnis lediglich nen Broadcaststorm verursacht) eine DB geschädigt werden kann :confused:

[csdragon]

Wie ist das gemeint:

"Es hängt also davon ab, welche Art von VPN du verwendest."?

Anscheinend haben grade ettliche Clients auf die Datenbank zugegriffen und Ihre Daten wohl bloß halb reingeschrieben... so wurde mir das zumindest mitgeteilt... k.A. bin kein DB-Experte...

Hat laut dem Kunden wohl nur ziemlich Zeit in Anspruch genommen das wieder zu bereinigen...

[DerMarcus]

Wie ist das gemeint:

"Es hängt also davon ab, welche Art von VPN du verwendest."?

Wie schon gesagt finden Loops nur bis OSI LAyer 2 statt, nicht darüber.

L2TP als VPN-Protokoll setzt auf Layer 2 auf. Prinzipiell könnte man also argumentieren, dass auch Loops übertragen werden.

IPSec beispielsweise setzt auf Layer 3 (IP halt) auf.

Allerdings muss meines wissens bei eines Site-to-Site Verbindung auch bei L2TP immer eine Art Gateway an jedem Standort stehen. Ich denke mal, dass da dann spätestens Schluss wäre mit dem Loop.

Aber in einem voll geswitchten Netz sollten Loops doch ohnehin kaum auftreten, oder vertu ich mich da jetzt?

[lordy]

Was du meinst, sind vermutlich Kollisionen, die sollte es in einem voll-geswitchten Netzwerk natürlich nicht geben.

Loops kann es aber geben, solange man kein Spanning-Tree o.ä. einsetzt.

[DerMarcus]

Loops kann es aber geben, solange man kein Spanning-Tree o.ä. einsetzt.

Hah! Richtig! Spanning Tree war das Zauberwort!

[csdragon]

Sinnvoll ist meines Erachtens nur Rapid-Spanning-Tree, da das Multiple Spanning Tree bis zu 3 Minuten braucht um seine Wege wieder aufzubauen... und bis dahin haben die meisten den Loop eh schon erkannt...

Arbeiten ist in der Zeit auch nicht möglich und wegen der fehlenden Anbindung an die Datenbank haben wir dort dann die gleichen Probleme wie letztens...

Ausserdem fahren sich ja dann auch nach ner Zeit wohl noch die VM-Server teilweise herunter...

Rapid Spanning Tree bzw. Spanning Tree im Allgemeinen ist echt ne geniale Geschichte... wenn alle Switche das unterstützen... Nur wie gesagt: an den Aussenstellen sind nunmal doofe Switche verbaut, die das nicht können!

Tests haben ergeben dass es dann egal ist ob STP aktiviert ist oder nicht - falls jemand nen Loop bei so nem Switch im Netzwerk steckt...

Tja... und das Budget muss wohl im Moment keine neuen Switche für die Aussenstellen hergeben... sonst würd ich dort sofort neue verbauen

Bearbeitet 16. Juli 2010 von csdragon

[ardcore]

Sinnvoll ist meines Erachtens nur Rapid-Spanning-Tree, da das Multiple Spanning Tree bis zu 3 Minuten braucht um seine Wege wieder aufzubauen... und bis dahin haben die meisten den Loop eh schon erkannt...

Gefährliches Halbwissen... oder besser gesagt kein Wissen

[csdragon]

ok... gebe mich geschlagen... es waren 30 Sekunden... :old

Die Zeit kam mir zumindest vor wie 3 Minuten :floet:

das is aber auch nicht wirklich toll und reicht locker aus um diverse Thinclients vom Server zu trennen, Software zum Absturz zu bringen oder Probleme mit ner Datenbank zu verursachen...

Und wenn jemand den Loop wieder entfern, gibt es nochmals nen kleinen Ausfall... bei RSTP sind das halt im Gegensatz dazu nur maximum 1-2 pings die nicht durchgehen...

[ardcore]

ok... gebe mich geschlagen... es waren 30 Sekunden... :old

Die Zeit kam mir zumindest vor wie 3 Minuten :floet:

Und wenn jemand den Loop wieder entfern, gibt es nochmals nen kleinen Ausfall... bei RSTP sind das halt im Gegensatz dazu nur maximum 1-2 pings die nicht durchgehen...

Wieder falsch. Du verzettelst dich immer weiter. Lass es lieber.

[csdragon]

Was verzettel ich mich? Man hat beim Abstecken wieder Pingverluste... - und da bin ich mir 100 pro sicher, da ich das ausprobiert habe...

[ardcore]

Was verzettel ich mich? Man hat beim Abstecken wieder Pingverluste... - und da bin ich mir 100 pro sicher, da ich das ausprobiert habe...

Nicht nur das du dich wieder mit den Zeiten der Protokolle verzettelst, sondern auch noch mit deren Unterscheidung untereinander und bei Rückführung der Schleife, zeugt nicht gerade von Expertise.

Du kannst doch nicht im Eingangspost doofe Fragen über Loops über VPN-Verbindungen stellen und dann innerhalb des Threads anfangen Wasser zu Wein zu predigen.

Behalt dein Halbwissen für dich auch wenn es gut gemeint ist,

das hilft anderen Unwissenden in keinster Weise weiter sondern führt nur noch mehr auf den falschen Pfad.

[Crash2001]

@adcore:

Wie wäre es denn, wenn du das mal richtigstellen würdest, anstatt den User mehr oder weniger zu beleidigen?

Aus dem Kopf könnte ich es nämlich grad auch nicht so wirklich, da ich die fdefault-Zeiten nicht kenne. Zudem kann an den Zeiten aber auch noch was gedreht werden...

[RipperFox]

Wie schon gesagt finden Loops nur bis OSI LAyer 2 statt, nicht darüber.

Au ja, ich mach jetzt auch mit

Das oben genannte ist falsch!

(jetzt aber mit Begründung: )

IP kann man wunderbar im Kreis routen, bis die TTL abläuft..

So was ist auch ein Loop und normalerweise unerwünscht!

Gesellige Grüße

hesa

[DocInfra]

Ich werf mal RIP und das Count-to-infinity-Problem ins Rennen.

[ardcore]

Meine Frage ist jetzt: Die verschiedenen Zweigstellen sind alle über VPN verbunden. Wenn jetzt in der Zweigstelle 2 jemand einen Loop steckt, ist dann damit automatisch auch das Hauptwerk betroffen?

Um deine Frage zu beantworten:

Nein, das Hauptwerk sollte, lassen wir ein paar exotische Spezialbedingungen weg, in geschildertem Fall nicht betroffen sein.

Allerdings kann die Aussenanbindung des Hauptwerkes über die der VPN-Tunnel terminiert wird in Mitleidenschaft gezogen werden. Dies kann Auswirkungen auf Anbindungen von anderen Aussenstandorten bei einer Hub-and-Spoke-Topologie haben.

In 98% der Fälle sollte es aber in geschildertem Fall nicht zu Problemen kommen.

Gruss,

ardcore.

[dgr243]

Grundsätzlich ist doch hier aber das zugrundeliegende Problem ein Problem der Datenbank bzw. des Zugriffs darauf.. Halb geschriebene Daten sollte normalerweise in einer nicht abgeschlossenen Transaktion stehen, welche nach einer gewissen Zeit automatisch verworfen wird.

Das ist ein Thema, was vollkommen unabhängig davon ist, wie genau Client und Server miteinander kommunizieren. Selbst auf der selben Maschine, kann dir der schreibende Prozess abrauchen. Auch dann hättest du halb geschriebene Daten.. Hier ist also grundlegend an der Applikation zu arbeiten (Problem Management).

Aus Incident Sicht sind natürlich Loop Vermeidungsmethoden wichtig zu nennen um bis zur Behebung des Problems zumindest etwas weiter zu kommen. Allerdings ist das unter Unkenntnis der zugrundeliegenden Netzstrukturen nicht wirklich machbar.