AS ਵਿਚਕਾਰ VPNv4: ਲੇਬਲ ਫਾਰਵਰਡਿੰਗ ਸਮਝੌਤਾ ਕੀ ਮੰਗਦਾ ਹੈ

AS ਸੀਮਾ ਰਾਊਟਰ 'ਤੇ VPNv4 ਲੇਬਲ ਪੜ੍ਹਨਾ ਤੁਹਾਨੂੰ ਥੋੜ੍ਹਾ ਹੀ ਦੱਸਦਾ ਹੈ ਜਿੰਨਾ ਚਿਰ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਹੈਂਡਓਫ਼ ਕਿਹੜਾ ਅੰਤਰ-AS ਮਾਡਲ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਲੇਬਲ ਆਪਣੇ ਆਪ ਵਿੱਚ ਰੂਟ ਦਾ ਗੁਣ ਨਹੀਂ ਹੈ; ਇਹ ਦੋ ਰਾਊਟਰਾਂ ਵਿਚਕਾਰ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਅਤੇ ਡਿਲੀਵਰੀ ਬਾਰੇ ਸਮਝੌਤਾ ਦਰਜ ਕਰਦਾ ਹੈ। ਡਿਸਪਲੇ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲ ਪਛਾਣੋ। ਵਰਨਾ ਤੁਸੀਂ ਅਜਿਹੇ ਸਮਝੌਤੇ ਵਿੱਚ ਖ਼ਰਾਬੀ ਲੱਭ ਰਹੇ ਹੋ ਜੋ ਕਿਸੇ ਨੇ ਲਿਖਿਆ ਹੀ ਨਹੀਂ।

ਸੀਮਾ ਕਿਹੜਾ ਮਾਡਲ ਲਾਗੂ ਕਰਦੀ ਹੈ

VRF-ਤੋਂ-VRF ਬੰਦੋਬਸਤ ਮਿਲਦੇ VRF ਨੂੰ ਰਾਊਟਿਡ ਅਟੈਚਮੈਂਟ ਰਾਹੀਂ ਜੋੜਦੀ ਹੈ। ਹਰ ਧਿਰ ਦੂਜੀ ਨੂੰ ਗਾਹਕ-ਕਿਨਾਰੇ ਦਾ ਗੁਆਂਢੀ ਮੰਨਦੀ ਹੈ ਅਤੇ ਉਹ ਸਾਧਾਰਨ IPv4 ਰੂਟ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਸ ਸੀਮਾ 'ਤੇ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ MPLS ਦੀ ਲੋੜ ਨਹੀਂ।

ਦੂਜੀ ਬੰਦੋਬਸਤ ਲੇਬਲ ਵਾਲੇ VPNv4 ਰੂਟ ਸੀਮਾ ਰਾਊਟਰਾਂ ਵਿਚਕਾਰ ਹੀ ਬਦਲਦੀ ਹੈ। ਇਹ ਤਾਂ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜੇ ਇੰਟਰਕਨੈਕਟ ਦੇ ਪਾਰ ਇੱਕ ਸੁਸੰਗਤ ਲੇਬਲ-ਸਵਿੱਚਡ ਪਾਥ ਹੋਵੇ ਅਤੇ route-target ਵੰਡਣਾ ਤੇ ਭਰੋਸੇ ਦਾ ਮਾਡਲ ਦੋਵੇਂ ਧਿਰਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਹੋਵੇ। ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਟੁਕੜਾ ਨਾ ਹੋਵੇ, ਤਾਂ ਮਾਡਲ ਵਰਤੋਂ ਵਿੱਚ ਨਹੀਂ, ਕਨਫਿਗਰੇਸ਼ਨ ਭਾਵੇਂ ਕੁਝ ਵੀ ਸੁਝਾਏ।

ਤੀਜੀ ਬੰਦੋਬਸਤ ਲੇਬਲ ਵਾਲੀ PE ਪਹੁੰਚ ਵੰਡਦੀ ਹੈ ਜਦਕਿ VPN ਰੂਟ AS ਪਾਰ ਐਂਡਪੁਆਇੰਟ ਜਾਂ ਰੂਟ ਰਿਫਲੈਕਟਰਾਂ ਵਿਚਕਾਰ ਸਫ਼ਰ ਕਰਦੇ ਹਨ। ਇਹਨਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਸੀਮਾ 'ਤੇ ਵੱਖਰਾ ਕੰਮ ਛੱਡਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਦੇ ਕੰਟਰੋਲ ਪਲੇਨ ਨੂੰ ਦੂਜੇ ਦੀਆਂ ਇੰਟਰਫ਼ੇਸ ਧਾਰਨਾਵਾਂ ਨਾਲ ਮਿਲਾਉਣਾ ਹੀ ਕਲਾਸਿਕ ਅਸਫਲਤਾ ਹੈ। ਉਹ ਬੇਮੇਲ ਆਮ ਤੌਰ 'ਤੇ ਅਜਿਹੇ ਲੇਬਲ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ ਜੋ ਇੱਕ ਪਾਸੇ ਸਹੀ ਲੱਗਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰੀਫ਼ਿਕਸ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਪੜ੍ਹੋ

