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

1. ਤੈਅ ਕਰੋ ਕਿ ਲਿੰਕ ਨੂੰ ਕੀ ਲੈ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

2. ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲੀ ਪਛਾਣ ਦੀ ਹੱਦ ਤੈਅ ਕਰੋ

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

ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਹੱਬ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਕਿਹੜੇ ਦੂਰ ਦੇ ਹੱਬ ਵਿੱਚ ਜੁੜਦਾ ਹੈ ਅਤੇ ਦੂਰ ਦੀ ਪਛਾਣ ਕਿੱਥੋਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ। ਵਚਨਬੱਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਆਰਕੀਟੈਕਚਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ:

RequirementRouted pathCascaded segment
Broadcast domainSeparate on each sideShared across the link
Address serviceOne DHCP server per sideMust not run two on one domain
Loop riskRoute loops onlyLayer-two loops if segments overlap

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

3. ਦੇਖੋ ਹੱਬ ਪਹਿਲਾਂ ਹੀ ਕੀ ਲੈ ਜਾਂਦਾ ਹੈ

ਹੱਬ ਘੱਟ ਹੀ ਅਲੱਗ ਹੁੰਦਾ ਹੈ। ਇਹ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਭੌਤਿਕ ਐਡਾਪਟਰ ਨਾਲ ਬ੍ਰਿਜ ਕਰ ਸਕਦਾ ਹੈ, ਵਰਚੁਅਲ ਰਾਊਟਰ ਰਾਹੀਂ ਰਾਊਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਕਿਤੇ ਹੋਰ ਕੈਸਕੇਡ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਜੁੜਾਅ ਨਵੇਂ ਸੰਬੰਧ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। ਇਸੇ ਲਈ «ਅਸੀਂ ਸਿਰਫ਼ ਦੋ ਹੱਬ ਜੋੜੇ» ਅਕਸਰ «ਇਹ ਦੋ ਸਾਈਟਾਂ ਹੁਣ ਇੱਕੋ ਹਿੱਸਾ ਕਿਉਂ ਹਨ» ਬਣ ਜਾਂਦਾ ਹੈ।

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

ਸਿਰਫ਼ ਇੱਕ ਰਸਤਾ ਨਾ ਹੋਣ ਕਾਰਨ ਲਿੰਕ ਨਾ ਜੋੜੋ; ਰਸਤਾ ਠੀਕ ਕਰੋ। ਪਹਿਲਾਂ ਕਾਗਜ਼ ਉੱਤੇ ਟੋਪੋਲੋਜੀ ਬਣਾਓ, ਹਰ ਬ੍ਰਿਜ ਅਤੇ ਕੈਸਕੇਡ ਸਮੇਤ, ਕਿਉਂਕਿ ਚਿੱਤਰ ਦੋ ਮਿੰਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਬਹੁਤੇ ਲੂਪ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੜ ਲੈਂਦਾ ਹੈ।

4. ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਸੰਭਾਲੋ

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

DNS ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਹੈ। ਕੈਸਕੇਡ ਫ੍ਰੇਮ ਲੈ ਜਾਂਦਾ ਹੈ; ਇਹ ਰਿਜ਼ੌਲਵਰ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਸਥਾਨਕ ਪਾਸੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਨਾਮ ਲਿੰਕ ਪਾਰ ਨਾ ਹੱਲ ਹੋ ਸਕਦਾ ਹੈ। ਲੁੱਕਅਪ ਨੂੰ IP ਰਸਤੇ ਤੋਂ ਵੱਖਰਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਚੱਲਦਾ ping ਦੋਵਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਸਾਬਤ ਕਰਦਾ ਹੈ।

5. ਅਸਲ ਸਰੋਤ ਨਾਲ ਸਾਬਤ ਕਰੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