MPLS ਸ਼ਾਖਾ ਰਾਊਟਿੰਗ: CE ਕੀ ਸਿੱਖਦਾ ਹੈ ਅਤੇ ਕਿਸ ਤੋਂ

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

ਰਸਤੇ ਉੱਤੇ ਇੱਕ ਪੈਕੇਟ ਦਾ ਪਿੱਛਾ ਕਰਨਾ ਇਹ ਦੇਖਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਗਾਹਕ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ ਅਤੇ ਕਿਹੜਾ ਹਿੱਸਾ ਸੇਵਾ ਦਾ ਹੈ।

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

ਹਰ ਹੌਪ ਦਾ ਕੰਮ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦਾ ਹੈ

CE-A ਨੂੰ ਦੂਰ ਦੀ LAN ਲਈ ਰੂਟ ਚਾਹੀਦਾ ਹੈ ਜੋ ਉਸਦੇ ਸਥਾਨਕ ਪ੍ਰਦਾਤਾ ਕਨੈਕਸ਼ਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਦੂਰ ਦੀ ਸ਼ਾਖਾ ਦੇ WAN ਪਤੇ ਵੱਲ ਨਹੀਂ। ਫਿਰ ਪ੍ਰਦਾਤਾ VPN ਰਾਊਟਿੰਗ ਸਥਿਤੀ ਵਰਤ ਕੇ ਪੈਕੇਟ ਨੂੰ ਆਪਣੇ ਕੋਰ ਵਿੱਚੋਂ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ CE-B ਇਸਨੂੰ ਟਾਰਗਿਟ LAN ਉੱਤੇ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਪੜਾਅ ਉੱਤੇ ਹੋਸਟ ਨੂੰ ਲੇਬਲ, VRF ਜਾਂ ਦੂਜੇ ਪਾਸੇ ਦਾ ਇੰਟਰਨੈੱਟ ਸਰਕਿਟ ਸਮਝਣ ਦੀ ਲੋੜ ਨਹੀਂ।

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

RFC 4364 ਗਾਹਕ ਅਤੇ ਪ੍ਰਦਾਤਾ ਕਿਨਾਰਿਆਂ ਵਿਚਕਾਰ ਸਾਂਝ ਨੂੰ ਪ੍ਰਦਾਤਾ ਦੇ VPN ਰੂਟ ਵੰਡਣ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਠੀਕ ਉਹੀ ਸੀਮਾ ਹੈ ਜਿਸ ਬਾਰੇ ਇਹ ਗਾਈਡ ਹੈ। ਗਾਹਕ ਦਾ ਕੰਮ ਆਪਣੇ ਕਿਨਾਰੇ ਨੂੰ ਦੱਸਣਾ ਹੈ ਕਿ ਉਹ ਕੀ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਜੋ ਪਹੁੰਚਯੋਗਤਾ ਵਾਪਸ ਦਿੰਦੀ ਹੈ ਉਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ।

ਹੈਂਡਓਫ ਨੂੰ ਕਿਸ ਗੱਲ 'ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਢਾਂਚਾ ਪ੍ਰਦਾਤਾ ਨਾਲ ਮਿਲ ਕੇ ਚੁਣੋ, ਉਨ੍ਹਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਹੀਂ। ਸਥਿਰ ਰੂਟ, BGP ਜਾਂ CE ਅਤੇ PE ਵਿਚਕਾਰ ਰਾਊਟਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਸਮਝੌਤਾ ਸਭ ਜਾਇਜ਼ ਹਨ, ਅਤੇ OSPF ਕੋਲ ਅਜਿਹੇ ਹੈਂਡਓਫ ਲਈ ਪਰਿਭਾਸ਼ਿਤ MPLS VPN ਮਾਡਲ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦੋ ਦੂਰ ਦੇ ਗਾਹਕ ਕਿਨਾਰਿਆਂ ਵਿਚਕਾਰ ਅਣ-ਨਿਰਧਾਰਿਤ ਪ੍ਰਦਾਤਾ ਕੋਰ ਰਾਹੀਂ OSPF ਗੁਆਂਢੀਆਪਣ ਬਣਾਉਣ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਅਜਿਹਾ ਡਿਜ਼ਾਈਨ ਹੈ ਜਿਸ ਲਈ ਪ੍ਰਦਾਤਾ ਸਹਿਮਤ ਨਹੀਂ ਹੋਇਆ ਅਤੇ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦਾ।

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

