VxLAN գործարան. Մաս 3

Բարև, Հաբր: Ես ավարտում եմ հոդվածների շարքը, նվիրված դասընթացի մեկնարկին «Ցանցային ինժեներ» OTUS-ից, օգտագործելով VxLAN EVPN տեխնոլոգիան՝ գործվածքի ներսում երթուղղելու համար և օգտագործելով Firewall՝ ներքին ծառայությունների միջև մուտքը սահմանափակելու համար

Շարքի նախորդ մասերը կարող եք գտնել հետևյալ հղումներով.

• Ցիկլի 1-ին մաս - L2 կապ սերվերների միջև
• Շարքի 2-րդ մաս - Ուղղորդում VNI-ների միջև
• Շարքի 2.5 մաս - Տեսական շեղում

Այսօր մենք կշարունակենք ուսումնասիրել երթուղային տրամաբանությունը VxLAN գործվածքի ներսում: Նախորդ մասում մենք դիտարկեցինք ներգործվածքների երթուղին մեկ VRF-ի շրջանակներում: Այնուամենայնիվ, ցանցում կարող է լինել հաճախորդների ծառայությունների հսկայական քանակ, և դրանք բոլորը պետք է բաշխվեն տարբեր VRF-ների մեջ՝ նրանց միջև հասանելիությունը տարբերակելու համար: Ի լրումն ցանցի բաժանման, բիզնեսը կարող է կարիք ունենալ միացնել Firewall-ը, որպեսզի սահմանափակի մուտքն այս ծառայությունների միջև: Այո, սա լավագույն լուծումը չի կարելի անվանել, բայց ժամանակակից իրողությունները պահանջում են «ժամանակակից լուծումներ»։

Դիտարկենք VRF-ների միջև երթուղղման երկու տարբերակ.

1. Ուղղորդում առանց VxLAN գործվածքից դուրս գալու;
2. Երթուղիավորում արտաքին սարքավորումների վրա:

Սկսենք VRF-ների միջև երթուղային տրամաբանությունից: Կան որոշակի թվով VRF-ներ: VRF-ների միջև երթուղղելու համար դուք պետք է ցանցում ընտրեք մի սարք, որը կիմանա բոլոր VRF-ների մասին (կամ մասերի, որոնց միջև անհրաժեշտ է երթուղում): Նման սարքը կարող է լինել, օրինակ, Leaf անջատիչներից մեկը (կամ բոլորը միանգամից) . Այս տոպոլոգիան կունենա հետևյալ տեսքը.

Որո՞նք են այս տոպոլոգիայի թերությունները:

Ճիշտ է, յուրաքանչյուր Leaf-ը պետք է իմանա ցանցի բոլոր VRF-ների (և դրանցում եղած բոլոր տեղեկատվության մասին), ինչը հանգեցնում է հիշողության կորստի և ցանցի ծանրաբեռնվածության ավելացման: Ի վերջո, հաճախ յուրաքանչյուր Leaf switch կարիք չունի իմանալու այն ամենի մասին, ինչ կա ցանցում:

Այնուամենայնիվ, եկեք ավելի մանրամասն քննարկենք այս մեթոդը, քանի որ փոքր ցանցերի համար այս տարբերակը բավականին հարմար է (եթե բիզնեսի հատուկ պահանջներ չկան)

Այս պահին դուք կարող եք հարց ունենալ, թե ինչպես փոխանցել տեղեկատվություն VRF-ից VRF, քանի որ այս տեխնոլոգիայի իմաստը հենց այն է, որ տեղեկատվության տարածումը պետք է սահմանափակվի:

Եվ պատասխանը կայանում է այնպիսի գործառույթների մեջ, ինչպիսիք են երթուղային տեղեկատվության արտահանումը և ներմուծումը (այս տեխնոլոգիայի կարգավորումը դիտարկվել է երկրորդ ցիկլի մասեր): Հակիրճ կրկնեմ.

VRF-ը AF-ում դնելիս պետք է նշեք route-target ներմուծման և արտահանման երթուղային տեղեկատվության համար: Դուք կարող եք այն ավտոմատ կերպով նշել: Այնուհետև արժեքը կներառի VRF-ի հետ կապված ASN BGP և L3 VNI: Սա հարմար է, երբ ձեր գործարանում ունեք միայն մեկ ASN.

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Այնուամենայնիվ, եթե ունեք մեկից ավելի ASN և պետք է երթուղիներ փոխանցեք նրանց միջև, ապա ձեռքով կազմաձևումը կլինի ավելի հարմար և մասշտաբային տարբերակ: route-target. Ձեռքով տեղադրման վերաբերյալ առաջարկությունն առաջին համարն է, օգտագործեք ձեզ հարմար մեկը, օրինակ. 9999.
Երկրորդը պետք է սահմանվի որպես VNI-ի հավասարություն այդ VRF-ի համար:

Եկեք կարգավորենք այն հետևյալ կերպ.

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

Ինչ տեսք ունի երթուղային աղյուսակում.

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Դիտարկենք VRF-ների միջև երթուղիների երկրորդ տարբերակը՝ արտաքին սարքավորումների միջոցով, օրինակ՝ Firewall-ը:

Արտաքին սարքի միջոցով աշխատելու մի քանի տարբերակ կա.

