EIGRP ਗੁਆਂਢੀ ਜਾਂ DMVPN ਟਰਾਂਜ਼ਿਟ? ਪਹਿਲਾਂ ਭੂਮਿਕਾ ਜਾਂਚੋ

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

ਕਦਮ 1: ਦੋ ਭੂਮਿਕਾਵਾਂ ਬਣਾਓ

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

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

ਕਦਮ 2: ਵਿਚਕਾਰਲਾ ਡਿਵਾਈਸ ਕੀ ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਜਾਂਚੋ

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

ਇਸ ਲਈ ਪਹਿਲਾ ਅਸਲ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਟੋਕਾਲ ਟਿਊਨ ਕਰਨਾ ਹੈ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਉਹ ਡੱਬਾ hub ਹੈ, spoke ਹੈ, ਸਿਰਫ਼ underlay ਹਾਪ ਹੈ, ਜਾਂ ਅਜਿਹੀ Layer 2 ਸੇਵਾ ਹੈ ਜੋ ਸਿਰਿਆਂ ਵਿਚਕਾਰ ਫਰੇਮ ਲੈ ਜਾਂਦੀ ਹੈ।

ਕਦਮ 3: ਗੁਆਂਢੀ ਦਾ ਨਿਯੰਤਰਣ ਤਲ ਜਾਂਚੋ

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

RFC 7868 EIGRP ਨੂੰ ਮਲਟੀਕਾਸਟ ਨਿਯੰਤਰਣ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਵਾਲਾ IP ਪ੍ਰੋਟੋਕਾਲ ਦੱਸਦਾ ਹੈ, ਇਸ ਲਈ ਗੁਆਂਢੀ ਸੰਬੰਧ ਅਜਿਹੀ ਚੀਜ਼ ਨਹੀਂ ਜਿਸ ਨੂੰ ਵਿਚਕਾਰਲਾ ਰਾਊਟਰ ਪੈਕਟ ਨੂੰ ਮੰਜ਼ਿਲ ਵੱਲ ਰਾਊਟ ਕਰਕੇ ਬਦਲ ਸਕੇ। ਜਾਂ ਤਾਂ ਨਿਯੰਤਰਣ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਸਾਥੀ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਜਾਂ ਗੁਆਂਢ ਬਣਦਾ ਹੀ ਨਹੀਂ।

ਕਦਮ 4: ਆਵਾਜਾਈ ਨਿਯੰਤਰਣ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ ਜਾਂਚੋ

ਅੱਗੇ, ਜਾਂਚੋ ਕਿ overlay ਇੱਛਤ ਸਿਰਿਆਂ ਵਿਚਕਾਰ ਨਿਯੰਤਰਣ ਟ੍ਰੈਫ਼ਿਕ ਸੱਚਮੁੱਚ ਲੈ ਜਾਂਦਾ ਹੈ। ਸਾਥੀ ਦੀ NHRP ਮੈਪਿੰਗ ਅਤੇ ਉੱਥੇ ਪਹੁੰਚਣ ਵਾਲਾ ਬਾਹਰੀ ਰਸਤਾ ਵੇਖੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟਨਲ ਇੰਟਰਫੇਸ ਉੱਪਰ ਹੈ ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਲੰਘਾ ਰਿਹਾ ਹੈ। ਸਫਲ underlay ping ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬਾਹਰੀ ਰਸਤਾ ਮੌਜੂਦ ਹੈ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ overlay ਨਿਯੰਤਰਣ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਪਹੁੰਚਾਇਆ ਗਿਆ।

ਪਾਰਦਰਸ਼ੀ Layer 2 ਸੇਵਾ, ਬਿੰਦੂ-ਤੋਂ-ਬਿੰਦੂ ਟਨਲ ਅਤੇ ਬਹੁ-ਬਿੰਦੂ DMVPN ਕਲਾਊਡ ਮਲਟੀਕਾਸਟ ਵੱਖ-ਵੱਖ ਢੰਗਾਂ ਨਾਲ ਪਹੁੰਚਾਉਂਦੇ ਹਨ। ਤਿੰਨੇ ਇੱਕੋ ਜਿਹਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ ਅਜਿਹਾ ਮੰਨਣ ਦੀ ਥਾਂ ਜੋ ਸੱਚਮੁੱਚ ਤੈਨਾਤ ਹੈ ਉਸ ਲਈ ਸਮਰਥਿਤ ਇੰਟਰਫੇਸ, NHRP ਅਤੇ ਮਲਟੀਕਾਸਟ ਮਾਡਲ ਦੀ ਪਾਲਣਾ ਕਰੋ।

ਕਦਮ 5: ਹਿੱਸਾ ਨਾ ਲੈ ਸਕੇ ਤਾਂ ਸੀਮਾ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਕਰੋ

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

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

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