EVPN firewall քաղաքականություն՝ կենտրոնացված gateway ընդդեմ բաշխված IRB-ի
Կենտրոնացված gateway-ները վարձակալի թրաֆիկը տանում են firewall-ով, բաշխված IRB-ն՝ ոչ։ Համեմատեք, թե որտեղ է յուրաքանչյուրը ստուգում և ինչ է պետք արագ ուղուն։
Երկու EVPN նախագծեր վարձակալի gateway-ը տեղադրում են տարբեր տեղերում, և firewall-ը յուրաքանչյուրում տարբեր թրաֆիկ է տեսնում։ Կենտրոնացված gateway-ի դեպքում ենթացանցերի միջև թրաֆիկը հասնում է firewall-ին, քանի որ հենց այնտեղ է կատարվում երթուղավորումը։ Բաշխված IRB-ի դեպքում leaf անջատիչները երթուղավորում են տեղական, և firewall-ը ոչինչ չի տեսնում, քանի դեռ դուք դիտավորյալ չեք տեղադրել այն։ Ոչ մի մոդել սխալ չէ։ Սխալն այն է, որ firewall-ը ամրացնես սահմանին և ենթադրես, թե 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-ի երկու հոսթեր խոսում են կամրջման միջոցով, և այդ ուղու վրա երթուղավորող firewall չկա, քանի դեռ առանձին 2-րդ շերտի ստուգման նախագիծ չի ընդհատում այն։ Դա ճիշտ է երկու մոդելում էլ, ուստի դա նախագծի բաց է, ոչ թե նրանց միջև համեմատություն։
Մյուս երեք տողերն այն տեղերն են, որտեղ մոդելները իրոք տարբերվում են։
Կենտրոնացված gateway՝ պարզ ստուգում, իրական տրանզիտային ծախս
Պահեք վարձակալի VLAN-ները որպես 2-րդ շերտի ծառայություններ և դրեք դրանց երթուղավորման gateway-ները firewall-ի վրա։ Ենթացանցերի միջև թրաֆիկն այնուհետև գնում է այդ gateway-ին և վերադառնում, հնարավոր է նույնիսկ այն դեպքում, երբ երկու հոսթերն էլ նույն leaf-ի վրա են։ Ստուգման կետը միանշանակ է, և դա է այս նախագծի ամբողջ փաստարկը։ Ծախսը firewall-ի վրա տրանզիտային բեռն է՝ գումարած կենտրոնական կախվածություն թողունակությունից և հասանելիությունից, որը հիմա պետք է նախագծեք։
Սահմանափակեք փոփոխությունը ձեր նախատեսած վարձակալի gateway-ներով։ Յուրաքանչյուր VLAN հասցե հեռացնելը չափազանց լայն է, երբ կառավարումը, underlay-ը և հարթակի ինտերֆեյսները առանձին պարտականություններ ունեն։ Ստուգեք նաև երկրորդ ակտիվ gateway-ը, քանի որ մեկը, որը դեռ երթուղավորում է firewall-ի շուրջը, հանգիստ ձախողում է նախագիծը։
Այս մոդելն ավելի հեշտ է բացատրել աուդիտորին։ Այն ինքնաբերաբար ավելի էժան չէ շահագործել։
Բաշխված IRB՝ արագ ուղի, լռելյայն ստուգում չկա
Բաշխված anycast gateway-ներով յուրաքանչյուր leaf տեղական երթուղավորում է վարձակալի թրաֆիկը, և RFC 9135-ը նկարագրում է, թե ինչու դա խուսափում է կենտրոնացված gateway-ով հետադարձ տեղափոխումից։ Օգուտն իրական է, և ունի ուղիղ հետևանք՝ ստուգումը հնարավոր չէ եզրակացնել այն տեղից, որտեղ firewall-ը միացված է։ Սահմանային leaf-ին միացված firewall-ը տեսնում է արտաքին թրաֆիկը և այն ամենը, ինչ դուք հստակորեն ուղղորդում եք դրան։
Տեղադրեք ծառայությունը մեխանիզմով, որն իրոք աջակցում է հարթակը՝ քաղաքականության վրա հիմնված վերահասցեավորում, ծառայության հանգույց կամ վերահսկվող երթուղավորում VRF-ների միջև firewall-ով։ Համապատասխանեցրեք նախատեսված թրաֆիկը դրա իրական մուտքի կետում։ Հոսթերին ուղղված ինտերֆեյսի վրա գրված քաղաքականությունը չի ծածկում overlay-ից եկող փաթեթը։
Կարդացեք տեղադրված երթուղիները, ոչ թե նախատեսված լռելյայնը։ Ուղղակի ներմուծված ավելի կոնկրետ վարձակալի նախածանցը կարող է շրջանցել firewall-ին ուղղված լռելյայն երթուղին, և կազմաձևում ոչինչ սխալ չի երևա։
Համաչափությունը երթուղավորման հատկություն է, ոչ թե ստուգման երաշխիք
Համաչափ IRB-ն նկարագրում է, թե ինչպես են մուտքային և ելքային provider edge հանգույցները վարվում հոսքի երթուղավորման և կամրջման հետ։ Այն ոչինչ չի ասում այն մասին, թե արդյոք երկու ուղղություններն էլ հասնում են նույն stateful սարքին։ ECMP-ն, anycast-ը և firewall-ի բարձր հասանելիությունը ազդում են, թե որ հանգույցն է տեսնում վերադարձի թրաֆիկը, և կլաստերի աջակցվող վիճակի մոդելը որոշում է՝ դա ընդունելի է արդյոք։
Հետևեք վերադարձի ուղուն հստակ յուրաքանչյուր հոսքի համար, որը ձեզ համար կարևոր է։ NAT-ը այդ աշխատանքի համընդհանուր փոխարինողը չէ, և դրա վրա հենվող նախագծերը սովորաբար բացը գտնում են failover-ի ժամանակ, ոչ թե կառուցման։
Անցեք մեկ պարտադիր հոսք և մեկ դիտավորյալ բացառված հոսք երկու ուղղություններով, նախքան նախագիծը հաստատելը։
Ինչպես ընտրել և ինչ փորձարկել ամեն դեպքում
Ընտրեք կենտրոնացված gateway-ը, երբ ստուգման ծածկույթն ավելի կարևոր է, քան տրանզիտային թողունակությունը, և դուք կարող եք թույլ տալ կենտրոնական կախվածությունը։ Ընտրեք բաշխված IRB-ն, երբ տեղական երթուղավորումն է նպատակը, և բյուջե դրեք հստակ ծառայության ներդրման համար՝ այն ենթադրելու փոխարեն։
Այնուհետև փորձարկեք այն երթուղավորումը, որը դուք իրականում տեղադրել եք, որովհետև հենց այնտեղ են երկու նախագծերն առավել տարբերվում։
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixՆերառեք թեստի մեջ ծառայության հանգույցի խափանումը և վերականգնումը։ Ստուգումը հանգիստ շրջանցող պահուստային երթուղին տարբեր որոշում է, քան պլանավորված fail-open քաղաքականությունը, և սովորաբար նախատեսված է դրանցից միայն մեկը։ Ավարտված նախագիծը նշում է, թե որտեղ է երթուղավորվում թրաֆիկի յուրաքանչյուր դասը, որտեղ է այն ստուգվում, և ինչ է տեղի ունենում, երբ այդ ստուգման ուղին հասանելի չէ։