VPN ਰਾਹੀਂ PIM-SM: BSR, RP ਮੈਪਿੰਗ ਅਤੇ RPF ਪਥ ਜਾਂਚੋ

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

ਟਨਲ ਤੋਂ ਨਹੀਂ, ਰਿਸੀਵਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਜਿਸ ਰਿਸੀਵਰ ਨੇ ਕਦੇ ਸਮੂਹ ਦੀ ਬੇਨਤੀ ਨਹੀਂ ਕੀਤੀ, ਉਹ ਕਿਸੇ ਵੀ ਰਾਊਟਰ 'ਤੇ ਕੋਈ ਸਥਿਤੀ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਇਸ ਲਈ ਹੋਰ ਕੁਝ ਵੀ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਿਸੀਵਰ ਵਾਲੇ ਹਿੱਸੇ ਵਿੱਚ ਜੁਆਇਨ ਮੌਜੂਦ ਹੈ। Cisco ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ, ਆਖਰੀ ਹੌਪ ਦੇ ਰਾਊਟਰ 'ਤੇ show ip igmp groups ਜੁੜੇ ਸਮੂਹਾਂ ਨੂੰ ਉਸ ਇੰਟਰਫੇਸ ਦੇ ਕੋਲ ਛਾਪਦਾ ਹੈ ਜਿਸਨੇ ਉਹਨਾਂ ਨੂੰ ਸੁਣਿਆ। ਜਦੋਂ ਉਸ ਆਉਟਪੁੱਟ ਵਿੱਚ ਸਮੂਹ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਟਨਲ ਧਿਆਨ ਭਟਕਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਹੈ: ਬੇਨਤੀ ਐਕਸੈਸ ਸਵਿੱਚ 'ਤੇ, ਹੋਸਟ ਸਾਕਟ 'ਤੇ ਜਾਂ querier ਤੋਂ ਬਿਨਾਂ VLAN ਵਿੱਚ ਮਰ ਗਈ।

ਮੈਂ ਵੇਖੇ ਬਹੁਤੇ ਗੁੰਮ ਜੁਆਇਨਾਂ ਦੇ ਦੋ ਆਮ ਕਾਰਨ ਹਨ: ਹੋਸਟ ਅਤੇ ਰਾਊਟਰ ਵਿਚਕਾਰ IGMP ਸੰਸਕਰਣ ਦਾ ਅੰਤਰ, ਅਤੇ ਅਜਿਹੇ ਸਵਿੱਚ 'ਤੇ ਪਈ querier ਚੋਣ ਜੋ ਰੂਟਿੰਗ ਨਹੀਂ ਕਰਦਾ। ਤੀਜਾ ਵਧੇਰੇ ਬਾਰੀਕ ਹੈ: ਸਮੂਹ ਵਿੱਚ ਜੁਆਇਨ ਹੈ ਪਰ ਗਲਤ VLAN ਵਿੱਚ, ਕਿਉਂਕਿ ਹੋਸਟ ਵਿੱਚ ਦੋ ਨੈੱਟਵਰਕ ਕਾਰਡ ਹਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਗਲਤ ਕਾਰਡ ਨਾਲ ਬੰਨ੍ਹਿਆ ਗਿਆ। IPv6 ਰਿਸੀਵਰਾਂ ਨੂੰ MLD ਨਾਲ ਉਹੀ ਸਮੱਸਿਆ ਹੈ, ਜਿੱਥੇ show ipv6 mld groups ਉਸੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਟਨਲ ਨੂੰ ਛੂਹ ਕੇ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਸੇ ਲਈ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ।

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

ਕੀ BSR ਸੈੱਟ ਦੂਜੇ ਪਾਸੇ ਪਹੁੰਚਦਾ ਹੈ?

