MPLS L3VPN ਲੈਬ ਪਿੰਗ ਨਹੀਂ ਕਰ ਰਹੀ? ਇਹ ਪੰਜ ਹਾਪ ਜਾਂਚੋ

ਗਾਹਕ ਦੇ ਦੋ ਰਾਊਟਰ, ਇੱਕ ਜੋੜਾ provider edge ਡਿਵਾਈਸ ਅਤੇ ਇੱਕ ਪਿੰਗ ਜੋ ਬਿਨਾਂ ਗਲਤੀ ਸੁਨੇਹੇ ਦੇ ਮਰ ਜਾਂਦਾ ਹੈ। ਛੋਟੀ MPLS L3VPN ਲੈਬ ਵਿੱਚ ਖਰਾਬੀ ਲਗਭਗ ਹਮੇਸ਼ਾ ਪੰਜ ਚੈਕਪੁਆਇੰਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ’ਤੇ ਬੈਠਦੀ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਕੋਲ ਉਹ ਕਮਾਂਡ ਹੈ ਜੋ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਨਿਰਭਰਤਾ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਜਾਂ ਗੈਰਹਾਜ਼ਰ ਹੈ। ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਹਰ ਵਾਰ ਪਿੰਗ ਫੇਲ੍ਹ ਹੋਣ ’ਤੇ BGP ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾਵੇ, ਬਜਾਏ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚਣ ਦੇ। ਜੇ ਤੁਸੀਂ ਸਿੱਧਾ VRF ਸੰਰਚਨਾ ’ਤੇ ਛਾਲ ਮਾਰੋ, ਤਾਂ ਦੋ ਡਿਵਾਈਸ ਅੱਗੇ ਦੇ ਅਣਸੁਲਝੇ ਅਗਲੇ ਹਾਪ ਨਾਲ ਸ਼ੁਰੂ ਹੋਈ ਸਮੱਸਿਆ ’ਤੇ ਘੰਟਾ ਗੁਆ ਸਕਦੇ ਹੋ।

ਸੂਚੀ ਨੂੰ ਹੇਠਾਂ ਤੋਂ ਉੱਪਰ ਤੱਕ ਕੰਮ ਕਰੋ। ਪਾਸ ਹੋਣ ਵਾਲਾ ਚੈਕਪੁਆਇੰਟ ਪਾਸ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਅਸਫਲਤਾ ਹੀ ਡੀਬੱਗ ਕਰਨ ਯੋਗ ਹੈ।

ਪਹਿਲਾ ਚੈਕਪੁਆਇੰਟ: PE ਇੱਕ-ਦੂਜੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ

ਹਰ PE ਨੂੰ ਦੂਜੇ PE ਦੇ loopback ਤੱਕ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਰਸਤਾ ਕਿਸੇ ਅਸਲ ਚੀਜ਼ ਰਾਹੀਂ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। interior gateway protocol ਉੱਥੇ ਜਾਣ ਦਾ ਆਮ ਰਾਹ ਹੈ, ਪਰ ਸਥਿਰ ਰਸਤਾ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿੰਨੀ ਦੇਰ ਦੁਹਰਾਉ ਖੋਜ ਕਿਸੇ ਜੀਵਤ adjacency ’ਤੇ ਉੱਤਰਦੀ ਹੈ। IOS ਸ਼ੈਲੀ ਦੇ ਡਿਵਾਈਸਾਂ ’ਤੇ, show ip route 10.0.0.2 ਅਤੇ ਫਿਰ show ip cef 10.0.0.2 ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ prefix ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਇਸਦੇ ਪਿੱਛੇ ਹੱਲ ਹੋਈ adjacency ਹੈ ਜਾਂ ਨਹੀਂ। ਟੇਬਲ ਵਿੱਚ ਮੌਜੂਦ ਰਸਤਾ, ਜਿਸਦੇ ਪਿੱਛੇ adjacency ਨਹੀਂ, ਪਹੁੰਚ ਨਹੀਂ ਹੈ।

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਜਾਂਚੋ। ਅਸਮਮਿਤ IGP ਲਾਗਤ, ਗਲਤ ਪਾਸੇ ਦਾ passive interface ਜਾਂ loopback ਫਿਲਟਰ ਕਰਨ ਵਾਲਾ distribute list ਹਰ ਇੱਕ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਤੋੜਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਦਿਸ਼ਾ ਸੈਸ਼ਨ ਮਾਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ। ਜੇ loopback ਪਿੰਗ ਕਰਦੇ ਹਨ ਪਰ BGP ਸੈਸ਼ਨ Active ਵਿੱਚ ਖੜ੍ਹਾ ਹੈ, ਤਾਂ ਹੋਰ ਕੁਝ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ update source ਵੇਖੋ।

