ਸਾਈਟ ਦੇ ਅੰਦਰ ਇੱਕੋ iESI, ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਵਿਲੱਖਣ: Junos ਜੋੜ

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

ਦੋ ਖੇਤਰ, ਦੋ ਨਿਯਮ

ਸਾਈਟ ਦੇ ਅੰਦਰ, ਵਾਧੂ interconnect ਗੇਟਵੇ ਇੱਕ multihomed ਅੰਤ ਬਿੰਦੂ ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਇੱਕੋ interconnect ESI ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਦੇ peers ਨੂੰ ਦੋ ਸੁਤੰਤਰ ਦੀ ਥਾਂ ਇੱਕ ਤਾਰਕਿਕ ਮੈਂਬਰ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਾਂਝੇ ਮੁੱਲ ਦਾ ਪੂਰਾ ਅਰਥ ਇਹੀ ਹੈ।

ਸਾਈਟਾਂ ਵਿਚਕਾਰ, ਹਰ ਗੇਟਵੇ ਸਮੂਹ ਨੂੰ ਆਪਣਾ ਮੁੱਲ ਮਿਲਦਾ ਹੈ। ਇੱਕੋ ਪਛਾਣਕਰਤਾ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਦੋ ਡੇਟਾ ਸੈਂਟਰ ਕੰਟਰੋਲ ਪਲੇਨ ਵਿੱਚ ਇੱਕ multihomed ਸਮੂਹ ਬਣ ਜਾਂਦੇ ਹਨ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ WAN ਰਾਹੀਂ ਜੋੜ ਡਿਜ਼ਾਈਨ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਦੋ ਸਾਈਟਾਂ ਇੱਕ ਦੂਜੇ ਦੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਢੰਗ ਵੀ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦੀਆਂ ਹਨ।

ਸਾਈਟ ਦੇ ਅੰਦਰ: ਸਮੂਹ ਲਈ ਇੱਕ ਪਛਾਣ

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

ਸਮਰਥਿਤ ਮਾਡਲ all-active ਹੈ। ਉਹੀ ਹਵਾਲਾ ਇਸ ਜੋੜ ਪਛਾਣ ਲਈ single-active ਕਾਰਜ, ਆਪਣੇ-ਆਪ ਪ੍ਰਾਪਤ LACP ਪਛਾਣਕਰਤਾ ਅਤੇ source-bmac ਵਿਕਲਪ ਬਾਹਰ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੰਨ ਲੈਣ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਦੀ ਪਛਾਣਕਰਤਾ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮੁੜ ਸਮੀਖਿਆ ਲੋੜੀਂਦੀ ਹੈ। ਇਹ ਸੀਮਾ ਡਿਜ਼ਾਈਨ ਇਨਪੁਟ ਹੈ, ਫੁਟਨੋਟ ਨਹੀਂ।

ਸਾਈਟਾਂ ਵਿਚਕਾਰ: ਵੱਖਰੇ ਮੁੱਲ, ਜਾਂ ਜਾਣਬੁੱਝ ਕੇ ਰਲੇਵਾਂ

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

ਇੱਛਿਤ ਫ਼ਰਕ ਯੋਜਨਾ ਵਿੱਚ ਲਿਖੋ, ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਸਾਈਟ ਟੈਂਪਲੇਟ ਕਾਪੀ ਕਰਨ ਵਾਲਾ ਇੰਜੀਨੀਅਰ ਉਸ ਦੀ ਪਛਾਣਕਰਤਾ ਵੀ ਨਾਲ ਨਾ ਲਿਆਵੇ।

peer ਬਿਆਨ ਪਛਾਣ ਦਾ ਹਿੱਸਾ ਹੈ

ਸਮੂਹ ਦਾ ਹਰ ਗੇਟਵੇ ਆਪਣੇ ਸਥਾਨਕ peers ਨੂੰ loopback ਪਤੇ ਅਨੁਸਾਰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਸੰਬੰਧ ਵਿਅਕਤੀਗਤ MAC-VRF ਦੇ ਅੰਦਰ ਨਹੀਂ ਬਲਕਿ ਗਲੋਬਲ EVPN ਪੱਧਰ 'ਤੇ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਗਲਤ ਲੜੀ-ਕ੍ਰਮ ਵਿੱਚ ਰੱਖਣਾ commit ਹੋਣ ਵਾਲਾ ਪਰ ਕਦੇ ਸਮੂਹ ਨਾ ਬਣਾਉਣ ਵਾਲਾ ਕਨਫਿਗਰੇਸ਼ਨ ਬਣਾਉਣ ਦਾ ਆਮ ਤਰੀਕਾ ਹੈ। ਹਵਾਲਾ ਲੜੀ-ਕ੍ਰਮ ਇੱਕ ਵਾਰ ਪੜ੍ਹੋ, ਫਿਰ ਉਸ 'ਤੇ ਟਿਕੇ ਰਹੋ।

ਬਿਆਨ ਦਾ ਨਾਮ ਵੀ ਬਦਲਿਆ। Juniper ਨੇ 24.2R1 ਵਿੱਚ interconnect peer-gateways ਬਿਆਨ ਦਾ ਨਾਮ ਬਦਲਿਆ ਅਤੇ 24.4R1 ਵਿੱਚ ਡੇਟਾ ਸੈਂਟਰ interconnect ਲਈ interconnect-ਵਿਸ਼ੇਸ਼ ਰੂਪ ਬਹਾਲ ਕੀਤਾ। ਇਸ ਲਈ ਵਿਚਕਾਰਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਲਿਆ ਸਨਿੱਪਟ ਅਜਿਹਾ ਨਾਮ ਵਰਤ ਸਕਦਾ ਹੈ ਜੋ ਤੈਨਾਤ ਸੰਸਕਰਣ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ, ਜਾਂ ਉਲਟਾ ਵੀ। ਸਨਿੱਪਟ ਕਿਹੜੀ ਰਿਲੀਜ਼ ਤੋਂ ਆਇਆ ਇਹ ਸਨਿੱਪਟ ਦੇ ਕੋਲ ਹੀ ਦਰਜ ਕਰੋ।

iESI ਸਾਂਝਾ ਕਰਨਾ ਕੀ ਨਹੀਂ ਕਰਦਾ

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

ਇਹ peer ਪਹੁੰਚ ਜਾਂ designated forwarder ਦੀ ਚੋਣ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਆਮ ਸਥਿਤੀ ਵਿੱਚ unicast ਅਤੇ ਲੋੜੀਂਦੇ broadcast ਤੇ multicast ਵਿਵਹਾਰ ਦੀ ਪਰਖ ਕਰੋ, ਫਿਰ ਇੱਕ ਗੇਟਵੇ ਹਟਾ ਕੇ ਦੁਹਰਾਓ ਤਾਂ ਜੋ ਬਚਿਆ ਮੈਂਬਰ ਸਮੂਹ ਇਕੱਲਾ ਢੋਵੇ।

ਉਹੀ ਦੂਜਾ ਦੌਰ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਮੂਹ ਅਸਲੀ ਹੈ।

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