Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 33 reacties
Submitter: himlims_

Door een bug in een update voor de routersoftware van de firma Juniper is het internetverkeer maandag bij een aantal backboneproviders tijdelijk ernstig verstoord geraakt. De fout zou in een update van het bgp gezeten hebben.

Nadat de Juniper-routers waren voorzien van een firmware-update om het bgp bij te werken, crashten een groot aantal apparaten. Hierdoor werd het netwerkverkeer tussen de diverse backbonerouters ernstig gestoord. De routers draaien op het JunOS en worden bij een groot aantal backboneproviders gebruikt.

De problemen speelden met name in de Verenigde Staten, maar ook in delen van Europa werkten internetverbindingen maandag slecht of niet. Een groot aantal websites was als gevolg van de problemen met de crashende Juniper-routers tijdelijk onbereikbaar.

De storingen kwamen vooral voor bij de Amerikaanse backboneprovider Level 3, maar ook de isp's Tata en Time Warner kampten met problemen. Juniper wist de storing na enkele uren te verhelpen door een in allerijl uitgebrachte bugfix te installeren.

Volgens Juniper zijn de problemen opgetreden op routers die JunOS 10.2 en 10.3 draaien. Details over de problemen gaf het in verlegenheid gebrachte concern niet, maar op pastebin is een document geplaatst waarin een groter aantal versienummers wordt genoemd die met de bug kampen.

Moderatie-faq Wijzig weergave

Reacties (33)

Dus als ik goed begrijp heeft elke getroffen ISP op hetzelfde moment dezelfde firmware update uitgevoerd die voor deze problemen gezorgd heeft? Dat lijkt me erg onwaarschijnlijk, iets als 'autoupdate' wordt naar mijn weten niet gebruikt in de router wereld, je wil namelijk zelf bepalen wat je wanneer upgrade.
Dit was helemaal geen firmware update, maar een BGP-update. BGP is het protocol waarmee routers onderling hun routeringstabellen uitwisselen. Er zit in een aantal firmware versies een bug die gisteren getriggerd werd doordat een provider zijn routeringstabellen openbaar maakte via BGP.
Deze bug was in augustus al gefixt in alle firmwarebuilds, dus de routers die nu gecrasht zijn hebben die update nooit doorgevoerd.

[Reactie gewijzigd door _JGC_ op 8 november 2011 12:31]

Het was een bug in de firmware.
Firmware is gewoon software. Geschreven in C.
De bug zat in de software die de forwarding-tables op een bepaalde chip aanpast.
Die bug wordt getriggered als je bepaalde routes in een bepaalde volgorde installeert en weer delete of veranderd (update).
Routes op het Internet worden verspreid/geadverteerd via het BGP protocol.
De berichtjes in BGP waarmee je routes adverteerd heten: BGP-updates.

Wat er dus is gebeurd:
Ergens op het Internet was er een router (of een set van routers), die bepaalde routes op een bepaalde manier telkens deed veranderen.
Via BGP werden die routes, en die verandering verspreid naar vele andere routers.
Sommige van die routers draaiden de JunOS software waar die bug in zit.
Die routers accepteerden de veranderingen, en installeerden/veranderden die routes in de forwarding-tables van hun interfaces.
En dat triggerde de bug.
En daardoor crashten die routers.
Informatief? Foute informatie imho.

Wat is een BGP update volgens jou? BGP is een open standaard en vastgelegd in een RFC en wordt niet "geupdate". Al er iets geupdate wordt kan dat praktisch alleen maar met firmwareupdates.
Een BGP Update is een bericht dat BGP-routers onderling uitwisselen...
Snap ik. Maar een BGP update gebeurd elke seconde 1000-den keren dus dat kan geen bug zijn lijkt me.
Een bug (welke bug ook) heeft relatie met firmware, niet met een updatemessage van een routeringprotocol.
een BGP update krijg je elke keer dat er een route bijkomt of verwijderd wordt of als er attributen van die route wijzigen. In een stabiel netwerk krijg je geen enorme aantallen updates.
Waarschijnlijk is het BGP proces gecrashed door een update pakket met daarin een route met een unieke combinatie van attributen. Vervolgens moet die route worden verwerkt waar dat proces over gestruikeld is. Een core router kan relaties hebben met 10 tallen andere core routers en dus kunnen er tegelijkertijd een hoop andere routers crashen als gevolg van een enkele update.
In een stabiel netwerk krijg je geen enorme aantallen updates.
In de "default-free zone" in het midden van het net worden er momenteel 383 duizend routes geadverteerd. 383000. Als er slechts een klein deel van de routes veranderd, dan heb je nog steeds enkele updates per seconde.

