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

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

ਸਵਾਲ ਹੱਲ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਜਾਂਚਾਂ

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

ObservationRouting loopRoute flapping
Prefix in the tableInstalled, same next hop throughoutWithdrawn and reinstalled, or next hop alternates
Hop countReaches zero at the same two gatewaysExpires only while the prefix is missing
Failure shapeConsistent loss for that prefix from every sourceBursts, often after a link or peer event
Where the fix belongsThe site that owns the prefix, plus filters on the transit pathAdvertisement, hold timers, or the flapping link

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

ਪਹਿਲੀ ਜਾਂਚ: ਪ੍ਰੀਫ਼ਿਕਸ ਸਥਿਰ ਹੈ ਜਾਂ ਹਿਲ ਰਿਹਾ ਹੈ

ਕਾਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਸ ਨੇ ਕੀ ਸਥਾਪਿਤ ਕੀਤਾ, ਇਹ ਨਹੀਂ ਕਿ ਕਾਨਫ਼ਿਗਰੇਸ਼ਨ ਫ਼ਾਈਲ ਕੀ ਵਾਅਦਾ ਕਰਦੀ ਹੈ। ਲੀਨਕਸ ਗੇਟਵੇ 'ਤੇ ip route get 10.20.30.40 ਉਹੀ ਖੋਜ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਫ਼ਾਰਵਰਡਿੰਗ ਰਾਹ ਚਲਾਉਂਦਾ ਹੈ, ਨੀਤੀ ਟੇਬਲਾਂ ਸਮੇਤ, ਜਦਕਿ ip route show 10.20.30.0/24 ਐਂਟਰੀ ਆਪ ਦਿਖਾਉਂਦਾ ਹੈ। ip monitor route ਹਰ ਬਦਲਾਅ ਨੂੰ ਹੁੰਦਿਆਂ ਹੀ ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੀਫ਼ਿਕਸ ਨੂੰ ਆਉਂਦਿਆਂ-ਜਾਂਦਿਆਂ ਦੇਖਣ ਦਾ ਇਹ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।

FRR ਜਾਂ BIRD ਚਲਾਉਣ ਵਾਲੇ ਰਾਊਟਰ 'ਤੇ ਦਿਲਚਸਪ ਚੀਜ਼ ਫ਼ਾਰਵਰਡਿੰਗ ਟੇਬਲ ਨਹੀਂ ਹੁੰਦੀ। show ip bgp 10.20.30.0/24 ਚੁਣਿਆ ਰਾਹ ਅਤੇ ਉਸ ਦਾ ਅੱਪਟਾਈਮ ਵਾਪਸ ਦਿੰਦਾ ਹੈ; ਹਰ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ ਰੀਸੈਟ ਹੋਣ ਵਾਲਾ ਅੱਪਟਾਈਮ ਉਹ ਫਲੈਪਿੰਗ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ, ਲੂਪ ਨਹੀਂ। show ip bgp summary ਗੁਆਂਢੀ ਦੀ ਹਾਲਤ ਅਤੇ ਪ੍ਰੀਫ਼ਿਕਸ ਗਿਣਤੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਵਾਰ-ਵਾਰ ਡਿੱਗਣ ਵਾਲਾ ਸਾਥੀ ਫ਼ਾਰਵਰਡਿੰਗ ਰਾਹ ਤੋਂ ਦੋਸ਼ ਹਟਾ ਦਿੰਦਾ ਹੈ।

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

ਦੂਜੀ ਜਾਂਚ: ਕੀ ਅਗਲਾ ਹੌਪ ਆਗਮਨ ਟਨਲ ਵੱਲ ਵਾਪਸ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ

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

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

WireGuard ਆਪਣੇ ਨੋਟ ਦਾ ਹੱਕਦਾਰ ਹੈ, ਕਿਉਂਕਿ ਦੋਸ਼ ਦੇਣ ਲਈ ਕੋਈ ਘੋਸ਼ਣਾ ਨਹੀਂ ਹੈ। wg show ਹਰ ਸਾਥੀ ਦੇ AllowedIPs ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਾਰਨਲ ਸਾਥੀ ਲਈ ਮੰਜ਼ਿਲ ਤਾਂ ਹੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜੇ ਉਹ ਉਸ ਰੇਂਜ ਵਿੱਚ ਆਉਂਦੀ ਹੈ। ਉੱਥੇ ਲੂਪ ਦਾ ਮਤਲਬ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਢਕਣ ਵਾਲੀ AllowedIPs ਰੇਂਜ ਜਾਂ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਵਾਪਸ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਥਿਰ ਰੂਟ ਹੈ, ਇਸ ਲਈ ਮੁਰੰਮਤ ਸਿਰਫ਼ ਉਹਨਾਂ ਦੋ ਥਾਵਾਂ 'ਤੇ ਹੈ।

ਤੀਜੀ ਜਾਂਚ: ਹੌਪ ਗਿਣਤੀ ਪੜ੍ਹੋ, ਤਾਰੇ ਨਹੀਂ

traceroute -n -I 10.20.30.40 ਅਤੇ mtr -n -r -c 20 10.20.30.40 ਦੋਵੇਂ ਰਾਹ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ICMP ਮੋਡ ਅਕਸਰ ਉਸ ਫਿਲਟਰਿੰਗ ਤੋਂ ਬਚ ਜਾਂਦਾ ਹੈ ਜੋ UDP ਪ੍ਰੋਬ ਖਾ ਜਾਂਦੀ ਹੈ। ਲੂਪ ਉਹਨਾਂ ਹੀ ਦੋ ਗੇਟਵੇ ਪਤਿਆਂ ਦੇ ਛੋਟੇ ਦੁਹਰਾਉਣ ਵਾਲੇ ਕ੍ਰਮ ਵਰਗਾ ਦਿਸਦਾ ਹੈ, ਹਰ ਵਾਰ TTL ਵਧਦਾ ਹੈ। ਡਿੱਗਣਾ ਆਖ਼ਰੀ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਗੇਟਵੇ ਮਗਰੋਂ ਤਾਰਿਆਂ ਵਰਗਾ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਚੁੱਪ ਹੌਪ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸਬੂਤ ਨਹੀਂ।

ਜਦੋਂ ਰਾਹ ਅਸਪਸ਼ਟ ਹੋਵੇ, ਤਾਰ 'ਤੇ TTL ਪੜ੍ਹੋ। ਦੋਵੇਂ ਗੇਟਵੇ 'ਤੇ tcpdump -ni any -vv icmp ਹਰ ਪੈਕਟ ਦਾ TTL ਅਤੇ ਸਮਾਂ ਲੰਘਣ ਵਾਲੇ ਹਰ ਜਵਾਬ ਦਾ ਸਰੋਤ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੇ ਪੈਕਟ ਦੂਰ ਦੀ ਸਾਈਟ 'ਤੇ ਰਾਹ ਵਿੱਚ ਹੋ ਸਕਣ ਵਾਲੀ ਹੌਪ ਗਿਣਤੀ ਤੋਂ ਘੱਟ TTL ਨਾਲ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਹੌਪ ਜੋੜ ਰਿਹਾ ਹੈ ਜੋ traceroute ਤੁਹਾਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਅਤੇ ਇਹ ਤਦ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਸਾਈਟ ਦਾ ਫ਼ਾਇਰਵਾਲ ਦੂਜੇ ਵੱਲੋਂ ਪ੍ਰੋਬਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਪ੍ਰੀਫ਼ਿਕਸ ਦੇ ਮਾਲਕ ਦੀ ਮੁਰੰਮਤ ਕਰੋ, ਫਿਰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਜਾਂਚੋ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