Waarom een AWS VGW-subnetroute geen één VPN-tunnel kan kiezen

Twee Site-to-Site VPN-verbindingen eindigen op één virtuele privégateway en adverteren hetzelfde filiaalprefix. De subnetroutetabel bevat één vermelding voor dat prefix, wijzend naar de gateway, en geen veld dat een tunnel benoemt. De voorkeur tussen de verbindingen gebeurt dus ergens wat de console geen routing noemt. Weten welke laag de beslissing bezit is het verschil tussen een werkende standby en een wijziging die niets doet.

Twee lagen zijn in het spel: de VPC-route die zegt welke gateway, en de eigen tunnelkeuze van de gateway. Ze door elkaar halen levert wijzigingen op die er in de routetabel correct uitzien en nooit een pakket verplaatsen.

Twee lagen die er als één uitzien

De subnetroute beantwoordt één vraag: voor deze bestemming, welke koppeling? Het doel is de virtuele privégateway, en de metriek concurreert alleen met andere routes in dezelfde tabel. Niets in die vermelding onderscheidt tunnel één van tunnel twee, of verbinding A van verbinding B. Een specifieker prefix is een andere bestemmingsmatch, geen fijnere padkeuze.

De gateway beantwoordt de volgende vraag: onder de tunnels die hij voor dat prefix houdt, welke draagt nu verkeer. Die beslissing komt van tunnelgezondheid en de BGP-attributen die van de klantgateway worden ontvangen, en ze verschijnt nooit in de subnetroutetabel.

Wat de VGW werkelijk vergelijkt

Gezondheid komt eerst. Een tunnel die neerligt, of een BGP-sessie die niet is opgekomen, verliest voordat enig attribuut wordt bekeken. Daarom verandert het niets om een pad vooraan te zetten op een verbinding die al faalt.

Onder de geschikte paden voor hetzelfde prefix verkiest AWS het kortere AS_PATH. Als twee paden even lang zijn, vergelijkt het MED, onder voorbehoud van de gedocumenteerde voorwaarde over de eerste AS in het pad. Lees de gepubliceerde volgorde in plaats van de folkloreversie, want de folklore laat meestal de gezondheidsstap en de uitzondering voor statische routes weg. Eén gevolg: drie prepends op de back-upverbinding maken de primaire strikt korter, en dat is de gebruikelijke manier om de voorkeur uit te drukken.

Prepend, en wanneer het niets doet

Prepend gebeurt in de uitgaande aankondigingen van de klantgateway, niet binnen AWS. Je voegt je eigen ASN twee of drie keer toe aan het prefix dat AWS moet vermijden, en AWS ziet dan een langer pad voor die verbinding. De primaire verbinding behoudt de aankondiging zonder prepend. Als beide verbindingen adverteren vanuit dezelfde ASN met hetzelfde aantal prepends, heb je geen voorkeur uitgedrukt.

Controleer na de wijziging het ontvangen pad aan de AWS-kant. Een prepend die het klantapparaat nooit heeft verlaten ziet er precies uit als een die AWS heeft genegeerd.

Statische routes negeren het hele argument

Als de verbinding statische routing gebruikt, is er geen AS_PATH om te verlengen. AWS documenteert statische VPN-routes als voorrang hebbend boven via BGP geleerde routes voor hetzelfde prefix, dus een gemengd ontwerp gedraagt zich niet als een volledig dynamisch ontwerp. Bepaal eerst het routingtype en kies dan het voorkeursmechanisme dat ervoor bestaat.

Met twee statische verbindingen die hetzelfde prefix adverteren, is de nuttige hefboom het prefix: adverteer een specifieker bereik op de verbinding die je wilt gebruiken, en accepteer dat je hebt veranderd welke bestemming matcht, niet welk pad wint.

Waarom een transitgateway een ander antwoord is

Een transitgateway ondersteunt equal-cost multipath over VPN-koppelingen, zodat twee verbindingen verkeer kunnen delen in plaats van dat één standby staat. Dat ontwerp heeft een ander faalvlak: stromen verspreiden zich over tunnels, en één tunnel die uitvalt verplaatst slechts een deel van de last. Een VGW-recept kopiëren naar een transitgateway, of omgekeerd, schept verwachtingen die geen van beide platforms nakomt.

Kies het model vóór het mechanisme: actief en standby met een vastgezette voorkeur, of actief en actief met ECMP.

Wat je moet verifiëren nadat je het hebt ingesteld

Bevestig vier dingen in volgorde. De subnettabel lost het prefix nog steeds op naar de bedoelde gateway. De gateway vermeldt beide tunnels als actief. Het ontvangen AS_PATH op de verbinding die je wilt vermijden is langer dan het andere. En een echte stroom van een instantie in dat subnet gaat door de verwachte tunnel, aan beide kanten waargenomen in plaats van afgeleid uit een groene status.

Voer daarna de goedgekeurde failovertest uit en kijk hoe het overlevende pad de dienst draagt. Een voorkeur die alleen in een configuratiediff bestaat is nog geen voorkeur.