Hvorfor en AWS VGW-undernegrute ikke kan vælge én VPN-tunnel

To Site-to-Site VPN-forbindelser terminerer på én virtuel privat gateway og annoncerer det samme grenpræfiks. Undernegrutetabellen har én post for det præfiks, der peger på gatewayen, og intet felt der navngiver en tunnel. Præferencen mellem forbindelserne sker derfor et sted, som konsollen ikke kalder routing. At vide hvilket lag der ejer beslutningen er forskellen mellem en fungerende standby og en ændring, der intet gør.

To lag er i spil: VPC-ruten der siger hvilken gateway, og gatewayens eget valg af tunnel. Forveksler man dem, får man ændringer, der ser korrekte ud i rutetabellen og aldrig flytter en pakke.

To lag der ligner ét

Undernegruten besvarer et enkelt spørgsmål: for denne destination, hvilken vedhæftning? Målet er den virtuelle private gateway, og dens metrik konkurrerer kun med andre ruter i samme tabel. Intet i den post skelner tunnel et fra tunnel to, eller forbindelse A fra forbindelse B. Et mere specifikt præfiks er et andet destinationsmatch, ikke et finere valg af vej.

Gatewayen besvarer det næste spørgsmål: blandt de tunneler, den holder for præfikset, hvilken bærer trafik nu. Den beslutning kommer fra tunnelets sundhed og de BGP-attributter, der modtages fra kundegatewayen, og den optræder aldrig i undernegrutetabellen.

Hvad VGW faktisk sammenligner

Sundhed kommer først. En tunnel, der er nede, eller en BGP-session, der ikke er kommet op, taber, før nogen attribut undersøges. Derfor ændrer det intet at foranstille en sti på en forbindelse, der allerede fejler.

Blandt kvalificerede stier til samme præfiks foretrækker AWS den kortere AS_PATH. Når to stier er lige lange, sammenlignes MED, underlagt den dokumenterede betingelse om den første AS i stien. Læs den offentliggjorte rækkefølge i stedet for folkeversionen, fordi folkeversionen normalt dropper sundhedstrinnet og undtagelsen for statiske ruter. En konsekvens: tre foranstillinger på backupforbindelsen gør den primære strengt kortere, og det er den sædvanlige måde at udtrykke præferencen på.

Foranstilling, og hvornår den intet gør

Foranstilling sker i kundegatewayens udgående annonceringer, ikke inde i AWS. Du tilføjer dit eget ASN to eller tre gange til det præfiks, du vil have AWS til at undgå, og AWS ser så en længere sti for den forbindelse. Den primære forbindelse beholder annonceringen uden foranstilling. Hvis begge forbindelser annoncerer fra samme ASN med samme antal foranstillinger, har du ikke udtrykt nogen præference.

Kontrollér den modtagne sti på AWS-siden efter ændringen. En foranstilling, der aldrig forlod kundeudstyret, ser præcis ud som en, AWS ignorerede.

Statiske ruter ignorerer hele argumentet

Hvis forbindelsen bruger statisk routing, er der ingen AS_PATH at forlænge. AWS dokumenterer statiske VPN-ruter som havende forrang for BGP-lærte ruter til samme præfiks, så et blandet design opfører sig ikke som et fuldt dynamisk. Beslut routingtypen først, og vælg derefter den præferencemekanisme, der findes for den.

Med to statiske forbindelser, der annoncerer samme præfiks, er det nyttige håndtag præfikset: annoncér et mere specifikt interval på den forbindelse, du vil bruge, og accepter, at du ændrede hvilken destination der matcher, ikke hvilken sti der vinder.

Hvorfor en transitgateway er et andet svar

En transitgateway understøtter equal-cost multipath over VPN-vedhæftninger, så to forbindelser kan dele trafikken i stedet for at én står standby. Det design har en anden fejlflade: flows spredes over tunneler, og én tunnel der går ned flytter kun en del af belastningen. Kopierer man en VGW-opskrift over på en transitgateway, eller omvendt, skabes forventninger, som ingen af platformene indfrier.

Vælg modellen før mekanismen: aktiv og standby med en fastlåst præference, eller aktiv og aktiv med ECMP.

Hvad du skal verificere, når du har sat det op

Bekræft fire ting i rækkefølge. Undernegrutetabellen opløser stadig præfikset til den tilsigtede gateway. Gatewayen viser begge tunneler som oppe. Den modtagne AS_PATH på den forbindelse, du vil undgå, er længere end den anden. Og et reelt flow fra en instans i det undernet går gennem den forventede tunnel, observeret i begge ender i stedet for udledt af en grøn status.

Kør derefter den godkendte failovertest og se den overlevende sti bære tjenesten. En præference, der kun findes i en konfigurationsdiff, er endnu ikke en præference.