ਦੂਜਾ ਚੈਕਪੁਆਇੰਟ: ਲੇਬਲ ਦਾ ਰਸਤਾ ਮੌਜੂਦ ਹੈ

ਦੂਰ ਦੇ loopback ਤੱਕ IP ਰਸਤਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਟਰਾਂਸਪੋਰਟ ਲੇਬਲ ਲਾਵੇਗਾ। LDP ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਦੂਰ ਦੇ loopback ਦੇ ਸਥਾਨਕ ਅਤੇ ਦੂਰ ਦੋਵੇਂ ਬਾਈਂਡਿੰਗ ਹਨ ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਲੇਬਲ forwarding ਟੇਬਲ ਵਿੱਚ ਦਿਸਦਾ ਹੈ। show mpls ldp bindings 10.0.0.2 32 ਲੇਬਲ ਦੇ ਜੋੜੇ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ show mpls forwarding-table 10.0.0.2 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ line card ਅਸਲ ਵਿੱਚ ਕੀ ਲਾਵੇਗਾ। ਜਦੋਂ ਦੂਜੀ ਕਮਾਂਡ ਕੋਈ ਲੇਬਲ ਨਹੀਂ ਦਿਖਾਉਂਦੀ ਜਾਂ IP ’ਤੇ ਵਾਪਸ ਡਿੱਗਦੀ ਹੈ, ਟਰਾਂਸਪੋਰਟ VPN ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਢੋਂਦਾ ਜਿਵੇਂ ਡਿਜ਼ਾਈਨ ਮੰਨਦਾ ਹੈ।

ਇਹ ਫ਼ਰਕ ਇਸ ਗੱਲ ਤੋਂ ਆਉਂਦਾ ਹੈ ਕਿ MPLS forwarding state ਨੂੰ ਮੰਜ਼ਿਲ prefix ਤੋਂ ਕਿਵੇਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਉਹੀ ਮਾਡਲ ਜੋ RFC 3031 ਵਿੱਚ ਵਰਣਿਤ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਲੈਬ LDP ਦੀ ਬਜਾਏ RSVP-TE ਜਾਂ BGP-ਨਾਲ ਲੱਗਦੇ ਲੇਬਲ ਵਰਤਦੀ ਹੈ, ਤਾਂ ਉਸੇ ਵਿਧੀ ਦੀ ਆਪਣੀ ਅਵਸਥਾ ਜਾਂਚੋ; ਇਹ ਮੰਨਣਾ ਕਿ LDP ਹਰ ਅੰਡਰਲੇ ਲੇਬਲ ਵੰਡਦਾ ਹੈ, ਭੂਤ ਬੱਗ ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਦਾ ਆਮ ਤਰੀਕਾ ਹੈ। ਟੁੱਟਿਆ ਲੇਬਲ ਰਸਤਾ ਆਮ ਤੌਰ ’ਤੇ ਬਾਅਦ ਵਿੱਚ ਅਜਿਹੇ VPN ਰਸਤੇ ਵਜੋਂ ਦਿਸਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਹੈ ਪਰ ਬੇਕਾਰ ਹੈ।

ਤੀਜਾ ਚੈਕਪੁਆਇੰਟ: VPN ਰਸਤਾ ਸਹੀ-ਸਲਾਮਤ ਪਹੁੰਚਿਆ

ਠੀਕ ਗਾਹਕ prefix ਦਾ VPNv4 ਜਾਂ VPNv6 ਰਸਤਾ ਵੇਖੋ, ਸੈਸ਼ਨ ਸੰਖੇਪ ਨਹੀਂ। show bgp vpnv4 unicast all 10.10.1.0/24 ਨੂੰ route distinguisher, ਦੂਰ ਦੇ PE ਦੇ loopback ’ਤੇ ਸੈੱਟ next hop ਅਤੇ ਇੱਕ ਲੇਬਲ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ prefix ਨਹੀਂ ਹੈ ਤਾਂ ਪਹਿਲਾ ਸ਼ੱਕ ਸਰੋਤ PE ’ਤੇ export ਨੀਤੀ ਜਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ PE ’ਤੇ import ਨੀਤੀ ਹੈ, ਅਤੇ route target ਹੀ ਆਮ ਦੋਸ਼ੀ ਹਨ।

route target ਜਾਂਚ BGP ਪ੍ਰਾਪਤੀ ਤੋਂ ਵੱਖ ਪੜ੍ਹੋ। ਰਸਤਾ ਸਹੀ next hop ਨਾਲ ਆ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ VRF ਵਿੱਚ ਨਾ ਉੱਤਰੇ ਕਿਉਂਕਿ importtarget ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ PE ’ਤੇ show ip route vrf CUSTOMER 10.10.1.0 ਉਹ ਪਰੀਖਿਆ ਹੈ ਜਿਸਦਾ ਮਹੱਤਵ ਹੈ; BGP ਟੇਬਲ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਰਸਤਾ ਨਿਯੰਤਰਣ ਤਲ ਪਾਰ ਕਰ ਗਿਆ।

