EVPN ਸੀਮਾ ਅਟੈਚਮੈਂਟਾਂ ਦੁਆਲੇ ਨਹੀਂ, ਨਿਰਯਾਤ ਨੀਤੀ ਦੁਆਲੇ ਬਣਾਓ

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

ਸੀਮਾ ਕੀ ਪਾਰ ਕਰਦਾ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਹਰ ਪਾਸੇ ਕਿਹੜੇ ਰਾਊਟ ਦਿਸਣੇ ਚਾਹੀਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਦੀ ਦਿਸ਼ਾ, ਅਤੇ ਉਸ ਸੂਚੀ ਵਿੱਚ ਤਬਦੀਲੀ ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਲਿਖੋ। ਜੋ ਸੀਮਾ ਸਭ ਕੁਝ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਐਲਾਨਦੀ ਹੈ, ਉਸ ਕੋਲ ਨੀਤੀ ਨਹੀਂ, ਸਿਰਫ਼ ਇੱਕ ਕੇਬਲ ਹੈ।

ਫਿਰ ਉਸ ਫੇਲ੍ਹ ਦਾ ਨਾਂ ਲਓ ਜੋ ਤੁਸੀਂ ਚਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ: ਇੱਕ uplink ਡਾਊਨ, ਇੱਕ border leaf ਡਾਊਨ, ਜਾਂ ਪੂਰਾ ਬਾਹਰੀ ਡੋਮੇਨ ਅਪਹੁੰਚ। ਹਰ ਜਵਾਬ ਬਦਲਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਦੋ ਸੁਤੰਤਰ ਗੁਆਂਢੀ, ਸਾਂਝਾ Layer 2 ਅਟੈਚਮੈਂਟ, ਜਾਂ ਦੋਵੇਂ ਚਾਹੀਦੇ ਹਨ।

ਉਹ ਦੋ ਸੂਚੀਆਂ ਬਣਨ ਤੋਂ ਬਾਅਦ ਹੀ ਅਟੈਚਮੈਂਟ ਦਾ ਸਵਾਲ ਜਵਾਬਯੋਗ ਹੁੰਦਾ ਹੈ। ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਵਿਧੀ ਬਰਾਬਰ ਵੈਧ ਲੱਗਦੀ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਬਹੁਤੀਆਂ ਆਪਣੇ ਆਪ ਨੂੰ ਹਟਾ ਲੈਂਦੀਆਂ ਹਨ। ਰਾਊਟਿੰਗ ਦਾ ਕੰਮ ਪਹਿਲਾਂ ਕਰਨ ਦੀ ਪੂਰੀ ਦਲੀਲ ਇਹੀ ਹੈ।

ASN ਅਤੇ peering ਸੀਮਾ ਤੈਅ ਕਰੋ

ਇੱਕ ਨਿੱਜੀ-AS ਫੈਬਰਿਕ ਆਮ ਤੌਰ ਉੱਤੇ eBGP ਰਾਹੀਂ ਜਨਤਕ ਸੀਮਾ ਡੋਮੇਨ ਨਾਲ peering ਕਰਦਾ ਹੈ, ਅਤੇ ਦਿਲਚਸਪ ਹਿੱਸਾ ਦੋਵੇਂ ਪਾਸਿਆਂ ਦੀ ਨੀਤੀ ਹੈ। ਤੈਅ ਕਰੋ ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਸਵੀਕਾਰ ਹੁੰਦੇ ਹਨ, ਕਿਹੜੇ ਐਲਾਨੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ upstream ਨੂੰ ਕਿਹੜਾ AS path ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਕਨਫੈਡਰੇਸ਼ਨ ਜਾਂ local-AS ਸੁਵਿਧਾ ਕਿਸੇ ਖਾਸ ਟੋਪੋਲੋਜੀ ਲਈ ਡਿਜ਼ਾਈਨ ਚੋਣ ਹੈ। ਕੋਈ ਵੀ ਲਾਜ਼ਮੀ ਨਹੀਂ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਫੈਬਰਿਕ ਅਤੇ upstream ਵੱਖਰੀਆਂ ASN ਭੂਮਿਕਾਵਾਂ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਲੋੜ ਬਿਨਾਂ ਇੱਕ ਅਪਣਾਉਣਾ ਹਰ ਭਵਿੱਖੀ ਤਬਦੀਲੀ ਵਿੱਚ ਚੱਲਦੇ ਹਿੱਸੇ ਜੋੜਦਾ ਹੈ।

Layer 3 uplink ਨੂੰ multichassis LAG ਦੀ ਲੋੜ ਨਹੀਂ

