ਤੁਹਾਡਾ BGP ਸੈਸ਼ਨ VPC ਰੂਟ ਟੇਬਲ ਵਿੱਚ ਕਿਉਂ ਨਹੀਂ ਦਿਸਦਾ

ਜੋ ਕਹਾਣੀ ਵਾਰ-ਵਾਰ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ EC2 VPN ਐਪਲਾਇੰਸ 'ਤੇ ਰਾਊਟਿੰਗ ਡੈਮਨ BGP ਦੇ ਉੱਪਰ ਆਉਣ 'ਤੇ VPC ਨੂੰ ਇਸ ਦੇ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਸਿਖਾ ਦੇਵੇਗਾ। ਇਸ ਦਾ ਅੱਧਾ ਸੱਚ ਹੈ। ਸੈਸ਼ਨ ਉੱਪਰ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਕਾਰਨ VPC ਦੀ ਰੂਟ ਟੇਬਲ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਇਸ ਲਈ ਪਹਿਲਾ ਲੱਛਣ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਬਨੈੱਟ ਹੁੰਦਾ ਹੈ ਜੋ ਟ੍ਰੈਫਿਕ ਨੂੰ ਚੁੱਪਚਾਪ ਕਾਲੇ ਟੋਏ ਵਿੱਚ ਸੁੱਟ ਦਿੰਦਾ ਹੈ।

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

ਮਿੱਥ: BGP ਚਾਲੂ ਕਰੋ ਅਤੇ VPC ਪ੍ਰੀਫਿਕਸ ਸਿੱਖ ਲਵੇਗਾ

BGP ਦੋ ਬੁਲਾਰਿਆਂ ਵਿਚਕਾਰ ਗੱਲਬਾਤ ਹੈ, ਅਤੇ ਇਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਬੁਲਾਰੇ ਤੁਹਾਡੀ ਐਪਲਾਇੰਸ 'ਤੇ ਰਾਊਟਿੰਗ ਡੈਮਨ ਅਤੇ VPC Route Server ਦਾ ਇੱਕ ਐਂਡਪਾਇੰਟ ਹਨ ਜਿਸਨੂੰ AWS ਤੁਹਾਡੀ ਮਲਕੀਅਤ ਵਾਲੇ ਸਬਨੈੱਟ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਉਹ ਗੱਲਬਾਤ ਪ੍ਰੀਫਿਕਸ ਲੈ ਕੇ ਚੱਲਦੀ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਸਬਨੈੱਟਾਂ ਦੀ ਰੂਟ ਟੇਬਲ ਨੂੰ ਨਹੀਂ ਛੂਹਦੀ, ਕਿਉਂਕਿ ਉਹ ਟੇਬਲਾਂ ਸਿਰਫ਼ ਪ੍ਰਸਾਰ ਰਾਹੀਂ ਸਿੱਖਦੀਆਂ ਹਨ ਜੋ ਹਰ ਇੱਕ 'ਤੇ ਸਮਰੱਥ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜਦ ਤੱਕ ਇਹ ਨਹੀਂ ਹੁੰਦਾ, VPC ਦਾ ਤਾਣਾ-ਬਾਣਾ ਐਪਲਾਇੰਸ ਦੇ ਜਾਣਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਦਾ।

ਸੈਟਅੱਪ ਦੇ ਕਦਮ ਇੱਕ ਕਾਰਨ ਕਰਕੇ ਵੱਖਰੇ ਹਨ: ਜੋੜੋ, ਐਂਡਪਾਇੰਟ ਬਣਾਓ, ਪੀਅਰ ਕਰੋ, ਫਿਰ ਪ੍ਰਸਾਰ ਸਮਰੱਥ ਕਰੋ।

Route Server ਇੱਕ ਕੰਟਰੋਲ ਪਲੇਨ ਹੈ, ਸੁਰੰਗ ਨਹੀਂ

