14
Wireshark Malformed Packet
Hallo,
ich versuche einem Problem auf die Spur zu kommen, das aus mehreren kleinen Problem zu bestehen scheint. Sozusagen eine Matroschka unter den Problemen.
Folgendes:
Grober Aufbau...
In VLAN 10 befinden sich etwa 10 Rechner die auf einen Datenbankserver (Firebird DB SuperServer 3.0) per OBDC-Treiber zugreifen. Nun passiert es immer wieder das Anwender auf bestimmte Datensätze nicht mehr zugreifen können und es im firebird.log zum Fehler "read errno = 10054". Das lässt darauf schließen das der Firebird-Prozess auf ein Commit wartet, das aber nicht mehr kommt, da der Client die Verbindung verloren hat. Dies endet damit, das die Datenbank einen Lock erfährt.
Ich konnte zwar mittlerweile durch Optimierung des Firebird-Servers die Performance verbessern und die Symptome weitestgehend lindern, doch gibt es immer noch vereinzelt das Problem. Meist kann dies dann kurzfristig nur durch einen Neustart des Firebird-Servers behoben werden. Mittlerweile denke ich das es noch zusätzlich ein Netzwerk-Problem gibt.
Leider ist das Log nicht wirklich ergiebig und die Möglichkeiten mit Firebird sehr eingeschränkt. Es gibt dort keine, zumindest mir nicht bekannte, Möglichkeit herauszufinden welcher Rechner genau das Problem hat.
Auf dem DB-Server habe ich dann mit Wireshark einen Mitschnitt erstellt, ungefähr 25 Minuten... Experteninformation:
Es wurden nur die Aktivitäten auf Port TCP 3050 mitgeschnitten. Die Malformed Packets bestehen in beide Richtungen zu und von fast allen Clients. Deshalb schließe ich mittlerweile eine Fehlkonfiguration oder einen Defekt eines Switches nicht aus. Aber auch eine fehlerhafte Client-Software wäre möglich.
Bin mir nicht sicher ob das der Fehler ist den ich suche und ob es sich überhaupt um ein Problem handelt. Beim SMPP scheint es normal zu sein, da hier meist das Packet mit dem letzten Fragment der Übertragung angezeigt wird.
Auf den Access-Switchen (SG200 und SG350X, siehe Zeichnung) sind keine Fehler auf den Schnittstellen vorhanden. Selbes Bild auf dem Brocade, jeweils die Schnittstelle vom Server und den Uplinks zu den Access-Switchen geprüft. Hier mal ein Auszug von der Schnittstelle des Servers:
Statistik
Die Auslastung steigt über den Tag kaum auf über 2%. DSCP/QoS ist auf der Schnittstelle des Servers, der Switche und der Clients aktiviert. Die Pakete auf Port 3050 sind aber derzeit nicht markiert. Die LWL-Uplinks sind ebenfalls kaum beansprucht. Habe die Windows Firewall zu Testzwecken deaktiviert, aber keine Veränderung. Da sich der Server ebenfalls im VLAN 10 befindet und somit sich alles im selben L2-Segment abspielt, sehe ich den pfSense weniger als Problem.
Latenzen mit ICMP und DSCP 0 zum entferntesten Rechner bei 0,62ms mit 500x 4K-Blöcken übertragen. Durchsatz bei 110MB/s.
Patchkabel der Client-Arbeitsplätze weitestgehend erneuert. Treiber up-to-date. Rechner sind etwas betagt, aber jetzt auch nicht "Asbach Uralt".
Nächste Maßnahme wäre ein Mitschnitt auf einem Client-Rechner, aber da ich es nicht eingrenzen kann, wäre das ins "Blaue" raten.
Was könnte man noch prüfen? Sind die angezeigten Fehler überhaupt ein Problem?
Gruß
ich versuche einem Problem auf die Spur zu kommen, das aus mehreren kleinen Problem zu bestehen scheint. Sozusagen eine Matroschka unter den Problemen.
Folgendes:
Grober Aufbau...
In VLAN 10 befinden sich etwa 10 Rechner die auf einen Datenbankserver (Firebird DB SuperServer 3.0) per OBDC-Treiber zugreifen. Nun passiert es immer wieder das Anwender auf bestimmte Datensätze nicht mehr zugreifen können und es im firebird.log zum Fehler "read errno = 10054". Das lässt darauf schließen das der Firebird-Prozess auf ein Commit wartet, das aber nicht mehr kommt, da der Client die Verbindung verloren hat. Dies endet damit, das die Datenbank einen Lock erfährt.
Ich konnte zwar mittlerweile durch Optimierung des Firebird-Servers die Performance verbessern und die Symptome weitestgehend lindern, doch gibt es immer noch vereinzelt das Problem. Meist kann dies dann kurzfristig nur durch einen Neustart des Firebird-Servers behoben werden. Mittlerweile denke ich das es noch zusätzlich ein Netzwerk-Problem gibt.
Leider ist das Log nicht wirklich ergiebig und die Möglichkeiten mit Firebird sehr eingeschränkt. Es gibt dort keine, zumindest mir nicht bekannte, Möglichkeit herauszufinden welcher Rechner genau das Problem hat.
Auf dem DB-Server habe ich dann mit Wireshark einen Mitschnitt erstellt, ungefähr 25 Minuten... Experteninformation:
Es wurden nur die Aktivitäten auf Port TCP 3050 mitgeschnitten. Die Malformed Packets bestehen in beide Richtungen zu und von fast allen Clients. Deshalb schließe ich mittlerweile eine Fehlkonfiguration oder einen Defekt eines Switches nicht aus. Aber auch eine fehlerhafte Client-Software wäre möglich.
Bin mir nicht sicher ob das der Fehler ist den ich suche und ob es sich überhaupt um ein Problem handelt. Beim SMPP scheint es normal zu sein, da hier meist das Packet mit dem letzten Fragment der Übertragung angezeigt wird.
Auf den Access-Switchen (SG200 und SG350X, siehe Zeichnung) sind keine Fehler auf den Schnittstellen vorhanden. Selbes Bild auf dem Brocade, jeweils die Schnittstelle vom Server und den Uplinks zu den Access-Switchen geprüft. Hier mal ein Auszug von der Schnittstelle des Servers:
SSH@ICX7250-24 Switch#sh int e 1/1/6
GigabitEthernet1/1/6 is up, line protocol is up
Port up for 5 hour(s) 21 minute(s) 13 second(s)
Hardware is GigabitEthernet, address is 609c.9fXX.XXXX (bia 609c.9fXX.XXXX)
Configured speed 1Gbit, actual 1Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual MDIX
EEE Feature Disabled
Member of L2 VLAN ID 10, port is untagged, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
Flow Control is config enabled, oper enabled, negotiation disabled
Mirror disabled, Monitor disabled
Mac-notification is disabled
Not member of any active trunks
Not member of any configured trunks
Port name is firebird
IPG MII 96 bits-time, IPG GMII 96 bits-time
MTU 1500 bytes
MMU Mode is Store-and-forward
300 second input rate: 3901264 bits/sec, 565 packets/sec, 0.39% utilization
300 second output rate: 611352 bits/sec, 375 packets/sec, 0.06% utilization
20427754 packets input, 19514919625 bytes, 0 no buffer
Received 94 broadcasts, 902 multicasts, 20426758 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
12326764 packets output, 2104320437 bytes, 0 underruns
Transmitted 4505 broadcasts, 29751 multicasts, 12292508 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Protected: No
MAC Port Security: Disabled
UC Egress queues:
Queue counters Queued packets Dropped Packets
0 12287379 0
1 325 0
2 31 0
3 0 0
4 4099 0
5 7 0
6 3 0
7 9934 0
MC Egress queues:
Queue counters Queued packets Dropped Packets
0 15435 0
1 178 0
2 9373 0
3 0 0Statistik
SSH@ICX7250-24 Switch#sh statistics e 1/1/6
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC Name
1/1/6 Up Forward Full 1G None No 10 0 609c.9fXX.XXXX firebird
Port 1/1/6 Counters:
InOctets 19565903357 OutOctets 2111934779
InPkts 20485226 OutPkts 12363506
InBroadcastPkts 94 OutBroadcastPkts 4512
InMulticastPkts 904 OutMulticastPkts 29848
InUnicastPkts 20484228 OutUnicastPkts 12329146
InBadPkts 0
InFragments 0
InDiscards 0 OutErrors 0
CRC 0 Collisions 0
InErrors 0 LateCollisions 0
InGiantPkts 0
InShortPkts 0
InJabber 0 OutDiscards 0
InFlowCtrlPkts 0 OutFlowCtrlPkts 0
InBitsPerSec 4474592 OutBitsPerSec 715128
InPktsPerSec 645 OutPktsPerSec 427
InUtilization 0.45% OutUtilization 0.07%Die Auslastung steigt über den Tag kaum auf über 2%. DSCP/QoS ist auf der Schnittstelle des Servers, der Switche und der Clients aktiviert. Die Pakete auf Port 3050 sind aber derzeit nicht markiert. Die LWL-Uplinks sind ebenfalls kaum beansprucht. Habe die Windows Firewall zu Testzwecken deaktiviert, aber keine Veränderung. Da sich der Server ebenfalls im VLAN 10 befindet und somit sich alles im selben L2-Segment abspielt, sehe ich den pfSense weniger als Problem.
Latenzen mit ICMP und DSCP 0 zum entferntesten Rechner bei 0,62ms mit 500x 4K-Blöcken übertragen. Durchsatz bei 110MB/s.
Patchkabel der Client-Arbeitsplätze weitestgehend erneuert. Treiber up-to-date. Rechner sind etwas betagt, aber jetzt auch nicht "Asbach Uralt".
Nächste Maßnahme wäre ein Mitschnitt auf einem Client-Rechner, aber da ich es nicht eingrenzen kann, wäre das ins "Blaue" raten.
Was könnte man noch prüfen? Sind die angezeigten Fehler überhaupt ein Problem?
Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 634277
Url: https://administrator.de/contentid/634277
Printed on: April 25, 2024 at 08:04 o'clock
14 Comments
Latest comment
Vorab ein paar Fragen zur Infrastruktur an sich:
- Ist das VLAN 10 vom Server Netz (Firebird) segementiert ? Wenn ja, wer routet ?
- Gibt es redundante Links ? Wenn ja nutzt du Spanning Tree und welchen STP ?
- Wenn STP hast du beachtet das der ICX ein inkompatibles Spanning Tree zum Cisco benutzt und das entsprechende angepasst bzw. berücksichtigt ?
Zitat von @aqui:
Vorab ein paar Fragen zur Infrastruktur an sich:
Vorab ein paar Fragen zur Infrastruktur an sich:
- Ist das VLAN 10 vom Server Netz (Firebird) segementiert ? Wenn ja, wer routet ?
Nein, ist nicht segmentiert. Server und Arbeitsplätze befinden sich im selben Subnetz im selben VLAN.
* Gibt es redundante Links ? Wenn ja nutzt du Spanning Tree und welchen STP ?
Redundate Links zu den Access-Switchen gibt es nicht. Allerdings wurde die Konfiguration dahingehend vorbereitet:
Auf dem Brocade:
vlan 10 by port
tagged ethe 1/2/2 ethe 1/2/6
untagged ethe 1/1/6
spanning-tree
!
!
spanning-tree single 802-1w
spanning-tree single 802-1w priority 4096
no fast port-spanAuf den Ciscos ist konfiguriert:
Spanning Tree State enable
STP Operation Mode Rapid STP
Priority 32768
* Wenn STP hast du beachtet das der ICX ein inkompatibles Spanning Tree zum Cisco benutzt und das entsprechende angepasst bzw. berücksichtigt ?
.
.
Ja, siehe vorhergehend.
Nein, ist nicht segmentiert.
Also ein komplett flaches, dummes Netz. Hoffentlich liegst du dann bei nicht mehr als 100, max. 150 Clients pro Netz. Wenn mehr wäre eine Segmentierung natürlich sinnvoller.STP ist auch OK, das kann man ausschliessen
Switches sind alle auf dem aktuellen bzw. recommended Release ?
- ICX 8.0.90h (h Patch !)
- SG350X 2.5.5.47
- SG200 1.4.11.5
Solche Fehler sind immer nicht ganz einfach. Um die bestehende Infrastruktur wirklich vollständig ausschliessen zu können müsstest du 1 oder 2 Testclients einmal direkt an den Server patchen und vergleichen.
Malformed Pakete sind auch nicht immer zwingend ein Netzwerk Fehler sondern könnten auch simple Anzeige Fehler sein:
https://www.wireshark.org/docs/wsug_html_chunked/AppMessages.html#_malfo ...
In diesem VLAN bin ich bei knapp 20 Geräten. Also alles im Rahmen.
Der Brocade ist bei 08.0.70g von Ende 2019, also noch nicht so alt.
Der SG350X ist aktuell
Der SG200 ist eine ganze Ecke weg von aktuell, den werde ich den kommenden Minuten aktualisieren.
Der Brocade ist bei 08.0.70g von Ende 2019, also noch nicht so alt.
Der SG350X ist aktuell
Der SG200 ist eine ganze Ecke weg von aktuell, den werde ich den kommenden Minuten aktualisieren.
Habe den SG200 jetzt auf der aktuellen Version 1.4.11.5
Leider hat er etwas Widerstand geleistet. Da er noch einen alten Boot Code drauf hatte, konnte ich nicht direkt auf eine 1.4x Version springen. Beim Boot Code Upgrade hat er sich nach dem Neustart erstmal verabschiedet. Er kam nicht mehr hoch. Habe dann einen Factory Reset durchgeführt und die Backup Config geladen. Danach war auch der aktuelle Boot Code drauf, warum er aber nicht mehr geschafft hat neuzustarten, bleibt mir schleierhaft. Ein stromlos machen und anschließendes Starten half auch nichts.
Erst, wie bereits beschrieben, der Reset brachte den Erfolg.
Wie verhält sich das eigentlich mit einem Update beim Brocade/Ruckus ICX? In den neueren Versionen ab 08.0.90 wurde ja einiges verändert, kann man das drüber bügeln? Was ist mit alten Funktionen wie "dual-mode" die es in den neuen Versionen nicht mehr gibt, werden die Konfigurationen migriert oder muss man diese vorher anpassen?
Leider hat er etwas Widerstand geleistet. Da er noch einen alten Boot Code drauf hatte, konnte ich nicht direkt auf eine 1.4x Version springen. Beim Boot Code Upgrade hat er sich nach dem Neustart erstmal verabschiedet. Er kam nicht mehr hoch. Habe dann einen Factory Reset durchgeführt und die Backup Config geladen. Danach war auch der aktuelle Boot Code drauf, warum er aber nicht mehr geschafft hat neuzustarten, bleibt mir schleierhaft. Ein stromlos machen und anschließendes Starten half auch nichts.
Erst, wie bereits beschrieben, der Reset brachte den Erfolg.
Wie verhält sich das eigentlich mit einem Update beim Brocade/Ruckus ICX? In den neueren Versionen ab 08.0.90 wurde ja einiges verändert, kann man das drüber bügeln? Was ist mit alten Funktionen wie "dual-mode" die es in den neuen Versionen nicht mehr gibt, werden die Konfigurationen migriert oder muss man diese vorher anpassen?
Also die Firmware-Updates haben nichts gebracht. Das Problem besteht weiterhin. Ist auch total sporadisch und folgt keinem Muster. Es ist zum Mäuse melken!
Gestern den ganzen Nachmittag nichts. Dann heute Vormittag, und jetzt am Nachmittag zwei Mal innerhalb von 20 Minuten. Ich verstehe es nicht. Es könnte im Prinzip alles sein, wenn ich so drüber nachdenke. Von den Betriebssystem des Servers und der Clients, bis hin zum Netzwerk oder der Application. Ein defektes Kabel, eine defekte Netzwerkschnittstelle, ein blöder Treiber.
Ich werde jetzt nochmal einen Stresstest über das Netzwerk machen und schauen was als erstes nach gibt.
Gestern den ganzen Nachmittag nichts. Dann heute Vormittag, und jetzt am Nachmittag zwei Mal innerhalb von 20 Minuten. Ich verstehe es nicht. Es könnte im Prinzip alles sein, wenn ich so drüber nachdenke. Von den Betriebssystem des Servers und der Clients, bis hin zum Netzwerk oder der Application. Ein defektes Kabel, eine defekte Netzwerkschnittstelle, ein blöder Treiber.
Ich werde jetzt nochmal einen Stresstest über das Netzwerk machen und schauen was als erstes nach gibt.
Du solltest dringenst auch den ICX Core auf die recommendete 8.0.90h (h Patch !) updaten. Die 8.0.7er ist uralt und hat keinen Support mehr und hatte ein paar STP Bugs und LACP Fixes. Gut, die FW ist nicht involviert in die Kommunikation aber das solltest du schon machen.
Per USB Stick ist das 3 Minuten Sache mit einer Downtime.
Es ist so oder so empfehlenswert denn Ruckus wird über kurz oder lang alles auf das neue UFI Format umstellen was auch den Bootloader automatisch mit updatet.
Achtung beim Update aufs UFI das muss mit einem Zwischenschritt passieren:
Per USB Stick ist das 3 Minuten Sache mit einer Downtime.
Es ist so oder so empfehlenswert denn Ruckus wird über kurz oder lang alles auf das neue UFI Format umstellen was auch den Bootloader automatisch mit updatet.
Achtung beim Update aufs UFI das muss mit einem Zwischenschritt passieren:
- Firmware Image ZIP File für 8.0.90h runterladen und non UFI Imagename und Bootloader Code rauskopieren.
- An den Cisco Ports unbedingt gig-default neg-off konfigurieren bei 1Gig SFPs !!
- Switch mit dem non UFI Image updaten ebenso den Bootloader und checken das im Stack alle Member die neue SW und Bootloader geladen haben. (show ver und show flash)
- Rebooten
- Wenn der Stack wieder gebootet hat wiederholst du die Update Prozedur mit dem UFI Image nochmal. Du wirst sehen das nach dem Upload automatisch der aktuelle UFI Bootloader extrahiert und upgedatet wird.
- Dann Switch final auf das UFI Image booten
Als hätte ich es geahnt... hatte schon ein ungutes Gefühl beim Upgrade und war vermutlich auch damals der Grund warum ich solange bei 08070g geblieben bin. Das Upgrade ging voll in die Hose.
Habe haargenau deine Anweisungen befolgt, die neue Firmware lief auch. Aber dann funktionierten meine SFP-Ports nicht mehr. Ich kann sie aktivieren und deaktivieren wie ich will, ich kann keine Verbindungen zu den Acess-Switchen aufbauen. Habe jetzt versucht ein simples flaches VLAN1 mit untagged Ports und einfach C-Netz einzurichten... keine Chance. Geht nicht.
Werde jetzt versuchen auf dem secondary ein 08070g zu downgraden.
Habe haargenau deine Anweisungen befolgt, die neue Firmware lief auch. Aber dann funktionierten meine SFP-Ports nicht mehr. Ich kann sie aktivieren und deaktivieren wie ich will, ich kann keine Verbindungen zu den Acess-Switchen aufbauen. Habe jetzt versucht ein simples flaches VLAN1 mit untagged Ports und einfach C-Netz einzurichten... keine Chance. Geht nicht.
Werde jetzt versuchen auf dem secondary ein 08070g zu downgraden.
Gut, du hast ja wohl hoffentlich das neue Image ins Secondary geflasht, dann kannst du einfach wieder aus dem Primary booten und gut iss. Aber das ist nicht nötig... Immer ruhig Blut ! 
Mit der neuen Firmware musst du bei Fremdherstellern einfach nur ein gig-default neg-off auf den SFP Ports konfigurieren, dann sollte das sofort wieder klappen.
So sieht der Port dann aus:
!
interface ethernet 1/2/2
port-name LWL Uplink Cisco SG
gig-default neg-off
!
Sorry hatte ich oben vergessen zu erwähnen !
Mit der neuen Firmware musst du bei Fremdherstellern einfach nur ein gig-default neg-off auf den SFP Ports konfigurieren, dann sollte das sofort wieder klappen.
So sieht der Port dann aus:
!
interface ethernet 1/2/2
port-name LWL Uplink Cisco SG
gig-default neg-off
!
Sorry hatte ich oben vergessen zu erwähnen !
Zitat von @aqui:
Mit der neuen Firmware musst du bei Fremdherstellern einfach nur ein gig-default neg-off auf den SFP Ports konfigurieren, dann sollte das sofort wieder klappen.
So sieht der Port dann aus: !
interface ethernet 1/2/2
port-name LWL Uplink Cisco SG
gig-default neg-off
!
Mit der neuen Firmware musst du bei Fremdherstellern einfach nur ein gig-default neg-off auf den SFP Ports konfigurieren, dann sollte das sofort wieder klappen.
So sieht der Port dann aus: !
interface ethernet 1/2/2
port-name LWL Uplink Cisco SG
gig-default neg-off
!
Das wird es vermutlich gewesen sein. Besten Dank!
Finde es von Ruckus etwas schwach das die fast nirgends ein Wort darüber verlieren. Die Funktion ist zwar bekannt und auch dokumentiert, aber es wird nichts im Zusammenhang mit Third-Party Modulen erwähnt. Zumindest kann ich in den Release Notes von ab 2017 nichts finden.
Sowas hätte man irgendwie besser kommunizieren können.
Wo hast du die Info her?
Das Update hat nun funktioniert. Ich habe aber noch zwei Fragen dazu:
1. Sollte nach dem booten auf das UFI-Image nicht jeweils bei Pri und Sec Boot Code das 10118 drin sein? Bei mir ist im Sec jetzt noch das 10114 drin...
Ansonsten sieht mein show ver so hier aus...
2. Seitdem Update ist komischerweise eine LED der 1Gbit-LWL-Uplinks gelb statt wie vorher grün. Soweit ich das kenne bedeutet das meistens entweder half-duplex oder 100Mbit. In der Konfiguration ist das aber beides nicht der Fall. Hat das jetzt eine andere Bedeutung? Interessanterweise genau die Schnittstelle zu dem SG200...
1. Sollte nach dem booten auf das UFI-Image nicht jeweils bei Pri und Sec Boot Code das 10118 drin sein? Bei mir ist im Sec jetzt noch das 10114 drin...
Stack unit 1:
Compressed Pri Code size = 29360128, Version:08.0.90hT211 (SPS08090h.bin)
Compressed Sec Code size = 29360128, Version:08.0.90hT211 (SPS08090h.bin)
Compressed Pri Boot Code size = 786944, Version:10.1.18T215 (spz10118)
Compressed Sec Boot Code size = 786944, Version:10.1.14T215 (spz10114)
Code Flash Free Space = 1759145984
Stack unit 2:
Compressed Pri Code size = 29360128, Version:08.0.90hT211 (SPS08090h.bin)
Compressed Sec Code size = 29360128, Version:08.0.90hT211 (SPS08090h.bin)
Compressed Pri Boot Code size = 786944, Version:10.1.18T215
Compressed Sec Boot Code size = 786944, Version:10.1.14T215
Code Flash Free Space = 1750147072
Stack unit 3:
Compressed Pri Code size = 29360128, Version:08.0.90hT211 (SPS08090h.bin)
Compressed Sec Code size = 29360128, Version:08.0.90hT211 (SPS08090h.bin)
Compressed Pri Boot Code size = 786944, Version:10.1.18T215
Compressed Sec Boot Code size = 786944, Version:10.1.14T215
Code Flash Free Space = 1757110272Ansonsten sieht mein show ver so hier aus...
Copyright (c) Ruckus Networks, Inc. All rights reserved.
UNIT 1: compiled on Nov 4 2020 at 21:41:12 labeled as SPS08090h
(29360128 bytes) from Primary SPS08090h.bin (UFI)
SW: Version 08.0.90hT211
Compressed Primary Boot Code size = 786944, Version:10.1.18T215 (spz10118)
Compiled on Mon Jul 13 09:53:15 2020
UNIT 2: compiled on Nov 4 2020 at 21:41:12 labeled as SPS08090h
(29360128 bytes) from Primary SPS08090h.bin (UFI)
SW: Version 08.0.90hT211
Compressed Primary Boot Code size = 786944, Version:10.1.18T215 (spz10118)
UNIT 3: compiled on Nov 4 2020 at 21:41:12 labeled as SPS08090h
(29360128 bytes) from Primary SPS08090h.bin (UFI)
SW: Version 08.0.90hT211
Compressed Primary Boot Code size = 786944, Version:10.1.18T215 (spz10118)2. Seitdem Update ist komischerweise eine LED der 1Gbit-LWL-Uplinks gelb statt wie vorher grün. Soweit ich das kenne bedeutet das meistens entweder half-duplex oder 100Mbit. In der Konfiguration ist das aber beides nicht der Fall. Hat das jetzt eine andere Bedeutung? Interessanterweise genau die Schnittstelle zu dem SG200...
10GigabitEthernet1/2/6 is up, line protocol is up
Port up for 38 minute(s) 9 second(s)
Hardware is 10GigabitEthernet, address is 609c.9fXX.XXXX (bia 609c.9fXX.XXXX)
Configured speed 1Gbit, actual 1Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual MDI
Tagged member of 4 L2 VLANs, untagged in VLAN 1, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
Flow Control is config enabled, oper enabled, negotiation disabled
Mirror disabled, Monitor disabled
Mac-notification is disabled
VLAN-Mapping is disabled
Not member of any active trunks
Not member of any configured trunks
Port name is Cisco SG200-50
IPG XGMII 96 bits-time
MTU 1500 bytes
MMU Mode is Store-and-forward
300 second input rate: 7568 bits/sec, 6 packets/sec, 0.00% utilization
300 second output rate: 14000 bits/sec, 9 packets/sec, 0.00% utilization
13700 packets input, 2044020 bytes, 0 no buffer
Received 1030 broadcasts, 1715 multicasts, 10955 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
24190 packets output, 4870340 bytes, 0 underruns
Transmitted 7364 broadcasts, 8066 multicasts, 8760 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Protected: No
MAC Port Security: Disabled
UC Egress queues:
Queue counters Queued packets Dropped Packets
0 5027 0
1 263 0
2 141 0
3 0 0
4 419 0
5 2597 0
6 36 0
7 1235 0
MC Egress queues:
Queue counters Queued packets Dropped Packets
0 10116 0
1 2895 0
2 322 0
3 1139 0
Zu 1.)
Ja, da hast du recht. Wenn du das UFI Image in das Secondary flashst sollte in jedem Falle dort auch der aktuelle 10.1.18er Boot Code geflasht sein.
Ggf. wieder holst du das nochmal. Falls es nicht klappt mal mit einem Unit spezifischen Flashen (unit x) am Kommando. Die Boot Codes sollten identisch sein. Kannst du ja auch beim UFI Flash Prozess im CLI mit den dortigen Terminal Messages (ggf. term mon eingeben wenn du Telnet oder SSH machst) sehen das er nach dem Image auch noch den Bootcode flasht.
Zu 2.)
Hast du zusätzlich zu gig-default neg-off auch testweise mal den Spoeed auf 1G dort forciert mit speed 1000 ? Wenn das ein 1 G Port ist solltest du das besser mal machen.
Die Interface Statistiken sehen sonst absolut sauber aus.
Ja, da hast du recht. Wenn du das UFI Image in das Secondary flashst sollte in jedem Falle dort auch der aktuelle 10.1.18er Boot Code geflasht sein.
Ggf. wieder holst du das nochmal. Falls es nicht klappt mal mit einem Unit spezifischen Flashen (unit x) am Kommando. Die Boot Codes sollten identisch sein. Kannst du ja auch beim UFI Flash Prozess im CLI mit den dortigen Terminal Messages (ggf. term mon eingeben wenn du Telnet oder SSH machst) sehen das er nach dem Image auch noch den Bootcode flasht.
Zu 2.)
Hast du zusätzlich zu gig-default neg-off auch testweise mal den Spoeed auf 1G dort forciert mit speed 1000 ? Wenn das ein 1 G Port ist solltest du das besser mal machen.
Die Interface Statistiken sehen sonst absolut sauber aus.
Zitat von @aqui:
Zu 1.)
Ja, da hast du recht. Wenn du das UFI Image in das Secondary flashst sollte in jedem Falle dort auch der aktuelle 10.1.18er Boot Code geflasht sein.
Ggf. wieder holst du das nochmal. Falls es nicht klappt mal mit einem Unit spezifischen Flashen (unit x) am Kommando. Die Boot Codes sollten identisch sein. Kannst du ja auch beim UFI Flash Prozess im CLI mit den dortigen Terminal Messages (ggf. term mon eingeben wenn du Telnet oder SSH machst) sehen das er nach dem Image auch noch den Bootcode flasht.
Zu 1.)
Ja, da hast du recht. Wenn du das UFI Image in das Secondary flashst sollte in jedem Falle dort auch der aktuelle 10.1.18er Boot Code geflasht sein.
Ggf. wieder holst du das nochmal. Falls es nicht klappt mal mit einem Unit spezifischen Flashen (unit x) am Kommando. Die Boot Codes sollten identisch sein. Kannst du ja auch beim UFI Flash Prozess im CLI mit den dortigen Terminal Messages (ggf. term mon eingeben wenn du Telnet oder SSH machst) sehen das er nach dem Image auch noch den Bootcode flasht.
Du meinst also eine Unit auswählen und dann auf den Secondary (Primary derzeit gebootet mit UFI) einfach nochmal das UFI-Image drüberbügeln?
Ich habe es selbst noch nicht getestet, aber was passiert wenn man den Stack in den Secondary bootet und dort unterschiedliche Firmware-Versionen und Boot Codes drauf liegen?
Zu 2.)
Hast du zusätzlich zu gig-default neg-off auch testweise mal den Spoeed auf 1G dort forciert mit speed 1000 ? Wenn das ein 1 G Port ist solltest du das besser mal machen.
Die Interface Statistiken sehen sonst absolut sauber aus.
Hast du zusätzlich zu gig-default neg-off auch testweise mal den Spoeed auf 1G dort forciert mit speed 1000 ? Wenn das ein 1 G Port ist solltest du das besser mal machen.
Die Interface Statistiken sehen sonst absolut sauber aus.
speed-duplex 1000-full bereits gesetzt.
und dann auf den Secondary (Primary derzeit gebootet mit UFI) einfach nochmal das UFI-Image drüberbügeln?
Richtig, einfach nochmal im Secondary rübermangeln...und dort unterschiedliche Firmware-Versionen und Boot Codes drauf liegen?
Er wird vermutlich normal booten aber dir auf der Konsole eine Fehlermeldung geben das das nicht das zum UFI Image gebundelte Boot Image ist und du doch bitte nochmals auf das UFI Image updaten sollst.Booten wird er weil das ja der "Transfer" Bootloader ist der UFI und non UFI bootet.
