OSPF ਬਨਾਮ EIGRP ਦੀਆਂ ਬਹੁਤੀਆਂ ਬਹਿਸਾਂ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ ਕਿ ਟਨਲ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰੋਟੋਕਾਲ ਢੋ ਸਕਦੀ ਹੈ, ਅਤੇ ASA ’ਤੇ ਪਹਿਲਾਂ ਜਾਂਚਣ ਵਾਲਾ ਹਿੱਸਾ ਇਹੀ ਧਾਰਨਾ ਹੈ। ਤੁਲਨਾ ਉਦੋਂ ਹੀ ਦਿਲਚਸਪ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਮੇਜ, VTI ਕਿਸਮ ਅਤੇ multicast ਰਾਹ ਪੱਕੇ ਹੋ ਜਾਣ। ਇਹ ਕ੍ਰਮ ਗਲਤ ਹੋਇਆ ਤਾਂ ਤੁਸੀਂ ਅਜਿਹੀ ਟਨਲ ’ਤੇ ਟਾਈਮਰ ਟਿਊਨ ਕਰਨ ਵਿੱਚ ਦੁਪਹਿਰ ਗੁਆ ਦਿਓਗੇ ਜੋ ਕਦੇ ਗੁਆਂਢ ਨਹੀਂ ਬਣਾਏਗੀ। ਮੈਂ ਹਰ ਅਜਿਹੇ ਡਿਜ਼ਾਈਨ ਦੀ ਸ਼ੁਰੂਆਤ ਰਿਲੀਜ਼ ਨੋਟਸ ਅਤੇ ਚੱਲ ਰਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਕਰਦਾ ਹਾਂ, ਪ੍ਰੋਟੋਕਾਲ ਦੀ ਪਸੰਦ ਤੋਂ ਨਹੀਂ।

ਪ੍ਰੋਟੋਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਰਿਲੀਜ਼ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ

ASA 9.24 ਲਈ Cisco ਦੀ VTI ਗਾਈਡ ਇੱਕ ਵਰਤੋਂਯੋਗ ਦਸਤਾਵੇਜ਼ੀ ਆਧਾਰ ਹੈ: ਇਹ ਸਥਿਰ ਅਤੇ ਗਤੀਸ਼ੀਲ VTI ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ ਅਤੇ ਸਥਿਰ ਰਾਊਟਿੰਗ, BGP, OSPF ਅਤੇ EIGRP ਦੀ ਸੂਚੀ ਦਿੰਦੀ ਹੈ। ਇਸਦਾ ਫੀਚਰ ਇਤਿਹਾਸ VTI ’ਤੇ OSPFv2 ਅਤੇ EIGRP ਦੇ ਸਮਰਥਨ ਨੂੰ 9.19(1) ’ਤੇ ਰੱਖਦਾ ਹੈ। ਇਸ ਤੋਂ ਪੁਰਾਣਾ ਸਭ ਕੁਝ ਵੱਖਰੀ ਗੱਲ ਹੈ।

ਇਸ ਲਈ ਪਹਿਲੇ ਦੋ ਸਵਾਲ ਉਬਾਊ ਅਤੇ ਨਿਰਣਾਇਕ ਹਨ:

CheckWhat decides it
Image and releaseWhether the feature history lists OSPFv2 or EIGRP on VTI for the version you run
VTI typeStatic or dynamic, and which routing context the platform permits
Multicast on the tunnelWhether it is enabled, and whether the group limits are respected

ਇਹ ਕਹਿਣਾ ਕਿ ASA VTI ਵਰਤ ਨਹੀਂ ਸਕਦਾ, ਜਾਂ IGP ਨਹੀਂ ਢੋ ਸਕਦਾ, ਕੁਝ ਪੁਰਾਣੇ ਇਮੇਜਾਂ ਲਈ ਸਹੀ ਸੀ ਅਤੇ ਅੱਜ ਦਾ ਸਮਰਥਨ ਮੈਟ੍ਰਿਕਸ ਨਹੀਂ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, 9.24 ਗਾਈਡ ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਅੱਪਗਰੇਡ ਕਰਨ ਦੀ ਹਦਾਇਤ ਨਹੀਂ ਹੈ। ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਉਹ ਰਿਲੀਜ਼ ਕੀ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਤੈਨਾਤ ਰਿਲੀਜ਼ ਨੂੰ ਆਪਣਾ ਜਵਾਬ ਖੁਦ ਦੇਣਾ ਪਵੇਗਾ।

