ਪ੍ਰਤੀ-ਟਨਲ QoS ਤੁਹਾਡੇ ਹੱਬ ਦੇ ਕੁੱਲ ਅੱਪਲਿੰਕ ਨੂੰ ਸੀਮਿਤ ਨਹੀਂ ਕਰਦੀ

ਇਹ ਵਿਸ਼ਵਾਸ ਗਣਿਤ ਵਰਗਾ ਲੱਗਦਾ ਹੈ: ਪੰਜ ਸਪੋਕ, ਹਰੇਕ 5 Mbit/s 'ਤੇ ਢਾਲਿਆ ਗਿਆ, ਇਸ ਲਈ ਹੱਬ ਵੱਧ ਤੋਂ ਵੱਧ 25 Mbit/s ਢੋਂਦਾ ਹੈ। ਪਹਿਲਾ ਅੱਧ ਸੱਚ ਹੈ ਅਤੇ ਸਿੱਟਾ ਨਹੀਂ। ਪ੍ਰਤੀ-ਟਨਲ ਨੀਤੀ ਹਰ ਟਨਲ ਲਈ ਇੱਕ ਵਾਰ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਹਰ ਹੱਬ ਲਈ ਇੱਕ ਵਾਰ ਨਹੀਂ, ਅਤੇ ਪੰਜੇ ਟਨਲ ਜਿਸ ਸਾਂਝੇ ਅੱਪਲਿੰਕ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ ਉਹ ਉਸ ਗਣਨਾ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਆਉਂਦਾ। ਅੱਪਲਿੰਕ 'ਤੇ ਭੀੜ ਬਿਲਕੁਲ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਰਹਿੰਦੀ ਹੈ।

ਇਹ ਵਿਸ਼ਵਾਸ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ

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

ਇਸ ਲਈ ਪ੍ਰਤੀ ਸਪੋਕ 5 Mbit/s ਪ੍ਰਤੀ-ਟਨਲ ਉੱਪਰੀ ਸੀਮਾ ਹੈ, ਅਤੇ ਟਨਲਾਂ ਜਿੰਨੀਆਂ ਹਨ ਓਨੀਆਂ ਸੀਮਾਵਾਂ ਹਨ।

ਇੱਕ ਨੀਤੀ ਕਾਪੀ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ

Cisco ਦੀ IOS XE 'ਤੇ DMVPN ਵਿੱਚ ਪ੍ਰਤੀ-ਟਨਲ QoS ਗਾਈਡ NHRP ਸਮੂਹ ਜਾਣਕਾਰੀ ਰਾਹੀਂ ਚੁਣੀ ਅਤੇ ਹਰ ਸਪੋਕ 'ਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੀ ਹੱਬ ਆਉਟਗੋਇੰਗ ਨੀਤੀ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ। ਉਸ ਵਾਕ ਤੋਂ ਦੋ ਸੀਮਾਵਾਂ ਆਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਦਰ ਇੱਕ ਸਪੋਕ ਦੀ ਹੈ, ਸਾਂਝੀ ਬਾਲਟੀ ਦੀ ਨਹੀਂ, ਅਤੇ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਹੱਬ ਤੋਂ ਸਪੋਕ ਵੱਲ ਟ੍ਰੈਫਿਕ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ, ਉਲਟਾ ਨਹੀਂ।

ਸਪੋਕ ਦੀ ਭੇਜਣ ਦੀ ਦਿਸ਼ਾ ਦੀ ਯੋਜਨਾ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਬਣਾਓ। ਹੱਬ ਆਉਟਗੋਇੰਗ ਨੀਤੀ ਵਿੱਚ ਕੁਝ ਵੀ ਸੀਮਿਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਸ਼ਾਖਾ ਕੀ ਅੱਪਲੋਡ ਕਰਦੀ ਹੈ।

ਕੁੱਲ ਸੀਮਾ ਸਾਂਝੀ ਰੁਕਾਵਟ 'ਤੇ ਰੱਖੋ

