VPN ਗੇਟਵੇ ਪੋਰਟ 'ਤੇ ਡੁਪਲੈਕਸ ਬੇਮੇਲ: ਦੋਵੇਂ ਸਿਰੇ ਪੜ੍ਹੋ

ਟਨਲ ਰਾਹੀਂ ਫਾਈਲ ਕਾਪੀ ਇੱਕ ਸਕਿੰਟ ਲਈ ਰੁਕਦੀ ਹੈ, ਫਿਰ ਚੱਲਦੀ ਹੈ, ਅਤੇ VPN ਲੌਗ ਕੁਝ ਨਹੀਂ ਦਿਖਾਉਂਦੇ। ਐਪਲੀਕੇਸ਼ਨ ਨੈੱਟਵਰਕ ਨੂੰ ਦੋਸ਼ ਦਿੰਦੀ ਹੈ, ਨੈੱਟਵਰਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਦੋਸ਼ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਵਿੱਚ ਪੋਰਟ ਗਿਆਰਾਂ ਮਹੀਨਿਆਂ ਤੋਂ ਚਾਲੂ ਹੈ। ਇਹ ਮਾਰਗਦਰਸ਼ਨ ਰੁਕਾਵਟ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਕੇ ਬਾਹਰ ਵੱਲ ਭੌਤਿਕ ਲਿੰਕ ਤੱਕ ਜਾਂਦੀ ਹੈ: ਪੋਰਟ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਦੂਰ ਵਾਲਾ ਸਿਰਾ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਵੇਖ ਰਹੇ ਸੀ ਤਾਂ ਕਾਊਂਟਰਾਂ ਨੇ ਕੀ ਕੀਤਾ। ਕਿਸੇ ਦੇ ਵੀ ਡੁਪਲੈਕਸ ਸੈਟਿੰਗ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ।

ਪੋਰਟ ਤੋਂ ਨਹੀਂ, ਰੁਕਾਵਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

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

ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਡੁਪਲੈਕਸ ਬੇਮੇਲ ਦੀ ਇੱਕ ਪਛਾਣ ਹੁੰਦੀ ਹੈ: ਗਲਤੀਆਂ ਸਿਰਫ਼ ਲੋਡ ਹੇਠ, ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ ਦਿਖਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਛੋਟੇ ping ਅਤੇ ਇੰਟਰਐਕਟਿਵ ਸੈਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਠੀਕ ਰਹਿੰਦੇ ਹਨ। ਜੇ ਨਿਸ਼ਕਿਰਿਆ ਟ੍ਰੈਫ਼ਿਕ ਵੀ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਪਹਿਲਾਂ ਕਿਤੇ ਹੋਰ ਵੇਖੋ।

ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਓਪਰੇਸ਼ਨਲ ਮੋਡ ਪੜ੍ਹੋ

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

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

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

ਜੇ ਤੁਸੀਂ ਦੂਰ ਵਾਲਾ ਸਿਰਾ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਦਾ ਨਿਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਮਾਲਕ ਤੋਂ ਓਪਰੇਸ਼ਨਲ ਮੋਡ ਅਤੇ ਕਾਊਂਟਰ ਮੰਗੋ, ਜਾਂ ਆਪਣਾ ਪਾਸਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧ ਕਰੋ।

10/100 ਅੱਧਾ ਡੁਪਲੈਕਸ ਮਾਮਲਾ ਕਿਹੋ ਜਿਹਾ ਦਿਖਦਾ ਹੈ

10/100 ਤਾਂਬੇ ਦੇ ਲਿੰਕਾਂ 'ਤੇ, ਆਟੋਨੈਗੋਸ਼ੀਏਟ ਕਰਨ ਵਾਲਾ ਸਿਰਾ ਜ਼ਬਰਦਸਤੀ ਸੈੱਟ ਕੀਤੇ ਸਾਥੀ ਦੀ ਰਫ਼ਤਾਰ ਲੱਭ ਸਕਦਾ ਹੈ ਪਰ ਉਸ ਦੀ ਡੁਪਲੈਕਸ ਸੈਟਿੰਗ ਨਹੀਂ ਸਿੱਖਦਾ। ਸਮਾਨਾਂਤਰ ਖੋਜ ਸਿਗਨਲ ਤੋਂ ਰਫ਼ਤਾਰ ਤੈਅ ਕਰਦੀ ਹੈ, ਅਤੇ ਡੁਪਲੈਕਸ ਗੱਲਬਾਤ ਦੀ ਥਾਂ ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਪਾਸਾ ਅੱਧੇ ਡੁਪਲੈਕਸ 'ਤੇ ਰਹਿ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜਾ ਪੂਰੇ 'ਤੇ ਚੱਲਦਾ ਹੈ।

Cisco ਦੀ ਆਟੋਨੈਗੋਸ਼ੀਏਸ਼ਨ ਮਾਰਗਦਰਸ਼ਿਕਾ ਉਸ ਖ਼ਾਸ ਮਾਮਲੇ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਇਹ ਹਰ ਥਾਂ ਨੈਗੋਸ਼ੀਏਸ਼ਨ ਬੰਦ ਕਰਨ ਦੀ ਦਲੀਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਗੀਗਾਬਿਟ ਤਾਂਬੇ ਬਾਰੇ ਇਹ ਕੁਝ ਵੀ ਲਾਭਦਾਇਕ ਨਹੀਂ ਕਹਿੰਦੀ, ਜਿੱਥੇ ਡੁਪਲੈਕਸ ਸਥਿਰ ਹੈ ਅਤੇ ਲਿੰਕ ਦੇ ਉੱਠਣ ਲਈ ਆਟੋਨੈਗੋਸ਼ੀਏਸ਼ਨ ਜ਼ਰੂਰੀ ਹੈ।

