ਦੋ ਗਾਹਕਾਂ ਲਈ ਇੱਕੋ /24? VPNv4 ਨੂੰ RD ਅਤੇ ਲੇਬਲ ਚਾਹੀਦਾ ਹੈ
ਦੋ ਕਿਰਾਏਦਾਰ ਇੱਕੋ /24 ਦਾ ਐਲਾਨ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਰ ਸਕਦੇ ਹਨ ਕਿ RD ਹਰ ਰੂਟ ਨੂੰ ਆਪਣੀ ਪਛਾਣ ਦਿੰਦਾ ਹੈ। ਲੇਬਲ ਦੂਜੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਅੱਗੇ ਕਿਵੇਂ ਭੇਜਣਾ ਹੈ।
ਦੋ ਕਿਰਾਏਦਾਰ ਆਪਣੀ ਸ਼ਾਖਾ ਨੂੰ ਇੱਕੋ 10.50.0.0/24 ਨਾਲ ਨੰਬਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਇੱਕ ਦਾ ਰੂਟ ਪ੍ਰਦਾਤਾ ਦੇ ਕਿਨਾਰੇ ਤੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜਾ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ। ਉਸ ਟਿਕਟ ਪਿੱਛੇ ਦੀ ਸਰਲੀਕਰਨ ਆਮ ਤੌਰ 'ਤੇ ਰੂਟ ਵਿਭੇਦਕ (RD) ਛੱਡਣਾ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ "ਲੇਬਲ ਪਹਿਲਾਂ ਹੀ ਗਾਹਕ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ"। ਉਹ ਨਹੀਂ ਕਰਦਾ। RD ਅਤੇ ਲੇਬਲ ਦੋ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਅੰਤਰ ਤਦ ਹੀ ਦਿਸਦਾ ਹੈ ਜਦੋਂ ਓਵਰਲੈਪ ਹੁੰਦੇ ਪਤੇ ਇਸਨੂੰ ਮਜਬੂਰ ਕਰਦੇ ਹਨ।
ਜਿੱਥੇ ਦੋ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਉੱਥੇ ਇੱਕ ਰੂਟ
ਆਮ IPv4 ਯੂਨੀਕਾਸਟ ਇੱਕੋ ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਦੋ ਰਾਹਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਵਧੀਆ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਕਿਰਾਏਦਾਰ A ਤੋਂ 10.50.0.0/24 ਅਤੇ ਕਿਰਾਏਦਾਰ B ਤੋਂ 10.50.0.0/24 ਇੱਕੋ ਕੁੰਜੀ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਜਿੱਤਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਸਿਰਫ਼ ਬੈਕਅਪ ਰਾਹ ਵਜੋਂ ਬਚਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਨੇ ਉਹੀ ਕੀਤਾ ਜੋ ਕਿਹਾ ਗਿਆ ਸੀ; ਕੰਟਰੋਲ ਪਲੇਨ ਨੂੰ ਇੱਕੋ ਪਛਾਣਕਰਤਾ ਹੇਠ ਦੋ ਵੱਖਰੇ ਰੂਟ ਸਟੋਰ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ।
ਨਤੀਜਾ ਗਲਤੀ ਵਾਂਗ ਨਹੀਂ, ਗੁੰਮ ਰੂਟ ਵਾਂਗ ਦਿਸਦਾ ਹੈ: ਜੋ PE ਮੁਕਾਬਲਾ ਹਾਰ ਗਿਆ ਉਹ ਅਜੇ ਵੀ ਆਪਣੇ ਕਿਰਾਏਦਾਰ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਸਾਈਟ ਦੇ ਅੰਦਰ ਪਿੰਗ ਸਫਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਟੈਸਟ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਨੀਤੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ VPNv4 ਟੇਬਲ ਵਿੱਚ ਉਸ ਪ੍ਰੀਫਿਕਸ ਦੀਆਂ ਐਂਟਰੀਆਂ ਗਿਣੋ।
RD ਇੱਕ ਕੁੰਜੀ ਨੂੰ ਦੋ ਬਣਾਉਂਦਾ ਹੈ
ਅੱਠ ਬਾਈਟ ਦਾ ਰੂਟ ਵਿਭੇਦਕ IPv4 ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ BGP ਜੋ ਵਸਤੂ ਚੁੱਕਦਾ ਹੈ ਉਹ IPv4 ਪ੍ਰੀਫਿਕਸ ਦੀ ਥਾਂ VPN-IPv4 ਪਤਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਦੋ ਕਿਰਾਏਦਾਰ ਇੱਕੋ 32 ਬਿੱਟ ਰੱਖ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਅੱਗੇ ਵਾਲੇ 64 ਬਿੱਟ ਵੱਖਰੇ ਹਨ। AS-ਅਧਾਰਿਤ RD ਅਤੇ ਪਤਾ-ਅਧਾਰਿਤ RD ਲਈ ਫਾਰਮੈਟ ਕਿਸਮਾਂ ਹਨ, ਅਤੇ ਚੋਣ ਮੂਲ PE ਦੀ ਹੈ। PE ਇੱਕੋ AS ਸਾਂਝਾ ਕਰਦੇ ਹੋਣ ਤਾਂ AS-ਅਧਾਰਿਤ RD ਆਮ ਹੈ, ਅਤੇ ਨਾ ਕਰਨ 'ਤੇ ਪਤਾ-ਅਧਾਰਿਤ।
RD ਨੂੰ ਮੈਂਬਰਸ਼ਿਪ ਟੈਗ ਵਜੋਂ ਨਾ ਪੜ੍ਹੋ. ਰੂਟ ਟਾਰਗੇਟ ਆਯਾਤ ਅਤੇ ਨਿਰਯਾਤ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ ਅਤੇ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੇ VRF ਰੂਟ ਸਥਾਪਿਤ ਕਰ ਸਕਦੇ ਹਨ; RD ਸਿਰਫ਼ ਇਹ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਰੂਟ ਦੀ ਆਪਣੀ ਪਛਾਣ ਹੈ। ਹਰ VRF ਨੂੰ ਆਪਣਾ RD ਦੇਣਾ ਆਮ ਅਭਿਆਸ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਸ ਮੈਪਿੰਗ ਨੂੰ ਰੂਟ ਦਰਸ਼ਕ ਵਿੱਚ ਪੜ੍ਹਨਯੋਗ ਰੱਖਦਾ ਹੈ।
ਲੇਬਲ ਸਥਾਨਕ ਅੱਗੇ ਭੇਜਣ ਦੀ ਹਦਾਇਤ ਹੈ
ਹਰ ਐਲਾਨ MPLS ਲੇਬਲ ਵੀ ਚੁੱਕਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਅਰਥ ਉਸ ਰਾਊਟਰ ਤੱਕ ਸੀਮਿਤ ਹੈ ਜਿਸਨੇ ਇਹ ਵੰਡਿਆ। ਦੂਜਾ PE ਅਸੰਬੰਧਿਤ ਮੰਜ਼ਿਲ ਲਈ ਉਹੀ ਨੰਬਰ ਦੇ ਸਕਦਾ ਹੈ। ਇਸੇ ਲਈ ਲੇਬਲ ਗਾਹਕ ਦੀ ਪਛਾਣ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ: ਨੰਬਰ ਅਗਲੇ ਹੌਪ ਅਤੇ ਇਸਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਵਾਲੀ ਭੇਜਣ ਦੀ ਸਥਿਤੀ ਦੇ ਕੋਲ ਹੀ ਸਹੀ ਹੈ।
ਵੰਡ ਦੀ ਬਾਰੀਕੀ ਲਾਗੂਕਰਨ ਅਤੇ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਬਦਲਦੀ ਹੈ: ਕੁਝ ਪਲੇਟਫਾਰਮ ਹਰ VRF ਲਈ ਇੱਕ ਲੇਬਲ ਵੰਡਦੇ ਹਨ, ਹੋਰ ਹਰ ਪ੍ਰੀਫਿਕਸ ਲਈ, ਅਤੇ ਲੇਬਲ ਗਾਹਕ ਦੀ ਥਾਂ ਭੇਜਣ ਦੀ ਕਿਰਿਆ ਦੀ ਪਛਾਣ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕੋ ਮੰਜ਼ਿਲ 'ਤੇ ਪਹੁੰਚਣ ਵਾਲੇ ਦੋ ਵੱਖਰੇ ਲੇਬਲ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ ਹਨ, ਅਤੇ ਦੋ PE 'ਤੇ ਇੱਕੋ ਲੇਬਲ ਨੰਬਰ ਵੀ ਨਹੀਂ।
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
ਇੱਕ ਦੂਜੇ ਦੀ ਥਾਂ ਕਿਉਂ ਨਹੀਂ ਲੈ ਸਕਦਾ
ਐਲਾਨ ਪੜ੍ਹਨ ਦਾ ਅਰਥ ਹੈ ਚਾਰ ਚੀਜ਼ਾਂ ਇਕੱਠੀਆਂ ਵੇਖਣਾ: RD-ਯੋਗ ਪ੍ਰੀਫਿਕਸ, ਰੂਟ ਟਾਰਗੇਟ, ਅਗਲਾ ਹੌਪ ਅਤੇ ਲੇਬਲ। ਵਰਤੋਂਕਾਰ ਪੈਕੇਟ ਪੜ੍ਹਨ ਦਾ ਅਰਥ ਹੈ ਉਸ ਜਾਣਕਾਰੀ ਤੋਂ ਸਥਾਪਿਤ ਸਟੈਕ ਵੇਖਣਾ। ਸਿਹਤਮੰਦ ਡਿਜ਼ਾਈਨ ਦੋਵੇਂ ਪਾਸੇ ਮੇਲ ਖਾਂਦੇ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਟੁੱਟੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਪਾਸਾ ਸਹੀ ਅਤੇ ਦੂਜਾ ਪੁਰਾਣਾ ਹੁੰਦਾ ਹੈ। ਉਹੀ ਤੁਲਨਾ ਪਛਾਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਭੇਜਣ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ।
ਕੰਟਰੋਲ ਪਲੇਨ ਅਤੇ ਡੇਟਾ ਪਲੇਨ ਵਿਚਕਾਰ ਸਾਫ਼ ਵਿਰੋਧ ਸਿੱਖਿਆ ਸਾਧਨ ਹੈ, ਐਨਕੋਡਿੰਗ ਦਾ ਵਰਣਨ ਨਹੀਂ। RFC 8277 ਲੇਬਲ ਨੂੰ ਲੇਬਲ ਵਾਲੇ NLRI ਦੇ ਅੰਦਰ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਐਲਾਨ ਆਪ ਬੰਧਨ ਚੁੱਕਦਾ ਹੈ; ਇਸਨੂੰ ਭੇਜਣ ਲਈ ਵਰਤਣਾ ਪਿਛਲਾ, ਵੱਖਰਾ ਕਦਮ ਹੈ।
ਜਦੋਂ ਕਿਰਾਏਦਾਰ ਦਾ ਰੂਟ ਗੁੰਮ ਹੋਵੇ, ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ: ਪ੍ਰੀਫਿਕਸ ਲਈ ਦੋ VPNv4 ਐਂਟਰੀਆਂ, ਹਰ ਇੱਕ 'ਤੇ ਸਹੀ ਰੂਟ ਟਾਰਗੇਟ, ਹੱਲ ਹੋਣ ਯੋਗ ਅਗਲਾ ਹੌਪ, ਅਤੇ ਉਹ ਲੇਬਲ ਜਿਸਦੀ ਸਥਿਤੀ ਪ੍ਰਾਪਤਕਰਤਾ PE ਕੋਲ ਹੈ। ਪਛਾਣ ਨੂੰ ਭੇਜਣ ਦੇ ਮੁੱਲ ਨਾਲ ਠੀਕ ਕਰਨਾ, ਜਾਂ ਉਲਟਾ, ਇੱਕ ਜਾਂਚ ਪਾਸ ਕਰੇਗਾ ਅਤੇ ਅਗਲੀ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਵੇਗਾ।