ਦੋ ਅਪਲਿੰਕ ਇੱਕੋ fe80::1 ਸਾਂਝਾ ਕਰਦੇ ਹੋਣ ਤੇ IPv6 ਨੀਤੀ ਰੂਟਿੰਗ

ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਅਪਲਿੰਕ ਹਨ, ਅਤੇ ip -6 route show ਦੋਵਾਂ ਉੱਤੇ ਇੱਕੋ ਅਗਲਾ ਹੌਪ ਛਾਪਦਾ ਹੈ: default via fe80::1 dev uplink0 ਅਤੇ default via fe80::1 dev uplink1। ਇਹ ਪਤਾ ਦੋਹਰਾ ਹੋਣ ਦਾ ਟਕਰਾਅ ਨਹੀਂ, ਅਤੇ ਸਿਰਫ਼ ਅਗਲਾ ਹੌਪ fe80::1 ਨੀਤੀ ਸਾਰਣੀ ਵਿੱਚ ਕਾਪੀ ਕਰਨ ਨਾਲ ਕਰਨਲ ਨੂੰ ਨਹੀਂ ਪਤਾ ਲੱਗਦਾ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਲਿੰਕ ਚਾਹੁੰਦੇ ਹੋ। ਅਸਲ ਸਵਾਲ ਲੱਛਣ ਦੇ ਸੰਕੇਤ ਨਾਲੋਂ ਤੰਗ ਹੈ: ਦੂਜੀ ਸਾਰਣੀ ਨੂੰ ਇੱਕ ਲਿੰਕ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਦੋਵੇਂ, ਅਤੇ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਉਹ ਰੂਟ ਜਿਉਂਦੇ ਕੀ ਰੱਖਦਾ ਹੈ। ਕ੍ਰਮ ਨਾਲ ਜਾਂਚੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ ਬਹੁਤਾ ਹੱਲ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।

ਉਹੀ fe80::1 ਦੋ ਵੱਖਰੇ ਗੁਆਂਢੀ ਹਨ

ਲਿੰਕ-ਸਥਾਨਕ ਪਤੇ ਇੱਕ ਲਿੰਕ ਤੱਕ ਸੀਮਤ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ fe80::1 ਦੋ ਵਾਰ ਛਾਪਿਆ ਇੱਕੋ ਪਤਾ ਨਹੀਂ; ਇਹ ਇੱਕੋ ਪਿਛੇਤਰ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਦੋ ਗੁਆਂਢੀ ਹਨ। ਜ਼ੋਨ ਇੰਡੈਕਸ ਹੀ ਹੋਸਟ ਦਾ ਇਹ ਦੱਸਣ ਦਾ ਢੰਗ ਹੈ ਕਿ ਕਿਹੜਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ fe80::1%uplink0 ਅਤੇ fe80::1%uplink1 ਕਰਨਲ ਲਈ ਵੱਖਰੀਆਂ ਮੰਜ਼ਿਲਾਂ ਹਨ, ਅਤੇ ਉਹ ਪਿਛੇਤਰ ਕਦੇ ਦੂਰ ਦੇ ਰਾਊਟਰ ਤੱਕ ਨਹੀਂ ਜਾਂਦਾ। RFC 4007 ਇਸ ਪਿੱਛੇ ਦਾ ਜ਼ੋਨ ਮਾਡਲ ਬਿਆਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਨੀਤੀ ਸਾਰਣੀ ਨੂੰ ਹਰ ਲਿੰਕ-ਸਥਾਨਕ ਅਗਲੇ ਹੌਪ ਨਾਲ ਜੰਤਰ ਲੈ ਕੇ ਚੱਲਣਾ ਪੈਂਦਾ ਹੈ।

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

ਜੰਤਰ ਹਟਾਓ ਅਤੇ ਰੂਟ ਲਿਖਣਯੋਗ ਨਹੀਂ ਰਹਿੰਦਾ। ip -6 route add default via fe80::1 table 200 ਗੇਟਵੇ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ iproute2 ਇਸਨੂੰ Error: Nexthop has invalid gateway. ਗਲਤੀ ਨਾਲ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। dev uplink0 ਜੋੜੋ ਅਤੇ ਕਮਾਂਡ ਸਫਲ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਅਗਲੇ ਹੌਪ ਨੂੰ ਉਹਨਾਂ ਦੋ ਗੁਆਂਢੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਜਕੜਨ ਵਾਲਾ ਜੰਤਰ ਹੀ ਹੈ। ਜੰਤਰ ਜੋ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਉਹ ਹੈ ਕਿ uplink0 ਇਸ ਸਾਰਣੀ ਲਈ ਸਹੀ ਲਿੰਕ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਦੂਜੇ ਹੋਸਟ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਰੂਟ ਉਸ ਹੋਸਟ ਦੇ ਇੰਟਰਫੇਸ ਨਾਮ ਨਾਲ ਲੈ ਆਉਂਦਾ ਹੈ, ਅਸਲ ਗਲਤੀਆਂ ਇੱਥੋਂ ਹੀ ਆਉਂਦੀਆਂ ਹਨ।