1. Սարքը գիտի, թե ինչ է VxLAN-ը, և մենք կարող ենք այն ավելացնել գործվածքների մի մասում;
2. Սարքը ոչինչ չգիտի VxLAN-ի մասին:

Մենք չենք կանգնի առաջին տարբերակի վրա, քանի որ տրամաբանությունը գրեթե նույնն է լինելու, ինչ ցույց է տրված վերևում.

Դիտարկենք երկրորդ տարբերակը, երբ մեր Firewall-ը ոչինչ չգիտի VxLAN-ի մասին (այժմ, իհարկե, հայտնվում է VxLAN աջակցությամբ սարքավորում։ Օրինակ՝ Checkpoint-ը հայտարարել է իր աջակցության մասին R81 տարբերակով։ Կարող եք կարդալ դրա մասին։ այստեղ, սակայն, այս ամենը փորձարկման փուլում է, և շահագործման կայունության նկատմամբ վստահություն չկա):

Արտաքին սարքը միացնելիս մենք ստանում ենք հետևյալ դիագրամը.

Ինչպես երևում է գծապատկերից, Firewall-ի հետ ինտերֆեյսի վրա հայտնվում է խցան: Սա պետք է հաշվի առնել ապագայում ցանցը պլանավորելիս և ցանցային տրաֆիկը օպտիմալացնելիս:

Այնուամենայնիվ, վերադառնանք VRF-ների միջև երթուղավորման սկզբնական խնդրին: Firewall-ի ավելացման արդյունքում մենք գալիս ենք այն եզրակացության, որ Firewall-ը պետք է իմանա բոլոր VRF-ների մասին։ Դա անելու համար բոլոր VRF-ները նույնպես պետք է կազմաձևվեն եզրագծային Leafs-ի վրա, և Firewall-ը պետք է միացված լինի յուրաքանչյուր VRF-ին առանձին հղումով:

Արդյունքում, Firewall-ով սխեման.

Այսինքն, Firewall-ում դուք պետք է ինտերֆեյս կարգավորեք ցանցում տեղակայված յուրաքանչյուր VRF-ի համար: Ընդհանուր առմամբ, տրամաբանությունը բարդ տեսք չունի, և միակ բանը, որ ինձ դուր չի գալիս այստեղ, Firewall-ի վրա ինտերֆեյսների հսկայական քանակն է, բայց այստեղ ժամանակն է մտածել ավտոմատացման մասին:

Լավ: Մենք միացրինք Firewall-ը և ավելացրինք այն բոլոր VRF-ներին: Բայց ինչպե՞ս կարող ենք այժմ ստիպել տրաֆիկին յուրաքանչյուր տերևից անցնել այս Firewall-ով:

Firewall-ին միացված Leaf-ում խնդիրներ չեն առաջանա, քանի որ բոլոր երթուղիները տեղական են.

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Այնուամենայնիվ, ինչ վերաբերում է հեռավոր Leafs-ին: Ինչպե՞ս փոխանցել նրանց լռելյայն արտաքին երթուղին:

Ճիշտ է, EVPN երթուղու տիպի 5-ի միջոցով, ինչպես ցանկացած այլ նախածանց VxLAN գործվածքի վրա: Այնուամենայնիվ, սա այնքան էլ պարզ չէ (եթե մենք խոսում ենք Cisco-ի մասին, քանի որ ես չեմ ստուգել այլ վաճառողների հետ)

Նախնական երթուղին պետք է գովազդվի այն Leaf-ից, որին միացված է Firewall-ը: Այնուամենայնիվ, երթուղին փոխանցելու համար Leaf-ը պետք է ինքն իրեն իմանա: Եվ այստեղ որոշակի խնդիր է առաջանում (գուցե միայն ինձ համար), երթուղին պետք է ստատիկ գրանցվի VRF-ում, որտեղ դուք ցանկանում եք գովազդել նման երթուղի.

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Հաջորդը, BGP-ի կազմաձևում, սահմանեք այս երթուղին AF IPv4-ում.

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Այնուամենայնիվ, սա դեռ ամենը չէ: Այս կերպ լռելյայն երթուղին չի ներառվի ընտանիքում l2vpn evpn. Բացի դրանից, դուք պետք է կարգավորեք վերաբաշխումը.

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Մենք նշում ենք, թե որ նախածանցները կմտնեն BGP վերաբաշխման միջոցով

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Այժմ նախածանցը 0.0.0.0/0 ընկնում է EVPN երթուղու տիպի 5-ի մեջ և փոխանցվում է տերևի մնացած հատվածին.

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

BGP աղյուսակում մենք կարող ենք նաև դիտարկել ստացված երթուղու տիպ 5-ը լռելյայն երթուղով 10.255.1.5-ի միջոցով:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Սրանով ավարտվում է EVPN-ին նվիրված հոդվածաշարը։ Ապագայում ես կփորձեմ դիտարկել VxLAN-ի աշխատանքը Multicast-ի հետ համատեղ, քանի որ այս մեթոդը համարվում է ավելի լայնածավալ (ներկայումս հակասական հայտարարություն)

Եթե ​​դեռ ունեք հարցեր/առաջարկություններ թեմայի վերաբերյալ, մտածեք EVPN-ի ցանկացած ֆունկցիոնալության մասին - գրեք, մենք այն կքննարկենք հետագա:

Source: www.habr.com