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

ਆਵਾਜਾਈ ਚਾਲੂ ਅਤੇ ਸੇਵਾ ਬੰਦ ਹੋਣਾ ਆਮ ਹਾਲਤ ਹੈ

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

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

ਸਟੈਕ ਨੂੰ ਦੋ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵਜੋਂ ਪੜ੍ਹੋ

ਹੇਠਲਾ ਲੇਬਲ ਸੇਵਾ ਦਾ ਹੈ ਅਤੇ ਉੱਪਰਲਾ ਲੇਬਲ ਰਾਹ ਦਾ ਹੈ। RFC 4364 ਕ੍ਰਮ ਨੂੰ ਸਧਾਰਨ ਢੰਗ ਨਾਲ ਦੱਸਦਾ ਹੈ: ਪਹਿਲਾਂ VPN ਰੂਟ ਲੇਬਲ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਉਹ ਲੇਬਲ ਵਾਲਾ ਪੈਕਟ BGP ਦੇ ਅਗਲੇ ਹੌਪ ਵੱਲ ਟਨਲ ਰਾਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉੱਥੇ ਹੀ ਟ੍ਰੈਫਿਕ-ਇੰਜੀਨੀਅਰਿੰਗ ਟਨਲ ਆਪਣਾ ਲੇਬਲ ਉੱਤੇ ਰੱਖਦਾ ਹੈ।

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

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

RSVP ਦੀ ਸਫਲਤਾ ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

RSVP-TE ਸਰੋਤ ਰਾਖਵੇਂਕਰਨ ਨਾਲ ਜਾਂ ਬਿਨਾਂ ਸਪਸ਼ਟ ਰੂਪ ਨਾਲ ਰੂਟ ਕੀਤੇ LSP ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਕੋਰ ਵਿੱਚੋਂ ਪੈਕਟ ਦੇ ਰਾਹ ਬਾਰੇ ਇੱਕ ਠੋਸ ਅਤੇ ਲਾਭਦਾਇਕ ਗਾਰੰਟੀ ਹੈ। ਇਹ ਗਾਹਕ ਰਾਹਾਂ ਬਾਰੇ ਬਿਆਨ ਨਹੀਂ ਹੈ, ਅਤੇ ਸੰਰਚਿਤ ਟਨਲ ਨਾਮ ਰਾਹ ਹੀ ਨਹੀਂ ਹੈ।

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

ਕ੍ਰਮ ਨਾਲ ਜਾਂਚੋ, ਫਿਰ ਰੁਕੋ

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

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

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

ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਬੇਨਤੀ ਦੀ ਪਾਲਣਾ ਕਰੋ ਅਤੇ ਚੰਗੇ ਸਬੂਤ ਰੱਖੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