ਸ਼ਰਤ ਇੱਕ: ਸਾਰਣੀ ਵਿੱਚ ਇੱਕ ਲਿੰਕ ਜਾਂ ਦੋ

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

ਉਸ ਦੂਜੇ ਮਾਮਲੇ ਵਿੱਚ ਨਿਯਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸਾਰਣੀ ਕਦੋਂ ਵੇਖਣੀ ਹੈ, ਅਤੇ ਰੂਟ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਜਾਵੇਗਾ:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

ਕੋਈ ਵੀ ਵਸਤੂ ਦੂਜੀ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀ, ਅਤੇ ਸਿਰਫ਼ ਡਿਫਾਲਟ ਵਾਲੀ ਸਾਰਣੀ ਵੀ ਆਪਣਾ ਗੇਟਵੇ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਜੇ ਜੋੜ ਅਸਵੀਕਾਰ ਹੋਵੇ, ਜਾਂ ਰੂਟ ਹੋਵੇ ਪਰ ਵਰਤੋਂਯੋਗ ਨਾ ਹੋਵੇ, ਤਾਂ ਉਸ ਇੰਟਰਫੇਸ ਦਾ ਜੁੜਿਆ ਪ੍ਰਿਫਿਕਸ ਉਸੇ ਸਾਰਣੀ ਵਿੱਚ ਪਾਓ, ਜਾਂ ਹੌਪ ਨੂੰ onlink ਵਜੋਂ ਨਿਸ਼ਾਨ ਲਗਾਓ (ਜਦੋਂ ਉਹ ਪ੍ਰਿਫਿਕਸ ਕਿਤੇ ਹੋਰ ਰੂਟ ਹੁੰਦਾ ਹੈ)। ਉੱਪਰਲੇ ਬਲਾਕ ਵਿੱਚ 2001:db8:100::/48 ਕੋਈ ਮਨਮਾਨੀ ਮੰਜ਼ਿਲ ਨਹੀਂ, ਸਗੋਂ uplink1 ਉੱਤੇ ਉਹ ਜੁੜਿਆ ਪ੍ਰਿਫਿਕਸ ਦਰਸਾਉਂਦਾ ਹੈ। fwmark ਨਿਯਮ ਸਿਰਫ਼ ਉਹ ਨਿਸ਼ਾਨ ਖਪਤ ਕਰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਨੇ ਲਾਉਣਾ ਹੁੰਦਾ ਹੈ: ਫਾਰਵਰਡਿੰਗ ਰਾਹ ਉੱਤੇ nftables ਜਾਂ iptables ਨਿਯਮ ਤੋਂ, ਜਾਂ SO_MARK ਸਾਕਟ ਉੱਤੇ, ਇਸ ਲਈ ਨਿਸ਼ਾਨ ਦੇ ਸਰੋਤ ਤੋਂ ਬਿਨਾਂ ਕਾਪੀ ਕੀਤਾ ਬਲਾਕ ਕਿਸੇ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ।

ਸ਼ਰਤ ਦੋ: ਮੈਟ੍ਰਿਕ ਮਰੇ ਪ੍ਰਦਾਤਾ ਨੂੰ ਨਹੀਂ ਲੱਭਦੇ

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

