VPN ਉੱਤੇ BGP ਤੁਹਾਡੇ ਅੰਡਰਲੇ ਰਾਹ ਨੂੰ ਕਿਉਂ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦਾ
VPN ਉੱਤੇ BGP ਪਹੁੰਚਯੋਗਤਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਰੂਟ ਨੀਤੀ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਪਰ ਅੰਡਰਲੇ ਅਜੇ ਵੀ ਬਾਹਰੀ ਰਾਹ ਚੁਣਦਾ ਹੈ। ਸੈਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ।
ਦੋ ਸਾਈਟਾਂ IPsec ਸੁਰੰਗ ਉੱਤੇ BGP ਪੀਅਰ ਕਰਦੀਆਂ ਹਨ, ਇੱਕ-ਦੂਜੇ ਦੇ ਪ੍ਰੀਫਿਕਸ ਸਿੱਖਦੀਆਂ ਹਨ, ਅਤੇ ਡਾਇਗ੍ਰਾਮ ਨੂੰ ਰਾਹ ਨਿਯੰਤਰਣ ਵਜੋਂ ਮੁੜ ਲੇਬਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਲੇਬਲ ਉਲਝਣ ਦੀ ਸ਼ੁਰੂਆਤ ਹੈ। ਸੈਸ਼ਨ ਪਹੁੰਚਯੋਗਤਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਨੀਤੀ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਪਰ ਕਿਹੜਾ ਪ੍ਰਦਾਤਾ, ਕੇਬਲ ਜਾਂ ਰਾਊਟਰ ਐਨਕ੍ਰਿਪਟਿਡ ਪੈਕਟ ਢੋਂਦਾ ਹੈ, ਇਸ ਬਾਰੇ ਇਸ ਦੀ ਕੋਈ ਆਵਾਜ਼ ਨਹੀਂ। ਮੈਂ ਇੱਕ ਟੀਮ ਨੂੰ ਕੰਮ ਕਰਦੀ ਸੁਰੰਗ ਮੁੜ ਬਣਾਉਂਦੇ ਦੇਖਿਆ ਹੈ, ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਉਮੀਦ ਸੀ ਕਿ BGP ਰੂਟ ਬਦਲਾਅ ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਜਿਹੇ ਦੂਜੇ ਫਾਈਬਰ ਰਾਹ ਉੱਤੇ ਲੈ ਜਾਵੇਗਾ ਜਿਸ ਨੂੰ ਸੈਸ਼ਨ ਕਦੇ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ।
ਲੋਕ ਕੀ ਮੰਨਦੇ ਹਨ ਕਿ ਸੈਸ਼ਨ ਕੀ ਖਰੀਦਦਾ ਹੈ
ਬਹੁਤੀ ਉਮੀਦ ਇਸ ਗੱਲ ਤੋਂ ਆਉਂਦੀ ਹੈ ਕਿ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਵਿੱਚ ਰੂਟ ਬਦਲਾਅ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ। ਤੁਸੀਂ ਸੁਰੰਗ ਉੱਤੇ ਪ੍ਰੀਫਿਕਸ ਦਾ ਐਲਾਨ ਕਰਦੇ ਹੋ, ਦੂਰ ਦਾ ਪਾਸਾ ਉਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਹਿਲਦਾ ਹੈ। ਇਹੀ ਕ੍ਰਮ ਉਸ ਰਾਊਟਰ ਉੱਤੇ ਵੀ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸੱਚਮੁੱਚ ਟ੍ਰੈਫਿਕ-ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਨਿਯੰਤਰਣ ਹਨ, ਇਸ ਲਈ ਦੋਵੇਂ ਰਲ-ਗਿਲ ਜਾਂਦੇ ਹਨ। ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਵਿੱਚ ਦੋਵੇਂ ਸਾਈਟਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਇੱਕੋ ਪਹੁੰਚ ਲਿੰਕ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਫ਼ਰਕ ਉੱਥੇ ਕਦੇ ਨਹੀਂ ਦਿਸਦਾ।
BGP ਪਹੁੰਚਯੋਗਤਾ ਦਾ ਪ੍ਰੋਟੋਕਾਲ ਹੈ। ਇਹ ਪੀਅਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪ੍ਰੀਫਿਕਸ ਲਈ ਪੈਕਟ ਪਹੁੰਚਾ ਸਕਦੇ ਹੋ ਅਤੇ ਹਰ ਪਾਸੇ ਨੂੰ ਮਿਲਣ ਵਾਲੀਆਂ ਪੇਸ਼ਕਸ਼ਾਂ ਦਾ ਕ੍ਰਮ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ। ਇਹ ਸੁਰੰਗ ਉੱਤੇ ਸੱਚਮੁੱਚ ਲਾਭਦਾਇਕ ਹੈ: ਸਾਈਟਾਂ ਦੇ ਆਉਣ-ਜਾਣ ਨਾਲ ਪ੍ਰੀਫਿਕਸ ਦਿਸਦੇ ਅਤੇ ਗ਼ਾਇਬ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਹਰ ਐਜ ਡਿਵਾਈਸ ਉੱਤੇ ਸਥਿਰ ਰੂਟ ਲਿਖੇ ਬਿਨਾਂ ਰੇਂਜ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ। ਜੋ ਇਹ ਨਹੀਂ ਕਰਦਾ, ਉਹ ਹੈ ਪ੍ਰਦਾਤਾ ਦੇ ਰਾਊਟਰਾਂ ਨੂੰ ਤੁਹਾਡੇ ਨਿਯੰਤਰਣ ਹੇਠ ਲਿਆਉਣਾ।
ਅੰਡਰਲੇ ਬਾਹਰੀ ਹੈਡਰ ਢੋਂਦਾ ਹੈ। ਤੁਹਾਡਾ ਸੁਰੰਗ ਐਂਡਪੌਇੰਟ ਐਨਕ੍ਰਿਪਟਿਡ ਪੈਕਟ ਪੀਅਰ ਪਤੇ ਉੱਤੇ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੋ ਪਤਿਆਂ ਵਿਚਕਾਰਲਾ ਨੈੱਟਵਰਕ ਉਨ੍ਹਾਂ ਨੂੰ ਉਸ ਦੇ ਆਪਰੇਟਰਾਂ ਵੱਲੋਂ ਸਥਾਪਿਤ ਰੂਟਾਂ ਰਾਹੀਂ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। BGP ਸੈਸ਼ਨ ਵਿੱਚ ਕੁਝ ਵੀ ਉਸ ਫ਼ੈਸਲੇ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ, ਜਦ ਤੱਕ ਉਹੀ ਪ੍ਰਦਾਤਾ ਅਜਿਹੀ ਸਮਰਥਿਤ ਸੇਵਾ ਨਾ ਦੇਵੇ ਜੋ ਅਜਿਹਾ ਕਰਦੀ ਹੋਵੇ।
ਸੈਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਢੋਂਦਾ ਹੈ
BGP ਬੁਲਾਰਾ ਆਪਣੇ ਪੀਅਰ ਦੇ 179 ਪੋਰਟ ਉੱਤੇ TCP ਸੰਬੰਧ ਖੋਲ੍ਹਦਾ ਹੈ, RFC 4271 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਸੁਨੇਹਾ ਫਾਰਮੈਟ ਅਤੇ ਰਾਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਰਤ ਕੇ। ਜਦੋਂ ਪੀਅਰ ਪਤਾ ਸੁਰੰਗ ਦੇ ਅੰਦਰ ਹੁੰਦਾ ਹੈ, ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੰਗ ਉੱਪਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਉਹ ਪਤਾ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੂਰਾ ਹੋਇਆ IKE ਆਦਾਨ-ਪ੍ਰਦਾਨ BGP ਗੁਆਂਢੀ ਨਹੀਂ ਹੈ। ਰੂਟ-ਆਧਾਰਿਤ IPsec ਲਾਗੂਕਰਨ ਮੇਲ ਖਾਂਦੇ ਸੁਰੰਗ ਰੂਟ ਦੇ ਹੋਣ ਉੱਤੇ ਹੀ ਟ੍ਰੈਫਿਕ ਲੰਘਣ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਨੀਤੀ-ਆਧਾਰਿਤ ਲਾਗੂਕਰਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਚੋਣਕਾਰ ਦੇ ਅੰਦਰ ਪੀਅਰ ਪਤਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਨੂੰ ਉਲਟਾ ਕਰਨ ਨਾਲ ਉਹ ਕਲਾਸਿਕ ਹਾਲਤ ਬਣਦੀ ਹੈ ਜਿੱਥੇ ਸੁਰੰਗ ਹਰੀ ਹੈ ਅਤੇ ਸੈਸ਼ਨ ਵਿਹਲਾ ਬੈਠਾ ਹੈ।
ਸੈਸ਼ਨ ਉੱਪਰ ਆਉਣ ਤੋਂ ਬਾਅਦ ਨੀਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਇਸ ਵਿੱਚੋਂ ਕੀ ਲੰਘੇਗਾ। ਪ੍ਰੀਫਿਕਸ ਸੂਚੀਆਂ, AS-ਰਾਹ ਫਿਲਟਰ, ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰੀਫਿਕਸ ਦੀ ਸੀਮਾ ਅਤੇ ਡਿਫ਼ਾਲਟ ਰੂਟਾਂ ਬਾਰੇ ਸਪਸ਼ਟ ਫ਼ੈਸਲਾ ਘੱਟੋ-ਘੱਟ ਹਨ, ਅਤੇ ਇਹ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਜੋ ਮਿਲਦਾ ਹੈ ਸਭ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਪੀਅਰ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਸਥਾਨਕ ਇੰਟਰਨੈੱਟ ਪਹੁੰਚ ਨੂੰ ਚੁੱਪਚਾਪ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਨੂੰ ਵੱਖਰੀਆਂ ਸੂਚੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਪੀਅਰ ਤੋਂ ਤੁਸੀਂ ਕੀ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ ਅਤੇ ਉਸ ਨੂੰ ਕੀ ਐਲਾਨ ਕਰਦੇ ਹੋ, ਇਹ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਹਨ।
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
ਅੱਗੇ MTU ਡੰਗਦਾ ਹੈ। ਐਨਕੈਪਸੁਲੇਸ਼ਨ ਲਾਭਦਾਇਕ ਪੇਲੋਡ ਘਟਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਵੱਡਾ ਅੱਪਡੇਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਥਾਪਿਤ ਦਿਸਦੇ ਸੈਸ਼ਨ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ: ਪੀਅਰ ਉੱਪਰ ਰਹਿੰਦਾ ਹੈ, ਪ੍ਰੀਫਿਕਸ ਕਦੇ ਨਹੀਂ ਆਉਂਦੇ, ਅਤੇ ਲੌਗ ਵਿੱਚ ਕੁਝ ਸਪਸ਼ਟ ਨਹੀਂ ਪੈਂਦਾ। ਫਿਲਟਰਾਂ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੰਗ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ TCP MSS ਸੀਮਿਤ ਕਰੋ, ਜਾਂ ਓਵਰਹੈੱਡ ਲਈ ਥਾਂ ਰੱਖ ਕੇ ਸੁਰੰਗ MTU ਸੈੱਟ ਕਰੋ।
ਬਾਹਰੀ ਪੈਕਟ ਫਿਰ ਵੀ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ
ਇੱਕ ਸਾਈਟ ਤੋਂ ਦੂਜੀ ਤੱਕ ਐਨਕ੍ਰਿਪਟਿਡ ਪੈਕਟ ਸਥਾਨਕ ਰਾਊਟਰ ਪੀਅਰ ਦੇ ਜਨਤਕ ਪਤੇ ਲਈ ਜੋ ਰਾਹ ਚੁਣਦਾ ਹੈ, ਉਸ ਰਾਹੀਂ ਬਾਹਰ ਨਿਕਲਦੇ ਹਨ। ਜੇ ਦੋਵੇਂ ਸਾਈਟਾਂ ਇੱਕੋ ਪ੍ਰਦਾਤਾ ਤੋਂ ਟ੍ਰਾਂਜ਼ਿਟ ਖਰੀਦਦੀਆਂ ਹਨ, ਇੱਕੋ ਮੈਟਰੋ ਸੁਵਿਧਾ ਪਾਰ ਕਰਦੀਆਂ ਹਨ, ਜਾਂ ਇੱਕ ਪਾਸਾ ਕੈਰੀਅਰ-ਗ੍ਰੇਡ NAT ਪਿੱਛੇ ਹੈ, ਤਾਂ ਸੁਰੰਗ ਪ੍ਰਦਾਤਾ ਦੀ ਨਾਕਾਮੀ ਤੋਂ ਸਿਰਫ਼ ਸੰਜੋਗ ਨਾਲ ਬਚਦੀ ਹੈ। ਨਿਗਰਾਨੀ ਟੂਲ ਵਿੱਚ ਸੁਰੰਗ ਆਈਕਨ ਗਿਣਨਾ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।
ਰੂਟ ਚੋਣ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਸਥਾਪਨਾ ਵੀ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਹਨ। ਪ੍ਰੀਫਿਕਸ BGP ਸਾਰਣੀ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਵਜੋਂ ਬੈਠ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਫਾਰਵਰਡਿੰਗ ਸਾਰਣੀ ਵਿੱਚੋਂ ਗ਼ਾਇਬ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਅਗਲਾ ਹਾਪ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ ਜਾਂ ਵਧੇਰੇ ਖ਼ਾਸ ਰੂਟ ਜਿੱਤ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਦੱਸਦਾ ਹੈ ਕਿ BGP ਨੇ ਪ੍ਰੀਫਿਕਸ ਸਿੱਖਿਆ ਪਰ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਵਹਿੰਦਾ, ਤਾਂ ਲਾਭਦਾਇਕ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇਹ ਸਥਾਪਿਤ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕਿਹੜੇ ਅਗਲੇ ਹਾਪ ਵੱਲ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ।
ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਲਈ ਇਮਾਨਦਾਰ ਜਵਾਬ ਸਾਂਝੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਸੂਚੀ ਹੈ: ਪਹੁੰਚ ਸਰਕਿਟ, ਉੱਪਰਲਾ ਪ੍ਰਦਾਤਾ, ਸੁਵਿਧਾ ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਉੱਤੇ ਕੋਈ ਵੀ ਹਾਲਤ ਰੱਖਣ ਵਾਲਾ ਉਪਕਰਣ। ਸੁਰੰਗ ਉੱਤੇ ਦਾ ਸੈਸ਼ਨ ਉਸ ਨਿਰਭਰਤਾ ਨੂੰ ਨਹੀਂ ਹਟਾ ਸਕਦਾ ਜਿਸ ਦੇ ਉੱਪਰ ਇਹ ਨਹੀਂ ਬੈਠਾ।
ਵੱਖ ਕਰਨ ਯੋਗ ਤਿੰਨ ਫ਼ੈਸਲੇ
ਜਦੋਂ ਡਿਜ਼ਾਈਨ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਹਰ ਰੁਕਾਵਟ ਦੀ ਗੱਲਬਾਤ ਗੋਲ ਘੁੰਮਦੀ ਹੈ। ਪਹਿਲਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਕਾਗ਼ਜ਼ ਉੱਤੇ ਵੱਖ ਕਰੋ, ਫਿਰ ਹਰ ਇੱਕ ਨੂੰ ਉਸ ਉਪਕਰਣ ਨਾਲ ਜੋੜੋ ਜੋ ਸੱਚਮੁੱਚ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
ਹਰ ਕਤਾਰ ਦਾ ਮਾਲਕ ਵੱਖਰਾ ਹੈ। ਪਹਿਲੀ ਗੱਲਬਾਤ ਹੈ, ਦੂਜੀ ਤੁਹਾਡੇ ਉਪਕਰਣਾਂ ਉੱਤੇ ਸੰਰਚਨਾ ਹੈ, ਤੀਜੀ ਜ਼ਿਆਦਾਤਰ ਕਿਸੇ ਹੋਰ ਦਾ ਨੈੱਟਵਰਕ ਹੈ। ਜੋ ਬਦਲਾਅ ਬੇਨਤੀ ਆਪਣੀ ਛੂਹਣ ਵਾਲੀ ਕਤਾਰ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਉਸ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨਾ BGP ਸਮੱਸਿਆ ਕਹਿਣ ਵਾਲੀ ਬੇਨਤੀ ਨਾਲੋਂ ਕਿਤੇ ਸੌਖਾ ਹੈ।
ਯੋਜਨਾ ਬਣਾਉਣ ਯੋਗ ਨਾਕਾਮੀ ਦੇ ਢੰਗ
ਪੀਅਰ ਦਾ ਸਾਰਾਂਸ਼ ਰੂਟ ਸਵੀਕਾਰ ਕਰਨਾ ਸਭ ਤੋਂ ਆਮ ਆਪਣੇ ਆਪ ਨੂੰ ਲਾਇਆ ਜ਼ਖ਼ਮ ਹੈ। ਕੋਈ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਸੌਖਾ ਕਰਨ ਲਈ ਛੋਟਾ ਇਕੱਠ ਐਲਾਨ ਕਰਦਾ ਹੈ, ਦੂਰ ਦਾ ਪਾਸਾ ਉਸ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੁਰੰਗ ਪਿੱਛੇ ਨਾ ਹੋਣ ਵਾਲੀਆਂ ਰੇਂਜਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਸੁਰੰਗ ਦਾ ਪਿੱਛਾ ਕਰਕੇ ਮਰ ਜਾਂਦਾ ਹੈ। ਠੀਕ ਉਮੀਦ ਕੀਤੇ ਪ੍ਰੀਫਿਕਸ ਉੱਤੇ ਫਿਲਟਰ ਕਰੋ, ਜਾਂ ਸਹੀ ਸੀਮਾਵਾਂ ਵਾਲੀ ਪ੍ਰੀਫਿਕਸ ਸੂਚੀ ਵਰਤੋ, ਅਤੇ ਕਦੇ ਵੀ ਨੰਗਾ ਇਕੱਠ ਸਵੀਕਾਰ ਨਾ ਕਰੋ ਕਿਉਂਕਿ ਇਹ ਸੈਸ਼ਨ ਨੂੰ ਸਾਫ਼-ਸੁਥਰਾ ਦਿਸਦਾ ਕਰਦਾ ਹੈ।
ਵਾਪਸ ਲੈਣ ਦਾ ਸਮਾਂ ਦੂਜਾ ਹੈ। ਪਛਾਣ ਹੋਲਡ ਟਾਈਮਰ, ਤੁਸੀਂ ਸਮਰੱਥ ਕੀਤਾ ਹੋਵੇ ਤਾਂ BFD, ਸੁਰੰਗ ਦੀ ਮੁਰਦਾ ਪੀਅਰ ਪਛਾਣ ਅਤੇ ਦੂਰ ਦਾ ਪਾਸਾ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਐਲਾਨ ਬੰਦ ਕਰਦਾ ਹੈ, ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹਨ: ਨਵਾਂ ਰੂਟ ਨਵੇਂ ਸੰਬੰਧ ਬਹਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਥਾਪਿਤ TCP ਸੈਸ਼ਨ ਪੁਰਾਣੇ ਪਤੇ ਵਰਤਦੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਰਾਹ ਉੱਤੇ ਹਾਲਤ ਰੱਖਣ ਵਾਲੇ ਫਾਇਰਵਾਲ ਜਾਂ NAT ਉਹ ਐਂਟਰੀਆਂ ਰੱਖ ਸਕਦੇ ਹਨ ਜੋ ਹੁਣ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ। ਰੂਟ ਬਦਲਾਅ ਸਭ ਕੁਝ ਸੁਲਝਾ ਦੇਵੇਗਾ ਮੰਨਣ ਦੀ ਥਾਂ ਐਪਲੀਕੇਸ਼ਨ ਰਿਕਵਰੀ ਨੂੰ ਮਨਜ਼ੂਰੀ ਮਾਪਦੰਡਾਂ ਵਿੱਚ ਰੱਖੋ।
ਤੀਜੀ ਹੈ ਵਾਪਸੀ ਰਾਹ ਦੀ ਅਸਮਾਨਤਾ। ਟ੍ਰੈਫਿਕ ਸੁਰੰਗ ਰਾਹੀਂ ਆ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਢੋਣ ਲਈ ਕਦੇ ਨਾ ਬਣਾਈ ਗਈ ਪ੍ਰਦਾਤਾ ਲਿੰਕ ਰਾਹੀਂ ਵਾਪਸ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ ਇੱਕ-ਤਰਫ਼ਾ ਆਡੀਓ, ਨਾਕਾਮ ਹੈਂਡਸ਼ੇਕ ਜਾਂ ਜਵਾਬ ਸੁੱਟਣ ਵਾਲੇ ਫਾਇਰਵਾਲ ਵਜੋਂ ਦਿਸਦਾ ਹੈ। ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਜਾਂਚੋ।
ਸਮਝੌਤੇ ਵਿੱਚ ਕੀ ਲਿਖਣਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਕਿਵੇਂ ਪਰਖਣਾ ਹੈ
ਮਨਜ਼ੂਰ ਪ੍ਰੀਫਿਕਸ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਮੰਗੋ: ਹਰ ਰੇਂਜ ਬਣਾਉਣ ਦਾ ਅਧਿਕਾਰ ਕਿਸ ਨੂੰ ਹੈ, ਡਿਫ਼ਾਲਟ ਰੂਟ ਮਨਜ਼ੂਰ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਸੁਰੰਗ ਸੇਵਾ ਕਿਹੜੇ ਪਤਾ ਪਰਿਵਾਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ। RFC 8212 ਨੇ ਇਸ ਨੂੰ ਮੰਨਣ ਵਾਲੇ ਲਾਗੂਕਰਨਾਂ ਵਿੱਚ eBGP ਲਈ ਸਪਸ਼ਟ ਆਯਾਤ ਅਤੇ ਨਿਰਯਾਤ ਨੀਤੀ ਨੂੰ ਉਮੀਦ ਬਣਾ ਦਿੱਤਾ, ਇਸ ਲਈ ਅਜੇ ਵੀ ਲੁਕਵੇਂ ਸਭ-ਸਵੀਕਾਰ ਵਿਵਹਾਰ ਉੱਤੇ ਨਿਰਭਰ ਪੀਅਰ ਨੂੰ ਪੁੱਛਣਾ ਯੋਗ ਹੈ।
ਫਿਰ ਡਾਇਗ੍ਰਾਮ ਦੀ ਥਾਂ ਉਪਕਰਣ ਤੋਂ ਪਰਖੋ। FRR ਸ਼ੈਲੀ ਦੇ ਰਾਊਟਰਾਂ ਉੱਤੇ ਲਾਭਦਾਇਕ ਕਮਾਂਡਾਂ:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
ਅਜਿਹੇ ਦੋ ਨਿਰੀਖਣ ਜੋੜੋ ਜੋ ਰੂਟਿੰਗ ਸਾਰਣੀ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੇ ਸਕਦੀ। ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਐਨਕੈਪਸੁਲੇਟਿਡ ਪੈਕਟ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਪਤੇ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ, ਬਾਹਰੀ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਕੈਪਚਰ ਕਰੋ, ਉਦਾਹਰਣ ਲਈ tcpdump -ni eth0 udp port 51820 WireGuard ਸੁਰੰਗ ਲਈ, ਜਾਂ IPsec ਲਈ ESP ਫਿਲਟਰ। ਫਿਰ ਪੀਅਰ ਦੇ ਜਨਤਕ ਪਤੇ ਵੱਲ ਟ੍ਰੇਸ ਕਰੋ ਅਤੇ ਹਾਪਾਂ ਦੀ ਸੁਰੰਗ ਦੇ ਅੰਦਰਲੇ ਟ੍ਰੇਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ; ਜੇ ਦੋਵੇਂ ਇੱਕੋ ਪ੍ਰਦਾਤਾ ਲੜੀ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੀ ਵਾਧੂ ਸਮਰੱਥਾ ਨੈੱਟਵਰਕ ਵਿੱਚ ਨਹੀਂ, ਰੂਟਿੰਗ ਨੀਤੀ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ।
ਅੰਤ ਵਿੱਚ, ਜਾਣ-ਬੁੱਝ ਕੇ ਵਾਪਸ ਲੈਣ ਦੀ ਜਾਂਚ ਕਰੋ। ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਦੌਰਾਨ ਸੁਰੰਗ ਹੇਠਾਂ ਲਾਹੋ, ਪ੍ਰੀਫਿਕਸ ਕਿੰਨਾ ਸਮਾਂ ਸਥਾਪਿਤ ਰਹਿੰਦਾ ਹੈ, ਮੌਜੂਦਾ ਸੈਸ਼ਨਾਂ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਦੂਰ ਦਾ ਪਾਸਾ ਉਸ ਰੂਟ ਉੱਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਸਵੀਕਾਰ ਕਰੋਗੇ, ਇਹ ਦਰਜ ਕਰੋ। ਉਹ ਅਭਿਆਸ ਕਿਸੇ ਵੀ ਡਾਇਗ੍ਰਾਮ ਨਾਲੋਂ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਵੱਧ ਦੱਸਦਾ ਹੈ।
ਰੂਟ ਮਨਜ਼ੂਰੀ ਨਹੀਂ ਹੈ। ਜਿਨ੍ਹਾਂ ਪ੍ਰੀਫਿਕਸ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਤੁਸੀਂ ਤੈਅ ਕਰਦੇ ਹੋ, ਉਹ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕਿਹੜੇ ਵਰਤੋਂਕਾਰ ਸੁਰੰਗ ਪਿੱਛੇ ਕਿਹੜੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ, ਮਨਜ਼ੂਰ ਸੇਵਾਵਾਂ ਅਤੇ ਹੋਸਟ ਫਾਇਰਵਾਲ ਉੱਥੇ ਹੀ ਰੱਖੋ ਜਿੱਥੇ ਸਨ। ਪਹੁੰਚਯੋਗ ਪੀਅਰ ਵੀ ਅਸੀਮਤ ਟ੍ਰਾਂਜ਼ਿਟ ਜਾਂ ਮਨਮਾਨੇ ਪਤੇ ਬਣਾਉਣ ਦੀ ਮਨਜ਼ੂਰੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਅਜਿਹਾ ਅਧਿਕਾਰ BGP ਨੀਤੀ ਲਾਈਨ ਵਿੱਚ ਨਹੀਂ, ਸਮਝੌਤੇ ਵਿੱਚ ਵਪਾਰਕ ਸਵਾਲ ਵਜੋਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਹਰ ਪਾਸਾ ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਬਣਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਹੜੇ ਕਦੇ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ, ਉਨ੍ਹਾਂ ਦੇ ਨਾਮ ਦੱਸੋ।
- ਸੁਰੰਗ ਉੱਤੇ MSS ਸੀਮਿਤ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਵੱਡੇ ਅੱਪਡੇਟ ਸੱਚਮੁੱਚ ਆਉਂਦੇ ਹਨ।
- ਸਾਂਝੀਆਂ ਅੰਡਰਲੇ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਸੂਚੀ ਦਿਓ, ਸੁਰੰਗਾਂ ਦੀ ਗਿਣਤੀ ਨਹੀਂ।
- ਅਸਲ ਵਾਪਸ ਲੈਣ ਦਾ ਸਮਾਂ ਮਾਪੋ ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੀ ਕਰਦਾ ਹੈ।