all-active EVPN ਉੱਤੇ Linux ਦਾ ਸਰਗਰਮ-ਬੈਕਅੱਪ ਬਾਂਡ: ਕੀ ਟੁੱਟਦਾ ਹੈ

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

ਸਰਗਰਮ-ਬੈਕਅੱਪ ਆਉਂਦੇ ਫ਼ਰੇਮ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ

ਬਾਂਡਿੰਗ ਮੋਡ 1 ਭੇਜਣ ਦੇ ਰਾਹ ਵਿੱਚ ਠੀਕ ਇੱਕ ਸਲੇਵ ਰੱਖਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਫੇਲ੍ਹ ਹੋਣ ’ਤੇ ਹੀ ਉਸਨੂੰ ਬਦਲਦਾ ਹੈ। ਉਹ ਹਿੱਸਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਾਪਤੀ ਵਾਲਾ ਪਾਸਾ ਹੈ: ਕਰਨਲ ਫ਼ਰੇਮ ਸਟੈਕ ਨੂੰ ਸਿਰਫ਼ ਤਦ ਹੀ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਸਰਗਰਮ ਸਲੇਵ ’ਤੇ ਆਵੇ, ਅਤੇ ਕਿਸੇ ਹੋਰ ਸਲੇਵ ’ਤੇ ਦਿਖਣ ਵਾਲੇ ਫ਼ਰੇਮ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਇਹ all_slaves_active ਸੈਟਿੰਗ ਉਸੇ ਨਿਯਮ ਨੂੰ ਢਿੱਲਾ ਕਰਨ ਲਈ ਹੀ ਹੈ, ਅਤੇ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਇਹ ਬੰਦ ਹੈ। ip -d link show bond0 ਮੋਡ ਦੇ ਕੋਲ ਮੌਜੂਦਾ ਮੁੱਲ ਛਾਪਦਾ ਹੈ।

/proc/net/bonding/bond0 ਸਰਗਰਮ ਸਲੇਵ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ ਅਤੇ ਹਰ ਸਲੇਵ ਲਈ ਲਿੰਕ ਸਥਿਤੀ ਦੱਸਦਾ ਹੈ। ਕਿਹੜਾ ਪੋਰਟ ਹੁਣ ਟਰੈਫ਼ਿਕ ਢੋ ਰਿਹਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਫ਼ਾਈਲ ਹੀ ਇੱਕੋ-ਇੱਕ ਇਮਾਨਦਾਰ ਸਰੋਤ ਹੈ।

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

all-active ਮਲਟੀਹੋਮਿੰਗ ਦੂਰ ਦੇ ਅਗਲੇ ਹੌਪ ਨਾਲ ਕੀ ਕਰਦੀ ਹੈ

EVPN ਮਲਟੀਹੋਮਿੰਗ ESI ਨਾਲ ਪਛਾਣੇ ਜਾਂਦੇ ਇੱਕ ਈਥਰਨੈੱਟ ਸੈਗਮੈਂਟ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਵਾਲੀਆਂ ਲੀਫ਼ਾਂ ਦਾ ਸਮੂਹ ਬਿਆਨ ਕਰਦੀ ਹੈ ਅਤੇ ਉਹ ਸੈਗਮੈਂਟ ਬਾਕੀ ਫੈਬਰਿਕ ਨੂੰ ਐਲਾਨਦੀ ਹੈ। all-active ਮਾਡਲ ਵਿੱਚ ਦੂਰ ਦੇ ਪੀਅਰ ਸੈਗਮੈਂਟ ਦੇ ਪਤਿਆਂ ਲਈ ਇੱਕ ਤੋਂ ਵੱਧ ਅਗਲੇ ਹੌਪ ਸਥਾਪਤ ਕਰਦੇ ਹਨ। ਸਰਵਰ ਵੱਲ ਯੂਨੀਕਾਸਟ ਫਿਰ ਕਿਸੇ ਵੀ ਲੀਫ਼ ’ਤੇ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਫੈਬਰਿਕ ਹਰ ਫ਼ਲੋ ਲਈ ਖੁੱਲ੍ਹ ਕੇ ਚੁਣ ਸਕਦੀ ਹੈ। ਇਹੀ ਡਿਜ਼ਾਈਨ ਦਾ ਪੂਰਾ ਮਕਸਦ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਧਾਰਨਾ ਵੀ ਹੈ ਜੋ ਸਰਵਰ ਦੇ ਬਾਂਡ ਨੂੰ ਪੂਰੀ ਕਰਨੀ ਹੈ।

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

ਜਿੱਥੇ ਦੋਵੇਂ ਚੋਣਾਂ ਅਸਹਿਮਤ ਹੁੰਦੀਆਂ ਹਨ

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

