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

ਮਕੈਨਿਜ਼ਮ ਨੂੰ ਸੈਸ਼ਨ ਕਿਸਮ ਨਾਲ ਮਿਲਾਓ

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

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

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

ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਉਦਾਹਰਨ ਗਿਣੋ

ਮੰਨ ਲਓ ਤਿੰਨ ਗੇਟਵੇ ਤੁਹਾਡੇ ਮਨਜ਼ੂਰ ਕੀਤੇ ਭਾਰ ਹੇਠ 800 ਇੱਕੋ ਸਮੇਂ ਟਨਲ 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਹਨ, ਜੋ ਕੁੱਲ 2,400 ਹੈ। ਵਿਅਸਤ ਘੰਟੇ ਦਾ 1,650 ਟੀਚਾ ਆਰਾਮਦਾਇਕ ਲੱਗਦਾ ਹੈ ਜਦ ਤੱਕ ਇੱਕ ਇਕਾਈ ਨਹੀਂ ਗੁੰਮਦੀ, ਅਤੇ ਫਿਰ ਬਚੀ ਜੋੜੀ ਨੂੰ ਸਖ਼ਤ 1,600 ਦੇ ਸਾਮ੍ਹਣੇ 1,650 ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਡਿਜ਼ਾਈਨ ਪਹਿਲਾਂ ਹੀ ਫੇਲ੍ਹ ਹੋ ਚੁੱਕਾ ਹੈ, ਅਤੇ ਫੇਲਓਵਰ ਦੀ ਕੋਈ ਟਿਊਨਿੰਗ ਗਣਿਤ ਸੁਧਾਰਦੀ ਨਹੀਂ।

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

ਸਿਰਫ਼ ਸਥਿਰ ਹਾਲਤ ਨਹੀਂ, ਦੁਬਾਰਾ ਜੁੜਨ ਦੀ ਲਹਿਰ ਦਾ ਬਜਟ ਵੀ ਰੱਖੋ

ਫੇਲ੍ਹ ਹੋਏ ਮੈਂਬਰ ਦੇ ਸੈਸ਼ਨ ਚੁੱਪਚਾਪ ਕਿਤੇ ਹੋਰ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦੇ। ਮਕੈਨਿਜ਼ਮ ਅਨੁਸਾਰ ਉਹ ਸਥਿਤੀ ਨਾਲ ਤਬਦੀਲ ਹੁੰਦੇ ਹਨ, ਜ਼ੀਰੋ ਤੋਂ ਦੁਬਾਰਾ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ, ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੇ ਸ਼ਡਿਊਲ ਅਨੁਸਾਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਨ।

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

ਪੂਲ ਅਤੇ ਰਸਤੇ ਨਾਲ ਸਮਰੱਥਾ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

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

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

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

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

ਸੰਬੰਧਿਤ ਲੇਖ