Bootstrap Router ਸੁਨੇਹੇ ਇੱਕ PIM ਡੋਮੇਨ ਦੇ ਅੰਦਰ ਹੌਪ-ਦਰ-ਹੌਪ ਚਲਦੇ ਹਨ, ਅਤੇ ਟਨਲ ਰਾਹੀਂ ਟੁੱਟਣ ਵਾਲੀ ਦਿਸ਼ਾ ਉਹੀ ਹੈ। ਉਮੀਦਵਾਰ RP ਆਪਣੀਆਂ ਘੋਸ਼ਣਾਵਾਂ ਚੁਣੇ ਗਏ BSR ਨੂੰ ਯੂਨੀਕਾਸਟ ਰਾਹੀਂ ਭੇਜਦੇ ਹਨ, ਇਸ ਲਈ RP ਤੋਂ BSR ਤੱਕ ਦਾ ਹਿੱਸਾ ਕੰਮ ਕਰਦੇ ਟਨਲ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਬਿਨਾਂ ਬਦਲਾਅ ਰਹਿੰਦਾ ਹੈ। ਦੂਜੀ ਦਿਸ਼ਾ ਵਿੱਚ Bootstrap ਸੁਨੇਹਿਆਂ ਦਾ ਹੜ੍ਹ ਹਰ ਵਿਚਕਾਰਲੇ ਇੰਟਰਫੇਸ 'ਤੇ PIM ਸਮਰੱਥ ਹੋਣ ਅਤੇ ਕਿਸੇ ਸੀਮਾ 'ਤੇ ਸੁਨੇਹੇ ਰੋਕਣ ਵਾਲਾ ਕੁਝ ਨਾ ਹੋਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। RFC 5059 ਉਸ ਵੰਡ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕੀ ਘੇਰੇ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸਨੂੰ ਛੋਟਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ।

ip pim bsr-border ਕਥਨ, ਪ੍ਰੋਟੋਕਾਲ 103 ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਵਾਲਾ ACL, ਜਾਂ ਨੀਤੀ-ਆਧਾਰਿਤ IPsec ਟਨਲ ਜੋ ਮਲਟੀਕਾਸਟ ਨਹੀਂ ਲੈ ਜਾ ਸਕਦਾ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਹੜ੍ਹ ਨੂੰ ਕੱਟ ਦੇਵੇਗਾ ਜਦਕਿ ਯੂਨੀਕਾਸਟ ਅਟੁੱਟ ਰਹੇਗਾ। ਇਹੀ ਸੁਮੇਲ ਫੇਲ੍ਹਤ ਨੂੰ RP ਸਮੱਸਿਆ ਵਰਗੀ ਦਿਖਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਅਸਲ ਵਿੱਚ ਇਹ ਪਹੁੰਚ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਮੈਂ RP ਸੰਰਚਨਾ ਤੋਂ ਪਹਿਲਾਂ BSR ਸਥਿਤੀ ਪੜ੍ਹਦਾ ਹਾਂ।

ਦੂਰ ਵਾਲੇ ਪਾਸੇ ਦੇ ਰਾਊਟਰ 'ਤੇ show ip pim bsr-router ਚੁਣੇ ਗਏ BSR ਅਤੇ ਸਿੱਖੇ ਗਏ RP ਸੈੱਟ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ; ਜੇ ਆਉਟਪੁੱਟ ਖਾਲੀ ਹੈ, ਤਾਂ ਦੂਰ ਵਾਲਾ ਪਾਸਾ ਆਪਣੇ ਡੋਮੇਨ ਵਿੱਚ ਬੈਠਾ ਹੈ ਅਤੇ ਕੋਈ ਵੀ RP ਸੰਰਚਨਾ ਦੋਵਾਂ ਨੂੰ ਨਹੀਂ ਮਿਲਾ ਸਕੇਗੀ। ਟਨਲ ਦੇ ਦੋਵੇਂ ਪਾਸਿਆਂ 'ਤੇ show ip pim rp mapping ਵਿੱਚ ਸਮੂਹ ਸੀਮਾਵਾਂ ਅਤੇ RP ਪਤਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਸਿਰਫ਼ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਮੈਪਿੰਗ ਗਲਤ ਥਾਂ 'ਤੇ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਸਾਂਝਾ ਰੁੱਖ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਰਿਸੀਵਰ ਸਦਾ ਲਈ ਉਡੀਕਦਾ ਹੈ।

