OTV ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਲੋੜੀਂਦਾ Ethernet ਸਮਝੌਤਾ ਲਿਖੋ

ਇੱਕ workload ਦੂਜੇ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ ਸੇਵਾ ਉੱਤੇ ਸਮਾਂ-ਸੀਮਾ ਵੱਟਣ ਲੱਗਦੀ ਹੈ ਜੋ ਪਹਿਲੇ ਤੋਂ ਠੀਕ ਜਵਾਬ ਦੇ ਰਹੀ ਸੀ। ਕੋਈ OTV ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਮੌਜੂਦਾ Layer 2 VPN «broadcast ਨਹੀਂ ਕਰਦਾ»। ਇਹ ਸਿੱਟਾ ਆਮ ਤੌਰ ’ਤੇ ਕਾਹਲੀ ਦਾ ਹੁੰਦਾ ਹੈ। ਸੇਵਾ ਦੀ ਸ਼੍ਰੇਣੀ ਅਤੇ ਤੁਹਾਡਾ ਖਰੀਦਿਆ ਖਾਸ ਸਮਝੌਤਾ ਦੋ ਵੱਖਰੇ ਸਵਾਲ ਹਨ, ਅਤੇ ਸਮਾਂ-ਸੀਮਾ ਵੱਟਣ ਦਾ ਕਾਰਨ ਅਜੇ ਕਿਸੇ ਨਾਲ ਜੋੜਿਆ ਨਹੀਂ ਗਿਆ।

ਉਹ ਲੱਛਣ ਜੋ ਤੁਲਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ

ਉਤਪਾਦਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਐਪ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਸਾਈਟਾਂ ਦੀ ਗਿਣਤੀ, VLAN ਦਾਇਰਾ, ਪਤਿਆਂ ਦੀ ਸਿੱਖਿਆ, flooding ਸਹਿਣਸ਼ੀਲਤਾ ਅਤੇ ਅਸਫਲਤਾ ਦਾ ਵਿਵਹਾਰ ਲੋੜ ਦੱਸਦੇ ਹਨ। «Layer 2» ਅਤੇ «OTV» ਆਰਕੀਟੈਕਚਰ ਦੱਸਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਪੰਨੇ ’ਤੇ ਪੰਜ ਗੁਣ ਕਿਸੇ ਵੀ ਵਿਕਰੇਤਾ ਤੁਲਨਾ ਤੋਂ ਵੱਧ ਚਿਰ ਰਹਿਣਗੇ।

ਫਿਰ ਜਾਂਚੋ ਕਿ ਮੌਜੂਦਾ ਸੇਵਾ ਉਹ ਪੰਜ ਗੁਣ ਪਹਿਲਾਂ ਹੀ ਪੂਰੇ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਸੰਭਾਲੀ Layer 2 VPN ਵਿੱਚ multipoint ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਕੰਟਰੋਲ-ਪਲੇਨ ਸਿੱਖਿਆ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸ ਦਾ ਇਨਵੌਇਸ ’ਤੇ ਇੱਕ ਨਜ਼ਰ ਨੇ ਜ਼ਿਕਰ ਨਹੀਂ ਕੀਤਾ।

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

ਲੇਬਲ ਤੁਹਾਨੂੰ ਕੀ ਨਹੀਂ ਦੱਸਦਾ

Layer 2 VPN ਇੱਕ ਸ਼੍ਰੇਣੀ ਹੈ, ਉਤਪਾਦ ਨਹੀਂ। ਪੌਇੰਟ-ਟੂ-ਪੌਇੰਟ VPWS ਅਤੇ multipoint VPLS ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਫਾਰਵਰਡ ਕਰਦੇ ਹਨ, ਅਤੇ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਕੰਟਰੋਲ-ਪਲੇਨ ਸਿੱਖਿਆ ਅਤੇ ਲੂਪ ਪ੍ਰਬੰਧਨ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਵੀ ਸ਼ਾਮਲ ਹਨ ਅਤੇ ਸਧਾਰਨ ਵੀ। ਇਹ ਮੰਨਣਾ ਕਿ ਹਰ Layer 2 VPN ਠੀਕ ਦੋ ਸਾਈਟਾਂ ਜੋੜਦਾ ਹੈ ਅਤੇ ਸਭ ਕੁਝ flood ਕਰਦਾ ਹੈ, ਗਲਤ ਤੁਲਨਾ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ। ਸਮਝੌਤੇ ’ਤੇ ਨਾਮ ਇਸਦੇ ਪਿੱਛੇ ਦੀ ਫਾਰਵਰਡਿੰਗ ਸਾਰਣੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

ਮੌਜੂਦਾ ਸੇਵਾ ਕਿਹੜਾ ਫਾਰਵਰਡਿੰਗ ਮਾਡਲ ਲਾਗੂ ਕਰਦੀ ਹੈ ਅਤੇ ਐਪ ਨੂੰ ਕਿਹੜਾ ਚਾਹੀਦਾ ਹੈ, ਪੁੱਛੋ। hub-and-spoke ਲੋੜ ਅਤੇ full-mesh ਲੋੜ ਦੋਵਾਂ ਨੂੰ Layer 2 ਕਹਿਣ ’ਤੇ ਵੀ ਵੱਖਰੇ ਡਿਜ਼ਾਈਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।

OTV ਆਪਣੀ ਹੱਦ ਕਿੱਥੇ ਖਿੱਚਦਾ ਹੈ

