Rapport om routinganalys för Post och Telestyrelsen I samband med flytt av knutpunkt från Stockholm-A till Stockholm-C Bilaga 5
Innehåll INNEHÅLL... 2 1 INTRODUKTION... 3 1.1 BAKGRUND... 3 1.1 ÖVERSIKT AV INTERNETKNUTPUNKTEN I STOCKHOLM... 3 2 BESKRIVNING AV TEST SCENARIER... 5 2.1 INSAMLAT DATA... 5 2.1.1 BGP loggar... 5 2.1.2 Dataformulär... 6 2.2 DATAINSAMLINGSPUNKTER OCH DELTAGANDE ISPER... 6 2.3 ANSLUTNINGSMATRIS... 7 3 ANALYS AV DATA... 7 3.1 BGP DATA... 7 3.1.1 Lastgrafer per ISP... 8 3.1.2 BGP aktivitetsgrafer... 30 4 SLUTSATSER... 33 5 ORDLISTA... 34
1 Introduktion 1.1 Bakgrund Post och Telestyrelsen har av regeringen fått i uppdrag att rapportera om sårbarhet och stabilitet för Internet i Sverige. Rapporten består av flera delar som täcker olika aspekter av Internets stabilitet. En av dessa hanterar stabiliteten på Internet i händelse av ett bortfall av en av de större Internetknutpunkterna i Sverige. Netnod Internet Exchange Ab driver de fyra största Internetknutpunkterna, i avseende på antal deltagande operatörer. Netnod hade sedan tidigare planerat att flytta en av dessa knutpunkter från befintlig lokal till en ny lokal, och detta gav möjligheten att pröva stabiliteten kring knutpunkter i verkligheten. Den här rapporten analyserar de observationer som gjorts för routing uppdateringar, ändringar och operatörers routing policy, under flytten och en tid innan. Flytten skedde den 9:onde november 2002, med början vid midnatt och slutfördes strax innan kl 8 på morgonen den 10:onde. 1.1 Översikt av Internetknutpunkten i Stockholm. I Stockholm driver Netnod ett antal tekniker för knutpunkter. Dessa är två Cisco Systems Spatial Reuse Protocol (SRP, även kallat DPT, Dynamic Packet Transport) OC-12 (622 Mbps) och OC-48 (2.4Gbps) ringar, en Gigabit Ethernet knutpunkt och en historisk FDDI baserad Internetknutpunkt. Varje teknik är delad i två fysiskt separata delar. För SRP är dessa två fysiska nätverk de inre och yttre ringarna i SRP. Varje av de inre och yttre ringarna är anslutna till två olika SPR koncentratorer, kallade A och B. I bilden nedan representeras A och B koncentratorerna av RS1 och RS2.
I bilden ovan är R1 - R4 operatörernas routrar. A och B linjerna är de två dubbelriktade ringarna. FDDI konfigurationen är uppbyggt efter samma principer, där två ringar ansluts till två olika Digital Gigaswitchar, också kallade A och B. I de båda tidigare exemplen används nivå två (enligt TCP/IP modellen, se OSI/TCP/IP modellen i ordlistan) teknologins egenskaper för att hantera redundans för de båda Internetknutpunkterna. I båda fallen har de båda ringarna samma IP-subnät. För Gigabit Ethernet används två olika IP-subnät såväl som två separata Gigabit Ethernet switchar som varje ansluten operatör ansluts till med två anslutningar. Detta innebär att för Gigabit Ethernet används ingen nivå två teknik för att ge redundans. De två switcharna är inte anslutna till varandra, så varje operatör är ansluten med två länkar, en till varje switch, och varje anslutning är numrerad från två olika IP-subnät. För Gigabit Ethernet används istället för nivå två, nivå tre, dvs IP, för att skapa redundans. De två olika Gigabit Ethernet switcharna kallas också för A respektive B. FDDI och Gigabit Ethernet är sammankopplade i B platsen via en s.k. brygga. En kund anslutning till Gigabit Ethernet skulle alltså se ut som A- sidan B-Sidan Kundrouter Gigabit Ethernet Switch FDDI Switch I bilden ovan kan kundroutern representeras av en eller två fysiska routrar. För B-sidan delar alltså FDDI nätet och Gigabit Ethernet switchen i B samma nivå tre nät. Varje A och B enhet som beskrivs ovan finns i två olika bergrum som ägs och drivs av Post och Telestyrelsen. I den ovan beskrivna flytten flyttades utrustningen från A lokalen till en plats kallad C. Den flyttade utrustningen var all A-utrustningen. Vid flytten ändrades ingen av operatörernas konfiguration så alla bibehöll samma nivå tre och två adress.
2 Beskrivning av test scenarier 2.1 Insamlat data För analysen av effekten av bortfallet av en knutpunkt samlades olika data in från ett antal olika källor. Data består i ett antal dataformulär och loggar av BGP aktivitet från olika platser över världen. Datat kan delas in i två olika kategorier. BGP Data Dataformulär insamlade från olika ISP kunder till Netnod De insamlade BGP-loggarna fungerar som mätdata för effekterna av flytten. Dataformulären används för att bättre förstå operatörernas nätverkskonfiguration och ge en insikt i vissa av de data vi samlade in. 2.1.1 BGP loggar I den första kategorin skulle data samlas in från tio operatörer som är anslutna till knutpunkten. En av de tillfrågade operatörerna kunde dock inte delta då den utrustning de använde, inte klarade av att hantera loggning av den typ av data som krävdes för analyserna. En operatör samlade in datat men delade aldrig med sig av detta till oss. Detta innebär att endast data från åtta operatörer användes för analyserna. Den operatör som inte kunde delta är kallad ISP09 i dataanalyserna. Detta påverkar inte analys resultatet eftersom BGP protokollets konstruktion betyder att förändringar kommer att propageras till alla peers. BGP datat har betydelse för att kunna se effekterna av ett bortfall av en knutpunkt med avseende på stabilitet. BGP är det routingprotokoll som används i IP nät mellan s.k. autonomasystem, i vårt fall operatörerna. Via BGP sprids informationen om vilket vägval som just nu gäller, eller är möjligt för att nå ett visst IP nät på Internet. BGP är ett s.k. vektorbaserat routingprotokoll och lider därför av problemet med att routingkonvergens kan ta relativt lång tid (se tex http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ripe- 37-convergence/ för mer detaljer). Detta innebär att vid ett länk fel med en länk över vilken icke-multihop BGP utbyts kommer BGP att detektera att den motstående noden i ett annat autonomtsystem inte längre är nåbar. Den BGP noden kommer då att annonsera att den inte längre är en giltig väg. Notera att multihop BGP kan stanna uppe även vid ett länk fel eftersom detta per definition inte är bundet till direkt ansluta länkar, och kunde använda en annan knutpunk för att hålla en BGP session uppe så länge det finns routing information mellan dem. Så vitt vi vet används dock ingen multihop BGP över knutpunkten. De ISPer som deltog i insamlandet av data samlade in referens data från måndagen innan flytten ända tills måndagen efter flytten. Datat som samlades in var BGP updates som togs emot av routrar anslutna till Internetknutpunkten. Alla operatörer samlade inte in data från alla routrar som är anslutna till Internetknutpunkten, men den enda teknik med möjlighet till fler anslutna routrar är Gigabit Ethernet. Vissa operatörer samlade även in data för bara en router för både Gigabit Ethernet och SRP från samma router. Detta är inte ett problem då ett BGP update meddelande ses även genom ibgp.
Varje operatör bads också att skicka in en kopia av deras BGP tabell så att ett normal fall kunde etableras. Detta visade sig också användbart för att förstå operatörernas routing policy. Tyvärr ansåg dock de flesta operatörer att detta skulle lämna ut för mycket information om deras peering policy och valde att inte dela denna information. 2.1.2 Dataformulär Dataformulären består av ett antal frågor och tabeller som de ISPer som deltog i testet ombads fylla i före och efter flytten. Formulärens avsikt är att fastställa ett antal frågeställningar runt operatörernas nätverkskonfiguration. Bland annat hur deras routing policy är tänkt att hantera redundans i händelse av bortfall av en av deras anslutningar till en knutpunkt. Den ursprungliga iden var att via dataformulären skapa en bild av hur operatörerna planerat för en händelse som att en knutpunkt faller bort. Tanken var att via formulären kunna göra en jämförelse mellan den uppmätta vägen trafik tog mot den som operatörerna planerade för. För denna analys krävs dock att operatörerna avslöjar vilka avtal de har om trafikutbyte mellan sig. Detta anses normalt som väldigt känslig information, och endast tre operatörer svarade. Baserat på detta är det väldigt svårt att dra några slutsatser. Vad man dock kan konstatera ur det material som ändå lämnats in är att operatörerna verkar ha väldigt divergerande trafik val, vilket är bra. Med andra ord, olika operatörer har väldigt olika vägar som primära, sekundära etc. Många av operatörerna har inte ens Netnod som primär eller sekundär, utan andra knutpunkter, privata peering linjer eller sin transit linjer för trafiken över Netnod. Det inlämnade materialet är som sagts, för begränsat för att man skall kunna dra klara slutsatser av det, men om samma förhållanden gäller även i övrigt vore det klart positivt. Det betyder att beroendet på en enskild knutpunkt är väldigt begränsat. Ur det lilla material som finns kan man även konstatera att operatörerna inte har någon preferens mellan A och B knutpunkten för Gigabit Ethernet. Annars fanns det en möjlighet att bryggningen till FDDI knutpunkten från Gigabit Ethernet B skulle ha lett till att operatörer föredrog denna. Det verkar dock inte vara fallet. Vad man kan säga baserat på diskussioner med operatörerna om formulären och det data som kommit in är att detta är ett känsligt ämne för vissa operatörer och variationen i hur datat hanteras avspeglar sig i operatörernas övriga egenskaper, som storlek och peering policy. Operatörer som har en väldigt restriktiv peering policy är normalt mer restriktiva med att lämna ut material om vem de peerar med. Detta förhållande avspeglar sig också till viss del i operatörernas storlek och antal kunder. Materialet som lämnades in användes som förståelse vid analysen av routingdatat. 2.2 Datainsamlingspunkter och deltagande ISPer De deltagande ISPerna har valts ut helt slumpmässigt och försöker att täcka en så stor mångfald som möjligt. De representerar stora och små operatörer, så väl som operatörer med både ett nationellt och ett internationellt nätverk. Urvalet av ISPer täcker också operatörer som är anslutna till alla knutpunkter i Stockholm så väl som bara till en del av knutpunkterna i Stockholm. Data samlades in inte bara från ISPer som deltog i testet men också från ett antal andra insamlingspunkter runt världen. Främst från Packet Clearing House (PCH)
datainsamlingsboxar i London och på USAs öst och västkust. RIPEs Routing Information Services (RIS) box i Stockholm användes också som referens punkt. PCHs insamlingsboxar pratar BGP med ett antal routrar hos olika operatörer, sk peering sessioner, och loggar alla BGP uppdateringar de tar emot. Orsaken till att PCHs boxar används är för att få en samlad bild av BGP uppdateringarna och hur detta påverkar stabiliteten. Vid en förändrad BGP rutt kommer denna att propageras över hela världen. Enda orsaken till att den propageringen kan stoppas upp är om den rutt som en uppdatering annonseras för också täcks av en sk aggregate rutt. Under vissa omständigheter, tex en operatörs nät som använder sig av automatisk aggregering, så kommer den mer specifika ruttens annonsering inte att propageras vidare. Samma sak kan inträffa om den rutt som uppdateras bara är en back-up rutt. Man kan med andra ord säga att de uppdateringar som syns i USA för prefix över knutpunkten kan tolkas som de mer signifikanta och de som verkligen påverkade stabiliteten eftersom andra händelser, även om de syns, kan ha en relativt liten effekt för nåbarheten till Internet i stort. 2.3 Anslutningsmatris De operatörer som deltog i datainsamlandet är anslutna till Internetknutpunkten i Stockholm enligt följande ISP Gigabit DPT-622 DPT-2.5G FDDI Ethernet ISP01 X X ISP02 X X ISP03 X X ISP04 X X ISP05 X X ISP06 X X X IPS07 X X ISP08 X X ISP09 ISP10 X X X X 3 Analys av data 3.1 BGP data Generellt upptäcktes väldigt lite eller ingen aktivitet i det insamlade BPG datat som skulle antyda att större routing händelser inträffat. Detta beror antagligen på ett antal orsaker som går att finna i konstruktionen av knutpunkterna. För SRP ringarna kommer ett fel i någon av dem att hanteras på nivå två. Detta innebär att nivå tre, dvs IP och BGP aldrig kommer at detektera ett länk fel och aldrig generera BGP aktivitet, och därför aldrig att lämna några spår efter sig med BGP updates. I och med att
redundans hanteras på nivå två kommer heller inget att ses på nivå tre, tex via traceroute, om att trafiken tar en annan väg. Enda fallet som kunde leda till att ett fel på SRP ring får att detektera på nivå tre i ett normalfall (dvs, inget fel på anslutna routrar eller på båda ringar) vore om den andra ringen som trafiken faller tillbaka till inte skulle ha tillräckligt med bandbredd för att klara av att hantera den totala trafiklasten ensam. I testerna runt flytten av knutpunkten finns dock inget som tyder på detta. Flytten skedde dock nattetid så det går inte att dra en sådan slutsats. Vissa ISPer rapporterade fördröjningar under flytten men vi har inte sett något sådant i något av våra tester och kan inte förklara detta. Under nivå två konvergensen kan dock en kort tid av fördröjningar och paketförluster uppstå, men detta bör vara under 50ms. Vissa ISPer rapporterade en ökning av trafiken på deras internationella knutpunkter under den tid som flytten varade. Det finns dock inga spår av att rutter skulle ha flyttats till andra knutpunkter i det material som vi samlat in, eller att trafik över Netnods knutpunkter skulle ha minskat under flytten. 3.1.1 Lastgrafer per ISP Följande grafer visar trafik ökning/minskning för de deltagande ISPerna över de olika knutpunkterna de är anslutna till. Flytten skedde i slutet av vecka 44 och flytten är klart synlig i SRP2.5G och Gigabit Ethernet graferna för de operatörer som är anslutna. På grund av skalningen i MRTG programmet som används för att generera graferna blir upplösningen väldigt dålig om man vill ha med jämförelseperioder före och efter flytten. I graferna ser man dock trafiken flytta från A till B sidan. För DPT622 verkar det vara ett problem med interfaceräknarna i Cisco för DPT622 eftersom graferna visar trafik på den ring som är nere. Detta beror antagligen på att räknarna visar den totala lasten per SRP interface och inte per ring. Från graferna verkar det också som om ingen trafik flyttade från Stockholms knutpunk till andra knutpunkter i Sverige eller utomlands. Den mesta trafiken verkar ha stannat i Stockholm och flyttats över till respektive B sida. På Gigabit Ethernet knutpunkten fanns det ett driftsproblem måndagen efter flytten, vilket också syns på graferna. I graferna för SRP är den blå linjen utgående trafik för operatörerna och den gröna är inkommande trafik. I graferna för Gigabit Ethernet är Grön den utgående trafik och blått den ingående trafiken. Notera att A och B referenserna vid graferna korrelerar till namnen på ringarna och inte till de fysiska platsernas namn. Dessa är inte nödvändigtvis de samma. 3.1.1.1 ISP01
STH-DPT-622 A I grafen ser vi lasten hos ISP01 på deras DPT-622 anslutning mot A sidan. För DPT 622 verkar interface räknarna hos Cisco bara beakta det totala trafik flödet över de båda ringarna så någon trafik flytt syns inte. Dock kan man notera att trafiklasten är konstant över flytten så trafiken flyttades ej. STH-DPT-622 B I grafen ser vi lasten hos ISP01 på deras DPT-622 anslutning mot B sidan. För DPT 622 verkar interface räknarna hos Cisco bara beakta det totala trafik flödet över de båda ringarna så någon trafik flytt syns inte. Dock kan man notera att trafiklasten är konstant över flytten så trafiken flyttades ej. STH-DPT-2.5G outer I grafen visas DPT-2.5G anslutningen på den yttre SRP ringen som fanns mot A platsen som flyttades. Här ser man klart och tydligt flytten när trafiken går ner till 0 på Lördagen i vecka 44.
STH-DPT-2.5G inner I grafen ovan ser man hur trafiken under flytten skiftar från Den yttre SRP-2.4G ringen till den inre som visas ovan. GBG-DPT-622 A GBG-DPT-622 B
MAL-DPT-622 A MAL-DPT-622 B De fyra graferna ovan visar lasten på den inre och yttre SRP ringen i Göteborg och Malmö för ISP01. Man kan notera att under flytten sker ingen ökning av trafiken, och man kan dra slutsatsen att ingen trafik flyttades från Stockholm till Göteborg eller Malmö under nertiden på knutpunkten i Stockholm 3.1.1.2 ISP02 STH-DPT-622 A I grafen ser vi lasten hos ISP02 på deras DPT-622 anslutning mot B sidan. För DPT 622 verkar interface räknarna hos Cisco bara beakta det totala trafik flödet över de båda ringarna så någon trafik flytt syns inte. Dock kan man notera att trafiklasten är konstant över flytten så trafiken flyttades ej.
STH-DPT-622 B I grafen ser vi lasten hos ISP02 på deras DPT-622 anslutning mot B sidan. För DPT 622 verkar interface räknarna hos Cisco bara beakta det totala trafik flödet över de båda ringarna så någon trafik flytt syns inte. Dock kan man notera att trafiklasten är konstant över flytten så trafiken flyttades ej. STH-DPT-2.5G outer I grafen visas DPT-2.5G anslutningen på den yttre SRP ringen som fanns mot A platsen som flyttades. Här ser man klart och tydligt flytten när trafiken går ner till 0 på lördagen i vecka 44. STH-DPT-2.5G inner För ISP02 verkar dock en viss trafik obalans mellan inkommande och utgående trafik över ringarna finnas vilket leder till att för den inre ringen syns trafikskiftet som en ökning av utgående trafik.
GBG-DPT-622 A GBG-DPT-622 B MAL-DPT-622 A MAL-DPT-622 B Även här syns i de fyra graferna för Göteborg och Malmö att ingen trafik verkar ha flyttat bort från Stockholm
3.1.1.3 ISP03 Gigabit Ethernet A För Gigabit Ethernet för ISP03 kan man konstatera att trafiken minskar under flytten om dock ganska obetydligt. Den dåliga upplösningen av skalan gör att detta syns väldigt dåligt. Gigabit Ethernet B Här kan man konstatera att ISP03 har mer trafik på B sidan än man har mot A sidan. Detta är antagligen en medveten routing policy. Man kan också konstatera att reservvägen för trafiken inte verkar vara över B knutpunkten eftersom trafiken är mer eller mindre oförändrad under flytten. STH-DPT-2.5G outer
STH-DPT-2.5G inner För ISP 03 ses dock skiftet av trafik från den inre till den yttre SRP2.5G ringen tydligt i de båda graferna ovan. GBG-DPT-622 A GBG-DPT-622 B MAL-DPT-622 A
MAL-DPT-622 B Även för ISP03 kan man av de fyra graferna ovan konstatera att ingen trafik verkar ha skiftat till Göteborg eller Malmö. 3.1.1.4 IPS04 Gigabit Ethernet A ISP04 har i princip ingen trafik alls över A sidan av Gigabit Ethernet knutpunkten. Gigabit Ethernet B Man kan ur grafen ovan för Gigabit Ethernet trafik över B knutpunkten i jämförelse med deras A knutpunkt konstatera att deras routingpolicy antagligen är att utnyttja A endast som
reserv. Det innebär att en utslagen A knutpunkten inte har någon eller väldigt lite effekt för dem. STH-DPT-622 A STH-DPT-622 B Här kan man observera samma fenomen som i de övriga anslutna operatörernas DPT-622, dvs att Ciscos programvara i routern verkar hantera den inre och yttre ringen som en enhet. Detta kan bero på SRR protokollet i SRP. GBG-DPT-622 A
GBG-DPT-622 B MAL-DPT-622 A MAL-DPT-622 B Även för ISP04 kan vi konstatera att ingen trafik flyttats till de övriga knutpunkterna då ingen ökning syns på deras lastgrafer. 3.1.1.5 ISP05
Gigabit Ethernet A Med de två graferna ovan kan man precis som för andra operatörer tidigare, konstatera att ISP05 använder sin anslutning till Gigabit Ethernet A som redundans för sin anslutning till Gigabit Ethernet B vid tidpunkten för flytten. Man kan också anta att operatören har ändrat denna policy i början av vecka 46. Gigabit Ethernet B STH-DPT-622 A STH-DPT-622 B För ISP05 kan man konstatera att trafiken på DPT-622s B anslutning går ner till inget vid tidpunkten för flytten. Detta är den en av de få operatörer där flytten har registrerat s i DPT- 622.
GBG-DPT-622 A GBG-DPT-622 B ISP05 har ingen trafik i Göteborg vid tidpunkten för flytten och man kan också konstatera att ingen trafik verkar flytta över till Göteborg från Stockholm. 3.1.1.6 ISP06 Gigabit Ethernet A
Gigabit Ethernet B ISP06 har ingen trafik över Gigabit Ethernet alls vid tidpunkten för flytten. Trafiken kommer långt senare och därför kan ingen effekt uppmätas av flytten. STH-DPT-622 A STH-DPT-622 B Precis som många andra operatörer tidigare kan man konstatera att vissa Cisco router programvaror inte verkar registrera DPT622 ringarna som två skilda ringar. STH-DPT-2.5G outer I DPT-2.5G fallet ser man dock fortfarande tydligt att ringen tas ned och flyttas till den inre ringen.
STH-DPT-2.5G inner I grafen ser man hur både inkommande och utgående trafik på den inre ringen ökar vid tidpunkten för flytten GBG-DPT-622 A GBG-DPT-622 B MAL-DPT-622 A
MAL-DPT-622 B Inte heller för ISP06 ser man någon ökning av trafiken i Göteborg eller Malmö vid tidpunkten för flytten. 3.1.1.7 ISP07 Gigabit Ethernet A Trots att ISP07 har relativt lite trafik på Gigabit Ethernet A kan man se att vid tidpunkten för flytten går trafiken från ca 7Mbps ner till ingen trafik alls för att gå upp till ca 7Mbps efter flytten. Gigabit Ethernet B Dock är den mängd trafik (ca 7Mbps) så liten att det inte går att utläsa den trafikens skift till Gigabit Ethernet B.
STH-DPT-622 A STH-DPT-622 B Även för ISP07 uppträder fenomenet med räknare för DPT-622. 3.1.1.8 ISP08 Gigabit Ethernet A För ISP08 ser man ett väldigt tydligt fall av trafikvolymen från strax över 4.2Mbps till ingen trafik alls.
Gigabit Ethernet B Det är för ISP08 dock svårare att konstatera att trafiken skiftat då den trafiken är väldigt begränsad. Man kan dock ana sig till att den ökade gröna toppen i grafen vid tidpunkten för flytten är trafiken som skiftat från A knutpunkten. STH-DPT-622 A STH-DPT-622 B För ISP08 visas dock igen ett dropp för DPT-622 id tidpunkten för flytten. Eftersom endast två anslutna operatörers grafer visar detta är det ganska säkert att detta går att hänvisa till ett programvarufel.
GBG-DPT-622 A GBG-DPT-622 B MAL-DPT-622 A MAL-DPT-622 B Även ISP08 visar på avsaknad av att trafik flyttats från Stockholm till Göteborg eller Malmö.
3.1.1.9 IPS09 IPS09 deltog inte i testerna så deras last grafer har också utelämnats. 3.1.1.10 ISP10 Gigabit Ethernet A Gigabit Ethernet B ISP10 har väldigt lite trafik över Gigabit Ethernet så någon säker slutsats går inte att dra av detta, men det verkar som om en top uppträtt på Gigabit Ethernet B vid tidpunkten för flytten. STH-DPT-622 A
STH-DPT-622 B Hos ISP10 ser man dock att trafiken på DPT-622 faktiskt flyttar till den andra ringen vid flytten. STH-DPT-2.5G outer STH-DPT-2.5G inner Även för DPT-622 ser man att lasten flyttar från en ring till den andra vid flytten. Efter flytten verkar dock aldrig trafiken gå tillbaks.
GBG-DPT-622 A GBG-DPT-622 B MAL-DPT-622 A MAL-DPT-622 B Slutligen kan man också av ISP10s grafer för Göteborg och Malmö konstatera att ingen trafik flyttats tid från Stockholm.
3.1.2 BGP aktivitetsgrafer Genom att analysera BGP aktivitet som kan ses totalt och för de prefix som annonseras av operatörerna som deltog i testet, går det att fastställa den inverkan på routing stabilitet och ruttval som flytten hade. Grafen nedan visar den totala BGP aktiviteten som PCHs mätpunkter på USAs öst och västkust har uppmätt. Det finns olika antal peers till de två mätpunkterna vilket förklarar de olika absoluta mätetalen. Man kan notera att ingen speciell aktivitet syns vid tidpunkten för flytten. Detta tyder på att flytten inte ledde till större störningar i Internet som helhet. Om detta hade skett hade vi sett en allmän höjning av BGP aktivitet. De olika linjerna är plottning av antal BGP_WITHDRAWAL och BGP_ANNOUNCEMENT meddelanden som skickats för alla IP näts prefix och som mottagits av den programvara på PCH datorerna som pratar BGP. Följande graf visar den uppmätta aktiviteten för de prefix som de deltagande operatörerna annonserar till andra operatörer vid Netnods knutpunkter vid tidpunkten för flytten.
I grafen ovan kan vi se en hel del aktivitet under dygnet som leder upp till flytten, och vi ser en liten ökning av aktivitet för de prefix som annonseras av Netnods kunder vid tidpunkten för flytten. Ökningen är i princip uteslutande BGP_ADVERTISEMENT och inget är BGP_WITHDRAWAL. Detta beror antagligen på att rutten finns kvar och endast NEXT_HOP uppdateras. NEXT_HOP är dock bara en attribut förändring och genererar inget BGP_WITHDRAWAL meddelande. Detta blir tydligare om vi förstorar tidpunkten för flytten och tittar på vilken typ av BGP meddelanden som ses för prefix annonserade av Netnods kunder under bara tidpunkten för flytten.
Detta visar att under flytten ökade BGP re-advertisment aktiviteten. Detta beror antagligen på att den aktuella rutt eller prefix som påverkas, inte försvinner ur routing tabellen utan bara NEXT_HOP uppdateras som konstaterats tidigare. Om vi jämför BGP withdrawals meddelanden för operatörernas prefix vid Netnod, men den totala mängden withdrawals ser vi
Samma analys för BGP announcements visar 4 Slutsatser För att summera det insamlade datat från flytten kan man konstatera att trafiken tar den väg som den är förväntad att gå vid ett eventuellt bortfall av knutpunkt. Vissa operatörer beslöt att kontrollerat och manuellt flytta trafik medan andra lät deras routing policy ta hand om detta. Båda metoder verkar ha fungerat och gett samma resultat. Den stora majoriteten verkar ha valt att låta sin policy hantera bortfallet. Vi kan också från slutsatserna i fördröjningsmätningarna konstatera att de som tog ned sina anslutningar manuellt troligen var den främsta orsaken till de problem vi såg. Av lastgraferna kan man se att trafiken bara verkar skiftat precis under flytten, vilket också ses i routing datat där BGP_ANNOUNCEMENT ses ganska exakt med när knutpunkten kommit upp igen vilket tyder på att en klar majoritet låtit routing och policy hantera flytten av trafik. Ur redundanssynpunkt kan man konstatera att knutpunkterna i Stockholm står sig väl. Ingen knutpunkt verkar vara kritisk för alla operatörer, och operatörerna har alla valt olika vägar som reserv för den händelse en knutpunkt skulle slås ut. Knutpunkterna täcker också upp för varandra, vilket man klart ser i trafikgraferna ovan. Trafiken stannar i Stockholm om bara en av knutpunkterna går ner. Man kan med andra ord inte riskera att ett bortfall av en knutpunkt i Stockholm skulle kunna överlasta en knutpunkt i en annan del av landet. I den händelse att båda knutpunkter i Stockholm skulle slås ut, kan man anta att trafiken skulle flytta till någon av de andra knutpunkterna i landet. Hur dessa skulle hantera överflyttningen av den fulla trafiklasten från Stockholm är väldigt svårt att säga. Man kan konstatera att de tre andra orterna som Netnod opererar har totalt kapacitet att hantera ett bortfall av Stockholm.
Huruvida trafiken verkligen flyttas dit är upp till operatörerna att hantera via policy beslut. Vi ser redan idag att vissa operatörers trafik som primär väg, eller likvärdig väg, för publik peering använder andra knutpunkter än Netnods. Testdatat visar också att både nivå två och nivå tre verkar uppnå önskade resultat. Nivå två kan utläsas som något effektivare i termer av den tid det tar att uppnå ni BGP konvergens. Orsaken till detta står att finna i att nivå två använder sig av effektivare feldetektering för övervakning av länkar och att nivå två protokoll med inbyggda skyddsmekanismer oftast har en förutbestämd reservväg, och alltså inte behöver beräkna denna vilket nivå tre routingprotokoll behöver. Slutsatsen om snabbare nivå två konvergens stöds också av resultatet i fördröjningstestet som kördes parallellt. Värt att notera är också att modellen med flera knutpunkter i samma stad och i landet verkar ha fungerat mycket väl och så som planerat. Det är dock viktigt att påpeka att testerna gjordes vid en tidpunkt med mycket lite trafik, och det är troligt att ett test vid en tidpunkt då det funnits mer trafik antagligen skulle leda till andra resultat. Förmodligen skulle dock resultatet av ett sådant test mest peka på fördröjningar över DPT-622 ringen i Stockholm, vilket är en känd risk med tanke på den trafik volym som transportas över den i relation till dess kapacitet. 5 Ordlista BGP Border Gateway Protocol Interdomain protokoll. Hanterar vägval mellan autonomasystem och även till viss del inom dessa. Definierat av Internet Engineering Task Force i RFC1771 DPT / SRP Dynamic Packet Transport / Spatial Reuse Protocol Paketbaserad ring teknik skapad av Cisco Systems. Se http://www.cisco.com/warp/public/cc/techno/media/wan/sonet/dpt/dpta_wp.htm FDDI Nivå två protokoll definierat av IEEE. Gigabit Ethernet OSI / TCP/IP modell SRR Singel Ring Redundacy