ਫਿਰ ਜਵਾਬ ਦਾ ਪਿੱਛਾ ਕਰੋ। ਸ਼ਾਖਾ B ਨੂੰ ਸਰੋਤ LAN ਵੱਲ ਵਾਪਸ ਜਾਣ ਲਈ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਪਾਸੇ ਦੇ ਹੋਸਟ ਨੂੰ ਆਪਣਾ ਗੇਟਵੇ ਅਤੇ ਆਪਣੀਆਂ ਸੇਵਾ ਇਜਾਜ਼ਤਾਂ ਚਾਹੀਦੀਆਂ ਹਨ। CE-A ਉੱਤੇ ਦਿਖਣ ਵਾਲਾ ਰੂਟ ਅੱਧੀ ਯਾਤਰਾ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਅੱਧੀ ਯਾਤਰਾ ਕਾਰਨ ਹੈ ਕਿ ping ਟੈਸਟ ਦੀ ਇੱਕ ਦਿਸ਼ਾ ਸਿਹਤਮੰਦ ਦਿਖਦੀ ਹੈ ਜਦੋਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਅਜੇ ਵੀ ਅਸਫਲ ਹੁੰਦੀ ਹੈ।

ਸਵੀਕ੍ਰਿਤੀ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਹੈਂਡਓਫ ਜਾਂਚੋ

ਦੋਵੇਂ ਗਾਹਕ ਕਿਨਾਰਿਆਂ ਉੱਤੇ ਰਾਊਟਿੰਗ ਸਥਿਤੀ ਇਕੱਠੀ ਕਰੋ, ਪ੍ਰਦਾਤਾ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਲੋੜੀਂਦੇ LAN ਪ੍ਰੀਫਿਕਸ VPN ਵਿੱਚ ਸਵੀਕਾਰ ਹੋਏ ਹਨ, ਅਤੇ ਫਿਰ ਹਰ ਦਿਸ਼ਾ ਵਿੱਚ ਇੱਕ ਮਨਜ਼ੂਰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ। ਸਿਰਫ਼ ਰੂਟ ਸਾਰਣੀਆਂ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀਆਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂਚ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕੰਮ ਨਾ ਕਰਨ 'ਤੇ ਕਿਹੜਾ ਨਿਯੰਤਰਣ ਤਲ ਫੇਲ੍ਹ ਹੋਇਆ।

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

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

ਜਾਣੋ ਕਿ ਸੇਵਾ ਕੀ ਨਹੀਂ ਦਿੰਦੀ

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

VPN ਵੱਖਰਾ ਕਰਨਾ ਵੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਹੈ। ਲੇਬਲ ਸਵਿਚਿੰਗ ਗਾਹਕਾਂ ਨੂੰ ਪ੍ਰਦਾਤਾ ਦੇ ਨੈੱਟਵਰਕ ਅੰਦਰ ਵੱਖਰੇ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਜੇ ਸਮਝੌਤਾ ਗੋਪਨੀਯਤਾ ਮੰਗਦਾ ਹੈ ਤਾਂ ਇਹ ਪੇਲੋਡ ਨੂੰ ਗੋਪਨੀ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਜਿੱਥੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਓਵਰਲੇਅ ਨੇ ਇਹ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਸਾਈਟ ਦੀ ਰਾਊਟਿੰਗ ਸੰਰਚਨਾ ਦੇ ਕੋਲ ਸੇਵਾ ਮਾਡਲ ਲਿਖਿਆ ਰੱਖੋ। ਸਬਨੈੱਟ ਜੋੜਨ ਵਾਲੇ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਪੜ੍ਹਨਾ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਘੋਸ਼ਿਤ ਹੁੰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਕੌਣ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਮੀਦ ਕੀਤਾ ਵਾਪਸੀ ਰਸਤਾ ਕੀ ਹੈ: BGP/MPLS IP VPN ਨਿਰਦੇਸ਼ ਇਹਨਾਂ ਸਭ ਦੇ ਪਿੱਛੇ ਮਾਡਲ ਦਾ ਹਵਾਲਾ ਹੈ।