Bakit hindi kinokontrol ng BGP sa ibabaw ng VPN ang ruta ng underlay

Dalawang site ang nag-peer ng BGP sa ibabaw ng IPsec tunnel, natututo ng mga prefix ng isa't isa, at ang diagram ay muling pinangalanang kontrol sa ruta. Iyon mismong label ang simula ng kalituhan. Ang sesyon ay nagpapalitan ng maabot at naglalapat ng patakaran, ngunit wala itong boses kung aling provider, cable o router ang nagdadala ng mga naka-encrypt na packet. May nakita akong team na muling itinatayo ang gumaganang tunnel dahil inaasahan nilang ililipat ng pagbabago sa rutang BGP ang trapiko sa isa pang fiber na ruta na hindi kailanman kayang impluwensyahan ng sesyon.

Ano ang inaakala ng mga tao na binibili ng sesyon

Karamihan ng inaasahan ay nagmumula sa hitsura ng pagbabago sa ruta sa laboratoryo. Nag-aanunsyo ka ng prefix sa tunnel, ini-install ito ng malayong panig, at gumagalaw ang trapiko. Ang parehong pagkakasunod-sunod ay nangyayari sa router na talagang may mga kontrol sa traffic engineering, kaya napagkakamalan ang dalawa. Sa laboratoryo, karaniwang nagbabahagi ang dalawang site ng isang access link, at iyon ang dahilan kung bakit hindi kailanman lumilitaw ang pagkakaiba doon.

Ang BGP ay isang protocol ng maabot. Sinasabi nito sa isang peer na makapaghahatid ka ng mga packet para sa isang prefix at hinahayaan ang bawat panig na ihanay ang mga alok na natatanggap nito. Talagang kapaki-pakinabang ito sa ibabaw ng tunnel: lumilitaw at nawawala ang mga prefix habang dumarating at umaalis ang mga site, at maaari mong tanggihan ang isang saklaw nang hindi nagsusulat ng static na ruta sa bawat edge device. Ang hindi nito ginagawa ay ilagay ang mga router ng provider sa ilalim ng iyong kontrol.

Ang underlay ang nagdadala ng panlabas na header. Ipinapadala ng iyong tunnel endpoint ang mga naka-encrypt na packet sa address ng peer, at ipinapasa ito ng network sa pagitan ng dalawang address na iyon gamit ang mga rutang ini-install ng mga operator nito. Walang anuman sa sesyon ng BGP ang nagbabago sa desisyong iyon, maliban kung ang parehong provider ay nag-aalok ng sinusuportahang serbisyo na gumagawa niyon.

Ano ang talagang dinadala ng sesyon

Binubuksan ng BGP speaker ang koneksyon ng TCP sa port 179 ng peer nito, gamit ang mga format ng mensahe at attribute ng ruta na tinukoy sa RFC 4271. Kapag ang address ng peer ay nasa loob ng tunnel, dapat nakataas ang tunnel at maabot ang address bago pa man magsimula ang sesyon. Ang natapos na palitan ng IKE ay hindi kapitbahay ng BGP. Ang mga implementasyon ng IPsec na nakabatay sa ruta ay nagpapadaan ng trapiko kapag may tumutugmang ruta ng tunnel, at ang nakabatay sa patakaran ay nangangailangan ng address ng peer sa loob ng protektadong selector. Ang baligtarin ito ay lumilikha ng klasikong kalagayan kung saan berde ang tunnel at nakaupo lang ang sesyon.

Kapag nakataas na ang sesyon, ang patakaran ang nagpapasya kung ano ang tumatawid dito. Ang mga listahan ng prefix, filter ng AS-path, kisame sa pinakamataas na bilang ng prefix at malinaw na desisyon sa default na ruta ang pinakamababa, at nalalapat ito sa dalawang direksyon. Ang peer na tumatanggap ng lahat ng natatanggap ay maaaring magbigay ng default na ruta na tahimik na pumapalit sa lokal na access sa internet. Ang dalawang direksyon ay nangangailangan ng magkahiwalay na listahan, dahil ang tinatanggap mo mula sa peer at ang inaanunsyo mo rito ay dalawang magkaibang desisyon.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Pagkatapos ay kumagat ang MTU. Binabawasan ng encapsulation ang kapaki-pakinabang na payload, kaya ang malaking update ay maaaring huminto sa sesyon na mukhang ganap na naitatag: nananatiling nakataas ang peer, hindi dumarating ang mga prefix at walang halatang nahuhulog sa log. Limitahan ang TCP MSS sa interface ng tunnel, o magtakda ng MTU ng tunnel na may espasyo para sa overhead, bago sisihin ang mga filter.

Saan pa rin pumupunta ang mga panlabas na packet

Ang mga naka-encrypt na packet mula sa isang site patungo sa isa pa ay lumalabas sa pinipili ng lokal na router para sa pampublikong address ng peer. Kung ang dalawang site ay bumili ng transit mula sa parehong provider, tumatawid sa parehong pasilidad ng metro, o nasa likod ng carrier-grade NAT ang isang panig, ang tunnel ay nakakaligtas sa pagkabigo ng provider nang nagkataon lamang. Ang pagbilang ng mga icon ng tunnel sa tool sa pagsubaybay ay walang sinasabi sa iyo tungkol dito.

Ang pagpili ng ruta at pag-install ng forwarding ay magkahiwalay ding pangyayari. Ang prefix ay maaaring nakaupo sa talahanayan ng BGP bilang pinakamahusay at kulang pa rin sa talahanayan ng forwarding, dahil hindi malulutas ang susunod na hop o nananalo ang mas partikular na ruta. Kapag may nag-ulat na natutunan ng BGP ang prefix ngunit hindi dumadaloy ang trapiko, ang kapaki-pakinabang na tanong ay kung naka-install ito at sa aling susunod na hop ito nakaturo.

