Nexus TCAM: ARP દમન પ્રદેશને બે સ્લાઇસ કેમ જોઈએ
લોજિકલ એન્ટ્રીઓ બજેટનો ફક્ત અડધો ભાગ છે. ડબલ-પહોળાઈ તરીકે કાપેલા ફીચરને સ્લાઇસની જોડી જોઈએ, અને ખોટી જગ્યાએ એક ખાલી સ્લાઇસ પૂરતી નથી.
તમે ARP દમન પ્રદેશનું માપ નક્કી કરો છો, ડિઝાઇનને જે એન્ટ્રીઓ જોઈએ તે ગણો છો, તેના કરતાં વધુ ખાલી ક્ષમતા ધરાવતો પ્રદેશ શોધો છો, અને હજી પણ ફેરફાર બંધ બેસતો નથી. કંઈપણ ખોટું ગણાયું નથી. તમે જે બજેટ વાંચી રહ્યા હતા તે સ્લાઇસમાં માપવામાં આવે છે, અને ડબલ-પહોળાઈ તરીકે કાપેલા ફીચરને કોઈપણ એન્ટ્રી ધ્યાનમાં લેવાય તે પહેલાં તેમાંથી બે જોઈએ.
ફાળવણીને નિશ્ચિત સંખ્યાના એકમો સાથેની ગોઠવણીની સમસ્યા તરીકે ગણો, અને ગણિત યોગ્ય વર્તન કરવા લાગશે.
પ્રદેશ સ્લાઇસનો માલિક છે, એન્ટ્રીઓનો નહીં
આ પ્લેટફોર્મ પર TCAM સ્લાઇસમાં વિભાજિત છે, અને દરેક સ્લાઇસ બરાબર એક પ્રદેશની છે. પ્રદેશો સ્લાઇસમાં માપવામાં આવે છે, અને ફીચરની પહોળાઈ નક્કી કરે છે કે તે ઓછામાં ઓછી કેટલી સ્લાઇસ વાપરે છે. એક-પહોળાઈનું ફીચર એક સ્લાઇસમાં રહી શકે છે; ડબલ-પહોળાઈના ફીચરને અડીને આવેલી જોડી જોઈએ.
| Concept | What it means when you plan |
|---|---|
| Slice | The indivisible unit; it belongs to one region and cannot be shared |
| Feature width | Single or double; a double-width feature must have two slices available |
| Logical entries | What the feature wants to store, which only matters after the slices are allocated |
તેથી ખાલી સ્લાઇસ આપમેળે વાપરી શકાય તેવી ક્ષમતા નથી. અલગ સ્લાઇસ પર બેસેલા બે એક-પહોળાઈના પ્રદેશો નવા ડબલ-પહોળાઈના પ્રદેશને જોઈતી જોડીમાં ભળતા નથી, અને કુલ મળીને ઘણી બિનવપરાયેલી જગ્યા દર્શાવતું કોષ્ટક તમને એવા સંગ્રહ વિશે કહે છે જે તમે ખર્ચી શકતા નથી.
કાપતા પહેલાં આધારરેખા નોંધો
ચોક્કસ હાર્ડવેર મોડેલ, NX-OS આવૃત્તિ, પ્રદેશોની વર્તમાન પહોળાઈ અને માપ, અને દરેક પ્રદેશ વાપરતા ફીચરો એકત્રિત કરો. કોઈપણ ફેરફાર પહેલાં આ કરો, કારણ કે ફરી લોડ કર્યા પછી અગાઉની સ્થિતિ એક સ્મૃતિ હોય છે, હકીકત નહીં.
show version
show hardware capacity
show running-config | include hardware profileઆદેશોના નામ પ્લેટફોર્મ અને આવૃત્તિ પ્રમાણે બદલાય છે, અને કાપવાની માર્ગદર્શિકા તેના પોતાના હાર્ડવેરને લાગુ પડતા નામો જણાવે છે. બીજા મોડેલનો આદેશ એ જ કોષ્ટક આપશે એમ ધારવાને બદલે તમને ખરેખર મળતું આઉટપુટ વાંચો.
પછી દરેક પ્રદેશ શેના માટે છે તે લખો. VACL પ્રદેશ કોઈ કારણસર ફિલ્ટર ક્ષમતા છે, અને QoS પ્રદેશ એટલા માટે છે કારણ કે કોઈએ તેને હજી અમલમાં રહેલી નીતિ માટે માપ્યો હતો. ચકાસ્યા વિના તે જગ્યાઓને પુનઃપ્રાપ્ત કરી શકાય તેવી જગ્યા તરીકે ગણતી યોજના ફીચરો ચૂપચાપ દૂર કરવાની યોજના છે. તમે જે પ્રદેશ ઘટાડવાનું વિચારો છો તે દરેક માટે એક માલિક નિયુક્ત કરો, અને વિન્ડો પહેલાં તે માલિકને નવું માપ આપો.
દિશાનો પણ વિચાર કરો. જ્યાં પ્લેટફોર્મ ઇનગ્રેસ અને ઇગ્રેસ ફાળવણીને જોડે છે, ત્યાં એક બાજુનો ફેરફાર બીજી બાજુનું બજેટ વાપરી શકે છે, અને ફક્ત ઇનગ્રેસ કોષ્ટક ગણતી યોજના સાચી દેખાશે અને ફરી લોડ કરતી વખતે નિષ્ફળ જશે.
એક મોટી સ્લાઇસ મુક્ત કરવાથી શું થતું નથી
મોટા એક-પહોળાઈના પ્રદેશને ઘટાડવાથી એક સ્લાઇસ મુક્ત થાય છે. જો તમારા લક્ષ્ય પ્રદેશને જોડીની જરૂર હોય, તો તે એક સ્લાઇસ નકામી હોઈ શકે જ્યાં સુધી તે બીજી ખાલી સ્લાઇસને અડીને ન હોય, અને સાન્નિધ્ય ગોઠવણીની લાક્ષણિકતા છે, કુલની નહીં.
આ એ બિંદુ છે જ્યાં લોકો તારણ કાઢે છે કે પ્લેટફોર્મ તૂટેલું છે અથવા દસ્તાવેજીકરણ ખોટું છે. બંમાંથી કંઈ સાચું નથી. ફાળવણી મોડેલ બરાબર એ જ કરે છે જે તે કહે છે, અને ભૂલ એ હતી કે યોગ્ય સ્થાનો પર ખાલી સ્લાઇસ ગણવાને બદલે ખાલી જગ્યા ગણાઈ. એક વાર તમે ગોઠવણી કાગળ પર દોરી લો, પછી ઉપલબ્ધ જોડી કાં તો છે કાં નથી, અને કુલ વિશેની દલીલ કરતાં પ્લેટફોર્મ માલિક સાથે આ ઘણી સરળ વાતચીત છે.
નામ આપવા લાયક એક આવૃત્તિ-જાળ પણ છે. Cisco ની કાપવાની માર્ગદર્શિકા ચોક્કસ હાર્ડવેર પેઢીનું વર્ણન કરે છે અને સ્પષ્ટ કહે છે કે તેનું મોડેલ ન તો Cloud Scale છે ન તો Silicon One. પ્રદેશોના નામ, મૂળભૂત માપ અને કયા ફીચરો ડબલ-પહોળાઈના છે તે પણ બીજે સ્થળે અલગ છે, તેથી એક પ્લેટફોર્મ પર ચોક્કસ પ્રદેશ વિશેની ચેતવણી તે પ્લેટફોર્મ અને આવૃત્તિ વિશેનો પુરાવો છે, સાર્વત્રિક રેસીપી નહીં.
પ્રદેશ બદલવો એ ફીચર ફેરફાર છે
દરેક કાપ એ ક્ષમતાની આપલે છે. પ્રદેશ ઘટાડીને ARP દમન માટે જગ્યા કરવી તે પ્રદેશ જેનું રક્ષણ કરતો હતો તે ઘટાડે છે, અને પરિણામ ત્યાં સુધી દેખાય નહીં જ્યાં સુધી જગ્યા જોઈતી નીતિ ફરી લાગુ ન થાય.
વિન્ડો પહેલાં અસરગ્રસ્ત દરેક ફીચરના માલિકની લેખિત સંમતિ મેળવો. આ નોકરશાહી નથી: જે વ્યક્તિએ શરૂઆતમાં VACL પ્રદેશ માપ્યો હતો તે જાણે છે કે તે શું ફિલ્ટર કરે છે, અને જગ્યા કરનાર વ્યક્તિ સામાન્ય રીતે જાણતી નથી.
હાર્ડવેર ગોઠવણી બદલતા ફેરફારો માટે ફરી લોડ થવાની અપેક્ષા રાખો. કેટલાક પ્લેટફોર્મ તેની જરૂર રાખે છે અને કેટલાક નહીં, પણ જ્યારે ફરી લોડ શક્ય હોય ત્યારે જાળવણી વિન્ડો વિના આયોજન કરવું એ રૂટિંગ ફેરફારને અટકાવમાં ફેરવવાની રીત છે. વિન્ડોને આદેશની આસપાસ નહીં, ફરી લોડની આસપાસ ગોઠવો, અને અગાઉની પ્રોફાઇલ ટેક્સ્ટ એવી જગ્યાએ રાખો જ્યાંથી તમે વ્યવસ્થાપન સત્ર ગુમાવેલા કન્સોલમાંથી તેને વાંચી શકો.
લાગુ કરો અને આધારરેખા સામે ચકાસો
પ્લેટફોર્મની સમર્થિત પ્રક્રિયા દ્વારા યોજના લાગુ કરો, પછી તમે જાળવી રાખેલા ફંક્શન ચકાસો, ફક્ત તમે ઉમેરેલું નહીં. ફિલ્ટર ચૂપચાપ મેળ ખાવાનું બંધ કરી દીધું હોય તેમ છતાં કામ કરતો નવો કાપેલો પ્રદેશ મૂળ નિષ્ફળતા કરતાં ખરાબ પરિણામ છે.
ક્ષમતાનું આઉટપુટ ફરી વાંચો અને તમે નોંધેલી આધારરેખા સાથે તુલના કરો, પછી જે ફીચરે ફેરફાર પ્રેર્યો તે ચકાસો. Nexus TCAM કાપવાની માર્ગદર્શિકા અહીં વર્ણવેલ પહોળાઈ અને સ્લાઇસ મોડેલ માટે સંદર્ભ છે, જેમાં તે કઈ હાર્ડવેર પેઢી આવરે છે તે પણ સામેલ છે.