Hoeveelheid routes op het Internet vindt je hier: http://www.cidr-report.org/as2.0/

En dan heb je nog BGP/MPLS-VPNs. Traffic wordt over MPLS gestuurd. Maar de control informatie wordt via BGP verspreid. BGP/MPLS-VPNs werken (voornamelijk ? alleen ?) binnen het netwerk van een enkele ISP. Dus die zullen inderdaad wel stabieler zijn.

[Reactie gewijzigd door gryz op 8 november 2011 14:11]

Er zijn weinig routers die duizenden updates per seconde krijgen, maar dat even terzijde.

Inderdaad heeft een bug een relatie met firmware (of soms zelfs hardware). Deze specifieke bug werd niet getriggerd door een willekeurige update, maar trad alleen onder heel erg specifieke omstandigheden op.

Heb je de beschrijving van Juniper al gelezen, die op pastebin was gepost? Ik zal een relevant stukje aanhalen:
The assertions (crash) all occurred in the code used to store routing information, called Ktree, on the MPC. Due to the order and mix of adds and deletes to the tree, certain combinations of address adds and deletes can corrupt the data structures within the MPC, which in turn can cause this line card crash. The MPC recovers and returns to service quickly, and without operator intervention.
Dus: er zit een bug in een aantal Junos-versies, die te maken heeft met het verwerken van *geldige* BGP Update messages, en alleen optreedt bij specifieke combinaties & volgordes van adresupdates.

En blijkbaar zijn er de afgelopen dagen meerdere van dat soort update-messages tussen BGP-routers uitgewisseld, want op diverse mailing lists (zoals NANOG en Outages) is wel info te vinden dat meerdere grote partijen door deze bug gebeten zijn.
Wikipedia is het niet met je eens.
zowieso iedereen die via Level3 aan het net gekoppeld zit
Dus Level3 heeft ineens AL hun routers (1000+) in de upgrade gegooid? Nah.. denk het niet :)
De verwarring komt omdat het nieuwsbericht technisch onjuist is. Level3 heeft vannacht de routers geupdate om deze bug te verhelpen. Dit is dus NA de outage van gisteren.
dat zou wel eens goed kunnen, gisterenavond/vannacht was ik met 7 anderen een potje SC2 aan't spelen, toen plots 4 of 5 tegelijkertijd begonnen te laggen en ze hadden allemaal andere providers. Ik zelf heb er zelfs een paar seconden uit gelegen, terwijl ik zo veel onderbrekingen nog nooit had ervaren.

het is moeilijk om te achterhalen waar de oorzaak lag, maar in elk geval bedacht ik mij toen al dat de oorzaak ergens hogerop moest worden gezocht.
Dit probleem was al opgelost in versies van het OS welke na 2011-08-03 uit zijn gekomen (zie pastebin link in het artikel). Het lijkt dus op een geval van het niet in de gaten houden van updates & deze aktief uitrollen binnen het netwerk.

[Reactie gewijzigd door brederodekater op 8 november 2011 12:26]

2011-08-03, dat is net 2 maanden oud. Ik kan me heel goed voorstellen dat grote backboneproviders niet zomaar elke update direct installeren maar dat ze eerst een validatie en test proces moeten doorlopen.
Daarnaast zullen de updates wel volgens een min of meer vaste planning uitgerold worden, je kunt tenslotte niet op elk willekeurig moment een willekeurige router even uit de lucht halen.

Zo gezien is 2 maanden helemaal niet zo lang.
"je kunt tenslotte niet op elk willekeurig moment een willekeurige router even uit de lucht halen."

