OSPF ਵੱਧ ਤੋਂ ਵੱਧ ਮੈਟ੍ਰਿਕ: ਸ਼ਾਖਾ ਨੂੰ ਹਟਾਏ ਬਿਨਾਂ ਉਸ ਦੇ ਟ੍ਰਾਂਜ਼ਿਟ ਨੂੰ ਨਿਰੁਤਸਾਹਿਤ ਕਰਨਾ

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

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

ਉਸ ਮਾਰਗ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ ਤੋਂ ਬਚਣਾ ਹੈ

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

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

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

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

ਵੱਧ ਤੋਂ ਵੱਧ ਮੈਟ੍ਰਿਕ ਕੀ ਐਲਾਨਦੀ ਹੈ

RFC 6987 ਇੱਕ ਰਾਊਟਰ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਆਪਣੇ ਗੈਰ-ਸਟਬ ਲਿੰਕ ਵੱਧ ਤੋਂ ਵੱਧ ਲਿੰਕ ਮੈਟ੍ਰਿਕ ਨਾਲ ਐਲਾਨਦਾ ਹੈ, ਜੋ 0xffff ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਹੈ। ਰਾਊਟਰ ਅਜੇ ਵੀ ਆਪਣੇ ਆਪ ਅਤੇ ਆਪਣੇ ਲਿੰਕਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ; ਇਹ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਨੂੰ ਰੇਂਜ ਦੇ ਉੱਪਰਲੇ ਸਿਰੇ ’ਤੇ ਕੀਮਤ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਦੂਜਾ ਰਾਊਟਰ ਇਸ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲੇ ਮਾਰਗ ਨੂੰ ਮਹਿੰਗਾ ਗਿਣਦਾ ਹੈ।

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

RFC 6987 ਵਿਧੀ ਦਾ ਖੇਤਰ ਕਿਸਮਾਂ ਜਾਂ ਨਾਮਜ਼ਦ-ਰਾਊਟਰ ਚੋਣ ਨਾਲ ਵੀ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ। ਸਟਬ ਖੇਤਰ ਖੇਤਰ ਸੀਮਾ ’ਤੇ ਲਿੰਕ-ਸਟੇਟ ਐਲਾਨਾਂ ਦੀ ਇੱਕ ਸ਼੍ਰੇਣੀ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਸਟਬ ਰਾਊਟਰ ਆਪਣੇ ਲਿੰਕਾਂ ਦੀ ਕੀਮਤ ਤੈਅ ਕਰਦਾ ਹੈ। ਮਿਲਦੇ-ਜੁਲਦੇ ਸ਼ਬਦ, ਅਸੰਬੰਧਿਤ ਮਸ਼ੀਨਰੀ।

ਪਹੁੰਚ ਯੋਗਤਾ ਕਿਉਂ ਬਚੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਨਹੀਂ

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

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

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

ਆਖਰੀ ਮਾਰਗ ਦੀ ਸਮੱਸਿਆ

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

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

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

OSPFv3 ਲਈ RFC R-ਬਿੱਟ ਨੂੰ ਟ੍ਰਾਂਜ਼ਿਟ ਭਾਗੀਦਾਰੀ ਬਾਹਰ ਕਰਨ ਦੇ ਵੱਖਰੇ ਤਰੀਕੇ ਵਜੋਂ ਚਰਚਾ ਕਰਦਾ ਹੈ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਇਹ ਵੱਧ-ਮੈਟ੍ਰਿਕ ਤਕਨੀਕ ਵਰਗਾ ਹੀ ਆਖਰੀ-ਮਾਰਗ ਵਿਵਹਾਰ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਦੋ ਪਤਾ ਪਰਿਵਾਰਾਂ ਵਿਚਕਾਰ ਸੈਟਿੰਗਾਂ ਨਕਲ ਨਾ ਕਰੋ ਜਿਵੇਂ ਉਹ ਇੱਕੋ ਵਿਸ਼ੇਸ਼ਤਾ ਹੋਣ।

ਆਮ ਅਤੇ ਫੇਲ੍ਹ ਹਾਲਾਤਾਂ ਵਿੱਚ ਇਸ ਨੂੰ ਸਾਬਤ ਕਰੋ

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

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

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

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