EVPN ਫਾਇਰਵਾਲ ਨੀਤੀ: ਕੇਂਦਰੀ ਗੇਟਵੇ ਬਨਾਮ ਵੰਡਿਆ IRB
ਕੇਂਦਰੀ ਗੇਟਵੇ ਕਿਰਾਏਦਾਰ ਦਾ ਟ੍ਰੈਫਿਕ ਫਾਇਰਵਾਲ ਰਾਹੀਂ ਭੇਜਦੇ ਹਨ, ਵੰਡਿਆ IRB ਨਹੀਂ। ਦੇਖੋ ਕਿ ਕਿਹੜਾ ਕਿੱਥੇ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ ਰਾਹ ਨੂੰ ਕੀ ਲੋੜ ਹੈ।
ਦੋ EVPN ਡਿਜ਼ਾਈਨ ਕਿਰਾਏਦਾਰ ਦੇ ਗੇਟਵੇ ਨੂੰ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਤੇ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਫਾਇਰਵਾਲ ਹਰ ਇੱਕ ਵਿੱਚ ਵੱਖਰਾ ਟ੍ਰੈਫਿਕ ਦੇਖਦਾ ਹੈ। ਕੇਂਦਰੀ ਗੇਟਵੇ ਨਾਲ, ਸਬਨੈੱਟਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਫਾਇਰਵਾਲ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਕਿਉਂਕਿ ਰਾਊਟਿੰਗ ਉੱਥੇ ਹੀ ਹੁੰਦੀ ਹੈ। ਵੰਡੇ IRB ਨਾਲ, leaf ਸਵਿੱਚ ਸਥਾਨਕ ਤੌਰ ਤੇ ਰਾਊਟ ਕਰਦੇ ਹਨ ਅਤੇ ਫਾਇਰਵਾਲ ਕੁਝ ਨਹੀਂ ਦੇਖਦਾ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦੇ। ਕੋਈ ਵੀ ਮਾਡਲ ਗਲਤ ਨਹੀਂ ਹੈ। ਗਲਤ ਇਹ ਹੈ ਕਿ ਸਰਹੱਦ ਤੇ ਫਾਇਰਵਾਲ ਜੋੜੋ ਅਤੇ ਮੰਨ ਲਓ ਕਿ fabric ਟ੍ਰੈਫਿਕ ਉਸ ਤੱਕ ਪਹੁੰਚਾ ਦੇਵੇਗਾ।
ਦੋ ਮਾਡਲ, ਦੋ ਵੱਖਰੇ ਜਾਂਚ ਬਿੰਦੂ
ਪਹਿਲਾਂ ਉਹਨਾਂ ਫਲੋ ਦੇ ਨਾਮ ਦਿਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਜਾਂਚ ਦੀ ਲੋੜ ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਮਾਡਲ ਉਹਨਾਂ ਨਾਲ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਨਜਿੱਠਦੇ ਹਨ।
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
ਇੱਕੋ ਸਬਨੈੱਟ ਦੇ ਅੰਦਰ ਦਾ ਟ੍ਰੈਫਿਕ ਉਹ ਕਤਾਰ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਇੱਕ VLAN ਤੇ ਦੋ ਹੋਸਟ ਬ੍ਰਿਜਿੰਗ ਰਾਹੀਂ ਗੱਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਸ ਰਾਹ ਵਿੱਚ ਕੋਈ ਰਾਊਟਿਡ ਫਾਇਰਵਾਲ ਨਹੀਂ ਹੁੰਦਾ, ਜਦ ਤੱਕ ਕੋਈ ਵੱਖਰਾ ਲੇਅਰ 2 ਜਾਂਚ ਡਿਜ਼ਾਈਨ ਇਸਨੂੰ ਰੋਕ ਨਾ ਲਵੇ। ਇਹ ਦੋਵੇਂ ਮਾਡਲਾਂ ਵਿੱਚ ਸੱਚ ਹੈ, ਇਸ ਲਈ ਇਹ ਡਿਜ਼ਾਈਨ ਦੀ ਘਾਟ ਹੈ, ਉਹਨਾਂ ਵਿਚਕਾਰ ਤੁਲਨਾ ਨਹੀਂ।
ਬਾਕੀ ਤਿੰਨ ਕਤਾਰਾਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਮਾਡਲ ਸੱਚਮੁੱਚ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।
ਕੇਂਦਰੀ ਗੇਟਵੇ: ਸਧਾਰਨ ਜਾਂਚ, ਅਸਲ ਟ੍ਰਾਂਜ਼ਿਟ ਲਾਗਤ
ਕਿਰਾਏਦਾਰ ਦੇ VLAN ਨੂੰ ਲੇਅਰ 2 ਸੇਵਾਵਾਂ ਵਜੋਂ ਰੱਖੋ ਅਤੇ ਉਹਨਾਂ ਦੇ ਰਾਊਟਿੰਗ ਗੇਟਵੇ ਫਾਇਰਵਾਲ ਤੇ ਰੱਖੋ। ਸਬਨੈੱਟਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਫਿਰ ਉਸ ਗੇਟਵੇ ਤੱਕ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਸ਼ਾਇਦ ਉਦੋਂ ਵੀ ਜਦੋਂ ਦੋਵੇਂ ਹੋਸਟ ਇੱਕੋ leaf ਤੇ ਹੋਣ। ਜਾਂਚ ਬਿੰਦੂ ਸਪੱਸ਼ਟ ਹੈ, ਅਤੇ ਇਹੀ ਇਸ ਡਿਜ਼ਾਈਨ ਦੀ ਪੂਰੀ ਦਲੀਲ ਹੈ। ਲਾਗਤ ਫਾਇਰਵਾਲ ਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਭਾਰ ਅਤੇ ਹੁਣ ਤੁਹਾਨੂੰ ਇੰਜੀਨੀਅਰ ਕਰਨ ਵਾਲੀ ਕੇਂਦਰੀ ਸਮਰੱਥਾ ਤੇ ਉਪਲਬਧਤਾ ਦੀ ਨਿਰਭਰਤਾ ਹੈ।
ਬਦਲਾਅ ਨੂੰ ਉਹਨਾਂ ਕਿਰਾਏਦਾਰ ਗੇਟਵੇ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਸੀਂ ਇਰਾਦਾ ਰੱਖਦੇ ਹੋ। ਹਰ VLAN ਪਤਾ ਹਟਾਉਣਾ ਬਹੁਤ ਵਿਸ਼ਾਲ ਹੈ ਜਦੋਂ ਪ੍ਰਬੰਧਨ, underlay ਅਤੇ ਪਲੇਟਫਾਰਮ ਇੰਟਰਫੇਸ ਦੇ ਵੱਖਰੇ ਫਰਜ਼ ਹੋਣ। ਦੂਜਾ ਸਰਗਰਮ ਗੇਟਵੇ ਵੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਜੋ ਅਜੇ ਵੀ ਫਾਇਰਵਾਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਰਾਊਟ ਕਰਦਾ ਹੈ ਉਹ ਡਿਜ਼ਾਈਨ ਨੂੰ ਚੁੱਪਚਾਪ ਨਕਾਰਦਾ ਹੈ।
ਇਹ ਮਾਡਲ ਲੇਖਾ-ਪਰੀਖਕ ਨੂੰ ਸਮਝਾਉਣਾ ਸੌਖਾ ਹੈ। ਇਹ ਚਲਾਉਣਾ ਆਪਣੇ ਆਪ ਸਸਤਾ ਨਹੀਂ ਹੈ।
ਵੰਡਿਆ IRB: ਤੇਜ਼ ਰਾਹ, ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਕੋਈ ਜਾਂਚ ਨਹੀਂ
ਵੰਡੇ anycast ਗੇਟਵੇ ਨਾਲ, ਹਰ leaf ਕਿਰਾਏਦਾਰ ਦਾ ਟ੍ਰੈਫਿਕ ਸਥਾਨਕ ਤੌਰ ਤੇ ਰਾਊਟ ਕਰਦਾ ਹੈ, ਅਤੇ RFC 9135 ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕੇਂਦਰੀ ਗੇਟਵੇ ਰਾਹੀਂ ਵਾਪਸੀ ਢੋਆ-ਢੁਆਈ ਨੂੰ ਕਿਉਂ ਟਾਲਦਾ ਹੈ। ਲਾਭ ਅਸਲ ਹੈ, ਅਤੇ ਇਸਦਾ ਸਿੱਧਾ ਨਤੀਜਾ ਹੈ: ਫਾਇਰਵਾਲ ਕਿੱਥੇ ਜੁੜਿਆ ਹੈ ਇਸ ਤੋਂ ਜਾਂਚ ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ। ਸਰਹੱਦੀ leaf ਨਾਲ ਜੁੜਿਆ ਫਾਇਰਵਾਲ ਬਾਹਰੀ ਟ੍ਰੈਫਿਕ ਅਤੇ ਉਹ ਸਭ ਦੇਖਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਉਸ ਵੱਲ ਮੋੜਦੇ ਹੋ।
ਪਲੇਟਫਾਰਮ ਜੋ ਸੱਚਮੁੱਚ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਉਸ ਵਿਧੀ ਨਾਲ ਸੇਵਾ ਸ਼ਾਮਲ ਕਰੋ: ਨੀਤੀ-ਆਧਾਰਿਤ ਰੀਡਾਇਰੈਕਸ਼ਨ, ਇੱਕ ਸੇਵਾ ਨੋਡ, ਜਾਂ ਫਾਇਰਵਾਲ ਰਾਹੀਂ ਨਿਯੰਤਰਿਤ VRF-ਅੰਤਰ ਰਾਊਟਿੰਗ। ਇੱਛਤ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਸਦੇ ਅਸਲ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਤੇ ਮਿਲਾਓ। ਹੋਸਟਾਂ ਵੱਲ ਦੇ ਇੰਟਰਫੇਸ ਤੇ ਲਿਖੀ ਨੀਤੀ overlay ਤੋਂ ਆਉਣ ਵਾਲੇ ਪੈਕੇਟ ਨੂੰ ਨਹੀਂ ਢਕਦੀ।
ਇੱਛਤ ਡਿਫਾਲਟ ਦੀ ਬਜਾਏ ਸਥਾਪਿਤ ਰੂਟ ਪੜ੍ਹੋ। ਸਿੱਧਾ ਆਯਾਤ ਕੀਤਾ ਵਧੇਰੇ ਵਿਲੱਖਣ ਕਿਰਾਏਦਾਰ ਪ੍ਰੀਫਿਕਸ ਫਾਇਰਵਾਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਡਿਫਾਲਟ ਰੂਟ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਸੰਰਚਨਾ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਦਿਸੇਗਾ।
ਸਮਰੂਪਤਾ ਰਾਊਟਿੰਗ ਦਾ ਗੁਣ ਹੈ, ਜਾਂਚ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ
ਸਮਰੂਪ IRB ਦੱਸਦਾ ਹੈ ਕਿ ਪ੍ਰਵੇਸ਼ ਅਤੇ ਨਿਰਗਮ provider edge ਨੋਡ ਇੱਕ ਫਲੋ ਲਈ ਰਾਊਟਿੰਗ ਅਤੇ ਬ੍ਰਿਜਿੰਗ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹਨ। ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਇੱਕੋ stateful ਡਿਵਾਈਸ ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ। ECMP, anycast ਅਤੇ ਫਾਇਰਵਾਲ ਦੀ ਉੱਚ ਉਪਲਬਧਤਾ ਸਭ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਨੋਡ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਕਲਸਟਰ ਦਾ ਸਮਰਥਿਤ ਸਥਿਤੀ ਮਾਡਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਸਵੀਕਾਰਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।
ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਰ ਫਲੋ ਲਈ ਵਾਪਸੀ ਰਾਹ ਦੀ ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਪਾਲਣਾ ਕਰੋ। NAT ਉਸ ਕੰਮ ਦਾ ਸਰਵਵਿਆਪੀ ਬਦਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਤੇ ਨਿਰਭਰ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ ਤੇ ਨਿਰਮਾਣ ਦੇ ਦੌਰਾਨ ਨਹੀਂ ਬਲਕਿ failover ਦੇ ਦੌਰਾਨ ਕਮੀ ਲੱਭਦੇ ਹਨ।
ਡਿਜ਼ਾਈਨ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਲਾਜ਼ਮੀ ਫਲੋ ਅਤੇ ਇੱਕ ਜਾਣਬੁੱਝ ਕੇ ਬਾਹਰ ਰੱਖਿਆ ਫਲੋ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਤੁਰ ਕੇ ਵੇਖੋ।
ਕਿਵੇਂ ਚੁਣਨਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ ਕੀ ਪਰਖਣਾ ਹੈ
ਜਾਂਚ ਕਵਰੇਜ ਟ੍ਰਾਂਜ਼ਿਟ ਸਮਰੱਥਾ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਕੇਂਦਰੀ ਨਿਰਭਰਤਾ ਸਹਿ ਸਕੋ ਤਾਂ ਕੇਂਦਰੀ ਗੇਟਵੇ ਚੁਣੋ। ਸਥਾਨਕ ਰਾਊਟਿੰਗ ਮੁੱਖ ਗੱਲ ਹੋਵੇ ਤਾਂ ਵੰਡਿਆ IRB ਚੁਣੋ, ਅਤੇ ਮੰਨ ਲੈਣ ਦੀ ਬਜਾਏ ਸਪੱਸ਼ਟ ਸੇਵਾ-ਪ੍ਰਵੇਸ਼ ਲਈ ਬਜਟ ਰੱਖੋ।
ਫਿਰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਸਥਾਪਿਤ ਕੀਤੀ ਰਾਊਟਿੰਗ ਨੂੰ ਪਰਖੋ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ ਸਭ ਤੋਂ ਵੱਧ ਉੱਥੇ ਹੀ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixਪਰਖ ਵਿੱਚ ਸੇਵਾ ਨੋਡ ਦੀ ਅਸਫਲਤਾ ਅਤੇ ਬਹਾਲੀ ਸ਼ਾਮਲ ਕਰੋ। ਜੋ ਫਾਲਬੈਕ ਰੂਟ ਚੁੱਪਚਾਪ ਜਾਂਚ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ ਉਹ ਯੋਜਨਾਬੱਧ fail-open ਨੀਤੀ ਤੋਂ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ ਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਇੱਛਤ ਹੁੰਦਾ ਹੈ। ਤਿਆਰ ਡਿਜ਼ਾਈਨ ਦੱਸਦਾ ਹੈ ਕਿ ਹਰ ਟ੍ਰੈਫਿਕ ਵਰਗ ਕਿੱਥੇ ਰਾਊਟ ਹੁੰਦਾ ਹੈ, ਕਿੱਥੇ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਉਹ ਜਾਂਚ ਰਾਹ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।