ਆਪਣੇ BGP ਗੁਆਂਢੀਆਂ ਵਾਲੇ ਸੁਤੰਤਰ ਰਾਊਟਿਡ ਇੰਟਰਫ਼ੇਸ ਦੋ ਸਪਸ਼ਟ ਰਾਹ ਅਤੇ ਦੋ ਸਪਸ਼ਟ ਫੇਲ੍ਹ ਡੋਮੇਨ ਦਿੰਦੇ ਹਨ। vPC ਜਾਂ ਕੋਈ ਹੋਰ multichassis LAG Layer 2 ਅਟੈਚਮੈਂਟ ਲੋੜ ਪੂਰੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਉਹ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇਹੀ ਸਹੀ ਸੰਦ ਹੈ।

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

ਤੁਸੀਂ ਪਹਿਲਾਂ ਲਿਖੀ ਰਾਊਟਿੰਗ ਨੀਤੀ ਅਟੈਚਮੈਂਟ ਵਿਧੀ ਬਦਲਣ ਨਾਲ ਨਹੀਂ ਬਦਲਦੀ, ਜੋ ਚੰਗਾ ਸੰਕੇਤ ਹੈ ਕਿ ਕ੍ਰਮ ਸਹੀ ਸੀ।

ਸਿਰਫ਼ ਉਹੀ ਨਿਰਯਾਤ ਕਰੋ ਜੋ ਟੈਨੈਂਟ ਨੂੰ ਲੋੜ ਹੈ

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

EVPN IP Prefix ਰਾਊਟ, ਜਿਸਨੂੰ ਆਮ ਤੌਰ ਉੱਤੇ Type 5 ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਤੇ RFC 9136ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, overlay ਵਿੱਚ ਪ੍ਰੀਫਿਕਸ ਜਾਣਕਾਰੀ ਢੋਂਦਾ ਹੈ। ਲਾਗੂ ਕਰਨ ਨੂੰ ਅਜੇ ਵੀ ਮੇਲ ਖਾਂਦੀ ਨਿਰਯਾਤ ਅਤੇ ਆਯਾਤ ਨੀਤੀ ਅਤੇ next-hop ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਦੀ ਲੋੜ ਹੈ, ਇਸ ਲਈ ਸੀਮਾ ਉੱਤੇ ਬਾਹਰੀ BGP ਰਾਊਟ ਮਿਲਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਟੈਨੈਂਟ VRF ਇਸਨੂੰ ਆਯਾਤ ਕਰਦਾ ਹੈ।

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

ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਜਾਂਚੋ

ਇੱਕ ਨੁਮਾਇੰਦਾ ਬਾਹਰੀ ਪ੍ਰੀਫਿਕਸ ਚੁਣੋ ਅਤੇ ਸੀਮਾ ਦੇ ਇੱਛਤ VRF, ਨਿਰਯਾਤ ਨੀਤੀ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ leaf ਦੇ ਫਾਰਵਰਡਿੰਗ ਸੰਦਰਭ ਅਤੇ ਟੈਨੈਂਟ ਸਰੋਤ ਤੱਕ ਵਾਪਸੀ ਦੇ ਰਾਹ ਵਿੱਚੋਂ ਇਸਦਾ ਪਿੱਛਾ ਕਰੋ। ਜੋ ਪ੍ਰੀਫਿਕਸ ਇੱਕ ਥਾਂ ਦਿਸਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਥਾਂ ਨਹੀਂ, ਉਹ ਗਲਤੀ ਨੂੰ ਤੁਰੰਤ ਲੱਭ ਲੈਂਦਾ ਹੈ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ next hop overlay ਵਿੱਚੋਂ ਕਿਵੇਂ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਅਣਸੁਲਝੇ next hop ਵਾਲਾ ਮੌਜੂਦ ਰਾਊਟ ਕੁਝ ਵੀ ਫਾਰਵਰਡ ਨਹੀਂ ਕਰਦਾ। ਫਿਰ uplink ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਜਾਂਚ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਉਦੋਂ ਹੀ ਨੀਤੀ ਅਤੇ next-hop ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਸਭ ਤੋਂ ਵੱਧ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।

ਕੰਮ ਦਾ ਕ੍ਰਮ: ਕ੍ਰਾਸਿੰਗ ਰਾਊਟ ਸੂਚੀਬੱਧ ਕਰੋ, ASN ਨੀਤੀ ਉੱਤੇ ਸਹਿਮਤੀ ਬਣਾਓ, ਅਟੈਚਮੈਂਟ ਨੂੰ ਉਸਦੇ ਅਸਲ ਕੰਮ ਲਈ ਚੁਣੋ, ਹਰ ਟੈਨੈਂਟ ਲਈ ਨਿਰਯਾਤ ਦਾ ਦਾਇਰਾ ਤੈਅ ਕਰੋ, ਫਿਰ ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਉਸਦਾ ਵਾਪਸੀ ਰਾਹ ਜਾਂਚੋ।