OTV IP ਟਰਾਂਸਪੋਰਟ ਉੱਤੇ ਚੱਲਦਾ ਹੈ, ਕੰਟਰੋਲ-ਪਲੇਨ MAC ਪਹੁੰਚ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ edge ਭੂਮਿਕਾਵਾਂ ਨਾਲ। ਸਥਾਨਕ spanning-tree ਜਾਣਕਾਰੀ ਸਥਾਨਕ ਰਹਿੰਦੀ ਹੈ, ਟਰਾਂਸਪੋਰਟ ਭਰ ਵਿੱਚ ਇੱਕ ਅਣ-ਨਿਯੰਤ੍ਰਿਤ ਡੋਮੇਨ ਵਜੋਂ ਫੈਲਾਉਣ ਦੀ ਥਾਂ। ਇਹ ਸਾਧਾਰਨ ਬ੍ਰਿਜਡ ਵਿਸਤਾਰ ਤੋਂ ਅਸਲ ਫ਼ਰਕ ਹੈ, ਅਤੇ ਲੋਕ ਇਸੇ ਕਾਰਨ ਇਸ ਵੱਲ ਝੁਕਦੇ ਹਨ।

ਹੱਦ ਲਾਭ ਜਿੰਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਅਣਜਾਣ unicast, broadcast ਅਤੇ multicast ਦੀ ਸੰਭਾਲ ਪਲੇਟਫਾਰਮ ਅਤੇ ਇਸਦੀ ਸੰਰਚਨਾ ’ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਅਤੇ edge ਜੋੜੀ ਨੂੰ ਸਮਰਥਿਤ multihoming ਵਿਧੀ ਰਾਹੀਂ ਸਹਿਯੋਗ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇੱਕੋ VLAN ਫਾਰਵਰਡ ਕਰਨ ਵਾਲੇ ਦੋ ਸੁਤੰਤਰ ਯੰਤਰ ਇੱਕੋ ਡਿਜ਼ਾਈਨ ਨਹੀਂ, ਅਤੇ ਉਹ ਵੱਖਰੀ ਅਸਫਲਤਾ ਸਥਿਤੀ ਪੈਦਾ ਕਰਦੇ ਹਨ।

Flooding ਘਟਦਾ ਹੈ, ਹਟਦਾ ਨਹੀਂ

ਕੁਝ ਗੈਰ-ਜ਼ਰੂਰੀ flooding ਦਬਾਉਣਾ ਇਸ ਗਾਰੰਟੀ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਕਿ ਕੋਈ broadcast ਜਾਂ multicast ਫ੍ਰੇਮ ਕਦੇ ਵਿਸਤਾਰ ਨੂੰ ਪਾਰ ਨਹੀਂ ਕਰੇਗਾ। ਇੱਕ ਸਾਈਟ ’ਤੇ ਸ਼ੁਰੂ ਹੋਇਆ ਤੂਫਾਨ ਅਜੇ ਵੀ ਟਰਾਂਸਪੋਰਟ ਖਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਟਰੈਫਿਕ ਸ਼੍ਰੇਣੀ ਫਿਲਟਰ ਕਰਨ ਵਾਲੀ ਪਲੇਟਫਾਰਮ ਸੁਵਿਧਾ ਬਾਕੀ ਨਹੀਂ ਫਿਲਟਰ ਕਰਦੀ। ਕਿਸੇ ਵੀ overlay ਨਾਲ ਨਿਰਾਸ਼ਾ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਇਸੇ ਫ਼ਰਕ ਤੋਂ ਆਉਂਦਾ ਹੈ।

ਇਸ ਲਈ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ OTV broadcast ਤੂਫਾਨ ਰੋਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਟਰੈਫਿਕ ਸ਼੍ਰੇਣੀਆਂ ਪਾਰ ਹੁੰਦੀਆਂ ਹਨ, ਕਿਨ੍ਹਾਂ ਹਾਲਤਾਂ ਵਿੱਚ, ਅਤੇ ਪਾਰ ਹੁੰਦਿਆਂ ਗਤੀ ਕੀ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।

ਉੱਥੇ ਹੁੰਦਿਆਂ underlay ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਸਮਰਥਿਤ ਡਿਲਿਵਰੀ, ਪੈਕਟ ਦਾ ਆਕਾਰ, ਰਾਊਟਿੰਗ ਅਤੇ ਚੁਣੀ ਰਿਲੀਜ਼ ਦੀ ਲੋੜੀਂਦੀ ਨੇੜਤਾ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ overlay ਨਾਲ ਮੁਫ਼ਤ ਨਹੀਂ ਆਉਂਦਾ, ਅਤੇ 1500 ਬਾਈਟ ਫ੍ਰੇਮ ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਵਾਲੀ ਟਨਲ ਆਪਣੇ ਆਪ ਤੁਹਾਡੇ ਟੈਗ ਕੀਤੇ ਫ੍ਰੇਮਾਂ ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਵਾਲੀ ਟਨਲ ਨਹੀਂ।

ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਮੰਗਣ ਵਾਲਾ ਸਮਝੌਤਾ

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

ਸਿਰਫ਼ ਉਸ ਲੋੜ ਲਈ ਬਦਲਾਅ ਚੁਣੋ ਜੋ ਮੌਜੂਦਾ ਸੇਵਾ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦੀ। VLAN ਨੂੰ ਹੋਰ ਵਧਾਉਣਾ ਐਪ ਅਤੇ Ethernet ਦੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਵੀ ਇਸਦੇ ਨਾਲ ਵਧਾਉਂਦਾ ਹੈ; ਨਵਾਂ overlay ਨਾਮ ਉਹ ਨਹੀਂ ਹਟਾਉਂਦਾ।

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