Pabrika ng VxLAN. Bahagi 3

Hello, Habr. Tinatapos ko ang isang serye ng mga artikulo, nakatuon sa paglulunsad ng kurso "Network engineer" ng OTUS, gamit ang teknolohiyang VxLAN EVPN para sa pagruruta sa loob ng tela at paggamit ng Firewall upang paghigpitan ang pag-access sa pagitan ng mga panloob na serbisyo

Ang mga nakaraang bahagi ng serye ay matatagpuan sa mga sumusunod na link:

• 1 bahagi ng cycle - L2 connectivity sa pagitan ng mga server
• Bahagi 2 ng serye - Pagruruta sa pagitan ng mga VNI
• Bahagi 2.5 ng serye - Theoretical digression

Ngayon ay patuloy nating pag-aaralan ang lohika ng pagruruta sa loob ng tela ng VxLAN. Sa nakaraang bahagi, tiningnan namin ang intra-fabric routing sa loob ng isang VRF. Gayunpaman, maaaring mayroong isang malaking bilang ng mga serbisyo ng kliyente sa network, at lahat ng mga ito ay dapat na ipamahagi sa iba't ibang mga VRF upang maiba ang pag-access sa pagitan ng mga ito. Bilang karagdagan sa paghihiwalay ng network, maaaring kailanganin ng isang negosyo na ikonekta ang isang Firewall upang paghigpitan ang pag-access sa pagitan ng mga serbisyong ito. Oo, hindi ito matatawag na pinakamahusay na solusyon, ngunit ang mga modernong katotohanan ay nangangailangan ng "modernong solusyon".

Isaalang-alang natin ang dalawang opsyon para sa pagruruta sa pagitan ng mga VRF:

1. Pagruruta nang hindi umaalis sa tela ng VxLAN;
2. Pagruruta sa panlabas na kagamitan.

Magsimula tayo sa lohika ng pagruruta sa pagitan ng mga VRF. Mayroong isang tiyak na bilang ng mga VRF. Upang mag-ruta sa pagitan ng mga VRF, kailangan mong pumili ng device sa network na makakaalam tungkol sa lahat ng VRF (o mga bahagi kung saan kailangan ang pagruruta). . Ang topology na ito ay magiging ganito:

Ano ang mga disadvantages ng topology na ito?

Tama, kailangang malaman ng bawat Leaf ang tungkol sa lahat ng mga VRF (at lahat ng impormasyong nasa kanila) sa network, na humahantong sa pagkawala ng memorya at pagtaas ng pagkarga ng network. Pagkatapos ng lahat, madalas na ang bawat switch ng Leaf ay hindi kailangang malaman ang tungkol sa lahat ng nasa network.

Gayunpaman, isaalang-alang natin ang pamamaraang ito nang mas detalyado, dahil para sa mga maliliit na network ay angkop ang pagpipiliang ito (kung walang tiyak na mga kinakailangan sa negosyo)

Sa puntong ito, maaaring mayroon kang tanong tungkol sa kung paano ilipat ang impormasyon mula sa VRF patungo sa VRF, dahil ang punto ng teknolohiyang ito ay tiyak na ang pagpapakalat ng impormasyon ay dapat na limitado.

At ang sagot ay nasa mga function tulad ng pag-export at pag-import ng impormasyon sa pagruruta (ang pag-set up ng teknolohiyang ito ay isinasaalang-alang sa pangalawa bahagi ng cycle). Hayaan akong ulitin nang maikli:

Kapag nagtatakda ng VRF sa AF, dapat mong tukuyin route-target para sa impormasyon sa pag-import at pag-export sa pagruruta. Maaari mo itong awtomatikong tukuyin. Pagkatapos ay isasama sa value ang ASN BGP at L3 VNI na nauugnay sa VRF. Ito ay maginhawa kapag mayroon ka lamang isang ASN sa iyong pabrika:

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

Gayunpaman, kung mayroon kang higit sa isang ASN at kailangan mong maglipat ng mga ruta sa pagitan nila, kung gayon ang manu-manong pagsasaayos ay magiging isang mas maginhawa at nasusukat na opsyon. route-target. Ang rekomendasyon para sa manu-manong pag-setup ay ang unang numero, gumamit ng isa na maginhawa para sa iyo, halimbawa, 9999.
Ang pangalawa ay dapat itakda sa katumbas ng VNI para sa VRF na iyon.

I-configure natin ito gaya ng sumusunod:

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

Ano ang hitsura nito sa routing table:

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

Isaalang-alang natin ang pangalawang opsyon para sa pagruruta sa pagitan ng mga VRF - sa pamamagitan ng panlabas na kagamitan, halimbawa Firewall.

Mayroong ilang mga opsyon para sa pagtatrabaho sa pamamagitan ng panlabas na device:

