VPN પર BGP તમારા અંડરલે પાથને કેમ નિયંત્રિત કરતું નથી

VPN પર BGP પહોંચક્ષમતા બદલે છે અને રૂટ નીતિ લાગુ કરે છે, પણ અંડરલે હજી પણ બહારનો પાથ પસંદ કરે છે. સત્ર ખરેખર શું નિયંત્રિત કરે છે.

બે સાઇટ્સ IPsec ટનલ પર BGP પીઅર કરે છે, એકબીજાના પ્રીફિક્સ શીખે છે, અને ડાયાગ્રામને પાથ નિયંત્રણ તરીકે ફરી લેબલ કરવામાં આવે છે. એ લેબલ જ ગૂંચવણની શરૂઆત છે. સત્ર પહોંચક્ષમતા બદલે છે અને નીતિ લાગુ કરે છે, પણ એન્ક્રિપ્ટેડ પેકેટ કયો પ્રોવાઇડર, કેબલ કે રાઉટર વહન કરે છે તેમાં એનો કોઈ શબ્દ નથી. મેં એક ટીમને કાર્યરત ટનલ ફરી બનાવતી જોઈ છે, કારણ કે તેઓ ધારતા હતા કે BGP રૂટ ફેરફાર ટ્રાફિકને બીજા ફાઇબર પાથ પર ખસેડશે જેને સત્ર ક્યારેય પ્રભાવિત કરી શકે નહીં.

લોકો ધારે છે કે સત્ર શું ખરીદે છે

મોટાભાગની અપેક્ષા લેબમાં રૂટ ફેરફાર કેવો દેખાય તેમાંથી આવે છે. તમે ટનલ પર પ્રીફિક્સ જાહેર કરો છો, દૂરની બાજુ તેને સ્થાપિત કરે છે, અને ટ્રાફિક ખસે છે. એ જ ક્રમ એ રાઉટર પર પણ થાય છે જેમાં ખરેખર ટ્રાફિક-એન્જિનિયરિંગ નિયંત્રણો છે, તેથી બંને ભેગા થઈ જાય છે. લેબમાં સામાન્ય રીતે બંને સાઇટ્સ એક જ એક્સેસ લિંક વહેંચે છે, અને એટલે જ તફાવત ત્યાં ક્યારેય દેખાતો નથી.

BGP એ પહોંચક્ષમતાનું પ્રોટોકોલ છે. તે પીઅરને કહે છે કે તમે પ્રીફિક્સ માટે પેકેટ પહોંચાડી શકો છો, અને દરેક બાજુને મળતી ઑફરો ક્રમમાં ગોઠવવા દે છે. ટનલ પર તે ખરેખર ઉપયોગી છે: સાઇટ્સ આવતા-જતા પ્રીફિક્સ દેખાય છે અને અદૃશ્ય થાય છે, અને દરેક એજ ઉપકરણ પર સ્ટેટિક રૂટ લખ્યા વિના તમે રેન્જ નકારી શકો છો. તે જે કરતું નથી તે છે પ્રોવાઇડરના રાઉટરને તમારા નિયંત્રણ હેઠળ લાવવા.

અંડરલે બહારનું હેડર વહન કરે છે. તમારો ટનલ એન્ડપોઇન્ટ પીઅર એડ્રેસ પર એન્ક્રિપ્ટેડ પેકેટ મોકલે છે, અને એ બે એડ્રેસ વચ્ચેનું નેટવર્ક તેના ઓપરેટરોએ સ્થાપિત કરેલા રૂટ દ્વારા તેમને ફોરવર્ડ કરે છે. BGP સત્રમાં કંઈ પણ એ નિર્ણય બદલતું નથી, સિવાય કે એ જ પ્રોવાઇડર એવી સમર્થિત સેવા આપે જે એ કરે.

સત્ર ખરેખર શું વહન કરે છે

