BGP ਸੈਸ਼ਨ ਚਾਲੂ, ਗਾਹਕ ਦਾ ਰਾਹ ਟੁੱਟਿਆ: DMVPN ਉੱਤੇ MPLS

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

ਇਹ ਖੱਡ MPLS-over-DMVPN ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਸਭ ਤੋਂ ਸੌਖਿਆਂ ਦਿਸਦੀ ਹੈ, ਜਿੱਥੇ ਹੱਬ ਰਾਹ ਅਤੇ ਸਿੱਧਾ ਸਪੋਕ ਰਾਹ ਪੀਅਰਿੰਗ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਾ ਰੱਖਣ ਵਾਲੇ ਕਾਰਨਾਂ ਕਰਕੇ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰ ਸਕਦੇ ਹਨ।

ਸੈਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ

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

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

ਚਾਰ ਕਾਰਜ-ਵਿਧੀਆਂ, ਇੱਕ ਨਹੀਂ

MPLS-over-DMVPN ਬਾਰੇ Cisco ਦੇ ਦਸਤਾਵੇਜ਼ ਹਿੱਸਿਆਂ ਨੂੰ ਸਪਸ਼ਟ ਵੱਖ ਕਰਦੇ ਹਨ। MP-BGP ਪ੍ਰਦਾਤਾ ਦੇ ਕੰਢੇ ਦੇ ਯੰਤਰਾਂ ਵਿਚਕਾਰ ਗਾਹਕ ਦੇ ਓਵਰਲੇ ਲੇਬਲ ਵੰਡਦਾ ਹੈ। MPLS ਉਹ ਲੇਬਲ ਪੈਕਟ ਦਾ ਫ਼ਾਰਵਰਡਿੰਗ ਸੰਦਰਭ ਚੁਣਨ ਲਈ ਵਰਤਦਾ ਹੈ। NHRP ਓਵਰਲੇ ਪਤੇ ਨੂੰ ਡਾਇਨੈਮਿਕ ਟਨਲ ਨੂੰ ਲੋੜੀਂਦੇ ਟਰਾਂਸਪੋਰਟ ਸਿਰੇ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ। IPsec ਜਿੱਥੇ ਲਾਗੂ ਹੋਵੇ ਉੱਥੇ ਪੀਅਰ ਰਾਹ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।

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

ਹੱਬ ਰਾਹ ਦੀ ਤੁਲਨਾ ਸ਼ਾਰਟਕਟ ਨਾਲ ਕਰੋ, ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਚਲ

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

ਤੁਲਨਾ ਦੌਰਾਨ ਵਹਾਅ ਸਥਿਰ ਰੱਖੋ। ਨਿਰੀਖਣਾਂ ਵਿਚਕਾਰ ਸਰੋਤ ਹੋਸਟ, VRF ਜਾਂ ਟਾਰਗਿਟ ਬਦਲਣ ਨਾਲ ਦੋ ਅਸੰਬੰਧਿਤ ਕਹਾਣੀਆਂ ਬਣਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਅਭਿਆਸ ਵਿਗੜਨ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ।

loopback ਜਾਂਚਾਂ ਨੂੰ ਆਪਣੇ ਵੱਖਰੇ ਡੱਬੇ ਵਿੱਚ ਰੱਖੋ

ਰਾਊਟਰ ਦੇ loopback ਤੋਂ ਭੇਜਿਆ ping ਲਾਹੇਵੰਦ ਜਾਂਚ ਹੈ, ਅਤੇ ਇਹ ਹੋਸਟ ਦੇ ਵਹਾਅ ਤੋਂ ਵੱਖਰੀ ਹਾਲਤ ਪਰਖਦਾ ਹੈ। ਸਰੋਤ ਪਤਾ ਰਾਊਟਰ ਦਾ ਹੈ, ਇਸ ਦਾ ਰਾਊਟਿੰਗ ਸੰਦਰਭ VRF ਦੀ ਥਾਂ ਸੰਸਾਰਕ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਦਾ ਰਾਹ ਗਾਹਕ ਪ੍ਰੀਫ਼ਿਕਸ ਦੇ ਰਾਹ ਤੋਂ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ loopback ਦਾ ਜਵਾਬ ਦੇਣਾ ਅਤੇ ਇਸ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸ਼ਾਰਟਕਟ ਰਾਹੀਂ ਚੱਲਣਾ ਵੱਖਰੇ ਨਤੀਜੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਦੂਜਾ ਹੀ ਗਾਹਕ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

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

ਸੰਸਕਰਣ ਅਤੇ ਖ਼ਰਾਬੀ ਦੇ ਦਾਅਵਿਆਂ ਨੂੰ ਆਪਣੇ ਸਬੂਤ ਚਾਹੀਦੇ ਹਨ

ਖੇਤਰੀ ਰਿਪੋਰਟਾਂ ਕਦੇ-ਕਦੇ ਹੋਸਟ ਮਾਸਕ ਜਾਂ BGP ਸਰੋਤ ਪਤਾ ਬਦਲਣ ਦੀ ਸਲਾਹ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਅਜਿਹੀਆਂ ਰਿਪੋਰਟਾਂ ਸਿਰਫ਼ ਉਸ ਖ਼ਰਾਬੀ ਅਤੇ ਉਹਨਾਂ ਰਿਲੀਜ਼ਾਂ ਨਾਲ ਪੜ੍ਹਨ ਯੋਗ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਉਹ ਲਿਖੀਆਂ ਗਈਆਂ। ਇੱਕ ਰਿਲੀਜ਼ ਦਾ ਹੱਲ ਇਹ ਬਿਆਨ ਨਹੀਂ ਕਿ ਆਰਕੀਟੈਕਚਰ ਹਰ /32 ਪ੍ਰੀਫ਼ਿਕਸ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ।

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