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 പ്രിഫിക്സ് പഠിച്ചു പക്ഷേ ട്രാഫിക് ഒഴുകുന്നില്ല എന്ന് ആരെങ്കിലും റിപ്പോർട്ട് ചെയ്യുമ്പോൾ, ഉപയോഗപ്രദമായ ചോദ്യം അത് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടോ, ഏത് അടുത്ത ഹോപ്പിലേക്കാണ് ചൂണ്ടുന്നത് എന്നതാണ്.
ഡിസൈൻ അവലോകനത്തിനുള്ള സത്യസന്ധമായ ഉത്തരം പങ്കിട്ട ആശ്രിതത്വങ്ങളുടെ ഒരു പട്ടികയാണ്: ആക്സസ് സർക്യൂട്ട്, അപ്സ്ട്രീം ദാതാവ്, സൗകര്യം, തിരിച്ചുവരവ് പാതയിലെ ഏതെങ്കിലും സ്റ്റേറ്റ്ഫുൾ ഉപകരണം. ടണലിലൂടെയുള്ള ഒരു സെഷന് അത് മുകളിൽ ഇരിക്കാത്ത ഒരു ആശ്രിതത്വം നീക്കാൻ കഴിയില്ല.
വേർതിരിക്കാൻ യോഗ്യമായ മൂന്ന് തീരുമാനങ്ങൾ
ഒരു ഡിസൈൻ ഇവ കൂട്ടിക്കലർത്തുമ്പോൾ, ഓരോ തകരാർ സംഭാഷണവും വൃത്തത്തിൽ തിരിയുന്നു. ആദ്യം അവ കടലാസിൽ വേർതിരിക്കുക, പിന്നീട് ഓരോന്നിനെയും അത് യഥാർത്ഥത്തിൽ നടപ്പാക്കുന്ന ഉപകരണത്തിലേക്ക് ബന്ധിപ്പിക്കുക.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path 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 പരിമിതപ്പെടുത്തുക, വലിയ അപ്ഡേറ്റുകൾ യഥാർത്ഥത്തിൽ എത്തുന്നുവെന്ന് സ്ഥിരീകരിക്കുക.
- പങ്കിട്ട അൺഡർലേ ആശ്രിതത്വങ്ങൾ ലിസ്റ്റ് ചെയ്യുക, ടണലുകളുടെ എണ്ണമല്ല.
- യഥാർത്ഥ പിൻവലിക്കൽ സമയം അളക്കുക, ആപ്ലിക്കേഷൻ എന്ത് ചെയ്യുന്നു എന്ന് രേഖപ്പെടുത്തുക.