To tilstødende /24 smelter pænt sammen til én /23, og den pæne aritmetik overbeviser folk om, at ændringen er kosmetisk. Det er aritmetik om adresser, og tunnelen er ligeglad med andet end selektorer, som er et forhandlingstilbud og ikke en beskrivelse af et netværk. Den kortere linje kan lade den samme trafik være beskyttet, beskytte mere end tilsigtet eller undlade at dække halvdelen af den, alt efter hvad de to parter er villige til at acceptere. At læse det installerede resultat er den eneste måde at vide, hvilken af de tre der skete.

Tre fakta som folk smelter sammen til ét

Adressesættet siger, hvilke værter der skal beskyttes. Grupperingen siger, hvordan disse adresser tilbydes: én selektor eller flere, i én association eller flere. Det forhandlede resultat siger, hvad de to parter faktisk installerede, og det kan være snævrere end nogen af de første to.

Skriv dem adskilt i ændringsnotatet. Én linje konfiguration skjuler ofte tre forskellige svar. En anmelder, der ikke kan skille dem, kan heller ikke godkende ændringen.

Hvad svareren må gøre med din aggregering

En IKEv2-svarer må indsnævre et tilbudt selektorpar til en delmængde, den er villig til at acceptere, og den må afvise tilbuddet helt, hvis intet acceptabelt findes. Den kan også angive, at yderligere trafik kræver en anden association i stedet for at passe ind i denne.

En svarer, der ikke accepterer noget, returnerer i stedet en fejl, hvilket i det mindste siger, at tilbuddet blev afvist og ikke stille indsnævret.

Det betyder, at en vellykket udveksling beviser, at parterne blev enige om noget, ikke at de blev enige om alt, hvad du listede. Den første succesmeddelelse er et udgangspunkt for at læse resultatet, aldrig en konklusion. Den accepterede delmængde kan være mindre end en enkelt /24, hvilket får det installerede sæt til at ligne tilbuddet meget lidt.

Hvor en opsummering stille sletter en grænse

To /24 kan have forskellige serviceregler: den ene tillader måske kun en administrationsprotokol, den anden en generel applikation. En selektor, der dækker begge adresser på IP-niveau, bevarer ikke disse regler, og opsummeringen flytter grænsen ind i den filtrering, der findes bag tunnelen. List servicereglerne pr. undernet, før du aggregerer, ellers sker den sammenligning aldrig.

Protokol- og portværdier er en del af en selektor, ikke et ekstra tilbehør. Hvis den oprindelige politik begrænsede dem, skal aggregeringen bære den samme begrænsning, ellers er ændringen en tilladelsesændring i routing-kostume. Hvis begrænsningen var pointen med den oprindelige politik, så hold den eksplicit efter opsummeringen og sig det i notatet.

At læse resultatet pr. præfiks

Efter ændringen skal du se på det, der blev installeret, i stedet for det, der blev konfigureret. Generér derefter en flow fra hvert præfiks i hver retning, og tjek de tællere, der hører til den association, der håndterer det. To præfikser, der giver trafik på én association, er fine; to præfikser, hvor det ene ikke giver noget, er fundet.

Gør dette med den samme applikation, som brugerne kører. En sonde, der udgår fra gatewayen, tester en anden vej end en klient bag den, og forskellen er præcis der, hvor selektorbugs gemmer sig. En flad tæller på et præfiks, der burde være travlt, er stærkere bevis end nogen loglinje, fordi den måler fravær.

At gøre ændringen reversibel

Behold den oprindelige politik i konfigurationen, indtil den nye er afprøvet fra hver præfikskombination, og noter, hvilken association hver flow landede i. Hvis en part udskifter associationer, når tilbuddet ændres, skal tilbagerulningen gendanne det gamle tilbud og ikke blot de gamle adresser.

Koordiner med ejeren af den anden ende, før vinduet åbner. En opsummering, som den ene side anser for indlysende, kan være en uacceptabel gruppering på den anden, og det er dyrt at opdage under ændringen. Bliv enige om den tilbudte gruppering skriftligt, og sammenlign den derefter med det, udvekslingen installerer. Gem aftalen i ændringsbilletten, ikke i en chattråd, der forsvinder i næste uge.

Relaterede artikler