Ang tapat na sagot para sa pagsusuri ng disenyo ay isang listahan ng mga pinagsasaluhang dependency: circuit ng access, upstream provider, pasilidad at anumang device na may state sa return path. Ang sesyon sa ibabaw ng tunnel ay hindi maaaring mag-alis ng dependency na hindi niya kinauupuan.

Tatlong desisyong sulit ihiwalay

Kapag hinalo ng disenyo ang mga ito, ang bawat usapan sa pagkabigo ay umiikot. Ihiwalay muna ang mga ito sa papel, pagkatapos iugnay ang bawat isa sa device na talagang nagpapatupad nito.

Bawat hilera ay may ibang may-ari. Ang una ay negosasyon, ang pangalawa ay configuration sa iyong mga device, ang pangatlo ay kadalasan network ng iba. Ang kahilingan sa pagbabago na nagpapangalan sa hilerang hinahawakan nito ay mas madaling aprubahan kaysa sa nagsasabing problema sa BGP.

Mga mode ng pagkabigo na sulit planuhin

Ang pagtanggap ng summary route ng peer ang pinakakaraniwang self-inflicted na sugat. May nag-aanunsyo ng maikling aggregate para pasimplehin ang palitan, tinatanggap ito ng malayong panig, at ang trapiko para sa mga saklaw na wala sa likod ng tunnel ay sumusunod sa tunnel at namamatay. I-filter sa eksaktong inaasahang prefix, o gumamit ng listahan ng prefix na may tamang hangganan, at huwag kailanman tumanggap ng hubad na aggregate dahil ginagawang maayos ang sesyon.

Ang oras ng pag-withdraw ay ang pangalawa. Ang pagtuklas ay nakadepende sa hold timer, sa BFD kung pinagana mo ito, sa dead peer detection ng tunnel at sa bilis ng pagtigil ng malayong panig sa pag-anunsyo. Ang mga umiiral na sesyon ay hiwalay na problema: ang bagong ruta ay maaaring magpanumbalik ng mga bagong koneksyon habang ang mga naitatag na sesyon ng TCP ay patuloy na gumagamit ng lumang address, at ang mga firewall na may state o NAT sa ruta ay maaaring magtago ng mga entry na hindi na tumutugma. Ilagay ang pagbawi ng aplikasyon sa mga pamantayan sa pagtanggap sa halip na ipagpalagay na inaayos ng pagbabago sa ruta ang lahat.

Ang pangatlo ay asymmetry ng return path. Ang trapiko ay maaaring dumating sa tunnel at bumalik sa link ng provider na hindi kailanman nilayon na magdala nito, na lumilitaw bilang one-way na audio, bigong handshake o firewall na nagtatapon ng mga sagot. Suriin ang dalawang direksyon nang hiwalay.

Ano ang isusulat sa kontrata, at paano ito i-verify

Humingi ng nakasulat na mga pinapayagang prefix: sino ang awtorisadong gumawa ng bawat saklaw, kung pinapayagan ang default na ruta at aling mga address family ang sinusuportahan ng serbisyo ng tunnel. Ginawa ng RFC 8212 ang malinaw na patakaran sa import at export na inaasahan para sa eBGP sa mga implementasyong sumusunod dito, kaya ang peer na umaasa pa rin sa implicit na tanggapin-lahat ay sulit tanungin.

Pagkatapos ay i-verify mula sa device at hindi mula sa diagram. Mga kapaki-pakinabang na command sa mga router na istilong FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Magdagdag ng dalawang obserbasyon na hindi maibibigay sa iyo ng talahanayan ng ruta. Kunan sa panlabas na interface upang kumpirmahin kung aling address ang talagang pinupuntirya ng mga naka-encapsulate na packet, halimbawa tcpdump -ni eth0 udp port 51820 para sa tunnel ng WireGuard, o filter ng ESP para sa IPsec. Pagkatapos ay i-trace patungo sa pampublikong address ng peer at ihambing ang mga hop sa isang trace sa loob ng tunnel; kung pareho silang sumusunod sa parehong chain ng provider, ang redundancy mo ay nabubuhay sa patakaran ng ruta at hindi sa network.

Sa huli, sadyang subukan ang pag-withdraw. Ibaba ang tunnel sa maintenance window, itala kung gaano katagal nananatiling naka-install ang prefix, ano ang nangyayari sa mga umiiral na sesyon at kung bumabalik ba ang malayong panig sa rutang talagang tatanggapin mo. Ang pagsasanay na iyon ay mas maraming sinasabi tungkol sa disenyo kaysa sa anumang diagram.

Ang ruta ay hindi awtorisasyon. Ang mga prefix na napagkasunduan mong palitan ay walang sinasabi tungkol sa kung aling mga user ang makakaabot sa aling serbisyo sa likod ng tunnel, kaya panatilihin ang authentication, mga pinapayagang serbisyo at firewall ng host sa eksaktong dati nilang lugar. Ang naaabot na peer ay hindi rin pahintulot para sa walang limitasyong transit o sa paggawa ng arbitraryong address, at ang ganoong awtoridad ay nabibilang sa kontrata bilang komersyal na tanong, hindi sa linya ng patakaran ng BGP.

• Pangalanan ang mga prefix na magagawa ng bawat panig, at ang mga hindi dapat tanggapin kailanman.
• Limitahan ang MSS sa tunnel at kumpirmahin na talagang dumarating ang malalaking update.
• Ilista ang mga pinagsasaluhang dependency ng underlay, hindi ang bilang ng tunnel.
• Sukatin ang tunay na pag-withdraw at itala kung ano ang ginagawa ng aplikasyon.