ਜਦੋਂ ਸਪਲਿਟ ਟਨਲ ਦੇ ਰੂਟ ਓਵਰਲੈਪ ਹੁੰਦੇ ਹਨ: ਕਿਹੜਾ ਪ੍ਰੀਫਿਕਸ ਜਿੱਤਦਾ ਹੈ

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

1. ਟਿਕਾਣਾ ਅਤੇ ਸਰੋਤ ਲਿਖੋ

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

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

2. ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜਾ ਰੂਟ ਚੁਣਿਆ

ਰੂਟ ਸਾਰਣੀ ਪੜ੍ਹ ਕੇ ਜਵਾਬ ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ। ਸਟੈਕ ਜੋ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ ਉਹੀ ਸਵਾਲ ਉਸੇ ਸਰੋਤ ਪਤੇ ਨਾਲ ਪੁੱਛੋ: Linux ’ਤੇ ip route get 10.20.4.10 from 10.8.0.2, ਜਾਂ PowerShell ਵਿੱਚ Find-NetRoute -RemoteIPAddress 10.20.4.10। ਨਤੀਜਾ ਉਹ ਰੂਟ ਦੱਸਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਉਹ ਅਕਸਰ ਉਹ ਨਹੀਂ ਹੁੰਦਾ ਜਿਸਦੀ ਸਾਰਣੀ ਪੜ੍ਹਦਿਆਂ ਤੁਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ।

ਮੇਲ ਖਾਂਦੇ ਰੂਟਾਂ ਵਿੱਚ ਆਮ ਤੌਰ ’ਤੇ ਵਧੇਰੇ ਖਾਸ ਪ੍ਰੀਫਿਕਸ ਜਿੱਤਦਾ ਹੈ: ਦੋਵਾਂ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਪਤੇ ਲਈ /24, /16 ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ। ਇੱਕੋ ਲੰਬਾਈ ਦੀਆਂ ਮੇਲਾਂ ਵਿੱਚ ਘੱਟ ਮੈਟ੍ਰਿਕ ਜਿੱਤਦੀ ਹੈ, ਅਤੇ ਬੰਦ ਲਿੰਕ ’ਤੇ ਲੱਗਿਆ ਰੂਟ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕੋ /24 ਨੂੰ ਇੱਕੋ ਮੈਟ੍ਰਿਕ ਨਾਲ ਧੱਕਣ ਵਾਲੇ ਦੋ ਟਨਲ ਵੱਖਰਾ ਮਾਮਲਾ ਹਨ: ਕਰਨਲ ਦੋਵੇਂ ਰੂਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਚੁਣਦਾ ਹੈ, ਇਸ ਲਈ ਨਤੀਜਾ ਕਲਾਇੰਟ ਦੇ ਜੁੜਨ ਦੇ ਕ੍ਰਮ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਥਾਂ ਬਦਲਦਾ ਰਹਿ ਸਕਦਾ ਹੈ। ਸੋਮਵਾਰ-ਚੱਲਦਾ-ਹੈ-ਮੰਗਲਵਾਰ-ਫੇਲ੍ਹ-ਹੁੰਦਾ-ਹੈ ਨਮੂਨਾ ਇਹੀ ਹਾਲਤ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਕਿਸੇ ਹੋਰ ਕ੍ਰਮ ਵਿੱਚ ਦੁਬਾਰਾ ਜੁੜਨ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ।

3. ਜਾਂਚੋ ਕਿ ਕਿਸੇ ਨੀਤੀ ਨਿਯਮ ਨੇ ਖੋਜ ਨੂੰ ਕਿਤੇ ਹੋਰ ਮੋੜਿਆ

ਰੂਟ ਸਾਰਣੀ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰਨਲ ਆਪਣੇ ਨੀਤੀ ਨਿਯਮਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ। ਨਿਯਮ ਕਿਸੇ ਦਿੱਤੇ ਸਰੋਤ, ਵਰਤੋਂਕਾਰ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਸ਼ਾਨ ਦੀ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਬਿਲਕੁਲ ਹੋਰ ਸਾਰਣੀ ਵਿੱਚ ਭੇਜ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਮੁੱਖ ਸਾਰਣੀ ਦਾ ਜਿੱਤਣ ਵਾਲਾ ਪ੍ਰੀਫਿਕਸ ਉਸ ਪ੍ਰਵਾਹ ਲਈ ਕਦੇ ਨਾ ਵੇਖਿਆ ਜਾਵੇ। ip rule show ਉਨ੍ਹਾਂ ਨੂੰ ਮੁਲਾਂਕਣ ਕ੍ਰਮ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ip route show table 100 ਦੱਸਦਾ ਹੈ ਕਿ ਚੁਣੀ ਸਾਰਣੀ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ।

