ਤੁਹਾਡਾ L2VPN ਹੁਣੇ ਬਣਾਏ RSVP-TE LSP ਨੂੰ ਕਿਉਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ

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

ਇੱਕ ਲੇਬਲ ਸੇਵਾ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਦੂਜਾ ਪੈਕੇਟ ਹਿਲਾਉਂਦਾ ਹੈ

pseudowire ਲੇਬਲ, ਜੋ ਟਾਰਗਿਟ LDP ਦੁਆਰਾ ਸਿਗਨਲ ਹੁੰਦਾ ਹੈ ਅਤੇ RFC 4447 ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਪ੍ਰਦਾਤਾ ਕਿਨਾਰੇ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਅਟੈਚਮੈਂਟ ਸਰਕਟ ਫਰੇਮ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਰੇਮ ਉੱਥੇ ਕਿਵੇਂ ਪਹੁੰਚਿਆ, ਇਸ ਬਾਰੇ ਇਹ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਇਸਦੇ ਹੇਠਾਂ ਦਾ ਲੇਬਲ ਟ੍ਰਾਂਸਪੋਰਟ ਦਾ ਹੈ, ਅਤੇ ਉਹ ਸਟੈਕ ਪੀਅਰ ਲੂਪਬੈਕ ਲਈ ਪਹੁੰਚ ਦਾ ਐਲਾਨ ਕਰਨ ਵਾਲੇ ਨੇ ਬਣਾਇਆ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ LDP ਹੋਵੇ, RSVP-TE ਹੋਵੇ ਜਾਂ ਸੈਗਮੈਂਟ-ਰੂਟਿਡ ਰਾਹ। ਦੋ ਪਰਤਾਂ ਨੂੰ ਵੱਖਰੇ ਪ੍ਰੋਟੋਕਾਲ ਸਿਗਨਲ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦੀ ਹੈ ਜਦਕਿ ਦੂਜੀ ਪੁਰਾਣੀ ਹੋਵੇ। ਇਹੀ ਵੰਡ ਪੂਰੀ ਉਲਝਣ ਦਾ ਸਰੋਤ ਹੈ।

ਸਿੱਧਾ ਕਹਿਣਾ ਢੁਕਵਾਂ ਹੈ: pseudowire LSP ਨਹੀਂ ਚੁਣਦਾ। ਇਹ ਫਰੇਮ ਟ੍ਰਾਂਸਪੋਰਟ ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਅਤੇ ਟ੍ਰਾਂਸਪੋਰਟ ਆਪਣੇ ਦਿੱਤੇ ਗਏ ਮੰਜ਼ਿਲ ਪਤੇ ਤੋਂ ਫੈਸਲਾ ਕਰਦਾ ਹੈ।

ਨਵੇਂ LSP ਉੱਤੇ ਸਾਫ਼ ping ਇੰਨਾ ਘੱਟ ਕਿਉਂ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਇਸਦਾ ਕਾਰਨ ਵੀ ਇਹੀ ਹੈ। LSP ਚਾਲੂ, ਲੇਬਲ ਵਾਲਾ ਅਤੇ ਹੋਰ ਸੇਵਾਵਾਂ ਢੋਂਦਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਤੁਹਾਡਾ pseudowire ਹਾਲੇ ਵੀ ਕਿਸੇ ਹੋਰ ਅਗਲੇ ਹੌਪ ਰਾਹੀਂ ਹੱਲ ਹੁੰਦਾ ਹੈ। ਜਦ ਤੱਕ ਤੁਸੀਂ ਬਾਈਂਡਿੰਗ ਨਹੀਂ ਪੜ੍ਹਦੇ, ਉਹ ਦੋ ਤੱਥ ਸੰਬੰਧਿਤ ਨਹੀਂ।

ਵਿਕਲਪ A: pseudowire ਨੂੰ ਚੁਣੇ ਟ੍ਰਾਂਸਪੋਰਟ ਉੱਤੇ ਪਿੰਨ ਕਰੋ

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

ਕੀਮਤ ਦਾਇਰਾ ਹੈ। ਪੀਅਰ ਪਤੇ ਉੱਤੇ ਮਿਲਣ ਵਾਲੀ ਨੀਤੀ ਉਸ ਪੀਅਰ ਵੱਲ ਸੰਕੇਤ ਕਰਨ ਵਾਲੀ ਹਰ ਸੇਵਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਸਿਰਫ ਤੁਹਾਡੇ ਮਨ ਵਿੱਚਲੇ pseudowire ਨੂੰ ਨਹੀਂ।

