Probleme mit Internet Cisco Switch
Hey Leute,
wir haben einen Coreswitch (sind mehrer gestackte Cisco Switch) im Serverraum stehen diese sind mit Etagen Switchen per Glas verbunden.
Seit ein paar Wochen haben wir das Problem das bei einigen Usern die Internetseiten sich sehr sehr langsam aufbauen. Es dauert mehrer Minuten bis eine Seite kommt.
Es ist OS und Hardware unabhängig. Auch wenn ich den Rechner an einen anderen Port hänge bleibt das verhalten. Was aber ohne Probleme Funktioniert ist die Verbindung zu den Servern.
Auf der Firewall sehe ich wenn die Rechner in Internet gehen das die Packete auf dem Port 80 beschädigt sind.
Kann mir nur nicht erklären warum.
Was etwas Abhilfe schaft ist einen anderen Rechner der normal läuft an den Port zu hängen wo es zu Problemen kommt und dann wieder den Rechner der ursprünglich da war. Dennach scheint alles wieder zu laufen.
Da das Problem an verschiedenen Etagen Switchen auftaucht kann es nur am Coreswitch hängen.
Habt ihr eine Idee was ich da machen könnte?
Der Cisco Coreswitch hat die Software Version 12.0
Könnte man vielleicht irgendwelche Caches auf dem Switch löschen ohne das die User was davon merken? mac-address-table oder sowas
Hoffe ihr könnt mir da helfen und weiß wirklich nicht wo ich ansetzen soll
wir haben einen Coreswitch (sind mehrer gestackte Cisco Switch) im Serverraum stehen diese sind mit Etagen Switchen per Glas verbunden.
Seit ein paar Wochen haben wir das Problem das bei einigen Usern die Internetseiten sich sehr sehr langsam aufbauen. Es dauert mehrer Minuten bis eine Seite kommt.
Es ist OS und Hardware unabhängig. Auch wenn ich den Rechner an einen anderen Port hänge bleibt das verhalten. Was aber ohne Probleme Funktioniert ist die Verbindung zu den Servern.
Auf der Firewall sehe ich wenn die Rechner in Internet gehen das die Packete auf dem Port 80 beschädigt sind.
Kann mir nur nicht erklären warum.
Was etwas Abhilfe schaft ist einen anderen Rechner der normal läuft an den Port zu hängen wo es zu Problemen kommt und dann wieder den Rechner der ursprünglich da war. Dennach scheint alles wieder zu laufen.
Da das Problem an verschiedenen Etagen Switchen auftaucht kann es nur am Coreswitch hängen.
Habt ihr eine Idee was ich da machen könnte?
Der Cisco Coreswitch hat die Software Version 12.0
Könnte man vielleicht irgendwelche Caches auf dem Switch löschen ohne das die User was davon merken? mac-address-table oder sowas
Hoffe ihr könnt mir da helfen und weiß wirklich nicht wo ich ansetzen soll
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 239002
Url: https://administrator.de/contentid/239002
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
44 Kommentare
Neuester Kommentar
Hmm, ohne jetzt den Aufbau des Netztes richtig zu kennen, würde ich dir pauschal zustimmen.
Ich geh mal beispielweise von folgendem Aufbau aus:
Coreswitch führt zu den Etagenswitchen; An E-Switch 1 hängen die Server und ein paar Clients; An allen anderen hängen nur Clients.
Würde bedeuten, dass bei Aufruf der Intranet-Seite von Etage 4 aus der weg also so wäre: Client -> E-Switch 4 -> Coreswitch -> E-Switch 1 -> Intranetserver
So in etwa richtig?
Wenn du die Möglichkeit hast würde ich mal nen anderen Switch/Hub zum testen nehmen. Auch wenn Hubs "dumm" sind, reicht es denke ich zum testen aus. Oder vielleicht andere Ports aufm Coreswitch konfigurieren und auf diese wechseln.
Ich geh mal beispielweise von folgendem Aufbau aus:
Coreswitch führt zu den Etagenswitchen; An E-Switch 1 hängen die Server und ein paar Clients; An allen anderen hängen nur Clients.
Würde bedeuten, dass bei Aufruf der Intranet-Seite von Etage 4 aus der weg also so wäre: Client -> E-Switch 4 -> Coreswitch -> E-Switch 1 -> Intranetserver
So in etwa richtig?
Wenn du die Möglichkeit hast würde ich mal nen anderen Switch/Hub zum testen nehmen. Auch wenn Hubs "dumm" sind, reicht es denke ich zum testen aus. Oder vielleicht andere Ports aufm Coreswitch konfigurieren und auf diese wechseln.
Moin,
hast du denn schon mal die Logs der Core- und Etagenswitche überprüft?
Im Problemfall solltest du auch den Netzwerkverkehr mit z.b. Wireshark prüfen um genauer einzugrenzen was/wo das Problem liegt.
lg
Slainte
hast du denn schon mal die Logs der Core- und Etagenswitche überprüft?
Im Problemfall solltest du auch den Netzwerkverkehr mit z.b. Wireshark prüfen um genauer einzugrenzen was/wo das Problem liegt.
Auf der Firewall sehe ich wenn die Rechner in Internet gehen das die Packete auf dem Port 80 beschädigt sind.
Was genau meinst du mit "beschädigt"? CRC Falsch? Dann ist die Frage auf welchem Layer usw...lg
Slainte
Hallo,
also die Sorge das die Cisco Switche nicht mehr hochfahren teile ich nicht.
Bei Allied Telesysn Switchen kenne ich das, aber bei Cisco habe ich da bisher keine Sorgen.
Zeigen den die Logfiles der Coreswitche irgendwelche Auffälligkeiten?
Werden da auch Paketfehler angezeigt?
Insbesondere am Edge Switch an dem die Clients direkt hängen?
Die Frage ist ja wo die Pakete kaputt gehen!
Gab es vor dem auftreten der Fehler andere Umbauarbeiten bei euch?
An der Elektrik? Neue Maschinen oder so was in der Richtung?
brammer
also die Sorge das die Cisco Switche nicht mehr hochfahren teile ich nicht.
Bei Allied Telesysn Switchen kenne ich das, aber bei Cisco habe ich da bisher keine Sorgen.
Zeigen den die Logfiles der Coreswitche irgendwelche Auffälligkeiten?
Werden da auch Paketfehler angezeigt?
Insbesondere am Edge Switch an dem die Clients direkt hängen?
Die Frage ist ja wo die Pakete kaputt gehen!
Gab es vor dem auftreten der Fehler andere Umbauarbeiten bei euch?
An der Elektrik? Neue Maschinen oder so was in der Richtung?
brammer
Ein Switch würde auf den Switchports so oder so keine corupted Frames weiterreichen wie zur seligen Hub Zeit. Das wäre also Blödsinn.
Sofern hier kein Spanning Tree Problem vorliegt ird es zu 90% nicht an den Switches liegen sondern die Ursache steckt sicher woanders.
Neukaufen hilft dann natürlich auch wenig...
Was das Rebooten anbetrifft kann man uneingeschränkt die Meinung des Kollegen brammer teilen sowas anzunehmen bei einem Premium Switch ist Blödsinn aber die Fragestellung an sich zeigt schon das der TO kein netzwerker ist sondern hier im freien Fall spekuliert. Solcherlei Probleme sind generell keine Infrastrukturprobleme aber das nur nebenbei.
Fazit: Switchlogs ansehen mit "show logg" nach Auffälligkeiten wie STP Loops usw. CPU last kontrollieren "sh cpu" oder "sh proc cpu" und genau diese Port identifizieren WO die Paketfehler auftreten. Dort ist meist auch das Endgerät dran was diese Fehler verursacht wie z.B. ein Ethernet Autonegotiation Problem (Speed und Duplex Mismatch !)
Nach sowas gilt es zu suchen, der Rest ist nur wildes Spekulieren das bekanntlich zu nix führt !
Sofern hier kein Spanning Tree Problem vorliegt ird es zu 90% nicht an den Switches liegen sondern die Ursache steckt sicher woanders.
Neukaufen hilft dann natürlich auch wenig...
Was das Rebooten anbetrifft kann man uneingeschränkt die Meinung des Kollegen brammer teilen sowas anzunehmen bei einem Premium Switch ist Blödsinn aber die Fragestellung an sich zeigt schon das der TO kein netzwerker ist sondern hier im freien Fall spekuliert. Solcherlei Probleme sind generell keine Infrastrukturprobleme aber das nur nebenbei.
Fazit: Switchlogs ansehen mit "show logg" nach Auffälligkeiten wie STP Loops usw. CPU last kontrollieren "sh cpu" oder "sh proc cpu" und genau diese Port identifizieren WO die Paketfehler auftreten. Dort ist meist auch das Endgerät dran was diese Fehler verursacht wie z.B. ein Ethernet Autonegotiation Problem (Speed und Duplex Mismatch !)
Nach sowas gilt es zu suchen, der Rest ist nur wildes Spekulieren das bekanntlich zu nix führt !
Hallo,
wenn die Server direkt an dem Ccore Switch
angeschlossen worden sind, ist das dann redundant
passiert? Wenn ja schau einfach mal nach ob ein Port
vom Intranetserver einfach nur durchgebrannt bzw.
beschädigten ist.
Gruß
Dobby
wenn die Server direkt an dem Ccore Switch
angeschlossen worden sind, ist das dann redundant
passiert? Wenn ja schau einfach mal nach ob ein Port
vom Intranetserver einfach nur durchgebrannt bzw.
beschädigten ist.
Gruß
Dobby
So einen ähnlichen Fall hatte ich auch mal.
HP Core-Switch über LWL an CISCO Etagen-Switche.
Von Heut auf Morgen war das gesamte Netzwerk sporadisch immer wieder total langsam. Jeweils so nach 30-60 Minuten war auf einmal alles wieder normal.
Als Verursacher stellte sich ein CISCO Etagenswitch herraus. War dieser nicht mehr am Netz, hat sich das Problem innerhalb ein paar Sekunden selbst "beseitigt".
Daraufhin haben wir diesen Switche ausgetauscht. Problem ist nicht mehr aufgetreten.
HP Core-Switch über LWL an CISCO Etagen-Switche.
Von Heut auf Morgen war das gesamte Netzwerk sporadisch immer wieder total langsam. Jeweils so nach 30-60 Minuten war auf einmal alles wieder normal.
Als Verursacher stellte sich ein CISCO Etagenswitch herraus. War dieser nicht mehr am Netz, hat sich das Problem innerhalb ein paar Sekunden selbst "beseitigt".
Daraufhin haben wir diesen Switche ausgetauscht. Problem ist nicht mehr aufgetreten.
Zitat von @erco123:
So einen ähnlichen Fall hatte ich auch mal.
HP Core-Switch über LWL an CISCO Etagen-Switche.
Als Verursacher stellte sich ein CISCO Etagenswitch herraus. War dieser nicht mehr am Netz, hat sich das Problem innerhalb ein
paar Sekunden selbst "beseitigt".
Daraufhin haben wir diesen Switche ausgetauscht. Problem ist nicht mehr aufgetreten.
Die Unverträglichkeiten von Cisco's und HP's (R/M)STP Implementationen sind bekannt und haben übringens mit dem Problem des TEs nichts zu tun, der hat nämlich eine CISCO-Only UmgebungSo einen ähnlichen Fall hatte ich auch mal.
HP Core-Switch über LWL an CISCO Etagen-Switche.
Als Verursacher stellte sich ein CISCO Etagenswitch herraus. War dieser nicht mehr am Netz, hat sich das Problem innerhalb ein
paar Sekunden selbst "beseitigt".
Daraufhin haben wir diesen Switche ausgetauscht. Problem ist nicht mehr aufgetreten.
Mag sein. Bei mir hat es aber ca. 5 Jahre Funktioniert. Nach Austausch des Defekten Switches läuft es jetzt seit 4 Jahren absolut störungsfrei. Auch Kombination HP und Cisco.
Will damit ja nur sagen, das ein Gerät, irgendwo im Netzwerk - wie, und weshalb auch immer - das ganze Netzwerk gestört hat. Selbst die Kommunikation über 2 Ports am Core Switch hat nicht mehr ordentlich funktioniert.
Will damit ja nur sagen, das ein Gerät, irgendwo im Netzwerk - wie, und weshalb auch immer - das ganze Netzwerk gestört hat. Selbst die Kommunikation über 2 Ports am Core Switch hat nicht mehr ordentlich funktioniert.
wie, und weshalb auch immer -
Diese Aussage zeigt ja schon das du nichtmal nachgesehen hast oder verstanden hast wo die Ursache ist oder sein könnte.... Keine guten Voraussetzungen für einen verantwortungsvollen Netzwerker Na ja, jeder Dummie weiss ja mittlerweile auch das die HP Billigswitches (ProCurve) kein Cisco PVST+ supporten weil HP generell überhaupt keine Art von Per VLAN Spanning Tree supportet.
Außer bei ihren zugekauften Huawei China H3C Schnüffelswitches.
Da Cisco PVSTP+ völlig andere Mac BPDU Adressen benutzt ist es nicht kompatibel zu HP (und vielen anderen die kein PVSTP+ supporten auch).
Bessere Hersteller supporten das und erkennen automatisch PVSTP+ BPDUs und konfigurieren dann ihre Uplink Ports entsprechend um so 100% kompatibel zu Ciscos STP Lösung zu sein.
Ergebnis wenn man das nicht macht oder nicht supportet ist sind dann langsame Netzwerke durch sporadische STP Loops oder der komplette Zusammenbruch des STPs. Was man aber mit nur sehr wenig Troubleshooting Einsatz sofort herausbekommt...wenn man denn weiss was man tut ?!
Jeder Netzwerker weiss das und erzwingt dann in der Cisco Konfig ein Single SPAN Verfahren wenn er zwangsweise üble HP Technik verbauen muss. Gute Netzwerk Admins wehren sich vorher dagegen
Dumm und nicht effizient in einem redundanten STP Netzwerk aber was will man machen wenn man billige HPs im Edge hat und Redundanz.
Da muss man eben auf HP Niveau runter oder hat das Ergebnis von oben....
Das ist aber hier genau nicht das Thema wie oben schon richtig angemerkt. Glücklicherweise ist hier (hoffentlich) kein HP ProCurve Schrott vorhanden sondern vermutlich nur eine Fehlkonfiguration oder ein defektes Endgerät.
Nunja - das Interesse von mir, und dem Kunden selber ist das das Netz wieder tut, und etwa 100 Leute wieder richtig arbeiten können.
Verursacher diagnostiziert, ausgetauscht, und damit alle zufrieden gestellt. Klar kann man sich noch Tage oder Wochen damit beschäftigen, hilft aber keinem, denn der Switch hat einen Defekt, den hat er jetzt auch noch.
Was soll man deiner Meinung nach machen?
Verursacher diagnostiziert, ausgetauscht, und damit alle zufrieden gestellt. Klar kann man sich noch Tage oder Wochen damit beschäftigen, hilft aber keinem, denn der Switch hat einen Defekt, den hat er jetzt auch noch.
Was soll man deiner Meinung nach machen?
Hallo,
Ich gehe weiterhin davon aus das die Switche nicht das Problem sind.
kannst du oder Kunde mit Sicherheit sagen das es außerhalb des Netzes keine Arbeiten gegeben hat die einen Einfluss haben ?
Kabelarbeiten?
Elektrische umbaumassnahmen?
Neuer Stromversorger?
Die falsch formatierten oder fehlerhaften Pakete am Router. Kannst du da mehr zu sagen?
Brammer
Ich gehe weiterhin davon aus das die Switche nicht das Problem sind.
kannst du oder Kunde mit Sicherheit sagen das es außerhalb des Netzes keine Arbeiten gegeben hat die einen Einfluss haben ?
Kabelarbeiten?
Elektrische umbaumassnahmen?
Neuer Stromversorger?
Die falsch formatierten oder fehlerhaften Pakete am Router. Kannst du da mehr zu sagen?
Brammer
Zitat von @aqui:
Na ja, jeder Dummie weiss ja mittlerweile auch das die HP Billigswitches (ProCurve) kein Cisco PVST+ supporten weil HP
generell überhaupt keine Art von Per VLAN Spanning Tree supportet.
Außer bei ihren zugekauften Huawei China H3C Schnüffelswitches.
Das ist so falsch wie vermessen, HP unterstützt mit MSTP sehr wohl schon seit ewigen Zeiten und auch vor der 3COM Übernahme per VLAN Spanning Tree. HP unterstützte zumindest "früher" grundsätzlich nur Technologien die auch standardisiert waren, daher auch kein propritäres PVST+.Na ja, jeder Dummie weiss ja mittlerweile auch das die HP Billigswitches (ProCurve) kein Cisco PVST+ supporten weil HP
generell überhaupt keine Art von Per VLAN Spanning Tree supportet.
Außer bei ihren zugekauften Huawei China H3C Schnüffelswitches.
Bessere Hersteller supporten das und erkennen automatisch PVSTP+ BPDUs und konfigurieren dann ihre Uplink Ports entsprechend um so
100% kompatibel zu Ciscos STP Lösung zu sein.
Bessere Hersteller supporten also eine von Cisco entwickelte und nicht standardisierte Technologie um kompatibel mit Cisco zu sein? Ich denke bessere Hersteller supporten Standards und kochen nicht ihr eigenes Süppchen.100% kompatibel zu Ciscos STP Lösung zu sein.
P.S.: bei Schnüffelswitchen fällt mir doch spontan Herr Snowden im Zusammenhang mit Cisco und der Post ein. Glashaus und so...
VG,
Thomas
(der im früheren Leben mal Procurve ASE war)
Zitat von @xbast1x:
Hast du ggfs. die Server neu gebootet? Wir haben des öftern Probleme, dass die Verbindung nur begrenzt möglich ist.
Nachdem Reboot der Cisco Anlage ist alles wieder i.o (kommt ungefähr alle 3 Monate vor)
Hast du ggfs. die Server neu gebootet? Wir haben des öftern Probleme, dass die Verbindung nur begrenzt möglich ist.
Nachdem Reboot der Cisco Anlage ist alles wieder i.o (kommt ungefähr alle 3 Monate vor)
Ich weiß nicht, was du da stehen hast - ich betreue einen großen Stapel an Cisco-Switches und Routern und alle haben eine Uptime von *mindestens* vier Jahren, die meisten laufen schon deutlich länger...
Zum Problem:
Sicher, dass es am Switch liegt? Ich würde eher behaupten, dass da die Netzwerkkarte der Firewall einen abbekommen hat oder kaputte Firmware/Treiber für die Netzwerkkarte geladen werden. Falls das eine Firewall mit Atheros-Chip ist: Das ist die Antwort auf dein Problem
Die Atheros-Dinger sind bekannt dafür, dass die nur eine begrenzte Zeit vernünftig laufen und dann Probleme wie Packetloss, hängende Netzwerkkarte u.s.w. auftreten.
Um das vernünftig herauszufinden solltest du dir den Switchport der Firewall auf dem Cisco auf einen anderen Port Mirroren ("Monitoren") und mit Wireshark zuschauen, ob die Pakete bereits defekt in den Switchport der Firewall geworfen werden. Notfalls auch mal den Switchport der Firewall und das Kabel tauschen.
Für LWL: Das sind optische Bauteile, die werden älter und irgendwann kann eine kritische "Dunkelheit" erreicht werden. Falls du am gemirrorten Port defekte Pakete siehst die ZUR Firewall geschickt werden, solltest du dir an allen infrage kommenden Uplinks die CRC-Counter ansehen und ggf. die GBIC- oder SFP-Module testweisen tauschen.
Das ist so falsch wie vermessen, HP unterstützt mit MSTP sehr wohl schon seit ewigen Zeiten und auch vor der 3COM Übernahme per VLAN Spanning Tree.
Falsch ist es nicht bzw. nicht ganz, vermessen mag man so sehen oder nicht. MSTP ist zwar ein PVSTP Verfahren kumuliert aber auch wieder mehrere STP Prozesse in Instanzen und ist damit nicht skalierbar. Zeigt außerdem welche Hardware HP einsetzt nd warum man deren Produkte in größeren Netzen nicht sieht.Auch MSTP funktioniert nicht wirklich mit PVSTP+ wie man hier genau nachlesen kann:
http://blog.ine.com/2010/02/22/understanding-mstp/
Die Conclusions dazu sprechen eine eindeutige Sprache ! Generell ist HP also unteres Mittelmaß aber für die Masse der KMU Anwender reicht das ja.
Generell stell sich ja die allgemeine Frage ob STP basierte Netzwerke eh noch eine Zukunft haben. Die Antwort darauf lautet sicher nein, denn mit SPB und TRILL in einer Ethernet Fabric läuten ja schon die Totenglocken für STP allgemein.
Aber auch hier wieder ohne HP was zeigt das sie Server und Laptops eben besser können als im Netzwerk innovativ zu sein. Da können sie wie immer nur billig also Commodity wie NetGear und D-Link.
Aber wie bereits gesagt der Masse der KMU Kunden reicht das vollends da sie keinerlei Ansprüche haben ans Netz. Ist wie Strom...dafür hat man ja auch eine Steckdose in der Wand !
Hallo nochmal,
Kompatibilitätsmodus, aber der funktioniert so weit ich informiert bin
auch nur bedingt bis hin zu gar nicht.
bin ich mir sicher dass STP, RSTP und auch das
MST noch längere Zeit weiter genutzt werden.
für das implementieren des Cisco PVST+, allerdings
muss man das für jeden Switch tun!!! Also nix mit Lizenz
kaufen und dann in alle Firmware sämtlicher Switche im
Sortiment aufnehmen, daher ist es zur Zeit noch auf die
XCM8800 Serie beschränkt, also die beiden Switche
XCM8810 & XCM8806. dafür aber komplett.
(TIER1,2 & TIER3), Nortel wurde von Avaya übernommen
und es wurde darüber debattiert ob man Netgear nicht auch
mit übernimmt und sie dann als KMU bzw. "Billigsparte"
unter eigener Regie laufen lässt. Netgear ist aber unter der
Vereinbahrung bzw. Absprache nur in einem gewissen
Marktsegment zu agieren und operieren in die
Eigenständigkeit entlassen worden und muss
nun selber zu sehen wie sie klar kommen.
Es ist aber damit zu rechnen das man bei Netgear
auch das SPB lizenziert und zumindest mit in die
XCM8800 Serie einfließen lässt, SPB ist ja auch
erst seit 2012 ein Standard und man wird sehen
ob er sich auch etablieren wird, also wie viel Avaya
dafür von den Herstellern haben möchte (Lizenzgebühren).
Das höchste der Gefühle ist eventuell noch der
XSM7224S oder die M7100 Serie in die man das
PVST+ mit einfließen lassen wird, aber bei dem
SPB könnte ich mir gut vorstellen das es demnächst
recht viele Switche aus dem Portfolio gibt die damit
ausgestattet werden.
Trill ist keine Option für Netgear, aus den bereits weiter
oben genannten Gründen, denn das ist eigentlich mehr
im Datacenter Bereich eine Option und nicht bei Netgear
mit Equipment für bis zu 300 Mitarbeitern.
Standards zu sein finde ich persönlich am besten,
daher würde ich mich sicher freuen, wenn recht viele
das SPB mit in Ihre Firmware einfließen lassen, aber
nur zusätzlich zu dem STP,RSTP, MSTP & PVST+.
Gruß
Dobby
Auch MSTP funktioniert nicht wirklich mit PVSTP+ wie
man hier genau nachlesen kann:
Es gibt bei einigen Anbietern bzw, Herstellern einen so genanntenman hier genau nachlesen kann:
Kompatibilitätsmodus, aber der funktioniert so weit ich informiert bin
auch nur bedingt bis hin zu gar nicht.
Generell stell sich ja die allgemeine Frage ob STP
basierte Netzwerke eh noch eine Zukunft haben.
Also für Kleinst-, kleine und mittlere Unternehmenbasierte Netzwerke eh noch eine Zukunft haben.
bin ich mir sicher dass STP, RSTP und auch das
MST noch längere Zeit weiter genutzt werden.
....also Commodity wie NetGear....
Die haben gerade verschiedene Lizenzen gezeichnetfür das implementieren des Cisco PVST+, allerdings
muss man das für jeden Switch tun!!! Also nix mit Lizenz
kaufen und dann in alle Firmware sämtlicher Switche im
Sortiment aufnehmen, daher ist es zur Zeit noch auf die
XCM8800 Serie beschränkt, also die beiden Switche
XCM8810 & XCM8806. dafür aber komplett.
....denn mit SPB und TRILL in einer Ethernet Fabric
SPB wurde von Nortell entwickelt und zwar für Carrier(TIER1,2 & TIER3), Nortel wurde von Avaya übernommen
und es wurde darüber debattiert ob man Netgear nicht auch
mit übernimmt und sie dann als KMU bzw. "Billigsparte"
unter eigener Regie laufen lässt. Netgear ist aber unter der
Vereinbahrung bzw. Absprache nur in einem gewissen
Marktsegment zu agieren und operieren in die
Eigenständigkeit entlassen worden und muss
nun selber zu sehen wie sie klar kommen.
Es ist aber damit zu rechnen das man bei Netgear
auch das SPB lizenziert und zumindest mit in die
XCM8800 Serie einfließen lässt, SPB ist ja auch
erst seit 2012 ein Standard und man wird sehen
ob er sich auch etablieren wird, also wie viel Avaya
dafür von den Herstellern haben möchte (Lizenzgebühren).
Das höchste der Gefühle ist eventuell noch der
XSM7224S oder die M7100 Serie in die man das
PVST+ mit einfließen lassen wird, aber bei dem
SPB könnte ich mir gut vorstellen das es demnächst
recht viele Switche aus dem Portfolio gibt die damit
ausgestattet werden.
Trill ist keine Option für Netgear, aus den bereits weiter
oben genannten Gründen, denn das ist eigentlich mehr
im Datacenter Bereich eine Option und nicht bei Netgear
mit Equipment für bis zu 300 Mitarbeitern.
läuten ja schon die Totenglocken für STP allgemein.
Mehr ist besser und kompatibel zu möglichst vielenStandards zu sein finde ich persönlich am besten,
daher würde ich mich sicher freuen, wenn recht viele
das SPB mit in Ihre Firmware einfließen lassen, aber
nur zusätzlich zu dem STP,RSTP, MSTP & PVST+.
Gruß
Dobby
Es gibt bei einigen Anbietern bzw, Herstellern einen so genannten Kompatibilitätsmodus, aber der funktioniert so weit ich informiert bin auch nur bedingt bis hin zu gar nicht.
Diese Aussage ist falsch, denn wenn der Hersteller dediziert PVSTP+ supportet wie z.B. Extreme oder Brocade etc. dann funktioniert das in der regel sauber und problemlos.NetGear kann es natürlich nicht...
SPB wurde von Nortell entwickelt und zwar für Carrier
http://de.wikipedia.org/wiki/IEEE_802.1aq
Als Nortel pleite ging gabs das noch nichtmal...
Das NetGear das implementiert ist wohl recht utopisch. Das ist ein Standard für größere Netze bzw. RZ Netze und dafür hat NetGear kein Produkt Portfolio. Außerdem...welcher verantwortungsvolle RZ Betreiber setzt im RZ NetGear ein...?? Deren Zielkunden sind ganz andere...deshalb ist auch TRILL keine Option. SPB und TRILL machen ja im Ergebnis mehr oder weniger das gleiche.
Was nun das Bessere ist von beiden, da streiten die Experten noch. Tendenzen gehen aber zu TRILL da das einfach mehr kann und flexibler ist.
...denn wenn der Hersteller dediziert PVSTP+ supportet...
Der Kompatibilitäts Modus bei Netgear hat nicht funktioniertund dann haben sie (Per VLAN Spanning Tree (PVST+) lizensiert
ich hoffe mal ganz stark das es sich um das selbe Protokoll
handelt und nun zumindest die größeren Switche der 8800 Serie
kompatibel zu den Cisco Switche sind.
Ist das nur eine andere Schreibweise oder auch ein anderes Protokoll?
Als Nortel pleite ging gabs das noch nichtmal...
Auszug aus dem original Text:SPB basiert auf einer Technik, die ursprünglich von Fachleuten von Nortel Networks für den Carrier-Bereich entwickelt wurde und nach der Insolvenz von Nortel zu Avaya gelangte. Seit März 2012 ist Shortest Path Bridging ein IEEE-Standard. .... weiter lesen
- Quellenhinweis
- TEC Channel
Gruß
Dobby
Der Kompatibilitäts Modus bei Netgear hat nicht funktioniert...
OK, vielleict bei NetGear nicht weiter verwunderlich Bei den anderen klappt es fehlerlos.Wo genau die Unterschiede in den PVSTP BPDU Adressen sind kannst du hier genau nachlesen:
http://cciethebeginning.wordpress.com/2008/10/15/differences-between-pv ...
Holla....NetGear kann auch groß...
http://www.netgear.com/images/XCM88000_09Mar11HR18-31485.pdf
OK, da steht PVSTP+ das sieht vielversprechend aus... Würd ich aber sicherheitshalber nochmal nachfragen ob sie auch wirklich 0100.0CCC.CCCD BPDUs verstehen ?!
Was die Nortel SPB Historie anbetrifft hast du Recht....sorry. Allerdings war das nur ein Draft und nicht der nachher entwickelte IEEE Standard.
Wo genau die Unterschiede in den PVSTP BPDU
Adressen sind kannst du hier genau nachlesen:
Ich habe mich da wohl ein wenig unverständlichAdressen sind kannst du hier genau nachlesen:
bzw. unglücklich ausgedrückt:
Ist das was Du geschrieben hast (PVSTP+) und was
in der Netgear Beschreibung steht (PVST+) ein und das selbe
Protokoll? Oder nicht? So meinte ich das.
Was die Nortel SPB Historie anbetrifft hast du Recht
Hätte ja auch anders sein können, denn den Autorkenne ich ja auch nicht persönlich!!
Holla....NetGear kann auch groß...
Auch bei vielen kleinen und mittlerenBetrieben wird es mitunter eng im Netzwerk
und man muss größere SAN bzw. Storage
Lösungen anbinden, die Switche arbeiten
aber nur mit einer internen Geschwindigkeit
von 10 GBit/s, also nichts wildes.
PVSTP+ haben sie schon einmal und auf eines
der folgenden warte ich dieses Jahr auch noch:
VCStack/VCCP
EPSR
SPB
TRILL ist aufwendiger bietet aber mehr
nur das werde ich wohl bei Netgear nicht
zu sehen bekommen.
Gruß
Dobby
wollte vielleich die Macadresstable mit clear mac-address-table leeren.
Eher ein laienhafter und hilfloser Versuch ohne Grund der auch vermutlich nicht helfen wird !Du kannst das on the fly machen, denn die Mac Tabelle füllt sich beim ersten Paket wieder. Nur mal nebenbei gefragt: Weisst du überhaupt WAS die Mac Adress Tabelle des Switches ist, was sie bewirkt und wie der Switch sie anlegt und verwaltet ?
Nach der Fragestellung zu urteilen vermutlich nicht
Was kann das nur sein.
Warum nimmst du nicht endlich mal einen kostenlosen Wireshark zur Hand, definierst einen Mirror Port für den PC und snifferst das Verhalten mal mit....dann siehst du doch gleich woran es liegt.Oder minimal siehst dir mit "show logg" mal das Log des Switches an ob dort etwas auffälliges wie Topo Changes, Broadcast Stürme, Loops usw. usw. zu sehen sind ?!
Oder...mit "show int xyz" mal die Port Statistiken der betroffenen Ports ob dort Auffälligkeiten /error, CRC Fehler, Runts usw. usw,) zu sehen sind.
Von dir kommt hier ja nichts Konkretes außer wilder Raterei und Spekualtionen im freien Fall...sorry !
Zitat von @homermg:
Mit Wireshark bin ich schon dran habe nur nur bis jetzt nichts feststellen können da ich auch nicht lange an die Betroffene
Rechner dran kann.
Mit Wireshark bin ich schon dran habe nur nur bis jetzt nichts feststellen können da ich auch nicht lange an die Betroffene
Rechner dran kann.
Das schöne an Wireshark und dem Mirror Port ist ja das du gar nicht an den betroffenen Rechner ran mußt sondern das ganze von (d)einem Rechner parallel beobachten kannst. Hast du denn einen Mirrorport konfiguriert?
VG,
Thomas
Hallo,
Kannst du mit Sicherheit ausschließen das es an der Netzwerkinfrastruktur oder den Rahmenbedingungen liegt???
brammer
Kannst du mit Sicherheit ausschließen das es an der Netzwerkinfrastruktur oder den Rahmenbedingungen liegt???
kannst du oder Kunde mit Sicherheit sagen das es außerhalb des Netzes keine Arbeiten gegeben hat die einen Einfluss haben ?
Kabelarbeiten?
Elektrische umbaumassnahmen?
Neuer Stromversorger?
Die falsch formatierten oder fehlerhaften Pakete am Router. Kannst du da mehr zu sagen?
Kabelarbeiten?
Elektrische umbaumassnahmen?
Neuer Stromversorger?
Die falsch formatierten oder fehlerhaften Pakete am Router. Kannst du da mehr zu sagen?
brammer
So nun mal "Butter bei die Fische" bitte,
es kann auf der einen Seite nicht sein das alles in Ordnung
ist mit den PCs und dem Switch, wenn das von Dir genannte
Verhalten sich so zuträgt!
Wenn Du denn einen PC vom Switch abnimmst und dann einen
anderen PC für kurze Zeit ansteckst und nach dem Umstecken
dann wieder alles läuft für eine gewissen Zeit (lease time), dann
würde ich einmal folgende Geräte näher einkreisen wollen.
Zumindest habe ich das bis dato so verstanden!
- Switch Port kaputt oder (statischer Knall)
- Switch Port falsch konfiguriert (VLAN, ACL, Loop)
- LAN Port am PC kaputt (statischen Knall oder Staub drin)
- PC Selber kaputt (Elko durchgeschmort)
- Kabel des einen PCs kaputt (Kabelbruch)
- IP des PCs doppelt vergeben oder MAC doppelt vorhanden
So und in der Regel setzt man sich dann an seine
Adminkonsole, einen freien PC, ein extra starkes Notebook
oder an einen kleinen Server mit Linux drauf hin und schmeißt
WireShark an und auf dem besagten Switch konfiguriert man
einen so genannten Monitorport bzw. mirrored Port und lässt
sich dann mittels WireSharl alles anzeigen, Vorsicht bei
schwachen PCs, Laptops oder Servern ist es ratsam die Datei
in die der WireShark die Daten schreibt sollte dann nicht größer
als 2 GB sein!!!
Kein Filter im WireShark anlegen und alles aufzeichnen,
und wenn es dann zu dem besagtem Verhalten kommt,
gleich melden lassen und auf die Uhr schauen sonst muss
man die ganzen Dateien alle durchsehen und das will in der
Regel niemand.
Wenn ich mir die zeit anschaue die man für das Schreiben
dieses Beitrags benötigt hat wäre das Thema wahrscheinlich
schon durch!
Wichtig ist das die betreffende Person bzw. der Mitarbeiter
sich zeitnah meldet und nicht erst in die Kantine zum Essen
geht!!!
Gruß
Dobby
es kann auf der einen Seite nicht sein das alles in Ordnung
ist mit den PCs und dem Switch, wenn das von Dir genannte
Verhalten sich so zuträgt!
Wenn Du denn einen PC vom Switch abnimmst und dann einen
anderen PC für kurze Zeit ansteckst und nach dem Umstecken
dann wieder alles läuft für eine gewissen Zeit (lease time), dann
würde ich einmal folgende Geräte näher einkreisen wollen.
Zumindest habe ich das bis dato so verstanden!
- Switch Port kaputt oder (statischer Knall)
- Switch Port falsch konfiguriert (VLAN, ACL, Loop)
- LAN Port am PC kaputt (statischen Knall oder Staub drin)
- PC Selber kaputt (Elko durchgeschmort)
- Kabel des einen PCs kaputt (Kabelbruch)
- IP des PCs doppelt vergeben oder MAC doppelt vorhanden
So und in der Regel setzt man sich dann an seine
Adminkonsole, einen freien PC, ein extra starkes Notebook
oder an einen kleinen Server mit Linux drauf hin und schmeißt
WireShark an und auf dem besagten Switch konfiguriert man
einen so genannten Monitorport bzw. mirrored Port und lässt
sich dann mittels WireSharl alles anzeigen, Vorsicht bei
schwachen PCs, Laptops oder Servern ist es ratsam die Datei
in die der WireShark die Daten schreibt sollte dann nicht größer
als 2 GB sein!!!
Kein Filter im WireShark anlegen und alles aufzeichnen,
und wenn es dann zu dem besagtem Verhalten kommt,
gleich melden lassen und auf die Uhr schauen sonst muss
man die ganzen Dateien alle durchsehen und das will in der
Regel niemand.
Wenn ich mir die zeit anschaue die man für das Schreiben
dieses Beitrags benötigt hat wäre das Thema wahrscheinlich
schon durch!
Wichtig ist das die betreffende Person bzw. der Mitarbeiter
sich zeitnah meldet und nicht erst in die Kantine zum Essen
geht!!!
Gruß
Dobby
Hallo,
Du gehst immer noch von vielen Fehlerquellen aus, die vorhanden
sein müssen, da es ja überall zu Fehlern kommt.
Freunde Dich bitte auch einmal damit an, das es nur ein Fehler sein
kann und dann das restliche Netzwerk bzw. Teile davon in
Mitleidenschaft zieht!
vorkommt die wiedrum natürlich an verschieden Ports auf
dem Coreswitch hängen
Ist der Port beschädigt und lässt noch Pakete durch
die verstümmelt werden kann sich das auf das gesamte
Netzwerk auswirken.
mehreren Switche und.....
Ist durch einen Tippfehler eine IP Adresse doppelt
wird der Port abgeschaltet um einen Loop bzw. einen
Adresskonflikt zu beseitigen. Und wenn nun der andere
PC angesteckt wird bekommt der einen andere Adresse
und es geht dann so lange gut bis die "lease time" abläuft.
gleichzeitig.....
Ist ein LAN Port an einem PC kaputt kann auch dieser das
gesamte Netzwerk stören!
Clients ja dieses normalerweise melden.
??? Wo melden die sich denn bei Euch?
Gruß
Dobby
Du gehst immer noch von vielen Fehlerquellen aus, die vorhanden
sein müssen, da es ja überall zu Fehlern kommt.
Freunde Dich bitte auch einmal damit an, das es nur ein Fehler sein
kann und dann das restliche Netzwerk bzw. Teile davon in
Mitleidenschaft zieht!
- Switch Port kaputt oder (statischer Knall)
Kann nicht sein da es ja bei mehreren Etagen Switchenvorkommt die wiedrum natürlich an verschieden Ports auf
dem Coreswitch hängen
die verstümmelt werden kann sich das auf das gesamte
Netzwerk auswirken.
- Switch Port falsch konfiguriert (VLAN, ACL, Loop)
Kann ich mir nicht vorstellen da es wie gesagt anmehreren Switche und.....
Ist durch einen Tippfehler eine IP Adresse doppelt
wird der Port abgeschaltet um einen Loop bzw. einen
Adresskonflikt zu beseitigen. Und wenn nun der andere
PC angesteckt wird bekommt der einen andere Adresse
und es geht dann so lange gut bis die "lease time" abläuft.
LAN Port am PC kaputt (statischen Knall oder Staub drin)
& - PC Selber kaputt (Elko durchgeschmort)
sehr unwahrscheinlich dann müsste das ja bei vielen Clients& - PC Selber kaputt (Elko durchgeschmort)
gleichzeitig.....
gesamte Netzwerk stören!
IP des PCs doppelt vergeben oder MAC doppelt vorhanden
das könnte ich mal checken! habe nicht dran gedacht da dieClients ja dieses normalerweise melden.
Mac Adresse doppelt kann doch nicht wirklich sein solange
es nicht virtuelle Clients sind oder sehe ich das falsch?
Ja das siehst Du falsch.es nicht virtuelle Clients sind oder sehe ich das falsch?
Gruß
Dobby
In diesem Fall sieht der Coreswitch wo alles zusammenläuft das die Macadresse des Clients 2x existiert. Dann steht in den Logs auf dem Switch soweit ich mich Erinnern kann irgendwas mit mac flap.
Das kannst du ganz einfach fixen indem du den Mac address aging timer etwas reduzierst. Damit timen die Mac Adressen schneller aus und diese Flapping Errors werden verhindert:"show mac address-table aging-time" zeigt was eingestellt ist und diese Zeit verringerst du dann halt mit dem entsprechenden Kommando auf den betroffenen Switches wo die APs dran hängen.