Skala VPN-sessioner efter roll och kontrollera sedan felreserven

Du lägger till en andra gateway, konsolen visar två friska medlemmar och sessionstaket rör sig knappt, eftersom ingenting berättade för klienterna hur de når den nya enheten. Att skala en VPN-tjänst är två beslut i följd: vilken mekanism som fördelar klienter för den här anslutningstypen och hur mycket kapacitet som återstår efter den värsta enskilda förlusten. Tar du dem i omvänd ordning får du en design som ser redundant ut och fallerar precis när den behövs. Börja vid konsolen och gör sedan aritmetiken.

Anpassa mekanismen till sessionstypen

Fjärranvändare, site-till-site-peers och alltid påslagna enhetstunnlar är inte utbytbara sessioner. En distributionsfunktion byggd för en av dem omdirigerar normalt en klient under förhandlingen, vilket inte betyder något för en peer som redan har en fast adress och en statisk konfiguration.

Ciscos guide för hög tillgänglighet för ASA håller tre förmågor åtskilda: lastbalansering för fjärråtkomst-VPN, tillståndsbevarande failover och site-till-site-klustring. Bara den första flyttar en lämplig klient från en gruppost till en medlem, och LAN-till-LAN-anslutningar stannar utanför den fördelningen. En generisk TCP-lastbalanserare kan inte ersätta protokollets eget omdirigeringssteg, eftersom tunnelns handskakning inte är vanlig HTTP som en proxy kan skriva om. Det praktiska resultatet är en lastbalanserare som accepterar anslutningen och ändå lämnar klienten utan möjlighet att tunnla.

Läs funktionslistan mot din sessionstyp innan du beställer en andra enhet. Licensraden och mekanismraden är separata poster, och den ena innebär inte den andra.

Räkna igenom exemplet i stället för att gissa

Anta att tre gateways vardera är validerade på 800 samtidiga tunnlar under den belastning du godkänt, vilket ger 2,400 totalt. Ett mål på 1,650 under rusningstimmen verkar bekvämt tills en enhet förloras, och då måste det överlevande paret hålla 1,650 mot hårda 1,600. Designen har redan misslyckats, och ingen failover-justering reparerar aritmetiken.

Sätt målet så att den överlevande uppsättningen fortfarande klarar det, vilket för en grupp på tre medlemmar innebär att ligga under två tredjedelar av totalen. Det förhållandet är en egenskap hos aritmetiken och inte hos någon produkt, så räkna om det när en medlems validerade siffra ändras. Håll det licensierade antalet, det dokumenterade maximumet och din egen uppmätta siffra i tre kolumner, eftersom de sällan stämmer överens och den minsta styr. En fjärde kolumn för den observerade rusningstoppen håller planen ärlig efter den första månaden.

Budgetera återanslutningsvågen, inte bara det stabila läget

Sessioner på en misslyckad medlem dyker inte tyst upp någon annanstans. Beroende på mekanismen flyttas de över med tillstånd, förhandlar om från början eller väntar på att applikationen försöker igen enligt sitt eget schema.

Några tusen klienter som försöker igen inom en minut är en annan händelse än en stabil 1,650, och autentiseringsservrarna känner av det först. Kontrollera även poolutrymmet, eftersom omdirigeringen inte rådfrågar det: en medlem som inte kan tilldela en adress accepterar ändå klienten och släpper sedan dess trafik.

Verifiera kapaciteten med poolen och vägen till hands

Verifieringen är en ren läsövning som fångar de flesta designfel innan ett underhållsfönster öppnas. Samla in poolen per medlem, antalet aktiva sessioner och vägen tillbaka till klientens subnät och jämför varje med planen. Uttömning av poolen och en saknad returväg visar sig båda som en klient som autentiserar sig och sedan tappar trafik.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Kör de läsningarna mot varje medlem under en normal rusningstimme och inte en lugn. En medlem som rapporterar sessioner men saknar lediga adresser är redan vid sin praktiska gräns, vad licensen än säger. Notera firmwareversionen bredvid varje utdata, eftersom kommandonamn förskjuts mellan versioner.

Öva förlusten en gång med avsikt, utanför kontorstid, och registrera vad de överlevande medlemmarna rapporterar medan det sker. En medlem som accepterar omdirigeringen men saknar poolutrymme visas som misslyckad tilldelning, vilket extra bandbredd aldrig åtgärdar. Spara de validerade siffrorna med datumet bredvid planen, så att nästa kapacitetsgranskning börjar med bevis i stället för ett licensark. Lägg till resultatet av den övningen på samma sida, även när siffrorna stämmer med planen.