Route Server ਇੱਕ ਵੀ ਪੈਕਟ ਨੂੰ ਐਨਕ੍ਰਿਪਟ, ਫਾਰਵਰਡ ਜਾਂ ਜਾਂਚਦਾ ਨਹੀਂ। ਇਹ ਐਪਲਾਇੰਸ ਨਾਲ BGP ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਮਿਲੇ ਪ੍ਰੀਫਿਕਸ ਉਹਨਾਂ ਰੂਟ ਟੇਬਲਾਂ ਨੂੰ ਦੇਣ ਲਈ ਮੌਜੂਦ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਹਨ। ਡੇਟਾ ਪਲੇਨ ਨਹੀਂ ਬਦਲਿਆ: ਪੈਕਟ ਅਜੇ ਵੀ ਐਪਲਾਇੰਸ ਦੇ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ, ਇਸਦੇ VPN ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ ਅਤੇ ਉਸੇ ਰਾਹ ਵਾਪਸ ਆਉਂਦੇ ਹਨ।

ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫਾਰਵਰਡਿੰਗ ਇੰਸਟੈਂਸ 'ਤੇ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਦੀ ਜਾਂਚ ਅਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹੈ, ਕਿਉਂਕਿ ਇੰਸਟੈਂਸ ਹੁਣ ਕਿਸੇ ਹੋਰ ਨੂੰ ਸੰਬੋਧਿਤ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡ ਕਰ ਰਿਹਾ ਹੈ।

ਸੁਰੱਖਿਆ ਸਮੂਹ ਅਤੇ ਸਬਨੈੱਟ ਨਿਯੰਤਰਣ ਫਾਰਵਰਡ ਕੀਤੇ ਪ੍ਰਵਾਹ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। Route Server ਟ੍ਰੈਫਿਕ ਸੁੱਟਣ ਵਾਲੀ ਐਪਲਾਇੰਸ ਨੂੰ ਇਸਨੂੰ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰੇਗਾ, ਅਤੇ ਦੂਰਲੇ ਪਾਸੇ ਗੁੰਮ ਵਾਪਸੀ ਰੂਟ ਦੀ ਮੁਰੰਮਤ ਨਹੀਂ ਕਰੇਗਾ।

ਪ੍ਰਸਾਰ ਹਰ ਰੂਟ ਟੇਬਲ ਲਈ ਹੈ, ਪੂਰੇ VPC ਲਈ ਨਹੀਂ

ਰੂਟ ਸਰਵਰ ਨੂੰ VPC ਨਾਲ ਜੋੜਨਾ ਅਤੇ ਰੂਟ ਟੇਬਲ 'ਤੇ ਪ੍ਰਸਾਰ ਸਮਰੱਥ ਕਰਨਾ ਦੋ ਫੈਸਲੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਦੂਜਾ ਹੀ ਬਦਲਦਾ ਹੈ ਕਿ ਸਬਨੈੱਟ ਕੀ ਕਰਦਾ ਹੈ। ਛੇ ਰੂਟ ਟੇਬਲਾਂ ਵਾਲਾ VPC ਇੱਕ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਪ੍ਰੀਫਿਕਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਪੰਜ ਵਿੱਚ ਨਹੀਂ, ਜੋ ਹੱਬ ਸਬਨੈੱਟ ਲਈ ਬਿਲਕੁਲ ਸਹੀ ਹੈ ਅਤੇ ਬਿਲਕੁਲ ਇਹੀ «ਅੱਧਾ ਕੰਮ ਕਰਦਾ ਹੈ» ਵਾਲਾ ਉਲਝਾਉਣ ਵਾਲਾ ਨਤੀਜਾ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜਿੱਥੇ ਪ੍ਰਸਾਰ ਚਾਲੂ ਹੈ ਉੱਥੇ ਵੀ ਇੱਕ ਮੁਕਾਬਲੇ ਵਾਲਾ ਰੂਟ ਜਿੱਤ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ VPC ਦੀ ਰੂਟ ਚੋਣ ਸਭ ਤੋਂ ਲੰਬੇ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ ਅਤੇ ਬਰਾਬਰ ਲੰਬਾਈ 'ਤੇ ਪ੍ਰਸਾਰਿਤ ਨਾਲੋਂ ਸਥਿਰ ਰੂਟ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ। ਇਹ ਤਰਜੀਹ ਚੁੱਪਚਾਪ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।

