80
Redundante Core Switches
Hallo Zusammen,
unsere IT Abteilung hat eine Teststellung beauftragt, um das bestehende Netzwerk für ca. 70 Mitarbeiter redundant aufzubauen. Eingesetzt werden sollen (wobei ich mit der Auswahl persönlich nicht sehr zufrieden bin):
-2 Core Swtiche (Zyxel XS-3700-24)
-15 Access Switche (HP JG962A-24)
Wir haben uns folgenden aufbau überlegt:
(Quelle: Administrator.de)
Genügt es hier die beiden Core Switche mit VRRP zu verbinden, sodass einer im Standby bleibt, falls der andere ausfällt oder wären andere Verbindungsarten sinnvoll?
Hat hier jemand Erfahrung mit der Funktion unter Zyxel Datacenter Switchen?
Generell soll jeder Access-Switch mit je einer LWL Verbindung über ein SFP Modul mit den beiden Core Switchen verbunden werden. Ich gehe davon aus, dass STP oder MSTP in den Access-Switchen aktiviert sein muss um Schleifen zu vermeiden, oder ist durch VRRP der Slave Core-Switch sowieso nur im Standby und ich bekomme dadurch keine Schleifen? In manchen DV-Schränken werden 2 HP Switche montiert. Macht es Sinn die Switche noch einmal untereinander zu verbinden oder wie oben geschrieben immer von Core- zu Access-Switch?
Gegebenenfalls soll das vorhandene Class B Netz in mehrer VLANs unterteilt werden. Muss VRRP dann für jedes VLAN eingerichtet werden, also ein virtuelles Gateway je VLAN?
Ich denke die Konfiguration von VRRP könnte weg fallen, wenn richtige Full Stacking Switche eingesetzt würden. Die Ports müssten dann nur über LACP gebündelt werden. Für Stacking Switche fehlt anscheinend das nötige Kleingeld
Viele Grüße und ein schönes Wochenende.
unsere IT Abteilung hat eine Teststellung beauftragt, um das bestehende Netzwerk für ca. 70 Mitarbeiter redundant aufzubauen. Eingesetzt werden sollen (wobei ich mit der Auswahl persönlich nicht sehr zufrieden bin):
-2 Core Swtiche (Zyxel XS-3700-24)
-15 Access Switche (HP JG962A-24)
Wir haben uns folgenden aufbau überlegt:
Genügt es hier die beiden Core Switche mit VRRP zu verbinden, sodass einer im Standby bleibt, falls der andere ausfällt oder wären andere Verbindungsarten sinnvoll?
Hat hier jemand Erfahrung mit der Funktion unter Zyxel Datacenter Switchen?
Generell soll jeder Access-Switch mit je einer LWL Verbindung über ein SFP Modul mit den beiden Core Switchen verbunden werden. Ich gehe davon aus, dass STP oder MSTP in den Access-Switchen aktiviert sein muss um Schleifen zu vermeiden, oder ist durch VRRP der Slave Core-Switch sowieso nur im Standby und ich bekomme dadurch keine Schleifen? In manchen DV-Schränken werden 2 HP Switche montiert. Macht es Sinn die Switche noch einmal untereinander zu verbinden oder wie oben geschrieben immer von Core- zu Access-Switch?
Gegebenenfalls soll das vorhandene Class B Netz in mehrer VLANs unterteilt werden. Muss VRRP dann für jedes VLAN eingerichtet werden, also ein virtuelles Gateway je VLAN?
Ich denke die Konfiguration von VRRP könnte weg fallen, wenn richtige Full Stacking Switche eingesetzt würden. Die Ports müssten dann nur über LACP gebündelt werden. Für Stacking Switche fehlt anscheinend das nötige Kleingeld
Viele Grüße und ein schönes Wochenende.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 327806
Url: https://administrator.de/contentid/327806
Ausgedruckt am: 15.11.2024 um 11:11 Uhr
80 Kommentare
Neuester Kommentar
wobei ich mit der Auswahl persönlich nicht sehr zufrieden bin
Das solltest du auch nicht. Zyxel im Core ist eher ein Witz...Genügt es hier die beiden Core Switche mit VRRP zu verbinden, sodass einer im Standby bleibt, falls der andere ausfällt oder wären andere Verbindungsarten sinnvoll?
Du hast heutzutage 2 Optiionen:- Ein HA Szenario mit VRRP woebei VRRP hier ausschliesslich nur die Layer 3 Gateway Redundanz realisiert. Für die Layer 2 Redundanz werkelt dann das RSTP
- Ein Switchpaar was echtes Stacking supportet und du die 2 Core Switches in einen Stackverbund bringen kannst.
Vorteil erste Option: Preiswert und auch mit billigsten Taiwan Switches wie den Zyxel zu realisieren
Nachteil: Spanning Tree. STP sorgt leider dafür das alle redundanten Links in den Standby gehen und nicht aktiv genutzt werden können. Link Aggregation ist nicht möglich über 2 Switches nur wenn diese spezielle, herstellerproprietäre Trunk Virtualisierungs Protokolle supporten.
Vorteil 2te Option: Frei von Spanning Tree und den daraus resultierenden Nachteilen, VRRP und L3 Redundnaz nicht erforderlich, da der Stack in sich redundant ist, alles Accesslinks können bandbreiteneffizient mit beiden Links (LACP Trunk) angebunden werden, einfacher Aufbau und zentralöes Management
Nachteil: Geringfügig teurer als die erste Option da das Stacking Feature mehr kostet.
Wichtig ist das in der Stacking Variante ein richtiges Stacking auf Hardware Basis supportet ist und kein billiges Clustering wie es HP oft in den Billigserien macht.
Full Stacking Switches wie Cisco SG-500 oder Brocade ICX 7250 usw. wären da solche Kandidaten die das supporten. Letzterer ideal, da er gleich je 8 1G/10G SFP Slots an Bord hat für die Optiken.
Heutzutage entscheidet man sich in der Regel immer für Option 2.
Hat hier jemand Erfahrung mit der Funktion unter Zyxel Datacenter Switchen?
Vermutlich keiner, denn Zyxel ist ein Billighersteller der den Consumer Markt bedient. Solche Hardware hat in Datacentern die die Bezeichnung verdienen nichts zu suchen.Ich gehe davon aus, dass STP oder MSTP in den Access-Switchen aktiviert sein muss um Schleifen zu vermeiden
Ja, wenn man die klassische aber heutzutage veraltete Design Option 1 wählt.Du solltest dir unbedingt etwas Know How zu VRRP anlesen:
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
Denn du mischst hier recht unsinnig Layer 2 und Layer 3. VRRP ist ein L3 only Protokoll wie oben schon gesagt !
Macht es Sinn die Switche noch einmal untereinander zu verbinden
In jedem Falle, denn sonst würde die Redundanz immer über die Access Links realisiert was ein schlechtes Design ist.Beim Stacking hat man eh eine Daisy Chain Verbindung (idealerweise 10G) über die Stack Member.
Ich denke die Konfiguration von VRRP könnte weg fallen, wenn richtige Full Stacking Switche eingesetzt würden
Yepp, Bingo ! Der Kandidat hat 100 Punkte !! So sähe es aus:
Die Ports müssten dann nur über LACP gebündelt werden
Nein falsch ! Das Stacking geschieht über dedizierte Stack Trunks. Da rennt was Chip Spezifisches, das dann aber über Standard Ethernet Infrastruktur.Für Stacking Switche fehlt anscheinend das nötige Kleingeld
Das wäre natürlich völliger Quatsch denn die Mehrkosten sind nur sehr gering. Es wäre sparen am absolut falschen Ende und das wird sich später bitter rächen !Für heutige Datacenter ist Stacking oder Ethernet Fabric eigentlich ein Muß.
Wenn das natürlich das RZ von Würstchen Karl ist mit 2 Selbstbau Servern spielt es natürlich keine Rolle, dann tun ganz sicher auch die Zyxel Gurken.
Das design oben zeigt eigentlich ganz klar das derjenige der das Designt hat wenig bis keine Fachkenntnisse in RZ Infrastruktur Planung hat
Darüber solltest du auch mal nachdenken !
Das design oben zeigt eigentlich ganz klar das derjenige der das Designt hat wenig bis keine Fachkenntnisse in RZ Infrastruktur Planung hat
Darüber solltest du auch mal nachdenken !
Darüber solltest du auch mal nachdenken !
Darauf habe ich leider keinen Einfluss. Ich wäre lieber auf Full Stacking Switche gegangen aber es sollen nun mal die Zyxel Dinger werden.
Das wäre natürlich völliger Quatsch denn die Mehrkosten sind nur sehr gering. Es wäre sparen am absolut falschen Ende und das wird sich später bitter rächen !
Die Access-Switche sollen über Glasfaser mit den Core-Switchen verbunden werden. Also muss jeder Core Switch mind. 15 SFP Ports haben. Ich denke Full Stacking Swiche werden dann spürbar teurer...
Du solltest dir unbedingt etwas Know How zu VRRP anlesen:
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
Denn du mischst hier recht unsinnig Layer 2 und Layer 3. VRRP ist ein L3 only Protokoll wie oben schon gesagt !
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
Denn du mischst hier recht unsinnig Layer 2 und Layer 3. VRRP ist ein L3 only Protokoll wie oben schon gesagt !
In deinem verlinkten Wiki Artikel habe ich schon nachgelesen. Auch auf anderen Seiten. Tatsächlich komme ich in dem Zusammenhang gedanklich durcheinander, dass VRRP ein reines L3 Protokoll ist und die Gateway Redundanz sicherstellt und für L2 RSTP benötigt wird. Ich habe noch nicht ganz verstanden, warum durch das VRRP Protokoll ein virtuelles Gateway erstelle wird (welches das Standardgateway der Netzwerkgeräte wird) und dadurch die Core-Switche redundant werden...bei den Zyxel Dingern habe ich mir die Konfiguration im Manual durchgelesen...jeder von den Zyxeln muss mit dem Router verbunden werden. Full Stacking Switche verschmelzen zu einer Einheit - da kann ich die Redundanz nachvollziehen.
Wie sieht es dann mit VLANs aus? Wenn mehrere VLANs angelegt werden, müssen auch mehrere virtuelle Router in den Core Switchen angelegt werden oder stelle ich mir das falsch vor? Wie lassen sich gedanklich mehrere VLANs mit der oben beschriebenen Situation aufbauen? Geplant sind 4-5 vLANs. Manche Geräte sollen Zugriff auf mehrer vLANs bekommen - der Zugang zum Internet erfolgt dann über einen Router. Die eingesetzten Switche sind Layer3 fähig, sodass hier das Routing erfolgt.
Hallo zusammen,
die ganzen Ports benutzt werden wenn die Frage erlaubt ist? 10 x 24 Ports sind ja 240 Ports hat das einen bestimmten Grund oder
sind die Switche überall verteilt oder warum ist da so viel Platz nach oben? Stehen die Switche denn alle in einem oder zwei 19" Racks.
Ports: 8 x 10GBase-T + 12 x 10 Gigabit SFP+ + 4 x C 10 G-Bit SFP+
Der ist nur Layer2+ und warum nicht alles von Zyxel kaufen? Denn in der Regel verwaltet man mit einer
Software die der Hersteller für "größere" Installationen bereit stellt so eine Anzahl von Switchen. Und
darüber laufen auch Alarme ab und viele andere Sachen mehr. Aber nochmal diese Switche können
kein dynamisches Routing auf Layer3 Ebene sondern nur statisches Routing! Eventuell muss dann
noch eine Layer3 Lizenz gekauft werden. Interessant wäre aber wirklich noch einmal zu wissen
ob alle Switche in ein oder zwei Racks rein kommen!?
als die HP Switche. Die auch noch ein Problem mit dem VLANs haben, @aqui weiß da aber mehr
drüber zu berichten als ich.
es kommt immer nur darauf an was man zur Verfügung hat, man bezwecken möchte und was die Switche alle zu bieten haben!
Zeitfrage ob in Sekunden oder Minuten die Sache geregelt werden soll. Also sprich es ist Zeit abhängig.
Es kommt auch immer stark darauf an was man denn bezwecken möchte! Früher hat man ein Netzwerk nur mittels Uplinks verbunden,
da hat man dann aber zu viele "Hopps" und einen hohen Portverlust! Dann kam der "Switch Stack" und man hatte mehr Ports frei, eine
höhere Übertragunsrate (intern) und die Sicherheit das wenn ein Switch ausfällt der obere und der untere Switch diese Aufgaben mit
übernehme, zwar nur mittels halber Übertragungsrate und auch nur bei einem Stapel im Ring (Ring Switch Stack) aber immerhin fällt
nichts aus und dann wäre da noch die einfachere Konfiguration eines Stapels (Switch Stack). Bei den neueren Verfahren zum Stapeln
von Switchen via SFP Module an der Front des Gerätes fallen daher einige dieser Vorzüge weg, es sei denn sie haben an der Rückseite
einen freien Schacht zur Aufnahme eines "Stacking Moduls".
und dem selben Hersteller sein und müssen auch VRRP tauglich sein und nicht nur der Core! Und nicht vergessen dann auch nur ein
Switch von den beiden Core Switchen!!!! Und von daher würde ich wirklich zu Switchen greifen die alle von einem Hersteller kommen.
diese werden dann an den Core angebunden, entweder routet der Core denn alle Stapel, oder die Stapel haben je einen Layer3 Switch
der routet dann den Stapel oder aber man hat einen Stapel (Ring) aus Layer3 Switchen und wenn dann einer in der Mitte, ein Master
ist und ausfällt, fangen die darüber und darunter liegenden die Last mit halber Bandbreite ab.
darauf an was man benötigt, denn wenn alle Switche volle Leistung bringen sollen und in einem oder zwei 19"Racks installiert
werden und die Ausfallsicherheit muss da sein, dann kommt man nicht drum herum! Und wenn alle Switche einige Routing
Protokolle wie VRRP/HRSP / OSFP / RIP / PIM oder BGP beherrschen sollen bzw. müssen wird es wohl auch nicht ohne
echten Switch Stack gehen!
Ist ja auch immer eine Budgetfrage ich würde mal bei Netgear nachsehen wollen ob da nicht etwas für Euch zu holen ist!
Zwei NETGEAR ProSafe XSM7224S mit Layer3 Lizenz als Core Switche und dann aus der M5300er Serie den Rest.
Dazu noch die Netgear NMS300 Software und man kann die Switche auch voll und ganz verwalten und managen.
Oder aber man nimmt je nachdem was gewünscht wird zwei Netgear M4300-24X ProSafe Managed 24x 10Gigabit Switche und dann
aus der M5300 Serie den rest, Vorteil wäre hier das alle von Haus aus und ohne zusätzliche Lizenz routen können! Und das wären dann
bei den Core Switchen und den Switchen der M5300 Serie folgende Protokolle, RIP, OSPF, VRRP, PIM, PBR.
Gruß
Dobby
unsere IT Abteilung hat eine Teststellung beauftragt, um das bestehende Netzwerk für ca. 70 Mitarbeiter redundant aufzubauen.
70 MAs mit einem PC und VOIP Klienten sind bei mir 140 Geräte plus Server NAS/SAN und Tape/RDX Libraries, wofür sollen denndie ganzen Ports benutzt werden wenn die Frage erlaubt ist? 10 x 24 Ports sind ja 240 Ports hat das einen bestimmten Grund oder
sind die Switche überall verteilt oder warum ist da so viel Platz nach oben? Stehen die Switche denn alle in einem oder zwei 19" Racks.
Eingesetzt werden sollen (wobei ich mit der Auswahl persönlich nicht sehr zufrieden bin):
Warum weil gemischt wird oder der Marke wegen oder wegen was genau?-2 Core Swtiche (Zyxel XS-3700-24)
Gerätetyp: Switch - 24 Anschlüsse - L2+ - verwaltet - stapelbarPorts: 8 x 10GBase-T + 12 x 10 Gigabit SFP+ + 4 x C 10 G-Bit SFP+
Der ist nur Layer2+ und warum nicht alles von Zyxel kaufen? Denn in der Regel verwaltet man mit einer
Software die der Hersteller für "größere" Installationen bereit stellt so eine Anzahl von Switchen. Und
darüber laufen auch Alarme ab und viele andere Sachen mehr. Aber nochmal diese Switche können
kein dynamisches Routing auf Layer3 Ebene sondern nur statisches Routing! Eventuell muss dann
noch eine Layer3 Lizenz gekauft werden. Interessant wäre aber wirklich noch einmal zu wissen
ob alle Switche in ein oder zwei Racks rein kommen!?
-15 Access Switche (HP JG962A-24)
Zyxel GS1910 oder GS2200 Switche vertragen sich bestimmt deutlich besser mit dem 3700erals die HP Switche. Die auch noch ein Problem mit dem VLANs haben, @aqui weiß da aber mehr
drüber zu berichten als ich.
Genügt es hier die beiden Core Switche mit VRRP zu verbinden, sodass einer im Standby bleibt, falls der andere
ausfällt oder wären andere Verbindungsarten sinnvoll?
Was soll denn überhaupt bezweckt werden? Man kann auch Switche mittels VRRP/HRSP oder gar mittels OSPF nutzenausfällt oder wären andere Verbindungsarten sinnvoll?
es kommt immer nur darauf an was man zur Verfügung hat, man bezwecken möchte und was die Switche alle zu bieten haben!
Hat hier jemand Erfahrung mit der Funktion unter Zyxel Datacenter Switchen?
Nein.Generell soll jeder Access-Switch mit je einer LWL Verbindung über ein SFP Modul mit den beiden Core Switchen verbunden werden.
Zu viel! Dann lieber einen Switch Stapel (Switch Stack) im Ring mit den beiden Core Switchen verbinden.Ich gehe davon aus, dass STP oder MSTP in den Access-Switchen aktiviert sein muss um Schleifen zu vermeiden,
In der Regel eher RSTP aber das kann sicherlich auch von Hersteller zu Hersteller unterschiedlich sein, ist eben eineZeitfrage ob in Sekunden oder Minuten die Sache geregelt werden soll. Also sprich es ist Zeit abhängig.
....oder ist durch VRRP der Slave Core-Switch sowieso nur im Standby und ich bekomme dadurch keine Schleifen?
VRRP läuft ja eigentlich so ab das ein Switch im "Stand by Modus" ist und der andere arbeitet.In manchen DV-Schränken werden 2 HP Switche montiert.
Also nicht in dem Serverraum alle Switche in ein oder zwei 19" Racks?Macht es Sinn die Switche noch einmal untereinander zu verbinden oder wie oben geschrieben immer von Core- zu Access-Switch?
In der Regel bildet man Stapel und diese bindet man dann an den Core an. Das kann je nach Installation auch unterschiedlich ausfallen!Es kommt auch immer stark darauf an was man denn bezwecken möchte! Früher hat man ein Netzwerk nur mittels Uplinks verbunden,
da hat man dann aber zu viele "Hopps" und einen hohen Portverlust! Dann kam der "Switch Stack" und man hatte mehr Ports frei, eine
höhere Übertragunsrate (intern) und die Sicherheit das wenn ein Switch ausfällt der obere und der untere Switch diese Aufgaben mit
übernehme, zwar nur mittels halber Übertragungsrate und auch nur bei einem Stapel im Ring (Ring Switch Stack) aber immerhin fällt
nichts aus und dann wäre da noch die einfachere Konfiguration eines Stapels (Switch Stack). Bei den neueren Verfahren zum Stapeln
von Switchen via SFP Module an der Front des Gerätes fallen daher einige dieser Vorzüge weg, es sei denn sie haben an der Rückseite
einen freien Schacht zur Aufnahme eines "Stacking Moduls".
Gegebenenfalls soll das vorhandene Class B Netz in mehrere VLANs unterteilt werden. Muss VRRP dann für jedes VLAN eingerichtet
werden, also ein virtuelles Gateway je VLAN?
Je nach dem was Du erreichen möchtest und was vor allen anderen Dingen benötigt wird. Denn dann sollten die Switche alle von einwerden, also ein virtuelles Gateway je VLAN?
und dem selben Hersteller sein und müssen auch VRRP tauglich sein und nicht nur der Core! Und nicht vergessen dann auch nur ein
Switch von den beiden Core Switchen!!!! Und von daher würde ich wirklich zu Switchen greifen die alle von einem Hersteller kommen.
Ich denke die Konfiguration von VRRP könnte weg fallen, wenn richtige Full Stacking Switche eingesetzt würden.
Warum denn? Man bildet Switch Stapel von zwei bis um die acht Switche herum je nach Hersteller kann das aber auch variieren unddiese werden dann an den Core angebunden, entweder routet der Core denn alle Stapel, oder die Stapel haben je einen Layer3 Switch
der routet dann den Stapel oder aber man hat einen Stapel (Ring) aus Layer3 Switchen und wenn dann einer in der Mitte, ein Master
ist und ausfällt, fangen die darüber und darunter liegenden die Last mit halber Bandbreite ab.
Die Ports müssten dann nur über LACP gebündelt werden. Für Stacking Switche fehlt anscheinend das nötige Kleingeld
Die Stacking Module und DAC Kabel dazu kann man auch nach und nach dazu kaufen! Und zweitens es kommt auch immerdarauf an was man benötigt, denn wenn alle Switche volle Leistung bringen sollen und in einem oder zwei 19"Racks installiert
werden und die Ausfallsicherheit muss da sein, dann kommt man nicht drum herum! Und wenn alle Switche einige Routing
Protokolle wie VRRP/HRSP / OSFP / RIP / PIM oder BGP beherrschen sollen bzw. müssen wird es wohl auch nicht ohne
echten Switch Stack gehen!
Ist ja auch immer eine Budgetfrage ich würde mal bei Netgear nachsehen wollen ob da nicht etwas für Euch zu holen ist!
Zwei NETGEAR ProSafe XSM7224S mit Layer3 Lizenz als Core Switche und dann aus der M5300er Serie den Rest.
Dazu noch die Netgear NMS300 Software und man kann die Switche auch voll und ganz verwalten und managen.
Oder aber man nimmt je nachdem was gewünscht wird zwei Netgear M4300-24X ProSafe Managed 24x 10Gigabit Switche und dann
aus der M5300 Serie den rest, Vorteil wäre hier das alle von Haus aus und ohne zusätzliche Lizenz routen können! Und das wären dann
bei den Core Switchen und den Switchen der M5300 Serie folgende Protokolle, RIP, OSPF, VRRP, PIM, PBR.
Gruß
Dobby
Darauf habe ich leider keinen Einfluss.
Warum nicht ?? Bist du kein Angestellter aus der IT Abteilung der mit seinem Fachwissen dort sinnvoll die Investition steuern kann ?? Genau DAS würde doch Sinn machen das in richtige Bahnen zu lenken und ist doch vermutlich die Intention deines Threads hier.Oder sollen wir dich nur bedauern weil du zusehen musst wie fachfremde Laien mit größter Unwissenheit da irgendwelchen Mist zusammenfrickeln. Danach sieht es ja augenscheinlich aus und wenn nicht JETZT kannst du noch die Notbremse ziehen und das in vernünftige Bahnen lenken !!!
Wer wenn nicht DU als Fachmann hat denn Einfluss ?? Der Cheffe als fachfremender Kaufmann fällt vermutlich von einer PC Bude geschaffene falsche Entscheidungen für die Infrastruktur.
Oder warum hast du den Thread denn sonst eröffnet hier ??
Also muss jeder Core Switch mind. 15 SFP Ports haben
Das stimmt wenn du insgesamt 15 Accessswitches hast, Nur was stutzig macht bei dieser Anzahl....Access Switches haben üblicherweise 24 oder 48 Endgeräte Ports was dann bei 70 Mitarbeiter entweder 360 oder 720 Ports bedeutet. Plus dann noch der Endgeräteports die die gestackten Core Switches auch noch mitbringen. Nimmt man da 48 Port Switches sind das nochmal 96 Ports on Top !....
Ein ziemliches Missverhältniss zur Anzahl der Mitarbeiter oder sind da jetzt auch noch Server, Telefonie, WLAN und Druckerports mit eingerechnet.
Wenn du z.B. mal Brocade ICX 7250 nimmst, die haben je 8 SFP+ Ports und je nach Modell 24 oder 48 Kupfer Ports. Von denen kannst du bis zu 12 Geräte in einen Full Stack bringen. Ob du die abgesetzt mit Glasfaser stackst oder mit preiswerten Kupfer Twinax Kabeln (DAC Kabel) oder einem Mischbetrieb spielt keinerlei Rolle.
Mit 4 im Stack hast du deine 16 Glasfaserports. Vermutlich kannst du dir dann auch welche sparen wenn du die Kupferports der Stackswitches mit in deine Endgeräte Port Kalkulation mit einbeziehst. Die Anzahl der Cores reduziert sich dann.
Aber worüber reden wir eigentlich wenn die Fremdentscheider längst beschlossen haben billigste Chinaböller unterster Kategorie einzusetzen für dein RZ...??!!
Ich denke Full Stacking Swiche werden dann spürbar teurer...
Nein, falsche Denke wenn man das über die Laufzeit und in Bezug auf Zukunftssicherheit und Skalierbarkeit rechnet. Die Stacking Option ist nur geringfügig teuerer.Die ganze Argumentation hinkt doch. Vermutlich hast du oder deine fachfremden Entscheider die du nicht beeinflussen kannst tausende Euro für Server und MS Lizenzen verpulvert und beim Netzwerk darfs dann billigste Chinaware sein. Sowas rächt sich schon sehr schnell.
Ich habe noch nicht ganz verstanden, warum durch das VRRP Protokoll ein virtuelles Gateway erstelle wird
Nun die Erklärung dafür ist kinderleicht:Bei einem HA Design mit Spanning Tree und VRRP hast du ja bei 2 Core Switches ZWEI mögliche IP Adressen als Gateway für die Engeräte. Entweder Switch 1 oder Switch 2.
Entscheidest du dich für Switch 1 und der fällt mal aus steht dein Netzwerk. Nimmst du Switch 2 und der fällt aus steht das Netzwerk wieder. Wenn du mehr als 2 Core Switches hast wird es umso schwieriger.
Deshalb gibt es VRRP ! VRRP sorgt dafür das die 2 (oder mehr) Core Switches EINE einzige IP Adresse sharen und sich gegenseitig sagen ob sie noch "leben". Fällt einer der Switches aus nimmt der andere immer diese IP mit und damit kommt es nicht zu einem Gateway Verlust der Endgeräte.
Simples Allerweltsprinzip von VRRP schon seit Jahrhunderten....
Bei einem Full Stack ist das natürlich obsolet, denn der verhält sich aus Endgeräte Sicht wie ein großer Chassis Switch. Dort gibt es ja dann nur eine IP und das Stacking Protokoll sorgt dafür das das auf den Backup Switch wandert sofern der Master im Stack mal ausfallen sollte.
Bei guten Switches geschieht sowas "hitless" sprich unterbrechungsfrei.
Wenn mehrere VLANs angelegt werden, müssen auch mehrere virtuelle Router in den Core Switchen angelegt werden
Nein ! Es müssen keinen Router angelegt werden. Der im L3 Switch ja vorhandene Routing Prozess bekommt lediglich ein virtuelle Bein in das VLAN gelegt.Das geschieht in der regel bei allen Herstellern damit das lediglich nur eine IP Adresse in dem VLAN definiert wird, damit ist dann VLAN Routing automatisch aktiv.
Wie lassen sich gedanklich mehrere VLANs mit der oben beschriebenen Situation aufbauen?
Auch das ist jahrhunderte alte aber aus den obigen Gründen heutzutage nicht mehr zeitgemässes klassisches Design.Jedes VLAN hat seine IP Adresse im Router und jedes VLAN hat seinen VRRP Prozess. Hier im folgenden kannst du das mal an einer Beispielkonfig sehen die das recht gut erklärt:
Switch 1:
!
interface VLAN 10
ip address 10.0.1.253 /24
vrrp-extended-group 10
virtual-ip 10.0.1.254
enable
no preempt-mode
short-path-forwarding
!
Switch 2:
!
interface VLAN 10
ip address 10.0.1.252 /24
vrrp-extended-group 10
virtual-ip 10.0.1.254
enable
no preempt-mode
short-path-forwarding
!
Hier hast du die 2 VLAN Interfaces auf den Switches und die virtuelle VRRP Gateway IP die die 2 Switches sharen.
Bei einem Stack gibts das natürlich nicht wie du sagst, denn da hat man ja nur ein Interface, da der Stack ja elektrich gesehen ein einzelner Switch ist !
Die Zugriffsrechte zwischen den einzelnen VLANs regelt man mit IP Accesslisten...alles klassischer Standard.
Wie bereits gesagt.... Zukunftsfähig und skalierbar bist du nur mit einer Stacking Lösung. Auch im Hinblick auf die Managebarkeit ist das nicht zu unterschätzen. Mit dem alten Design kann man 2 Mann beschäftigen. Eine Stacking Lösung kann der Hausmeister nebenbei managen. Auch das sind laufende Kosten...
Soweit denken aber deine genannten Entscheider sicher nicht wie man man schon deutlich an deren überholten Billigkonzept mit Chinaswitches sieht.
Stehen die Switche denn alle in einem oder zwei 19" Racks.
Die Switche sind verteilt auf ca. 9 Racks, daher die Anzahl. Mit eingerechnet sind VoIP Geräte, PCs, Drucker, Server, APs, etc.Warum weil gemischt wird oder der Marke wegen oder wegen was genau?
Zum Einen das gemischte und zum anderen die Marke. Ich hatte Zyxel bisher nur in Kleinstnetzen mit 10 Geräten eingesetzt, ohne VoIP, VLAN usw. und habe schon oft gelesen, dass bei größeren Netzen die Wahl eher auf andere Geräte fallen sollte. Erfahrung hab ich aber selbst keine.Was soll denn überhaupt bezweckt werden?
Geplant sind 2 Core Switche, die redundant werden sollen. Da die Auswahl wohl bei den Zyxeln bleibt, die kein Full Stack unterstützen und @aqui trotz Empfehlung meinerseits auf andere Geräte zu gehen, muss wohl oder übel das Beste mit den Geräten gemacht werden und als Möglichkeit bin ich dann auf VRRP und ...STP gestoßen, um Schleifen zu vermeiden.Wird ...STP auf den entsprechenden Ports einfach nur aktiviert oder muss das aktiv konfiguriert werden?
Je nach dem was Du erreichen möchtest und was vor allen anderen Dingen benötigt wird
Später sollen mehrere VLANs hinzukommen, wie z. B. Trennung nach Etagen, ein Server VLAN, Router VLAN etc. Hier weiß ich nun nicht, wie das dann in Verbindung mit VRRP zu konfigurieren ist. Bei der Konfig von VRRP habe ich gesehen, dass sich die beiden Core Switche eine virtuelle Gateway IP teilen. Muss dann für jedes der o. g. VLANS eine eigene Gateway IP angelegt werden und wie sieht es mit dem Thema DHCP in den einzelnen VLANs aus?Ist ja auch immer eine Budgetfrage ich würde mal bei Netgear nachsehen wollen ob da nicht etwas für Euch zu holen ist!
Die wahl ist wohl auf die HP Switche gefallen, da diese die leisesten PoE Switche sind. Ein Paar Verteiler sitzen in Büros, sodass hier der Geräuschepegel dann zu hoch wäre. Baulich ist das wohl leider nicht anders machbar.Was wären dann Empfehlungen für die Core und Access Switche, die preislich in etwa gleich sind? Das die Anschaffung von der Lautstärke der Access Switche abhängt ist auch suboptimal...
Oder warum hast du den Thread denn sonst eröffnet hier ??
Durch Empfehlung und Argumentation meinerseits sollen es wohl die Zyxel Dinger werden. Ich muss nicht den Geldbeutel öffnen und von daher bin ich nicht der Entscheider, der dann aber auch mit den langfristigen Konsequenzen der Anschaffung leben muss. Ich empfinde den Konfigurations- und Pflegeaufwand als deutlich höher, wobei ich schon bei vielen Artikeln auf Switche mit Full Stacking gestoßen bin und das wäre auch mein Wunsch gewesen.Hier im folgenden kannst du das mal an einer Beispielkonfig sehen die das recht gut erklärt:
Diese Beispielkonfig hatte ich mir im Manual des Switche angeschaut.VRRP in Verbindung mit verschiedenen VLANs (Etagen, DSL Router, Server, Gast) ist mir allerdings noch nicht klar. Muss jedes VLAN in der Konfiguration sein eigenes Gateway haben und wie sieht es da mit einem DHCP Server aus? Die Etage müssen ja auf die Server Zugreifen, die Gäste nur aufs Internet. DSL Router ist dann einer vorhanden, der dann von allen VLANs genutzt wird. Die Ports, welche die Switche miteinander verbinden müssen tagged sein?
Ich hatte bisher nur kleinere VLANs zum Testen aufgebaut und würde gerne in das Thema tief einsteigen und habe schon viele Artikel gelesen, die mich dann in Bezug auf die bestehende Umstrukturierung immer mehr verwirren, wobei dann noch das VRRP dazu kommt... mir fehlen gedanklich die Schritte, wie sich die VLANs mit dieser Basis konfigurieren lassen:
-2 Core Switche über VRRP redundant
-15 Access Switche in ca. 9 Unterverteilern, verbunden mit je einer LWL Strecke zu Master und Slave Core Switch
-VLANs für Etagen, Server, Gast usw. mit unterschiedlichen Zugriffsberechtigungen (Gast nur Internet, Etagen auf Server X usw.)
Hier weiß ich nun nicht, wie das dann in Verbindung mit VRRP zu konfigurieren ist.
Kannst du ja nun oben in einem Live Beispiel sehen Wird ...STP auf den entsprechenden Ports einfach nur aktiviert oder muss das aktiv konfiguriert werden?
Das hängt im Wesentlichen von den verwendeten Switches ab. Achtung ! hier gibt es eine Menge STP Derivate die teils nicht kompatibel sind:- PVSTP und PVSTP+ (Per VLAN STP, nicht mit STP bzw. RSTP kompatibel)
- Single Span STP und RST (kompatibel)
- MSTP
Das große Problem ist das du mit den Billigswitches ja in ein L2 STP Design gezwungen wirst !!
Beim Stacking hättest du gar kein Problem mit STP denn das wäre komplett frei von STP da du ja dann mit LACP LAGs arbeiten würdest und auch so die Bandbreite voll ausnutzen kannst.
Das geht so dann nicht mehr mit STP. Einer der redundanten Links ist dann immer tot (Blocking Mode) aus redundanzgründen.
Hier wäre es dann sinnvoll ein MSTP Priority Customizing zu machen über die MSTP Instances für die verschiedenen VLANs um wenigstens ein Sharing der redundanten Links zu machen und diese beidseitig auszunutzen.
Klare Empfehlung ist dann auf MSTP zu gehen und ein MSTP Design zu machen. MSTP sollten beide Switch Hersteller supporten auch Billigheimer Zyxel.
Hier siehst du schon wieder einen gravierenden Nachteil des "alten", non Stacking Designs. Der Konfig Aufwand das sinnvoll für ein RZ zu betreiben ist ungleich höher als mit Stacking.
Das gesamte Management natürlich ebenso. Gerade im Hinblick auf die von dir sinnvollerweise ja auch geplanten Segmentierung des Netzes.
Wie bereits gesagt haben die Entscheider das vermutlich wegen fehlendem Fachwissen gar nicht auf dem Radar...aber egal.
MSTP und VRRP wäre dann dein Weg...auch wenn er steinig ist.
Die wahl ist wohl auf die HP Switche gefallen, da diese die leisesten PoE Switche sind.
Wie immer natürlich Blödsinn. Aber ein HP Systemhaus was Umsatz gezwungen ist muss sowas ja sagen bzw. kennt den Rest der Welt nicht. Wieder ein Indiz für beschränkten Horizont...aber auch egal.Was wären dann Empfehlungen für die Core und Access Switche,
Access Switches kannst du ja belassen auf der HP Wahl. Deine Anforderungen sind ja vermutlich eher gering also ist HP da schon einigermaßen OK wenn es denn sein muß.Im Core solltest du aber dringend auf Stacking Switches gehen. Ist ja schon mehrfach betont worden.
Cisco SG-500 wäre dann entsprechende HW. Da aber vom Core und dessen Stabilität im RZ sehr viel abhängt wären vielleicht ein paar Euronen mehr mit 2mal ICX 7250 gut angelegt....
Durch Empfehlung und Argumentation meinerseits sollen es wohl die Zyxel Dinger werden.
Dazu ist ja hier schon alles gesagt worden...Ich empfinde den Konfigurations- und Pflegeaufwand als deutlich höher,
Das ist auch so und siehst du genau richtig ! MSTP und VRRP mit all den Parametern sind dann Pflicht für dich. Da die Zyxel Billigdinger nicht mal LACP Virtualisierungsprotokolle können hast du auch keine Chance mit gesplitteten LACP Links das zu umgehen.Muss jedes VLAN in der Konfiguration sein eigenes Gateway haben
Ja, natürlich ! Wie sollte der Switch denn sonst routen zwischen den VLANs ??!!Hier mal die erweiterete Konfig mit 4 VLANs im Core und dem Gäste Netz mit entsprechender Beschränkung und IP Accesslisten die den Gästen den Zugang zu den anderen VLANs verbieten.
Diese Konfig sollte dir das dann ggf. etwas transparenter machen wie das Gesamtkonstrukt aus L3 Sicht ohne Stacking aussieht oder aussehen könnte:
Core Switch 1:
!
interface VLAN 10
description Client Netz
ip address 10.0.1.253 /24
vrrp-extended-group 10
virtual-ip 10.0.1.254
no preempt-mode
short-path-forwarding
!
interface VLAN 20
description WLAN Netz
ip address 10.0.2.253 /24
vrrp-extended-group 20
virtual-ip 10.0.2.254
no preempt-mode
short-path-forwarding
!
interface VLAN 30
description Server Netz
ip address 10.0.3.253 /24
vrrp-extended-group 30
virtual-ip 10.0.3.254
no preempt-mode
short-path-forwarding
!
interface VLAN 40
description Gaeste WLAN
ip address 10.0.4.253 /24
deny 10.0.4.0 0.0.0.255 10.0.1.0 0.0.0.255
deny 10.0.4.0 0.0.0.255 10.0.2.0 0.0.0.255
deny 10.0.4.0 0.0.0.255 10.0.3.0 0.0.0.255
permit 10.0.4.0 0.0.0.255 any
vrrp-extended-group 40
virtual-ip 10.0.4.254
no preempt-mode
short-path-forwarding
Core Switch 2:
!
interface VLAN 10
description Client Netz
ip address 10.0.1.252 /24
vrrp-extended-group 10
virtual-ip 10.0.1.254
no preempt-mode
short-path-forwarding
!
interface VLAN 20
description WLAN Netz
ip address 10.0.2.252 /24
vrrp-extended-group 20
virtual-ip 10.0.2.254
no preempt-mode
short-path-forwarding
!
interface VLAN 30
description Server Netz
ip address 10.0.3.252 /24
vrrp-extended-group 30
virtual-ip 10.0.3.254
no preempt-mode
short-path-forwarding
!
interface VLAN 40
description Gaeste WLAN
ip address 10.0.4.252 /24
deny 10.0.4.0 0.0.0.255 10.0.1.0 0.0.0.255
deny 10.0.4.0 0.0.0.255 10.0.2.0 0.0.0.255
deny 10.0.4.0 0.0.0.255 10.0.3.0 0.0.0.255
permit 10.0.4.0 0.0.0.255 any
vrrp-extended-group 40
virtual-ip 10.0.4.254
no preempt-mode
short-path-forwarding
Das sollte eigentlich alles erklären...!
welche die Switche miteinander verbinden müssen tagged sein?
Nur die Uplink Ports zw. den Switches natürlich, logischerweise ! Die müssen doch die VLAN Informationen (VLAN ID) zwischen den Switches übertragen.Ich hatte bisher nur kleinere VLANs zum Testen aufgebaut und würde gerne in das Thema tief einsteigen
Dann hilft dir ggf. das hiesige Tutorial und besonders die Grundlagen URLs am Anfang.VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
(Die dort erwähnten externen Switches kannst du dir natürlich bei deinen L3 Core Switches wegdenken !)
mir fehlen gedanklich die Schritte, wie sich die VLANs mit dieser Basis konfigurieren lassen:
Mit dem o.a. Beispiel und 4 VLANs sollte das ja nun hinreichend klar sein. Sonst wie immer fragen...
@aqui Vielen Dank derweil.
Die Zyxel Teile sind ja nur L2+ und keine vollwertigen Layer3 kann aber statisches Routing. Was kann dann ein echter L3 Switch mehr - dynamisches Routing?
Der DSL Router ist dann quasi nur Router/Modem fürs Internet und das könnte - überspitzt gesagt - eine FritzBox sein, weil das Routing in den Coreswitchen stattfindet und der DSL Router quasi nur als Uplink ins Internet dient?
Diese Konfig sollte dir das dann ggf. etwas transparenter machen wie das Gesamtkonstrukt aus L3 Sicht ohne Stacking aussieht oder aussehen könnte:
Genau da setzt es bei mir dann aus. Ich habe noch nicht verstanden, ob das VRRP zwischen den Cores separat zu konfigurieren ist und dann den VLANs als "vrrep-extended-group" zugeordnet wird oder ist die VRRP Konfiguration gleich die Konfig der VLANs? Bei der Konfiguration von VRRP lege ich ja das virtuelle Gateway fest. Im Manual bei den Zyxeln habe ich mir die Konfig von VRRP angesehen, da stand aber nichts von vLAN - also wird das separat konfiguriert? Da verstehe ich aber dann nicht den Zusammenhang oder kommen die virtuellen Gateways für die vLANS von der VRRP Konfiguration? Müssen dann bei den Access Switchen die Ports z. B. 1-12 und 13-24 in VLANs aufgeteilt werden und der Uplink Port muss getagged werden, damit die Switche kommunizieren können? Das Routing der VLANs übernehmen dann die Cores.Die Zyxel Teile sind ja nur L2+ und keine vollwertigen Layer3 kann aber statisches Routing. Was kann dann ein echter L3 Switch mehr - dynamisches Routing?
Der DSL Router ist dann quasi nur Router/Modem fürs Internet und das könnte - überspitzt gesagt - eine FritzBox sein, weil das Routing in den Coreswitchen stattfindet und der DSL Router quasi nur als Uplink ins Internet dient?
MSTP und VRRP wäre dann dein Weg...auch wenn er steinig ist.
Wie ist das MSTP dann zu konfigurieren bei den Core und Access Switchen? Wird das nur an den Ports aktiviert, die Uplink zu den Cores sind oder wird das Protokoll allgemein aktiviert und Loops werden automatisch erkannt und die entsprechenden Ports geblockt?Access Switches kannst du ja belassen auf der HP Wahl. Deine Anforderungen sind ja vermutlich eher gering also ist HP da schon einigermaßen OK wenn es denn sein muß.
Nur damit ich hier nicht unwissend bleibe - was spräche gegen eine Wahl von den HP 1920 Switchen als Access? Was hätte ich für einen Vorteil bei anderen Herstellern?Cisco SG-500 wäre dann entsprechende HW. Da aber vom Core und dessen Stabilität im RZ sehr viel abhängt wären vielleicht ein paar Euronen mehr mit 2mal ICX 7250 gut angelegt....
Ich würde Switche benötigen, die mindestens 15 SFP Slots haben, damit ich die Access Switche über Glasfaser anbinden kann. Welche Stacking Switche als Cores wären dann in diesem Fall ratsam?
ZyXEL XS3700-24 ~3500 Euro
L2+ = Layer2 & Basic Layer3 features
HP JG962A-24 ~1100 Euro
Netgear M4300-24X ~3500 Euro
Layer3 Switch mit PIM, VRRP, RIP, PBR, OSPF
Netgear M4300-28GPoE+ 28-Port ProSafe ~1500 Euro
Layer3 Switch, OSPF, RIP, IGMPv2, IGMP, VRRP, PIM-SM, PIM-DM, IGMPv3, MLDv2
Egal wie Ihr Euch entscheidet, aber nehmt von nur einem Hersteller die Switche und dann bitte Switche
für den Core Bereich der ein echter Layer3 Switch ist und nicht Layer2+ als Layer2 plus ein paar Layer3
Features. Oder zumindest wo man eine Layer3 Lizenz nachlösen kann um mehr herauszuholen.
Je nach Länge und zu überbrückenden Abstand ist man mit dem Netgear M4300-24x besser beraten, denn
wenn man hier von unter hundert Metern redet kann man das alles mittels CAT.6A Kabeln erledigen und
hat noch ordentlich gespart. Denn dann entfallen die SFP+ Optiken und die LWL Kabel alle samt.
Des weiteren kann man auch über eine Verwendung von VRRP & OSPF nachdenken und alles via einer
Software überwachen und managen. Man kann auch gerade wie bei Euch eine Spine-Leaf Struktur aufbauen
Gruß
Dobby
L2+ = Layer2 & Basic Layer3 features
HP JG962A-24 ~1100 Euro
Netgear M4300-24X ~3500 Euro
Layer3 Switch mit PIM, VRRP, RIP, PBR, OSPF
Netgear M4300-28GPoE+ 28-Port ProSafe ~1500 Euro
Layer3 Switch, OSPF, RIP, IGMPv2, IGMP, VRRP, PIM-SM, PIM-DM, IGMPv3, MLDv2
Egal wie Ihr Euch entscheidet, aber nehmt von nur einem Hersteller die Switche und dann bitte Switche
für den Core Bereich der ein echter Layer3 Switch ist und nicht Layer2+ als Layer2 plus ein paar Layer3
Features. Oder zumindest wo man eine Layer3 Lizenz nachlösen kann um mehr herauszuholen.
Je nach Länge und zu überbrückenden Abstand ist man mit dem Netgear M4300-24x besser beraten, denn
wenn man hier von unter hundert Metern redet kann man das alles mittels CAT.6A Kabeln erledigen und
hat noch ordentlich gespart. Denn dann entfallen die SFP+ Optiken und die LWL Kabel alle samt.
Des weiteren kann man auch über eine Verwendung von VRRP & OSPF nachdenken und alles via einer
Software überwachen und managen. Man kann auch gerade wie bei Euch eine Spine-Leaf Struktur aufbauen
Gruß
Dobby
@108012
Sind die netgear Teile nicht sogar Full stacking fähig, sodass die 2 coreswitche wie einer agieren? Ich hab da was auf der Webseite gelesen.
Mal ungeachtet von den Herstellern, habe ich wie oben geschrieben noch ein paar Verständnisfragen zur Konfiguration der Switches, da ich das Thema VRRP in Verbindung mit vLAN noch nicht voll verstanden habe.
Sind die netgear Teile nicht sogar Full stacking fähig, sodass die 2 coreswitche wie einer agieren? Ich hab da was auf der Webseite gelesen.
Mal ungeachtet von den Herstellern, habe ich wie oben geschrieben noch ein paar Verständnisfragen zur Konfiguration der Switches, da ich das Thema VRRP in Verbindung mit vLAN noch nicht voll verstanden habe.
Nur damit ich hier nicht unwissend bleibe - was spräche gegen eine Wahl von den HP 1920 Switchen als Access? Was hätte ich
für einen Vorteil bei anderen Herstellern?
Zyxel GS2200 würde man zusammen eventuell stapeln (Switch Stack) können!für einen Vorteil bei anderen Herstellern?
Ich würde Switche benötigen, die mindestens 15 SFP Slots haben, damit ich die Access Switche über Glasfaser
anbinden kann. Welche Stacking Switche als Cores wären dann in diesem Fall ratsam?
Reden wir dann immer noch über eine 10 GBit/s Anbindung oder nur noch via 1 GBit/s?anbinden kann. Welche Stacking Switche als Cores wären dann in diesem Fall ratsam?
Sind die netgear Teile nicht sogar Full stacking fähig, sodass die 2 coreswitche wie einer agieren? Ich hab da was auf der Webseite gelesen.
Ich habe Dir zwei Sorten von Switchen empfohlen je nachdem was Ihr da alles braucht und benötigt, das kann ja auch starkvariieren und das weißt eben nur Du selber. Und da ich das mit den Switchen und deren Verteilung noch nicht herausgelesen
habe, habe ich eben zwei Varianten empfohlen! Einmal alles in ein oder zwei 19" Racks und einmal verteilt so wie Du es jetzt
hier beschrieben hast.
Alles in eine oder zwei Racks:
Zwei NETGEAR ProSafe XSM7224S mit Layer3 Lizenz als Core Switche und den Rest aus der M5300er Serie
Echtes Stacking mit Modulen
Leaf und Spine Topologie:
Alles aus der Netgear M4300 Serie!
Layer3 Switche mit OSPF und VRRP
Mal ungeachtet von den Herstellern, habe ich wie oben geschrieben noch ein paar Verständnisfragen zur Konfiguration der
Switches, da ich das Thema VRRP in Verbindung mit vLAN noch nicht voll verstanden habe.
Das ist mir schon klar nur es wird eben auch nicht besser wenn man Switche von zwei Herstellern nimmt!Switches, da ich das Thema VRRP in Verbindung mit vLAN noch nicht voll verstanden habe.
- Einfachere Konfiguration da beide das selbe GUI und CLI verwenden
- Bessere Verwaltbarkeit durch ein Software, bei Zyxel weiß ich das aber nicht so genau, bei Netgear heißt diese NMS300
- Man kann aus den Core und den Access Switchen eventuell auch Stapel erstellen!
- Nur eine Supportstelle
- Garantierte Kompatibilität aller Switche untereinander
Ich würde die Switche von Zyxel dann lieber alle von Zyxel nehmen wollen, GS2200 wären da eventuell kompatibel mit.
Gruß
Dobby
Hallo MasterPhil,
Im Datacenter? Nein! In einem echten Datacenter findet ZyXEL praktisch nicht statt. Mit dem XS3900-48F hat ZyXEL zwar einen DCB-fähigen ToR-Switch im Programm, aber es würde mich doch sehr wundern, wenn der in Deutschland überhaupt schon irgendwo im Einsatz wäre. Beim Distri auf Lager ist er jedenfalls nicht. Der wird wohl nur für spezielle Projekte geordert. Auf anderen Märkten mag es vielleicht anders aussehen.
Und damit kommen wir zum Kernproblem Deines Threads: Du wirfst hier mit Begriffen um Dich, die stark interpretierbar sind und vermutlich Deine Umgebung gar nicht richtig charakterisieren. Ein Datacenter ist für mich ein spezieller Gebäudekomplex mit Zugangssicherungen, Klimatisierung, Notfallstromversorgung, teilweise hunderten Racks und hunderten bis tausenden physischen Servern/Hosts. Allein das Thermalmanagement eines solchen Datacenters unterliegt schon umfangreichen Planungen und gewissenhaften Berechnungen! Gleiches gilt erst recht für die Netzwerkinfrastruktur, denn hier stellt - von den hohen zu verabreitenden Datenmengen und -raten abgesehen - vorallem auch das Thema Server- und Storagevirtualisierung spezielle Anforderungen.
Wenn Du hier z.B. von "Core-Switches" sprichst, dann erweckst Du bei dem ein oder anderen Leser gewisse Assoziationen an die Größe des Netzes und an die damit verbundenen Funktionsanforderungen, die mit Eurer Umgebung vermutlich gar nicht korrespondieren. Dementsprechend wird in den Antworten dann ganz gerne "draufgehauen" und es werden Dinge diskutiert und Lösungen empfohlen, die an Eurem Bedarf möglicherweise völlig vorbei gehen!
In diesem Sinne solltest Du auch einige Aussagen von Aqui einordnen. Er hat insofern Recht, als dass ZyXEL keine Core-Switche anbietet. Damit sind aber die Core-Switche für mindestens mittlere bis wirklich große Netze gemeint. In solchen Projekten kooperiert ZyXEL meines Wissens mit Extreme Networks. Definitiv Unrecht hat er, wenn er schreibt, dass ZyXEL nur "billigen Consumerschrott" anbieten würde. "Auch" wäre da wohl treffender. Denn neben den vielen Geräten für Privatanwender und Kleinunternehmen bietet ZyXEL auch viele Produkte an, die für den Mittelstand und für Carrier geeignet sind. So ist ZyXEL in Deutschland beispielsweise bei vielen City- und Regionalprovidern nicht nur mit CPEs, sondern auch mit DSLAMs und Switches im Access- und Distribution-Layer vertreten. Man beachte beispielsweise die breite Palette an Metro-Ethernetswitches.
Selbstverständlich kann es sinnvoll sein, auch Eurer vergleichsweise sehr kleines Netz logisch in gewisse "Layer" zu unterteilen und so zu beschreiben. Das kann die Diskussion darüber und die Planungen vereinfachen. Jedoch darf man dabei nicht Eure konkreten Anforderungen außer Acht lassen. Nur so kann man realistisch beurteilen, was für Euch sinnvoll ist und geeignete Empfehlungen geben. Alles andere wäre unseriös.
Genau in der Darstellung Eurer konkreten Anforderungen sehe ich hier bislang aber das größte Manko. Teilweise scheint Ihr Euch auch selbst darüber gar nicht im Klaren zu sein (VLANs, IP-Routing)!
Ich wüsste z.B. gern von Dir mehr über die Anbindung der Server an Euren kombinierten Core-, Distribution- bzw. Aggregation- und Datacenter-Layer.
Wieviele (physische) Server gibt es und wie werden diese angebunden (2x 10G?). Mit welcher Netzwerklast ist im Mittel und im Maximum zu rechnen? Wenn eine Servervirtualisierung zum Einsatz kommt, solltest Du darüber auch Näheres berichten. Wichtig wäre auch zu wissen, ob sich beide Coreswitche und alle Server am selben Standort befinden oder ob diese aus Redundanzgründen getrennt sind.
Auch die Anbindung der Accessswitche an den Core bedarf einer Klarstellung: Einerseits spricht die Hardwareauswahl dafür, dass alle Accessswitches mit 2x 10G an den Core angebunden werden sollen, andererseits sprichst Du selbst von einem Erfordernis von 15 SFP-Slots pro Coreswitch, was jeweils nur 1G wäre (SFP vs. SFP+)!
Ich bin wie Aqui durchaus ein Freund von Stacking. Aber man muss schon genau hinsehen, ob man sich damit nicht einen Flaschenhals einbaut! Angenommen, Deine Server sind mit x mal 10G an den Core-/DC-Layer angegebunden sowie dieser an den Accesslayer mit je 2x 10G und aufgrund des Stackings kann auf all diesen Links ein Linksaggregation gefahren werden, dann hast Du das Problem, dass zwischen den Stackmembern möglicherweise hoher Datenverkehr entsteht. Die Stackverbindung stellt zwischen den Stackmembern ja nicht nur die Controlplane, sondern auch die Dataplane! Wenn alle Ports 10G machen, erscheint es nicht sinnvoll, lediglich über 2x 10G zu stacken. Das müssten dann schon mind. 4x 10G sein. In meinem Netz sind die Switche für den kombinierten Core- und Datacenter-Accesslayer z.B. mit 8x 10G gestackt und werden demnächst durch 40G-Module ersetzt...
Das dürfte im übrigen auch der Grund sein, weshalb der vorgesehene ZyXEL-Switch XS3700-24 nicht stackingfähig ist (zumindest derzeit - auch bei anderen Modellen wurde das erst per Softwareupdate nachgereicht). Andere ZyXEL-Switche können sehrwohl gestackt werden. Aber nur über maximal 2x 10G. Deshalb macht das nur Sinn bei Switches, die im Wesentlichen nur 1G-Access-Ports haben und nur die Uplink- und Stackports 10G sind. Vor diesem Hintergrund sollte auch die Empfehlung von Aqui hinsichtlich der SG500X nocheinmal dringend hinterfragt werden: Laut Datenblatt können diese über die rückseitigen 5G-Kupferports oder über die normalen 10G-Ports gestackt werden. Sollten bei diesen Switchen also auch nur max. 2x 10G fürs Stacking zur Verfügung stehen, kann dies bei der vorgesehen Topologie ein Flaschenhals sein! Zumal hierfür wenn überhaupt nur der SG500XG in Frage käme, da die anderen nicht die erforderliche Anzahl an 10G-Ports haben. Und selbst bei diesem sind von den 16x 10G-Port 8 Stück reine Kupferports...
Sollten sich ohnehin alle Coreswitche und Server alle am selben Standort in unmittelbarer Nähe zueinander befinden, wäre m.E. eventuell ein vollredundant ausgebauter Modularswitch mit vollständig passiver Data- und Controlplane die bessere Alternative zum Stacking!
Im Übrigen ist es nicht ganz korrekt, dass man beim Einsatz von Spanning Tree zwangsläufig "tote Links" erhält. Das ist nur eine Frage des Designs: Angenommen Du hast 100 Endgeräte, dann packst Du davon 50 in ein VLAN und 50 in ein anderes, konfigurierst für jedes dieser VLANs eine eigene STP-Instance und sorgst dafür, dass diese Instanzen (logisch) auf unterschiedlichen Ports ("über kreuz") blocking gehen. Das geht zwischen Switchen verschiedener Hersteller mit MSTP oder bei einer homogenen Umgebung meist mittels proprietärer Protokolle noch eleganter. Ganz trivial ist die Einrichtung und der Betrieb von Spanning Tree gleichwohl nicht und so hat es durchaus etwas für sich, hierauf nach Möglichkeit zu verzichten...
Gruß
sk
Im Datacenter? Nein! In einem echten Datacenter findet ZyXEL praktisch nicht statt. Mit dem XS3900-48F hat ZyXEL zwar einen DCB-fähigen ToR-Switch im Programm, aber es würde mich doch sehr wundern, wenn der in Deutschland überhaupt schon irgendwo im Einsatz wäre. Beim Distri auf Lager ist er jedenfalls nicht. Der wird wohl nur für spezielle Projekte geordert. Auf anderen Märkten mag es vielleicht anders aussehen.
Und damit kommen wir zum Kernproblem Deines Threads: Du wirfst hier mit Begriffen um Dich, die stark interpretierbar sind und vermutlich Deine Umgebung gar nicht richtig charakterisieren. Ein Datacenter ist für mich ein spezieller Gebäudekomplex mit Zugangssicherungen, Klimatisierung, Notfallstromversorgung, teilweise hunderten Racks und hunderten bis tausenden physischen Servern/Hosts. Allein das Thermalmanagement eines solchen Datacenters unterliegt schon umfangreichen Planungen und gewissenhaften Berechnungen! Gleiches gilt erst recht für die Netzwerkinfrastruktur, denn hier stellt - von den hohen zu verabreitenden Datenmengen und -raten abgesehen - vorallem auch das Thema Server- und Storagevirtualisierung spezielle Anforderungen.
Wenn Du hier z.B. von "Core-Switches" sprichst, dann erweckst Du bei dem ein oder anderen Leser gewisse Assoziationen an die Größe des Netzes und an die damit verbundenen Funktionsanforderungen, die mit Eurer Umgebung vermutlich gar nicht korrespondieren. Dementsprechend wird in den Antworten dann ganz gerne "draufgehauen" und es werden Dinge diskutiert und Lösungen empfohlen, die an Eurem Bedarf möglicherweise völlig vorbei gehen!
In diesem Sinne solltest Du auch einige Aussagen von Aqui einordnen. Er hat insofern Recht, als dass ZyXEL keine Core-Switche anbietet. Damit sind aber die Core-Switche für mindestens mittlere bis wirklich große Netze gemeint. In solchen Projekten kooperiert ZyXEL meines Wissens mit Extreme Networks. Definitiv Unrecht hat er, wenn er schreibt, dass ZyXEL nur "billigen Consumerschrott" anbieten würde. "Auch" wäre da wohl treffender. Denn neben den vielen Geräten für Privatanwender und Kleinunternehmen bietet ZyXEL auch viele Produkte an, die für den Mittelstand und für Carrier geeignet sind. So ist ZyXEL in Deutschland beispielsweise bei vielen City- und Regionalprovidern nicht nur mit CPEs, sondern auch mit DSLAMs und Switches im Access- und Distribution-Layer vertreten. Man beachte beispielsweise die breite Palette an Metro-Ethernetswitches.
Selbstverständlich kann es sinnvoll sein, auch Eurer vergleichsweise sehr kleines Netz logisch in gewisse "Layer" zu unterteilen und so zu beschreiben. Das kann die Diskussion darüber und die Planungen vereinfachen. Jedoch darf man dabei nicht Eure konkreten Anforderungen außer Acht lassen. Nur so kann man realistisch beurteilen, was für Euch sinnvoll ist und geeignete Empfehlungen geben. Alles andere wäre unseriös.
Genau in der Darstellung Eurer konkreten Anforderungen sehe ich hier bislang aber das größte Manko. Teilweise scheint Ihr Euch auch selbst darüber gar nicht im Klaren zu sein (VLANs, IP-Routing)!
Ich wüsste z.B. gern von Dir mehr über die Anbindung der Server an Euren kombinierten Core-, Distribution- bzw. Aggregation- und Datacenter-Layer.
Wieviele (physische) Server gibt es und wie werden diese angebunden (2x 10G?). Mit welcher Netzwerklast ist im Mittel und im Maximum zu rechnen? Wenn eine Servervirtualisierung zum Einsatz kommt, solltest Du darüber auch Näheres berichten. Wichtig wäre auch zu wissen, ob sich beide Coreswitche und alle Server am selben Standort befinden oder ob diese aus Redundanzgründen getrennt sind.
Auch die Anbindung der Accessswitche an den Core bedarf einer Klarstellung: Einerseits spricht die Hardwareauswahl dafür, dass alle Accessswitches mit 2x 10G an den Core angebunden werden sollen, andererseits sprichst Du selbst von einem Erfordernis von 15 SFP-Slots pro Coreswitch, was jeweils nur 1G wäre (SFP vs. SFP+)!
Ich bin wie Aqui durchaus ein Freund von Stacking. Aber man muss schon genau hinsehen, ob man sich damit nicht einen Flaschenhals einbaut! Angenommen, Deine Server sind mit x mal 10G an den Core-/DC-Layer angegebunden sowie dieser an den Accesslayer mit je 2x 10G und aufgrund des Stackings kann auf all diesen Links ein Linksaggregation gefahren werden, dann hast Du das Problem, dass zwischen den Stackmembern möglicherweise hoher Datenverkehr entsteht. Die Stackverbindung stellt zwischen den Stackmembern ja nicht nur die Controlplane, sondern auch die Dataplane! Wenn alle Ports 10G machen, erscheint es nicht sinnvoll, lediglich über 2x 10G zu stacken. Das müssten dann schon mind. 4x 10G sein. In meinem Netz sind die Switche für den kombinierten Core- und Datacenter-Accesslayer z.B. mit 8x 10G gestackt und werden demnächst durch 40G-Module ersetzt...
Das dürfte im übrigen auch der Grund sein, weshalb der vorgesehene ZyXEL-Switch XS3700-24 nicht stackingfähig ist (zumindest derzeit - auch bei anderen Modellen wurde das erst per Softwareupdate nachgereicht). Andere ZyXEL-Switche können sehrwohl gestackt werden. Aber nur über maximal 2x 10G. Deshalb macht das nur Sinn bei Switches, die im Wesentlichen nur 1G-Access-Ports haben und nur die Uplink- und Stackports 10G sind. Vor diesem Hintergrund sollte auch die Empfehlung von Aqui hinsichtlich der SG500X nocheinmal dringend hinterfragt werden: Laut Datenblatt können diese über die rückseitigen 5G-Kupferports oder über die normalen 10G-Ports gestackt werden. Sollten bei diesen Switchen also auch nur max. 2x 10G fürs Stacking zur Verfügung stehen, kann dies bei der vorgesehen Topologie ein Flaschenhals sein! Zumal hierfür wenn überhaupt nur der SG500XG in Frage käme, da die anderen nicht die erforderliche Anzahl an 10G-Ports haben. Und selbst bei diesem sind von den 16x 10G-Port 8 Stück reine Kupferports...
Sollten sich ohnehin alle Coreswitche und Server alle am selben Standort in unmittelbarer Nähe zueinander befinden, wäre m.E. eventuell ein vollredundant ausgebauter Modularswitch mit vollständig passiver Data- und Controlplane die bessere Alternative zum Stacking!
Im Übrigen ist es nicht ganz korrekt, dass man beim Einsatz von Spanning Tree zwangsläufig "tote Links" erhält. Das ist nur eine Frage des Designs: Angenommen Du hast 100 Endgeräte, dann packst Du davon 50 in ein VLAN und 50 in ein anderes, konfigurierst für jedes dieser VLANs eine eigene STP-Instance und sorgst dafür, dass diese Instanzen (logisch) auf unterschiedlichen Ports ("über kreuz") blocking gehen. Das geht zwischen Switchen verschiedener Hersteller mit MSTP oder bei einer homogenen Umgebung meist mittels proprietärer Protokolle noch eleganter. Ganz trivial ist die Einrichtung und der Betrieb von Spanning Tree gleichwohl nicht und so hat es durchaus etwas für sich, hierauf nach Möglichkeit zu verzichten...
Gruß
sk
dass man beim Einsatz von Spanning Tree zwangsläufig "tote Links" erhält. Das ist nur eine Frage des Designs:
Da hast du natürlich absolut Recht nur die Fragestellung und Vermischung von L2 und L3 Funktionen des TOs lässt vermuten das er mit STP Optimierung wenig bis gar keine Erfahrung hat und was das Setup in einem non-stacking Design erschwert.Auf der anderen Seite sprengt es den Rahmen dieses Threads würde man jetzt im Einzelnen die VLAN basierte Priorisierung mit PVSTP erklären.
Deshalb war oben nur kurz angerissen hier sinnigerweise auf MSTP zu setzen und es, wie du ja auch richtig sagst, über die Instances dort und deren Priorisierung der Root Bridges zu lösen, was es für STP Anfänger etwas vereinfacht.
Aber so oder so erhöht das erheblich den Konfig Aufwand und das Management. Gerade auch bei Änderungen am Netz.
In einem Stacking Design entfällt das. Man kann es nur immer wiederholen.
@aqui: Wo kommt das Zitat her? Erscheint zusammenhangslos...
Welches Zitat meinst du ?? Das mit den MSTP Instances ?
Ich meinte das:
"Der Hauptnutzen wäre doch dabei zwei räumlich weit getrennte Netzwerke zu verbinden und wenig Verluste aufgrund der Kabellänge zu haben."
@MasterPhil:
Ich habe mir jetzt mal die neuen SG350X- und SG550X-Modelle von CSB angesehen (die hier noch oft empfohlenen SG300 und SG500[X] sind end of life). Es gibt jetzt auch Modelle mit 24 SFP+-Ports, was Euren Anforderungen im "Core" entsprechen dürfte. Nämlich die Modelle SG350XG-24F und SG550XG-24F.
Auch positiv: Den Stack kann man zumindest beim 550er auch über ein LAG "fahren". Im Datenblatt des 550ers ist das explizit erwähnt: http://www.cisco.com/c/dam/en/us/products/collateral/switches/550x-seri ...
Das Datenblatt des 350ers schweigt sich hierzu leider aus: http://www.cisco.com/c/dam/en/us/products/collateral/switches/350x-seri ...
Das Admin-Guide erweckt jedoch den Anschein, dass LAGG-Stacking auch beim 350X möglich wäre: http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/350xg/admin ...
Welche Unterschiede gibt es ansonsten noch zwischen 350X und 550X? Auf den ersten Blick folgendes:
1) der 550X kann optional mit redundanten Netzteilen und Lüftern ausgestattet werden - wäre in Eurem Szenario m.E. überflüssig.
2) der 550X kann dynamisches Routing - der 350X nur statisches. Letzteres dürfte bei Euch normalerweise reichen.
3) der 550X unterstützt nunmehr auch "Community Private VLAN" - der 350X weiterhin nur "Private VLAN Edge". Benötigen werdet Ihr vermutlich weder das Eine noch das Andere.
4) beim 550X können bis zu 8 Geräte gestackt werden - beim 350X lediglich bis zu vier
Der 350X sollte Euch also eigentlich genügen. Da der Mehrpreis zum 550X aber vergleichsweise gering ist, wäre meine Empfehlung:
Im "Core" 2x SG550XG-24F gestackt über ein LAG mit 4x 10G.
Um die Administration zu vereinheitlichen, würde ich den Edge dann auch eher entsprechend dem jeweiligen Bedarf mit SG350 oder SG350X ausstatten. Da gibt es auch einige Modelle, die lüfterlos sind. Stacken würde ich die Edge-Switche nur innerhalb des gleichen Verteilerschrankes - nicht schrankübergreifend oder gar zwischen Edge und Core.
Beachte jedoch, wenn Du auf CSB setzt, dass - wenn ich das richtig gesehen habe - Firmwareupdates und Support nur für ein Jahr inkludiert sind. Darüber hinaus musst Du dafür Cisco-typisch Extrakohle für Smartnet-Verträge auf den Tisch legen. Bei der ehemaligen Procurve-Serie von HPE-Aruba und bei Zyxel sind Firmwareupdates für den Produktlifecycle hingegen kostenlos.
Gruß
sk
"Der Hauptnutzen wäre doch dabei zwei räumlich weit getrennte Netzwerke zu verbinden und wenig Verluste aufgrund der Kabellänge zu haben."
@MasterPhil:
Ich habe mir jetzt mal die neuen SG350X- und SG550X-Modelle von CSB angesehen (die hier noch oft empfohlenen SG300 und SG500[X] sind end of life). Es gibt jetzt auch Modelle mit 24 SFP+-Ports, was Euren Anforderungen im "Core" entsprechen dürfte. Nämlich die Modelle SG350XG-24F und SG550XG-24F.
Auch positiv: Den Stack kann man zumindest beim 550er auch über ein LAG "fahren". Im Datenblatt des 550ers ist das explizit erwähnt: http://www.cisco.com/c/dam/en/us/products/collateral/switches/550x-seri ...
Das Datenblatt des 350ers schweigt sich hierzu leider aus: http://www.cisco.com/c/dam/en/us/products/collateral/switches/350x-seri ...
Das Admin-Guide erweckt jedoch den Anschein, dass LAGG-Stacking auch beim 350X möglich wäre: http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/350xg/admin ...
Welche Unterschiede gibt es ansonsten noch zwischen 350X und 550X? Auf den ersten Blick folgendes:
1) der 550X kann optional mit redundanten Netzteilen und Lüftern ausgestattet werden - wäre in Eurem Szenario m.E. überflüssig.
2) der 550X kann dynamisches Routing - der 350X nur statisches. Letzteres dürfte bei Euch normalerweise reichen.
3) der 550X unterstützt nunmehr auch "Community Private VLAN" - der 350X weiterhin nur "Private VLAN Edge". Benötigen werdet Ihr vermutlich weder das Eine noch das Andere.
4) beim 550X können bis zu 8 Geräte gestackt werden - beim 350X lediglich bis zu vier
Der 350X sollte Euch also eigentlich genügen. Da der Mehrpreis zum 550X aber vergleichsweise gering ist, wäre meine Empfehlung:
Im "Core" 2x SG550XG-24F gestackt über ein LAG mit 4x 10G.
Um die Administration zu vereinheitlichen, würde ich den Edge dann auch eher entsprechend dem jeweiligen Bedarf mit SG350 oder SG350X ausstatten. Da gibt es auch einige Modelle, die lüfterlos sind. Stacken würde ich die Edge-Switche nur innerhalb des gleichen Verteilerschrankes - nicht schrankübergreifend oder gar zwischen Edge und Core.
Beachte jedoch, wenn Du auf CSB setzt, dass - wenn ich das richtig gesehen habe - Firmwareupdates und Support nur für ein Jahr inkludiert sind. Darüber hinaus musst Du dafür Cisco-typisch Extrakohle für Smartnet-Verträge auf den Tisch legen. Bei der ehemaligen Procurve-Serie von HPE-Aruba und bei Zyxel sind Firmwareupdates für den Produktlifecycle hingegen kostenlos.
Gruß
sk
@sk
Du hast Recht. Da ist irgendwas mit dem Cut and Paste schiefgegangen....
Es bezog sich natürlich auf das STP Customizing. Ist korrigiert.
Du hast Recht. Da ist irgendwas mit dem Cut and Paste schiefgegangen....
Es bezog sich natürlich auf das STP Customizing. Ist korrigiert.
Off Topic in eigener Sache:
Sollte ein Cisco-Vertriebspartner (vorzugsweise aus dem Rheinland) mitlesen: Ich hätte Interesse an einer Teststellung von mind. 2x 350X (und/oder 2x 550X) je mit mind. 4x 10G. Muss nicht kostenlos sein - gern gegen angemessenes Entgelt. Bei Gefallen gerne mit Übernahmeoption. Könnte mir vorstellen, bei künftigen Beschaffungen im Edge- und Distribution-Layer auf CSB zu wechseln. Gefallen mir "von der Papierform her" ganz gut...
Wenn ich Zeit finde, gibt es auch ein Review fürs Forum.
Kontaktaufnahme bitte per PN
Danke und Gruß
sk
Sollte ein Cisco-Vertriebspartner (vorzugsweise aus dem Rheinland) mitlesen: Ich hätte Interesse an einer Teststellung von mind. 2x 350X (und/oder 2x 550X) je mit mind. 4x 10G. Muss nicht kostenlos sein - gern gegen angemessenes Entgelt. Bei Gefallen gerne mit Übernahmeoption. Könnte mir vorstellen, bei künftigen Beschaffungen im Edge- und Distribution-Layer auf CSB zu wechseln. Gefallen mir "von der Papierform her" ganz gut...
Wenn ich Zeit finde, gibt es auch ein Review fürs Forum.
Kontaktaufnahme bitte per PN
Danke und Gruß
sk
@aqui
Danke für deine kritischen Kommentare Ich bin selbst erst 20 und möchte natürlich auch mal "was Größeres" administrieren oder zumindest mich darauf hin arbeiten. Anlesen ist immer gut, gerade was die Routing Protokolle, VLANs usw. an geht aber ich bin dann immer vor der Konfiguration und dann klappt es doch nicht so wie angelesen. Von der Berufsschule kennt man zwar noch die Protokolle, was man so gelernt hat von RIP über STP usw. aber das ganze dann in der Anwendung je nach Szenario ist dann eine andere Welt. Was ist denn ein guter Weg, um in den Themen VLAN / Routing "besser" zu werden? Lesen bis man Nachts davon träumt? Praktisch muss das ganze ja einmal umgesetzt werden.
Zum Eigentlichen Thema:
Wir haben uns nun für die Netgear Switche entschieden. Layer 3 als Core. Layer 2 als Access. Die Netgear switche lassen sich stacken - natürlich kein Full Stack aber Redundanz ist dadurch möglich, mit einer Downtime von etwa 2 Minuten. Das ist für uns vertretbar. Somit würde dann VRRP/HRSP weg fallen. Ich stehe jetzt aber noch vor dem VLAN Thema und möchte dich hierzu noch nach deiner Meinung fragen.
Aktuell ist das Netz ein Riesiges Klasse C mit einer SN von 255.255.0.0. Verschiedene Firmenbereiche sollen eigentlich auf andere nicht Zugreifen könne. Daher dachte ich an Aufteilung in VLANs - z. B. 192.168.1.0 255.255.255.0 für Produktion, 192.168.0.0 255.255.255.0 für Server etc.
Die Access Switche werden untereinander gestackt (wo 2-3 in einem Schrank sind) und gehen mit einer LWL Leitung als Uplink zum Core. Liege ich da richtig, dass die Stacking-Leitungen zwischen den Switchen und die Uplink Leitung zum Core getagged werden müssen und auf den Switchen kann ich dann Gruppen einrichten z. B. Port 1-12 VLAN 10 usw? Die Endgeräte bekommen somit untagged Pakete und über die Uplink Leitungen gehen "alle VLANs". Das Routing übernimmt dann der Layer 3 Core Switch?
Ist es hier dann Sinnvoll im Core Switch einen DHCP Server für die verschiedenen VLANs zu aktivieren? Wie wird dann der Internetrouter eingebunden, damit die einzelnen VLANs Internet haben?
Danke für deine kritischen Kommentare
Ich bin selbst erst 20 und möchte natürlich auch mal "was Größeres" administrieren oder zumindest mich darauf hin arbeiten. Anlesen ist immer gut, gerade was die Routing Protokolle, VLANs usw. an geht aber ich bin dann immer vor der Konfiguration und dann klappt es doch nicht so wie angelesen. Von der Berufsschule kennt man zwar noch die Protokolle, was man so gelernt hat von RIP über STP usw. aber das ganze dann in der Anwendung je nach Szenario ist dann eine andere Welt. Was ist denn ein guter Weg, um in den Themen VLAN / Routing "besser" zu werden? Lesen bis man Nachts davon träumt? Praktisch muss das ganze ja einmal umgesetzt werden.Zum Eigentlichen Thema:
Wir haben uns nun für die Netgear Switche entschieden. Layer 3 als Core. Layer 2 als Access. Die Netgear switche lassen sich stacken - natürlich kein Full Stack aber Redundanz ist dadurch möglich, mit einer Downtime von etwa 2 Minuten. Das ist für uns vertretbar. Somit würde dann VRRP/HRSP weg fallen. Ich stehe jetzt aber noch vor dem VLAN Thema und möchte dich hierzu noch nach deiner Meinung fragen.
Aktuell ist das Netz ein Riesiges Klasse C mit einer SN von 255.255.0.0. Verschiedene Firmenbereiche sollen eigentlich auf andere nicht Zugreifen könne. Daher dachte ich an Aufteilung in VLANs - z. B. 192.168.1.0 255.255.255.0 für Produktion, 192.168.0.0 255.255.255.0 für Server etc.
Die Access Switche werden untereinander gestackt (wo 2-3 in einem Schrank sind) und gehen mit einer LWL Leitung als Uplink zum Core. Liege ich da richtig, dass die Stacking-Leitungen zwischen den Switchen und die Uplink Leitung zum Core getagged werden müssen und auf den Switchen kann ich dann Gruppen einrichten z. B. Port 1-12 VLAN 10 usw? Die Endgeräte bekommen somit untagged Pakete und über die Uplink Leitungen gehen "alle VLANs". Das Routing übernimmt dann der Layer 3 Core Switch?
Ist es hier dann Sinnvoll im Core Switch einen DHCP Server für die verschiedenen VLANs zu aktivieren? Wie wird dann der Internetrouter eingebunden, damit die einzelnen VLANs Internet haben?
Lesen bis man Nachts davon träumt? Praktisch muss das ganze ja einmal umgesetzt werden.
Vorsicht, denn bei netgear machen die Leute meist gerade den die Bedienungsanleitung nicht zu lesen!!!!! Und dannist das Geschrei schnell groß was Netgear alles nicht kann und/oder falsch macht. Mal ein Beispiel dazu:
- Bei vielen wenn nicht fast allen Herstellern von Switchen nimmt man den einzelnen Port bzw. die Ports
eines LAGs (LACP) und nimmt sie zu einem VLAN als "Member"hinzu.
- Bei Netgear muss das gesamt LAG mit Nummer also LAG1 hinzugefügt werden damit es auf anhieb passt.
Dann gibt es auch keine Probleme damit. Nur weil eben viele Leute die Bedienungsanleitung nicht lesen,
passt es dann bei Ihnen nicht mit solchen Dingen. Also das Handbuch ist bei Netgear echt entscheidend.
Zum Eigentlichen Thema:
Darf man einmal erfahren für welche Kombination Ihr Euch entschieden habt?Ich habe zwei Vorschläge gemacht und die harmonieren alle mit einander und können auch gestapelt werden, also sprich
die Switche von Vorschlag eins können untereinander gestapelt werden und die Switche aus Vorschlag 2 können auch alle
untereinander gestapelt werden.
Wir haben uns nun für die Netgear Switche entschieden. Layer 3 als Core. Layer 2 als Access.
Aus der M4300 Serie die Switche sind alle Layer3 Switche! Und diese können OSPF und auch VRRP, eventuell lässt mandann die beiden Core Switche mit VRRP laufen und dann die anderen mittels OSPF, wäre ja auch zu überlegen ob das
eventuell besser ist oder gar mehr Sinn macht.
Die Netgear switche lassen sich stacken - natürlich kein Full Stack aber Redundanz ist dadurch möglich,
Schreib doch bitte einmal welche Switche ihr Euch ausgesucht habt. Den wie oben schon beschrieben lassen sich dieSwitche aus meinem Vorschlag Nummer eins alle mit bzw. untereinander stapeln und auch die aus Vorschlag Nummer zwei.
mit einer Downtime von etwa 2 Minuten.
Ist etwas hoch oder? Man kann auch einen Layer3 Switch den Stapel selber routen lassen und die Stapel dannan die Core Switche anschließen.
Das ist für uns vertretbar. Somit würde dann VRRP/HRSP weg fallen.
Beide Switche für den Core Bereich können VRRP, die aus der M4300er Serie sogar von Haus aus und der XSM7224Smittels einer Layer3 Lizenz auch auf jeden Fall.
Ich stehe jetzt aber noch vor dem VLAN Thema und möchte dich hierzu noch nach deiner Meinung fragen.
Aktuell ist das Netz ein Riesiges Klasse C mit einer SN von 255.255.0.0. Verschiedene Firmenbereiche sollen
eigentlich auf andere nicht Zugreifen könne.
In der Regel kann man jedem VLAN seinen eigenen IP Adressbereich vergeben, also sprich;Aktuell ist das Netz ein Riesiges Klasse C mit einer SN von 255.255.0.0. Verschiedene Firmenbereiche sollen
eigentlich auf andere nicht Zugreifen könne.
VLAN10 - 192.168.1.0/24
VLAN20 - 192.168.2.0/24
usw.
Daher dachte ich an Aufteilung in VLANs - z. B. 192.168.1.0 255.255.255.0 für Produktion, 192.168.0.0 255.255.255.0 für Server etc.
So würde ich das auch machen wollen.Die Access Switche werden untereinander gestackt (wo 2-3 in einem Schrank sind) und gehen mit einer LWL
Leitung als Uplink zum Core.
In die Stapel kann man auch die Core Switche mit einbeziehen oder aber auch eine Leaf / Spine Struktur aufbauenLeitung als Uplink zum Core.
was hier eventuell besser passt.
Liege ich da richtig, dass die Stacking-Leitungen zwischen den Switchen und die Uplink Leitung zum Core getagged werden müssen
Bei den Stapeln liegt es an den Switches selber was und wie konfiguriert werden muss, aber in der Regel werden Switch zu Switchund Router zu Switch immer "getaggt" verbunden.
und auf den Switchen kann ich dann Gruppen einrichten z. B. Port 1-12 VLAN 10 usw?
- VLAN anlegen- Namen vergeben (nach Etage oder Abteilung)
- Ports editieren und hinzufügen
- Ausnahme sind LAGs (LACP) hier wird das gesamte LAG hinzugefügt und nicht die einzelnen Ports
Die Endgeräte bekommen somit untagged Pakete und über die Uplink Leitungen gehen "alle VLANs".
Genau.Das Routing übernimmt dann der Layer 3 Core Switch?
Jo und je nach Switch kann man sicherlich auch über ein PBR nachdenken und eventuell beide Core Switche im Einsatz habenohne eine VRRP "stand by" Konfiguration.
Ist es hier dann Sinnvoll im Core Switch einen DHCP Server für die verschiedenen VLANs zu aktivieren?
Je nach Switchen und Konfiguration kann man das machen und dann auf den Stapeln einen einen DHCP Relay Agent aktivierenoder aber auch dort gleich den internen DHCP Server verwenden.
Wie wird dann der Internetrouter eingebunden, damit die einzelnen VLANs Internet haben?
Je nach dem ob der VLANs unterstützt oder nicht wird er an die Core Switche eingebunden. Wenn er keine VLANs unterstützt dannwird ein extra VLAN angelegt und dort ist dann die IP Adresse des Routers die Gateway Adresse. Dann sollte aber schon etwas wie
VRRP mit im Spiel sein, weil man den Router an beide Core Switche einbinden muss bzw. sollte.
Gruß
Dobby
Hallo Dobby,
vielen Dank erstmal!
Wir nutzen als Core die M4300 und der Rest sind L2 GS728TXP. Weil wir nicht jeden Switch einzeln an den Core anbinden, genügt uns der 12x12f und wir benötigen nicht so viele SFP+ Module. Die Downtime von etwa 2 Minuten ist abgesprochen und OK. Somit genügt es wenn wir die Core Stacken und können uns VRRP sparen.
Das mit den VLANs ist in jedem Fall sinnvoll und setzen wir so um.
Wir setzen eine Securepoint RC300 ein. Macht es Sinn so eine Firewall in ein extra VLAN zu stellen bzw. wie kann die Firewall am sinnvollsten eingebunden werden? Diese ist AntiSpam für den Exchange und macht alle weiteren Dinge die eine UTM Lösung so macht.
vielen Dank erstmal!
Darf man einmal erfahren für welche Kombination Ihr Euch entschieden habt?
Wir nutzen als Core die M4300 und der Rest sind L2 GS728TXP. Weil wir nicht jeden Switch einzeln an den Core anbinden, genügt uns der 12x12f und wir benötigen nicht so viele SFP+ Module. Die Downtime von etwa 2 Minuten ist abgesprochen und OK. Somit genügt es wenn wir die Core Stacken und können uns VRRP sparen.
Das mit den VLANs ist in jedem Fall sinnvoll und setzen wir so um.
Wir setzen eine Securepoint RC300 ein. Macht es Sinn so eine Firewall in ein extra VLAN zu stellen bzw. wie kann die Firewall am sinnvollsten eingebunden werden? Diese ist AntiSpam für den Exchange und macht alle weiteren Dinge die eine UTM Lösung so macht.
Wir haben uns nun für die Netgear Switche entschieden. Layer 3 als Core. Layer 2 als Access.
Ein Fehler ! Das siehst du schon an den massiven Einschränkungen die man in der Funktion hat. Auch das GUI ist wenig intuitiv. Wahrlich keine gute und intelligente Wahl aber du hast sicher deine Gründe dafür und technisch wird das sicher auch gehen wenn auch mit Klimmzügen.was man so gelernt hat von RIP über STP usw. aber das ganze dann in der Anwendung je nach Szenario ist dann eine andere Welt.
Natürlich NICHT für einen Mitarbeiter in der IT Abteilung. Der geht damit tagtäglich um und für den ist das Alltag Aktuell ist das Netz ein Riesiges Klasse C mit einer SN von 255.255.0.0.
Wie gruselig. No comment... L2 Broadcast Doamins sollten nie mahr als 150 bis max 200 Endgeräte beinhalten !Nochwas: Klasseneinteilung bei IP Netzwerken ist netzwerktechnische Steinzeit, das gibt es schon seit weit über 20 Jahren ! nicht mehr. Vergiss diesen Unsinn also:
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Verschiedene Firmenbereiche sollen eigentlich auf andere nicht Zugreifen könne.
Sinnvoll und natürlich auch gängige Praxis bei VLAN Segmentierung.Eine Segmentierung mit einem 24er Prefix (255.255.255.0 er Maske) ist sinnvoll und erleichtert den Überblick zumal man im 3ten Byte z.B. das VLAN kodieren kann usw.
Du solltest nur besser KEINE dieser dümmlichen 192.168er Allerweltsnetze nehmen sondern auf andere IP Netze des RFC 1918 Bereichs ausweichen:
https://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche
Das macht deshalb Sinn damit du nicht gleich bei VPN Nutzung oder NAT usw. in IP Adresskonflikte gerät.
Das 10er oder 172er Netz bietet da genug sinnvolle Alternativen wenn du jetzt die Chance hast das gleich richtig zu machen für die Zukunft !
Die Access Switche werden untereinander gestackt (wo 2-3 in einem Schrank sind) und gehen mit einer LWL Leitung als Uplink zum Core.
Viel sinnvoller wären hier natürlich zwei LWL Links jeweils von den äußeren Stack Membern zum Core und das idealerweise als LACP LAG ausgeführt um Spanning Tree aus dem Wege zu gehen und gleichzeitige Ausfallredundanz zu haben ! Siehe entsprechende Zeichnung oben !Auf den Stacking Ports rennt so oder so (fast) immer ein Hersteller proprietäres Protokoll. Du musst die Stacking Ports lediglich als Stack Ports konfigurieren, der Rest geschieht in der Regel automatisch.
Was die Uplink Ports anbetrifft müssen die natürlich tagged sein um die VLAN Informationen an den Core Stack zu übertragen, da hier ja das zenztrale L3 Switching (Routing) passiert.
In einem reinen gestackten Design kannst du auf jegliches Spanning Tree und auch Customizing verzichten. Und solltest du auch !!!
Wenn du den Core stacken kannst und auch die Access Switches, dann kannst du mit LACP Trunks arbeiten auf den Core und brauchst keinerlei STP und auch kein Customizing desselben mehr...logisch.
Das wäre ein ideales Design.
STP brauchst du ja nur wenn du den Core NICHT stacken kannst und als 2 Einzelgeräte in einem STP HA (High Availability) Design MIT Spanning Tree und VRRP betteiben musst.
Entfällt ja nun bei dir mit der Stacking Fähigkeit des Cores !
Ist es hier dann Sinnvoll im Core Switch einen DHCP Server für die verschiedenen VLANs zu aktivieren?
Nein ! Das sollte man in so einem größeren Design niemals machen !Sinn macht hier nur ein zenraler DHCP Server, den du vermutlich so oder so schon betreibst wenn du ein Microsoft Umfeld hast.
Hier werden dann einfach nur die zusätzlichen Scopes der neuen VLANs eingetragen und die DHCP Requests aus den VLAN Segmenten mit der DHCP Relay bzw. Forwarder Funktion auf den L3 Core Switches auf diesen zentralen DHCP Server geforwardet der sie dann verwaltet. Das wäre der richtige Weg !
Macht es Sinn so eine Firewall in ein extra VLAN zu stellen
Absolut ! Eine FW gehört in einem L3 Netzwerk niemals in ein produktives VLAN ! Auch WLAN und besonders Gast WLAN sind immer separate VLANs.Wie wird dann der Internetrouter eingebunden, damit die einzelnen VLANs Internet haben?
Das erklärt dir dieser Thread ganz genau:Bestehendes Netzwerk in VLANs trennen, Einkaufsberatung
Bei dir sind es natürlich vermutlich etwas mehr als die 3 VLANs dort
Kollege Dobby hat noch nicht verinnerlicht das dein Core ein Stack ist und damit natürlich dann sowas wie VRRP usw. entfällt. Sinnvoll wäre es aber den Internet Router auch mit einem LACP LAG oder wenigstens 2 Links an die Core Member anzubinden um hier Redundanz zu schaffen sofern die Internet Anbindung wichtig ist und wenig Downtime gefordert ist !
Wahrlich keine gute und intelligente Wahl aber du hast sicher deine Gründe dafür und technisch wird das sicher auch gehen wenn auch mit Klimmzügen
Das wurde nun als günstigste und beste Lösung in dem Preisbereich abgesegnet. Ich kann wenigstens die Switche zentral verwalten und habe alles vom selben Hersteller. Ich bin glücklicher als mit der Zyxel-HP-Lösung....Natürlich NICHT für einen Mitarbeiter in der IT Abteilung. Der geht damit tagtäglich um und für den ist das Alltag
Dann wäre es für mich gerne auch mal Alltag. Ich kenne es nur von Freunden, die in größeren Firmen arbeiten. Da kommt nicht viel neues dazu und die haben auch keine richtigen Berührungen mit Routing und VLAN, weil das Grundsätzliche alles schon steht...Du solltest nur besser KEINE dieser dümmlichen 192.168er Allerweltsnetze nehmen sondern auf andere IP Netze des RFC 1918 Bereichs ausweichen
Ich habe mir dazu sowieso überlegt, das Netz in VLANs als 172.16.0.0/24, 172.16.1.0/24 usw aufzuteilen.Du solltest nur besser KEINE dieser dümmlichen 192.168er Allerweltsnetze nehmen sondern auf andere IP Netze des RFC 1918 Bereichs ausweichen:
Was ändert das aber nun für mich bewusst ob ich die 192er Netze oder die 172er Netze nutze?In einem reinen gestackten Design kannst du auf jegliches Spanning Tree und auch Customizing verzichten. Und solltest du auch !!!
Die Netgear lassen sich leicht stacken - einer geht dann in den Standby und beide sind über eine IP erreichbar. Ich habe die Downtime per Stoppuhr gemessen. Trenne ich einen vom Strom dauert es etwa 2 Minuten bis der zweite aktiv geht - das ist OK.Nein ! Das sollte man in so einem größeren Design niemals machen !
Was spricht genau gegen DHCP am L3 Core? Dann lieber den MS DHCP nutzen? Die Relay Funktion habe ich gesehen im Switch.Absolut ! Eine FW gehört in einem L3 Netzwerk niemals in ein produktives VLAN !
Genügt es für die FW ein VLAN anzulegen mit z. B. 172.16.0.0/28 oder /30? Der Hostanteil muss hier ja nicht groß sein?Bei dir sind es natürlich vermutlich etwas mehr als die 3 VLANs dort
Es kommen max. 6-7 VLANs.Nun habe ich die VLANs gedanklich mal so aufgeteilt. Die Server in einem VLAN, Abteilungen geteilt, FW in einem VLAN, Gäste in ihrem VLAN. Soweit alles OK. Wie sieht es dann mit dem Windows DNS Server/Domaincontroller aus? Aktuell sitzen ja quasi alle im selben, großen Netz. Das GW ist auf jedem PC der Router, der DNS der Domaincontroller.
Wie sieht das dann später mit den VLANs aus, sodass dann natürlich auch die Namensauflösung weiterhin klappt? Wie kann ich mir das dann vorstellen, welches Gateway bzw. welchen DNS dann die einzelnen VLAN-Member nutzen?
In welches VLAN sollten dann die Switche selbst um auf die Konfig zugreifen zu können, standardmäßig ist ja das Management VLAN sowie alle Ports auf 1. Beim Testen habe ich gemerkt, dass der Zugriff auf den Switch dann auch auf die Gateway Adresse des VLAN möglich ist. Sollte das noch gesperrt werden?
Sollten Drucker auch in ein eingenes VLAN? Es könnte ja sein dass mehrere Abteilungen Drucker teilen bzw. auch Drucker in anderen Abteilungen drucken. Sollte sowas mit berücksichtigt werden?
Die FW hat dann nur eine IP in ihrem VLAN und der L3 Core routet dann Datenverkehr, der ins Internet soll über das VLAN/die Firewall?
Wie würdest du am Besten vorgehen, um das bestehende Class C Netz zu ändern bzw in VLANs zu splitten, gerade was die Domaincontroller/Server angeht (mir geht das da generell um das spätere neue Design).
Das wurde nun als günstigste und beste Lösung
Günstig ja beste definitiv Nein...aber dazu würde ja schon alles gesagt oben.die haben auch keine richtigen Berührungen mit Routing und VLAN, weil das Grundsätzliche alles schon steht...
Dann sind sie Winblows Supporter oder SAP Programmierer oder wie ?? Ein Netzwerker der ein Netz mit 1000 Ports und mehr betreuen muss sieht sowas täglich.Ich habe mir dazu sowieso überlegt, das Netz in VLANs als Ich habe mir dazu sowieso überlegt, das Netz in VLANs als 172.16.0.0/24, 172.16.1.0/24 usw aufzuteilen.aufzuteilen.
Eine weise Ideee aber besser im 2ten Byte nicht wieder gerade das erste Netz nehmen was jeder macht. Nimm lieber 172.26.0.0/24, 172.26.1.0/24 usw.Was ändert das aber nun für mich bewusst ob ich die 192er Netze oder die 172er Netze nutze?
Generell völlig Latte und Kosmetik aber wenn du mit VPNs (Homeworker, Cheffe von zuhause, Standortkopplung usw.) arbeitest nicht mehr. Dann sind IP Adresskonflikte vorprogrammiert.Die Netgear lassen sich leicht stacken - einer geht dann in den Standby
Aber doch wohl hoffentlich die Ports dort nicht ?? 2 Minuten downtime ist Schrott...aber normal für Netgear.Bei Hot Standby oder Storage Protokollen im Rechenzentrum sind 2 Minuten der Todesstoß. Da darfst du keine Protokolle wie NFS, iSCSI, SIP, RTP usw. drüber laufen lassen um sicher zu gehen. Oder...
musst mindestens mit LACP Trunks für Redundanz sorgen für so einen Fall.
Was spricht genau gegen DHCP am L3 Core?
Meist kann man einen externen DHCP Server redundant auslegen. das ist bei Switchhardware nicht möglich. Auch haben Switches ein erheblich eingeschränktes Option Set bei DHCP. Letztlich das Management ist einfacher da zentraler. Aber wie immer Geschmackssache letztlich.Genügt es für die FW ein VLAN anzulegen mit z. B. 172.16.0.0/28 oder /30?
Ja, Das ist der richtige Weg.Wie sieht es dann mit dem Windows DNS Server/Domaincontroller aus?
Kommen ja dann ins Server VLAN. Gateway auf die Switch IP im VLAN umstellen..fertisch. DNS musst du natürlich an die neuen IPs anpassen.Wenn du mit DHCP und dynmaischen Client DNS arbeitest dann fällt die DHCP Option Switch aus. Klar, denn das geht nur in Verbindung mit DHCP und DNS auf einem Server.
Wie sieht das dann später mit den VLANs aus, sodass dann natürlich auch die Namensauflösung weiterhin klappt?
Alle Clients bekommen dann immer den lokalen DNS Server bzw. IP im Server Segment per DHCP und gut iss.In welches VLAN sollten dann die Switche selbst um auf die Konfig zugreifen zu können
Das ist eine sehr gute Frage... Letztlich hängt die von deinem Sicherheitsprofil ab.Normal separiert man das in ein Management VLAN in dem alle Infrastruktur Komponenten drinstecken. Switches, ILO Boards, Sensoren usw. und trennt das von den Produktiv VLANs bzw. mit einer ACL die dann nur den Admins und ihrer IP Range Zugang erlaubt und damit verhindert das allen Usern der Konfig Zugang zu Füßen liegt.
Ist das für dich nicht so das Thema belässt du es in einem Produktiv VLAN deiner Wahl. Auch hier individuelle Ermessenssache.
Sollten Drucker auch in ein eingenes VLAN?
Bei 3 Druckern nein...macht kein Sinn. Bei 300 schon. Auch da ist die Grenze Ermessenssache.Richtig !
Ausnahme sollte hier das Gäste Netz und Gäste WLAN sein ! Da vergibst du KEINE IP Adresse auf der Infrastruktur sondern terminierst dieses VLAN mit einem tagged Link oder einem separaten Kabel auf der FW und lässt die den Traffic sichern. ACLs auf den Switsches sind nicht wirklich gästesicher Außerdem hat man auf den Firewalls in der Regel ein Captive Portal für Gäste mit Einmalpasswörtern:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Wie würdest du am Besten vorgehen, um das bestehende Class C Netz zu ändern bzw in VLANs zu splitten
Das ist ganz einfach....Du erzeugst ein VLAN 99 mit Namen "Altnetz". Das flanschst du an die neue Infrastruktur an auf dem schon alle VLANs, DHCP usw. eingerichtet sind.
Dann nimmst du dir Bereich für Bereich vor und steckst die Geräte Step by Step um.
So kannst du sanft migrieren und wenn mal was schiefgeht kannst du schnell wieder zurückstecken und den Fehler suchen.
Das ist sinnvoller alls alles auf einmal zu machen.
Dann sind sie Winblows Supporter oder SAP Programmierer oder wie ?? Ein Netzwerker der ein Netz mit 1000 Ports und mehr betreuen muss sieht sowas täglich.
Habe einen Freund, der arbeitet in der IT einer Firma mit ca. 100 Servern. Die haben ein Großes 172.17.0.0/16er Netz - das ist alles versammelt...Aber doch wohl hoffentlich die Ports dort nicht ?? 2 Minuten downtime ist Schrott...aber normal für Netgear.
Netgear unterstützt NSF (Nonstop Forwarding). Habe das ganze eingerichtet und so verliere ich 1-2 pings, wenn ein Core ausfällt. So wie es scheint können die Netgear Full Stacking. Konfiguration über eine IP und auch ordentliches failover....Ich finde die Konfig, was VLANs etc betrifft, etwas gewöhnungsbedürftig aber man kommt rein. Preis-Leistung ist auf jeden Fall meiner Meinung nach Top. Danke an @108012 an dieser Stelle für den Tipp.Alle Clients bekommen dann immer den lokalen DNS Server bzw. IP im Server Segment per DHCP und gut iss.
Das heißt ein Client im VLAN200 hat z. B. die 172.36.2.100 GW 172.36.2.254 und bekommt aus VLAN100 die DNS vom ComainController 172.36.1.1?Ich habe mir eine Teststellung aufgebaut. Zugriff im selben Switch, über die Trunk Leitung zum zweiten Switch und auch als Stack hat alles geklappt. Alle Netze konnten sich auch untereinander erreichen. Durch ACLs habe ich dann einzelne Netze isoliert - auch das hat geklappt. Über die Gateway Adresse habe ich von jedem VLAN den Layer 3 "Core" Switch erreicht. Lässt man das so oder kann das noch unterbunden werden?
terminierst dieses VLAN mit einem tagged Link oder einem separaten Kabel auf der FW und lässt die den Traffic sichern
Auf den Netgears lässt sich ein Private VLAN einrichten, dass dann automatisch isoliert wird. Das kann ich mir jetzt nicht vorstellen, wie dann die Firewall den Traffic des einen VLAN sichern kann. Lege ich eine statische Route auf dem L3 Switch an, die Traffic ins Internet über die Firewall routet? Bei den anderen VLANs muss ich doch auch eine statische Route ins FW-VLAN anlegen, damit diese ins Internet kommen, oder? Und eine Route, damit das Paket wieder zurück findet, oder?Das einzige Problem, was ich nocht habe ist der DHCP Server. Das Netgear Manual hat mir da nicht viel geholfen. Muss ich DHCP Relay verwenden? Angenommen mein DHCP steht im Server VLAN (172.16.1.0), dann kann dieser ja DHCP für alle VLANs sein, die Zugriff auf das Server VLAN haben. Muss der Port, auf dem der Server hängt dann tagged sein, sodass dieser weiß woher das Paket kommt oder gibt es einen anderen/einfachere Lösung? Das Gäste oder auch andere VLAN kann ich ja dann vom L3 Switch versorgen lassen.
Ich habe den DHCP am Core aktiviert und eingerichtet und auch PCs an den angeschlossenen Access Switch haben in Ihrem VLAN eine IP bekommen. An den Access Switchen musste ich keinen DHCP Relay aktivieren.
mit ca. 100 Servern. Die haben ein Großes 172.17.0.0/16er Netz - das ist alles versammelt...
Oha, kein besonders intelligender IP Address Plan! Und das rennt noch alles fehlerlos? Da hat aber der Netzwerker seine Hausaufgaben nicht gemacht oder die haben keinen Netzwerker und nur MS Leute...aber egal. Sowas ist ein NoGo und muss man wohl nicht weiter kommentieren.Das heißt ein Client im VLAN200 hat z. B. die 172.36.2.100 GW 172.36.2.254 und bekommt aus VLAN100 die DNS vom ComainController 172.36.1.1?
Ja, richtig.Lässt man das so oder kann das noch unterbunden werden?
Das kommt drauf an was du für eine Sicherheitspolicy fährst. Du kannst wie gesagt das Management isolieren..ist letztlich sicherer. Oder gute Usernamen und Passwörter auf den Switches einrichten Kann man ohne eure Security Anforderungen zu kennen nicht final beantworten.
Auf den Netgears lässt sich ein Private VLAN einrichten, dass dann automatisch isoliert wird. Das kann ich mir jetzt nicht vorstellen
Das ist ganz einfach:In so einem VLAN werden die Broadcast auf den einzelnen L2 Ports unterdrückt die zu dem VLAN gehören. Z.B. ARP was zwingend nötig ist für einen IP Sessionaufbau.
Damit ist dann eine Any zu Any Kommunikation direkt unterbunden. Ist also quasi sowas wie ein isolated VLAN.
Das macht man wenn man will das sich Endgeräte an den Ports NICHT sehen sehen sollen und miteinander kommunizieren sollen. Z.B. nur um zwangsweise einen Server etc zu erreichen.
Eigentlich kein Hexenwerk.
Lege ich eine statische Route auf dem L3 Switch an, die Traffic ins Internet über die Firewall routet?
Ja ganz genau !Eine statische Default Route ala ip route 0.0.0.0 0.0.0.0 <ip_adresse_firewall>
Kannst natürlich auch dynamisch routen mit RIPv2 oder OSPF !
Und eine Route, damit das Paket wieder zurück findet, oder?
Jau, ganz genau !Diese Route kommt aber auf die Firewall
Muss ich DHCP Relay verwenden?
Einzig nur wenn du einen zentralen DHCP Server z.B. Microsoft bei dir im Server VLAN betreibst. Dann musst du mit der Relay Fnktion die IP des Servers angeben damit alle DHCP Requests durch den L3 Switch an den Server geforwardet werden.DHCP ust UDP Broadcast das sonst immer im lokalen IP Segment verbleibt und von Routern NICHT geforwardet wird. TCP/IP Basics....
Wenn dein Switch DHCP Server speilt brauchst du logischerweise KEIN Relay/Forwarder zu definieren !
Der Server hängt natürlich NICHT mit einem Bein in dem VLAN. Bei einer Relay Fiunktion wäre das Quatsch !
Genau das kompensiert ja die Relay Funktion !!!
Hier ist das recht gut erklärt...bitte lesen !
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configurat ...
An den Access Switchen musste ich keinen DHCP Relay aktivieren.
Logisch, denn die machen ja nur L2 !Du kannst wie gesagt das Management isolieren..ist letztlich sicherer
Wie unterbinde ich dann den Zugriff auf das WebGUI über das Standardgateway? Jedes VLAN bekommt ja sein Gateway und über das komme ich auf das WebGUI - auch wenn ich das Management in ein eigenes VLAN packe?Angenommen ich hätte eine FritzBox als Router. Diese steht im VLAN99 172.36.99.0/30 mit IP 172.36.99.1. Der L3 Switch hat in dem VLAN die 172.36.99.2. Muss ich was beachten, wenn ich den Router mit je einer Leitung an jeweils einen gestacken Core hänge? Der L3 Core kennt ja alle VLANs, so muss ich nur eine default Route auf die IP 172.36.99.1 erstellen. Am Router dann wieder zurück auf die 172.36.99.2?
Ich würde den DHCP Server, der im Server VLAN ist für alle VLANs nutzen, die auf dieses Server VLAN Zugriff haben. Isolierte VLANs sollen Ihre IPs über den DHCP des Core bekommen. Macht es Sinn hier dann die 8.8.8.8 als Google DNS zu nutzen? Der DomainController als DNS ist ja nicht erreichbar...
Den DHCP Relay muss ich dann nur am Core Switch einrichten? Wann würde ich dann den L2 DHCP Relay benötigen (auch auf den Access Switchen)?
Einfach ausgedrückt schick ein Client einen DHCP Request, der L3 Core leitet diesen an den DHCP Server im Server VLAN. Woher weiß dann der DHCP auf dem Windows Server aus welchem Pool er die IP Adresse nehmen soll und wohin die Reise geht? Der Server hängt dann ja auch nur an einem untagged Port.
Muss der DNS Server am DC umkonfiguriert werden? Die Clients sind ja in neuen IP Ranges?
Sollten Drucker auch in ein eingenes VLAN?
Bei 3 Druckern nein...macht kein Sinn. Bei 300 schon. Auch da ist die Grenze Ermessenssache.Es sind ca. 18 Drucker im Einsatz. Die Drucker haben gerade IPs "passend" zu den jeweiligen PCs, die in dem Bereich liegen. Ich könnte nun die Drucker in das VLAN zu den Abteilungen packen oder in ein eigenes VLAN. IPs von den Drucker muss ich ja sowieso ändern, damit diese ins VLAN passen, dann auch am Server und die Drucker am Client ggf. neu verbinden. Richtig?
Ich trenne nun die VLANs 100 und 200 über ACLs, sodass die Geräte nich untereinander kommunizieren können. Nun habe ich einen zentralen Printserver im Server VLAN, der Drucker aus allen VLANs verwaltet. VLAN100 will auf Drucker in VLAN200 drucken. Mit dem zentralen Druckerserver sollte das ja funktionieren, da die Druckaufträge von den Clients zum Server gehen und der gibt Sie an die Drucker weiter, weil er ja die IPs ansprechen kann, korrekt?
Wie unterbinde ich dann den Zugriff auf das WebGUI über das Standardgateway?
Mit einer HTTP Accesslitse oder einer IP Accessliste am L3 VLAN Interface. Das ist recht einfach und kann jeder Websmart Switch.Der L3 Switch hat in dem VLAN die 172.36.99.2. Muss ich was beachten, wenn ich den Router mit je einer Leitung an jeweils einen gestacken Core hänge?
Ja !Hier ist es sehr wesentlich davon abhängig wie die FritzBox bzw. deren kleiner onboard 4 Port LAN Switch für deren LAN Port mit Spanning Tree umgehen kann.
Du hast ja Spanning Tree (i.d.R. RSTP) aktiv am Core um Loops von Port zu Port zu verhindern. Das ist ein Muss im Setup.
Jetzt gibt es 2 Möglichkeiten:
- Die FB schiebt die RSTP BPDU Pakete einfach nur durch, dann verhalten sich die 2 Links so wie ein Kurzschluss Kabel was du zw. den beisen Switchports steckst.
- Die FritzBox blockt RSTP BPDU Pakete. Dann hast du ein Problem, denn dann sehen die beiden Switchports am Core sich STP seitig nicht und verbleiben im Forwarding Mode was dann in einem Loop resultiert der dir dein gesamtes Netzwerk runterreisst.
Hier erkennt man schon wieder die fatelen Designfehler die du bzw. deine Verantwortlichen machen:
Eine FritzBox ist ein billiger Plastik Consumer Router der in einem Umfeld wie dem deinem nicht das geringste zu suchen hat !!
Hier sollte IMMER eine Router zum Einsatz kommen der auf seinem embedded Port einen LACP Link auf deinen Core supportet ! Die FB kann das logischerweise nicht. Über LACP hast du aktive Nutzung beider Uplinks mit Load Sharing PLUS gleichzeitigem Link Failover.
Single Point of Failure ist hier dann aber der Router selber. Ist der tot ist auch dein Internet tot, da nutzen dann auch 2 redundante Lionks herzlich wenig !
Hier helfen 2 Provider Router die man mit VRRP clustert und an den Core anbindet. So hat man Hardware und Provider Backup.
Ich würde den DHCP Server, der im Server VLAN ist für alle VLANs nutzen, die auf dieses Server VLAN Zugriff haben
Das macht Sinn !Macht es Sinn hier dann die 8.8.8.8 als Google DNS zu nutzen?
Niemals wenn dir deine Privatsphäre was wert ist ! Weis ja mittlerweile auch jeder Dummie das sie dann von dir ein Profil erstellen.Außerdem willst du vermutlich nicht deine DNS Requests um die halbe Welt schicken was Antwortszeiten drastisch vergrössert. Von Security jetzt mal gar nicht geredet.
Hier nimmt man logischerweise immer die DNS seines lokalen Providers !
Den DHCP Relay muss ich dann nur am Core Switch einrichten?
Ja, absolut richtig ! Das macht man nur an den L3 Interfaces und die sind bei dir im Core.Woher weiß dann der DHCP auf dem Windows Server aus welchem Pool er die IP Adresse nehmen soll
Das ist ganz einfach. Die Relay Funktion auf dem Switch ersetzt die Absender IP des Clients mit der L3 Segment IP des Switches. Muss er auch denn die Client Absender IP ist ja logischerwesie 0.0.0.0 da der Client ja noch gar keine IP hat. Anhand der Absender IP die dann dem VLAN Segment entspricht erkennt der DHCP Server dann seinen Pool und gibt die korrekte IP raus. Die Relay funktion forwardet den Reply dann wieder an die gecachte Mac des Clients.
Klassisches DHCP Relay wie es schon seit Jahrhuderten so in Netzwerken rennt
Muss der DNS Server am DC umkonfiguriert werden?
Umkonfiguriert nicht aber du musst ihm natürlich die neuen IP Netze beibringen. Also du musst etwas dazukonfigurieren.Ich könnte nun die Drucker in das VLAN zu den Abteilungen packen
Das macht m.E. am meisten Sinn bei der Anzahl. Also die Drucker in den VLANs zu belassen wo auch die Masse der Druckeruser ist.Ich trenne nun die VLANs 100 und 200 über ACLs, sodass die Geräte nich untereinander kommunizieren können.
Genau richtig !und der gibt Sie an die Drucker weiter, weil er ja die IPs ansprechen kann, korrekt?
Ja das ist so korrekt.Aber du kannst in der ACL ja auch immer Ausnahmen für einzelnen Hosts und Anwendungen definieren die trotzdem rüberdürfen oder müssen. Auch das ist ja mit ACL Finetuning problemlos möglich.
Hier erkennt man schon wieder die fatelen Designfehler die du bzw. deine Verantwortlichen machen:
Eine FritzBox ist ein billiger Plastik Consumer Router der in einem Umfeld wie dem deinem nicht das geringste zu suchen hat !!
Das mit der FritzBox war nur ein Beispiel, um die Einfachheit der Routen ins Internet darzustellen - wenn auch ein dummes Beispiel. Ich habe vor ca 1 Jahr den alten Router gekickt und zumindest eine Securepoint RC300 durchsetzen können.Eine FritzBox ist ein billiger Plastik Consumer Router der in einem Umfeld wie dem deinem nicht das geringste zu suchen hat !!
Das macht m.E. am meisten Sinn bei der Anzahl. Also die Drucker in den VLANs zu belassen wo auch die Masse der Druckeruser ist.
Wenn die Drucker am Druckserver verbunden sind und die Clients Aufträge an den Server senden, der ja alle Drucker kennt bzw. Zugriff auf alle hat, kann ich ja auch VLAN übergreifend drucken.Nun fühle ich mich im VLAN Thema wesentlich sicherer und alle Teststellungen haben bis dato funktioniert
Jetzt gehts ans erste richtige Live-System, in dem Netz gibt es noch viel auszubauen - für mich eine schöne Baustelle, wo ich was lernen kann.Vielen Dank für deine Hilfe und deine kritischen Kommentare, @aqui - dann bin ich mal guter Dinge, dass alles klappt
kann ich ja auch VLAN übergreifend drucken.
Ja natürlich, das ist richtig !Nun fühle ich mich im VLAN Thema wesentlich sicherer und alle Teststellungen haben bis dato funktioniert
Glückwunsch ! Bestätigt das du alles richtig gemacht hast. (Bis auf die Switches natürlich 
!!)für mich eine schöne Baustelle, wo ich was lernen kann.
In der Tat ! Und das KnowHow kann dir keiner mehr nehmen !
@aqui
Die Umstellung auf die neue Hardware ist soweit abgeschlossen - alle Switche sind verbunden (LAG mit LACP), VLAN Routing funktioniert, VoIP ist priorisiert, auch das Failover der Netgear Switche funktioniert sehr gut - ich bin mit den Switchen sehr zufrieden. Ok, die Weboberfläche ist in der Konfiguration komplizierter als andere Hersteller, aber wenn man sich zurecht findet funktionieren die Teile super.
Im nächsten Schritt trenne ich nun die einzelnen VLANs über ACLs und dann wäre auch das Thema geschafft, nun habe ich aber noch zwei Fragen:
1) Portforwarding: Der Router sitzt ja aktuell in einem separatem VLAN an einem untagged Port am Core. Wie realisiere ich nun ein Portforwarding auf einen Server? Ich hab im Netz ein paar Beiträge gefunden, aber die haben mich nicht wirklich weiter gebracht. Muss ich den Port an den Netgear-Core weiter leiten und der routet ihn dann ins entsprechende VLAN? Oder muss ich dem Router die VLANs (statische Routen) beibringen, sodass er in andere Netze zugreifen kann? Hätte ich dann nicht so wieder eine Sicherheitslücke, wenn der Router aus dem VLAN raus kommunizieren kann?
2) Wir nutzen einen separaten DSL Anschluss mit einer festen IP Adresse, über den bestimmte Rechner auf einen Server zugreifen müssen (ist so beschlossen worden, dass der Zugriff auf den externen Server über einen separaten DSL Zugang erfolgt). Bisher war am Windows-PC eine statische Route eingerichtet, sodass der PC auf die IP-Adresse des Servers über den separaten DSL Router geht - natürlich sehr Aufwendig Routen am PC manuell zu setzen.
Wie könnte ich das mit den VLANs am besten realisieren? Den separaten DSL Router auch wieder in ein extra VLAN und am Core dann policy based routing nutzen, um den Zugriff auf den externen Server über die separate DSL Leitung zu ermöglichen? Per Default würden ja alle Anfragen über die Default Route auf den "normalen Internetrouter" nach Außen gehen.
Die Umstellung auf die neue Hardware ist soweit abgeschlossen - alle Switche sind verbunden (LAG mit LACP), VLAN Routing funktioniert, VoIP ist priorisiert, auch das Failover der Netgear Switche funktioniert sehr gut - ich bin mit den Switchen sehr zufrieden. Ok, die Weboberfläche ist in der Konfiguration komplizierter als andere Hersteller, aber wenn man sich zurecht findet funktionieren die Teile super.
Im nächsten Schritt trenne ich nun die einzelnen VLANs über ACLs und dann wäre auch das Thema geschafft, nun habe ich aber noch zwei Fragen:
1) Portforwarding: Der Router sitzt ja aktuell in einem separatem VLAN an einem untagged Port am Core. Wie realisiere ich nun ein Portforwarding auf einen Server? Ich hab im Netz ein paar Beiträge gefunden, aber die haben mich nicht wirklich weiter gebracht. Muss ich den Port an den Netgear-Core weiter leiten und der routet ihn dann ins entsprechende VLAN? Oder muss ich dem Router die VLANs (statische Routen) beibringen, sodass er in andere Netze zugreifen kann? Hätte ich dann nicht so wieder eine Sicherheitslücke, wenn der Router aus dem VLAN raus kommunizieren kann?
2) Wir nutzen einen separaten DSL Anschluss mit einer festen IP Adresse, über den bestimmte Rechner auf einen Server zugreifen müssen (ist so beschlossen worden, dass der Zugriff auf den externen Server über einen separaten DSL Zugang erfolgt). Bisher war am Windows-PC eine statische Route eingerichtet, sodass der PC auf die IP-Adresse des Servers über den separaten DSL Router geht - natürlich sehr Aufwendig Routen am PC manuell zu setzen.
Wie könnte ich das mit den VLANs am besten realisieren? Den separaten DSL Router auch wieder in ein extra VLAN und am Core dann policy based routing nutzen, um den Zugriff auf den externen Server über die separate DSL Leitung zu ermöglichen? Per Default würden ja alle Anfragen über die Default Route auf den "normalen Internetrouter" nach Außen gehen.
Frage 1:
Nein, es reicht wenn du die Ziel IP des Systems angibst und das Paket an den L3 Switch forwardest. Der liest ja dann die richtige Ziel IP und forwardet das dann an das entsprechende Endgerät in dem VLAN.
Wenn du dem Router per .1q in alle VLANs hängst, dann wären deine L3 Switches ja vollkommen sinnfrei. Das wäre also ein Holzweg.
Frage2.
Die Lösung ist natürlich kinderleicht. Die zentrale Routing Instanz ist ja dein L3 Switch (Core) an dem richtest du ganz einfach eine statische Route auf das Zielnetz ein via 2tem DSL Anschluss als next Hop und fertig ist der Lack. Die Default Route zeigt auf den ersten DSL Anschluss.
Policy Routing ist dafür nicht erforderlich.
Es reicht auch wenn du beide DSL Router in das gleiche "Internet VLAN" packst. Z.B. 192.168.99.1 und .99.2
Default Route L3 Switch dann:
ip route 0.0.0.0 0.0.0.0 192.168.99.1
und die extra L3 Switch Route auf den Server dann via 2tem Router:
ip route host x.y.z.a 192.168.99.2
Eigentlich ganz einfach...!
Nein, es reicht wenn du die Ziel IP des Systems angibst und das Paket an den L3 Switch forwardest. Der liest ja dann die richtige Ziel IP und forwardet das dann an das entsprechende Endgerät in dem VLAN.
Wenn du dem Router per .1q in alle VLANs hängst, dann wären deine L3 Switches ja vollkommen sinnfrei. Das wäre also ein Holzweg.
Frage2.
Die Lösung ist natürlich kinderleicht. Die zentrale Routing Instanz ist ja dein L3 Switch (Core) an dem richtest du ganz einfach eine statische Route auf das Zielnetz ein via 2tem DSL Anschluss als next Hop und fertig ist der Lack. Die Default Route zeigt auf den ersten DSL Anschluss.
Policy Routing ist dafür nicht erforderlich.
Es reicht auch wenn du beide DSL Router in das gleiche "Internet VLAN" packst. Z.B. 192.168.99.1 und .99.2
Default Route L3 Switch dann:
ip route 0.0.0.0 0.0.0.0 192.168.99.1
und die extra L3 Switch Route auf den Server dann via 2tem Router:
ip route host x.y.z.a 192.168.99.2
Eigentlich ganz einfach...!
Vielen Dank @aqui
Die Route hab ich verstanden. Wie richte ich nun ein, dass nur der Webserver im Netz von 10 Computern aus den VLANs über den separaten DSL Anschluss erreicht werden soll, der "normale" Internetverkehr soll aber über den ersten DSL Anschluss? Der Core Switch müsste ja filtern Traffic zum Webserver über DSL2, sonstiger Traffic über DSL1.
Das Portforwarding und auch DHCP Relay haben auf Anhieb funktioniert. Das Netz steht, shared internet funktioniert, DNS und Domänenanmeldung usw. funktionieren auch.
Das Netz hat jetzt folgendes Design (wie von dir oben gepostet):
Ich habe mich jetzt noch nicht getraut die VLANs über ACLs zu trennen, weil ich da noch ein paar Verständnisprobleme habe. Routing übernimmt ja der L3 Switch. Die ACLs unter Netgear werden über das GUI an die entsprechenden Ports gebunden, die im jeweiligen VLAN Member sind.
https://kb.netgear.com/30818/How-to-configure-routing-VLANs-on-a-NETGEAR ...
Das heißt, ich muss auf allen 20 Switchen die jeweiligen ACLs anlegen, die ich brauche und dann den Ports zuweisen? Warum kann ich nicht zentral am L3 Switch trennen?
Das VLAN, in dem die Firewall steck, sollte ja auch getrennt werden, richtig? Aktuell ist am DNS des DC eine Weiterleitung auf die Firewall-IP angelegt - ansonsten hat die Auflösung ewig gedauert...Sperre ich nun das Firewall VLAN auf alles außer auf den DNS (DC)?
Zitat von @aqui:
Default Route L3 Switch dann: ip route 0.0.0.0 0.0.0.0 192.168.99.1
und die extra L3 Switch Route auf den Server dann via 2tem Router: ip route host x.y.z.a 192.168.99.2
Eigentlich ganz einfach...!
Default Route L3 Switch dann: ip route 0.0.0.0 0.0.0.0 192.168.99.1
und die extra L3 Switch Route auf den Server dann via 2tem Router: ip route host x.y.z.a 192.168.99.2
Eigentlich ganz einfach...!
Die Route hab ich verstanden. Wie richte ich nun ein, dass nur der Webserver im Netz von 10 Computern aus den VLANs über den separaten DSL Anschluss erreicht werden soll, der "normale" Internetverkehr soll aber über den ersten DSL Anschluss? Der Core Switch müsste ja filtern Traffic zum Webserver über DSL2, sonstiger Traffic über DSL1.
Das Portforwarding und auch DHCP Relay haben auf Anhieb funktioniert. Das Netz steht, shared internet funktioniert, DNS und Domänenanmeldung usw. funktionieren auch.
Das Netz hat jetzt folgendes Design (wie von dir oben gepostet):
Ich habe mich jetzt noch nicht getraut die VLANs über ACLs zu trennen, weil ich da noch ein paar Verständnisprobleme habe. Routing übernimmt ja der L3 Switch. Die ACLs unter Netgear werden über das GUI an die entsprechenden Ports gebunden, die im jeweiligen VLAN Member sind.
https://kb.netgear.com/30818/How-to-configure-routing-VLANs-on-a-NETGEAR ...
Das heißt, ich muss auf allen 20 Switchen die jeweiligen ACLs anlegen, die ich brauche und dann den Ports zuweisen? Warum kann ich nicht zentral am L3 Switch trennen?
Das VLAN, in dem die Firewall steck, sollte ja auch getrennt werden, richtig? Aktuell ist am DNS des DC eine Weiterleitung auf die Firewall-IP angelegt - ansonsten hat die Auflösung ewig gedauert...Sperre ich nun das Firewall VLAN auf alles außer auf den DNS (DC)?
Wie richte ich nun ein, dass nur der Webserver im Netz von 10 Computern aus den VLANs über den separaten DSL Anschluss erreicht werden soll
Das ist kinderleicht. Du gibst dann eine Hostroute an für den Webserver (Beispiel 10.1.1.100) statt einer Netzwerkroute.Das sieht dann so aus:
ip route 10.1.1.100 255.255.255.255 192.168.99.2
Oder manche Router wollen auch folgende Nomenklatur:
ip route host 10.1.1.100 192.168.99.2
Oder theoretisch ausgedrückt:
Ziehnetz(Host): 10.1.1.100, Maske: 255.255.255.255, Gateway: 192.168.99.2
Dann wird einzig nur der Server geroutet.
Das Portforwarding und auch DHCP Relay haben auf Anhieb funktioniert.
Klasse. Und das bei gruseligen NetGear Geraffel. Respekt !! Ich habe mich jetzt noch nicht getraut die VLANs über ACLs zu trennen,
Na dann aber mal los ! Mehr als das es nicht geht kann ja nicht passieren Das heißt, ich muss auf allen 20 Switchen die jeweiligen ACLs anlegen
Nein das ist natürlich völliger Quatsch ! Zeigt leider das du immer noch nicht dein eigens Netzwerk verstanden hast Die ACLs greifen nur da wo auch geroutet wird. Sprich einzig nur da wo L3 Switches sind die auch die IP Adresse zum Forwarding brauchen.
Der Rest sind doch alles nur dumme Layer 2 Access Switches die keinerlei Ahnung haben von IP Adressen und ihre Forwarding Entscheidung rein nur auf Mac Adress Basis fällen. Das solltest du doch nun langsam mal gelernt haben in deinem Netz....
Fazit: Nur einzig auf den L3 VLAN Ports wo auch geroutet wird aktivierst du diese ACLs. Nirgendwo sonst. Und da du nur einen Core Switch hast ist das nach Adam Riese nur ein Switch. Der 2er Stack verhält sich ja wie physisch ein Switch !
Das VLAN, in dem die Firewall steck, sollte ja auch getrennt werden, richtig?
Ja, absolut richtig ! Das solltest du keinesfalls in einem Produktiv VLAN mitlaufen lassen. Damit weichst du ja deine Sicherheit wieder auf.Aktuell ist am DNS des DC eine Weiterleitung auf die Firewall-IP angelegt
Auch das ist absolut richtig. Wo willst du sonst öffentliche Internet Hostnamen auflösen ?!Sperre ich nun das Firewall VLAN auf alles außer auf den DNS (DC)?
Dann kann auch kein einziger Host aus deinem gesamten Netzwerk mehr ins Internet sondern einzig nur noch der DC. Logisch wenn du alles sperrst außer dem Server.Da werden dich deine Kollegen dann ganz sicher sofort grillen
Was sollte der tiefere Sinn sein das zu tun ? Oder hast du irgendwo einen zentralen Proxy den alle anderen zwangsweise benützen müssen um ins Internet zu kommen. Dann macht das natürlich wieder Sinn, keine Frage.
Zitat von @aqui:
Da werden dich deine Kollegen dann ganz sicher sofort grillen
Was sollte der tiefere Sinn sein das zu tun ? Oder hast du irgendwo einen zentralen Proxy den alle anderen zwangsweise benützen müssen um ins Internet zu kommen. Dann macht das natürlich wieder Sinn, keine Frage.
Sperre ich nun das Firewall VLAN auf alles außer auf den DNS (DC)?
Dann kann auch kein einziger Host aus deinem gesamten Netzwerk mehr ins Internet sondern einzig nur noch der DC. Logisch wenn du alles sperrst außer dem Server.Da werden dich deine Kollegen dann ganz sicher sofort grillen
Was sollte der tiefere Sinn sein das zu tun ? Oder hast du irgendwo einen zentralen Proxy den alle anderen zwangsweise benützen müssen um ins Internet zu kommen. Dann macht das natürlich wieder Sinn, keine Frage.
Das verstehe ich noch nicht - mein Gedanke (wenn auch falsch) war: Das Standard GW ist ja der L3 Switch, DNS der DC, außer im Gast Netz ein Public DNS. Warum muss ich Zugriff auf das Firewall VLAN haben? Routing übernimmt ja der Core und sendet die Anfragen an die Firewall. Ich verstehe dabei den Punkt Sicherheit nicht, wenn das Firewall VLAN offen ist? Da könnte doch auch die Firewall in einem anderen VLAN sein? Wo ist da mein Denkfehler? Ich dachte, dass nur der DC am die Firewall weiterleiten können muss.
Das heißt, ich muss auf allen 20 Switchen die jeweiligen ACLs anlegen, die ich brauche und dann den Ports zuweisen?
Also es gibt von Netgear eine Verwaltungssoftware (NMS300) damit kann man alle Switche komplett verwalten und steuernalso auch ACLs kopieren oder gar insgesamt auf alle VLANs oder nur einige übertragen. [ NMS300]
Damit kann man bis zu 200 Geräte voll verwalten und konfigurieren oder Konfigurationen schnell auf andere Geräte
kopieren und ein Updatemanagement ist damit auch für alle Geräte möglich.
Warum kann ich nicht zentral am L3 Switch trennen?
Weil man ein Transfernetz braucht so wie @aqui es schon vorgeschlagen hat.Gruß
Dobby
Zitat von @108012:
also auch ACLs kopieren oder gar insgesamt auf alle VLANs oder nur einige übertragen. [ NMS300]
Damit kann man bis zu 200 Geräte voll verwalten und konfigurieren oder Konfigurationen schnell auf andere Geräte
kopieren und ein Updatemanagement ist damit auch für alle Geräte möglich.
Das heißt, ich muss auf allen 20 Switchen die jeweiligen ACLs anlegen, die ich brauche und dann den Ports zuweisen?
Also es gibt von Netgear eine Verwaltungssoftware (NMS300) damit kann man alle Switche komplett verwalten und steuernalso auch ACLs kopieren oder gar insgesamt auf alle VLANs oder nur einige übertragen. [ NMS300]
Damit kann man bis zu 200 Geräte voll verwalten und konfigurieren oder Konfigurationen schnell auf andere Geräte
kopieren und ein Updatemanagement ist damit auch für alle Geräte möglich.
Die Software nutze ich zur Zeit für Backups und Firmwareupdates. Mehr habe ich damit noch nicht gemacht, weil ich die Software etwas kompliziert finde.
Der L3 macht das Routing, dann lege ich ja nur da die ACLs an. Die restlichen L2 lasse ich dann unberührt. Die ACLs kann ich am Core nur den LAGs zuweisen. Vom Core gehen ja nur die Uplinks zu den L2 Teilen.
Weil man ein Transfernetz braucht so wie @aqui es schon vorgeschlagen hat
Wo ist da mein Denkfehler zwecks Transfernetz, wenn ich die ACLs nur am Core aktiviere?
Da ist kein Denkfehler. Das kannst du so machen.
Normalerweise legt man die AVL immer INBOUND an also an den L3 Interfaces eingehend, um gleich die IP Pakete am Ursprung rauszufiltern. Klassischer Standard eben.
Normalerweise legt man die AVL immer INBOUND an also an den L3 Interfaces eingehend, um gleich die IP Pakete am Ursprung rauszufiltern. Klassischer Standard eben.
Zitat von @MasterPhil:
Das verstehe ich noch nicht - mein Gedanke (wenn auch falsch) war: Das Standard GW ist ja der L3 Switch, DNS der DC, außer im Gast Netz ein Public DNS. Warum muss ich Zugriff auf das Firewall VLAN haben? Routing übernimmt ja der Core und sendet die Anfragen an die Firewall. Ich verstehe dabei den Punkt Sicherheit nicht, wenn das Firewall VLAN offen ist? Da könnte doch auch die Firewall in einem anderen VLAN sein? Wo ist da mein Denkfehler? Ich dachte, dass nur der DC am die Firewall weiterleiten können muss.
Zitat von @aqui:
Da werden dich deine Kollegen dann ganz sicher sofort grillen
Was sollte der tiefere Sinn sein das zu tun ? Oder hast du irgendwo einen zentralen Proxy den alle anderen zwangsweise benützen müssen um ins Internet zu kommen. Dann macht das natürlich wieder Sinn, keine Frage.
Sperre ich nun das Firewall VLAN auf alles außer auf den DNS (DC)?
Dann kann auch kein einziger Host aus deinem gesamten Netzwerk mehr ins Internet sondern einzig nur noch der DC. Logisch wenn du alles sperrst außer dem Server.Da werden dich deine Kollegen dann ganz sicher sofort grillen
Was sollte der tiefere Sinn sein das zu tun ? Oder hast du irgendwo einen zentralen Proxy den alle anderen zwangsweise benützen müssen um ins Internet zu kommen. Dann macht das natürlich wieder Sinn, keine Frage.
Das verstehe ich noch nicht - mein Gedanke (wenn auch falsch) war: Das Standard GW ist ja der L3 Switch, DNS der DC, außer im Gast Netz ein Public DNS. Warum muss ich Zugriff auf das Firewall VLAN haben? Routing übernimmt ja der Core und sendet die Anfragen an die Firewall. Ich verstehe dabei den Punkt Sicherheit nicht, wenn das Firewall VLAN offen ist? Da könnte doch auch die Firewall in einem anderen VLAN sein? Wo ist da mein Denkfehler? Ich dachte, dass nur der DC am die Firewall weiterleiten können muss.
Kannst du mir diese Frage noch mit dem Firewall VLAN beantworten @aqui?
Warum muss ich Zugriff auf das Firewall VLAN haben?
Das musst du in der Tat keineswegs ! Das ist nur ein Transportnetz, da hast du recht.Sorry, ich hatte die Frage missverstanden und mit dem Gastnetz verwechselt....
Du hast natürlich Recht !
Du musst in den ACLs nur die IP Adressen bzw. Netze passieren lassen die auch Internet Zugang haben sollen.
Sorry für die Verwirrung.
Danke - bedeutet für mich, dass ich nur den DC passieren lassen muss, weil auf dessen DNS ja eine Weiterleitung zur Firewall im Firewall VPN eingerichtet ist? In VLANs, die nicht mit dem DC kommunizieren sollen, wird ein Telekom DNS verteilt...
Ich versuche dann die Tage mal die ACLs auf dem L3 Core inbound anzulegen (die muss ich dann den LAGs zuweisen? und auch den 2-3 Geräten, die noch am Core hängen: Router, TK Anlage...?)
Nun möchte ich u. a. noch STP und DHCP Snooping aktivieren, um auch dahingehend Sicherheit zu haben.
Bei der VoIP Telefonie gibt es zzt immer wieder fehlende Pakete, also Silben / Wörter fehlen bei der Kommunikation. Nun habe ich mit Wireshark einen Telefon Port gemirrored und mir ist aufgefallen, dass ziemlich viel STP Pakete unterwegs sind (BDPUs?) Das stört anscheinend die VoIP-Pakete (QoS ist aber aktiviert). In den STP Statistiken konnte ich nun auf den Ports, an denen Telefone angeschlossen sind, sehr viele gesendete RSTP BPDUs Pakete sehen - ich vermute, dass der integrierte Switch der Telefone diese Pakete sendet. BPDU Guard / Filter ist an den Access Switchen nicht verfügbar, nur am Core Switch. Genrell ist auf allen Switchen (Core und Access) STP im Modus RSTP aktiviert. Auf den Access Switchen stehen die Ports, an denen Telefone hängen auf Designated und der Status auf Forwarding. Wenn ich die Ports deaktiviere, auf denen VoIP Telefone hängen, kann ich mit Wireshark natürlich keine Pakete mehr lesen. Dann scheint auch die VoIP Telefonie ohne fehlende / verzögerte Pakete zu klappen.
Ich verstehe bei STP noch nicht, wo ich was einstellen muss - mit "nur aktivieren" scheint es nicht getan zu sein.
Was muss ich nun einstellen, damit STP - auch in den VLANs - sauber funktioniert? Generell können die Access Switche STP/RSTP/MSTP und CST (der Core zusätzlich PVST). CST funktioniert anscheinend mit VLANs (was ich so gelesen habe). Muss ich einfach STP auf den Ports deaktivieren, auf denen die VoIP-Telefone hängen? Was muss ich generell für sauber funktionierendes STP einstellen? Loop Protection kann auch nur der Core - nicht aber die Access Switche.
Die Topologie hab ich ja oben gepostet (auf jedem Switch ist ein LAG eingerichtet - ebenfalls am Core, damit jeder Access Switch mit einem Bein auf jedem Core hängt) Nennt man diese Architektur nicht Leaf Spine?
DHCP Snooping - muss ich das einfach nur auf allen Switchen (Core und Access) aktivieren und den Port auf Trust Mode stellen, an dem der DHCP hängt (der DC)?
Ich versuche dann die Tage mal die ACLs auf dem L3 Core inbound anzulegen (die muss ich dann den LAGs zuweisen? und auch den 2-3 Geräten, die noch am Core hängen: Router, TK Anlage...?)
Nun möchte ich u. a. noch STP und DHCP Snooping aktivieren, um auch dahingehend Sicherheit zu haben.
Bei der VoIP Telefonie gibt es zzt immer wieder fehlende Pakete, also Silben / Wörter fehlen bei der Kommunikation. Nun habe ich mit Wireshark einen Telefon Port gemirrored und mir ist aufgefallen, dass ziemlich viel STP Pakete unterwegs sind (BDPUs?) Das stört anscheinend die VoIP-Pakete (QoS ist aber aktiviert). In den STP Statistiken konnte ich nun auf den Ports, an denen Telefone angeschlossen sind, sehr viele gesendete RSTP BPDUs Pakete sehen - ich vermute, dass der integrierte Switch der Telefone diese Pakete sendet. BPDU Guard / Filter ist an den Access Switchen nicht verfügbar, nur am Core Switch. Genrell ist auf allen Switchen (Core und Access) STP im Modus RSTP aktiviert. Auf den Access Switchen stehen die Ports, an denen Telefone hängen auf Designated und der Status auf Forwarding. Wenn ich die Ports deaktiviere, auf denen VoIP Telefone hängen, kann ich mit Wireshark natürlich keine Pakete mehr lesen. Dann scheint auch die VoIP Telefonie ohne fehlende / verzögerte Pakete zu klappen.
Ich verstehe bei STP noch nicht, wo ich was einstellen muss - mit "nur aktivieren" scheint es nicht getan zu sein.
Was muss ich nun einstellen, damit STP - auch in den VLANs - sauber funktioniert? Generell können die Access Switche STP/RSTP/MSTP und CST (der Core zusätzlich PVST). CST funktioniert anscheinend mit VLANs (was ich so gelesen habe). Muss ich einfach STP auf den Ports deaktivieren, auf denen die VoIP-Telefone hängen? Was muss ich generell für sauber funktionierendes STP einstellen? Loop Protection kann auch nur der Core - nicht aber die Access Switche.
DHCP Snooping - muss ich das einfach nur auf allen Switchen (Core und Access) aktivieren und den Port auf Trust Mode stellen, an dem der DHCP hängt (der DC)?
ass ich nur den DC passieren lassen muss, weil auf dessen DNS ja eine Weiterleitung zur Firewall im Firewall VPN eingerichtet ist?
Ja, richtig. Wenn dieser das einzige Endgerät in dem Transfernetz ist, dann reicht es wenn nur der durch darf. Ist ja dann der einzige der mit dieser Absender IP ins Internet geht. Wenn es sogar nur DNS ist könntest du das sogar noch auf UDP/TCP 53 einschränken.In VLANs, die nicht mit dem DC kommunizieren sollen, wird ein Telekom DNS verteilt...
Auch das ist OK und richtig wenn die Telekom dein Provider ist.Nun möchte ich u. a. noch STP und DHCP Snooping aktivieren
Richtig und Sinnvoll, besonders Letzteres.Bei der VoIP Telefonie gibt es zzt immer wieder fehlende Pakete,
Dazu 2 Fragen:- Liegt deine Telefonie in einem separaten Voice VLAN ?? (Hoffentlich ja)
- Priorisierst du auf allen Switches den Voice Traffic ?? (Hoffentlich ja)
In der regel wird dort 802.1p benutzt wenn es eine Layer 2 Priorisierung ist oder DiffServ (DSCP) wenn die Priorisierung auf Layer 3 (IP Header) passiert.
Dieser thread hat ein paar Details dazu:
Kaufberatung - Switches mit VoIP-Priorisierung
Ganz wichtig ist hier, sofern deine Telefone DSCP machen, das du dem Switches das zwingend konfigurierst. Layer 2 Switches ignorieren den IP Header, klar, denn sie treffen ihre Forwarding Entscheidung rein auf Mac Adress Basis. Was oben drüber ist an IP ist für sie uninteressant und folglich werten sie das nicht aus.
Ein DSCP Honring oder Trust muss man explizit konfigurieren und zwar auf jedem Switch dann.
Welches QoS Verfahren deine Telefone wirklich nutzen kannst du um ganz sicher zu gehen mit dem Wireshark checken. Der sagt dir immer was genau aufs Netz geht.
QoS muss auf jedem Switch eingerichtet sein.
Wenn du das konsequent machst und den Voice Traffic in einem VLAN isolierst verschwinden auch die Aussetzer.
mir ist aufgefallen, dass ziemlich viel STP Pakete unterwegs sind
Das ist ganz normal wenn du RSTP aktiv hast. Die Sequenz von BPDU Paketen beträgt standardmäßig zwei Sekunden und das sollte man auch so lassen.Das ist normal und stört nicht.
Ich verstehe bei STP noch nicht, wo ich was einstellen muss
Verstehen wie es grundsätzlich arbeitet sollte man aber schon....https://de.wikipedia.org/wiki/Spanning_Tree_Protocol
Du musst aber recht wenig einstellen. RSTP macht viel selber.
Was zwingend ist das du eine RSTP Root Bridge vorgibst. Das muss sein um die Switch Hierarchie festzulegen. Normalerweise nimmt man hier natürlich immer den Core Switch. Das solltest du auch tun !
Zur Root Bridge wird der Core Switch wenn man die Bridge bzw. Spanning Tree Priority hochdreht. Das muss in 4096er Schritten passieren.
Wenn du also die RSTP Priority deines Core Stacks auf 4096 drehst, dann wird der automatisch Root.
Hier Beispiel Cisco L2 Switch:
Die LAGs solltest du immer als Point zu Point Links im RSTP definieren um das Failover zu beschleunigen.
Alle anderen Ports sind Edge Ports und kann man also solche festlegen.
Mehr ist definitiv nicht zu tun.
Haben deien Telefone embeddete Switches ? Also so das man z.B. einen PC am Telefon anschliessen kann und das Telefon dann an der Wanddose (um einen 2ten Port zu sparen)
Dann musst du hier aufpassen das der Switch im Telefon am RSTP Prozess teilnimmt und ihn entsprechend im Setup oder Anlagensetup wo das Telefonprofil definiert wird customized.
Hat das Telefon keinen embedded Switch entfällt das natürlich.
Was muss ich nun einstellen, damit STP - auch in den VLANs - sauber funktioniert?
Da kannst du rein gar nichts einstellen. Deine billigen NetGear Switches supporten KEIN PVSTP (Per VLAN Spanning Tree) damit können sie gar kein VLAN spezifisches STP. Solche Billigteile supporten das nicht.Die können nur Single Spanning Tree, also nur einen einzigen RSTP Prozess für ALLE VLANs. Heisst dann natürlich in der Konsequenz wenn in VLAN x ein Blocking passiert reisst das den Port für alle anderen VLANs auch mit in dem Abgrund.
Wenn du Glück hast supporten deine NetGear Gurken MSTP ?!
Damit ist dann ein per VLAN Spanning Tree möglich. MSTP wäre auch immer die bessere Wahl als ein RSTP mit Single Span. Wenn sie es können solltest du es umstellen.
Loop Protection kann auch nur der Core - nicht aber die Access Switche.
Dann nützt es dir auch rein nur am Core was !Nennt man diese Architektur nicht Leaf Spine?
Ja, kann man so sagen obwohl der Begriff eher auf große Netze bezogen ist und nicht auf sowas wie dein Mininetz aber im Grunde stimmt das so.aktivieren und den Port auf Trust Mode stellen, an dem der DHCP hängt (der DC)?
Ja, genau richtig !Wenn es sogar nur DNS ist könntest du das sogar noch auf UDP/TCP 53 einschränken.
Beim Thema ACLs bin ich mir noch sehr unsicher, was ich programmieren muss. Gerade was die Regeln angeht (inbound based on Source IPv4, based on Destination IPv4). Ich habe da das Thema ACLs noch nicht ganz verstanden. Wo kann ich mich da am Besten einlesen? Im Netz finde ich zwar viel Beispiele, aber wenn es dann ans Umsetzen geht, weiß ich nicht sicher wie.
Dazu 2 Fragen:
Liegt deine Telefonie in einem separaten Voice VLAN ?? (Hoffentlich ja)
Priorisierst du auf allen Switches den Voice Traffic ?? (Hoffentlich ja)
Liegt deine Telefonie in einem separaten Voice VLAN ?? (Hoffentlich ja)
Priorisierst du auf allen Switches den Voice Traffic ?? (Hoffentlich ja)
Ich bin glücklich, deine Fragen mit Ja beantworten zu dürfen
Wir haben mit dem Netgear Support gemeinsam die Konfig angeschaut. Es gibt eine Funktion AutoVOIP, die Protocol-based und OUI-based priorisiert. In der OUI Tabelle habe ich die ersten drei Stellen der MAC eingetragen. Die AutoVOIP Funktion ist auf allen Access Ports aktiviert, wo VoIP Telefone hängen.Generell: Wenn die Telefone kein 802.1p benutzen, kann auch die AutoVoIP Funktion nichts priorisieren. Wenn das ganze hier nach MAC Adressen geht, gehe ich davon aus, dass das also eine L2 Priorisierung ist? Wenn nun die Telefone DSCP nutzen aber die Access Switche Layer 2 sind geht dann überhaupt eine Priorisierung oder kann man das normal in TK-Anlagen mustellen?
Wie schon gesagt, ist mir der viele RSTP Verkehr aufgefallen, wenn ich einen VoIP-Telefon-Port mirrore. Laut Netgear soll ich nun mal STP auf den Access Ports mit den VoIP Telefonen deaktivieren.
Haben deien Telefone embeddete Switches ?
Ja, desshalb sollte ich lt. Netgear STP auf diesen Access Ports deaktivieren.Anbei mal ein Paket, was ich von Wireshark habe (Ist ein Sprachpaket, während eines Telefonates).
Frame 43785: 294 bytes on wire (2352 bits), 294 bytes captured (2352 bits) on interface 0
Interface id: 0 (\Device\NPF_{0E4737FE-040F-4719-9E96-8D10285ACE01})
Encapsulation type: Ethernet (1)
Arrival Time: Apr 6, 2017 11:51:04.684959000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1491472264.684959000 seconds
[Time delta from previous captured frame: 0.022412000 seconds]
[Time delta from previous displayed frame: 0.022412000 seconds]
[Time since reference or first frame: 6491.810714000 seconds]
Frame Number: 43785
Frame Length: 294 bytes (2352 bits)
Capture Length: 294 bytes (2352 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:data]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: AlcatelB_ed:15:9b (00:80:9f:ed:15:9b), Dst: AlcatelB_f3:f8:9c (00:80:9f:f3:f8:9c)
Destination: AlcatelB_f3:f8:9c (00:80:9f:f3:f8:9c)
Address: AlcatelB_f3:f8:9c (00:80:9f:f3:f8:9c)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: AlcatelB_ed:15:9b (00:80:9f:ed:15:9b)
Address: AlcatelB_ed:15:9b (00:80:9f:ed:15:9b)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 172.16.11.84, Dst: 172.16.11.250
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)
1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 280
Identification: 0x81ad (33197)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x8801 [validation disabled]
[Header checksum status: Unverified]
Source: 172.16.11.84
Destination: 172.16.11.250
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 32040, Dst Port: 32052
Source Port: 32040
Destination Port: 32052
Length: 260
Checksum: 0xae4b [unverified]
[Checksum Status: Unverified]
[Stream index: 161]
Data (252 bytes)
Data: 800845ec7db1c49e0d64328d555555d5d5d555d5d5d555d5...
[Length: 252]Wenn du Glück hast supporten deine NetGear Gurken MSTP ?!
PVST unterstützt nur der Core - MSTP können aber alle Gurken Unter CST habe ich eine Bridge Priority von 32768 (0 to 61440). Diese drehe ich dann nur am Core hoch? Ich sehe in der Statistik noch Path Cost etc. Ich lege also unter MST nur die VLANs an, setzte die Prio am Core hoch und MSTP fliegt?
Beim Thema ACLs bin ich mir noch sehr unsicher, was ich programmieren muss.
Warum ?? Als "Master" hast du doch den Durchblick Denke immer an die IP Adressen die im IP Paket stehen und WIE sich diese IP Pakete im Netzwerk bewegen.
Einfaches Beispiel:
- 2 VLANs am Switch 1 = 10.1.1.0 /24 und 2 = 10.2.2.0 /24
- Du willst das 1 ins Internet darf ab nicht auf 2
DENY Source = 10.1.1.0 --> Destination = 10.2.2.0
PERMIT Source = 10.1.1.0 --> Destination = any
Beispiel wenn du nur HTTP Traffic ins VLAN 2 erlauben willst:
PERMIT Source = 10.1.1.0 Port: any --> Destination = 10.2.2.0 Port: TCP 80
DENY Source = 10.1.1.0 --> Destination = 10.2.2.0
PERMIT Source = 10.1.1.0 --> Destination = any
usw. usw.
Die Logik dahinter ist doch kinderleicht und da gibts nicht viel zu verstehen. Du siehst auch Reihenfolge der Regeln ist hier wichtig.
Wir haben mit dem Netgear Support gemeinsam die Konfig
Oha...da sitzen bekanntermaßen die großen Netzwerk Experten Die AutoVOIP Funktion ist auf allen Access Ports aktiviert, wo VoIP Telefone hängen.
Das ist ja nur die halbe Miete !! Je nachdem welches "Auto" Protokoll der Switch verwendet (LLDP, CDP etc.) müssen es ja deine Telefone auch verstehen ?! Tun sie es nicht ist es ihnen Latte was der Switch ihne als VLAN ID sagt ist mir der viele RSTP Verkehr aufgefallen, wenn ich einen VoIP-Telefon-Port mirrore.
Das ist nicht nur an einem Voice Port so sondern sollte an ALLEN Ports so sein. Wie gesagt der 2 Sekunden Rythmus bei BPDUs ist hier vollkommen normal und sollte dich nicht beunruhigen !!Laut Netgear soll ich nun mal STP auf den Access Ports mit den VoIP Telefonen deaktivieren.
Soviel zum Thema Experten.... Ist natürlich Blödsinn, denn damit setzt du die Loop Security natürlich dort außer Kraft. Den Rat muss man wohl nicht weiter kommentieren...Sprechen die Switches innerhalb der Telefone auch eine Art von Spanning Tree oder fluten sie BPDU Pakete ?
Das Schlimmste wäre wenn sie BPDUs blocken. Das musst du rausbekommen und ggf. den Telefonhersteller dazu befragen. Oder selber messen mit dem Kabelhai um sicherzugehen.
Deine Telefone machen wie erwartet DSCP, also eine L3 Priorisierung mit ToS 46 was schonmal gut ist, denn damit ist dein Voice Traffic im Netz schon klassifiziert. Die Switches müssen nur noch handeln:
1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)
Das ist der übliche ToS Wert im Telefoniebereich mit 46 (EF).
Hier mal wieder am Beispiel eines Cisco Switches mit 4 Priority Queues und dort kannst du sehen das DSCP 46 Pakete (Voice) mit dem ToS Wert 46 in die höchste Queue wandern und so am allerhöchsten priorisiert werden:
Bei den L2 Switches musst du DSCP Honoring an den Ingress Ports aktivieren damit die den IP Header an den Telefonports lesen. Möglich aber das das schon im Default aktiv ist an den L2 Modellen. Sprich das DSCP Trusting defaultseitig aktiviert ist. (Handbuch ?!)
PVST unterstützt nur der Core
Das ist bei NetGear fast unglaublich !!! Können sonst nur Premium Switches. Da würde mich echt mal ein Screenshot interessieren ob das wirklich der Fall ist ??OK du kannst das aber dann natürlich nicht mischen. Wenn die Accessteile das nicht können bleibt nur MSTP als kleinstes gemeinsames Vielfaches.
Unter CST habe ich eine Bridge Priority von 32768
Das ist Default und was weltweit alle STP Geräte haben.Diese drehe ich dann nur am Core hoch?
Ja, ausschliesslich nur am Core auf 4096Ich sehe in der Statistik noch Path Cost etc
Nein, nicht daran rumfummeln ! Auf Default lassen. Nur die Priority.Ich lege also unter MST nur die VLANs an, setzte die Prio am Core hoch und MSTP fliegt?
Nicht ganz...Bei MSTP legst du noch Instanzen an. Jede Instanz ist eine STP Gruppe. Default ist 1 und wenn du keine Instanz angibst landen alle in 1. Das ist OK bei wenig VLANs. Bei ein paar mehr sollte man wichtigere VLANs in eine separate Instanz bringen.
Dann Prio auf dem Core setzen und gut iss.
Die Logik dahinter ist doch kinderleicht und da gibts nicht viel zu verstehen. Du siehst auch Reihenfolge der Regeln ist hier wichtig.
Bedeutet für mich: Am Core Switch hängen ja nur die Uplinks (Konfiguriert als LAGs) zu den Access Switchen. Einzige Ausnahme ist TK-Anlage und Router, die zusätzlich auf dem Core hängen. Somit muss ich die Regeln inbound den LAGs zuweisen - und ggf. noch den 1/2 Geräten, die noch am Core hängen?
Das ist ja nur die halbe Miete !! Je nachdem welches "Auto" Protokoll der Switch verwendet (LLDP, CDP etc.) müssen es ja deine Telefone auch verstehen ?! Tun sie es nicht ist es ihnen Latte was der Switch ihne als VLAN ID sagt
So sieht die Netgear-Konfig aus - einmal Protocol based Auto VoIP:
OUI based Auto VoIP:
Der Auto VoIP Status erkennt aber auf keinem Switch Voice Kanäle (Vermutlich weil die Telefone DSCP nutzen? Auto VoIP arbeitet auf Basis von 802.1p? - die Handbücher von Netgear - wie auch der Telefonsupport sind mehr als mies - sogar total mies. Wenn die Telefone DSCP nutzen, kann Netgear ja auch keine VoIP Kanäle mit Auto VoIP erkennen.
Hier gibt es noch eine Voice VLAN Configuration, wo ich einzelnen Ports anscheinend die Voice VLAN ID zuweisen kann - lt. dem Netgear Support reicht es, wenn der Admin Mode ENABLED ist (Glaube ich aber nicht). Mir konnte auch keiner aus dem Support beantworten nach welchem Schema Auto-VoIP arbeitet. Muss ich im Menüpunkt QoS die Priorisierung konfigurieren oder bekommt das Auto VoIP mit DSCP auch hin oder kann Auto VoIP nur 802.1p?
Sprechen die Switches innerhalb der Telefone auch eine Art von Spanning Tree oder fluten sie BPDU Pakete ?
Ich vermute, dass der Switch im Telefon flutet, da in der STP Statistik auf den Ports extrem viele "Transmitted BPDUs" zu sehen sind. Kann man normalerweise in den Telefonen dahingehend etwas einstellen? STP an den Ports zu deaktivieren hielt ich auch für Quatsch.
Die Switches müssen nur noch handeln:
In der QoS Konfiguration der Switche steht unter dem Punkt CoS Configuration der Global Trust Mode auf "802.1p" (Generell gibt es unter QoS die Submenus CoS und DiffServ) - wählbar wäre noch DSCP. Lassen sich die Telefonanlagen normalerweise auf 802.1p umstellen? (Wäre aber Quatsch, oder?) Der Errichter hat mir nicht mitgeteilt, welches QoS in der Anlage genutzt wird - er meinte auch, dass keine Einstellungen in der Anlage sind..........
Anbei Screenshots:
Unter den DSCP Values kann ich keine 46er Pakete finden - die finde ich unter DSCP Queue Mapping nur am Core Switch..muss ich das nur am Core zuweisen? An den L2 hab ich Global (auf allen Ports) DSCP aktiviert.
Folgendes Paket geht in unterschiedlichen Intervallen von der Telefonanlage zu allen IP-Telefonen. Das Paket wird von Wireshark als "Malformed" gekennzeichnet. Ist das ein "harmloses" Paket was irgendeinen internen Zweck hat zwischen VoIP-Telefon und Telefonanlage?
Frame 67324: 56 bytes on wire (448 bits), 56 bytes captured (448 bits) on interface 0
Interface id: 0 (\Device\NPF_{0E4737FE-040F-4719-9E96-8D10285ACE01})
Encapsulation type: Ethernet (1)
Arrival Time: Apr 6, 2017 13:56:37.705186000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1491479797.705186000 seconds
[Time delta from previous captured frame: 0.000495000 seconds]
[Time delta from previous displayed frame: 0.000495000 seconds]
[Time since reference or first frame: 14024.830941000 seconds]
Frame Number: 67324
Frame Length: 56 bytes (448 bits)
Capture Length: 56 bytes (448 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:cpfi]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: AlcatelB_ed:14:e3 (00:80:9f:ed:14:e3), Dst: AlcatelB_f3:f8:9c (00:80:9f:f3:f8:9c)
Destination: AlcatelB_f3:f8:9c (00:80:9f:f3:f8:9c)
Address: AlcatelB_f3:f8:9c (00:80:9f:f3:f8:9c)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: AlcatelB_ed:14:e3 (00:80:9f:ed:14:e3)
Address: AlcatelB_ed:14:e3 (00:80:9f:ed:14:e3)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Trailer: 00000000000000000000000000
Internet Protocol Version 4, Src: 172.16.11.47, Dst: 172.16.11.250
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)
1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 29
Identification: 0x39c5 (14789)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xd109 [validation disabled]
[Header checksum status: Unverified]
Source: 172.16.11.47
Destination: 172.16.11.250
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5001, Dst Port: 7775
Source Port: 5001
Destination Port: 7775
Length: 9
Checksum: 0x59aa [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
[Malformed Packet: CPFI]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]Die DSCP Konfiguration ist für mich natürlich neu - hab ich noch nie gemacht (wie so vieles
) Ich könnte jetzt Global statt 802.1p alles auf DSCP umstellen. Wo weise ich dann die exakte Priorisierung zu, dass die VoIP Pakete bevorzugt werden? Ich verstehe das mit den Queues nicht....NetGears AutoVoIP scheint dann wohl L2 basiert zu priorisieren - also über 802.1p?Bei den L2 Switches musst du DSCP Honoring an den Ingress Ports aktivieren
Den Punkt kann ich nirgends in den QoS Optionen finden.
Da würde mich echt mal ein Screenshot interessieren ob das wirklich der Fall ist ??
Ob du dir auch mal einen Netgear kaufen wirst? 
Ja, ausschliesslich nur am Core auf 4096
Den Wert kann ich unter STP nirgends finden (bzw. kein Prio-Feld wo ich von 0-4096 Eintragen kann). Möglicherweise muss ich erst MSTP aktivieren?
Somit muss ich die Regeln inbound den LAGs zuweisen
Nein !!Die LAGs sind ja nur Layer 2 und routen nicht !!
IP Accesslisten können doch nur greifen wo Layer 3 also IP geforwardet wird und das wird es einzig nur an den Layer 3 sprich IP Interfaces des Core Routers !!
Die Interface IP die alle Endgeräte im VLAN als Gateway IP haben.
An dem Interface greifen die ACLs !! Nirgendwo sonst.
Layer 2 Ports keinen einzig und allein nur Mac Adressen. Weist du ja selber als Netzwerker...?!
So sieht die Netgear-Konfig aus - einmal Protocol based Auto VoIP:
MMmhhh das hat nix mit DSCP zu tun. Traffic Class 6 sieht eher nach 802.1p aus also Layer 2. Da bist du im falschen Menü ! Du willst ja DSCP machen und kein L2 QoS mit .1p.Worst Case wäre wenn deine Access Gurken kein DSCP Honoring supporten
da in der STP Statistik auf den Ports extrem viele "Transmitted BPDUs" zu sehen sind.
Das sind dann aber transmitted BPDUs von deinem Switch also welche die ER selber ausgesendet hat.Wenn der Switch im Telefon auch BPDUs sendet müssten dann dort doch received BPDUs stehen am Switchport !!!
Punkt CoS Configuration der Global Trust Mode auf "802.1p"
Das ist logischerweise FALSCH !!Deine Telefone nutzen ja DSCP (DiffServ) im L3. Niemals darf der Switch also 802.1p machen Global !! Das musst du deaktivieren oder aber zwingend auf DSCP umstellen !
wählbar wäre noch DSCP.
DAS wäre dann auch RICHTIG Du hast doch oben selber den Sniffer Trace gepostet oben wo doch ganz klar DSCP klassifizierte Pakete aus den Telefonen kommen und KEINE mit .1p.
Warum dann also diese eigentlich überflüssige Frage dazu ! DSCP und gut iss !
Telefonanlagen normalerweise auf 802.1p umstellen? (Wäre aber Quatsch, oder?)
Ja richtig, völliger Quatsch. Sie macht ja schon nachweislich DSCP (Sniffer Trace) warum solltest du das denn tauschen. Das wäre sinnfrei.Der Errichter hat mir nicht mitgeteilt, welches QoS in der Anlage genutzt wird - er meinte auch, dass keine Einstellungen in der Anlage sind
Der Typ hat keinerlei Ahnung von QoS in Netzwerken. Vergiss das und ihn gleich mit. Müssig darüber jetzt noch Worte zu verlieren... Solche Aussagen sind aber von Telefonie Fritzen durchaus normal, disqualifizieren den dann aber als Fachmann sofort.
Unter den DSCP Values kann ich keine 46er Pakete finden
Sieh doch bitte mal genau hin !!! Ganz GENAU...!Oben steht doch EF und gib dann mal das binäre 101110 was dahinter steht in deinen Rechner am PC ein !!!
http://de.calcuworld.com/berechnungen/binaer-rechner/
Was kommt dabei raus ?? Taadaaaa... Erst denken dann schreiben!
Deshalb ist unten 47 ja auch 101111. Das gute alte Binärsystem.... Aber im Konfig Stress übersieht man sowas ja auch manchmal...
Das kommt in die Prio Queue 2. Solltest du besser auf 3 setzen wenn der Switch 4 Queues hat. Wenns ein guter Switch ist und er 8 Queues hat dann in Queue 6.
Folgendes Paket geht in unterschiedlichen Intervallen von der Telefonanlage zu allen IP-Telefonen
Die Frage kannst du dir mit dem Trace selber beantworten... Es ist ein UDP 7775 Pakethttp://bfy.tw/B5JO
Vermutlich eine Art Keepalive der Anlage. Aber dazu musst du mal einen SE des Herstellers Alcatel befragen.
Die IANA Zuweisung lautet:
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Ein CPFI Error (Cross Point Frame Injector) ist ein nicht standardkonformes Packet:
https://www.wireshark.org/lists/ethereal-users/200608/msg00111.html
Möglich das der Kabelhai meckert das das durch Alcatel falsch genutzt wird.
Ich könnte jetzt Global statt 802.1p alles auf DSCP umstellen.
Das wäre richtig !Wo weise ich dann die exakte Priorisierung zu, dass die VoIP Pakete bevorzugt werden?
Hast du oben doch schon als Screenshot geschickt. Tomaten auf den... ?? EF = 46 = geht in Queue 2 (wenns den aktiviert ist !)
Ich verstehe das mit den Queues nicht....
Bitte lesen und verstehen, Thema Priority Queues auf Switches:http://www.downloads.netgear.com/files/answers/QoS_on_Netgear_Switches. ...
http://blog.ipspace.net/2014/05/queuing-mechanisms-in-modern-switches.h ...
usw. es gibt diverse Infos dazu im Netz !
NetGears AutoVoIP scheint dann wohl L2 basiert zu priorisieren - also über 802.1p?
Nach den von dir geposteten Screenshots zu urteilen ja. Der Default ist auf 802.1p eingestellt.Das ist dann nutzlos für dich, da wie gesagt deine Voice Anwendung ja klar DSCP nutzt.
Der Sniffer Trace ist da absolut eindeutig.
Ob du dir auch mal einen Netgear kaufen wirst?
Der Screenshot war schon mal gut...Besser wäre er gewesen wenn du den blauen Item Reiter mal auf "PVST VLAN" geklickt hättest um die Parameter zu sehen
Wenn dort wirklich PVST konfigurierbar ist dann ist das ein klarer Pluspunkt für Netgear...keine Frage. Damit kommen die dann noch weit vor HP und dann ists ne klare Kaufempfehlung im Billigbereich
Kollege Dobby wirds freuen...
Kollege Dobby wirds freuen...
War einfach eine Lizenzfrage! PVST und PVST+ ist eben von Cisco!Gruß
Dobby
Nein ! Nicht ganz richtig Dobby !
Nur PVSTP+ wird von Cisco benutzt. "Normales" PVSTP nutzen auch andere Hersteller wie Brocade, Extreme, Juniper usw.
Normales PVSTP nutzt die Standard BPDU Mac Adresse 01:80:c2:00:00:00 und nur Cisco nutzt als BPDU Mac proprietär die 01:00:0c:cc:cc:cd !
Deswegen ist Ciscos PVSTP+ auch inkompatibel zu anderen Spanning Tree Protokollen und Standard PVSTP was dann meist in einem Netzwerk Chaos endet mischt man das ohne Nachzudenken.
Auf PVSTP+ gibt es kein Patent oder Lizenz wie es z.B. bei VTP oder EIGRP der Fall ist.
Einige Hersteller "bemerken" aber automatisch diese proprietären Cisco PVSTP+ BPDUs und "erkennen" so einen Cisco Switch automatisch an einem ihrer Ports und schalten entsprechend um in einem gemischten Design aus mehreren Herstellern.
Alle Enterprise und Fabric Switches von Brocade machen das z.B. Einige andere Hersteller können es aber auch.
Billigswitches natürlich nicht. Da Cisco kein Single Span oder Standard PVST macht, muss man dann immer auf MSTP wechseln um kompatibel zu sein.
Oder noch besser: Gleich ein modernes Switching Design ganz ohne die Geißel Spanning Tree
Nur PVSTP+ wird von Cisco benutzt. "Normales" PVSTP nutzen auch andere Hersteller wie Brocade, Extreme, Juniper usw.
Normales PVSTP nutzt die Standard BPDU Mac Adresse 01:80:c2:00:00:00 und nur Cisco nutzt als BPDU Mac proprietär die 01:00:0c:cc:cc:cd !
Deswegen ist Ciscos PVSTP+ auch inkompatibel zu anderen Spanning Tree Protokollen und Standard PVSTP was dann meist in einem Netzwerk Chaos endet mischt man das ohne Nachzudenken.
Auf PVSTP+ gibt es kein Patent oder Lizenz wie es z.B. bei VTP oder EIGRP der Fall ist.
Einige Hersteller "bemerken" aber automatisch diese proprietären Cisco PVSTP+ BPDUs und "erkennen" so einen Cisco Switch automatisch an einem ihrer Ports und schalten entsprechend um in einem gemischten Design aus mehreren Herstellern.
Alle Enterprise und Fabric Switches von Brocade machen das z.B. Einige andere Hersteller können es aber auch.
Billigswitches natürlich nicht. Da Cisco kein Single Span oder Standard PVST macht, muss man dann immer auf MSTP wechseln um kompatibel zu sein.
Oder noch besser: Gleich ein modernes Switching Design ganz ohne die Geißel Spanning Tree
Gleich ein modernes Switching Design ganz ohne die Geißel Spanning Tree
Nur mal rein Interesse halber - wie ist das gemeint? Brauche ich nicht STP und Loop Protection, damit ein Scherzkeks keine Brücken stecken kann und das Netz lahm legt?
Doch die brauchst du beide zwingend dazu um das sicher zu verhindern. Ansonsten hat ein Scherzkeks leichtes Spiel dein Netz sehr einfach in die Knie zu zwingen.
An dem Interface greifen die ACLs !! Nirgendwo sonst.
Layer 2 Ports keinen einzig und allein nur Mac Adressen. Weist du ja selber als Netzwerker...?!
Layer 2 Ports keinen einzig und allein nur Mac Adressen. Weist du ja selber als Netzwerker...?!
Ich bin bisher immer nur kleine "Dödelnetze" gewohnt mit 1 Server und 4 Clients - das beschränkt natürlich den Horizont enorm - davon möchte ich ja weg
Das mit den ACLs und den virtuellen Interfaces habe ich soweit verstanden - das Gateway jedes VLANs ist ja das virtuelle des Core. Warum muss ich dann laut Netgear die ACLs an physische Ports / LAGs binden (unter Binding Configuration?) Ich habe mir eine Anleitung auf der Netgear Seite angesehen und da wurden auch die ACLs an physische Ports gebunden. Wobei ich begriffen haben, dass das Routing über die virtuellen Gateway Interfaces geht und dann auch hier die ACLs greifen müssen - mit der Umsetzung in den Screenshots fühle ich mich dann noch unsicher:
Sieh doch bitte mal genau hin !!! Ganz GENAU...!
Danke - da war ich wohl blind und hab nicht weit genug gedacht Der Netgear Support hat mir davon abgeraten, das QoS unter dem Menüpunkt "QoS" einzustellen, weil das zu kompliziert sei. Ich solle stattdessen Auto VoIP verwenden. Nach meinem jetzigen Kenntnistand priorisiert Auto VoIP mit 802.1p und nicht über DSCP - dann nutzt mir das natürlich recht wenig....Ich kann dort auch nirgends angeben, welcher Standard verwendet werden soll...Schade dass es Support gibt, der dann tatsächlich weniger weiß, als ich selbst nach einigen (tw. dummen) Fragen und Recherchen...
Ich habe nun DSCP Global für alle Ports aktiviert - an jedem L2 und am L3:
EF habe ich auf Queue 4 umgestellt (6 sind möglich) - auch an jedem L2 und am L3:
Muss hier dann noch den Ports, wo die TK bzw. die VoIP Telefone angeschlossen sind, die Queue zugewiesen werden? Ich vermute ja - somit kann der Switch die Pakete in die richtige Queue packen? Und die Priorisierung, welche Queue zuerst den Switch verlässt regelt er "von alleine" - je nach Höhe der Queue?
Die ganzen Einstellungen habe ich im Menü QoS --> CoS eingetragen - unter DiffServ gibt es dann Classes und Policys die ich anlegen könnte. Genügen, die obigen Einstellungen, dass der Vocie Traffic "zum Fliegen" kommt? Das ganze käme dann hier zum Tragen - scheint aber auch wieder eine andere Konfigurationsweise zu sein: https://kb.netgear.com/21617/How-do-I-configure-voice-VLAN-and-prioritiz ...
Nach einem PDF von Netgear scheint es das mit den Einstellungen unter CoS gewesen zu sein - unter DiffServ kann ich dann wohl noch komplexer rumfummeln.
Hier nochmal exklusiv für dich die STP Screenshots
Der nächste Hammer vom Netgear Support: Das Einstellen der Uhrzeit ist in den Switchen total kompliziert - auch das Handbuch hilft wenig. Klar, ich muss den SNTP Server angeben aber die Zeitzone hat es in sich...da muss ich mit Offset in Min/Stunden hantieren und laut Netgear bei der Zeitumstellung (Sommer-Winter) bei allen Switchen manuell den Offset anpassen? Das kann doch nur ein Witz sein?
ch bin bisher immer nur kleine "Dödelnetze" gewohnt mit 1 Server und 4 Clients - das beschränkt natürlich den Horizont enorm - davon möchte ich ja weg
Sehr löblich !!das Gateway jedes VLANs ist ja das virtuelle des Core.
Genau so ist es ! Die Accessteile sind alle nur L2 und L3 Traffic rennt immer über den Core Switch.Ich solle stattdessen Auto VoIP verwenden. Nach meinem jetzigen Kenntnistand priorisiert Auto VoIP mit 802.1p und nicht über DSCP
Dann ist es für dich vollkommen unbrauchbar, denn du machst ja DSCP !Für 802.1p müsstest du deine gesamte Anlage und auch alle Telefone umstellen. .1p ist immer Teil von .1q also Teil eines VLAN Tags !
Das bedeutet das dann alle Telefone Tagged in einem Voice VLAN arbeiten müssen, denn ohne VLAN Tag dann keine Layer 2 Priorisierung. Warum das "einfacher" sein soll weiss wohl nur der Wind.....oder der NetGear Support.
Auch das einfach so pauschl zu sagen ohne zu erklären WIE das dann vonstatten geht ist ja kontraproduktiv.
Das "Auto Voice" benutzt ja wie gesagt irgendein Protokoll Mechanismus um diese Settings den Telefonen bekannt zu machen. Standard ist da nur LLDP. CDP ist ein quasi Standard aber ein Cisco Protokoll was nur ein kleiner Anteil Endgeräte supportet.
Angenommen es ist LLDP oder LLDP med, dann müssen zwangsläufig auch deine telefone LLDP konfiguriert haben und verstehen. Es nützt ja nichts das es dann ggf. nur eine Seite macht und die andere ignoriert es weil sie es gar nicht kann.
Insofern ist dieser Rat also totaler Unsinn wenn man nicht beide Seiten betrachtet. Zeugt von wenig Fachkwnntniss wenn man so einseitig solch einen "Rat" bekommt. Verwundert aber auch nicht weiter beim NG 1st level Support.
unter DiffServ gibt es dann Classes und Policys die ich anlegen könnte.
Lass das alles im Default. Musst du nichts verändern. Für dich ist nur CoS 46 relevant und das solltest du statt in 2 in Queue 3 stecken.Hat die NG Gurke 4 oder 8 Priority Queues ???
Sollte sie 8 haben dann Queues 6. Oder wenns gemischt ist also L2 Access hat nur 4 und der Core 8 dann setzt du es auf die 4er Switches in 3 und beim 8er in 6.
Hier nochmal exklusiv für dich die STP Screenshots
Unfassbar !!! Die NG Gurken supporten Standard PVST !Das wertet die Hardware dann wirklich auf.... Respekt. Fragt sich dann nur wie skalierbar das ist. Bei Premium Switches ist Schluss bei 30-40 VLANs. Der Break even dürfte bei NG vermutlich weit drunter liegen. Aber immerhin...sie können es !!! Kann HP sich mal ne Scheibe abschneiden
Danke fürs posten.Das Einstellen der Uhrzeit ist in den Switchen total kompliziert
Damit trüben sie dann leider wieder das positive Bild. Normal ist das in der Tat NTP Server Zeitzone, So/Wi Zeit...fertisch.Das Einstellen der Uhrzeit ist in den Switchen total kompliziert
Setze Dir doch ein kleinen internen NTP Server auf und vom dem holen sich dann die Switche und Router oder Firewallsdie genaue Zeit dann sind alle Geräte immer mit ein und der selben Zeit versorgt und das passt dann am besten.
Gruß
Dobby
Den muss er ja aber auch konfigurieren. Es ging ja primär genau um die Einrichtung von NTP auf den Switches und nicht um das NTP Prozedere als solches
@aqui
Aber ich erhoffe mir dort keine Hilfe. Finde ich nur doof. Im Netz gibt es nur die wirren Handbücher von Netgear und sonst gibt es wenig bis keinen Support...
(Sieht Screenshots oben) - da konnte mir Netgear auch nicht sagen warum ich Regeln binden muss...ich dachte ich leg dir in einer Tabelle an ähnlich wie in einer Routingtabelle...kannst du mir eine Regel anhand der obigen Screenshots erläutern?
Ich vermute, mit der Einstellung an den Ports (Zuweisung der Queue) habe ich dann ein sauberes QoS? Auch hier würde mich bei NG der Unterschied zwischen CoS und DiffServ interessieren...wie gesagt kann ich bei DiffServ nur Policys und Klassen konfigurieren...das scheint eine komplexere L3 Priorisierung zu sein.
Meinst du ich muss in der Interface Queue Configuration auf allen Switchen (wie in den Screenshots oben) die Ports der Queue 4 (EF) zuweisen - der Switch hat im übrigen sowohl im Access als auch im Core Bereich 6 Queues.
NG 1st level Support.
War der L2 Support und wurde an den L3 Support eskaliert Aber ich erhoffe mir dort keine Hilfe. Finde ich nur doof. Im Netz gibt es nur die wirren Handbücher von Netgear und sonst gibt es wenig bis keinen Support...Hat die NG Gurke 4 oder 8 Priority Queues ???
Auf allen Switchen 6 QueuesDas mit den ACLs und den virtuellen Interfaces habe ich soweit verstanden - das Gateway jedes VLANs ist ja das virtuelle des Core. Warum muss ich dann laut Netgear die ACLs an physische Ports / LAGs binden (unter Binding Configuration?) Ich habe mir eine Anleitung auf der Netgear Seite angesehen und da wurden auch die ACLs an physische Ports gebunden. Wobei ich begriffen haben, dass das Routing über die virtuellen Gateway Interfaces geht und dann auch hier die ACLs greifen müssen - mit der Umsetzung in den Screenshots fühle ich mich dann noch unsicher:
(Sieht Screenshots oben) - da konnte mir Netgear auch nicht sagen warum ich Regeln binden muss...ich dachte ich leg dir in einer Tabelle an ähnlich wie in einer Routingtabelle...kannst du mir eine Regel anhand der obigen Screenshots erläutern?
Muss hier dann noch den Ports, wo die TK bzw. die VoIP Telefone angeschlossen sind, die Queue zugewiesen werden? Ich vermute ja - somit kann der Switch die Pakete in die richtige Queue packen? Und die Priorisierung, welche Queue zuerst den Switch verlässt regelt er "von alleine" - je nach Höhe der Queue?
Ich vermute, mit der Einstellung an den Ports (Zuweisung der Queue) habe ich dann ein sauberes QoS? Auch hier würde mich bei NG der Unterschied zwischen CoS und DiffServ interessieren...wie gesagt kann ich bei DiffServ nur Policys und Klassen konfigurieren...das scheint eine komplexere L3 Priorisierung zu sein.
Aber immerhin...sie können es !!! Kann HP sich mal ne Scheibe abschneiden Danke fürs posten.
Ich finde die Netgear Switche der Serie M4300 an sich gut..bis auf die Handbücher und den Support...für Midsized Business mit keinem riesen Budget sind die Teile völlig OK. NG wirbt mit Lifetime NextBusinessDay Austausch von defekten Geräten - wir hatten bei 22 Stück 1 Montagsgerät dabei - der Paketdienst brachte am nächsten Tag das neue Teil.Meinst du ich muss in der Interface Queue Configuration auf allen Switchen (wie in den Screenshots oben) die Ports der Queue 4 (EF) zuweisen - der Switch hat im übrigen sowohl im Access als auch im Core Bereich 6 Queues.
Netz gibt es nur die wirren Handbücher von Netgear und sonst gibt es wenig bis keinen Support...
Hattest du bei einem Billigheimer was anderes erwartet. Support kostet viel Geld was die Massenhersteller sparen (müssen) damit der nächste nicht zum TP-Link Chinesen geht. Es geht immer noch ein bischen weniger....Auf allen Switchen 6 Queues
OK, dann immer in Queue 4. Die beiden obersten sollte man nicht nehmen denn die brauchen die Switches selb er für STP usw. deshalb sollte man diese nicht zusätzlich belasten.Ich vermute, mit der Einstellung an den Ports (Zuweisung der Queue) habe ich dann ein sauberes QoS?
An den Ports wird das nicht gemacht. Die Zuweisung ToS Wert zu Queue passiert immer global.An den Ports muss man nur aktivieren das die inbound Traffic auf DSCP prüfen sollen. (DSCP Trust oder DSCP Honoring) Laut der Konfigs oben ist das aber Default der Fall wenn man auf DSCP umschaltet statt .1p
An den Ports muss man nur aktivieren das die inbound Traffic auf DSCP prüfen sollen. (DSCP Trust oder DSCP Honoring) Laut der Konfigs oben ist das aber Default der Fall wenn man auf DSCP umschaltet statt .1p
Also DSCP Trust ist auf allen Switchen global aktiviert:
EF geht in die Queue 4 (auch global auf allen Switchen):
Der Menüpunkt DiffServ scheint aber uninteressant zu sein - hier lassen sich komplexe Regeln anlegen - eigentlich müsste es das mit den o. g. Einstellungen gewesen sein.
Kommt aber immer noch zu Aussetzern in der Sprache - ein Bug in der Firmware der Telefonanlage? Die Anlage ist sehr neu und eher noch eine Beta als ein fertiges Release.... Laut Wireshark tagged die Anlage ja die Pakete entsprechend - DSCP ist nun auf allen Switchen aktiv (vorher war 802.1p aktiv - klar dass es da dann nicht gehen konnte). Oder sind das irgendwelche Netgear Besonderheiten, die eventuell noch einzustellen sind? Ich meine, es gibt schon viele Einstellungen (Voice VLAN, AutoVoIP, CoS, DiffServ)...
Unter ACL VLAN Binding muss ich anscheinend die ACLs enstprechend an die VLANs binden (bzw an die virtuelle Gateway IP des Core). Die ACLs lege ich dann zuvor mit Namen an.
Also DSCP Trust ist auf allen Switchen global aktiviert:
Perfekt ! Dann passt das !Hat der Switch eine Show Funktion wo du dir die Paket Counter der Priority Queues mal ansehen kannst ? Das ist wichtig.
Du weisst ja: Vertrauen ist gut, Kontrolle ist besser !!! Das gilt gerade bei Billigheimer NetGear.
Nur um zu sehen das der Switch nun auch wirklich DSCP 46 markierte Voice Pakete in die entsprechenden Priority Queues forwardet !
Tut er das nämlich nicht, sei es aus Konfig Fehler oder Firmware Bug, nützt das QoS dann natürlich nix.
eigentlich müsste es das mit den o. g. Einstellungen gewesen sein.
Das ist richtig. Er nutzt dann sein Default Profil für DSCP.Kommt aber immer noch zu Aussetzern in der Sprache -
Deshalb die Frage oben nach dem Show Kommando um zu sehen was der Switch macht bzw. das was er soll !!Ansonsten mit dem Wireshark mal einen solchen Call mit Aussetzern direkt im Netz mitscneiden.
Du kannst den Flow dann im Wireshark markieren und mit dem Wireshark PC die Kommunikation wieder abspielen.
Wenn dort keine Aussetzer zu hören sind (Paket Drops) dann liegt es nicht an der Switch Infrastruktur sondern an den Telefonen bzw. der Anlage selber.
Kommt aber immer noch zu Aussetzern in der Sprache -
Vorsicht ! "Taggen" ist missverständlich, denn das mein in der Regel einen L2 VLAN Tag und damit dann 802.1p.Du meinst sicher hat den richtigen DSCP Wert, richtig ?
Oder sind das irgendwelche Netgear Besonderheiten, die eventuell noch einzustellen sind?
Als bekennender NG Hasser kein Kommentar. Im Ernst...weiss ich nicht, denke aber nicht, da durch die Bank alle Hersteller weltweit das so machen.Unter ACL VLAN Binding muss ich anscheinend die ACLs enstprechend an die VLANs binden
Das wäre die gängige Vorgehensweise, richtig. Virtuelle Gateway IP im Core ist genau richtig. Klar, denn dort findet das L3 Forwarding statt und nur da können L3 ACLs auch greifen Deshalb die Frage oben nach dem Show Kommando um zu sehen was der Switch macht bzw. das was er soll !!
Show Kommando konnte ich keines finden, bzw auch keinen Punkt wo mir gemonitort wird, ob Pakete entsprechend der Queue 4 zugewiesen werden.
Konnte jetzt aber ein Gespräch mitschneiden, wo gegen Ende ein Aussetzer zu hören ist, Wireshark zeigt mir folgendes an der Stelle an:
Wenn ich mir das Gespräch nun in Wireshark anhöre, hört es sich flüssig an. Ein zweites Gespräch - auch mit - von Wireshark gekennzeichneten, verlorenen Paketen - hat tatsächlich einen Lag - die Stimme wird plötzlich unterbrochen und geht dann einfach weiter. Ist aber anscheinend häufig (oder immer?) bei dem Stream, der kommend ist - also der externe Gesprächspartner wird nicht mehr verstanden.
Jetzt bin ich an der Stelle, wo ich ratlos bin. Die Anlage kann ich ja nicht ausschließen oder? Nicht dass die Telefone bzw. die Anlage den Fehler verursachen? Generell ist im Netz auch nicht sooo viel Verkehr, dass die Abbrüche ständig wären. Der Telefonjunge ist wenig bis gar nicht kooperativ und sagt nur "liegt an eurer Infrastruktur". An den Switchen scheint aber alles soweit richtig zu sein - Screenshots hab ich ja gepostet. Die Einstellungen sind exakt so auf allen Geräten. Vielleicht muss ich noch mit den DiffServ Policys/Classes rumspielen? Netgear hat hier einen Artikel, wo alle Devices im VoiceVLAN über DiffServ Classes/Policys den Queues zugewiesen werden. Inwieweit ich hier noch Einstellungen treffen müsste, kann mir keiner beantworten - auch nicht der Netgear Support
Mit externer Gesprächspartner meinst du da einen im Internet oder der via Internet und Provider reinkommt.
Da kannst du dann nichts machen, denn diese Aussetzer passieren dann direkt im Internet bzw. auf dem Pfad im Internet selber. Dort priorisieren Provider nur ihren eigenen Voice Traffic aber niemals welchen von unabhängigen Voice Providern wie SIPgate, DUSnet usw. oder auch Betreiber von gehosteten VoIP Anlagen.
Hier solltest du natürlich zwingend noch den Voice Traffic in deinem Internet Router priorisieren !!!
Die ganze interne Priorisierung nützt nix für externe Voice Calls wenn das nicht auf dem Router auch passiert. Hier ist die größte Schwachstelle weil du von GiG Bandbreite mit einmal nur ein paar Mbits hast.
Der Router muss natürlich auch so konfiguriert sein das deine DSCP 46 Pakete priorisiert geforwardet werden.
Quasi genau so wie im Switch.
Auf dem Router macht man das mit einer ACL zum klassifizieren. Kommt aber drauf an was du/ihr da als Router betreibt und wie dort QoS umgesetzt ist ?!
Im Router ist ein großer Engpass und der muss natürlich wissen wenn einer im LAN dänische Western aus dem Internet saugt oder sonstwas macht oder die Summe der Surfer und Nutzer euren Internet Anschluss zu 70% ausnutzen und das auch nur in Peaks das er anstehenden Voice Traffic immer bevorzugt und als Allererstes forwardet das es bei Voice Paketen keinerlei Verzögerung gibt.
Das entfällt natürlich wenn die Anlage selber einen dedizierten ISDN oder ISDN S2m Anschluss lokal hat. Nicht aber wenn sie auch per VoIP an den Provider angebunden ist.
Ganz besonders gilt das natürlich dann wenn die Voice Anlage extern ausgelagert ist, denn dann gehen sämtliche Voice Calls auch interne immer übers öffentliche Internet. Umso wichtiger dann der Router und dessen Voice Priorisierung !
Wenn die Anlage lokal ist dann sollte es jetzt bei deiner Switchpriorisierung bei internen Calls keinerlei Aussetzer mehr geben. Auch nicht wenn der eine oder andere Link mal höher belastet ist.
Hier ist es also wichtig woher und wohin die Calls gehen die die Aussetzer haben und das der Router mitspielt.
Da kannst du dann nichts machen, denn diese Aussetzer passieren dann direkt im Internet bzw. auf dem Pfad im Internet selber. Dort priorisieren Provider nur ihren eigenen Voice Traffic aber niemals welchen von unabhängigen Voice Providern wie SIPgate, DUSnet usw. oder auch Betreiber von gehosteten VoIP Anlagen.
Hier solltest du natürlich zwingend noch den Voice Traffic in deinem Internet Router priorisieren !!!
Die ganze interne Priorisierung nützt nix für externe Voice Calls wenn das nicht auf dem Router auch passiert. Hier ist die größte Schwachstelle weil du von GiG Bandbreite mit einmal nur ein paar Mbits hast.
Der Router muss natürlich auch so konfiguriert sein das deine DSCP 46 Pakete priorisiert geforwardet werden.
Quasi genau so wie im Switch.
Auf dem Router macht man das mit einer ACL zum klassifizieren. Kommt aber drauf an was du/ihr da als Router betreibt und wie dort QoS umgesetzt ist ?!
Im Router ist ein großer Engpass und der muss natürlich wissen wenn einer im LAN dänische Western aus dem Internet saugt oder sonstwas macht oder die Summe der Surfer und Nutzer euren Internet Anschluss zu 70% ausnutzen und das auch nur in Peaks das er anstehenden Voice Traffic immer bevorzugt und als Allererstes forwardet das es bei Voice Paketen keinerlei Verzögerung gibt.
Das entfällt natürlich wenn die Anlage selber einen dedizierten ISDN oder ISDN S2m Anschluss lokal hat. Nicht aber wenn sie auch per VoIP an den Provider angebunden ist.
Ganz besonders gilt das natürlich dann wenn die Voice Anlage extern ausgelagert ist, denn dann gehen sämtliche Voice Calls auch interne immer übers öffentliche Internet. Umso wichtiger dann der Router und dessen Voice Priorisierung !
Wenn die Anlage lokal ist dann sollte es jetzt bei deiner Switchpriorisierung bei internen Calls keinerlei Aussetzer mehr geben. Auch nicht wenn der eine oder andere Link mal höher belastet ist.
Hier ist es also wichtig woher und wohin die Calls gehen die die Aussetzer haben und das der Router mitspielt.
Also generell ist VoIP nur intern - die Info hätte ich noch geben müssen. Die TK-Anlage hängt noch auf NTBAs - geht also noch über das ISDN Netz raus, weil in unserer Region noch keine SIP-Trunk Anschlüsse der Telekom verfügbar sind. Somit kommunizieren die Telefone über IP mit der Anlage und die Anlage nach außen via ISDN.
Die Abbrüche scheinen aber auch intern unter den einzelnen IP Apparaten zu sein. Ich finde es gerade sehr schwer die Ursache zu finden, warum es zu Aussetzern kommt...auch weil ich ja jetzt nachweislich welche mit Wireshark aufgezeichnet habe. Aber was die o. g. Screenshots von Wireshark zu bedeuten haben, kann ich leider nicht lesen. Irgendwie muss ja herauszufinden sein ob es tatsächlich am Netzwerk liegt (Infrastruktur/Switche) oder ob ich den Telefonjungen auf den Zahn fühlen muss? Die experimentieren nun mit neuer Firmware rum und der Hersteller sagt nur "liegt an eurem Netz". Wireshark hat ja was mit "Wrong sequence number" und 200 verlorenen Paketen aufgezeichnet.
Generell ist die AutoVoIP Funtkion von Netgear noch aktiv (OUI based und protocoll based) - das sollte ja aber keine Rolle spielen, da Layer 2 und Anlage Layer 3 korrekt? Ansonsten sind alle Einstellungen auf default - bis eben auf die globale Umstellung von 802.1p auf DSCP und dem setzen von EF=Queue 4.
Die Abbrüche scheinen aber auch intern unter den einzelnen IP Apparaten zu sein. Ich finde es gerade sehr schwer die Ursache zu finden, warum es zu Aussetzern kommt...auch weil ich ja jetzt nachweislich welche mit Wireshark aufgezeichnet habe. Aber was die o. g. Screenshots von Wireshark zu bedeuten haben, kann ich leider nicht lesen. Irgendwie muss ja herauszufinden sein ob es tatsächlich am Netzwerk liegt (Infrastruktur/Switche) oder ob ich den Telefonjungen auf den Zahn fühlen muss? Die experimentieren nun mit neuer Firmware rum und der Hersteller sagt nur "liegt an eurem Netz". Wireshark hat ja was mit "Wrong sequence number" und 200 verlorenen Paketen aufgezeichnet.
Generell ist die AutoVoIP Funtkion von Netgear noch aktiv (OUI based und protocoll based) - das sollte ja aber keine Rolle spielen, da Layer 2 und Anlage Layer 3 korrekt? Ansonsten sind alle Einstellungen auf default - bis eben auf die globale Umstellung von 802.1p auf DSCP und dem setzen von EF=Queue 4.
OK, dann ist das geklärt.
Wie ist die am Switch angebunden ? Hast du da mal nach CRC, Runt oder Alignment Errors gecheckt die ggf. ein Autnegotiation Problem darstellen können oder ist das Interface sauber ?
Ist die irgendwie redundant angebunden LAG, vLAG oder Failover Link ?
Richte Testweise mal 2 freie Softphone Clients ein wie den Phoner: http://www.phoner.de auf 2 PCs und melde die an der Anlage an.
Hier kannst du mal etwas mit Codecs rumspielen und der Sache weiter auf den Grund gehen, ob die Softphone Verbindung z.B. auch Aussetzer zeigt. Nur um ganz sicher zu gehen ob das Infrastruktur oder Anlagen bezogen ist.
Das ist das erste was du sicher rausbekommen musst.
Es ist natürlich auch Mist das es kein Show Kommando auf den Switches gibt die die Paket Counter in der Queue anzeigen Da rächt sich dann wieder Billigheimer Netgear
Solche Troubleshooting Tools sollten immer Standard sein bei Switches. Sind sie auch bei etablierten Herstellern...aber egal damit musst du leben...oder mal den NetGear Support fragen wie man das sichtbar machen kann.
Ggf. gibt es aber eine SNMP OID die du abfragen kannst um das zu checken. Das würde wenigstens die QoS Funktion auf den Switches sicher verifizieren. Handbuch oder NG Support fragen...!
Ebenso "protocoll based" ?? Was ist damit gemeint ?? RTP Protokoll SIP oder beides ?? Oder was ganz anderes ? Dazu müsste der Switch dann sogar eine Layer 4 Erkennung (Protokoll Layer) machen TCP und UDP Ports. NetGear ist das nicht wirklich zuzutrauen aber wer PVSTP kann...da muss man ja jetzt vorsichtig sein
Wie ist die am Switch angebunden ? Hast du da mal nach CRC, Runt oder Alignment Errors gecheckt die ggf. ein Autnegotiation Problem darstellen können oder ist das Interface sauber ?
Ist die irgendwie redundant angebunden LAG, vLAG oder Failover Link ?
Richte Testweise mal 2 freie Softphone Clients ein wie den Phoner: http://www.phoner.de auf 2 PCs und melde die an der Anlage an.
Hier kannst du mal etwas mit Codecs rumspielen und der Sache weiter auf den Grund gehen, ob die Softphone Verbindung z.B. auch Aussetzer zeigt. Nur um ganz sicher zu gehen ob das Infrastruktur oder Anlagen bezogen ist.
Das ist das erste was du sicher rausbekommen musst.
Es ist natürlich auch Mist das es kein Show Kommando auf den Switches gibt die die Paket Counter in der Queue anzeigen
Da rächt sich dann wieder Billigheimer Netgear Solche Troubleshooting Tools sollten immer Standard sein bei Switches. Sind sie auch bei etablierten Herstellern...aber egal damit musst du leben...oder mal den NetGear Support fragen wie man das sichtbar machen kann.
Ggf. gibt es aber eine SNMP OID die du abfragen kannst um das zu checken. Das würde wenigstens die QoS Funktion auf den Switches sicher verifizieren. Handbuch oder NG Support fragen...!
Generell ist die AutoVoIP Funtkion von Netgear noch aktiv (OUI based und protocoll based)
Mmmhhh "OUI based" bedeutet das es nach Mac Adress Vendor ID geht. Jetzt mal geraten weil nicht klar ist WAS genau das ist. Dann die Frage ob sie die Vendor ID erkennen, denn das muss in der Firmware oder Konfig hinterlegt sein. Musst du in die Doku sehen welcher Mechanismus das ist. Das ist kein Standard.Ebenso "protocoll based" ?? Was ist damit gemeint ?? RTP Protokoll SIP oder beides ?? Oder was ganz anderes ? Dazu müsste der Switch dann sogar eine Layer 4 Erkennung (Protokoll Layer) machen TCP und UDP Ports. NetGear ist das nicht wirklich zuzutrauen aber wer PVSTP kann...da muss man ja jetzt vorsichtig sein
Wie ist die am Switch angebunden ? Hast du da mal nach CRC, Runt oder Alignment Errors gecheckt die ggf. ein Autnegotiation Problem darstellen können oder ist das Interface sauber ?
Ist die irgendwie redundant angebunden LAG, vLAG oder Failover Link ?
Ist die irgendwie redundant angebunden LAG, vLAG oder Failover Link ?
Solche Errors kann ich laut Port Statistik ausschließen, anbei mal die volle Portstatistik vom TK-Port. Die Anlage ist nicht redundant angebunden sondern hängt nur mit 1 Port am Core Switch. (Port Role Designated setzt sich auf Disabled wenn ich STP an dem Port deaktiviere).
ifIndex 13
Port Type Normal
Port Channel ID Disable
Port Role Designated
STP Mode Enable
STP State Forwarding
Admin Mode Enable
Flow Control Mode Disable
LACP Mode Enable
Physical Mode Auto
Physical Status 1000 Mbps
Link Status Link Up
Link Trap Enable
Packets RX and TX 64 Octets 13847641
Packets RX and TX 65-127 Octets 3688446
Packets RX and TX 128-255 Octets 305842
Packets RX and TX 256-511 Octets 18013649
Packets RX and TX 512-1023 Octets 79556
Packets RX and TX 1024-1518 Octets 191890
Packets RX and TX 1519-2047 Octets 0
Packets RX and TX 2048-4095 Octets 0
Packets RX and TX 4096-9216 Octets 0
Octets Received 3196528886
Packets Received 64 Octets 6544697
Packets Received 65-127 Octets 417556
Packets Received 128-255 Octets 42512
Packets Received 256-511 Octets 8867233
Packets Received 512-1023 Octets 12386
Packets Received 1024-1518 Octets 26800
Packets Received > 1518 Octets 4309
Total Packets Received Without Errors 15915493
Unicast Packets Received 15884807
Multicast Packets Received 23829
Broadcast Packets Received 6857
Receive Packets Discarded 0
Total Packets Received with MAC Errors 0
Jabbers Received 0
Fragments Received 0
Undersize Received 0
Alignment Errors 0
Rx FCS Errors 0
Overruns 0
Total Received Packets Not Forwarded 0
802.3x Pause Frames Received 0
Unacceptable Frame Type 0
Total Packets Transmitted (Octets) 3819364724
Packets Transmitted 64 Octets 7302944
Packets Transmitted 65-127 Octets 3270890
Packets Transmitted 128-255 Octets 263330
Packets Transmitted 256-511 Octets 9146416
Packets Transmitted 512-1023 Octets 67170
Packets Transmitted 1024-1518 Octets 165090
Packets Transmitted > 1518 Octets 1331
Maximum Frame Size 1500
Total Packets Transmitted Successfully 20218502
Unicast Packets Transmitted 15894435
Multicast Packets Transmitted 1127709
Broadcast Packets Transmitted 3195027
Transmit Packets Discarded 0
Total Transmit Errors 0
Total Transmit Packets Discarded 0
Single Collision Frames 0
Multiple Collision Frames 0
Excessive Collision Frames 0
STP BPDUs Received 0
STP BPDUs Transmitted 0
RSTP BPDUs Received 0
RSTP BPDUs Transmitted 441807
MSTP BPDUs Received 0
MSTP BPDUs Transmitted 0
802.3x Pause Frames Transmitted 0
GVRP PDUs Received 0
GVRP PDUs Transmitted 0
GVRP Failed Registrations 0
GMRP PDUs Received 0
GMRP PDUs Transmitted 0
GMRP Failed Registrations 0
EAPOL Frames Received 0
EAPOL Frames Transmitted 0
Time Since Counters Last Cleared 10 day 17 hr 6 min 1 sec Richte Testweise mal 2 freie Softphone Clients ein wie den Phoner
Esos ProCall läuft schon auf etwa 6 PCs, da scheint es aktuell keine Aussetzer zu geben - die Aussetzer sind wohl nicht global an jedem Telefon in der Firma. Manche haben gar keine Aussetzer, manche schon. Ich konnte aber auch da kein Muster erkennen. Dann prüfe ich die SoftPhones nochmal genauer, ob es da Abbrüche gibt.
Dazu müsste der Switch dann sogar eine Layer 4 Erkennung (Protokoll Layer) machen TCP und UDP Ports
Laut einem Netgear PDF läuft wohl hier eine Layer 4 Erkennung...aber genaueres über die generelle Arbeitsweise von dem Überbegriff "AutoVoIP" konnte ich noch nicht in Erfahrung bringen. Das Ticket ist zwar an den L3 Support eskaliert, aber von da bekomme ich Hilfe gleich Null
P.S.: Von den Funktionen her muss ich sagen ganz gute Geräte, aber der Support und die Handbücher sind unter aller Kanone
So wenig Fachwissen von L3 Technikern vom Hersteller hatte ich noch nie.
Port Statistiken sehen in der Tat sauber aus !
Macht es einen Unterschied ob du STP aktivierst oder deaktivierst ? Sollte es eigentlich nicht....
Zu dem Rest sag ich jetzt mal nix....
Macht es einen Unterschied ob du STP aktivierst oder deaktivierst ? Sollte es eigentlich nicht....
Laut einem Netgear PDF läuft wohl hier eine Layer 4 Erkennung
War zu vermuten.... Sowas kostet aber horrende Performance auf einem Switch. Der muss alle Frames bis in den Layer 4 ansehen. Da gehen auch manchmal schon Ciscos in die Knie. Solltest du mal deaktivieren und checken ob das einen Unterschied macht. Richtig nutzen tust du das ja eh nicht.Zu dem Rest sag ich jetzt mal nix....
Macht es einen Unterschied ob du STP aktivierst oder deaktivierst ? Sollte es eigentlich nicht....
Habe ich jetzt auch am Core mal deaktiviert - auf den Access Switchen mit Voice Telefonen ist es schon aus. Lassen sich aus den Wireshark-Mitschnitten ansonsten noch weiter Infos rauslesen, vor allem was es mit den verlorenen Paketen und der "Wrong sequence number" auf sich hat? Oder heißt es jetzt für uns wirklich Try´ n Error? Weil das Netz mit 9 Verteilern doch relativ weitläufig aufgestellt, gibt es ja unendlich viele Möglichkeiten, wo die Probleme herkommen können? Ich kann ja bis jetzt nicht sauber die TK-Anlage ausschließen - bei einem Mitschnitt war eine kurze Verzögerung zu hören, beim anderen war das Gespräch völlig klar, der Teilnehmer am Telefon (intern) meinte aber er hätte den Gegenüber (extern) nicht sauber verstanden - war gegen Ende wo auch Wireshark "zugeschlagen" hat. Generell sind alle Captures (bzw. die Audio Streams), die Wireshark aufgezeichnet hat und wo auch am Telefon Aussetzer waren mit verlorenen Paketen gekennzeichnet. Also stimmt da zumindest die Messung mit Wireshark und dem tatsächlichem Telefonat über ein.
Zu dem Rest sag ich jetzt mal nix....
Wenn bei uns alles läuft, sehe ich bei dir die Netgear Switche stehen - zumindest in einer Teststellung
Habe ich jetzt auch am Core mal deaktiviert
Hoffentlich nicht den STP ??!! Du meinst das AutoVoIP oder ?Die wrong Sequence Number ist tödlich. Bei TCP hast du ein Frame Numbering und wenn das nicht mehr stimmt dann zeugt das von erheblichen Problemen im IP Stack dieses Endgerätes oder von erheblichen Paket Verlusten im Netz. Das wäre sehr außergewöhnlich und selten.
Ich kann ja bis jetzt nicht sauber die TK-Anlage ausschließen
Das ist die Crux. Du kannst aber mit iPerf mal Messungen machen was Antwortzeiten anbetrifft und Paket Delays und bei TCP auch das Sequencing. Da kannst du zu 90% dann schon Infrastruktur Fehler ausschliessen.Wenn du keine große Grundlast im Netz hast dann sollten popelige 64kBit Telefone immer sauber rüberkommen und das auch ohne QoS.
Hast du den Softphone Test mal gemacht ? iPerf solltest du auch mal machen. Das Problem auch das du nicht sicher weisst ob das QoS sauber rennt....
Was nach Sinn macht:
2 Telefone mal direkt am Switch anschliessen wo auch die Anlage rennt um zu sehen ob dort auch Aussetzer passieren. Da hier null Übertragungspfad ist muss das dort Aussetzer frei rennen auch ohne QoS.
Auch solltest du drauf achten das in der Codec Reihenfolge der Anlage immer der HD Codec G.722 zuerst negotiated wird. Das ist aber jetzt reine Telefonie Sache.
Von Netgear kam jetzt noch folgende Aussage:
Der letzte Teil klingt spannend. Wir haben sonst keine Probleme im Netz, daher würden mich die hohen delta Zeiten interessieren bzw. wodurch diese entstehen. Wenn ich wireshark laufen lasse haben lldp Pakete tatsächlich hohe delta Zeiten. DHCP könnte auch etwas schneller laufen (gefühlt) aber es bestehen derzeit keinerlei Beeinträchtigungen. Wie kann ich sowas generell messen bzw bestimmen wo verzögerungen herkommen? An sich sind die Switche ja nur zusammengesteckt über LAGs. Datentransfer über mehrere Minuten vom letzten Netzpunkt zum Server bleibt konstant bei 112 MB/s, also meiner Meinung nach Optimalwerte für Gigabit.
Ich habe jetzt zusätzlich unter DiffServ eine Regel angelegt. Hier werden alle Pakete aus dem Voice VLAN der Queue 4 zugewiesen. Das kann ich Monitoren und funktioniert auch soweit. Wobei DSCP Trust schon aktiviert ist und dort ja auch alles in Queue 4 geht.
Based on the information you provided and the latest wireshark capture, the issue may not be QOS. That said, it would be worthwhile to resolve rule this out by ensuring it works
There is also high delta times (time between frames) on the wireshark capture for all the malformed packets. The UDP (presumably voip) are only malformed when the delta time is above average. All the non-malformed udp packets and have regular delta times.
SCREENSHOT:
http://puu.sh/vhFLJ/8013432177.png
That raises questions about the network itself as not only do some udp packets have high delta times but also dhcp, arp, lldp, etc. So it is not specific to voip traffic. Of course you would notice network issues more on voip as it is more sensitive and real-time. Der letzte Teil klingt spannend. Wir haben sonst keine Probleme im Netz, daher würden mich die hohen delta Zeiten interessieren bzw. wodurch diese entstehen. Wenn ich wireshark laufen lasse haben lldp Pakete tatsächlich hohe delta Zeiten. DHCP könnte auch etwas schneller laufen (gefühlt) aber es bestehen derzeit keinerlei Beeinträchtigungen. Wie kann ich sowas generell messen bzw bestimmen wo verzögerungen herkommen? An sich sind die Switche ja nur zusammengesteckt über LAGs. Datentransfer über mehrere Minuten vom letzten Netzpunkt zum Server bleibt konstant bei 112 MB/s, also meiner Meinung nach Optimalwerte für Gigabit.
Ich habe jetzt zusätzlich unter DiffServ eine Regel angelegt. Hier werden alle Pakete aus dem Voice VLAN der Queue 4 zugewiesen. Das kann ich Monitoren und funktioniert auch soweit. Wobei DSCP Trust schon aktiviert ist und dort ja auch alles in Queue 4 geht.
Mmmhhh, das ist nur mit etwas Messaufwand rauszufinden. Du müsstest mehrere Messungen machen, woher diese Delaiys lommen, sprich also ob sie schon von den Endgeräten so ankommen oder durch das netz verursacht werden.
Was DHCP anbetrifft musst du dann mit einem Mirror Port mal den Server Port spiegeln und nach DHCP filtern.
Hier kannst du dann sehen welche Delay Zeiten der Server selber hat.
Gleiches gilt für die VoIP Anlage und die Telefone.
Sinnvollerweise sniffert man dann parallel auch am Zielrechner um zu sehen ob sich an den Deltas da dann nach dem "Durchqueren" des Netzes etwas verändert hat.
Letzteres ist eher selten aber kann man natürlich nicht ausschliessen. Solche hohen Deltas kommen meist vom Endgerät selber, das das überlastet ist oder die NIC nicht leistungsstark genug ist.
Aber wie gesagt, das müsste man sehr genau messen.
Idealerweise macht man mal eine Vergleichsmessung an nur einem Switch so das man einmal den Vergleich hat eines längeren Weges über Infrastruktur Links und direkt über den Backbone eines Switches.
Letzteres schliesst dann vollkommen ggf. defekt oder verdreckte Optiken oder Kabel aus.
Es ist gut möglich das dein L1 das verursacht. Hier bietet sich ein check aller Backbone Links und LAGs an ob dir Port Errors irgendwo verstärkt auftreten. Ist etwas Aufwand....
LLDP darfst du nicht zuviel drauf geben. Der interne Scheduler in Geräten (Switches, Router etc.) verwendet sehr wenig Zeit auf solche "kosmetischen" Protokolle die nicht lebenswichtig für die Funktion sind, deshalb kann es hier mal zu größeren Deltas kommen, das ist nicht so relevant. Für einen Switch ist es aber essentiell das sowas z.B. nie bei STP oder VRRP usw. passiert, da sein "überleben" bzw. das der Infrastruktur davon abhängt.
Was DHCP anbetrifft musst du dann mit einem Mirror Port mal den Server Port spiegeln und nach DHCP filtern.
Hier kannst du dann sehen welche Delay Zeiten der Server selber hat.
Gleiches gilt für die VoIP Anlage und die Telefone.
Sinnvollerweise sniffert man dann parallel auch am Zielrechner um zu sehen ob sich an den Deltas da dann nach dem "Durchqueren" des Netzes etwas verändert hat.
Letzteres ist eher selten aber kann man natürlich nicht ausschliessen. Solche hohen Deltas kommen meist vom Endgerät selber, das das überlastet ist oder die NIC nicht leistungsstark genug ist.
Aber wie gesagt, das müsste man sehr genau messen.
Idealerweise macht man mal eine Vergleichsmessung an nur einem Switch so das man einmal den Vergleich hat eines längeren Weges über Infrastruktur Links und direkt über den Backbone eines Switches.
Letzteres schliesst dann vollkommen ggf. defekt oder verdreckte Optiken oder Kabel aus.
Es ist gut möglich das dein L1 das verursacht. Hier bietet sich ein check aller Backbone Links und LAGs an ob dir Port Errors irgendwo verstärkt auftreten. Ist etwas Aufwand....
LLDP darfst du nicht zuviel drauf geben. Der interne Scheduler in Geräten (Switches, Router etc.) verwendet sehr wenig Zeit auf solche "kosmetischen" Protokolle die nicht lebenswichtig für die Funktion sind, deshalb kann es hier mal zu größeren Deltas kommen, das ist nicht so relevant. Für einen Switch ist es aber essentiell das sowas z.B. nie bei STP oder VRRP usw. passiert, da sein "überleben" bzw. das der Infrastruktur davon abhängt.
Idealerweise macht man mal eine Vergleichsmessung an nur einem Switch so das man einmal den Vergleich hat eines längeren Weges über Infrastruktur Links und direkt über den Backbone eines Switches.
Ich habe mit einem VoIP Analyzer und 2 PCs VoIP Traffic simuliert - markiert mit dem ToS Wert 46 und hatte an einem Switch keinen Jitter, keine Verzögerung und keine Paketverluste. Für mich klar, weil die Pakete ja nicht durch die ganze Infrastruktur gehen bzw der Core Switche muss diese nicht routen, korrekt? Über mehrere Stockwerke war dann max. ein Paketverlust von 1,7% - lt ITU G.114 ist bis zu 5% OK. Jitter war bei max. 0,7 und nur teilweise wieder eine Verzögerung - anscheinend ist diese auch dann, wenn es zu Aussetzern kommt. Ich vermute nun dass die Verzögerung diese Aussetzer verursacht. Nun ist die Gretchenfrage, was diese Verzögerungen der RTP Pakete verursacht? Um die Telefone auszuschließen teste ich nun Softphones am PC.
Letzteres ist eher selten aber kann man natürlich nicht ausschliessen. Solche hohen Deltas kommen meist vom Endgerät selber, das das überlastet ist oder die NIC nicht leistungsstark genug ist.
Aber wie gesagt, das müsste man sehr genau messen.
Aber wie gesagt, das müsste man sehr genau messen.
Wie misst man das genauer? Wie gesagt spuckt mir der VoIP Analyzer sehr gute Werte aus - bis auf seltene Verzögerungen, wo dann auch die Aussetzer sind..diese Delays hatte ich ja auch in Wireshark...
Laut Log am L3 treten auf keinen LAGs Errors auf, auch nicht am Port wo die TK Anlage hängt. Kann es sein, dass wirklich die TK Anlage oder die Telefone selbst das Problem sind? Wie gesagt ist im Netz so wenig Grundlast, dass VoIP theoretisch ohne QoS rennen müsste...
nicht durch die ganze Infrastruktur gehen bzw der Core Switche muss diese nicht routen, korrekt?
Sofern du nur an einem einzigen Switch beide Komponenten hattest und diese beiden Test PCs auch noch in einem gleichen IP Segment gelegen haben ist das korrekt !Über mehrere Stockwerke war dann max. ein Paketverlust von 1,7% - lt ITU G.114 ist bis zu 5% OK.
Oha.... das ist aber dramatisch. In einem lokalen Netzwerk das nicht überlastet ist also quasi im Mittel nicht mehr als 20-30% Last auf den Uplinks hat sollte es zu keinerlei Paket Verlusten kommen. Weder im L2 noch im L3.Dieser Wert ist weitaus zu hoch.
Normal hat man so um die 5-10% Durchschnittslast auf den Uplinks je nach Segmentierung und dafür ist der Wert wirklich extrem hoch.
Nun ist die Gretchenfrage, was diese Verzögerungen der RTP Pakete verursacht?
Erstens das und zweitens der doch recht hohe Paketverlust.Da es auf einem einzelnen Switch nicht passiert hat es was mit der Infrastruktur zu tun. Du solltest mal schrittweise den Hopcount erhöhen um dort eine Tendenz festzustellen.
Also erstmal alles auf L2 Basis innerhalb eines VLANs messen. In einem Switch, dann über 2 Switches, dann über 3 usw. Gibt es da einen Trend ?
Dann das gleiche mit L3 wo beide Test PCs in unterschiedlichen IP Netzen liegen.
Zudem solltest du SNMP aktivieren auf den Switches und dir mal die Belastung der Uplink Ports über ein paar Stunden ansehen:
RX Dropped Pkts Problem
Das ist wichtig um mal verlässliche Aussagen über die Grundlast machen zu können.
Sehr wichtig ist auch mal die CPU Last dieser Switches zu monitoren. Billigheimer verbauen sehr oft preiswerte und schwachbrüstige SoCs in den Switches die dann bei der kleinsten Belastung (STP, IGMP, QoS usw.) in die Knie gehen und als erstes dann einen Packet Drop verursachen. Das könnte eine Ursache sein...
Mit dem STG Tool kannst du mehrere Fenster gleichzeitig starten und das parallel überwachen also Uplink Lasten und CPU Last.
Das mit den Softphones ist auch gut um mal HW unabhängig zu testen. Ggf. die Testreihe mal mit HW und Softphones machen ob dort Unterschiede erkennbar sind.
So musst du dich an den Verursacher messtechnisch rantasten.
Oha.... das ist aber dramatisch. In einem lokalen Netzwerk das nicht überlastet ist also quasi im Mittel nicht mehr als 20-30% Last auf den Uplinks hat sollte es zu keinerlei Paket Verlusten kommen. Weder im L2 noch im L3.
Hier dachte ich, dass die TK Anlage Paketverluste bis 5% ausgleicht, bzw es bei 30 Minuten Messzeit und 1.7% Verlust eigentlich keine merkbaren Aussetzer geben dürfte?Da es auf einem einzelnen Switch nicht passiert hat es was mit der Infrastruktur zu tun. Du solltest mal schrittweise den Hopcount erhöhen um dort eine Tendenz festzustellen.
Ich könnte im selben Rack mit 4 Switchen am ersten und letzen Switch messen. Sobald ich aber das Rack wechsle, gehen die Pakete ja wieder über den L3, da alles mit dem verbunden ist. Billigheimer verbauen sehr oft preiswerte und schwachbrüstige SoCs
Ich kann nicht sehen, was im M4300 verbaut ist, aber wahrscheinlich SoCs mit:CPU
800 Mhz
1GB
RAM
256MB
Flash
Wenn dann kann ja nur der Core "Schuld" sein weil ja alles über den geht, sobald das Rack wechselt. Bei 50 PCs meine ich aber ist die Infrastruktur schon übergroß - gerade mit den 20 GBit LAGs zum Core, gestackt sind die Racks über 10 GBit. Wenn ein Paket ein Rack verlässt, geht es ja quasi direkt über LWL zum Core - also ist ein Access im EG laienhaft ausgdrückt nur über eine lange LWL Strecke mit dem Core verbunden - die Pakete müssen ja nicht erst mehrere Geräte durchqueren.
Mit 10 gleichzeitigen VoIP Calls hat der VoIP Analyzer eine Last von 1% über mehrere Racks gemessen, also über den Core. Da waren dann aber die 1,7% Verlust mit dabei.
Hier dachte ich, dass die TK Anlage Paketverluste bis 5% ausgleicht,
Nicht denken sondern nachdenken ! RTP basiert immer auf UDP. Wie denkst du soll dann ein Endgerät einen Paketverlust ausgleichen können ??
UDP hat bekanntlich keine Sicherungsschicht wie TCP, da gilt also was wech ist ist wech.... Das hört man dann auch deutlich an den Aussetzern.
Sobald ich aber das Rack wechsle, gehen die Pakete ja wieder über den L3, da alles mit dem verbunden ist.
Äähhh bitte wie ???Das ist doch Unsinn ! Sieh dir deine Zeichnung ganz oben an ! Die Layer 2 VLANs ziehen sich doch transparent über die gesamte Access Struktur auf den Core und auch da sind sie ja nich vorhanden.
Layer 3 Routing darf doch in so einem (richtigen) Design niemals davon abhängig sein an welchem Schrank, Switch oder sonstwas du steckst. Einzig das VLAN bestimmt ob es L3 Forwarding gibt oder nicht.
Wenn das tatsächlich stimmen sollte stimmt aber ganz gewaltig was nicht mit deinem grundlegenden Netzwerk Design ???
Hoffentlich hast du dich hier nur falsch ausgedrückt !!
Bei 50 PCs meine ich aber ist die Infrastruktur schon übergroß
Bei 20G LAGs ?? Das ist nicht dein Ernst hier von übergroß zu reden, oder ??Da könnten 500 Clients drin sein und es wäre immer noch vollkommen überdimensioniert.
die Pakete müssen ja nicht erst mehrere Geräte durchqueren.
Richtig !Mehr als max. 3 Layer 2 Hops kannst du in so einem Netzwerk gar nicht haben. Typisch sind es nur 1 oder 2 Hops wenn die Endgeräte zu 98% mit am Core angeschlossenen Geräten kommunizieren. In so fern hast du Recht das man sich Tests über mehr als 3 Hops natürlich sparen kann.
Mit 10 gleichzeitigen VoIP Calls
Das sind in Summe max. 640 kbit/s mal einen HD Voice Codec mit G.722 vorausgesetzt (bei G.711 ist es eh noch weniger).Bei einem 20G Netz muss man über solch ein Volumen wohl nicht mehr reden. Speziell wenn es auch noch verteilt ist auf den Access Switches.
Hier zählt dann nur die Auslastung der LWL Links und die CPU Last des Switches. Deshalb das SNMP Monitoring.
Bei in Summe 50 Clients auf einem 20G Backbone darf es zu keinerlei Paket Verlusten kommen auch keinen 1,7%
Hast du mal geprüft ob du Flow Control deaktiviert hast im Netz ?? Das muss aus sein wegen der mickrigen Port Buffer auf den NetGears !
Äähhh bitte wie ???
Ich habe das so gemeint: Die Access Switche sind ja nicht direkt miteinander verbunden - die Verbindung erfolgt ja über den Core. Also geht doch ein Datenpaket z. B. anhand des obigen Bildes vom linken Access Switch zum rechten Access Switch über den Core. Wenn ich dort nun 2 PCs mit VoIP Analyzer anschließe, geht das Datenpaket ja nicht direkt von Access zu Access sondern werden über den Core geswitcht - im selben VLAN natürlich nicht geroutet. Wenn nun noch das VLAN gewechselt wird routet der Core, ansonsten switcht er nur, korrekt?
Da könnten 500 Clients drin sein und es wäre immer noch vollkommen überdimensioniert.
Dann verstehe ich die Paketverluste oder Verzögerungen nicht. Laut TechLog wird die CPU am Core bei "Last" zu 15% belegt - war also der Max Wert. Broadcasts sind nun auch deutlich weniger, Errors an Ports oder LAGs sind auch keine zu sehen.Ich habe nur relativ viele solche Meldungen, wobei das doch der Switch locker weg stecken dürfte bei CPU Last von 15%, oder?
<13> Apr 25 14:05:51 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217292 %% Spanning Tree Topology Change Received: MSTID: 0 lag 7
<13> Apr 25 14:05:50 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217291 %% Spanning Tree Topology Change Received: MSTID: 0 lag 7
<13> Apr 25 14:05:49 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217289 %% Spanning Tree Topology Change Received: MSTID: 0 lag 7 vom linken Access Switch zum rechten Access Switch über den Core.
Ahhh, OK so war das gedacht.. Ja das stimmt natürlich. Röchel...das ist natürlich korrekt...ich dachte schon.. Dann verstehe ich die Paketverluste oder Verzögerungen nicht.
Genau ! Die würde ich auch nicht verstehen... Es sei denn schwachbrüstige und intern überbuchte oder überlastete Hardware.wird die CPU am Core bei "Last" zu 15% belegt - war also der Max Wert
Der 5min oder 15min Mittelwert sollte aber 1 bis max. 5% nicht übersteigen.Spanning Tree Topology Change Received:
Oha....böses Faul. Und dann auch noch im Sekundenrhytmus Das darf eigentlich niemals auftreten !
Ein Spanning Tree Topo Change kann es ja nur dann geben wenn ein Knoten wegfällt oder ein Link oder sowas und der Spanning Tree komplett neu berechnet werden muss was erheblich CPU Power kostet. Gerade bei Billighardware kann sowas tödlich sein durch deren schwachbrüstige SoCs intern.
Wenn der STP Prozess sauber customized ist kann es niemals einen Topo Change geben, denn das würde ja bedeuten das irgendwo ein Link ausgefallen und die Spanning Tree Topologie neu berechnet werden müsste.
Wenn alle Switches aktiv sind kann das ja nie passieren !!! Wie auch...?
Der Spanning Tree und seine Topologie sollte also immer konstant sein und diese Messages dürfen nur auftauchen bei Switch- oder Linkausfällen.
Das die bei dir im Sekundenrhytmus auftauchen zeigt auf einen gravierenden Fehler irgendwo im Spanning Tree !!
Das können kaputte Optiken auf einem Uplink Port sein, oder irgendwo ein fremder Switch der das falsche Protokoll spricht oder permanent eine andere Bridge Priority injiziert.
Das solltest du dringend rausbekommen was das ist.
Sagtest du nicht du hast sinnvollerweise in einem Stack Design jetzt ganz auf STP verzichtet ??? Wo kommen denn dann STP Topo Changes her wenn du gar kein STP mehr machst ??
Oder hattest du das jetzt an (ich meine MSTP, oder ?) um ein Looping von Fremdswitches zu verhinden. Macht auch Sinn aber das zeigt dann das irgendwas gehörig instabil ist in deinem Netz oder du hast da noch irgendwo ein Geister Device was deinen STP ins Wanken bringt !!
Topo Changes im Sekundenrhytmus sind tödlich für die Switch CPU. Da liegt sehr wahrscheinlich der Hund begraben !!
Es sei denn schwachbrüstige und intern überbuchte Hardware.
Bezogen auf die Netgear Teile? Der Mittelwert liegt irgendwo bei 0,X% Belastung. Der Netgear Support kann auch in der 3200 Zeilen langen TechSupport Datei keine Fehler finden..langsam tritt Verzweiflung ein, wenn der Telefonmann keine Fehler findet und wir auch nicht Das die bei dir im Sekundenrhytmus auftauchen zeigt auf einen gravierenden Fehler irgendwo im Spanning Tree !!
Sowas hab ich vermutet. STP steht noch auf Netgear default - dann werde ich es überall zum Testen deaktivieren. Eigentlich wollte ich STP einsetzen um Loops von eventuellen Fremdswitchen zu vermeiden.So wie es aussieht kommt der Topology Change von verschiedensten LAGs (der Auszug ist aus dem Core), ich denke nicht dass das kaputte Optiken sind, eher eine Fehlkonfig im Switch.
Wie kann ich am schnellsten rausfinden, von wo der TC her kommt? Wer verursacht den? Spielt da einfach nur die Konfig auf allen Switchen verrückt oder funkt da tatsächlich ein fremder mit rein? Für mich sieht es so aus als ob alle Netgears aufgrund von Konfig-Fails STP-Amok laufen
<13> Apr 25 14:33:33 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217938 %% Spanning Tree Topology Change Initiated: 0, Interface: lag 8
<13> Apr 25 14:33:33 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217937 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Apr 25 14:31:33 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217895 %% Spanning Tree Topology Change Initiated: 0, Interface: lag 6
<13> Apr 25 14:31:33 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217894 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Apr 25 14:30:23 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217858 %% Spanning Tree Topology Change Initiated: 0, Interface: lag 3
<13> Apr 25 14:30:23 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217857 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Apr 25 14:29:35 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217829 %% Spanning Tree Topology Change Initiated: 0, Interface: lag 5
<13> Apr 25 14:29:35 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217828 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Apr 25 14:29:19 CORE_SW_DV320-2 TRAPMGR[dot1s_task]: traputil.c(763) 217804 %% Spanning Tree Topology Change Initiated: 0, Interface: lag 2Macht auch Sinn aber das zeigt dann das irgendwas gehörig instabil ist in deinem Netz
Meinst du mit instabil, dass ein fremdes Gerät reinfunkt? Die Infrastruktur mit den Netgears an sich ist ja neu...wer weiß was an Netzwerkdosen in der Putzkammer noch dran hängt...Bezogen auf die Netgear Teile?
Das war natürlich generell gemeint sonst fühlen sich die HP Fanboys hier wieder auf die Füße getreten langsam tritt Verzweiflung ein, wenn der Telefonmann keine Fehler findet und wir auch nicht
Ein Fehler ist aber ganz klar da !! Denn ein sekundlicher STP Topo Change ist ganz sicher ncht normal !Hier musst du zwingend den verursachenden Port finden !!
Irgendwas hat das mit dem LAG Ports zu tun, denn die zählt er ja kontinuierlich mit Fehlern durch !!
Da stimmt was nicht !
Kann es sein das du da irgendwelche Mismatches in den MSTP Instances, der Revision Nummer oder dem MSTP Namen gemacht hast ??
Bedenke das der MSTP name immer Case Sensitive ist !
Irgendwo ist da noch der Wurm drin. Was sagt denn der NetGear Support zu dem sekündlichen Trap Messages? Normal kann das für die ja auch nicht sein.
eher eine Fehlkonfig im Switch.
Ist zu vermuten ! Vergleiche das MSTP Setup aller Switches nochmal ganz genau.Wer verursacht den?
Bei anderen Herstellern gibt es ein show mstp detail Kommando um das anzeigen zu lassen. Musst du mal ins Command Set der Switches sehen ob die sowas supporten.oder funkt da tatsächlich ein fremder mit rein?
Wäre auch gut möglich. Ob das der Fall ist kannst nur du wissen, denn du kennst (hoffentlich) dein Netzwerk und weisst was da angeschlossen ist.Betreibst du denn noch irgendwelche Altswitches die STP können oder haben Mitarbeiter kleine 5 Port Switches auf dem Schreibtisch (oder drunter) die STP machen ??
Ist irgendwo im RZ oder sonstwo noch ein alter vergessener Switch ?
Sonst musst du knallhart BPDU Protection einschalten auf allen Accessports wenn die NetGears sowas supporten.
Dann ignorieren sie inbound BPDUs auf den Accessports und erlauben sie nur auf Uplinks.
Instabil bezog sich auf den MSTP Status.
wer weiß was an Netzwerkdosen in der Putzkammer noch dran hängt...
DU als Admin solltest das wissen..oder wenigstens checken Kann es sein das du da irgendwelche Mismatches in den MSTP Instances, der Revision Nummer oder dem MSTP Namen gemacht hast ??
Das gesamte STP ist auf allen Switchen auf default - nach der Umstellung der VLANs habe ich da nichts angepasst oder geändert - vielleicht mein Fehler? Möglicherweise verursachen ja auch die Switche in den Telefonen solche TC?Ob das der Fall ist kannst nur du wissen, denn du kennst (hoffentlich) dein Netzwerk und weisst was da angeschlossen ist.
Ich bin noch nicht solange im Netz, kenne also nicht genau jeden Schreibtisch, ich weiß nur dass die Telefone integrierte Switche haben. Ich werde mal einen Rundgang machen und schauen ob es noch irgendwo 5-Port-Teile gibt....Ich kann ja zum Testen STP einfach mal deaktivieren, dann weiß ich sicher ob es an STP liegt, oder?
Sonst musst du knallhart BPDU Protection einschalten auf allen Accessports wenn die NetGears sowas supporten.
BPDU Guard hatte ich nur am Core eingeschalten - die Access können das nichtAuf den Access-Switchen wird das Log mit sowas geflutet. Ist auf allen Access Switchen, wo VoIP Telefone hängen, hat LLDP-MED nicht was mit Aushandlung TK-Telefon zu tun? Wobei auf 1/g7 kein Telefon hängt...betrifft aber auch 1/g4, g3 usw.
<13> Apr 26 17:02:57 EDGE_SW_DV110-1 TRAPMGR[lldpTask]: traputil.c(763) 44054 %% LLDP-MED Topology Change Detected: ChassisIDSubtype: 4, ChassisID: 10:FE:ED:06:94:24, DeviceClass: 1, Interface: 1/g7
<13> Apr 26 17:02:34 EDGE_SW_DV110-1 TRAPMGR[lldpTask]: traputil.c(763) 44053 %% LLDP-MED Topology Change Detected: ChassisIDSubtype: 4, ChassisID: 10:FE:ED:06:94:24, DeviceClass: 1, Interface: 1/g7Das ist auch komisch - extrem viele Link Up/Down Events.
<13> Apr 26 14:12:25 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43881 %% Link Down: 1/g11
<13> Apr 26 14:12:14 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43879 %% Link Up: 1/g11
<13> Apr 26 14:12:12 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43877 %% Link Down: 1/g11
<13> Apr 26 14:01:59 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43873 %% Link Up: 1/g11
<13> Apr 26 14:01:56 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43871 %% Link Down: 1/g11
<13> Apr 26 14:01:50 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43869 %% Link Up: 1/g11
<13> Apr 26 14:01:48 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43867 %% Link Down: 1/g11
<13> Apr 26 13:51:35 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43865 %% Link Up: 1/g11
<13> Apr 26 13:51:33 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43863 %% Link Down: 1/g11
<13> Apr 26 13:51:19 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43861 %% Link Up: 1/g11
<13> Apr 26 13:51:17 EDGE_SW_DV110-1 TRAPMGR[trapTask]: traputil.c(721) 43859 %% Link Down: 1/g11Das sagt mir die STP Statistik am Core: (19, 25, 20 etc. sind BPDUs Received), der Rest BPDUs Transmitted.
lag 1 0 0 19 53330 0 0
lag 2 0 0 25 53340 0 0
lag 3 0 0 20 53330 0 0
lag 4 0 0 22 53338 0 0
lag 5 0 0 6 53311 0 0
lag 6 0 0 21 53331 0 0
lag 7 0 0 5305 48256 0 0
lag 8 0 0 48016 5323 0 0
lag 9 0 0 3 53300 0 0Dasselbe am Access Switch - auf 13-24 hängen die VoIP Telefone...
1/g1 0 0 0 6833 0 0
1/g2 0 0 0 299 0 0
1/g3 0 0 0 0 0 0
1/g4 0 0 0 0 0 0
1/g5 0 0 0 302314 0 0
1/g6 0 0 0 0 0 0
1/g7 0 0 0 0 0 0
1/g8 0 0 0 0 0 0
1/g9 0 0 0 0 0 0
1/g10 0 0 0 0 0 0
1/g11 0 0 0 0 0 0
1/g12 0 0 0 0 0 0
1/g13 0 0 0 234765 0 0
1/g14 0 0 0 233671 0 0
1/g15 0 0 0 233674 0 0
1/g16 0 0 0 234925 0 0
1/g17 0 0 0 234918 0 0
1/g18 0 0 0 234921 0 0
1/g19 0 0 0 234915 0 0
1/g20 0 0 0 234915 0 0
1/g21 0 0 0 234912 0 0
1/g22 0 0 0 234914 0 0
1/g23 0 0 0 0 0 0
1/g24 0 0 0 0 0 0Das ist ein Ausschnitt aus dem Switch, wo rein Server hängen:
<13> Apr 25 11:39:15 EDGE_SW_DV322-1 TRAPMGR[dot1s_task]: traputil.c(763) 25680 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Apr 25 11:39:14 EDGE_SW_DV322-1 TRAPMGR[dot1s_task]: traputil.c(763) 25679 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Apr 25 11:39:14 EDGE_SW_DV322-1 TRAPMGR[trapTask]: traputil.c(721) 25678 %% Unit 1 elected as the new STP root
<13> Apr 25 11:37:01 EDGE_SW_DV322-1 TRAPMGR[dot1s_task]: traputil.c(763) 25677 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Apr 25 11:36:59 EDGE_SW_DV322-1 TRAPMGR[dot1s_task]: traputil.c(763) 25676 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Apr 25 11:36:57 EDGE_SW_DV322-1 TRAPMGR[dot1s_task]: traputil.c(763) 25675 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Apr 25 11:36:27 EDGE_SW_DV322-1 TRAPMGR[dot1s_task]: traputil.c(763) 25673 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Apr 25 11:36:25 EDGE_SW_DV322-1 TRAPMGR[dot1s_task]: traputil.c(763) 25672 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Apr 25 11:36:25 EDGE_SW_DV322-1 TRAPMGR[trapTask]: traputil.c(721) 25671 %% Unit 1 elected as the new STP rootEin Switch wo PCs und Telefone hängen:
<13> Apr 26 17:24:07 EDGE_SW_DV320-3 DOT1S[dtlTask]: dot1s_txrx.c(1246) 37162 %% dot1sBpduReceive(): Invalid Forward Delay
<11> Apr 26 17:24:05 EDGE_SW_DV320-3 DOT1S[dtlTask]: dot1s_txrx.c(269) 37161 %% dot1sBpduReceive(): Discarding the BPDU, since it is an invalid BPDU type
<13> Apr 26 17:24:05 EDGE_SW_DV320-3 DOT1S[dtlTask]: dot1s_txrx.c(1246) 37160 %% dot1sBpduReceive(): Invalid Forward Delay
<11> Apr 26 17:23:59 EDGE_SW_DV320-3 DOT1S[dtlTask]: dot1s_txrx.c(269) 37159 %% dot1sBpduReceive(): Discarding the BPDU, since it is an invalid BPDU type
<13> Apr 26 17:23:59 EDGE_SW_DV320-3 DOT1S[dtlTask]: dot1s_txrx.c(1246) 37158 %% dot1sBpduReceive(): Invalid Forward Delay
<11> Apr 26 17:23:57 EDGE_SW_DV320-3 DOT1S[dtlTask]: dot1s_txrx.c(269) 37157 %% dot1sBpduReceive(): Discarding the BPDU, since it is an invalid BPDU type
<13> Apr 26 17:23:57 EDGE_SW_DV320-3 DOT1S[dtlTask]: dot1s_txrx.c(1246) 37156 %% dot1sBpduReceive(): Invalid Forward DelayIch kann aus den Logs nicht nachvollziehen, was da genau verquer läuft...Flutet da jemand den Switch mit Paketen und der fängt dann das berechnen der Topologie neu an? Die LAGs sind ja normal eingerichtet...der STP Traffic scheint überall so hoch zu sein somit kann ich das nicht eingrenzen.
Am Core hat sich STP anscheinend selbstständig folgendermaßen konfiguriert - STP Mode steht aktuell noch auf RSTP. Ich habe jetzt STP testweise auf allen Switchen global deaktiviert. Die Topologieänderungen sind nicht wenig...
Muss ich generell auf allen Switchen eine MSTP Instanz je VLAN anlegen? Der Core hat eine Prio von 4096. Muss STP auf allen Ports aktiviert sein, sprich am Core und Access auf allen Ports und LAGs?
Ich bin gespannt wie es nun mit deaktiviertem STP aussieht. Richtig konfigurieren möchte ich es auf jeden Fall zur Sicherheit, Macht ja Sinn.
@nochmehrofftopic
Den Gastzugang realisere ich über ein extra VLAN. ACLs sollen den Zugriff verbieten und nur I-net zulassen. Nun soll aber nur Zugriff auf wenige Internetseiten möglich sein. Ist das sicher genug, wenn ich am Gateway eine Webfilter-Policy anlege, die Traffic aus dem Gast VLAN per Whitelist nur auf einzelne Seiten zulässt - nicht aber ins ganze Internet?
ACL:
Nun ist dann auch mal die Konfig der ACLs an der Reihe
Bin ich nun gedanklich soweit richtig, dass ich am Core die entsprechenden IP ACLs mit Regeln anlege (z. B. Gast VLAN darf auf kein anderes VLAN Zugreifen, heißt (bei Netgear) 1 ACL und für die Trennung mehrere Rules). Anschließend weise ich in der VLAN Binding Table z. B. dem Gast VLAN mit der ID XXX INBOUND die IP ACL XXX zu. Was bedeuted Sequence Number - auf was muss ich da achten und kannst du mir noch den Unterscheid erklären, wann ich INBOUND und wann OUTBOUND gewählt werden muss? Ich weiß nur dass ich INBOUND wählen muss, aber nicht sicher WARUM 
Edit: Das Netzwerk läuft aktuell ohne STP ohne Fehler oder extrem langsame Verbindungen, d. h. ich gehe davon aus, dass keine Schleifen vorhanden sind. Was mir noch aufgefallen ist, dass der Broadcast received Zähler im Log auf allen Switchen auf den LAGs sehr hoch ist...Sowohl am Core als auch auf den Access Switchen. Das LAG ist aber standardmäßig eingerichtet. Im Schnitt sind 10% aller Received Packets Broadcasts der LAG Member..sind das vllt die LACP Pakete?
Wie oben gepostet, hänt jeder Access Switch mit je einer LWL Leitung auf den gestackten Core Switchen. Die jeweiligen 2 Ports am Core Stack und am Access Stack sind als LAG mit LACP konfiguriert. VLAN Trunking geht ja über die LAGs....woher kommen dann ausschließlich auf den LAGs die hohen Broadcasts?
Wie oben gepostet, hänt jeder Access Switch mit je einer LWL Leitung auf den gestackten Core Switchen. Die jeweiligen 2 Ports am Core Stack und am Access Stack sind als LAG mit LACP konfiguriert. VLAN Trunking geht ja über die LAGs....woher kommen dann ausschließlich auf den LAGs die hohen Broadcasts?
Was bezeichnen die Counter Werte STP Statistik in den Spalten 3 und 4 ??
Dort kommt ein falscher und inkompatibler BPDU Frame an. Sowas ist verdächtig. Da hängt irgendwas dran was vermutlich KEIN MSTP spricht !!
BPDU Updates kommen im Sekundentakt. Das bedeutet alle Sekunde dann einen Topochange wenn dort falsche BPDUs gesendet werden.
Noch erheblich sinnvoller ist es aber ein unsicheres Gast VLAN gar nicht IP seitig am Core zu konfigurieren sondern es als reines isoliertes Layer 2 VLAN Netzwerk zu definieren mait es gar nicht erst L3seitig am Core aufliegt und so potentiellen Zugang zu allen internen VLANs hast.
Das ist ein gravierender Sicherheits Nachteil wenn du mal einen Fehler in der ACL machen solltest.
In dieses VLAN sollte man als KEINE Core IP definieren sondern die Firewall oder den Gast Router / Captive Portal dort immer DIREKT anschliessen.
So vermeidet man ein potentielles Sicherheitsleck.
Mit der Whitelist ist der richtige Weg dann den Zugang zu steuern.
ACL wirken immer nur inbound und des gilt dort immer: "First match wins !"
Das weisst sowie es einen Hit in einer ACL gibt wird der Rest der ggf. noch vorhandenen Regeln NICHT mehr abgearbeitet. Will heissen du kannst oben nicht etwas verbieten was du unten wieder erlaubst und umgekehrt.
Ist auch logisch. Mit Hilfe der Sequence Number kannst du dann Regeln in einer ACL einfacher neu ordnen anstatt die ACL immer wieder neu eingeben zu müssen.
Vorsicht bei Outbound ACL. Die sind bei Billigswitches so gut wie immer über die CPU gesteuert und nicht in HW.
Wenn dann macht auch nur Inbound Sinn. Du willst ja schon Pakete vorher filtern BEVOR sie in deine Infrastruktur kommen und dort auch noch Traffic verursachen.
Outbound Filter machen also nur in Ausnahmefällen Sinn.
Hast du STP jetzt global ganz aus oder nur STP und MSTP rennt noch ?
Das sind aber reine Point zu Point Protokolle die logischerweise NICHT im Netzwerk geflutet werden.
dot1sBpduReceive(): Invalid Forward Delay
Was sagt der NG Support was genau DAS bedeutet ??Discarding the BPDU, since it is an invalid BPDU type
Oha....da haben wir es !!Dort kommt ein falscher und inkompatibler BPDU Frame an. Sowas ist verdächtig. Da hängt irgendwas dran was vermutlich KEIN MSTP spricht !!
Am Core hat sich STP anscheinend selbstständig folgendermaßen konfiguriert
Das ist unmöglich und Quatsch. Sowas gibt es im STP gar nicht.STP Mode steht aktuell noch auf RSTP
Das ist falsch, denn es müsste ja MSTP sein ! STP zu deaktivieren ist richtig sofern damit nur das alte STP gemeint ist und nicht Spanning Tree als ganzes.Die Topologieänderungen sind nicht wenig...
Das ist wohl richtig und das ist auch der fatale Fehler !!BPDU Updates kommen im Sekundentakt. Das bedeutet alle Sekunde dann einen Topochange wenn dort falsche BPDUs gesendet werden.
Den Gastzugang realisere ich über ein extra VLAN.
Das ist richtig und auch sinnvoll und gängige Praxis.dass ich am Core die entsprechenden IP ACLs mit Regeln anlege (z. B. Gast VLAN darf
Ja, das ist genau richtig, denn der Core ist der zentrale Router der den L3 Traffic handelt.Noch erheblich sinnvoller ist es aber ein unsicheres Gast VLAN gar nicht IP seitig am Core zu konfigurieren sondern es als reines isoliertes Layer 2 VLAN Netzwerk zu definieren mait es gar nicht erst L3seitig am Core aufliegt und so potentiellen Zugang zu allen internen VLANs hast.
Das ist ein gravierender Sicherheits Nachteil wenn du mal einen Fehler in der ACL machen solltest.
In dieses VLAN sollte man als KEINE Core IP definieren sondern die Firewall oder den Gast Router / Captive Portal dort immer DIREKT anschliessen.
So vermeidet man ein potentielles Sicherheitsleck.
Mit der Whitelist ist der richtige Weg dann den Zugang zu steuern.
Was bedeuted Sequence Number
Das ist die Sequenz Nummer der Regeln in einer ACL.ACL wirken immer nur inbound und des gilt dort immer: "First match wins !"
Das weisst sowie es einen Hit in einer ACL gibt wird der Rest der ggf. noch vorhandenen Regeln NICHT mehr abgearbeitet. Will heissen du kannst oben nicht etwas verbieten was du unten wieder erlaubst und umgekehrt.
Ist auch logisch. Mit Hilfe der Sequence Number kannst du dann Regeln in einer ACL einfacher neu ordnen anstatt die ACL immer wieder neu eingeben zu müssen.
Vorsicht bei Outbound ACL. Die sind bei Billigswitches so gut wie immer über die CPU gesteuert und nicht in HW.
Wenn dann macht auch nur Inbound Sinn. Du willst ja schon Pakete vorher filtern BEVOR sie in deine Infrastruktur kommen und dort auch noch Traffic verursachen.
Outbound Filter machen also nur in Ausnahmefällen Sinn.
Das Netzwerk läuft aktuell ohne STP ohne Fehler
Jetzt auch ohne Topo Changes ??Hast du STP jetzt global ganz aus oder nur STP und MSTP rennt noch ?
Im Schnitt sind 10% aller Received Packets Broadcasts der LAG Member..sind das vllt die LACP Pakete?
Ja, das kann ausschliesslich nur LACP sein. GGf. noch LLDP sofern das per Default aktiv ist.Das sind aber reine Point zu Point Protokolle die logischerweise NICHT im Netzwerk geflutet werden.
woher kommen dann ausschließlich auf den LAGs die hohen Broadcasts?
Sicherheit gibt dir da nur ein Sniffer Trace.
