Waarom ’n AWS-VGW-subnetroete nie een VPN-tonnel kan kies nie

Twee Site-to-Site-VPN-verbindings eindig op een virtuele privaatpoort en adverteer dieselfde takvoorvoegsel. Die subnetroetetabel hou een inskrywing vir daardie voorvoegsel, wat na die poort wys, en geen veld wat ’n tonnel noem nie. Voorkeur tussen die verbindings gebeur dus iewers wat die konsole nie as roetering benoem nie. Om te weet watter laag die besluit besit, is die verskil tussen ’n werkende bystand en ’n verandering wat niks doen nie.

Twee lae is in die spel: die VPC-roete wat sê watter poort, en die poort se eie keuse van tonnel. Om hulle te verwar lewer wysigings wat in die roetetabel korrek lyk en nooit ’n pakkie beweeg nie.

Twee lae wat soos een lyk

Die subnetroete beantwoord ’n enkele vraag: vir hierdie bestemming, watter aanhegsel? Sy teiken is die virtuele privaatpoort, en sy metriek kompeteer net met ander roetes in dieselfde tabel. Niks in daardie inskrywing onderskei tonnel een van tonnel twee, of verbinding A van verbinding B nie. ’n Meer spesifieke voorvoegsel is ’n ander bestemmingspassing, nie ’n fyner padkeuse nie.

Die poort beantwoord die volgende vraag: onder die tonnels wat hy vir daardie voorvoegsel hou, watter een dra tans verkeer. Daardie besluit kom van tonnelgesondheid en die BGP-eienskappe wat van die kliëntpoort ontvang is, en dit verskyn nooit in die subnetroetetabel nie.

Wat die VGW werklik vergelyk

Gesondheid kom eerste. ’n Tonnel wat af is, of ’n BGP-sessie wat nie opgekom het nie, verloor voordat enige eienskap ondersoek word. Daarom verander dit niks om ’n pad voor te voeg op ’n verbinding wat reeds faal nie.

Onder geskikte paaie vir dieselfde voorvoegsel verkies AWS die korter AS_PATH. Wanneer twee paaie ewe lank is, vergelyk dit MED, onderhewig aan die gedokumenteerde voorwaarde oor die eerste AS in die pad. Lees die gepubliseerde volgorde eerder as die volksverhaal-weergawe, want die volksverhaal laat gewoonlik die gesondheidstap en die statiese-roete-uitsondering weg. Een gevolg: drie voorvoegsels op die rugsteunverbinding maak die primêre een streng korter, wat die gewone manier is om die voorkeur te stel.

Voorvoeging, en wanneer dit niks doen nie

Voorvoeging gebeur op die kliëntpoort se uitgaande advertensies, nie binne AWS nie. Jy voeg jou eie ASN twee of drie keer by die voorvoegsel wat jy wil hê AWS moet vermy, en AWS sien dan ’n langer pad vir daardie verbinding. Die primêre verbinding hou die advertensie sonder voorvoeging. As beide verbindings van dieselfde ASN met dieselfde voorvoegingstelling adverteer, het jy glad geen voorkeur uitgespreek nie.

Kontroleer die ontvangde pad aan die AWS-kant ná die verandering. ’n Voorvoeging wat nooit die kliënttoestel verlaat het nie, lyk presies soos een wat AWS geïgnoreer het.

Statiese roetes ignoreer die hele argument

As die verbinding statiese roetering gebruik, is daar geen AS_PATH om te verleng nie. AWS dokumenteer statiese VPN-roetes as prioritêr bo BGP-geleerde roetes vir dieselfde voorvoegsel, so ’n gemengde ontwerp gedra hom nie soos ’n heeltemal dinamiese een nie. Besluit eers die roeteringstipe, kies dan die voorkeurmeganisme wat daarvoor bestaan.

Met twee statiese verbindings wat dieselfde voorvoegsel adverteer, is die nuttige hefboom die voorvoegsel: adverteer ’n meer spesifieke reeks op die verbinding wat jy wil gebruik, en aanvaar dat jy verander het watter bestemming pas eerder as watter pad wen.

Waarom ’n transitpoort ’n ander antwoord is

’n Transitpoort ondersteun gelykekoste-multipad oor VPN-aanhegsels, so twee verbindings kan verkeer deel in plaas daarvan dat een standby staan. Daardie ontwerp het ’n ander falingsoppervlak: strome versprei oor tonnels, en een tonnel wat afgaan skuif net deel van die las. Om ’n VGW-resep op ’n transitpoort te kopieer, of omgekeerd, skep verwagtinge wat geen van die platforms nakom nie.

Kies die model voor die meganisme: aktief en bystand met ’n vasgepen voorkeur, of aktief en aktief met ECMP.

Wat om te verifieer nadat jy dit gestel het

Bevestig vier dinge in volgorde. Die subnettabel los die voorvoegsel steeds op na die bedoelde poort. Die poort lys beide tonnels as op. Die ontvangde AS_PATH op die verbinding wat jy wil vermy, is langer as die ander een. En ’n werklike stroom van ’n instansie in daardie subnet beweeg deur die verwagte tonnel, waargeneem aan beide kante eerder as afgelei uit ’n groen status.

Voer dan die goedgekeurde oorskakelingstoets uit en kyk of die oorblywende pad die diens dra. ’n Voorkeur wat net in ’n konfigurasieverskil bestaan, is nog nie ’n voorkeur nie.