🥇 ffatri VxLAN. Rhan 3

Helo, Habr. Rwy'n gorffen cyfres o erthyglau, ymroddedig i lansiad y cwrs "Peiriannydd rhwydwaith" gan OTUS, defnyddio technoleg VxLAN EVPN ar gyfer llwybro o fewn y ffabrig a defnyddio Firewall i gyfyngu mynediad rhwng gwasanaethau mewnol

Mae rhannau blaenorol y gyfres i'w gweld trwy'r dolenni canlynol:

Heddiw, byddwn yn parhau i astudio'r rhesymeg llwybro y tu mewn i ffabrig VxLAN. Yn y rhan flaenorol, buom yn edrych ar lwybro mewn-ffabrig o fewn un VRF. Fodd bynnag, efallai y bydd nifer enfawr o wasanaethau cleient yn y rhwydwaith, a rhaid dosbarthu pob un ohonynt i wahanol VRFs i wahaniaethu mynediad rhyngddynt. Yn ogystal â gwahanu rhwydwaith, efallai y bydd angen i fusnes gysylltu Mur Tân i gyfyngu mynediad rhwng y gwasanaethau hyn. Oes, ni ellir galw hwn yn ateb gorau, ond mae realiti modern yn gofyn am “atebion modern”.

Gadewch i ni ystyried dau opsiwn ar gyfer llwybro rhwng VRFs:

Llwybro heb adael y ffabrig VxLAN;
Llwybro ar offer allanol.

Gadewch i ni ddechrau gyda'r rhesymeg llwybro rhwng VRFs. Mae yna nifer penodol o VRF. Er mwyn llwybro rhwng VRFs, mae angen i chi ddewis dyfais yn y rhwydwaith a fydd yn gwybod am bob VRF (neu rannau y mae angen llwybro rhyngddynt) Gallai dyfais o'r fath fod, er enghraifft, yn un o'r switshis Leaf (neu i gyd ar unwaith) . Bydd y topoleg hon yn edrych fel hyn:

Beth yw anfanteision y dopoleg hon?

Mae hynny'n iawn, mae angen i bob Dail wybod am yr holl VRFs (a'r holl wybodaeth sydd ynddynt) ar y rhwydwaith, sy'n arwain at golli cof a llwyth rhwydwaith cynyddol. Wedi'r cyfan, yn aml iawn nid oes angen i bob switsh Leaf wybod am bopeth sydd ar y rhwydwaith.

Fodd bynnag, gadewch i ni ystyried y dull hwn yn fwy manwl, oherwydd ar gyfer rhwydweithiau bach mae'r opsiwn hwn yn eithaf addas (os nad oes unrhyw ofynion busnes penodol)

Ar y pwynt hwn, efallai y bydd gennych gwestiwn am sut i drosglwyddo gwybodaeth o VRF i VRF, oherwydd pwynt y dechnoleg hon yn union yw y dylid cyfyngu ar ledaenu gwybodaeth.

Ac mae'r ateb yn gorwedd mewn swyddogaethau megis allforio a mewnforio gwybodaeth llwybro (ystyriwyd sefydlu'r dechnoleg hon yn 2 rhannau o'r cylch). Gadewch imi ailadrodd yn fyr:

Wrth osod VRF yn AF, rhaid i chi nodi route-target ar gyfer gwybodaeth llwybro mewnforio ac allforio. Gallwch ei nodi'n awtomatig. Yna bydd y gwerth yn cynnwys yr ASN BGP a L3 VNI sy'n gysylltiedig â'r VRF. Mae hyn yn gyfleus pan mai dim ond un ASN sydd gennych yn eich ffatri:

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

Fodd bynnag, os oes gennych fwy nag un ASN a bod angen trosglwyddo llwybrau rhyngddynt, yna bydd cyfluniad â llaw yn opsiwn mwy cyfleus a graddadwy. route-target. Yr argymhelliad ar gyfer gosod â llaw yw'r rhif cyntaf, defnyddiwch un sy'n gyfleus i chi, er enghraifft, 9999.
Dylid gosod yr ail i fod yn gyfartal â'r VNI ar gyfer y VRF hwnnw.

Gadewch i ni ei ffurfweddu fel a ganlyn:

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

Sut mae'n edrych yn y tabl llwybro:

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

Gadewch i ni ystyried yr ail opsiwn ar gyfer llwybro rhwng VRFs - trwy offer allanol, er enghraifft Firewall.

Mae yna sawl opsiwn ar gyfer gweithio trwy ddyfais allanol:

Mae'r ddyfais yn gwybod beth yw VxLAN a gallwn ei ychwanegu at ran o'r ffabrig;
Nid yw'r ddyfais yn gwybod dim am VxLAN.