ਐਪਲਾਇੰਸ ਜੋ ਪ੍ਰੀਫਿਕਸ ਐਲਾਨਦੀ ਹੈ ਉਹਨਾਂ ਦੀ ਸੂਚੀ ਦੀ ਬਜਾਏ ਖਾਸ ਸਬਨੈੱਟ ਦੀ ਪ੍ਰਭਾਵੀ ਟੇਬਲ ਦੀ ਜਾਂਚ ਕਰੋ। API ਇਸ ਸਵਾਲ ਦਾ ਸਿੱਧਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: aws ec2 associate-route-server ਅਤੇ aws ec2 enable-route-server-propagation --route-table-id <id> ਉਹ ਦੋ ਕਦਮ ਹਨ ਜੋ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ aws ec2 describe-route-tables --route-table-ids <id> ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰੀਫਿਕਸ route server ਐਂਟਰੀ ਵਜੋਂ ਆਇਆ ਵੀ ਜਾਂ ਨਹੀਂ।

ਐਪਲਾਇੰਸ ਅਜੇ ਵੀ ਹਰ ਪੈਕਟ ਢੋਂਦੀ ਹੈ

ਪਹੁੰਚ ਦਾ ਐਲਾਨ ਕਰਨਾ ਇਸਨੂੰ ਰੱਖਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ. BGP ਸੈਸ਼ਨ ਸਥਾਪਿਤ ਰਹਿ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਐਪਲਾਇੰਸ ਦਾ VPN ਬੰਦ ਹੋਵੇ, ਅਤੇ ਕਦੇ ਨਾ ਬਦਲਣ ਵਾਲਾ ਸਥਿਰ ਐਲਾਨ ਟ੍ਰੈਫਿਕ ਨੂੰ ਮਰੇ ਰਾਹ ਵੱਲ ਖਿੱਚਦਾ ਰਹਿੰਦਾ ਹੈ। Route Server BFD ਵਰਗੀ ਨਾਕਾਮੀ ਖੋਜ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਪਰ ਉਹ ਪੀਅਰ ਦੀ ਜੀਵੰਤਤਾ ਜਾਂਚਦੀ ਹੈ, ਪੀਅਰ ਦੇ ਪਿੱਛੇ ਹਰ ਚੀਜ਼ ਦੀ ਸਿਹਤ ਨਹੀਂ।

ਐਲਾਨ ਨੂੰ ਅਸਲ ਦੂਰਲੇ ਰੂਟ ਨਾਲ ਬੰਨ੍ਹੋ: ਜਦੋਂ ਸੁਰੰਗ ਅਤੇ ਦੂਰਲਾ ਨੈੱਟਵਰਕ ਚਾਲੂ ਹੋਣ ਤਾਂ ਪ੍ਰੀਫਿਕਸ ਦਾ ਐਲਾਨ ਕਰੋ, ਅਤੇ ਨਾ ਹੋਣ 'ਤੇ ਇਸਨੂੰ ਵਾਪਸ ਲਵੋ।

ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਵਾਪਸ ਲਵੋ ਅਤੇ ਦੇਖੋ ਕੀ ਹੁੰਦਾ ਹੈ

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

ਰੂਟ ਨੂੰ ਦੂਜੀ ਐਪਲਾਇੰਸ 'ਤੇ ਭੇਜਣ ਨਾਲ ਉਹ ਸੈਸ਼ਨ ਨਹੀਂ ਹੁੰਦੇ ਜੋ ਇਹ ਢੋਂਦੀ ਸੀ, ਕਿਉਂਕਿ NAT ਅਤੇ ਫਾਇਰਵਾਲ ਦੀ ਸਥਿਤੀ ਪਹਿਲੀ ਡਿਵਾਈਸ 'ਤੇ ਹੀ ਰਹਿੰਦੀ ਹੈ।

ਦਰਜਨ ਭਰ ਪ੍ਰੀਫਿਕਸ ਦੇ ਸਥਿਰ ਸੈੱਟ ਲਈ, VPC ਦੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਸਥਿਰ ਰੂਟ ਹੀ ਸਸਤਾ ਜਵਾਬ ਰਹਿੰਦੇ ਹਨ। Route Server ਆਪਣੀ ਥਾਂ ਤਦ ਕਮਾਉਂਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੀਫਿਕਸ ਸੂਚੀ ਸੱਚਮੁੱਚ ਬਦਲਦੀ ਹੈ ਅਤੇ ਵਾਪਸ ਲੈਣ ਦੀ ਨੀਤੀ ਅਜਿਹੀ ਚੀਜ਼ ਹੋਵੇ ਜੋ ਤੁਸੀਂ ਆਨ-ਕਾਲ ਵਿਅਕਤੀ ਨੂੰ ਸਮਝਾ ਸਕੋ।