ਟਨਲ ਦੇ ਦੋਵੇਂ ਪਾਸਿਆਂ 'ਤੇ RP ਮੈਪਿੰਗ ਮਿਲਾਓ

ਸਥਿਰ RP, BSR ਅਤੇ anycast-RP ਇੱਕੋ ਸਵਾਲ ਦੇ ਤਿੰਨ ਜਵਾਬ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਮਿਲਾਉਣਾ ਕਦੇ ਵੀ ਇਕੱਠਾ ਨਾ ਹੋਣ ਵਾਲਾ ਡੋਮੇਨ ਬਣਾਉਣ ਦਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੈ। ਜੇ ਹੈੱਡ ਐਂਡ BSR ਵਰਤਦਾ ਹੈ ਅਤੇ ਸ਼ਾਖਾ ਕਿਸੇ ਹੋਰ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਥਿਰ ip pim rp-address ਵਰਤਦੀ ਹੈ, ਤਾਂ ਸ਼ਾਖਾ ਆਪਣਾ ਸਾਂਝਾ ਰੁੱਖ ਅਜਿਹੇ RP ਵੱਲ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸਨੂੰ ਰਿਸੀਵਰ ਹੋਣ ਦਾ ਪਤਾ ਨਹੀਂ। ਮੈਪਿੰਗ ਨੂੰ ਸਮੂਹ ਸੀਮਾ ਅਤੇ ਪਤਾ ਦੋਵਾਂ 'ਤੇ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਵਧੇਰੇ ਖਾਸ ਸੀਮਾ ਚੌੜੀ ਨੂੰ ਹਰਾਉਂਦੀ ਹੈ।

Anycast-RP ਇਸ ਲਈ ਹੈ ਕਿ ਦੋ ਸਾਈਟਾਂ ਇੱਕ RP ਪਤਾ ਸਾਂਝਾ ਕਰ ਸਕਣ, ਅਤੇ ਇੱਥੇ ਇਸਦਾ ਨਾਮ ਲੈਣਾ ਬਣਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ «ਉਹੀ RP» ਦੇ ਅਰਥ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਇੱਕ ਪਤਾ ਘੋਸ਼ਿਤ ਕਰਨ ਵਾਲੇ ਦੋ RP ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਇਕਸਾਰ ਹਨ; ਇੱਕੋ ਸੀਮਾ ਲਈ ਵੱਖਰੇ ਪਤੇ ਘੋਸ਼ਿਤ ਕਰਨ ਵਾਲੇ ਦੋ RP ਨਹੀਂ ਹਨ, ਭਾਵੇਂ ਹਰ ਸਾਈਟ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਿੰਨੀ ਵੀ ਸਿਹਤਮੰਦ ਲੱਗੇ।

232.0.0.0/8 ਦੇ ਅੰਦਰ ਸਰੋਤ-ਖਾਸ ਮਲਟੀਕਾਸਟ ਲਈ RP ਨੂੰ ਕਦੇ ਨਹੀਂ ਪੁੱਛਿਆ ਜਾਂਦਾ, ਇਸ ਲਈ ਖਾਲੀ RP ਮੈਪਿੰਗ ਆਪਣੇ ਆਪ ਖਰਾਬੀ ਨਹੀਂ ਹੈ। ਉਸ RP ਦਾ ਪਿੱਛਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਕਦੇ ਲੋੜੀਂਦਾ ਨਹੀਂ ਸੀ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਿਹੜਾ ਸੇਵਾ ਮਾਡਲ ਵਰਤਦੀ ਹੈ।

ਸਰੋਤ ਵੱਲ RPF ਖੋਜ ਪੜ੍ਹੋ

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