ਫਾਲਬੈਕ ਨੂੰ ਤਬਦੀਲੀ ਵਿੰਡੋ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਸ ਦੌਰਾਨ ਨਹੀਂ। ਜੇ ਪਿੰਨ ਕੀਤਾ LSP ਡਿੱਗ ਜਾਵੇ, ਤੁਸੀਂ ਸੇਵਾ ਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰਵਾਨਿਤ ਰਾਹ ਉੱਤੇ ਜਾਣ ਦਿੰਦੇ ਹੋ ਜਾਂ ਰੁਕਣ ਦਿੰਦੇ ਹੋ। ਜੋ ਨੀਤੀ ਚੁੱਪਚਾਪ ਐਸੇ ਰਾਹ ਵੱਲ ਮੁੜਦੀ ਹੈ ਜੋ ਦੇਰੀ ਜਾਂ ਵੱਖਰਤਾ ਦੀ ਸ਼ਰਤ ਤੋੜਦਾ ਹੈ, ਉਸਨੇ ਸਾਫ਼ ਰੁਕਾਵਟ ਨੂੰ ਕਿਸੇ ਨੂੰ ਵੀ ਸਮਝਾਉਣਾ ਕਿਤੇ ਔਖਾ ਬਣਾ ਦਿੱਤਾ ਹੈ।

ਵਿਕਲਪ B: IGP ਨੂੰ ਚੁਣਨ ਦਿਓ ਅਤੇ ਦੇਖੋ ਕੀ ਹੁੰਦਾ ਹੈ

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

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

ਕਿਸੇ ਇੱਕ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਫਾਰਵਰਡਿੰਗ ਪੜ੍ਹੋ

ਸੇਵਾ ਨਾਲੋਂ ਨਹੀਂ, ਪੀਅਰ ਪਤੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। Junos ਉੱਤੇ show route 203.0.113.1 detail ਚੁਣਿਆ ਅਗਲਾ ਹੌਪ ਅਤੇ ਲੇਬਲ ਕਾਰਵਾਈ ਛਾਪਦਾ ਹੈ, ਅਤੇ show route table mpls.0 ਆਉਂਦੇ ਲੇਬਲ ਨੂੰ ਉਸ ਕਾਰਵਾਈ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ। IOS XR ਉੱਤੇ show mpls l2transport vc 100 detail ਲਾਏ ਸਟੈਕ ਸਮੇਤ pseudowire ਸਥਿਤੀ ਦਿੰਦਾ ਹੈ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟ੍ਰਾਂਸਪੋਰਟ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ LSP ਵਰਤਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡਾ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਜਿਸਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। IOS XR ਉੱਤੇ traceroute mpls ipv4 203.0.113.1/32 ਲੇਬਲ-ਸਵਿੱਚਡ ਰਾਹ ਉੱਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਉਸਦੇ ਨਾਲ ਲੇਬਲ ਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਜੋ ਰਾਹ ਨੂੰ ਆਪ ਦੇਖਣ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਹੈ। ਫਿਰ ਦੂਰ ਦੇ ਪ੍ਰਦਾਤਾ ਕਿਨਾਰੇ ਤੋਂ ਅਭਿਆਸ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਵਾਪਸੀ ਦਿਸ਼ਾ ਸੁਤੰਤਰ ਤੌਰ ਤੇ ਹੱਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਨੀਤੀ ਦੇ ਅੰਸ਼ਕ ਰੋਲਆਉਟ ਪਿੱਛੋਂ ਅਸਮਰੂਪਤਾ ਆਮ ਹੈ। ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਸਹੀ ਅਤੇ ਦੂਜੀ ਵਿੱਚ ਗਲਤ ਰਾਹ ਸਮਾਨ ਰੂਪ ਨਾਲ ਗਲਤ ਰਾਹ ਨਾਲੋਂ ਬੁਰਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਅੱਧੇ ਟੈਸਟ ਪਾਸ ਹੋਣਗੇ।

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

ਪਸੰਦ ਨਾਲੋਂ ਨਹੀਂ, ਨਾਕਾਮੀ ਦੇ ਢੰਗ ਨਾਲ ਚੁਣੋ

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

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