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

Begge muligheder bærer pakker mellem lokationer, så beslutningen handler ikke om, hvilken protokol der er nyest, og tunnelens størrelse afgør den heller ikke. Tre forhold afgør den: hvor mange præfikser der ændres og hvor ofte, om designet kræver automatisk failover mellem stier, og hvor meget kontrolplansmaskineri teamet kan betjene klokken tre om natten. Svar ærligt på det, og valget træffer som regel sig selv. Resten af denne tekst er, hvad hvert svar koster.

Tre forhold afgør det

Det første forhold er ændringstakt. En håndfuld stabile undernet med tydeligt ejerskab kan vedligeholdes manuelt i årevis, og hver rute forbliver en linje, som nogen kan læse og kontrollere. Snesevis af præfikser, der flytter sig, når projekter kommer og går, er et andet problem, fordi hver flytning skal nå hver enhed, der stadig husker den gamle sti.

Det andet er fejlopførsel. Når en backup-sti skal blive aktiv, uden at et menneske bemærker det, skal noget opdage fejlen og trække ruten tilbage. Statisk routing kan kun gøre det via sporing eller betinget installation, og kun for de fejl, du har forudset.

Det tredje er appetit på et andet kontrolplan. En ruteprotokol tilføjer sessioner, godkendelse, filtre og udvælgelsespolitik, og hver af dem kræver overvågning plus en ændringsproces. Det er en permanent driftsomkostning, ikke en engangsopgave med konfiguration.

Tabellen under tredje afsnit er den korte version, og de tre afsnit efter den forklarer, hvorfor hver række står, hvor den står. Læs rækkerne op mod dit eget antal lokationer, før du vælger, fordi en beslutning, der ignorerer driftsomkostningen, kun er en halv beslutning.

Hvad statisk routing faktisk koster

En statisk rute skal være korrekt på begge sider af tunnelen. At tilføje et undernet betyder at redigere den fjerneste gateway, den lokale gateway og normalt returvejen, og at glemme en af dem giver en envejsfejl, der ligner en fejl i applikationen. Applikationsteamet ser timeouts, mens netværksteamet ser en rute, der er til stede og tilsyneladende sund. Intet team tager fejl, og derfor tager denne fejl så lang tid at placere.

En statisk post bliver også installeret, efter at stien under den forsvinder. Medmindre platformen leverer sporing, bliver ruten ved med at pege på et næste hop, der ikke længere videresender, og trafikken forsvinder i stedet for at skifte over. Den tavshed er den udgift, du accepterer, når du vælger den enkle løsning.

Skriv sporingsmetoden ved siden af hver rute, noter hvilke fejl den dækker, og opbevar listen sammen med tunnelkonfigurationen. Ellers bliver næste udfald opdaget af en bruger i stedet for af netværket, hvilket altid er den dyrere opdagelse.

Hvad dynamisk routing faktisk koster

En protokol annoncerer nye præfikser, trækker uopnåelige tilbage og udtrykker præference mellem stier. Det er virkelig nyttigt, når flere lokationer eller redundante tunneler ellers ville kræve koordinerede ændringer ved hver ændring. Det er også grunden til, at protokollen kan overraske dig på det værst tænkelige tidspunkt. Hver af disse handlinger er en tilstandsændring, du ikke selv har foretaget.

Den skaber to tilstande, som kan være uenige. Tunnelen kan være oppe, mens routingsessionen er nede, og sessionen kan være oppe, mens dens annonceringer udelader det undernet, applikationen har brug for. Begge ser ud som et netværk, der kun virker halvt, og ingen af dem er synlige fra en tunnelstatusside.

Filtre og politik bliver derfor en del af designet snarere end en eftertanke. En protokol, der annoncerer alt, vil til sidst annoncere noget forkert, og det forkerte præfiks rejser hurtigere end den person, der kan rette det. Skriv filtrene, før den første session aktiveres, så den første annoncering allerede er bevidst.

Styr, hvad routingsessionen må sige

Beslut den tilladte præfiksliste per peer, og håndhæv den ved indgang, fordi et udgående filter ikke kan forhindre en peer i at sende dig en default-rute. Default-ruter og aggregater er de dyre fejl her: de kan stille erstatte urelaterede stier med en enkelt lært post, der ser legitim ud. Afvis dem udtrykkeligt, medmindre designet virkelig ønsker dem.

Skriv den ejende lokation ved siden af hvert netværk, før den første session kommer op, fordi den mapping er kilden til filterlisten og ikke en dokumentationsudsmykning. Uden den må den person, der redigerer et filter, gætte, hvilken lokation der bør annoncere præfikset.

Redistribution mellem to protokoller er, hvor loops begynder, og hvor det samme præfiks ankommer to gange med attributter, der ikke sammenlignes rent. Hold redistribution ude af designet, indtil et specifikt krav tvinger det, og hvis det skal findes, så markér og filtrér ruterne ved grænsen.

Rutebaserede tunnelinterfaces gør dynamisk routing lettere at repræsentere, fordi tunnelen bliver et interface med ruter i stedet for en politik, der matcher selectors. Det fjerner ikke spørgsmålet om peer-omfang: IPsec-selectors skal stadig tillade den trafik, du har tænkt dig at route.

Test fejlvejen, ikke den glade vej

Uanset hvad du vælger, tag et uplink ned og bekræft, at trafikken flytter sig, eller at den fejler på den måde, du har dokumenteret. Et design, der kun er testet med begge stier sunde, er et design, der slet ikke er testet. Mål registreringstiden, mens du er der, fordi det tal, du målte, er det tal, brugerne vil opleve.

Bekræft derefter returvejen uafhængigt, fordi asymmetrisk routing over en VPN er almindelig og usynlig, indtil en tilstandsfuld enhed dropper svarene. En strøm, der virker i én retning, beviser kun halvdelen af vejen.

Arbejdsrækkefølge: tæl præfikserne, beslut hvordan fejl skal registreres, tjek hvem der kan betjene protokollen, styr hvad der annonceres, og test så et udfald fra ende til anden. Hvert skridt giver en kendsgerning, som det næste skridt har brug for.