Ordlista finns nedan för tekniska beteckningar.
Under tisdag förmiddag upptäckte vi att det plötsligt fanns paketförluster mot olika delar av internet.
Den initiala felsökningen försvårades då vi själva fick paketförluster mot de routrar som hanterar vår anslutning mot internet (de routrar som hanterar BGP för peering av IPv4 IPv6 routes).
Tekniker var redan på väg till vår serverhall i Mölndal och kunde påbörja felsökning på plats kort därpå.
Mycket pekade på en av två routrar som har hand om BGP mot den ena av våra ISP:er och eftersom inga konfigurationsförändringar gjorts hos oss så stängde vi ned anslutningen till BGP på den.
Det hjälpte dock inte och vi såg att medan många routes på internet fungerade bra till och från oss, så var det fortfarande paketförluster mot andra delar.
Felsökningsläge på routrarna gav inget uppenbart fel, men vi såg ändå att ena routern hade mer problem än den andra. Inga uppenbara ”drops” på några portar heller, vi provade ändå att snabbt koppla ur och in moduler och SFP:er (komponenter/fiberdon) för att se om det kunde avhjälpa något.
Vi kopplade därefter bort routingdelen helt från den router som vi identifierat som problematisk. Vi såg då inga paketförluster ut från oss när vi utförde tester, men det kom fortfarande in rapporter om paketförluster från våra kunder.
Tester gjordes och vi såg t.ex. att ”Telia Carrier” från Stockholm inte hade några paketförluster mot oss, medan ”Telia Sverige” från samma stad hade ca 50%. (https://lg.telia.net/)
Här någonstans började vi inse att det måste ha med våra routes att göra och vad våra routingmoduler i routrarna klarade av att hålla i minnet (TCAM/CEF).
Förklaring till hur minne fungerar i routrar
För att routrar så snabbt som möjligt skall räkna ut vart trafiken skall skickas på internet så används ett snabbt minne som cachear routrarnas uträkning så att de inte behöver spendera tid på att kontrollera det vid varje paket som skall skickas. Om minnet tar slut eller om den del av minnet som man har gett till t.ex. IPv4 eller IPv6 (https://sv.wikipedia.org/wiki/IPv4 https://sv.wikipedia.org/wiki/IPv6) så behöver routern räkna ut route via processorn. Har man då många paket som skall skickas blir det svårt för processorn att hinna med vilket leder till paketförluster.
Utbyte av routes
ODERLAND peerar med två ISP:er idag och det gör att vid problem hos en ISP så fortsätter vårt nätverk att fungera då vi talar om för båda våra ISP vilka nät vi har (annonserar ut).
Det gör att vi kan skicka och ta emot trafik den kortaste vägen genom de routes vi får via BGP från våra ISP:er. Det betyder att dessa routes (närmare 700.000+ entries för IPv4) måste få plats i minnet enligt ovan.
De routrar vi har i core idag har inte stöd för dynamisk allokering av utrymme för IPv4/IPv6. Det betyder att för att ge mer minne/utrymme för IPv4 routes t.ex. så behöver de bootas om. Det i sig är inte ett så stort problem, då man ofta har redundans på samtliga servrar, kopplad till båda routrarna.
MEN – och här var det som tog oss lite tid att hitta – när utrymmet för antal routes har övertrasserats, så krävs en omstart av routern för att få bort felet.
Felet kan också uppkomma om routingtabeller ändras ofta, då strukturerna i minnet inte frigör minnet korrekt.
Vi gjorde nämligen en del åtgärder för att komma runt problemet, rensade samtliga routes, stängde av access till en av ISP:erna och skickade allt trafik genom en och samma ISP för att inte använda de routes vi fått via BGP. Då fick vi istället mer problem, eftersom den nya statiska routen som vi satt upp (default gateway) inte lades in i minnet då det var ”fullt” trots borttagning av allt.
Vi utökade antalet routes som ipv4 får använda sig utav. Då såg vi att det krävdes en omstart av båda routrarna (då båda hade samma fel) så beslutade vi att starta om de. Efter några minuter var de igång och felet var borta.
Vad påverkades av driftstörningen
Samtliga tjänster hos oss via IPv4 påverkades, men inte för alla som försökte nå dem. Om man märkte av problemen eller ej beror på vilken väg ens trafik tog över nätet. De som påverkades upplevde sajter samt e-post som mycket långsam. Under sista delen av felsökningen var samtliga tjänster onåbara över internet ca 5-10 minuter.
Trafik som gick via IPv6 påverkades ej förutom vid omstarten av routrar.
Kan samma fel inträffa igen
Nej, inte inom den tidsram vi har för åtgärderna nedan. Vi utökade vårt IPv4 utrymme med ca 15% på routrarna. På de ca 4.5 år som routrarna har varit gång utan omstart eller problem så har routingtabellen för IPv4 växt med ca 3-5%. Eftersom åtgärdena som nämns nedan kommer att utföras nästa år är det inte ett problem.
Vilka åtgärder tar vi
- Vi har redan ett pågående arbete med att förnya vårt nätverk. Ny utrustning har köpts in och vi byter från 1/10 Gbit/s koppar mot 25/40/100 Gbit/s fiber i nästan all utrustning.
- Utökning till en ny serverhall har redan skett, näten är ihopkopplade men vi annonserar inte ut trafik där ännu. Vi kommer att kunna erbjuda redundans över två hallar i framtiden.
- De routrar vi har idag kommer att fasas ut och ersättas. Eftersom vi inte vill påverka julhandeln samt mellandagsrean om något mot all förmodan skulle gå snett så kommer det att ske i början av nästa år. Efter mycket, mycket tester (eftersom vi kan testa allt i den nya serverhallen först).
- En ny loggningsmiljö för kritiska interna system kommer att uppföras, så att liknande fel skall kunna hanteras otroligt mycket fortare.
- Larm kommer skickas ut till jourpersonal när antal routes växer betydligt.
Förlåt!
Vi ber om ursäkt att det tog oss tid att hitta exakt vad felet berodde på. Vi gör alltid vårt yttersta för att vårt nätverk skall vara stabilt och schemalägger i möjligaste mån servicefönster nattetid samt inte i anslutning t.ex. Black Friday eller dylika dagar då handeln är som högst.
Som många av er, våra kunder, nämnt så har vi väldigt sällan nertider och det är vi stolta över. Våra DDoS skydd har bara senaste veckorna stoppat en större mängd attacker som annars hade fyllt vår internettrafik och inneburit nertid för hela vår miljö.
Ordlista
BGP: Border Gateway Protocol. Ett regelverk för hur routrar pratar med varandra på internet för att byta trafik och information om vilka man har kontakt med. https://sv.wikipedia.org/wiki/Border_Gateway_Protocol
ISP: Internet Service Provider. Används här som leverantör av internettransit/åtkomst, enklare översatt som bredbandsleverantör, men när det gäller företagsanslutningar så kan man köpa till högre krav på service.
Paketförluster: Data behöver skickas om, vilket gör att det tar längre tid att skicka eller få data. På samma sätt som vanliga hårda paket, att man behöver skicka om ifall ett försvinner på vägen.
Peering: Utbyte av nätverksinformation, routes, om vart olika nät finns på internet
Route: I detta fall ”väg som trafiken på internet tar mellan punkt A till punkt B”
TCAM/CEF: Minne i routrar samt struktur för routes i minnet. https://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/13706-20.html