BGP-aankondigingen van de VGW versus de VPC-routetabel: wat verandert wat

Een ontbrekend prefix in een VPC-subnetroutetabel en een ontbrekend prefix op de router van de klant zijn twee verschillende storingen, en slechts één ervan wordt binnen AWS-routetabellen hersteld. De virtuele privégateway kondigt de CIDR-blokken aan die bij zijn VPC horen; de subnetroutetabel bepaalt waar een workload een antwoord naartoe stuurt. Het tweede behandelen als een manier om het eerste te veranderen is de meest voorkomende verkeerde afslag in deze diagnose. Voer de onderstaande controles in volgorde uit en houd de twee richtingen gescheiden.

Benoem de koppeling voordat je een tabel leest

Een site-to-site-VPN eindigt op een virtuele privégateway of op een transitgateway, en de resource-ID's bepalen welk routeringsmodel geldt. Lees ze eerst: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Het antwoord zegt of de volgende te onderzoeken tabel een VPC-routetabel of een routetabel van de transitgateway is.

Als de VPN aan een transitgateway is gekoppeld, stop dan met het behandelen van de VPC-routetabel als het controlevlak. Daar wijst de VPC-tabel naar de gatewaykoppeling, en associatie en propagatie vinden plaats in de routetabel van de transitgateway. Het mengen van beide weergaven levert stellige conclusies op over het verkeerde object.

De richting van AWS naar kantoor is een aankondiging

Voor een VGW-koppeling kondigt de gateway de CIDR-blokken die bij zijn VPC horen via BGP aan de klantgateway aan. Het toevoegen van een losse subnetroute, of het richten van een route op een peering-VPC of een apparaat, voegt geen ander bijbehorend CIDR toe en verschijnt niet in die aankondiging. Als op kantoor een prefix ontbreekt, vergelijk dan de lijst met ontvangen routes met de VPC-associaties voordat je een routetabel aanpast.

De eenvoudige regel heeft uitzonderingen, dus houd hem binnen zijn bereik. Een VPN CloudHub-opstelling kan siteprefixes opnieuw aankondigen tussen klantgateways, en een transitgateway volgt zijn eigen propagatieregels. De bewering dat een VGW alleen zijn eigen VPC aankondigt is een nuttige standaard, geen wet die elke topologie dekt die je tegenkomt.

De richting van kantoor naar AWS is propagatie plus selectie

In de omgekeerde richting leert de VGW het prefix van kantoor, maar dat alleen verplaatst geen workload. De subnetroutetabel moet ofwel propagatie voor de koppeling hebben ingeschakeld, ofwel een statische route naar dezelfde bestemming bevatten. Als beide voor één prefix bestaan, wint de statische route, en de langste-prefixovereenkomst wordt vóór beide uitgevoerd.

Lees de oorsprong in plaats van hem aan te nemen: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Een vermelding met oorsprong EnableVgwRoutePropagation kwam van BGP; een vermelding met oorsprong CreateRoute is door een mens getypt en blijft winnen tot iemand hem verwijdert.

Een runbook dat de twee richtingen gescheiden houdt

Noteer vier feiten aan de AWS-kant voordat je iets wijzigt: het koppelingstype, de bijbehorende VPC-CIDR's, de oorsprong van de subnetroute voor het betreffende prefix, en de status van de tunnel en BGP. Dezelfde describe-aanroep retourneert VgwTelemetry met een aantal geaccepteerde routes per tunnel, wat je vertelt of AWS überhaupt routes heeft geaccepteerd. Vergelijk dat vervolgens met wat het klantapparaat werkelijk heeft geïnstalleerd. Een prefix die in BGP voorkomt maar in de doorstuurtabel ontbreekt, is een lokaal import- of best-path-probleem, geen AWS-routetabelprobleem.

Als de subnettabel het prefix helemaal mist, schakel propagatie in of voeg een statische route toe, en lees daarna dezelfde query opnieuw na het propagatie-interval in plaats van aan te nemen dat de wijziging direct was. Als het prefix bestaat en verkeer nog steeds faalt, laat het controlevlak met rust en ga naar het datapad.

Wat je daar niet moet wijzigen

Schakel propagatie niet aan of uit op ongerelateerde routetabellen om één ontbrekend prefix te repareren, en voeg geen standaardroute toe om één ontbrekend CIDR te verbergen. Beide wijzigingen vergroten de impact en maken de volgende diagnose moeilijker. Beperk de aanpassing tot de tabel die het betreffende workload-subnet bedient.

Het datapad staat los van dit alles. Beveiligingsgroepen zijn stateful, netwerk-ACL's niet, en een hostfirewall of een asymmetrisch retourpad kan verkeer laten vallen dat de routering correct heeft afgeleverd. Een aangekondigde aggregatie autoriseert ook niet elke dienst erbinnen, dus beperk toegang bij de beleidsgrens in plaats van te vertrouwen op of een adres toevallig in een BGP-aankondiging voorkomt.

Bewaar het voor en na van elke routetabelquery in het wijzigingslogboek. Als de wijziging de situatie verslechtert, herstel de eerdere routes en bevestig met dezelfde query, want een terugdraaiing die je niet kunt verifiëren is slechts een gok.