ਇੱਕ ਅਧਿਕਾਰਤ ਗਾਹਕ ਪ੍ਰੀਫ਼ਿਕਸ ਲਓ ਅਤੇ ਉਸ 'ਤੇ ਤੁਰੋ। ਦੇਖੋ ਕੀ ਐਲਾਨਿਆ ਗਿਆ, ਕੀ ਪਹੁੰਚਿਆ, ਨੈਕਸਟ ਹੌਪ, ਲੇਬਲ ਅਤੇ ਉਹ ਇੰਪੋਰਟ ਨੀਤੀ ਜਿਸਨੇ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ। ਫਿਰ ਦੇਖੋ ਰਾਊਟਰ ਉਸ ਨੈਕਸਟ ਹੌਪ ਵੱਲ ਫਾਰਵਰਡਿੰਗ ਕਿਵੇਂ ਹੱਲ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉੱਥੇ ਹੀ ਲੇਬਲ ਪੈਕਟ ਬਣਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅੱਧਾ ਹਿੱਸਾ ਛੱਡੋ ਤਾਂ ਤੁਸੀਂ ਅਜਿਹੇ ਕੰਟਰੋਲ ਪਲੇਨ ਦਾ ਵਰਣਨ ਕਰ ਰਹੇ ਹੋ ਜੋ ਸ਼ਾਇਦ ਟ੍ਰੈਫ਼ਿਕ ਨਾ ਲੈ ਜਾ ਰਿਹਾ ਹੋਵੇ। ਦੋਵੇਂ ਪਾਠ ਸਿਰਫ਼ ਇਕੱਠੇ ਹੀ ਅਰਥ ਰੱਖਦੇ ਹਨ।

ਇਹ ਸੰਖਿਆ ਸਥਾਨਕ ਹੈ। ਇਸਦਾ ਅਰਥ ਉਸ ਰਾਊਟਰ ਨਾਲ ਜੁੜਿਆ ਹੈ ਜਿਸਨੇ ਇਹ ਤੈਅ ਕੀਤਾ ਅਤੇ ਉਸ ਪਾਥ ਨਾਲ ਜੋ ਉੱਥੇ ਪੈਕਟ ਲੈ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਹੀ ਮੁੱਲ ਦੋ ਵਾਰ ਦਿਖ ਸਕਦਾ ਹੈ ਅਤੇ ਦੋ ਵੱਖਰੀਆਂ ਗੱਲਾਂ ਕਹਿ ਸਕਦਾ ਹੈ। ਇਸਦੀ ਤੁਲਨਾ ਉਸ ਨਾਲ ਕਰੋ ਜੋ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਧਿਰ ਕਹਿੰਦੀ ਹੈ ਕਿ ਉਸਨੂੰ ਮਿਲਿਆ।

ਲੇਬਲ ਸਥਾਨਕ ਹੈ, ਅਤੇ ਵਾਅਦਾ ਵੀ

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

RFC 4364 ਲੇਬਲ ਵਾਲੀ VPNv4 ਪੀਅਰਿੰਗ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬੰਦੋਬਸਤਾਂ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਅਜਿਹੇ ਲੇਬਲ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਜੋ ਉਸ ਪੀਅਰ ਨੂੰ ਕਦੇ ਐਲਾਨੇ ਨਹੀਂ ਗਏ। ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਜਿੰਨੀ ਹੀ ਸੁਰੱਖਿਆ ਦੀ ਗੱਲ ਹੈ। ਜਨਤਕ ਇੰਟਰਨੈਟ ਰੂਟਿੰਗ ਸਬੰਧ ਨੂੰ ਨਿੱਜੀ VPN ਰੂਟ ਦੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਤੋਂ ਦੂਰ ਰੱਖੋ। ਜੇ ਇੰਟਰਕਨੈਕਟ ਸਾਦਾ IP ਹੈ, ਤਾਂ ਆਸ ਨਾ ਰੱਖੋ ਕਿ ਕੋਈ ਲੇਬਲ ਇਸ ਵਿੱਚੋਂ ਬਚੇਗਾ। ਅਤੇ ਜਿੱਥੇ ਲਿੰਕ ਲੇਬਲ ਵਾਲਾ ਹੈ, ਉੱਥੇ ਹਰ ਹੌਪ 'ਤੇ ਬਾਹਰਲਾ ਟਰਾਂਸਪੋਰਟ ਲੇਬਲ ਠੀਕ ਤਰ੍ਹਾਂ ਬਦਲਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਇੱਕ ਪਾਸੇ ਸਹੀ ਲੱਗਦਾ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਗਾਇਬ ਹੁੰਦਾ ਲੇਬਲ ਆਮ ਤੌਰ 'ਤੇ ਉਹੀ ਬੇਮੇਲ ਹੁੰਦਾ ਹੈ, ਰੂਟਿੰਗ ਦੀ ਖ਼ਰਾਬੀ ਨਹੀਂ।

ਸਵੀਕ੍ਰਿਤੀ ਵੇਲੇ ਕੀ ਲਿਖਣਾ ਹੈ

ਸਵੀਕ੍ਰਿਤੀ ਪੈਕਟ ਦੀ ਪਰਖ ਹੈ, ਟੇਬਲ ਦੀ ਸਮੀਖਿਆ ਨਹੀਂ। ਗਾਹਕ ਪੈਕਟ ਦਾ ਦੂਰਲੇ VRF ਤੱਕ ਪਿੱਛਾ ਕਰੋ ਅਤੇ ਉਸਦੇ ਜਵਾਬ ਦਾ ਵਾਪਸ ਪਿੱਛਾ ਕਰੋ, ਫਿਰ ਲਿਖੋ ਕਿ ਹੈਂਡਓਫ਼ ਕਿਹੜਾ ਮਾਡਲ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਸ਼ਾਮਲ ਕਰੋ ਦੋਵੇਂ ਪਾਸਿਆਂ ਦੇ ਹੈਂਡਓਫ਼ ਮਾਲਕਾਂ ਨੂੰ ਅਤੇ ਇਹ ਕਿ ਸੀਮਾ ਸਾਦਾ IP ਲੈ ਜਾਂਦੀ ਹੈ ਜਾਂ ਲੇਬਲ ਵਾਲਾ ਟ੍ਰੈਫ਼ਿਕ।

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