ਸਾਰਣੀ ਬਣਨ ਤੋਂ ਬਾਅਦ ਚੋਣ ਪਰਖੋ, ਅਤੇ ਕਰਨਲ ਜਿਸ ਤਰੀਕੇ ਨਾਲ ਵੇਖੇਗਾ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਪਰਖੋ। ip -6 route get 2001:db8:100::1 ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਰੂਟ ਛਾਪਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਜੰਤਰ ਅਤੇ ਚੁਣਿਆ ਸਰੋਤ ਪਤਾ ਸ਼ਾਮਲ ਹੈ, ਅਤੇ ਇਹ ਨੀਤੀ ਨਿਯਮਾਂ ਦਾ ਆਦਰ ਕਰਦਾ ਹੈ। ਗਲਤ ਅਪਲਿੰਕ ਦਾ ਸਰੋਤ ਪਤਾ ਆਮ ਤੌਰ ਉੱਤੇ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੈ ਕਿ ਨਿਯਮ ਤੁਹਾਡੀ ਉਮੀਦ ਨਾਲੋਂ ਪਹਿਲਾਂ ਮਿਲਿਆ।

ਸ਼ਰਤ ਤਿੰਨ: ਤੈਅ ਕਰੋ ਕਿ ਟਿਕਾਊਪਣ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ

ਰੂਟ ip -6 route add ਨਾਲ ਜੋੜਿਆ ਰੂਟ ਰੀਬੂਟ ਤੱਕ ਜਾਂ ਕੋਈ ਇਸਨੂੰ ਸਾਫ਼ ਕਰਨ ਤੱਕ ਟਿਕਦਾ ਹੈ। ਰਾਊਟਰ ਇਸ਼ਤਿਹਾਰਾਂ ਤੋਂ ਸਿੱਖਿਆ ਡਿਫਾਲਟ ਆਯੁ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ ਅਤੇ ਰਾਊਟਰ ਇਸਨੂੰ ਵਾਪਸ ਲੈ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਹੱਥੀਂ ਜੋੜਿਆ ਡਿਫਾਲਟ ਕਦੇ ਆਪਣੇ ਆਪ ਖ਼ਤਮ ਨਹੀਂ ਹੁੰਦਾ। ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਢੰਗ ਹੈ ਜਿਸ ਨਾਲ ਪੁਰਾਣਾ ਪੱਕਾ ਰੂਟ ਨਵੇਂ ਇਸ਼ਤਿਹਾਰ ਕੀਤੇ ਰੂਟ ਉੱਤੇ ਭਾਰੂ ਹੋ ਜਾਂਦਾ ਹੈ, ਬਹੁਤ ਦੇਰ ਬਾਅਦ ਵੀ ਜਦੋਂ ਉਸ ਦੱਸਿਆ ਅਪਲਿੰਕ ਹੋਂਦ ਵਿੱਚ ਨਹੀਂ ਰਿਹਾ।

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

ਹੋਰ ਹੋਸਟਾਂ ਲਈ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲੇ ਰਾਊਟਰ ਉੱਤੇ, ਸਾਰਣੀ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ net.ipv6.conf.all.forwarding ਪਰਖੋ। ਫਾਰਵਰਡਿੰਗ ਬੰਦ ਹੋਵੇ, ਤਾਂ ਦੂਜੇ ਨੈੱਟਵਰਕ ਵੱਲ ਪਤੇ ਵਾਲੇ ਪੈਕਟ ਸਾਰਣੀ 201 ਕਿੰਨੀ ਵੀ ਸਹੀ ਹੋਵੇ, ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।

ਅਗਲੇ ਬੰਦੇ ਲਈ ਡਿਜ਼ਾਈਨ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਆਡਿਟ ਕਰ ਸਕੇ

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

ਸਾਰਣੀ ਨੂੰ ਮੁਕੰਮਲ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ, ਗੁਆਂਢੀ ਨੂੰ ip -6 neigh show dev uplink0 ਨਾਲ ਤਸਦੀਕ ਕਰੋ, ip -6 rule show ਮੁੜ ਪੜ੍ਹੋ — ਕ੍ਰਮ ਦੀਆਂ ਅਣਹੋਣੀਆਂ ਲਈ, ਅਤੇ ਡਿਫਾਲਟ ਰੂਟ ਲੈਣ ਵਾਲੇ ping ਦੀ ਥਾਂ ਨਿਯਮ ਨਾਲ ਮਿਲਦੇ ਟ੍ਰੈਫਿਕ ਨਾਲ ਜਾਂਚ ਕਰੋ। ਫਿਰ ਇੱਕ ਅਪਲਿੰਕ ਜਾਣ ਬੁੱਝ ਕੇ ਬੰਦ ਕਰੋ ਅਤੇ ਵੇਖੋ ਕਰਨਲ ਕਿਹੜੇ ਰੂਟ ਉੱਤੇ ਮੁੜਦਾ ਹੈ; ਜਵਾਬ ਤੁਹਾਡੇ ਲਿਖੇ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ।