ਬ੍ਰਿਜ ਕੀਤੀਆਂ ਸਾਈਟਾਂ ਨੂੰ ਅਜੇ ਵੀ ਸਥਾਨਕ ਇੰਟਰਨੈਟ ਐਗਜ਼ਿਟ ਦਾ ਫੈਸਲਾ ਚਾਹੀਦਾ ਹੈ

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

ਬ੍ਰਿਜ ਫ੍ਰੇਮ ਢੋਂਦੀ ਹੈ, ਫੈਸਲੇ ਨਹੀਂ

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

ਉਸ ਸਾਂਝੇ ਸਬਨੈੱਟ ’ਤੇ ਦੋ ਰਾਊਟਰ ਰੱਖੋ ਅਤੇ ਦੋਵੇਂ ਸੰਭਾਵੀ ਗੇਟਵੇ ਬਣ ਜਾਂਦੇ ਹਨ, ਭਾਵੇਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਕਲਾਇੰਟ ਦੇ ਨੇੜੇ ਹੋਵੇ ਜੋ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ ਜਾਂ ਨਾ।

ਕਲਾਇੰਟ ਆਪਣਾ ਗੇਟਵੇ ਕਿਵੇਂ ਚੁਣਦਾ ਹੈ

RFC 1122 ਵਿੱਚ ਦਰਸਾਇਆ IPv4 ਫੈਸਲਾ ਸਰਲ ਹੈ। ਕਲਾਇੰਟ ਦੇ ਜੁੜੇ ਸਬਨੈੱਟ ਦੇ ਅੰਦਰਲਾ ਗੰਤਵਯ ਸਿੱਧਾ ARP ਨਾਲ ਪਹੁੰਚਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਬਾਹਰਲਾ ਗੰਤਵਯ ਸੰਰਚਿਤ ਡਿਫਾਲਟ ਗੇਟਵੇ ’ਤੇ ਜਾਂਦਾ ਹੈ। ਇਸੇ ਲਈ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਉਸੇ ਸਬਨੈੱਟ ਦਾ ਟ੍ਰੈਫਿਕ ਕਿਸੇ ਰਾਊਟਰ ਦੀ ਭਾਗੀਦਾਰੀ ਤੋਂ ਬਿਨਾਂ ਬ੍ਰਿਜ ਪਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਇੰਟਰਨੈਟ ਟ੍ਰੈਫਿਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਉਸ ਗੇਟਵੇ ਪਤੇ ’ਤੇ ਨਿਰਭਰ ਹੈ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਮਿਲਿਆ। ਦੋਵੇਂ ਵਿਵਹਾਰ ਸੁਤੰਤਰ ਹਨ, ਅਤੇ ਕੰਮ ਕਰਦੀ ਫਾਈਲ ਸ਼ੇਅਰਿੰਗ ਸਿਰਫ਼ ਪਹਿਲਾ ਸਾਬਤ ਕਰਦੀ ਹੈ।

ਜੇ ਛੋਟੀ ਸਾਈਟ ਦਾ ਕਲਾਇੰਟ ਵੱਡੀ ਸਾਈਟ ਦੇ ਰਾਊਟਰ ਨਾਲ ਸੰਰਚਿਤ ਸੀ, ਤਾਂ ਉਸ ਦੇ ਇੰਟਰਨੈਟ ਫ੍ਰੇਮ ਪਹਿਲਾਂ ਟਨਲ ਪਾਰ ਕਰਦੇ ਹਨ ਅਤੇ ਉੱਥੋਂ ਬਾਹਰ ਨਿਕਲਦੇ ਹਨ।

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

DHCP ਨੂੰ ਮਨਸ਼ਾ ਕੀਤੀ ਐਗਜ਼ਿਟ ਪ੍ਰਗਟ ਕਰਨ ਦਿਓ

DHCP ਜਵਾਬ ਵਿੱਚ ਵਿਕਲਪ 3 ਕਲਾਇੰਟ ਦੇ ਸਬਨੈੱਟ ’ਤੇ ਰਾਊਟਰ ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਤਰਜੀਹ ਕ੍ਰਮ ਵਿੱਚ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਆਮ ਤੌਰ ’ਤੇ ਪਹਿਲਾ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਲੈਂਦੇ ਹਨ। ਕਾਰਜਵਿਧੀ ਠੀਕ ਹੈ; ਮਾਲਕੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਡਿਜ਼ਾਈਨ ਗੜਬੜਾਉਂਦੇ ਹਨ। ਨੇੜਲਾ DHCP ਸਰਵਰ ਨੇੜਲਾ ਗੇਟਵੇ ਦੇਵੇਗਾ ਮੰਨਣ ਦੀ ਬਜਾਏ ਹਰ ਸਾਈਟ ’ਤੇ ਦਰਜ ਕਰੋ ਕਿ ਅਸਲ ਲੀਜ਼ ਕੀ ਦਿੰਦੀ ਹੈ।

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

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

ਚਾਰ ਚੀਜ਼ਾਂ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੋ

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

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

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