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 નીતિ કરતાં જુદો નિર્ણય છે, અને સામાન્ય રીતે બંનેમાંથી ફક્ત એક જ ઇચ્છિત હોય છે. અંતિમ ડિઝાઇન જણાવે છે કે દરેક ટ્રાફિક વર્ગ ક્યાં રાઉટ થાય છે, ક્યાં નિરીક્ષણ થાય છે, અને જ્યારે તે નિરીક્ષણ માર્ગ ઉપલબ્ધ ન હોય ત્યારે શું થાય છે.