ਚੌਥਾ ਚੈਕਪੁਆਇੰਟ: interface VRF ਵਿੱਚ ਹੈ

route distinguisher ਅਤੇ route target ਵਾਲੀ VRF ਪਰਿਭਾਸ਼ਾ ਕੋਈ interface ਉਸ ਵਿੱਚ ਨਹੀਂ ਲਿਜਾਂਦੀ। CE ਵੱਲ ਦੇ interface ਨੂੰ VRF ਨਿਯੁਕਤੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ show ip vrf interfaces ਜਾਂ show ip interface brief ਨੂੰ ਇਸਨੂੰ ਸਹੀ ਇੰਸਟੈਂਸ ਹੇਠ ਸੂਚੀਬੱਧ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹੀ ਉਹ ਚੈਕਪੁਆਇੰਟ ਹੈ ਜਿੱਥੇ ਨਕਲ ਕੀਤੀ ਸੰਰਚਨਾ ਸਭ ਤੋਂ ਵੱਧ ਗਲਤੀ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ VRF ਬਲਾਕ ਪੂਰਾ ਦਿਸਦਾ ਹੈ ਜਦਕਿ interface ਅਜੇ ਵੀ ਵਿਸ਼ਵਵਿਆਪੀ ਟੇਬਲ ਵਿੱਚ ਬੈਠਾ ਹੈ।

ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ PE ਨੇ ਸਥਾਨਕ ਗਾਹਕ prefix ਉਸ VRF ਵਿੱਚ ਸਿੱਖਿਆ ਹੈ ਅਤੇ CE ਕੋਲ ਜੋੜ ਰਾਹੀਂ ਵਾਪਸੀ ਦਾ ਰਸਤਾ ਹੈ। CE ’ਤੇ PE ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਸਥਿਰ default ਲੈਬ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਬਸ਼ਰਤੇ PE ਦੇ VRF ਵਿੱਚ CE ਦੇ LAN ਤੱਕ ਰਸਤਾ ਹੋਵੇ। ਜੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅੱਧਾ ਗੈਰਹਾਜ਼ਰ ਹੈ, ਪਿੰਗ ਕੋਈ ਲੇਬਲ ਲੱਗਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।

ਪੰਜਵਾਂ ਚੈਕਪੁਆਇੰਟ: ਜਵਾਬ ਘਰ ਦਾ ਰਸਤਾ ਲੱਭ ਲੈਂਦਾ ਹੈ

ਅੱਗੇ ਜਾਣ ਵਾਲਾ ਪੈਕੇਟ ਅਤੇ ਫਿਰ ਵਾਪਸ ਆਉਣ ਵਾਲਾ ਪੈਕੇਟ ਟਰੈਕ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੀਆਂ ਟੇਬਲਾਂ ਵਰਤਦੇ ਹਨ। ਪ੍ਰਵੇਸ਼ PE ’ਤੇ ਗਾਹਕ ਸਰੋਤ VRF ਦੇ ਅੰਦਰ ਦੂਰ ਦੇ prefix ਤੱਕ ਦੂਰ ਦੇ ਲੇਬਲ ਨਾਲ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਿਰਗਮ PE ’ਤੇ ਮੰਜ਼ਿਲ ਉਸੇ VRF ਦੇ ਅੰਦਰ CE ਵੱਲ ਦੇ interface ਤੱਕ ਹੱਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। PE ਆਪਣੇ ਆਪ ਤੋਂ ਭੇਜਿਆ ਪਿੰਗ ਸਬੂਤ ਨਹੀਂ ਹੈ: ਇਹ ਵਿਸ਼ਵਵਿਆਪੀ ਟੇਬਲ ਜਾਂ ਕਿਸੇ ਹੋਰ ਸਰੋਤ ਪਤੇ ਰਾਹੀਂ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 ਉਹ ਪਰੀਖਿਆ ਹੈ ਜੋ ਚਲਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।

ਮੇਜ਼ਬਾਨਾਂ ਦੇ ਫਾਇਰਵਾਲ, reverse-path filtering ਅਤੇ CE ਦੀਆਂ access ਸੂਚੀਆਂ ਅਜੇ ਵੀ ਲਾਗੂ ਹਨ। ਜੇ ਅੱਗੇ ਦਾ ਰਸਤਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਮਰ ਜਾਂਦਾ ਹੈ, ਸਮੱਸਿਆ ਵਾਪਸੀ ਵੱਲ ਦੇ ਰਸਤੇ ਜਾਂ ਫਿਲਟਰ ਵਿੱਚ ਹੈ, MPLS ਟਰਾਂਸਪੋਰਟ ਵਿੱਚ ਨਹੀਂ।

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