BGP સ્પીકર તેના પીઅર પર પોર્ટ 179 પર TCP જોડાણ ખોલે છે, RFC 4271-માં વ્યાખ્યાયિત સંદેશ ફોર્મેટ અને પાથ એટ્રિબ્યુટનો ઉપયોગ કરીને. જ્યારે પીઅર એડ્રેસ ટનલની અંદર હોય, ત્યારે સત્ર શરૂ થાય તે પહેલાં ટનલ ચાલુ હોવી જોઈએ અને એ એડ્રેસ પહોંચક્ષમ હોવું જોઈએ. પૂર્ણ થયેલું IKE વિનિમય BGP પડોશી નથી. રૂટ-આધારિત IPsec અમલીકરણો ફક્ત ત્યારે જ ટ્રાફિક પસાર કરે છે જ્યારે મેળ ખાતો ટનલ રૂટ અસ્તિત્વમાં હોય, અને નીતિ-આધારિત અમલીકરણને સુરક્ષિત સિલેક્ટરની અંદર પીઅર એડ્રેસની જરૂર હોય છે. આને ઊંધું કરવાથી ક્લાસિક સ્થિતિ સર્જાય છે જ્યાં ટનલ લીલી હોય છે અને સત્ર નિષ્ક્રિય બેસે છે.

સત્ર ચાલુ થયા પછી, નીતિ નક્કી કરે છે કે તેને શું પાર કરે છે. પ્રીફિક્સ યાદીઓ, AS-પાથ ફિલ્ટર, મહત્તમ પ્રીફિક્સની ટોચમર્યાદા અને ડિફૉલ્ટ રૂટ વિશે સ્પષ્ટ નિર્ણય એ લઘુતમ છે, અને તે બંને દિશામાં લાગુ પડે છે. જે પીઅર જે મળે તે બધું સ્વીકારે છે તે તમને એવો ડિફૉલ્ટ રૂટ આપી શકે છે જે સ્થાનિક ઇન્ટરનેટ એક્સેસને ચૂપચાપ બદલી નાખે છે. બંને દિશાઓને અલગ યાદીઓની જરૂર છે, કારણ કે પીઅર પાસેથી તમે શું સ્વીકારો છો અને તેને શું જાહેર કરો છો તે અલગ નિર્ણયો છે.

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

આગળ MTU કરડે છે. એન્કેપ્સ્યુલેશન ઉપયોગી પેલોડ ઘટાડે છે, તેથી મોટું અપડેટ એવા સત્રને અટકાવી શકે છે જે સંપૂર્ણ સ્થાપિત દેખાય છે: પીઅર ચાલુ રહે છે, પ્રીફિક્સ ક્યારેય આવતા નથી, અને લોગમાં કંઈ સ્પષ્ટ પડતું નથી. ફિલ્ટરને દોષ આપતા પહેલાં ટનલ ઇન્ટરફેસ પર TCP MSS મર્યાદિત કરો, અથવા ઓવરહેડ માટે જગ્યા સાથે ટનલ MTU સેટ કરો.

બહારના પેકેટ હજી ક્યાં જાય છે

એક સાઇટથી બીજી સાઇટ સુધીના એન્ક્રિપ્ટેડ પેકેટ સ્થાનિક રાઉટર પીઅરના જાહેર એડ્રેસ માટે જે પસંદ કરે તેમાંથી બહાર નીકળે છે. જો બંને સાઇટ્સ એક જ પ્રોવાઇડર પાસેથી ટ્રાન્ઝિટ ખરીદે, એક જ મેટ્રો સુવિધા પાર કરે, અથવા એક બાજુ કેરિયર-ગ્રેડ NAT પાછળ હોય, તો ટનલ પ્રોવાઇડર નિષ્ફળતામાંથી માત્ર સંજોગવશાત જ બચે છે. મોનિટરિંગ ટૂલમાં ટનલ આઇકન ગણવાથી તમને એ વિશે કંઈ ખબર પડતી નથી.

રૂટ પસંદગી અને ફોરવર્ડિંગ સ્થાપન પણ અલગ ઘટનાઓ છે. પ્રીફિક્સ BGP કોષ્ટકમાં શ્રેષ્ઠ તરીકે બેસી શકે છે અને છતાં ફોરવર્ડિંગ કોષ્ટકમાંથી ખૂટતું હોઈ શકે, કારણ કે આગલું હોપ ઉકેલી શકાતું નથી અથવા વધુ ચોક્કસ રૂટ જીતે છે. જ્યારે કોઈ જણાવે કે BGP એ પ્રીફિક્સ શીખ્યું પણ ટ્રાફિક વહેતો નથી, ત્યારે ઉપયોગી પ્રશ્ન એ છે કે તે સ્થાપિત છે કે નહીં અને કયા આગલા હોપ તરફ તે નિર્દેશ કરે છે.

