AWS VGW ਸਬਨੈੱਟ ਰੂਟ ਇੱਕ VPN ਟਨਲ ਕਿਉਂ ਨਹੀਂ ਚੁਣ ਸਕਦਾ

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

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

ਇੱਕੋ ਵਰਗੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਦੋ ਪਰਤਾਂ

ਸਬਨੈੱਟ ਰੂਟ ਇੱਕੋ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਇਸ ਮੰਤਵ ਲਈ ਕਿਹੜਾ ਅਟੈਚਮੈਂਟ? ਇਸਦਾ ਨਿਸ਼ਾਨਾ ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਗੇਟਵੇ ਹੈ, ਅਤੇ ਇਸਦਾ ਮੈਟ੍ਰਿਕ ਸਿਰਫ਼ ਉਸੇ ਟੇਬਲ ਦੇ ਹੋਰ ਰੂਟਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ। ਉਸ ਐਂਟਰੀ ਵਿੱਚ ਟਨਲ ਇੱਕ ਨੂੰ ਟਨਲ ਦੋ ਤੋਂ ਜਾਂ ਕਨੈਕਸ਼ਨ A ਨੂੰ ਕਨੈਕਸ਼ਨ B ਤੋਂ ਵੱਖ ਕਰਨ ਵਾਲਾ ਕੁਝ ਨਹੀਂ। ਵਧੇਰੇ ਖ਼ਾਸ ਪ੍ਰੀਫਿਕਸ ਦੂਜੀ ਮੰਤਵ ਮੇਲ ਹੈ, ਬਾਰੀਕ ਮਾਰਗ ਚੋਣ ਨਹੀਂ।

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

VGW ਅਸਲ ਵਿੱਚ ਕੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ

ਸਿਹਤ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ। ਡਾਊਨ ਟਨਲ, ਜਾਂ ਨਾ ਉੱਠਿਆ BGP ਸੈਸ਼ਨ, ਕਿਸੇ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਹਾਰ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਪਹਿਲਾਂ ਹੀ ਫੇਲ੍ਹ ਹੋ ਰਹੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਮਾਰਗ ਅੱਗੇ ਜੋੜਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

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

ਅੱਗੇ ਜੋੜਨਾ, ਅਤੇ ਜਦੋਂ ਇਹ ਕੁਝ ਨਹੀਂ ਕਰਦਾ

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

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ AWS ਪਾਸੇ ਪ੍ਰਾਪਤ ਮਾਰਗ ਦੀ ਜਾਂਚ ਕਰੋ। ਗਾਹਕ ਡਿਵਾਈਸ ਕਦੇ ਨਾ ਛੱਡਿਆ ਅੱਗੇ ਜੋੜਨਾ AWS ਵੱਲੋਂ ਅਣਡਿੱਠ ਕੀਤੇ ਜੋੜਨ ਵਰਗਾ ਹੀ ਦਿਸਦਾ ਹੈ।

ਸਥਿਰ ਰੂਟ ਪੂਰੀ ਦਲੀਲ ਨੂੰ ਅਣਡਿੱਠ ਕਰਦੇ ਹਨ

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

ਇੱਕੋ ਪ੍ਰੀਫਿਕਸ ਦਾ ਐਲਾਨ ਕਰਨ ਵਾਲੇ ਦੋ ਸਥਿਰ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ ਲਾਹੇਵੰਦ ਲੀਵਰ ਪ੍ਰੀਫਿਕਸ ਹੈ: ਜਿਸ ਕਨੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੈ ਉਸ 'ਤੇ ਵਧੇਰੇ ਖ਼ਾਸ ਰੇਂਜ ਦਾ ਐਲਾਨ ਕਰੋ, ਅਤੇ ਮੰਨੋ ਕਿ ਤੁਸੀਂ ਇਹ ਬਦਲਿਆ ਹੈ ਕਿ ਕਿਹੜਾ ਮੰਤਵ ਮਿਲਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਮਾਰਗ ਜਿੱਤਦਾ ਹੈ।

ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਵੱਖਰਾ ਜਵਾਬ ਕਿਉਂ ਹੈ

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

ਵਿਧੀ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲ ਚੁਣੋ: ਨਿਸ਼ਚਿਤ ਤਰਜੀਹ ਨਾਲ ਸਰਗਰਮ ਅਤੇ ਸਟੈਂਡਬਾਏ, ਜਾਂ ECMP ਨਾਲ ਸਰਗਰਮ ਅਤੇ ਸਰਗਰਮ।

ਸੈੱਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕੀ ਪੜਤਾਲਣਾ ਹੈ

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

ਫਿਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫੇਲਓਵਰ ਟੈਸਟ ਚਲਾਓ ਅਤੇ ਵੇਖੋ ਕਿ ਬਚਿਆ ਮਾਰਗ ਸੇਵਾ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। ਸਿਰਫ਼ ਸੰਰਚਨਾ ਫ਼ਰਕ ਵਿੱਚ ਮੌਜੂਦ ਤਰਜੀਹ ਅਜੇ ਤਰਜੀਹ ਨਹੀਂ ਹੈ।