Door Anoniem: Er was een SFP defect - alleen op een zodanige manier dat de link niet down ging , en de (aanwezige) redundantie was gebouwd op het idee dat een lijn down gaat als er een (lijn)storing is.
Dat is inderdaad technisch oplosbaar - allerlei protocollen mogelijk die verkeer sturen om end-to-end (of next hop) te zien of er wel tweeweg communicatie mogelijk is. (link aggegratie , ook met 1 link , bfd, stp , ospf , afhankelijk van het gekozen design) .
Er staan ook wat beschrijvingen bij die veel moeilijker oplosbaar zijn : de keuze om 'om te zwaaien' naar een andere verkeerspost duurt ca 4 uur, en gedurende die tijd is men blind . (en ik meen dat die keuze ook niet snel halverwege te stoppen is - oh nee, laat maar) .
Heel moeilijk dus wanneer je bij een storing besluit "dit duurt te lang om op te lossen, we gaan omzwaaien" .
Geen inzicht waarom het zo lang duurt - maar dat zal in een complexe omgeving niet snel om te bouwen zijn naar 'rapid failover' .
Wel iets dat verder zorgelijk is : omschrijving dat _alles_ bij elkaar liep te zoeken - netwerk engineers, systeem specialisten, database specialisten, applicatie specialisten etc .
Aha dat is interessant! Inderdaad snap ik wel dat het overstappen naar een backup verkeerspost een complex verhaal
is wat je niet snel doet en terugdraait, maar (net als jij denk ik) snap ik niet goed waarom men niet heel wat sneller
de oorzaak van het probleem wist op te sporen en die oorzaak te verhelpen, waardoor men op de originele locatie aan
het werk kon blijven. Ik weet niet in hoeverre men bij prorail op zondagavond IT technici op locatie heeft die meteen
de boel kunnen checken en zaken als een SFP kunnen verwisselen, dat zou evt nog kunnen betekenen dat er iemand
gebeld moet worden en in de auto moet stappen (niet in de trein, hopelijk!).
Maar zonder dat moet je zo iets toch wel in een half uurtje kunnen oplossen lijkt me. Desnoods trek je even ergens
een SFP uit die niet zo belangrijk is, als je er geen extra hebt liggen.
Tegen de tijd *dat* je weet dat er een SFP kapot is - (terwijl het interface wel gewoon up is, blijkbaar) is het wisselen simpel.
Het klopt wel dat 'normale' monitoring zo'n type defect niet ziet , die kijkt primair naar 'interface down' .
Daarom gebruik je al die keepalive protocollen om z'n type onderbreking zichtbaar te maken .
Maar wat je al zegt, met een van die andere oplossingen zou je dit hele probleem niet hebben, zij het dat je dan wel
goed moet monitoren want anders kan het zijn dat er een SFP stuk gaat, de redundantie alles opvangt, en dan veel later
een tweede stuk gaat (productiefoutje?) waarna de boel alsnog plat is. Het lijkt me dan ook verstandig alle links te
checken of er wel verkeer door komt ook als ze "up" aangeven.
Monitoring op verkeersvolume kan nuttig zijn, maar heeft het risico op vals positief - je backup pad voert normaal gesproken GEEN verkeer .
(zelfde uitdaging hebben firewall beheerders met 'idle' rules - sommige staan er zodat de backup kan werken . Die moet je niet blindelings 'opschonen want niet gebruikt' ).
Afgezien van de technische verbeter opties voor _dit type fout_ - mensen die het totaalplaatje snappen, en uit symptoom/logs van systemen en applicaties kunnen herleiden *dat* de verbinding van X naar Y niet meer werkt , die ontbraken er bij prorail, zo lijkt het.
Vanaf daar is het zoeken naar de defecte schakel in dat pad van X naar Y gewoon redelijk routine .
Zou wel grappig zijn als de C2000 storing dezelfde oorzaak heeft. Dan gaan we nog wat lezen over SFP's van een
bepaald merk...
Ik kwam eens een verhaal tegen van SFPs met een software bug - na 248 dagen uptime werden waarden in het verkeerde veld geschreven , en klapperde de SFPs .
Met strakke maintenance windows hebben nogal veel SFPs op een locatie dezelfde uptime . Oeps, daar gaat je redundantie .
(2^32 ticks ...) . Ook succes met lab test/reproducatie ...