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 कोरण्याची मार्गदर्शिका हे इथे वर्णन केलेल्या रुंदी आणि स्लाइस मॉडेलचे संदर्भ आहे, त्यात ते हार्डवेअरची कोणती पिढी समाविष्ट करते हेही समाविष्ट आहे।