unicast ਦਾ ਲੰਘਣਾ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ IGP ਬਣੇਗਾ

ਇਹੀ ਗਾਈਡ ਦੱਸਦੀ ਹੈ ਕਿ unicast ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਲੰਘਦਾ ਹੈ ਅਤੇ VTI ’ਤੇ OSPFv2 ਜਾਂ EIGRP ਲਈ multicast ਚਾਲੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, multicast ਗਰੁੱਪਾਂ ’ਤੇ ਦਸਤਾਵੇਜ਼ੀ ਸੀਮਾਵਾਂ ਨਾਲ। ਉਹੀ ਇੱਕ ਵਾਕ ਇਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਮੇਰੇ ਦੇਖੇ ਜ਼ਿਆਦਾਤਰ ਅਸਫਲ ਗੁਆਂਢ ਸਮਝਾ ਦਿੰਦਾ ਹੈ। ਟਨਲ ਰਾਹੀਂ ਚੱਲਦਾ ping, ਜਾਂ ਹਰਾ IPsec ਸਟੇਟਸ, ਸਿਰਫ਼ unicast ਰਾਹ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਟੋਕਾਲ ਖੋਜ ਲਈ multicast ਰਾਹ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਕਨਫਿਗਰ ਹੁੰਦੇ ਹਨ।

hello ਜਾਂ hold ਟਾਈਮਰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਇੰਟਰਫੇਸ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਉਹ multicast ਸੈਟਿੰਗ ਵੇਖੋ। ਜੇ ਸੈਟਿੰਗ ਨਹੀਂ ਹੈ, ਤਾਂ ਗੁਆਂਢ ਹੌਲੀ ਨਹੀਂ, ਅਸੰਭਵ ਹੈ।

ਇੱਕੋ ਟਨਲ ’ਤੇ OSPF ਅਤੇ EIGRP ਨਾਲ-ਨਾਲ

ਟਨਲ ’ਤੇ ਹੀ ਦੋਵੇਂ ਪ੍ਰੋਟੋਕਾਲ ਉਵੇਂ ਹੀ ਦਿਸਦੇ ਹਨ ਜਿਵੇਂ ਹੋਰ ਕਿਤੇ। OSPF ਨੂੰ ਮੇਲ ਖਾਂਦੀ ਨੈੱਟਵਰਕ ਕਿਸਮ, ਖੇਤਰ, ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਗੁਆਂਢੀ ਪੈਰਾਮੀਟਰ ਚਾਹੀਦੇ ਹਨ; EIGRP ਨੂੰ ਆਪਣਾ AS ਨੰਬਰ ਅਤੇ ਉਸ ਨਾਲ ਜਾਣ ਵਾਲੀਆਂ ਇੰਟਰਫੇਸ-ਪੱਧਰੀ ਸੈਟਿੰਗਾਂ ਚਾਹੀਦੀਆਂ ਹਨ।

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

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

ਗੁਆਂਢੀ ਸਥਾਪਿਤ ਰੂਟਾਂ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦੇ

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

show ospf neighbor ਅਤੇ show eigrp neighbors ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਸੈਸ਼ਨ ਜੀਵਤ ਹੈ। show route ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਸ਼ਾਖਾ ਪ੍ਰੀਫਿਕਸ ਪਹੁੰਚਿਆ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਹ ਵੱਖਰੇ ਸਵਾਲ ਹਨ।

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

ਪੂਰੀ ਹੋਈ ਤੁਲਨਾ ਵਿੱਚ ਕੀ ਦਰਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਜੇ ਉਨ੍ਹਾਂ ਚਾਰਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਡਿਜ਼ਾਈਨ ਨਹੀਂ, ਪਸੰਦ ਹੈ। ਪਹਿਲਾਂ ਗੁੰਮ ਤੱਥ ਠੀਕ ਕਰੋ; ਪ੍ਰੋਟੋਕਾਲ ਚੁਣਨਾ ਸੌਖਾ ਹਿੱਸਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