ਰੂਟ ਰਿਫਲੈਕਟਰ ਜੋੜਨ ਤੋਂ ਬਾਅਦ ਕੁਝ L2VPN ਰੂਟ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ
ਸੈਸ਼ਨ ਚੱਲਦੇ ਰਹਿੰਦੇ ਹਨ, ਫਿਰ ਵੀ ਕੁਝ L2VPN ਰੂਟ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਦੁਬਾਰਾ ਵਰਤੇ ਗਏ ਕਲਸਟਰ ID, ਕਲਾਇੰਟ ਸੰਬੰਧ ਅਤੇ ਰਿਫਲੈਕਸ਼ਨ ਗ੍ਰਾਫ ਇਸ ਚੋਣਵੇਂ ਨੁਕਸਾਨ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ।
ਸੈਸ਼ਨ ਚੱਲਦੇ ਰਹਿੰਦੇ ਹਨ, IGP ਸਥਿਰ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਚਾਰ ਵਿੱਚੋਂ ਦੋ ਪ੍ਰੋਵਾਈਡਰ ਕਿਨਾਰਿਆਂ 'ਤੇ ਕੁਝ L2VPN ਰੂਟ ਕਦੇ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੇ। ਇਹ ਪੈਟਰਨ ਆਵਾਜਾਈ ਦੀ ਨਹੀਂ, ਰਿਫਲੈਕਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਕਿਉਂਕਿ ਟੁੱਟਿਆ ਸੈਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਦੁਬਾਰਾ ਵਰਤੀ ਗਈ ਰਿਫਲੈਕਸ਼ਨ ਸੀਮਾ ਚੋਣਵੇਂ ਤੌਰ 'ਤੇ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਭੌਤਿਕ ਰਿੰਗ ਦਾ ਇਸ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ; ਤਾਰਕਿਕ ਵੰਡ ਗ੍ਰਾਫ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਉਹ ਰੂਟ ਰੁਕੇ। ਉਸ ਬਿੰਦੂ ਨੂੰ ਲੱਭਣ ਲਈ ਕੰਟਰੋਲ ਪਲੇਨ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਨੁਕਸਾਨ ਚੋਣਵਾਂ ਹੈ, ਜੋ ਖੋਜ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ
ਭੌਤਿਕ ਰਿੰਗ 'ਤੇ ਚਾਰ ਪ੍ਰੋਵਾਈਡਰ ਕਿਨਾਰਿਆਂ ਨੂੰ ਪੂਰੀ ਜਾਲ ਲਈ ਛੇ ਤਾਰਕਿਕ ਸੈਸ਼ਨ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਹਰ ਰਾਊਟਰ ਬਾਕੀ ਤਿੰਨ ਨਾਲ ਜੋੜੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਸੈਸ਼ਨ ਰੂਟ ਕੀਤੀ ਆਵਾਜਾਈ ਉੱਤੇ ਚੱਲਦੇ ਹਨ, ਇਸ ਲਈ ਕੇਬਲਿੰਗ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕਿੰਨੇ ਨੇੜਲੇ ਸੰਬੰਧ ਹਨ ਜਾਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਰਿਫਲੈਕਟ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਦੋ ਕਿਨਾਰੇ ਇੱਕ ਖਾਸ ਪ੍ਰੀਫਿਕਸ ਸਮੂਹ ਖੁੰਝਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕੇਬਲ ਸ਼ੱਕੀ ਨਹੀਂ ਹੈ।
ਚੋਣਵਾਂ ਨੁਕਸਾਨ ਲੂਪ ਰੋਕਥਾਮ, ਨੀਤੀ ਜਾਂ ਸੰਬੰਧ ਦੀ ਦਿਸ਼ਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਕੁਝ ਰੂਟ ਸੀਮਾ ਲੰਘਦੇ ਹਨ ਅਤੇ ਹੋਰ ਰਾਹ ਵਿੱਚ ਹੀ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਪੂਰਾ ਨੁਕਸਾਨ ਸੈਸ਼ਨ ਜਾਂ ਪਤਾ ਪਰਿਵਾਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਦੋਹਾਂ ਵਿੱਚੋਂ ਤੁਸੀਂ ਕਿਹੜਾ ਵੇਖ ਰਹੇ ਹੋ, ਇਹ ਤੈਅ ਕਰਨਾ ਪਹਿਲਾ ਲਾਹੇਵੰਦ ਕਦਮ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਇੱਕ ਹੀ ਕਮਾਂਡ ਲੱਗਦੀ ਹੈ।
ਰਿਫਲੈਕਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ
ਰੂਟ ਰਿਫਲੈਕਸ਼ਨ ਇਹ ਨਿਯਮ ਢਿੱਲਾ ਕਰਦਾ ਹੈ ਕਿ iBGP ਬੁਲਾਰਾ ਕਿਸੇ ਹੋਰ iBGP ਬੁਲਾਰੇ ਤੋਂ ਸਿੱਖਿਆ ਰੂਟ ਦੁਬਾਰਾ ਐਲਾਨ ਨਹੀਂ ਕਰ ਸਕਦਾ। RFC 4456 ਇਸ ਅਪਵਾਦ ਨੂੰ ਬੁਲਾਰੇ ਅਤੇ ਰੂਟ ਦੇ ਸਰੋਤ ਵਿਚਕਾਰ ਸੰਬੰਧ ਰਾਹੀਂ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਸੰਬੰਧ ਦੀ ਦਿਸ਼ਾ ਬਹੁਤੇ ਸਾਰਾਂਸ਼ਾਂ ਦੇ ਸੰਕੇਤ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕਲਾਇੰਟ ਤੋਂ ਸਿੱਖਿਆ ਰੂਟ ਹੋਰ ਕਲਾਇੰਟਾਂ ਅਤੇ ਗੈਰ-ਕਲਾਇੰਟਾਂ ਵੱਲ ਰਿਫਲੈਕਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਗੈਰ-ਕਲਾਇੰਟ ਤੋਂ ਸਿੱਖਿਆ ਰੂਟ ਸਿਰਫ਼ ਕਲਾਇੰਟਾਂ ਵੱਲ ਹੀ ਰਿਫਲੈਕਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਅਸਮਾਨਤਾ ਦੋ ਵਾਰ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਕਲਾਇੰਟ ਸੰਬੰਧ ਜੋੜਨਾ ਡਿਜ਼ਾਈਨ ਗਲਤੀ ਨੂੰ ਕਿਵੇਂ ਲੁਕਾ ਸਕਦਾ ਹੈ: ਇਹ ਉਹ ਰਾਹ ਖੋਲ੍ਹਦਾ ਹੈ ਜੋ ਟੋਪੋਲੋਜੀ ਨੇ ਕਦੇ ਨਹੀਂ ਚਾਹਿਆ।
CLUSTER_LIST ਵਿਸ਼ੇਸ਼ਤਾ ਰਿਫਲੈਕਸ਼ਨ ਦਾ ਇਤਿਹਾਸ ਦਰਜ ਕਰਦੀ ਹੈ, ਅਤੇ ਜੋ ਰਿਫਲੈਕਟਰ ਉਸ ਸੂਚੀ ਵਿੱਚ ਆਪਣਾ ਕਲਸਟਰ ID ਲੱਭਦਾ ਹੈ, ਉਸ ਨੂੰ ਐਲਾਨ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਲੂਪ ਰੋਕਥਾਮ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਵਿਧੀ ਵੀ ਹੈ ਜੋ ਪਛਾਣਕਰਤਾ ਗਲਤੀ ਨਾਲ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਣ 'ਤੇ ਰੂਟ ਮਿਟਾ ਦਿੰਦੀ ਹੈ। ORIGINATOR_ID ਸੰਬੰਧਿਤ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦਾ ਹੈ ਅਤੇ ਉਸ ਰਾਊਟਰ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੇ ਰੂਟ ਪਹਿਲਾਂ ਐਲਾਨਿਆ ਸੀ।
ਦੁਬਾਰਾ ਵਰਤੇ ਕਲਸਟਰ ID ਹੀ ਰੂਟ ਗਾਇਬ ਹੋਣ ਦਾ ਤਰੀਕਾ ਹਨ
ਛੋਟਾ ਨੈੱਟਵਰਕ ਇੱਕ ਸ਼ਾਰਟਕੱਟ ਦਾ ਸੱਦਾ ਦਿੰਦਾ ਹੈ: ਹਰ ਰਾਊਟਰ ਨੂੰ ਉਸ ਦੇ loopback ਦੇ ਬਰਾਬਰ ਕਲਸਟਰ ID ਦਿਓ, ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਹੋਰ ਰਿਫਲੈਕਟਰ ਜੋੜੋ, ਅਤੇ ਹੱਥ ਵਿੱਚ ਸੁਵਿਧਾਜਨਕ ਹੋਣ ਕਰਕੇ ਮੌਜੂਦਾ loopback ਦੁਬਾਰਾ ਵਰਤੋ। ਜੇ ਉਹ ਪਛਾਣਕਰਤਾ ਹੁਣ ਦੋ ਸੁਤੰਤਰ ਰਿਫਲੈਕਸ਼ਨ ਪੜਾਵਾਂ ਵਿੱਚ ਦਿਖਦਾ ਹੈ, ਤਾਂ ਦੂਜਾ ਪੜਾਅ CLUSTER_LIST ਵਿੱਚ ਆਪਣਾ ID ਵੇਖ ਕੇ ਰੂਟ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਵੀ ਗਲਤੀ ਦਰਜ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਸੁੱਟਣਾ ਲੂਪ ਪ੍ਰਤੀ ਸਹੀ ਪ੍ਰਤੀਕਿਰਿਆ ਹੈ।
ਇੱਕ ਕਲਸਟਰ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਵਾਧੂ ਰਿਫਲੈਕਟਰ ਜਾਇਜ਼ ਅਪਵਾਦ ਹਨ: ਉਹ ਜਾਣਬੁੱਝ ਕੇ ਇੱਕ ID ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਹੀ ਕਲਾਇੰਟ ਸੇਵਾ ਕਰ ਸਕੇ। ਪਛਾਣਕਰਤਾ ਨੂੰ ਚੇਸਿਸ ਦੇ ਨਾਮ ਵੱਖ ਕਰਨ ਦੀ ਥਾਂ ਰਿਫਲੈਕਸ਼ਨ ਡਿਜ਼ਾਈਨ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਸੰਰਚਨਾ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜੀਂਦਾ ਗ੍ਰਾਫ ਖਿੱਚੋ: ਪ੍ਰੀਫਿਕਸ ਕੌਣ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਹੜਾ ਕਲਾਇੰਟ ਸੰਬੰਧ ਪਹਿਲੇ ਰਿਫਲੈਕਸ਼ਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਕਿਹੜਾ ਰਿਫਲੈਕਟਰ ਉਸ ਨੂੰ ਅਗਲੇ ਪੜਾਅ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਆਖਰੀ ਕਲਾਇੰਟ ਕਿੱਥੇ ਬੈਠਦਾ ਹੈ। ਉਸ ਗ੍ਰਾਫ ਦੀ ਹਰ ਛਲਾਂਗ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਦੁਬਾਰਾ ਵਰਤਿਆ ਪਛਾਣਕਰਤਾ, ਗੁੰਮ ਕਲਾਇੰਟ ਸੰਬੰਧ ਜਾਂ ਨੀਤੀ ਫਿਲਟਰ ਰੂਟ ਰੋਕ ਸਕਦਾ ਹੈ। ਗ੍ਰਾਫ ਖਿੱਚਣ ਤੋਂ ਬਾਅਦ ਗੁੰਮ ਰੂਟ ਕੋਲ ਬੁਝਾਰਤ ਦੀ ਥਾਂ ਥਾਂ ਹੁੰਦੀ ਹੈ।
ਹਰ ਗੁਆਂਢੀ ਨੂੰ ਕਲਾਇੰਟ ਬਣਾਉਣ ਦੇ ਲਾਲਚ ਦਾ ਵਿਰੋਧ ਕਰੋ
ਗੁੰਮ ਰੂਟ ਦਾ ਤੇਜ਼ ਇਲਾਜ ਇਹ ਹੈ ਕਿ ਹਰ ਗੁਆਂਢੀ ਨੂੰ ਹਰ ਰਿਫਲੈਕਟਰ ਦਾ ਕਲਾਇੰਟ ਬਣਾਇਆ ਜਾਵੇ। ਪ੍ਰਸਾਰ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਤੁਹਾਨੂੰ ਕੁਝ ਵੀ ਦੱਸਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ: ਇਹ ਹਰ ਬੁਲਾਰੇ ਵੱਲੋਂ ਚੁੱਕੇ ਰੂਟ ਕਈ ਗੁਣਾ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਸੰਬੰਧ ਉਹ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸੀ।
ਛੋਟੇ ਨੈੱਟਵਰਕ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਆਕਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚਾਹੀਦਾ ਹੈ। ਪੂਰੀ iBGP ਜਾਲ ਚਾਰ ਰਾਊਟਰਾਂ ਲਈ ਛੇ ਸੈਸ਼ਨ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕੋਈ ਰਿਫਲੈਕਸ਼ਨ ਨਹੀਂ, ਅਤੇ ਬਾਕੀ ਕਿਨਾਰਿਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੀ ਨਿਯਤ ਰਿਫਲੈਕਟਰ ਜੋੜੀ ਦੂਜਾ ਆਕਾਰ ਹੈ। ਹਰ ਰਾਊਟਰ ਥੋੜ੍ਹਾ-ਥੋੜ੍ਹਾ ਰਿਫਲੈਕਟ ਕਰਨ ਵਾਲੀ ਅੰਸ਼ਿਕ ਜਾਲ ਨਾਲੋਂ ਦੋਵਾਂ ਬਾਰੇ ਸੋਚਣਾ ਸੌਖਾ ਹੈ। ਆਕਾਰ ਕੇਬਲਿੰਗ ਚਿੱਤਰ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਪੈਮਾਨੇ ਅਤੇ ਫੇਲ੍ਹਤਾ ਵਿਵਹਾਰ ਨਾਲ ਚੁਣੋ।
ਰਿਫਲੈਕਸ਼ਨ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਪਰਿਵਾਰ ਜਾਂਚੋ
ਪੋਰਟ 179 'ਤੇ TCP ਸੈਸ਼ਨ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਬੁਲਾਰੇ ਬੋਲ ਸਕਦੇ ਹਨ, ਅਤੇ VPN ਪਤਾ ਪਰਿਵਾਰ ਨੇ ਇੱਕ ਵੀ ਰੂਟ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂ ਨਹੀਂ, ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਪਹਿਲਾਂ ਸੈਸ਼ਨ ਸਥਿਤੀ, ਫਿਰ ਪਰਿਵਾਰ, ਫਿਰ ਵੱਖਰਾ ਪ੍ਰੀਫਿਕਸ ਸਥਾਪਿਤ ਕਰੋ।
vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"
ਉਹ ਤਿੰਨ ਆਉਟਪੁੱਟ ਗੁਆਂਢੀ ਸਮੱਸਿਆ, ਆਦਾਨ-ਪ੍ਰਦਾਨ ਸਮੱਸਿਆ ਅਤੇ ਗੁੰਮ ਪ੍ਰੀਫਿਕਸ ਸਮੱਸਿਆ ਨੂੰ ਵੱਖ ਕਰਦੇ ਹਨ। ਜੇ ਪਰਿਵਾਰ ਬਿਲਕੁਲ ਵੀ ਪ੍ਰੀਫਿਕਸ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਤਾਂ ਰਿਫਲੈਕਸ਼ਨ ਵੱਲ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਗੁਆਂਢੀ ਦੀ ਸਰਗਰਮੀ ਸਥਿਤੀ ਅਤੇ ਨਿਰਯਾਤ ਨੀਤੀ ਜਾਂਚੋ। ਜੇ ਪ੍ਰੀਫਿਕਸ ਇੱਕ ਕਿਨਾਰੇ 'ਤੇ ਦਿਖਦੇ ਹਨ ਪਰ ਦੂਜੇ 'ਤੇ ਨਹੀਂ, ਤਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਪਾਸੇ ਕਲਸਟਰ ਸੂਚੀ ਅਤੇ ਮੂਲ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਪਿਛਲੇ ਭਾਗ ਦਾ ਗ੍ਰਾਫ ਚੱਲੋ।
ਅਗਲੀ ਛਲਾਂਗ ਦੀ ਪਹੁੰਚ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਸਥਿਤੀ ਨੂੰ ਉਸ ਜਾਂਚ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਨਾ ਪਹੁੰਚਣ ਵਾਲੀ ਅਗਲੀ ਛਲਾਂਗ ਵਾਲਾ ਰਿਫਲੈਕਟ ਕੀਤਾ ਰੂਟ ਮੌਜੂਦ ਹੈ ਪਰ ਬੇਕਾਰ ਹੈ, ਜੋ ਅਗਲੀ ਛਲਾਂਗ ਦਾ ਕਾਲਮ ਵੇਖਣ ਤੱਕ ਰਿਫਲੈਕਸ਼ਨ ਫੇਲ੍ਹਤਾ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਅਗਲੀ ਛਲਾਂਗ ਹੱਲ ਕਰੋ, ਫਾਰਵਰਡਿੰਗ ਐਂਟਰੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੈਅ ਕਰੋ ਕਿ ਵੰਡ ਗ੍ਰਾਫ ਨੂੰ ਇੱਕ ਹੋਰ ਰਿਫਲੈਕਟਰ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।