Natutunan ng BGP ang prefix, pero lumalabpas pa rin ang trapik sa tunnel

Ipinapakita ng gateway ng sangay ang prefix ng cloud sa BGP table nito, nakabuo na ang sesyon sa provider, at lumalabas pa rin sa maling interface ang hiling ng isang user patungo sa prefix na iyon. Walang sira sa paraang sinasabi ng monitoring, dahil ang “natutunan ito ng BGP” ay pahayag tungkol sa control plane. Sa pagitan ng table na iyon at ng packet may apat na hiwalay na transisyon, at humihinto ang daloy sa isa lamang sa kanila. Daanan ang mga gate nang sunud-sunod at huminto sa unang bumabagsak.

Unang gate: ano talaga ang ipinadala ng kapitbahay

Magsimula sa prefix gaya ng natanggap, hindi gaya ng naibuod. Hanapin ang eksaktong network at mask sa BGP table at itala ang susunod na hop, ang AS path at anumang community na maaaring itugma ng import policy. Ang buod na ruta sa dashboard ay maaaring magtago ng katotohanang hindi kailanman tinanggap ang partikular na prefix.

Ang import policy ang karaniwang lugar kung saan nawawala ang ruta nang walang error. Maaaring itapon ng prefix list, community filter o inbound route map ang update habang nananatiling up at malusog ang sesyon, kaya napakaliit ang pinapatunayan ng berdeng ilaw ng kapitbahay. Ang kawalan ng log line ay hindi kawalan ng desisyon. Karaniwan itong nangangahulugang tahimik na ginawa ang desisyon, eksakto ayon sa pagkaka-configure.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Basahin ang output sa ganoong pagkakasunod-sunod. Sinasabi ng unang dalawang command kung dumating ang impormasyon at ano ang sinasabing ipinadala ng peer; sinasabi ng huling dalawa kung may nakarating sa routing at forwarding tables. Ang prefix na nasa unang command at wala sa ikatlo ay problema sa pagpili o pag-install, hindi sa konektibidad.

Ikalawang gate: pagpili, pagkatapos pag-install

Pumipili ng pinakamahusay na ruta ang BGP, at ang napiling ruta ay hindi awtomatikong na-i-install. Kailangang maresolba ang susunod na hop, at maaaring pag-aari na ng ibang pinagmulan ng ruta ang prefix na iyon na may mas mahusay na administrative distance. Ang static na rutang naiwan mula sa migration ay madaling mananalo laban sa balidong BGP path at ipapadala ang trapik sa ibang lugar.

Pinaghihiwalay ng RFC 4271 ang tatlong ideya: ano ang ipinadala ng peer, ano ang pinili ng speaker na ito bilang pinakamahusay, at ano ang iaanunsyo nito. Mga konseptwal na papel ang mga ito, hindi tatlong pisikal na database na dapat ilahad ng vendor, ngunit ang paghihiwalay na iyon ang dahilan kung bakit ang “nasa BGP ito” ay hindi kumpletong sagot.

Tingnan din kung aling routing context ang binabasa mo. Ang rutang naka-install sa VRF na hindi kinabibilangan ng interface ng user ay hindi nakikita ng mga packet ng user na iyon, at mukhang tama ang table sa lahat ng oras.

Ikatlong gate: ang paghahanap na naaangkop sa daloy na ito

Ngayon itigil ang pagtatanong tungkol sa ruta at simulan ang pagtatanong tungkol sa packet. Itala ang source address ng user, destinasyon, protocol, port at ingress interface, dahil maaaring pumili ang bawat isa ng ibang policy. Pagkatapos tingnan ang paghahanap na naaangkop sa kombinasyong iyon sa halip na ang pangkalahatang routing table.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Ang mas tiyak na prefix ang pinakakaraniwang sorpresa dito, at ang policy route ang pangalawa. Parehong ipinapawalang-bisa nila ang aggregate na tinitingnan mo, at wala sa kanila ang nakikita sa buod ng BGP table.

Ang ping mula sa gateway mismo ay hindi ebidensya tungkol sa sesyon ng user. Iba ang source address, iba ang policy path at madalas iba ang resulta. Subukan gamit ang parehong source na ginagamit ng application, o tanggapin na ibang tanong ang sinasagot ng test.

Ikaapat na gate: ang malayong kalahati ng ruta

Kung pinipili nga ng lokal na paghahanap ang tunnel, kailangan pa ring tanggapin ng proteksyon policy ang packet, payagan ng forwarding rule at sagutin ng isang bagay sa kabilang panig. Itatapon ng crypto ACL na hindi kasama ang pares ng address ang trapik habang iniuulat ng tunnel na up ito, na lumilikha ng timeout na hindi matukoy mula sa pagkabigo ng routing.

Kasinghalaga ng pabalik na ruta ang papunta. Kailangang malaman ng cloud side kung paano maabot ang source ng sangay, sa pamamagitan ng ruta o ng salin na sinadyang i-configure mo. Karaniwan ang asymmetric na pabalik na ruta sa mga disenyong sinubukan sa isang direksyon lamang.

Iugnay ang sariwang awtorisadong koneksyon sa tatlong obserbasyon: ang lokal na policy na tumugma, ang mga counter ng tunnel na gumalaw, at ang pagtanggap sa malayong panig kung saan ito nakikita. Kung hindi gumagalaw ang mga counter, hindi kailanman pumasok sa tunnel ang packet, anuman ang sabihin ng routing table. Kung gumagalaw at walang dumarating, itinatapon o mali ang routing ng malayong panig. Ang dalawang resultang iyon ay humahantong sa magkaibang team.

Pangalanan ang transisyong nabigo

Isulat ang resulta bilang isa sa limang estado: hindi natanggap, hindi tinanggap ng policy, hindi napili, hindi na-install, o hindi natugma ng daloy na ito. Magdagdag ng ikaanim para sa kaso kung tama ang lokal na ruta at hindi makasagot ang malayong dulo. Ang pangungusap na iyon ang deliverable, at mas kapaki-pakinabang ito kaysa screenshot ng nakatayong kapitbahay.

Magtago rin ng negatibong test sa acceptance plan: isang destinasyon na hindi dapat dumaan sa tunnel, beripikado pagkatapos ng pagbabago. Ang checklist na nagpapatunay lamang ng masayang ruta ay hindi mahuhuli ang malawak na policy rule na idaragdag ng isang tao sa susunod na maintenance window.