GCP HA VPN: BGP-sessie blijft hangen op Waiting for peer, de omwisseling van het adrespaar

Een BGP-sessie die op een Cloud VPN-tunnel nooit Established bereikt, is meestal geen routeringsprobleem. Het is een bedradingsprobleem: twee adressen die elkaar moeten spiegelen zijn in de verkeerde volgorde ingevoerd, of het paar van de eerste tunnel is hergebruikt op de tweede. De tunnel zelf kan volledig gezond zijn terwijl de sessie op Waiting for peer staat, omdat IPsec en BGP afzonderlijke onderhandelingen zijn tussen dezelfde twee eindpunten. Bepaal welke van de twee stuk is voordat u iets opnieuw bouwt.

Eén vraag beslist de meeste gevallen: ziet het peer-apparaat het adres van de Cloud Router wel?

Tunnelstatus en sessiestatus zijn verschillende controles

IKE en ESP komen eerst. Als de tunnel niet tot stand is gekomen, doet niets erbinnen ertoe en is de discussie over het BGP-adres voorbarig. Lees de status en de gedetailleerde status van de tunnel en daarna de BGP-peerstatus van de router voor diezelfde tunnel.

Een tunnel die omhoog staat terwijl de BGP-peer omlaag is, beperkt de fout tot de sessie: peer-adres, ASN of TCP 179 dat op het interne adres aankomt. Een tunnel omhoog, een sessie omhoog en nog steeds geen routes in de VPC is een derde geval. Adressen wijzigen helpt daar niet, omdat de sessie al werkt en het prefix simpelweg niet wordt aangekondigd of niet wordt verkozen. Deze drie gevallen uit elkaar houden is het grootste deel van het werk.

Elke tunnel heeft zijn eigen /30 nodig, met beide uiteinden ingevuld

Elke HA VPN-tunnel krijgt een link-local /30 uit 169.254.0.0/16, met één adres op de interface van de Cloud Router en het andere op uw peer. Het peer-veld moet het verre uiteinde benoemen, nooit het eigen adres van de router.

Twee tunnels betekenen twee interfaces op de Cloud Router, elk met een ander /30. Het paar van tunnel 0 hergebruiken op tunnel 1 is de fout die er in een samenvattingstabel netjes uitziet en sterft in het OPEN-pakket.

Lees het paar uit de routerresource en niet uit de consolesamenvatting. De samenvatting vermeldt het peer-adres in een kolom die makkelijk verkeerd te lezen is, en de ipRange van de interface plus het peerIpAddress van de peer moeten tegenovergestelde uiteinden van één /30 beschrijven.

De omwisseling gebeurt meestal tijdens een herbouw

Het is bij het opnieuw bouwen van een tunnel dat paren elkaar kruisen. Het peer-adres van de oude tunnel wordt in het interfaceveld van de nieuwe gekopieerd, of de nieuwe sessie wordt op de peer van de vorige sessie gericht. Hoe dan ook stuurt de Cloud Router OPEN-pakketten naar een adres dat nu zichzelf is of naar een adres zonder tunnel erachter.

Schrijf de paren op voordat u de console opent: tunnelnaam, interface, routeradres, peer-adres, peer-ASN. Maak daarna beide tunnels in één keer aan, zodat de tweede niet uit de resten van de eerste wordt gevuld.

Nog drie redenen waarom een sessie wacht

De peer-ASN is de eerste: elke kant moet met de ASN van de andere kant zijn geconfigureerd, en een verschil bereikt de peer maar komt nooit tot stand. De tweede is de firewall van de peer zelf, die TCP 179 op de tunnelinterface moet toestaan; een IKE- of ESP-regel dekt dat niet. De derde is een peer die antwoordt vanaf een ander bronadres dan het adres dat als zijn buur is geconfigureerd.

Het eigen log van de peer is de discriminator. Als de BGP-samenvatting geen buur voor dat adres vermeldt, komen er geen pakketten aan en is het paar of het pad fout. Staat de buur in Active of Connect, dan komen de pakketten aan en kloppen de sessieparameters niet.

Controleer in de volgorde waarin de pakketten reizen

Werk naar buiten: tunnelstatus, dan de BGP-peerstatus van de router, dan de BGP-samenvatting van de peer, dan de routes. Als de eerste twee gezond zijn, stop dan met het bewerken van de Cloud VPN-kant en werk op het peer-apparaat. Als de router de peer als omlaag meldt en uw apparaat heeft geen buur, dan is het paar fout of wordt de BGP-poort gefilterd. Een pakketopname op de tunnelinterface van de peer beslist het in één oogopslag, omdat OPEN-pakketten daar ofwel aankomen ofwel nooit aankomen.

gcloud compute routers get-status ROUTER --region=REGION drukt de peerstatus af naast het adres dat hij gebruikt, en dat is precies het paar dat u moet vergelijken.

Zodra de sessie tot stand is gekomen, bevestigt u dat het geleerde prefix in de routetabel van de VPC verschijnt en dat één host aan elke kant antwoordt. Leg daarna de definitieve paren naast de tunnelnnamen vast, zodat de volgende herbouw van een gecontroleerde tabel begint en niet van de consolesamenvatting.