ਦੋ ਸਮਰਥਿਤ ਰਾਹ ਹਨ, ਅਤੇ ਉਹ ਇੱਕ-ਦੂਜੇ ਦੇ ਬਦਲ ਨਹੀਂ। ਹੋਸਟ ਨੂੰ ਉਹ ਬਾਂਡ ਦਿਓ ਜਿਸਨੂੰ ਫੈਬਰਿਕ ਇੱਕ ਤਾਰਕਿਕ ਜੋੜ ਵਜੋਂ ਵੇਖ ਸਕੇ, ਜਿਸਦਾ ਵਿਵਹਾਰ ਵਿੱਚ ਅਰਥ ਲੀਫ਼ਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕੀਤਾ LACP ਬਾਂਡ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਲਿੰਕ ਸੱਚਮੁੱਚ ਇਕੱਠੇ ਸਰਗਰਮ ਹੁੰਦੇ ਹਨ। ਜਾਂ ਫੈਬਰਿਕ ਤੋਂ ਸਿੰਗਲ-ਸਰਗਰਮ ਡਿਲੀਵਰੀ ਵੀ ਸਵੀਕਾਰੋ, ਤਾਂ ਜੋ ਸੈਗਮੈਂਟ ਬਾਂਡ ਵਾਂਗ ਹੀ ਇੱਕ-ਪੋਰਟ-ਇੱਕ-ਵਾਰ ਵਾਲਾ ਮਾਡਲ ਅਪਣਾਏ। ਜੋ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ ਸਿਰਫ਼ ਇੱਕ ਪੋਰਟ ’ਤੇ ਸੁਣਨ ਵਾਲੇ ਬਾਂਡ ਅੱਗੇ all-active ਸੈਗਮੈਂਟ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਨਿਸ਼ਕ੍ਰਿਯ ਸਲੇਵਾਂ ’ਤੇ ਪ੍ਰਾਪਤੀ ਚਾਲੂ ਨਾ ਕਰੋ ਅਤੇ ਉਸ ਮਗਰੋਂ ਆਉਣ ਵਾਲੀ ਦੋਹਰੀ ਡਿਲੀਵਰੀ ਸਵੀਕਾਰ ਨਾ ਕਰੋ।

ਬੈਕਅੱਪ ਕੇਬਲ ਸਿਹਤਮੰਦ ਕਿਉਂ ਦਿਖਦੀ ਰਹਿੰਦੀ ਹੈ

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

ਇਸਦੀ ਥਾਂ ਪੁੱਛੋ ਕਿ ਵਾਪਸੀ ਫ਼ਰੇਮ ਨੇ ਕਿਹੜਾ ਭੌਤਿਕ ਪੋਰਟ ਵਰਤਿਆ। ਹੋਸਟ ’ਤੇ, ਬਾਂਡ ਪ੍ਰਤੀ ਨਹੀਂ ਸਗੋਂ ਸਲੇਵ ਪ੍ਰਤੀ ਪ੍ਰਾਪਤ ਪੈਕਟ ਗਿਣੋ, ਕਿਉਂਕਿ ਬਾਂਡ ਕਾਊਂਟਰ ਅਸਮਾਨਤਾ ਲੁਕਾਉਂਦਾ ਹੈ। ਲੀਫ਼ ’ਤੇ, ਵੇਖੋ ਸਰਵਰ ਦੇ MAC ਲਈ ਬ੍ਰਿਜ ਫ਼ਾਰਵਰਡਿੰਗ ਐਂਟਰੀਆਂ ਅਤੇ EVPN ਰੂਟ ਜੋ ਅਗਲੇ-ਹੌਪ ਸਮੂਹ ਢੋਂਦਾ ਹੈ। ਜੇ ਐਂਟਰੀ ਉਸ ਲੀਫ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ ਜਿਸਦਾ ਹੋਸਟ ਲਿੰਕ ਸਟੈਂਡਬਾਏ ਹੈ, ਤਾਂ ਡਿਜ਼ਾਈਨ ਉਸ ਪੋਰਟ ਵਿੱਚ ਡਿਲੀਵਰ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸਨੂੰ ਹੋਸਟ ਅਣਡਿੱਠ ਕਰਦਾ ਹੈ। ਇਹ ਹਾਰਡਵੇਅਰ ਖ਼ਰਾਬੀ ਨਹੀਂ ਸਗੋਂ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਦੀ ਅਸੰਗਤੀ ਹੈ, ਅਤੇ ਲਿੰਕ-ਸਥਿਤੀ ਦੀ ਕਿੰਨੀ ਵੀ ਨਿਗਰਾਨੀ ਇਸਨੂੰ ਉਜਾਗਰ ਨਹੀਂ ਕਰੇਗੀ।

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਡਿਲੀਵਰੀ ਜਾਂਚੋ, ਲਿੰਕ ਸਥਿਤੀ ਨਹੀਂ

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

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

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