GCP HA VPN: a BGP munkamenet beragad a Waiting for peer állapotba, a címpár felcserélése

Az a BGP munkamenet, amely soha nem éri el az Established állapotot egy Cloud VPN alagúton, általában nem útválasztási probléma. Kábelezési probléma: két címet, amelyeknek tükrözniük kell egymást, rossz sorrendben vittek be, vagy az első alagút párját használták újra a másodikon. Maga az alagút teljesen egészséges lehet, miközben a munkamenet a Waiting for peer állapotban áll, mert az IPsec és a BGP külön tárgyalás ugyanazon két végpont között. Döntse el, melyik a kettő közül romlott el, mielőtt bármit újjáépítene.

Egy kérdés eldönti a legtöbb esetet: látja egyáltalán a peer eszköz a Cloud Router címét?

Az alagút állapota és a munkamenet állapota két külön ellenőrzés

Először az IKE és az ESP jön. Ha az alagút nincs létrehozva, semmi sem számít benne, és a BGP címéről szóló vita korai. Olvassa el az alagút állapotát és részletes állapotát, majd az útválasztó BGP peer állapotát ugyanarra az alagútra.

Az az alagút, amely fent van, miközben a BGP peerje lent van, a munkamenetre szűkíti a hibát: peer cím, ASN vagy a belső címre érkező TCP 179. Alagút fent, munkamenet fent és még mindig nincs útvonal a VPC-ben ez a harmadik eset. A címek módosítása ott nem segít, mert a munkamenet már működik, és a prefixet egyszerűen nem hirdetik vagy nem részesítik előnyben. Ennek a három esetnek a szétválasztása a munka nagy része.

Minden alagútnak saját /30 kell, mindkét vég kitöltve

Minden HA VPN alagút kap egy link-local /30-at a 169.254.0.0/16 tartományból, az egyik cím a Cloud Router interfészen, a másik a peerjén. A peer mezőnek a távoli véget kell megneveznie, soha nem az útválasztó saját címét.

Két alagút két interfészt jelent a Cloud Routeren, mindegyiket más /30-mal. A 0 alagút párjának újrahasználata az 1 alagúton az a hiba, amely összefoglaló táblázatban rendezettnek látszik, és az OPEN csomagban hal meg.

A párt az útválasztó erőforrásából olvassa ki, ne a konzol összefoglalójából. Az összefoglaló olyan oszlopban sorolja fel a peer címet, amelyet könnyű félreolvasni, és az interfész ipRange-je plusz a peer peerIpAddress-e egyetlen /30 átellenes végeit kell leírnia.

A felcserélés általában újjáépítés közben történik

Az alagút újjáépítésekor keresztezik egymást a párok. A régi alagút peer címe átkerül az új alagút interfész mezőjébe, vagy az új munkamenet az előző munkamenet peerjére mutat. Így vagy úgy, a Cloud Router OPEN csomagokat küld egy olyan címre, amely most ő maga, vagy olyan címre, amely mögött nincs alagút.

Írja fel a párokat a konzol megnyitása előtt: alagút neve, interfész, útválasztó címe, peer címe, peer ASN. Ezután hozza létre mindkét alagutat egy menetben, hogy a második ne az első maradékaiból töltődjön ki.

Három további ok, amiért egy munkamenet vár

A peer ASN az első: mindkét oldalt a másik oldal ASN-jével kell konfigurálni, és az eltérés eljut a peerig, de soha nem épül fel. A második a peer saját tűzfala, amelynek engedélyeznie kell a TCP 179-et az alagút interfészen; egy IKE vagy ESP szabály ezt nem fedi le. A harmadik egy olyan peer, amely más forrás címről válaszol, mint amelyet szomszédjaként konfiguráltak.

A peer saját naplója a döntő. Ha a BGP összefoglalója nem sorol fel szomszédot ehhez a címhez, a csomagok nem érkeznek meg, és a pár vagy az útvonal hibás. Ha a szomszéd Active vagy Connect állapotban van, a csomagok megérkeznek, és a munkamenet paraméterei nem egyeznek.

Abban a sorrendben ellenőrizze, ahogy a csomagok haladnak

Dolgozzon kifelé: alagút állapota, majd az útválasztó BGP peer állapota, majd a peer BGP összefoglalója, majd az útvonalak. Ha az első kettő egészséges, hagyja abba a Cloud VPN oldal szerkesztését, és dolgozzon a peer eszközön. Ha az útválasztó lentként jelenti a peert, és az eszközén nincs szomszéd, a pár hibás, vagy a BGP port szűrve van. Egy csomagrögzítés a peer alagút interfészén egy pillantással eldönti, mert az OPEN csomagok vagy megérkeznek oda, vagy soha.

A gcloud compute routers get-status ROUTER --region=REGION a peer állapotát az általa használt cím mellé nyomtatja, és ez pontosan az a pár, amelyet össze kell hasonlítania.

Miután a munkamenet felépül, ellenőrizze, hogy a megtanult prefix megjelenik-e a VPC útvonaltáblázatában, és hogy oldalanként egy gazdagép válaszol-e. Ezután jegyezze fel a végleges párokat az alagutak neve mellé, hogy a következő újjáépítés egy ellenőrzött táblázatból induljon, ne a konzol összefoglalójából.