ਦੇਖਣਯੋਗ ਸਬੂਤ ਉਹਨਾਂ ਗਲਤੀਆਂ ਦਾ ਮਿਸ਼ਰਣ ਹੈ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ: ਪੂਰੇ ਡੁਪਲੈਕਸ ਪਾਸੇ FCS ਜਾਂ CRC ਗਲਤੀਆਂ, ਅੱਧੇ ਡੁਪਲੈਕਸ ਪਾਸੇ ਟਕਰਾਅ ਜਾਂ ਦੇਰ ਨਾਲ ਟਕਰਾਅ, ਅਤੇ ਲੋਡ ਹੇਠ ਢਹਿੰਦੀ ਥ੍ਰੂਪੁੱਟ, ਜਦੋਂ ਕਿ ਨਿਸ਼ਕਿਰਿਆ ਹਾਲਤ ਵਿੱਚ ਦੇਰੀ ਆਮ ਰਹਿੰਦੀ ਹੈ। ਇਹੀ ਅਸਮਾਨਤਾ ਪਛਾਣ ਹੈ। ਸਿਰਫ਼ ਵੱਧ ਭਾਰ ਵਾਲਾ ਲਿੰਕ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅਤੇ ਹਰ ਸਮੇਂ ਵਿਗੜਦਾ ਹੈ।

ਦੋਵੇਂ ਸਿਰੇ ਇਕੱਠੇ ਬਦਲੋ, ਵਾਪਸੀ ਦਾ ਰਾਹ ਰੱਖਦਿਆਂ

ਡੁਪਲੈਕਸ ਸੁਧਾਰ ਇੱਕ ਤਾਲਮੇਲ ਵਾਲਾ ਬਦਲਾਅ ਹੈ, ਸਥਾਨਕ ਨਹੀਂ। ਦੂਜੇ ਸਿਰੇ ਦੀ ਸਹਿਮਤੀ ਬਿਨਾਂ ਆਪਣਾ ਪਾਸਾ ਜ਼ਬਰਦਸਤੀ ਕਰਨਾ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਚੱਲਦਾ ਲਿੰਕ ਟੁੱਟਿਆ ਹੋਇਆ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ CLI ਦਾ ਕਮਾਂਡ ਸਵੀਕਾਰ ਕਰਨਾ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਿੰਟੈਕਸ ਵੈਧ ਸੀ।

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

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

ਕਈ ਆਧੁਨਿਕ ਲਿੰਕਾਂ 'ਤੇ ਸਹੀ ਜਵਾਬ ਇਹ ਹੈ ਕਿ ਕੁਝ ਵੀ ਜ਼ਬਰਦਸਤੀ ਕਰਨ ਦੀ ਥਾਂ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਆਟੋਨੈਗੋਸ਼ੀਏਸ਼ਨ ਚਾਲੂ ਰਹਿਣ ਦਿਓ। ਜ਼ਬਰਦਸਤੀ ਕਰਨਾ ਕਿਸੇ ਖ਼ਾਸ ਤਕਨੀਕ 'ਤੇ ਖ਼ਾਸ ਬੇਮੇਲ ਦਾ ਇਲਾਜ ਹੈ, ਆਮ ਸੁਧਾਰ ਨਹੀਂ। ਖ਼ਾਸ ਕਰਕੇ ਗੀਗਾਬਿਟ ਤਾਂਬੇ ਨੂੰ ਲਿੰਕ ਉੱਠਣ ਲਈ ਆਟੋਨੈਗੋਸ਼ੀਏਸ਼ਨ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ 10/100 ਦੀ ਸਲਾਹ ਉੱਥੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਾਊਂਟਰ ਚੰਗੇ ਪਾਸੇ ਵੱਲ ਸਰਕੇ

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਓਪਰੇਸ਼ਨਲ ਹਾਲਤ ਦੁਬਾਰਾ ਪੜ੍ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹ ਮਿਲਦੇ ਹਨ। ਫਿਰ ਉਹੀ ਕੰਮ ਦਾ ਭਾਰ ਚਲਾਓ ਜਿਸ ਨੇ ਰੁਕਾਵਟ ਪੈਦਾ ਕੀਤੀ ਸੀ ਅਤੇ ਜੀਵਨ ਭਰ ਦੇ ਕੁੱਲ ਜੋੜ ਦੀ ਥਾਂ ਕਾਊਂਟਰਾਂ ਦੇ ਫ਼ਰਕ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਸਾਲ ਭਰ ਤੋਂ ਇਕੱਠਾ ਹੁੰਦਾ ਕੁੱਲ ਜੋੜ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਪਿਛਲੇ ਦਸ ਮਿੰਟਾਂ ਵਿੱਚ ਕੀ ਹੋਇਆ।

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

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

ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੇ ਅੰਕੜੇ ਸਮੇਂ ਦੀ ਛਾਪ ਸਮੇਤ ਟਿਕਟ ਵਿੱਚ ਲਿਖੋ। ਉਹੀ ਰਿਕਾਰਡ «VPN ਬਿਹਤਰ ਲੱਗਦਾ ਹੈ» ਨੂੰ ਅਜਿਹੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਿਸ 'ਤੇ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਖੜ੍ਹਾ ਹੋ ਸਕੇ।