En större VPN-pool är inte en större sessionsgräns

Ett /22 rymmer 1,024 IPv4-adresser, och det talet förväxlas lätt med kapacitet. Det beskriver hur många tilldelningar intervallet kan stödja, inte hur många sessioner gatewayen tar emot eller hur mycket trafik den kan vidarebefordra. Bakom varje svar finns tre separata räkningar, och de fallerar på olika sätt. Det är genom att jämföra dem som en avvisning kopplas till den rätta.

Poolen, rättigheten och arbetsbelastningen räknas i olika enheter och av olika ägare.

Vad poolen faktiskt erbjuder

Börja med de faktiska gränserna i stället för masken. Subnätets topologi avgör hur många adresser servern kan dela ut, fasta tilldelningar och reservationer äter upp en del, och nätverks- och broadcastadressen är otillgängliga. Ett /22 erbjuder 1,024 i princip och färre i praktiken, vilket redan räcker för att bryta den aritmetik folk förväntar sig. Överlapp med nätverk som klienterna måste nå kan utesluta ett intervall som såg generöst ut. Kontrollera att tilldelningsmekanismen stöder det föreslagna intervallet innan du annonserar det.

En större pool tar bort exakt en begränsning. Den rör inte antagningsgränser, licensiering eller vidarebefordringskapacitet, och att utöka ett subnät utan att ändra rutterna och åtkomstpolicyn ger ett intervall som ingen kan nå.

Vad licensen faktiskt tillåter

Plattformens stödda samtidighet och produktens rättighet är ytterligare två tal, och de är ofta inte lika. Rättigheter kan räkna användare, enheter eller samtidiga sessioner, och dessa mått är inte utbytbara. Leverantörernas beställningsguider visar hur olika modellerna kan vara, därför bör peer-antalet från ett gammalt datablad inte föras över till en ny driftsättning. Läs avtalet som gäller för den tjänst du faktiskt driver.

En licens som räknar namngivna användare tar inte emot fler enheter bara för att det finns plats i poolen.

Vad gatewayen faktiskt kan bära

Den tredje räkningen är arbetsbelastningen. Uppskatta trafiken som dessa sessioner skapar tillsammans: paketfrekvenser, autentiseringsutbrott, krypteringskostnad och vilka policyfunktioner som är påslagna. Interaktiva sessioner och stora överföringar landar mycket olika på samma maskin. En gateway kan ha lediga adresser och licensierad antagning tillgänglig medan den avsedda belastningen överstiger vad den kan vidarebefordra. Kapacitetsplanering som bortser från funktionsuppsättningen ger ett tal som bara håller i ett laboratorium med allt avstängt.

En avvisning är ögonblicket för att se vad gatewayen loggade för det försöket: en tilldelningshändelse, ett antagningsbeslut eller ett fastnat autentiseringsanrop. Dessa tre kräver olika rättelser, och gissningar från klientsidan träffar sällan den rätta.

Tillskriv avvisningen innan du ändrar något

Jämförelsen som är användbar är mellan de tre räkningarna och felet som observerades. Är poolen full, utöka den och uppdatera rutterna och policyn som beskriver den. Avvisas antagning medan adresser återstår, ligger begränsningen någon annanstans. Tas sessionerna emot och prestandan kollapsar, är problemet kapacitet och inte någon av de två gränserna.

Notera vilken räkning som tog slut, när det hände och vad som förändrades efteråt. Den anteckningen hindrar nästa utredning från att börja om vid subnätmasken.

Att utöka en pool är en ändring på en rad med en tredelad uppföljning: rutter, policy och ett nytt test.