Kven rutar mellom nettstadene dine: VPN på lag 2 eller lag 3?
Fylg ei leverandør-VPN-overlevering frå tilbod til aksept og sjå kva part som eig rutinga mellom nettstader, nabolaget og den første feilen kvar veg.
Bestill ein leverandør-VPN, og nokon endar opp med å eige rutinga mellom nettstadene, anten du namngav den eigaren eller ikkje. Signer for ei lag 2-overlevering og leverandøren leverer eit røyr medan rutaren din dannar nabolaget; signer for ein lag 3-teneste og leverandøren ber prefiksa dine i sin eigen rutingskontekst. Begge er legitime produkt med ulike vakttelefonhistorier. Gå gjennom bestillinga frå tilbodet til den første aksepttesten, og valet sluttar å vere abstrakt.
Start med overleveringsskjemaet, ikkje med topologiskyen
Kvar leverandør sender før eller sidan eit skjema som spør kva han skal overlevere deg: ein pseudowire, eit multipoint Ethernet-segment eller ei ruta tilkopling på ein delt tenestekant. Det eine svaret avgjer meir enn noko diagram i salspresentasjonen, fordi det fastset kvar ansvaret ditt byrjar.
Ein punkt-til-punkt-pseudowire er éin krins mellom to tilkoplingar, og ein multipoint Ethernet-teneste koplar fleire nettstader i eitt kringkastingsdomene. På eit diagram ser dei like ut og oppfører seg heilt ulikt når ei løkke eller ein kringkastingsstorm er involvert. Stadfest kva som vert tilbode før du planlegg adressering.
Produktnamn avgjer ikkje dette. Ein MPLS-etikett, ei overlevering av mørk fiber og eit internettbasert overlegg kan alle kallast eit privat nett, og rammedokumenta handsamar tenestemodellen og delinga kunde-leverandør som det som må definerast. Be om semantikken til tilkoplinga skriftleg, og les han deretter tilbake til teamet ditt med enkle ord.
Les kva som kom inn på idriftsetjingsdagen
På idriftsetjingsdagen ser du på grensesnittet du fekk før du konfigurerer noko på det. Ei ruta lag 3-tilkopling syner seg vanlegvis som ein port med eit lite punkt-til-punkt-subnett eller som eit neste hopp du må nå. Ei lag 2-tilkopling syner seg som ei lenke som ventar rammer, så den første nyttige kommandoen er ein bru- eller nabo-sjekk i staden for eit ruteoppslag.
ip -br link show
ip -br addr show
ip route show default
ip neigh showDei fire linjene fortel deg kva verd du er i. Ei standardrute som peikar på ein leverandøradresse tyder at leverandøren rutar for deg. Eit grensesnitt utan nyttig lag 3-adresse, men med ei fylt bru, tyder at du vert venta å rute, og kvart manglande prefiks er ditt å rette.
Ei lenke som ser promiskuøs ut kan òg tyde at overleveringa er tagga, så stadfest VLAN-avtala før du klandrar krinsen. Dupliserte MAC-adresser over ein multipoint-teneste er eit designsymptom, ikkje ein leverandørfeil.
Tildel éin eigar per objekt før det første prefikset
Gå gjennom objektlista og sei høgt namnet på teamet som eig kvart enkelt. Kundeprefiks og annonseringane mellom nettstader. Nabolaget eller tenesteidentifikatoren som dannar tilhøvet til leverandørkanten. Kven bryt løkker, og kven har godteke å leve i eitt breiare kringkastingsdomene. Kvar MTU-taket ligg, korleis feil vert oppdaga og korleis tenesta kjem tilbake. Tilgangspolicy, pluss kva kryptering tenesta ikkje inneheld.
Lista er kort fordi det er den delen som bryt saman under ei hending. Viss to team begge trur dei eig rutepolicyen, gir eit avbrot to motstridande endringar i same time. Viss ingen eig han, overlever den første asymmetriske stien til ein kunde rapporterer han.
Ein ruta teneste gir deg vanlegvis ei BGP- eller statisk grense, så sida di treng ein lesbar sesjonstilstand: birdc show protocols eller tilsvarande på rutaren din fortel om nabolaget er oppe, og teljarane fortel om det flappar berre i arbeidstida. Ei lag 2-overlevering gir ikkje eit slikt signal, derfor må kunden eige ein eksplisitt tilgjengelegheitssjekk.
Gå gjennom feiltilfellet for ein nettstad
Skriv aksepttesten før tenesta går live: dropp éi nettstadstilkopling og noter kva kvart team ser. På ein lag 3-teneste trekker leverandøren tilgjengelegheita for prefiksa til den nettstaden tilbake, sesjonen din loggar tilbaketrekkinga, og dei øvrige nettstadene held stiane sine. På ein lag 2-teneste går krinsen ned, rutingsprotokollen din oppdagar ein død nabo, og den same konvergensen avheng heilt av tidtakarane dine.
Gjenopprett lenka og sjekk den andre halvdelen av tilfellet, fordi utdatert tilstand er den vanlege resten. Stadfest at nabolaget kjem tilbake, at prefiksa kjem tilbake med dei forventa attributta, og at inga mellombels statisk rute blir liggjande i tabellen frå hendinga.
Test òg den keisame feilen: ein nettstad som doblar trafikken sin. På ei ruta overlevering ser du teljarar per prefiks; på ei brua ser du kanskje berre gjennomstrøyminga til grensesnittet, noko som lèt deg gjette kva vert som er ansvarleg.
Kva kontrakten ikkje kjøper
Ein lag 2- eller lag 3-etikett seier ingenting om latens, ein dedikert ryggrad eller kryptering. Det er separate forpliktingar, og tilgjengelegheitstal inneber ingen av dei. Les tenesteavtala for det som er lova, og handsam alt anna som ein føresetnad du bør teste.
Viss kravet ditt er ei punkt-til-punkt-tilkopling mellom to kunderutarar, passar ein lag 2-teneste utan å be leverandøren køyre den interne rutinga di. Viss kravet er mange nettstader med ulike subnett og eit lite driftsteam, fjernar ein ruta teneste vanlegvis arbeid du elles ville eigd.
Ingen av dei er standard. Sjekk einingstøtta for innkapslinga, dei faktiske trafikkforholda mellom nettstader, redundansmodellen, og om teamet ditt kan drifte delen det nettopp har akseptert. Skriv deretter eigarnamna i runbooken, fordi det er den einaste delen av avgjerda som overlever bemanningsendringar.