Statiske ruter eller en ruteprotokoll over en site-til-site VPN?

Begge alternativene bærer pakker mellom lokasjoner, så beslutningen handler ikke om hvilken protokoll som er nyest, og tunnelens størrelse avgjør den heller ikke. Tre forhold avgjør den: hvor mange prefikser som endres og hvor ofte, om designet trenger automatisk failover mellom stier, og hvor mye kontrollplansmaskineri teamet klarer å drifte klokken tre om natten. Svar ærlig på det, og valget tar seg som regel selv. Resten av denne teksten er hva hvert svar koster.

Tre forhold avgjør det

Det første forholdet er endringstakt. En håndfull stabile subnett med tydelig eierskap kan vedlikeholdes manuelt i årevis, og hver rute forblir en linje noen kan lese og kontrollere. Titalls prefikser som flytter seg når prosjekter kommer og går, er et annet problem, fordi hver flytting må nå hver enhet som fortsatt husker den gamle stien.

Det andre er feilatferd. Når en reserverstin må bli aktiv uten at et menneske merker det, må noe oppdage feilen og trekke ruten tilbake. Statisk ruting kan bare gjøre det via sporing eller betinget installasjon, og bare for feilene du har tenkt gjennom på forhånd.

Det tredje er appetitt på et andre kontrollplan. En ruteprotokoll legger til sesjoner, autentisering, filtre og seleksjonspolicy, og hver av disse krever overvåking og en endringsprosess. Det er en permanent driftskostnad, ikke en engangsoppgave med konfigurasjon.

Tabellen under tredje avsnitt er kortversjonen, og de tre delene etter den forklarer hvorfor hver rad står der den står. Les radene mot ditt eget antall lokasjoner før du velger, fordi en beslutning som ignorerer driftskostnaden bare er en halv beslutning.

Hva statisk ruting faktisk koster

En statisk rute må være korrekt på begge sider av tunnelen. Å legge til et subnett betyr å redigere den eksterne gatewayen, den lokale gatewayen og vanligvis returveien, og å glemme en av dem gir en enveis feil som ser ut som en feil i applikasjonen. Applikasjonsteamet ser tidsavbrudd mens nettverksteamet ser en rute som finnes og tilsynelatende er sunn. Ingen av teamene tar feil, og derfor tar denne feilen så lang tid å plassere.

En statisk oppføring blir også stående installert etter at stien under den forsvinner. Med mindre plattformen leverer sporing, peker ruten videre mot et neste hopp som ikke lenger videresender, og trafikken forsvinner i stedet for å svitsje over. Den stillheten er kostnaden du aksepterer når du velger det enkle alternativet.

Skriv sporingsmetoden ved siden av hver rute, noter hvilke feil den dekker, og hold listen sammen med tunnelkonfigurasjonen. Ellers blir neste avbrudd oppdaget av en bruker i stedet for av nettverket, noe som alltid er den dyrere oppdagelsen.

Hva dynamisk ruting faktisk koster

En protokoll annonserer nye prefikser, trekker tilbake de som ikke kan nås og uttrykker preferanse mellom stier. Det er virkelig nyttig når flere lokasjoner eller overflødige tunneler ellers ville kreve koordinerte endringer ved hver endring. Det er også grunnen til at protokollen kan overraske deg på det verste tidspunktet. Hver av disse handlingene er en tilstandsendring du ikke selv har gjort.

Den skaper to tilstander som kan være uenige. Tunnelen kan være oppe mens rutingsesjonen er nede, og sesjonen kan være oppe mens annonseringene utelater subnettet applikasjonen trenger. Begge ser ut som et nettverk som virker halvveis, og ingen av dem er synlige fra en tunnelstatusside.

Filtre og policy blir derfor en del av designet i stedet for en ettertanke. En protokoll som annonserer alt, vil til slutt annonsere noe galt, og det gale prefikset reiser raskere enn personen som kan rette det. Skriv filtrene før første sesjon aktiveres, slik at den første annonseringen allerede er bevisst.

Kontroller hva rutingsesjonen har lov til å si

Bestem den tillatte prefikslisten per peer og håndhev den ved inngang, fordi et utgående filter ikke kan hindre en peer i å sende deg en standardrute. Standardruter og aggregater er de dyre feilene her: de kan stille erstatte urelaterte stier med én lært oppføring som ser legitim ut. Avvis dem eksplisitt med mindre designet virkelig ønsker dem.

Skriv den eide lokasjonen ved siden av hvert nettverk før første sesjon kommer opp, fordi den mappingen er kilden til filterlisten og ikke en dokumentasjonsutsmykning. Uten den må den som redigerer et filter, gjette hvilken lokasjon som bør annonsere prefikset.

Redistribusjon mellom to protokoller er der løkker starter, og der det samme prefikset ankommer to ganger med attributter som ikke sammenlignes rent. Hold redistribusjon utenfor designet til et spesifikt krav tvinger det, og hvis det må finnes, merk og filtrer rutene ved grensen.

Rutebaserte tunnelgrensesnitt gjør dynamisk ruting lettere å representere, fordi tunnelen blir et grensesnitt med ruter i stedet for en policy som matcher selectorer. Det fjerner ikke spørsmålet om peer-omfang: IPsec-selectorene må fortsatt tillate trafikken du har tenkt å rute.

Test feilstien, ikke den glade stien

Uansett hva du velger, ta ned én uplink og bekreft at trafikken flytter seg, eller at den feiler slik du dokumenterte. Et design som bare er testet med begge stier sunne, er et design som ikke er testet i det hele tatt. Mål deteksjonstiden mens du er der, fordi tallet du målte er tallet brukerne vil oppleve.

Bekreft deretter returveien uavhengig, fordi asymmetrisk ruting over en VPN er vanlig og usynlig til en tilstandsbevisst enhet dropper svarene. En flyt som virker i én retning, beviser bare halve stien.

Arbeidsrekkefølge: tell prefiksene, bestem hvordan feil skal oppdages, sjekk hvem som kan drifte protokollen, kontroller hva som annonseres, og test deretter ett avbrudd fra ende til annen. Hvert steg gir et faktum som neste steg trenger.