ਇੱਥੇ ਦੋ ਜਾਲ ਹਨ। ਖਾਲੀ ਸਾਰਣੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਅਗਲੇ ਨਿਯਮ ’ਤੇ ਡਿੱਗਣ ਵਾਲੀ ਖੋਜ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਨਿਯਮ ਕੁਝ ਨਾ ਕਰਦਾ ਜਾਪਦਾ ਹੈ। ਦੂਜਾ ਜਾਲ ਪਹਿਲ ਕ੍ਰਮਾਂਕ ਆਪ ਹੈ: ਨਿਯਮ ਵਧਦੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਅੰਦਰੂਨੀ ਮੁੱਲ 0 local, 32766 main ਅਤੇ 32767 default ਹਨ। 32767 ਤੋਂ ਘੱਟ ਨੰਬਰ ਵਾਲਾ ਨਿਯਮ ਸਭ ਨੂੰ ਫੜਨ ਵਾਲੇ ਡਿਫ਼ਾਲਟ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ। 32767 ਤੋਂ ਵੱਧ ਨੰਬਰ ਵਾਲਾ ਨਿਯਮ ਉਸਦੇ ਪਿੱਛੇ ਬੈਠਦਾ ਹੈ ਅਤੇ ਤਦ ਹੀ ਪਹੁੰਚਦਾ ਹੈ ਜਦੋਂ ਪਹਿਲਾਂ ਦੀ ਕੋਈ ਸਾਰਣੀ ਜਵਾਬ ਨਾ ਦੇਵੇ, ਜਿਸਨੂੰ main ਵਿੱਚ ਆਮ ਡਿਫ਼ਾਲਟ ਰੂਟ ਰੋਕਦਾ ਹੈ, ਇਸ ਲਈ ਵਿਵਹਾਰ ਵਿੱਚ ਉੱਥੇ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ ਅਤੇ ਸਥਾਪਿਤ ਦਿਸਦੇ ਹੋਏ ਵੀ ਚੁੱਪਚਾਪ ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਕਲਾਇੰਟ ਨੇ ਨਿਯਮ ਅਤੇ ਰੂਟ ਦੋਵੇਂ ਲਿਖੇ ਹਨ, ਤਾਂ ਦੋਵੇਂ ਜਾਂਚੋ, ਅਤੇ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਫਿਰ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਦੁਬਾਰਾ ਲਿਖਿਆ ਪ੍ਰੋਫਾਈਲ ਵੱਖਰੀ ਪਹਿਲ ਵਾਲਾ ਦੂਜਾ ਨਿਯਮ ਜੋੜ ਸਕਦਾ ਹੈ।

4. ਰੂਟਿੰਗ ਦੀ ਬਰਾਬਰੀ ਨੂੰ ਦੁਹਰਾਏ ਪਤੇ ਦੀ ਯੋਜਨਾ ਤੋਂ ਵੱਖ ਕਰੋ

ਕਈ ਵਾਰ ਪ੍ਰੀਫਿਕਸ ਬਿਲਕੁਲ ਵੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦਾ। ਦੋਵੇਂ ਥਾਵਾਂ 192.168.1.0/24 ਵਰਤਦੀਆਂ ਹਨ ਦਾ ਅਰਥ ਹੈ ਇੱਕੋ ਪਤਾ ਦੋ ਵੱਖਰੇ ਹੋਸਟਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਰੂਟ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਦੋ ਜਵਾਬਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੱਲ ਹੋਸਟ ਰੂਟ ਤਦ ਤੱਕ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਦੂਜੀ ਥਾਂ ਉਸੇ ਨਾਮ ਲਈ ਜਵਾਬ ਨਾ ਦੇਵੇ, ਅਤੇ ਫਿਰ ਅਪਵਾਦ ਚੁੱਪਚਾਪ ਹੀ ਖਰਾਬੀ ਬਣ ਜਾਂਦਾ ਹੈ।

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

5. ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਿਜ਼ੌਲਵਰ ਰੂਟ ਨਾਲ ਸਹਿਮਤ ਹੈ

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

ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਸਿੱਧਾ ਪੁੱਛੋ ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸਰਵਰ ਨੋਟ ਕਰੋ। ਘੱਟ TTL ਵਾਲਾ ਕੈਸ਼ ਜਵਾਬ ਇਹ ਵੀ ਸਮਝਾ ਸਕਦਾ ਹੈ ਕਿ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਬੇਨਤੀ ਪੰਜਵੀਂ ਨਾਲੋਂ ਵੱਖਰੀ ਕਿਉਂ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ।

6. ਦੁਬਾਰਾ ਜੁੜੋ, ਲਾਗੂ ਹਾਲਤ ਵੇਖੋ, ਫਿਰ ਦੋਵੇਂ ਪ੍ਰਵਾਹ ਜਾਂਚੋ

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

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