ਕੁੱਲ ਉੱਥੇ ਢਾਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਅਸਲ ਵਿੱਚ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ: ਉਸ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਜੋ ਸਾਰੀਆਂ ਟਨਲਾਂ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ। Cisco ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ 'ਤੇ class-default ਸ਼ੇਪਰ ਨੂੰ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਸਮਰਥਿਤ ਸਮਕਾਲੀ ਭੌਤਿਕ ਨੀਤੀ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ, ਜੋ ਤੁਸੀਂ ਲਿਖ ਸਕਦੇ ਹੋ ਕਿਸੇ ਵੀ ਲੜੀ ਨਾਲੋਂ ਵਧੇਰੇ ਸੰਕੁਚਿਤ ਬਿਆਨ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਬਣਾਈ ਕੋਈ ਵੀ ਦੂਜੀ ਭੌਤਿਕ ਨੀਤੀ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਉਲਟਾ ਸਾਬਤ ਨਾ ਕਰੇ।

ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਦੋਂ ਸਾਰੇ ਸਪੋਕ ਇੱਕੋ ਸਮੇਂ ਰੁੱਝੇ ਹੋਣ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਹੁੰਦਾ ਹੈ, ਕਿਹੜੀ ਸ਼੍ਰੇਣੀ ਨੂੰ ਤਰਜੀਹ ਮਿਲਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਕਤਾਰ ਮੁਕਾਬਲੇ ਦੀ ਮਾਲਕ ਹੈ। ਪ੍ਰਤੀ-ਸਪੋਕ ਸੀਮਾ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ, ਕਿਉਂਕਿ ਹਰ ਸਪੋਕ ਨੂੰ ਇਕੱਲਾ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ।

ਢਾਲਣ ਦੀਆਂ ਇਕਾਈਆਂ ਅਤੇ ਓਵਰਹੈੱਡ ਲੇਖਾ-ਜੋਖਾ ਨੂੰ ਅਸਲ ਸੌਂਪਣ ਨਾਲ ਮਿਲਾਓ। ਦਰ ਦੀ ਗਣਨਾ ਤੋਂ ਬਾਹਰ ਛੱਡਿਆ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਓਵਰਹੈੱਡ ਕਨਫਿਗਰ ਕੀਤੇ ਅੰਕ ਤੋਂ ਪਹਿਲਾਂ ਭਰ ਜਾਣ ਵਾਲੀ ਲਿੰਕ ਵਜੋਂ ਦਿਸਦਾ ਹੈ।

ਕਾਊਂਟਰ ਇੱਕ ਖ਼ਾਸ ਤਰੀਕੇ ਨਾਲ ਝੂਠ ਬੋਲਦੇ ਹਨ

ਜਿਸ ਪਰਤ ਨੂੰ ਤੁਸੀਂ ਢਾਲ ਰਹੇ ਹੋ ਉੱਥੇ ਕਾਊਂਟਰ ਪੜ੍ਹੋ। ਉਹੀ Cisco ਗਾਈਡ ਚੇਤਾਵਨੀ ਦਿੰਦੀ ਹੈ ਕਿ ਮੁੱਖ ਇੰਟਰਫ਼ੇਸ ਨੀਤੀ ਕਾਊਂਟਰ ਇਸ ਬਣਤਰ ਵਿੱਚ ਗ਼ਲਤ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਕਾਊਂਟਰ ਬਾਰੇ ਚੇਤਾਵਨੀ ਹੈ, ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਕੋਈ ਸ਼੍ਰੇਣੀ ਮਿਲ ਰਹੀ ਹੈ ਜਾਂ ਛੱਡ ਰਹੀ ਹੈ। ਇਸਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਨਤੀਜੇ ਤੋਂ ਵੱਖ ਰੱਖੋ, ਜੋ ਵਰਤੋਂਕਾਰ ਵੇਖਦਾ ਹੈ ਉਹ ਇੱਕੋ ਚੀਜ਼ ਹੈ।

ਪੁਰਾਣੀ traffic-shape ਉਦਾਹਰਨ ਨੂੰ ਅਸੰਬੰਧਿਤ ਨੀਤੀ ਨਕਸ਼ੇ ਦੇ ਕੋਲ ਕਾਪੀ ਕਰਨਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਦੋਵੇਂ ਦਰਾਂ ਇੱਕੋ ਪੈਕਟ ਨਿਯੰਤਰਿਤ ਕਰਦੀਆਂ ਹਨ।

ਕੁੱਲ ਦੀ ਪਰਖ ਕਰੋ, ਸਿਰਫ਼ ਸੀਮਾ ਦੀ ਨਹੀਂ

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

ਉਸ ਸਮੇਂ ਹੱਲ ਸਮਰੱਥਾ ਜਾਂ ਦਾਖਲੇ ਦਾ ਫੈਸਲਾ ਹੈ। ਪ੍ਰਤੀ-ਸਪੋਕ ਅੰਕ ਦੁਬਾਰਾ ਸੈਟ ਕਰਨਾ ਸਿਰਫ਼ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਸ਼ਾਖਾ ਪਹਿਲਾਂ ਸ਼ਿਕਾਇਤ ਕਰਦੀ ਹੈ।