Ni fyddwn yn canolbwyntio ar yr opsiwn cyntaf, gan y bydd y rhesymeg bron yr un fath â'r hyn a ddangosir uchod - rydym yn dod â phob VRF i'r Firewall ac yn ffurfweddu llwybro rhwng VRFs arno.

Gadewch i ni ystyried yr ail opsiwn, pan nad yw ein Mur Tân yn gwybod dim am VxLAN (nawr, wrth gwrs, mae offer gyda chefnogaeth VxLAN yn ymddangos. Er enghraifft, cyhoeddodd Checkpoint ei gefnogaeth yn fersiwn R81. Gallwch ddarllen amdano yma, fodd bynnag, mae hyn i gyd yn y cam profi ac nid oes hyder yn sefydlogrwydd gweithrediad).

Wrth gysylltu dyfais allanol, rydym yn cael y diagram canlynol:

Fel y gallwch weld o'r diagram, mae tagfa yn ymddangos yn y rhyngwyneb â'r Firewall. Rhaid ystyried hyn yn y dyfodol wrth gynllunio'r rhwydwaith a gwneud y gorau o draffig rhwydwaith.

Fodd bynnag, gadewch i ni ddychwelyd at y broblem wreiddiol o lwybro rhwng VRFs. O ganlyniad i ychwanegu'r Firewall, rydym yn dod i'r casgliad bod yn rhaid i'r Firewall wybod am bob VRF. I wneud hyn, mae'n rhaid i bob VRF hefyd gael ei ffurfweddu ar y Leafs ffin, a rhaid i'r Firewall gael ei gysylltu â phob VRF gyda dolen ar wahân.

O ganlyniad, mae'r cynllun gyda Firewall:

Hynny yw, ar y Firewall mae angen i chi ffurfweddu rhyngwyneb i bob VRF sydd wedi'i leoli ar y rhwydwaith. Yn gyffredinol, nid yw'r rhesymeg yn edrych yn gymhleth a'r unig beth nad wyf yn ei hoffi yma yw'r nifer enfawr o ryngwynebau ar y Firewall, ond yma mae'n bryd meddwl am awtomeiddio.

Iawn. Fe wnaethon ni gysylltu'r Firewall a'i ychwanegu at bob VRF. Ond sut allwn ni nawr orfodi traffig o bob Deilen i fynd trwy'r Mur Tân hwn?

Ar Leaf sy'n gysylltiedig â'r Mur Tân, ni fydd unrhyw broblemau'n codi, gan fod pob llwybr yn lleol:

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

Fodd bynnag, beth am Leafs anghysbell? Sut i basio'r llwybr allanol rhagosodedig iddynt?

Mae hynny'n iawn, trwy fath llwybr EVPN 5, fel unrhyw rhagddodiad arall dros y ffabrig VxLAN. Fodd bynnag, nid yw hyn mor syml (os ydym yn siarad am Cisco, gan nad wyf wedi gwirio gyda gwerthwyr eraill)

Rhaid hysbysebu'r llwybr rhagosodedig o'r Leaf y mae'r Mur Tân wedi'i gysylltu â hi. Fodd bynnag, i drosglwyddo'r llwybr, rhaid i Leaf ei wybod ei hun. Ac yma mae problem benodol yn codi (efallai i mi yn unig), rhaid i'r llwybr gael ei gofrestru'n statig yn y VRF lle rydych chi am hysbysebu llwybr o'r fath:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Nesaf, yn y ffurfweddiad BGP, gosodwch y llwybr hwn yn AF IPv4:

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

Fodd bynnag, nid dyna'r cyfan. Fel hyn ni fydd y llwybr rhagosodedig yn cael ei gynnwys yn y teulu l2vpn evpn. Yn ogystal â hyn, mae angen i chi ffurfweddu ailddosbarthu:

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

Rydym yn nodi pa rhagddodiaid fydd yn mynd i mewn i BGP trwy ailddosbarthu

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

Yn awr y rhagddodiad 0.0.0.0/0 yn disgyn i fath llwybr EVPN 5 ac yn cael ei drosglwyddo i weddill Leaf:

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

Yn y tabl BGP gallwn hefyd arsylwi ar y llwybr math 5 sy'n deillio o hynny gyda'r llwybr rhagosodedig trwy 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

Mae hyn yn cloi'r gyfres o erthyglau sydd wedi'u neilltuo i EVPN. Yn y dyfodol, byddaf yn ceisio ystyried gweithrediad VxLAN ar y cyd ag Multicast, gan fod y dull hwn yn cael ei ystyried yn fwy graddadwy (datganiad dadleuol ar hyn o bryd)

Os oes gennych gwestiynau / awgrymiadau o hyd ar y pwnc, ystyriwch unrhyw ymarferoldeb EVPN - ysgrifennwch, byddwn yn ei ystyried ymhellach.

Ffynhonnell: hab.com

ffatri VxLAN. Rhan 3

Ychwanegu sylw Diddymu ateb