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 काट्ने मार्गदर्शिका यहाँ वर्णन गरिएको चौडाइ र स्लाइस मोडेलको सन्दर्भ हो, जसमा यसले हार्डवेयरको कुन पुस्ता समेट्छ भन्ने पनि समावेश छ।