GCP HA VPN: BGP-sessionen fastnar på Waiting for peer, omkastningen av adressparet
En Cloud VPN BGP-session som fastnat på Waiting for peer har oftast bytt plats på tunnel- och peer-adressen. Kontrollera paret innan du bygger om något.
En BGP-session som aldrig når Established på en Cloud VPN-tunnel är oftast inte ett routingproblem. Det är ett kablingsproblem: två adresser som måste spegla varandra matades in i fel ordning, eller så återanvändes det första parets tunnel på den andra. Själva tunneln kan vara helt frisk medan sessionen står på Waiting for peer, eftersom IPsec och BGP är separata förhandlingar mellan samma två ändpunkter. Avgör vilken av de två som är trasig innan du bygger om något.
En fråga avgör de flesta fall: ser peer-enheten överhuvudtaget Cloud Routerns adress?
Tunnelstatus och sessionsstatus är olika kontroller
IKE och ESP kommer först. Om tunneln inte är upprättad spelar inget inuti den någon roll och diskussionen om BGP-adressen är för tidig. Läs tunnelns status och detaljerade status och läs sedan routerns BGP-peerstatus för samma tunnel.
En tunnel som är uppe medan dess BGP-peer är nere begränsar felet till sessionen: peer-adress, ASN eller TCP 179 som anländer på den inre adressen. En tunnel uppe, en session uppe och fortfarande inga rutter i VPC:n är ett tredje fall. Att ändra adresser hjälper inte där, eftersom sessionen redan fungerar och prefixet helt enkelt inte annonseras eller inte föredras. Att hålla de tre fallen åtskilda är det mesta av arbetet.
Varje tunnel behöver sitt eget /30, med båda ändarna ifyllda
Varje HA VPN-tunnel får ett link-local /30 ur 169.254.0.0/16, med en adress på Cloud Routerns gränssnitt och den andra på din peer. Peer-fältet måste namnge den bortre änden, aldrig routerns egen adress.
Två tunnlar innebär två gränssnitt på Cloud Routern, var och ett med ett annat /30. Att återanvända paret från tunnel 0 på tunnel 1 är felet som ser prydligt ut i en sammanställning och dör i OPEN-paketet.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Läs paret från routerresursen i stället för från konsolsammanfattningen. Sammanfattningen listar peer-adressen i en kolumn som är lätt att läsa fel, och gränssnittets ipRange plus peerens peerIpAddress måste beskriva motsatta ändar av ett och samma /30.
Omkastningen sker oftast vid en ombyggnad
Det är när en tunnel byggs om som par korsas. Den gamla tunnelns peer-adress kopieras in i den nya tunnelns gränssnittsfält, eller så pekas den nya sessionen mot den förra sessionens peer. Hur som helst skickar Cloud Routern OPEN-paket till en adress som nu är den själv eller till en adress utan tunnel bakom.
Skriv ned paren innan du öppnar konsolen: tunnelnamn, gränssnitt, routeradress, peer-adress, peer-ASN. Skapa sedan båda tunnlarna i en enda omgång, så att den andra inte fylls i från den förstas rester.
Tre andra skäl till att en session väntar
Peer-ASN är det första: varje sida måste konfigureras med den andras ASN, och en avvikelse når peeren men upprättas aldrig. Det andra är peerens egen brandvägg, som måste tillåta TCP 179 på tunnelgränssnittet; en IKE- eller ESP-regel täcker inte det. Det tredje är en peer som svarar från en annan källadress än den som konfigurerats som dess granne.
Peerens egen logg är den avgörande. Om dess BGP-sammanfattning inte listar någon granne för den adressen anländer inga paket och paret eller vägen är fel. Om grannen står i Active eller Connect anländer paketen och sessionsparametrarna stämmer inte.
Kontrollera i den ordning paketen färdas
Arbeta utåt: tunnelstatus, sedan routerns BGP-peerstatus, sedan peerens BGP-sammanfattning, sedan rutterna. Om de två första är friska, sluta redigera Cloud VPN-sidan och arbeta på peer-enheten. Om routern rapporterar peeren som nere och din enhet inte har någon granne är paret fel eller så filtreras BGP-porten. En paketinsamling på peerens tunnelgränssnitt avgör det med en blick, eftersom OPEN-paket antingen anländer dit eller aldrig gör det.
gcloud compute routers get-status ROUTER --region=REGION skriver ut peerstatusen bredvid adressen den använder, och det är exakt paret du behöver jämföra.
När sessionen är upprättad, bekräfta att det inlärda prefixet visas i VPC:ns routingtabell och att en värd på varje sida svarar. Skriv sedan ned de slutliga paren bredvid tunnlarnas namn, så att nästa ombyggnad börjar från en verifierad tabell och inte från konsolsammanfattningen.