ડિઝાઇન સમીક્ષા માટે પ્રામાણિક જવાબ છે વહેંચાયેલી નિર્ભરતાઓની યાદી: એક્સેસ સર્કિટ, અપસ્ટ્રીમ પ્રોવાઇડર, સુવિધા અને પરત પાથ પરનું કોઈપણ સ્ટેટફુલ ઉપકરણ. ટનલ પરનું સત્ર એવી નિર્ભરતા દૂર કરી શકતું નથી જેની ઉપર તે બેઠું નથી.

અલગ પાડવા લાયક ત્રણ નિર્ણયો

જ્યારે ડિઝાઇન આને ભેગા કરે છે, ત્યારે દરેક આઉટેજ ચર્ચા વર્તુળમાં ફરે છે. પહેલાં કાગળ પર તેમને અલગ કરો, પછી દરેકને એ ઉપકરણ સાથે જોડો જે ખરેખર તેને લાગુ કરે છે.

DecisionWho controls itTypical failure
Which prefixes may cross the relationship?Both sides, through prefix and AS-path policy you configure deliberatelyA default route accepted by mistake, or a vague aggregate
Which overlay next hop wins?Local BGP selection plus next-hop resolution on your own routersPrefix learned, never installed in the forwarding table
Where do the encrypted packets travel?The underlay operators, unless a supported service adds real controlPath diversity that was never there

દરેક પંક્તિનો માલિક અલગ છે. પહેલી વાટાઘાટ છે, બીજી તમારા ઉપકરણો પરનું કન્ફિગરેશન છે, ત્રીજી મોટે ભાગે બીજા કોઈનું નેટવર્ક છે. જે ફેરફાર વિનંતી પોતે સ્પર્શતી પંક્તિનું નામ આપે છે તે BGP સમસ્યા કહેતી વિનંતી કરતાં ઘણી સરળતાથી મંજૂર થાય છે.

આયોજન કરવા લાયક નિષ્ફળતાના પ્રકારો

પીઅરનો સારાંશ રૂટ સ્વીકારવો એ સૌથી સામાન્ય સ્વયં-પ્રેરિત ઘા છે. કોઈ વિનિમય સરળ બનાવવા ટૂંકું એગ્રિગેટ જાહેર કરે છે, દૂરની બાજુ તેને સ્વીકારે છે, અને ટનલ પાછળ ન હોય તેવી રેન્જનો ટ્રાફિક ટનલને અનુસરીને મરી જાય છે. ચોક્કસ અપેક્ષિત પ્રીફિક્સ પર ફિલ્ટર કરો, અથવા યોગ્ય મર્યાદાવાળી પ્રીફિક્સ યાદી વાપરો, અને ક્યારેય નગ્ન એગ્રિગેટ સ્વીકારશો નહીં કારણ કે તે સત્રને ચોખ્ખું દેખાડે છે.

પાછી ખેંચવાનો સમય બીજો છે. શોધ હોલ્ડ ટાઇમર, તમે સક્ષમ કર્યું હોય તો BFD, ટનલ ડેડ-પીઅર શોધ અને દૂરની બાજુ કેટલી ઝડપથી જાહેર કરવાનું બંધ કરે તેના પર આધાર રાખે છે. હાલના સત્રો અલગ સમસ્યા છે: નવો રૂટ નવા જોડાણો પુનઃસ્થાપિત કરી શકે છે જ્યારે સ્થાપિત TCP સત્રો જૂનાં એડ્રેસ વાપરવાનું ચાલુ રાખે છે, અને પાથ પરના સ્ટેટફુલ ફાયરવોલ કે NAT એવી એન્ટ્રીઓ રાખી શકે છે જે હવે મેળ ખાતી નથી. રૂટ ફેરફાર બધું ઉકેલી દેશે એમ ધારવાને બદલે એપ્લિકેશન પુનઃપ્રાપ્તિને સ્વીકૃતિ માપદંડમાં મૂકો.

ત્રીજી છે પરત પાથની અસમપ્રમતા. ટ્રાફિક ટનલ પર આવી શકે છે અને એવી પ્રોવાઇડર લિંક પરથી પાછો ફરી શકે છે જે તેને વહન કરવા માટે ક્યારેય બનાવાઈ ન હતી, જે એકમાર્ગી ઑડિયો, નિષ્ફળ હેન્ડશેક અથવા જવાબો ફેંકી દેતા ફાયરવોલ તરીકે દેખાય છે. બંને દિશાઓ અલગથી તપાસો.

