ਤੁਸੀਂ ARP ਦਮਨ ਖੇਤਰ ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ, ਡਿਜ਼ਾਈਨ ਨੂੰ ਲੋੜੀਂਦੀਆਂ ਐਂਟਰੀਆਂ ਗਿਣਦੇ ਹੋ, ਉਸ ਤੋਂ ਵੱਧ ਖਾਲੀ ਸਮਰੱਥਾ ਵਾਲਾ ਖੇਤਰ ਲੱਭਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਵੀ ਤਬਦੀਲੀ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੀ। ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਗਿਣਿਆ ਗਿਆ। ਤੁਸੀਂ ਜੋ ਬਜਟ ਪੜ੍ਹ ਰਹੇ ਸੀ ਉਹ ਸਲਾਈਸ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦੋਹਰੀ ਚੌੜਾਈ ਵਜੋਂ ਕੱਟੀ ਗਈ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਕਿਸੇ ਵੀ ਐਂਟਰੀ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਦੋ ਲੋੜੀਂਦੇ ਹਨ।

ਵੰਡ ਨੂੰ ਨਿਸ਼ਚਿਤ ਸੰਖਿਆ ਦੀਆਂ ਇਕਾਈਆਂ ਵਾਲੀ ਲੇਆਉਟ ਸਮੱਸਿਆ ਮੰਨੋ, ਅਤੇ ਗਣਿਤ ਠੀਕ ਵਿਵਹਾਰ ਕਰਨ ਲੱਗੇਗਾ।

ਖੇਤਰ ਸਲਾਈਸ ਦਾ ਮਾਲਕ ਹੈ, ਐਂਟਰੀਆਂ ਦਾ ਨਹੀਂ

ਇਨ੍ਹਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ TCAM ਸਲਾਈਸ ਵਿੱਚ ਵੰਡੀ ਹੋਈ ਹੈ, ਅਤੇ ਹਰ ਸਲਾਈਸ ਠੀਕ ਇੱਕ ਖੇਤਰ ਦੀ ਹੈ। ਖੇਤਰ ਸਲਾਈਸ ਵਿੱਚ ਮਾਪੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਚੌੜਾਈ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਘੱਟੋ-ਘੱਟ ਕਿੰਨੇ ਸਲਾਈਸ ਵਰਤਦੀ ਹੈ। ਇੱਕੋ ਚੌੜਾਈ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਇੱਕ ਸਲਾਈਸ ਵਿੱਚ ਰਹਿ ਸਕਦੀ ਹੈ; ਦੋਹਰੀ ਚੌੜਾਈ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਨਾਲ ਲੱਗਦੀ ਜੋੜੀ ਲੋੜੀਂਦੀ ਹੈ।

ConceptWhat it means when you plan
SliceThe indivisible unit; it belongs to one region and cannot be shared
Feature widthSingle or double; a double-width feature must have two slices available
Logical entriesWhat 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 ਕੱਟਣ ਗਾਈਡ ਇੱਥੇ ਵਰਣਿਤ ਚੌੜਾਈ ਅਤੇ ਸਲਾਈਸ ਮਾਡਲ ਲਈ ਸੰਦਰਭ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਇਹ ਹਾਰਡਵੇਅਰ ਦੀ ਕਿਹੜੀ ਪੀੜ੍ਹੀ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