Välj en stabil registreringskälla för GET VPN-medlemmar

Någon pekar gruppmedlemmens registrering mot en loopback-adress och förklarar att instabiliteten i GET VPN är löst. Ibland stämmer det. Ofta går loopbacken bara att nå från medlemmens egen routingtabell och ingen annanstans ifrån, så registreringen går sönder igen nästa gång uplinken som bar den fladdrar. Registreringsadressen är en identitet i kontrollplanet, och den hjälper bara när en verklig väg finns i båda riktningarna. Att välja den medvetet är värt besväret, och det är en mindre ändring än vad talesättet antyder.

Vad registreringsadressen identifierar

I en GDOI-driftsättning registrerar gruppmedlemmen sig hos nyckelservern och tar emot gruppolicy från den. Adressen som nyckelservern registrerar är medlemmens identitet för det samtalet.

Den identiteten omfattar kontrolsamtalet: registrering, nyckelförnyelse och nedladdning av policyn. Den blir inte källan till kundtrafik, och den ändrar inte vilka gränssnitt som skyddar vilka flöden.

Att hålla de två isär är första steget, eftersom det mesta av förvirringen kring den här inställningen kommer från förväntan att en ändring i kontrollplanet ska laga ett symptom i dataplanet.

En loopback är bara så bra som sin väg

En loopback ger medlemmen en logisk adress som inte försvinner när en fysisk uplink fallerar. Det är en verklig fördel på en router med flera vägar till nyckelservern.

Men det är också bara en adress. Om nyckelservern inte har någon väg tillbaka dit misslyckas registreringen precis som förut. Om medlemmens routingtabell bara når nyckelservern via en uplink är loopbacken stabil och vägen inte.

Kontrollera nåbarheten i båda riktningarna genom varje uplink som du vill ska överleva. En loopback som ligger kvar administrativt uppåt bevisar ingenting om vidarebefordran, och felet visar sig som en onåbar nyckelserver snarare än som ett gränssnittsproblem. Skriv kontrollen som ett kommando per uplink, inte som ett antagande. Då börjar nästa ändringsfönster med bevis i stället för med ett diagram.

Håll kontroll och skyddad trafik åtskilda

Ciscos GDOI-bypass-guide dokumenterar registreringsgränssnittet och förhållandet mellan registrering och hantering av bypass. Läs beteendet för den version du faktiskt kör i stället för att behandla en mening som ett universellt kommando.

Granska filtrering och översättning på kontrollvägen och bekräfta att nyckelhanteringstrafik inte av misstag dras in i en skyddspolicy som beror på just den gruppolicy som den försöker hämta. Ett sådant cirkulärt beroende är ett klassiskt sätt att få en fungerande driftsättning att fallera efter en policyändring.

Policyn för dataplanet är en egen design. Att ändra var registreringen kommer ifrån lämnar de skyddade flödena, selektorerna och bypass-reglerna precis där de var.

Kontrollera identiteten genom övergången

Notera före ändringen gruppen, den valda registreringsadressen, nyckelserverns destination, routingkontexten och den tillåtna kontrollvägen. Efter en godkänd uplink-ändring inspekterar du nyckelserverns vy över registrerade medlemmar och medlemmens kontrolltillstånd igen.

Det du vill se är att den avsedda logiska slutpunkten fortfarande är nåbar och fortfarande representerad som du designade den. Det du inte vill se är en andra registrering från en adress som du inte avsåg, för det är precis så dubbla medlemsposter uppstår.

Testa sedan skyddad applikationstrafik för sig. En överföring kan lyckas medan nästa nyckelförnyelse inte har någonstans att ta vägen, och en lyckad registrering säger ingenting om huruvida ett visst flöde är korrekt valt och routat.

Vad en stabil källa inte åtgärdar

Den tar inte bort dubbla medlemsposter som en tidigare felkonfiguration skapat. Den reparerar inte ett misslyckande i nyckelförnyelsen som orsakats av policyavvikelse mellan medlem och nyckelserver. Den överlever inte ett fel på en fysisk väg som tog bort den enda vägen till nyckelservern.

Det den gör är att ta bort en variabel: identiteten ändras inte längre när en uplink-adress ändras. Det är värt att ha, och det är en rad i en design och inte hela designen.

Ordningen: namnge kontrollvägen, välj en adress med väg i båda riktningarna, bekräfta nyckelserverns vy och testa sedan skyddad trafik separat. Om registreringen fortfarande misslyckas var loopbacken aldrig problemet.