Två kryptokartor, ett flöde: den senare posten är inte en reserv

Lägg till en andra kryptokart-post för samma adresspar, rikta den mot en annan peer, och du har skrivit en failover-plan. Det är myten, och den överlever eftersom den ser ut som varje annan ordnad lista du har konfigurerat. Ordningen i en kryptokarta avgör vilken post som gör anspråk på ett nytt flöde, inte vilken post som tar över när en peer slutar svara. Ingenting i den listan övervakar den bortre änden, så den andra posten sitter bara där utan att göra anspråk på något.

Myten: ordning betyder reserv

En ordnad lista med två poster och en delad definition känns som primär och sekundär. Likheten slutar vid syntaxen. Ciscos ASA-dokumentation beskriver kryptokartan som policymodellen som matchar skyddad trafik och namnger peer-arrangemanget för den, och matchningen sker mot posten som gör anspråk på flödet först. Tillgängligheten hos en fjärr-peer är inte en del av den bedömningen.

Det du har byggt är en policy som aldrig kommer att konsulteras för det flödet, plus en kommentar i en ändringslogg som hävdar redundans.

Ordningen gör anspråk på flödet, och bara en gång

Varje post innehåller en åtkomstkontrollista eller en definition av ett skyddat flöde, och varje ny utgående paket jämförs med dessa definitioner i ordning. Den första posten vars definition matchar äger flödet och dess peer. En andra post med identisk definition får aldrig en tur, eftersom den första redan matchade; en andra post med snävare definition betjänar bara flöden som den första inte gjorde anspråk på.

Det beteendet är användbart när du medvetet skär ut undantag ur en bred policy, och det är oanvändbart som failover-mekanism. Kontrollera vad som faktiskt hände med show crypto map och show crypto ipsec sa peer, och spåra sedan ett syntetiskt paket genom den väg du tror att det tar. Spårningen namnger posten som gjorde anspråk på det, och det är det enda svaret som spelar roll.

Ruttval och policyägande är separata beslut

En routingtabell svarar på vart paketet vidarebefordras. Kryptopolicyn svarar på vilket skydd och vilken peer som gäller för den valda trafiken. Att duplicera ett käll- och destinationspar under en annan peer ändrar det andra beslutet och lämnar det första orört, så svar kan fortfarande följa den gamla gatewayen medan det utgående paketet tar den nya peeren. Den asymmetrin producerar en tunnel som rapporterar uppe och inte släpper igenom något.

Håll också kontraktet ömsesidigt med den bortre änden: accepterad identitet, skyddade adressområden, en returväg för de intressanta prefixen och tillstånd för tjänsten. Ett alternativt utgående val som den andra sidan inte förväntar sig är inte en alternativ väg, det är hälften av en.

Vad en riktig alternativ väg behöver

Välj en mekanism som är designad för uppgiften: en stödd grupp peer-kandidater, en routad tunnel med en flytande statisk eller dynamisk routing-grannskap över den, eller vilken redundansdesign din plattform än dokumenterar för den tjänsten. Skriv sedan ned vilken komponent som upptäcker felet och vilken komponent som väljer alternativet, för det är två olika funktioner och ofta två olika team.

Adressöversättning kan också ge en plats en andra presenterad adress, men den ändrar samtidigt selektorer, loggning och källbaserade åtkomstregler. Behandla det som ett uttryckligt krav i stället för som en omväg för två tvetydiga poster.

Testa tre tillstånd, inte ett

Konfigurationen är först klar när den har ett försvarbart svar för normal drift, för tillståndet med misslyckad primär och för återgång till primär. Testa alla tre och notera vilken policypost och vilken peer som betjänade var och en. Ett test som stannar efter det första tillståndet bevisar att designen fungerar när ingenting är fel, och det är tillståndet du inte behövde kontrollera.

Skilj också på konfigurerad överlappning och den legitima samexistensen av gamla och nya associationer under en nyckeluppdatering. Flera aktiva SA är normala och tillfälliga; två poster som slåss om ett flöde är permanenta och osynliga.