કરારમાં શું લખવું, અને તેને કેવી રીતે ચકાસવું

માન્ય પ્રીફિક્સ લખિતમાં માંગો: દરેક રેન્જ ઉત્પન્ન કરવાનો અધિકાર કોને છે, ડિફૉલ્ટ રૂટ માન્ય છે કે નહીં, અને ટનલ સેવા કયા એડ્રેસ ફેમિલીને સમર્થન આપે છે. RFC 8212 એ સ્પષ્ટ આયાત અને નિકાસ નીતિને eBGP માટે અપેક્ષા બનાવી તે અમલીકરણોમાં જે તેને અનુસરે છે, તેથી જે પીઅર હજી પણ ગર્ભિત સર્વસ્વીકાર વર્તન પર આધાર રાખે છે તેને પૂછવું યોગ્ય છે.

પછી ડાયાગ્રામને બદલે ઉપકરણથી ચકાસો. 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

બે અવલોકનો ઉમેરો જે રૂટિંગ કોષ્ટક તમને આપી શકતું નથી. એન્કેપ્સ્યુલેટેડ પેકેટ ખરેખર કયા એડ્રેસને લક્ષ્ય બનાવે છે તેની ખાતરી કરવા બહારના ઇન્ટરફેસ પર કેપ્ચર કરો, ઉદાહરણ તરીકે tcpdump -ni eth0 udp port 51820 WireGuard ટનલ માટે, અથવા IPsec માટે ESP ફિલ્ટર. પછી પીઅરના જાહેર એડ્રેસ તરફ ટ્રેસ કરો અને ટનલની અંદરના ટ્રેસ સાથે હોપની તુલના કરો; જો બંને એક જ પ્રોવાઇડર શૃંખલાને અનુસરે, તો તમારી રીડન્ડન્સી નેટવર્કમાં નહીં, રૂટિંગ નીતિમાં રહે છે.

છેલ્લે, ઇરાદાપૂર્વક પાછી ખેંચવાનું પરીક્ષણ કરો. જાળવણી વિન્ડો દરમિયાન ટનલ નીચે ઉતારો, પ્રીફિક્સ કેટલો સમય સ્થાપિત રહે છે, હાલના સત્રોનું શું થાય છે અને દૂરની બાજુ ખરેખર સ્વીકાર્ય રૂટ પર પાછી ફરે છે કે નહીં તે નોંધો. એ કસરત કોઈપણ ડાયાગ્રામ કરતાં ડિઝાઇન વિશે વધુ કહે છે.

રૂટ એ અધિકૃતિ નથી. તમે બદલવા સંમત થાઓ તે પ્રીફિક્સ એ વિશે કંઈ કહેતા નથી કે કયા વપરાશકર્તા ટનલ પાછળની કઈ સેવા સુધી પહોંચી શકે છે, તેથી પ્રમાણીકરણ, માન્ય સેવાઓ અને હોસ્ટ ફાયરવોલ જ્યાં હતા ત્યાં જ રાખો. પહોંચક્ષમ પીઅર પણ અમર્યાદિત ટ્રાન્ઝિટ કે મનસ્વી એડ્રેસ ઉત્પન્ન કરવાની પરવાનગી નથી, અને એ પ્રકારની સત્તા BGP નીતિ લાઇનમાં નહીં, કરારમાં વ્યાપારી પ્રશ્ન તરીકે રહેવી જોઈએ.

  • દરેક પક્ષ કયા પ્રીફિક્સ ઉત્પન્ન કરી શકે અને કયા ક્યારેય સ્વીકારવા ન જોઈએ તે નામ આપો.
  • ટનલ પર MSS મર્યાદિત કરો અને ખાતરી કરો કે મોટા અપડેટ ખરેખર આવે છે.
  • વહેંચાયેલી અંડરલે નિર્ભરતાઓની યાદી આપો, ટનલની સંખ્યા નહીં.
  • વાસ્તવિક પાછી ખેંચવાનો સમય માપો અને એપ્લિકેશન શું કરે છે તે નોંધો.

સંબંધિત લેખો