show ip rpf 192.0.2.10 ਚੁਣਿਆ ਗਿਆ ਇੰਟਰਫੇਸ, ਅਗਲਾ ਹੌਪ ਅਤੇ ਫੈਸਲਾ ਪੈਦਾ ਕਰਨ ਵਾਲਾ ਮਾਰਗ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਬੇਮੇਲਤਾ ਵੇਖਣ ਲਈ ਇਹ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ip mroute 192.0.2.0 255.255.255.0 tunnel0 ਵਰਗਾ ਸਥਿਰ ਮਲਟੀਕਾਸਟ ਮਾਰਗ ਉਸ ਪ੍ਰੀਫਿਕਸ ਲਈ ਯੂਨੀਕਾਸਟ ਖੋਜ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਮਲਟੀਕਾਸਟ ਟੋਪੋਲੋਜੀ ਸੱਚਮੁੱਚ ਯੂਨੀਕਾਸਟ ਟੋਪੋਲੋਜੀ ਤੋਂ ਵੱਖਰੀ ਹੋਵੇ ਤਾਂ ਇਹ ਜਾਇਜ਼ ਸੁਧਾਰ ਹੈ। ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕਰਨ ਯੋਗ ਸੰਰਚਨਾ ਮੰਨੋ, ਘਟਨਾ ਵੇਲੇ ਲਗਾ ਕੇ ਭੁੱਲ ਜਾਣ ਵਾਲੇ ਪੈਚ ਵਜੋਂ ਨਹੀਂ।

ਪਿੰਗ ਨਾਲ ਨਹੀਂ, ਕਮਾਂਡਾਂ ਨਾਲ ਜੁਆਇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

ਅਸਲ ਇਨਕਮਿੰਗ ਇੰਟਰਫੇਸ ਅਤੇ ਖਾਲੀ ਨਾ ਹੋਣ ਵਾਲੀ ਆਉਟਗੋਇੰਗ ਸੂਚੀ ਵਾਲੀ ਭਰੀ ਹੋਈ (S,G) ਐਂਟਰੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੰਟਰੋਲ ਤਲ ਨੇ ਆਪਣਾ ਕੰਮ ਪੂਰਾ ਕੀਤਾ ਹੈ। ਜਿਸ ਐਂਟਰੀ ਦਾ ਇਨਕਮਿੰਗ ਇੰਟਰਫੇਸ Null ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਜਾਂ RPF failed ਲੇਬਲ ਵਾਲਾ ਕਾਊਂਟਰ ਜੋ ਲਗਾਤਾਰ ਵਧ ਰਿਹਾ ਹੈ, ਉਹ ਟਨਲ ਵੱਲ ਨਹੀਂ ਸਗੋਂ ਪਿਛਲੇ ਭਾਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਜੇ ਪੰਜੇ ਕਮਾਂਡਾਂ ਸਹੀ ਲੱਗਦੀਆਂ ਹਨ ਅਤੇ ਰਿਸੀਵਰ ਫਿਰ ਵੀ ਕੁਝ ਨਹੀਂ ਵੇਖਦਾ, ਤਾਂ ਬਚੀ ਸ਼ੱਕੀ ਚੀਜ਼ ਟਨਲ ਦੀ ਆਪਣੀ ਨੀਤੀ ਹੈ: ਅਜਿਹਾ ਕ੍ਰਿਪਟੋ ACL ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜੋ ਯੂਨੀਕਾਸਟ ਰੂਟਿੰਗ ਪ੍ਰੋਟੋਕਾਲ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਪਰ PIM, IGMP ਜਾਂ ਸਮੂਹ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨਹੀਂ। ਨੀਤੀ-ਆਧਾਰਿਤ IPsec ਟਨਲ 'ਤੇ ਮਲਟੀਕਾਸਟ ਬਿਲਕੁਲ ਨਹੀਂ ਢੋਇਆ ਜਾਂਦਾ, ਇਸ ਲਈ ਜਵਾਬ GRE ਜਾਂ VTI ਡਿਜ਼ਾਈਨ ਹੈ, ਹੋਰ ਫਿਲਟਰ ਛੋਟ ਨਹੀਂ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਪੰਜ ਜਾਂਚਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਫੇਲ ਹੋਈ, ਫਿਰ ਸਿਰਫ਼ ਉਹੀ ਪਰਤ ਬਦਲੋ।