Als het goed is kan dat juist wel ;p
En mogelijk was er in de update juist weer iets anders wat niet werkte.
Daar is juniper erg goed in, iets fixen maar ondertussen werkt iets anders weer niet.
En duurt dan weer maanden/jaren voordat het werkt. (zo zitten wij al ruim jaar te wachten of fix voor basic firewall issue)
Hmm, iemand overijverig de laatste firmware geļnstalleerd?
Juniper geeft niet voor niets altijd een recommende Firmware (vaak 1 of 2 versies onder de meest recente) aan
De bug is bekend sinds augustus, maar zoals je in het document op Pastebin kan lezen, dacht Juniper dat de kans vrij klein was dat hij vaak zou optreden:
Given the complexity of conditions required to trigger this issue, the
probability of exploiting this defect is extremely low.
Dus het zou me niets verbazen als Juniper geen sterk advies had gegeven tegen het draaien van deze versies.
Volgens mij draaien de Internet Plus verbindingen van Ziggo Zakelijk ook op Juniper routers. Hebben deze routers hier ook last van gehad?

Heb er zelf in ieder geval geen last van gehad!
Ziggo geen idee, maar zakelijke klanten met glasvezel van KPN konden gisteren enkele minuten bepaalde subnets op internet niet meer bereiken.
Jullie kunnen hier wel half wazig op reageren, maar hij heeft wel degelijk een punt.

Ik werk zowel met Juniper als met Cisco apparatuur. In mijn ervaring is JUNOS inderdaad veel meer buggy dan IOS.

Beide platformen hebben natuurlijk altijd wel veel bugs aan boord, maar bij JUNOS zijn het vaak bugs in "basic" features welke simpelweg niet opgemerkt worden, dus blijkbaar niet goed getest worden.

Memoryleaks zijn bijvoorbeeld ook aan de orde van de dag, iets wat je makkelijk kan detecteren als je fatsoenlijk test.
Testen op memory-leaks is niet altijd makkelijk. Een memory-leak kan getriggerd worden door iets wat in het lab niet gebeurd. Omdat je er niet aan denkt tijdens het testen. Als je er wel aan zou denken, dan had de developer er direct al rekening mee kunnen houden toen hij de software schreef.

En de events die memory doen leaken moeten in grote getalen gebeuren voor je ziet dat er een memory-leak is. En dat gebeurd vooral in live netwerken.
De obviouse leaks waar ik het over heb is bijvoorbeeld een leak die we er laatst uit haalde, het authenticatie process van dot1x. Deze leak treed steeds direct op bij het gebruik van dot1x. Conclusie, het is simpelweg gewoon niet getest. En zo is het steeds bij JUNOS, ik heb nog *nooit* een JUNOS upgrade gedaan zonder tegen obiouse bugs aan te lopen in die software.

Als je daarna vervolgens met JTAC moet werken om de problemen te verhelpen kom je er pas achter wat voor verschikking dat bedrijf is.

Af en toe loop ik flink te zeiken op Cisco, maar wat een verademing is dat bedrijf in vergelijking met Juniper.
Dat zou best iets met prijs/kwaliteit te maken kunnen hebben als je kijkt naar het prijs verschil.
Debuggen is iets wat je doet zodra je een bug vind.

Ze hadden betere test cases meoten schrijven voor hun software en die ook daadwerkelijk moeten uitvoeren.
Makkelijker gezegd dan gedaan.

Bovendien had Juniper de bug al gevonden en gefixd. Het probleem is dan: doe je een waarschuwing uitgaan naar *al* je klanten om ze te vragen te upgraden ? Dat veroorzaakt weer problemen op zich.

Wat je doet is een inschatting maken, hoe reeel de kans is dat dit probleem zich gaat voordoen in live netwerken. En als je denkt dat het wel mee valt, dan doe je verder niks. Binnen een aantal maanden tot een jaar zullen de meeste routers bij je klanten zowiezo nieuwe software-updates krijgen. En gaat het probleem vanzelf weg.

Dat hebben ze dus fout gegokt.

[Reactie gewijzigd door gryz op 8 november 2011 14:00]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True