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

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

ચાર બજેટ, એક નહીં

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

BudgetWhat you are really counting
SessionsPeers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count
PrefixesAlternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see
ChurnUpdates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event
RecoveryTime to detect, reselect, reinstall and restore the application, measured end to end rather than per box

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

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

તમારા પોતાના આંકડાઓ સાથે ગણતરી કરો

એક કાલ્પનિક ડિઝાઇન લો: 3,000 શાખાઓ, એકત્રીકરણ પહેલાં દરેકને ત્રણ પ્રીફિક્સ, અને રીડન્ડન્સી માટે પ્રતિ શાખા બે હબ. હબ-જોડીએ સારાંશ પહેલાં આશરે 9,000 શાખા પ્રીફિક્સ રાખવા પડે, અને દરેક શાખા બંને સાથે પિયર કરે તો ડિઝાઇન 6,000 શાખા-થી-હબ સેશન સૂચવે છે.

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

આ ડિઝાઇન-ચર્ચા માટેના આયોજન આંકડા છે, કોઈ ઉત્પાદનનું માપ નથી. કસરતનું ઉપયોગી પરિણામ વક્રનો આકાર છે, કોઈ ચોક્કસ રાઉટર ક્યાં હારે છે તેવો દાવો નહીં.

BGP તમને શું આપે છે, અને IGP તમને શું આપે છે

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

IGP આપોઆપ ખોટું નથી. જ્યારે ટોપોલોજી, વિસ્તાર-રચના અને પડોશી-નમૂનો સેવા સાથે મેળ ખાય, ત્યારે લિંક-સ્ટેટ પ્રોટોકોલ ઝડપથી એકરૂપ થાય છે અને ઓછું નીતિ-માળખું માગે છે. જાળ એ છે કે એ BGP જેવું પ્રતિ-પડોશી નિકાસ નિયંત્રણ વ્યક્ત કરી શકે એમ ધારવું: OSPF વિસ્તાર પૂર-સીમા છે, એક શાખા પર લટકાવી શકાય એવું ફિલ્ટર નહીં.

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

ધોધની કસોટી કરો, સ્થિર સ્થિતિની નહીં

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

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

પ્લેટફોર્મ આરામમાં શું કરે છે તે નહીં, ધોધની ટોચ પર શું કરે છે તે નોંધો, અને સુરક્ષા સુવિધાઓ ચાલુ રાખીને તેનું પુનરાવર્તન કરો. જે પ્રૂફ-ઓફ-કોન્સેપ્ટ ફક્ત શાંત કોષ્ટક બતાવે છે તે મેમરી-કસોટી છે, અને મેમરી કદી રસપ્રદ આંકડો નહોતું.

સંબંધિત લેખો