Statiska rutter eller en routingprotokoll över en site-till-site-VPN?

Båda alternativen bär paket mellan platser, så beslutet handlar inte om vilket protokoll som är nyare, och tunnelns storlek avgör det inte heller. Tre förhållanden avgör det: hur många prefix som ändras och hur ofta, om designen behöver automatisk failover mellan vägar, och hur mycket kontrollplansmaskineri teamet klarar att driva klockan tre på natten. Svara ärligt på det och valet brukar göra sig självt. Resten av den här texten är vad varje svar kostar.

Tre förhållanden avgör

Det första förhållandet är ändringstakten. En handfull stabila subnät med tydligt ägarskap kan underhållas för hand i åratal, och varje rutt förblir en rad som någon kan läsa och kontrollera. Dussintals prefix som flyttar sig när projekt kommer och går är ett annat problem, eftersom varje flytt måste nå varje enhet som fortfarande minns den gamla vägen.

Det andra är felbeteende. När en reservväg måste bli aktiv utan att en människa märker det, måste något upptäcka felet och dra tillbaka rutten. Statisk routing kan bara göra det genom spårning eller villkorad installation, och bara för de fel du tänkt igenom i förväg.

Det tredje är aptit på en andra kontrollplan. En routingprotokoll lägger till sessioner, autentisering, filter och urvalspolicy, och var och en av dessa kräver övervakning plus en ändringsprocess. Det är en permanent driftskostnad, inte en engångsuppgift med konfiguration.

Tabellen under tredje stycket är kortversionen, och de tre avsnitten efter den förklarar varför varje rad står där den står. Läs raderna mot ditt eget antal platser innan du väljer, eftersom ett beslut som ignorerar driftskostnaden bara är ett halvt beslut.

Vad statisk routing faktiskt kostar

En statisk rutt måste vara korrekt på båda sidor av tunneln. Att lägga till ett subnät innebär att redigera den avlägsna gatewayen, den lokala gatewayen och vanligtvis returvägen, och att glömma någon av dem ger ett enkelriktat fel som ser ut som en bugg i applikationen. Applikationsteamet ser tidsgränser medan nätverksteamet ser en rutt som finns och verkar frisk. Inget av teamen har fel, och därför tar det så lång tid att placera felet.

En statisk post ligger också kvar installerad efter att vägen under den försvinner. Om plattformen inte levererar spårning pekar rutten vidare mot ett nästa hopp som inte längre vidarebefordrar, och trafiken försvinner i stället för att växla över. Den tystnaden är den kostnad du accepterar när du väljer det enkla alternativet.

Skriv spårningsmetoden bredvid varje rutt, notera vilka fel den täcker, och håll listan tillsammans med tunnelkonfigurationen. Annars upptäcks nästa avbrott av en användare i stället för av nätverket, vilket alltid är den dyrare upptäckten.

Vad dynamisk routing faktiskt kostar

En protokoll annonserar nya prefix, drar tillbaka de som inte går att nå och uttrycker preferens mellan vägar. Det är verkligen användbart när flera platser eller redundanta tunnlar annars skulle kräva samordnade ändringar vid varje förändring. Det är också anledningen till att protokollet kan överraska dig i det sämsta ögonblicket. Var och en av dessa åtgärder är en tillståndsändring som du inte själv gjort.

Den skapar två tillstånd som kan vara oense. Tunneln kan vara uppe medan routing-sessionen är nere, och sessionen kan vara uppe medan dess annonser utelämnar subnätet som applikationen behöver. Båda ser ut som ett nätverk som fungerar halvvägs, och ingen av dem syns från en tunnelstatussida.

Filter och policy blir därför en del av designen i stället för en eftertanke. En protokoll som annonserar allt kommer till slut att annonsera något fel, och det felaktiga prefixet reser snabbare än personen som kan rätta det. Skriv filtren innan den första sessionen aktiveras, så att den första annonsen redan är avsiktlig.

Kontrollera vad routing-sessionen får säga

Bestäm den tillåtna prefixlistan per peer och upprätthåll den vid ingång, eftersom ett utgående filter inte kan hindra en peer från att skicka en standardrutt till dig. Standardrutter och aggregat är de dyra misstagen här: de kan tyst ersätta orelaterade vägar med en enda inlärd post som ser legitim ut. Avvisa dem uttryckligen om inte designen verkligen vill ha dem.

Skriv den ägande platsen bredvid varje nätverk innan den första sessionen kommer upp, eftersom den mappningen är källan till filterlistan och inte en dokumentationsprydnad. Utan den måste den som redigerar ett filter gissa vilken plats som borde annonsera prefixet.

Omfördelning mellan två protokoll är där loopar börjar, och där samma prefix anländer två gånger med attribut som inte jämförs rent. Håll omfördelning utanför designen tills ett specifikt krav tvingar fram den, och om den måste finnas, märk och filtrera rutterna vid gränsen.

Ruttbaserade tunnelgränssnitt gör dynamisk routing lättare att representera, eftersom tunneln blir ett gränssnitt med rutter i stället för en policy som matchar selektorer. Det tar inte bort frågan om peer-omfånget: IPsec-selektorerna måste fortfarande tillåta trafiken du tänker routa.

Testa felfilen, inte den lyckliga vägen

Vad du än väljer, ta ner en upplänk och bekräfta att trafiken flyttar sig, eller att den misslyckas så som du dokumenterat. En design som bara testats med båda vägarna friska är en design som inte testats alls. Mät upptäckten medan du är där, eftersom siffran du mätte är siffran användarna kommer att uppleva.

Bekräfta sedan returvägen oberoende, eftersom asymmetrisk routing över en VPN är vanlig och osynlig tills en tillståndsbevarande enhet släpper svaren. Ett flöde som fungerar i en riktning bevisar bara halva vägen.

Arbetsordning: räkna prefixen, bestäm hur fel ska upptäckas, kontrollera vem som kan driva protokollet, kontrollera vad som annonseras, och testa sedan ett avbrott från början till slut. Varje steg ger ett faktum som nästa steg behöver.