ਕੀ ਕੋਰ ਵਿੱਚ VPNv4 ਨੂੰ MPLS ਚਾਹੀਦਾ ਹੈ? ਜ਼ਰੂਰੀ ਨਹੀਂ
BGP VPNv4 ਰੂਟ-ਵੰਡ ਸੰਦਰਭ ਬਾਰੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਫਾਰਵਰਡਿੰਗ ਮਾਰਗ ਬਾਰੇ ਨਹੀਂ। ਆਯਾਤ, ਅਗਲੇ ਹੌਪ ਦਾ ਹੱਲ ਅਤੇ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ ਹੋ ਉਹ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਵੱਖ ਕਰੋ।
ਦੋ ਰਾਊਟਰਾਂ ਵਿਚਕਾਰ VPNv4 ਪਤਾ-ਪਰਿਵਾਰ ਚਾਲੂ ਕਰਨਾ ਸਿਰਫ਼ ਰੂਟ-ਵੰਡ ਸੰਦਰਭ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ। ਇਹ ਫਾਰਵਰਡਿੰਗ ਮਾਰਗ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜਾ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਗਾਹਕ ਪੈਕੇਟ ਨੂੰ ਦੂਰਲੇ ਅੰਤ ਬਿੰਦੂ ਤੱਕ ਲੈ ਜਾਵੇਗਾ। ਜਦੋਂ ਇਹ ਦੋ ਤੱਥ ਵੱਖ ਹੋ ਜਾਂਦੇ ਹਨ, ਸਵਾਲ «ਕੀ ਇਸਨੂੰ ਕੋਰ ਵਿੱਚ MPLS ਚਾਹੀਦਾ ਹੈ» ਪਲੇਟਫਾਰਮ ਵੱਲੋਂ ਸਮਰਥਿਤ ਡੇਟਾ ਪਲੇਨ ਬਾਰੇ ਵਧੇਰੇ ਸੰਕੁਚਿਤ ਅਤੇ ਜਵਾਬ ਦੇਣਯੋਗ ਸਵਾਲ ਬਣ ਜਾਂਦਾ ਹੈ।
ਪਤਾ-ਪਰਿਵਾਰ ਅਸਲ ਵਿੱਚ ਕੀ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ
ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ BGP AFI 1 ਅਤੇ SAFI 128 ਅਧੀਨ VPNv4 ਨੈੱਟਵਰਕ ਪਰਤ ਦੀ ਪਹੁੰਚਯੋਗਤਾ ਜਾਣਕਾਰੀ ਲਿਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਐਂਟਰੀ ਰੂਟ ਵਿਭੇਦਕ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਲੇਬਲ ਨਾਲ ਜੋੜਦੀ ਹੈ। ਸੈਸ਼ਨ ਇਸ ਗੱਲ ਦੀ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਧਿਰਾਂ ਉਹ ਜਾਣਕਾਰੀ ਐਨਕੋਡ ਅਤੇ ਡੀਕੋਡ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਜਿਸ ਬਾਰੇ ਇਹ ਗੱਲਬਾਤ ਨਹੀਂ ਕਰਦਾ ਉਹ ਡੇਟਾ ਪਲੇਨ ਹੈ। ਇਸ ਪੈਰੇ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਫਾਰਵਰਡਿੰਗ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਸੈਸ਼ਨ ਦੇ ਚੜ੍ਹਨ ਨਾਲ ਤੈਅ ਨਹੀਂ ਹੁੰਦਾ।
ਇਸ ਲਈ ਸਫਲ ਸੈਸ਼ਨ ਨਿਯੰਤਰਣ-ਪਲੇਨ ਸਮਰੱਥਾ ਦਾ ਸਬੂਤ ਹੈ, ਫਾਰਵਰਡਿੰਗ ਦਾ ਨਹੀਂ। ਰਾਊਟਰ ਹਜ਼ਾਰਾਂ VPNv4 ਐਂਟਰੀਆਂ ਰੱਖ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਹਰ ਗਾਹਕ ਪੈਕੇਟ ਨੂੰ ਸੁੱਟ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਕਾਰਨ ਹੀ ਦੋਵੇਂ ਅਸਫਲਤਾ ਵਰਗ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਰਲ-ਗਲ ਜਾਂਦੇ ਹਨ।
NLRI ਵਿੱਚਲੇ ਲੇਬਲ ਵੱਲ ਧਿਆਨ ਦਿਓ। ਇਹ ਸੇਵਾ ਲੇਬਲ ਹੈ, VRF ਦੇ ਅੰਦਰਲੇ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਬੱਧਾ ਹੋਇਆ ਹੈ, ਅਤੇ ਪੈਕੇਟ ਨਿਕਾਸ ਅੰਤ ਬਿੰਦੂ ਤੱਕ ਪਹੁੰਚਣ 'ਤੇ ਇਸਦੀ ਫਾਰਵਰਡਿੰਗ ਭੂਮਿਕਾ ਹੁੰਦੀ ਹੈ। ਕੋਈ ਵੀ ਟਰਾਂਜ਼ਿਟ ਯੰਤਰ ਇਸਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਹੈ।
ਪ੍ਰਾਪਤੀ, ਆਯਾਤ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਤਿੰਨ ਕਦਮ ਹਨ
ਰੂਟ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਇਸਦੀ ਵਰਤੋਂ ਦੀ ਇਜਾਜ਼ਤ ਹੋਣਾ ਅਤੇ ਇਸ ਨਾਲ ਫਾਰਵਰਡ ਕਰ ਸਕਣਾ ਯੰਤਰ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸੇ ਕਰਦੇ ਹਨ। BGP ਜੋ ਸੁਣਦਾ ਹੈ ਉਹ ਸੰਭਾਲਦਾ ਹੈ; ਆਯਾਤ ਨੀਤੀ ਅਤੇ ਰੂਟ-ਟਾਰਗੇਟ ਮੇਲ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜਾ VRF ਇਸਨੂੰ ਵਿਚਾਰ ਸਕਦਾ ਹੈ; ਫਿਰ ਫਾਰਵਰਡਿੰਗ ਪਲੇਨ ਨੂੰ ਘੋਸ਼ਿਤ ਅਗਲੇ ਹੌਪ ਨੂੰ ਅਜਿਹੀ ਚੀਜ਼ ਵਿੱਚ ਹੱਲ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜਿਸਨੂੰ ਇਹ ਸੱਚਮੁੱਚ ਤਾਰ 'ਤੇ ਭੇਜ ਸਕਦਾ ਹੈ।
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
ਸਭ ਤੋਂ ਹੈਰਾਨਕੁਨ ਅਸਫਲਤਾਵਾਂ ਇਸੇ ਮੱਧ ਕਦਮ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ। ਰੂਟ BGP ਸਾਰਣੀ ਵਿੱਚ ਮੌਜੂਦ, ਵੈਧ ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ VRF ਰੂਟ ਸਾਰਣੀ ਖਾਲੀ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਰੂਟ ਟਾਰਗੇਟ ਆਯਾਤ ਸੂਚੀ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਦਾ। ਕੁਝ ਵੀ ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀ ਦਰਜ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਕੋਈ ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀ ਹੋਈ ਹੀ ਨਹੀਂ।
ਆਖਰੀ ਕਦਮ ਉਹ ਹੈ ਜਿੱਥੇ ਪਲੇਟਫਾਰਮ ਸਮਰਥਨ ਦਿਸਦਾ ਹੈ। ਅੰਡਰਲੇ ਵਿੱਚ ਪਹੁੰਚਯੋਗ ਅਗਲਾ ਹੌਪ ਆਪਣੇ-ਆਪ VPN ਸੇਵਾ ਟਰਾਂਸਪੋਰਟ ਵਜੋਂ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਯੰਤਰ ਨੂੰ ਖਾਸ ਟਨਲ ਕਿਸਮ, ਖਾਸ ਲੇਬਲ ਕਾਰਵਾਈ ਜਾਂ ਦੋਵੇਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਹੱਲ ਸਥਿਤੀ ਪੜ੍ਹਨਾ ਰੂਟ ਗਿਣਤੀ ਪੜ੍ਹਨ ਨਾਲੋਂ ਵਧੇਰੇ ਜਾਣਕਾਰੀਪੂਰਨ ਹੈ।
IP ਕੋਰ ਅਜਿਹਾ ਸਟੈਕ ਲਿਜਾ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਇਹ ਕਦੇ ਸਵਿੱਚ ਨਹੀਂ ਕਰਦਾ
ਬਚਾਉਣ ਯੋਗ ਫ਼ਰਕ «ਕੋਰ MPLS ਨਹੀਂ ਚਲਾਉਂਦਾ» ਅਤੇ «ਸੇਵਾ ਵਿੱਚ ਕਿਤੇ ਵੀ ਲੇਬਲ ਨਹੀਂ» ਵਿਚਕਾਰ ਹੈ। ਇਹ ਵੱਖਰੇ ਦਾਅਵੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਪਹਿਲਾ ਟਰਾਂਜ਼ਿਟ ਯੰਤਰਾਂ ਬਾਰੇ ਹੈ। RFC 4023 IP ਜਾਂ GRE ਟਨਲਾਂ ਰਾਹੀਂ MPLS ਲਿਜਾਣ ਦੀ ਪਰਿਭਾਸ਼ਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਕਾਰਜਵਿਧੀ ਪੂਰੇ IP ਕੋਰ 'ਤੇ ਦੂਜੇ ਦਾਅਵੇ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ।
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulਟਰਾਂਜ਼ਿਟ ਰਾਊਟਰ ਬਾਹਰੀ IP ਮੰਜ਼ਿਲ ਦੇ ਆਧਾਰ 'ਤੇ ਫਾਰਵਰਡ ਕਰਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਨਾ ਗਾਹਕ ਪ੍ਰੀਫਿਕਸ ਚਾਹੀਦੇ ਹਨ ਨਾ ਸਥਾਨਕ ਲੇਬਲ ਸਵਿੱਚਿੰਗ। ਦੂਰਲੇ ਸਿਰੇ 'ਤੇ ਬਾਹਰੀ ਟਨਲ ਹਟਾਈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸੇਵਾ ਲੇਬਲ ਆਪਣਾ ਕੰਮ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਕੋਰ ਨੇ ਅਪਾਰਦਰਸ਼ੀ ਪੇਲੋਡ ਹਿਲਾਇਆ, ਅਤੇ IP ਨੈੱਟਵਰਕ ਜਿਸ ਵਿੱਚ ਚੰਗਾ ਹੈ ਉਹ ਬਿਲਕੁਲ ਇਹੀ ਹੈ।
ਇਹ ਡਿਜ਼ਾਈਨ ਤੁਹਾਨੂੰ ਜੋ ਨਹੀਂ ਦਿੰਦਾ ਉਹ ਸਰਵਵਿਆਪੀ ਗਾਰੰਟੀ ਹੈ। ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਹਰ ਰਾਊਟਰ ਹਰ VPNv4 ਅਗਲੇ ਹੌਪ ਨੂੰ ਕਿਸੇ ਵੀ GRE ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਇਹ ਕੰਮ ਕਰ ਰਹੀ ਸਥਾਨਕ MPLS ਸੰਰਚਨਾ ਮਿਟਾਉਣ ਦਾ ਕਾਰਨ ਹੈ। ਇਹ ਸਰਵਵਿਆਪੀ ਦਾਅਵੇ ਵਿਰੁੱਧ ਪ੍ਰਤੀਉਦਾਹਰਨ ਹੈ, ਅਤੇ ਵਿਵਹਾਰਕ ਸਵਾਲ ਪਲੇਟਫਾਰਮ ਤੱਕ ਸਥਾਨਕ ਰਹਿੰਦਾ ਹੈ। ਉਸ ਸਵਾਲ ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਨਿਯਮ ਵਜੋਂ ਨਹੀਂ, ਪਲੇਟਫਾਰਮ ਸੀਮਾ ਵਜੋਂ ਦਰਜ ਕਰੋ।
ਬਾਕਸ 'ਤੇ ਜ਼ੰਜੀਰ ਟੁੱਟਣ ਤੱਕ ਤੁਰੋ
ਪ੍ਰਾਪਤ ਰੂਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਸ ਪਹਿਲੇ ਕਦਮ 'ਤੇ ਰੁਕੋ ਜੋ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਿਛਲਾ ਕਦਮ ਟੁੱਟਿਆ ਹੋਣ 'ਤੇ ਅਗਲੇ ਕਦਮਾਂ ਦਾ ਨਿਦਾਨ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਆਮ ਅਮਲ ਵਿੱਚ ਚਾਰ ਕਮਾਂਡ ਇਸਦਾ ਬਹੁਤਾ ਹਿੱਸਾ ਕਵਰ ਕਰਦੀਆਂ ਹਨ।
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_Aਉਨ੍ਹਾਂ ਨੂੰ ਚਾਰ ਸੁਤੰਤਰ ਜਾਂਚਾਂ ਵਜੋਂ ਨਹੀਂ, ਕ੍ਰਮ ਵਜੋਂ ਪੜ੍ਹੋ। ਪਹਿਲਾ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਪਰਿਵਾਰ ਸਰਗਰਮ ਹੈ ਅਤੇ ਸਾਥੀ ਰੂਟਾਂ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਕਰ ਰਿਹਾ ਹੈ; ਦੂਜਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰੀਫਿਕਸ ਲਾਭਦਾਇਕ ਅਗਲੇ ਹੌਪ ਨਾਲ ਆਇਆ ਜਾਂ ਨਹੀਂ; ਤੀਜਾ ਆਯਾਤ ਯੋਗਤਾ ਸਾਬਤ ਕਰਦਾ ਹੈ; ਚੌਥਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਫਾਰਵਰਡਿੰਗ ਪਲੇਨ ਨੇ ਇਸ ਨਾਲ ਲੇਬਲ ਜਾਂ ਟਨਲ ਬੰਨ੍ਹਿਆ ਜਾਂ ਨਹੀਂ।
ਫਿਰ ਕੰਮ ਦੇ ਭਾਰ ਦਾ ਮਾਰਗ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਜਾਂਚੋ, ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਸਹਿਣ ਵਾਲੇ MTU ਨਾਲ। GRE ਹੈਡਰ ਬਾਈਟ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਛੋਟੇ ਪ੍ਰੋਬ ਪਾਰ ਕਰਨ ਵਾਲਾ ਮਾਰਗ ਪੂਰੇ ਆਕਾਰ ਦੇ ਪੈਕੇਟਾਂ 'ਤੇ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਟਰਾਂਸਪੋਰਟ ਖਰਾਬੀ ਦੀ ਬਜਾਏ ਐਪਲੀਕੇਸ਼ਨ ਖਰਾਬੀ ਵਾਂਗ ਦਿਸਦਾ ਹੈ।
ਦੋ ਸੰਚਾਲਨ ਟਿੱਪਣੀਆਂ ਚੱਕਰ ਬੰਦ ਕਰਦੀਆਂ ਹਨ। GRE ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਹੈ, ਗੋਪਨੀਯਤਾ ਨਹੀਂ, ਇਸ ਲਈ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੇ ਟਰਾਂਜ਼ਿਟ ਨੈੱਟਵਰਕ ਨੂੰ ਧਾਰਨਾ ਦੀ ਬਜਾਏ ਉੱਪਰ ਸਮਰਥਿਤ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਤੋਂ ਪਹਿਲਾਂ ਦਰਜ ਕਰੋ ਕਿ ਪਲੇਟਫਾਰਮ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਸਮਰਥਿਤ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹੀ ਇੱਕ ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸਿਰਫ਼-IP ਕੋਰ ਵੈਧ ਚੋਣ ਹੈ ਜਾਂ ਫਾਰਵਰਡ ਨਾ ਕਰ ਸਕਣ ਵਾਲੀ ਯੋਜਨਾ।