1. Alam ng device kung ano ang VxLAN at maaari naming idagdag ito sa bahagi ng tela;
2. Walang alam ang device tungkol sa VxLAN.

Hindi kami magtatagal sa unang opsyon, dahil ang lohika ay halos pareho sa ipinapakita sa itaas - dinadala namin ang lahat ng VRF sa Firewall at i-configure ang pagruruta sa pagitan ng mga VRF dito.

Isaalang-alang natin ang pangalawang opsyon, kapag walang alam ang ating Firewall tungkol sa VxLAN (ngayon, siyempre, lumalabas ang kagamitan na may suporta sa VxLAN. Halimbawa, inanunsyo ng Checkpoint ang suporta nito sa bersyong R81. Mababasa mo ang tungkol dito dito, gayunpaman, lahat ito ay nasa yugto ng pagsubok at walang tiwala sa katatagan ng operasyon).

Kapag kumokonekta sa isang panlabas na aparato, nakukuha namin ang sumusunod na diagram:

Gaya ng nakikita mo mula sa diagram, may lalabas na bottleneck sa interface na may Firewall. Dapat itong isaalang-alang sa hinaharap kapag nagpaplano ng network at nag-optimize ng trapiko sa network.

Gayunpaman, bumalik tayo sa orihinal na problema ng pagruruta sa pagitan ng mga VRF. Bilang resulta ng pagdaragdag ng Firewall, dumating kami sa konklusyon na dapat malaman ng Firewall ang tungkol sa lahat ng VRF. Upang gawin ito, ang lahat ng mga VRF ay dapat ding i-configure sa mga dahon ng hangganan, at ang Firewall ay dapat na konektado sa bawat VRF na may hiwalay na link.

Bilang resulta, ang scheme na may Firewall:

Iyon ay, sa Firewall kailangan mong i-configure ang isang interface sa bawat VRF na matatagpuan sa network. Sa pangkalahatan, ang lohika ay hindi mukhang kumplikado at ang tanging bagay na hindi ko gusto dito ay ang malaking bilang ng mga interface sa Firewall, ngunit narito ang oras upang isipin ang tungkol sa automation.

ayos lang. Ikinonekta namin ang Firewall at idinagdag ito sa lahat ng VRF. Ngunit paano natin ngayon mapipilit ang trapiko mula sa bawat Dahon na dumaan sa Firewall na ito?

Sa Leaf na konektado sa Firewall, walang lalabas na problema, dahil lokal ang lahat ng ruta:

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

Gayunpaman, ano ang tungkol sa malalayong Leafs? Paano ipasa sa kanila ang default na panlabas na ruta?

Tama, sa pamamagitan ng EVPN route-type 5, tulad ng anumang prefix sa ibabaw ng VxLAN fabric. Gayunpaman, ito ay hindi gaanong simple (kung pinag-uusapan natin ang tungkol sa Cisco, dahil hindi ko pa nasuri sa ibang mga vendor)

Dapat na i-advertise ang default na ruta mula sa Leaf kung saan nakakonekta ang Firewall. Gayunpaman, upang maihatid ang ruta, dapat alam mismo ng Leaf ito. At narito ang isang tiyak na problema ay lumitaw (marahil para lamang sa akin), ang ruta ay dapat na nakarehistro nang statically sa VRF kung saan nais mong mag-advertise ng ganoong ruta:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Susunod, sa configuration ng BGP, itakda ang rutang ito sa AF IPv4:

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

Gayunpaman, hindi lang iyon. Sa ganitong paraan ang default na ruta ay hindi isasama sa pamilya l2vpn evpn. Bilang karagdagan dito, kailangan mong i-configure ang muling pamamahagi:

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

Ipinapahiwatig namin kung aling mga prefix ang papasok sa BGP sa pamamagitan ng muling pamamahagi

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

Ngayon ang prefix 0.0.0.0/0 nahuhulog sa EVPN route-type 5 at ipinapadala sa natitirang bahagi ng 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

Sa talahanayan ng BGP maaari din nating obserbahan ang nagreresultang uri ng ruta 5 na may default na ruta sa pamamagitan ng 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

Ito ay nagtatapos sa serye ng mga artikulo na nakatuon sa EVPN. Sa hinaharap, susubukan kong isaalang-alang ang pagpapatakbo ng VxLAN kasabay ng Multicast, dahil ang pamamaraang ito ay itinuturing na mas nasusukat (sa ngayon ay isang kontrobersyal na pahayag)

Kung mayroon ka pa ring mga tanong/suhestyon sa paksa, isaalang-alang ang anumang pagpapagana ng EVPN - sumulat, isasaalang-alang pa namin ito.

Pinagmulan: www.habr.com