🥇VxLAN зауыты. 3-бөлім

Сәлем, Хабр. Мен мақалалар топтамасын аяқтаймын, курсының ашылуына арналған «Желі инженері» OTUS арқылы, мата ішінде бағыттау үшін VxLAN EVPN технологиясын пайдалану және ішкі қызметтер арасындағы қатынасты шектеу үшін брандмауэрді пайдалану

Серияның алдыңғы бөліктерін келесі сілтемелерден табуға болады:

Бүгін біз VxLAN құрылымының ішіндегі маршруттау логикасын зерттеуді жалғастырамыз. Алдыңғы бөлімде біз бір VRF ішіндегі мата ішіндегі маршруттауды қарастырдық. Дегенмен, желіде клиенттік қызметтердің үлкен саны болуы мүмкін және олардың арасындағы қатынасты ажырату үшін олардың барлығы әртүрлі VRF-ге таратылуы керек. Желіні бөлуге қоса, бизнес осы қызметтер арасындағы қатынасты шектеу үшін желіаралық қалқанды қосу қажет болуы мүмкін. Иә, мұны ең жақсы шешім деп атауға болмайды, бірақ заманауи шындық «заманауи шешімдерді» талап етеді.

VRF арасындағы бағыттаудың екі нұсқасын қарастырайық:

VxLAN матасынан шықпай бағыттау;
Сыртқы жабдықта маршруттау.

VRF арасындағы маршруттау логикасынан бастайық. Белгілі бір VRF саны бар. VRF арасында бағыттау үшін желідегі барлық VRF (немесе олардың арасында бағыттау қажет бөліктер) туралы білетін құрылғыны таңдау керек.Мұндай құрылғы, мысалы, Leaf қосқыштарының бірі (немесе барлығы бірден) болуы мүмкін. . Бұл топология келесідей болады:

Бұл топологияның кемшіліктері қандай?

Дұрыс, әрбір жапырақ желідегі барлық VRF (және олардағы барлық ақпарат) туралы білуі керек, бұл жадтың жоғалуына және желі жүктемесінің жоғарылауына әкеледі. Өйткені, көбінесе әрбір Leaf қосқышы желідегі барлық нәрселер туралы білудің қажеті жоқ.

Дегенмен, бұл әдісті толығырақ қарастырайық, өйткені шағын желілер үшін бұл опция өте қолайлы (егер нақты бизнес талаптары болмаса)

Осы кезде сізде ақпаратты VRF-ден VRF-ге қалай тасымалдауға болатыны туралы сұрақ туындауы мүмкін, себебі бұл технологияның мәні ақпараттың таралуы шектелуі керек.

Жауап маршруттау ақпаратын экспорттау және импорттау сияқты функцияларда жатыр (бұл технологияны орнату осы мақалада қарастырылған секунд цикл бөліктері). Қысқаша қайталаймын:

AF режимінде VRF параметрін орнатқан кезде көрсету керек 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.
Екіншісін сол VRF үшін VNI тең етіп орнату керек.

Оны келесідей конфигурациялайық:

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.

Сыртқы құрылғы арқылы жұмыс істеудің бірнеше нұсқасы бар:

Құрылғы VxLAN не екенін біледі және біз оны матаның бір бөлігіне қоса аламыз;
Құрылғы VxLAN туралы ештеңе білмейді.

Біз бірінші нұсқаға тоқталмаймыз, өйткені логика жоғарыда көрсетілгендей дерлік болады - біз барлық VRF-терді брандмауэрге әкелеміз және ондағы VRF арасындағы маршруттауды конфигурациялаймыз.

Екінші нұсқаны қарастырайық, брандмауэр VxLAN туралы ештеңе білмейді (қазір, әрине, VxLAN қолдауы бар жабдық пайда болады. Мысалы, Checkpoint R81 нұсқасында қолдауын жариялады. Бұл туралы оқи аласыз. осында, дегенмен, мұның бәрі тестілеу сатысында және жұмыс тұрақтылығына сенім жоқ).

Сыртқы құрылғыны қосқанда біз келесі диаграмманы аламыз:

Диаграммадан көріп отырғаныңыздай, желіаралық қалқан интерфейсінде тығырық пайда болады. Бұл болашақта желіні жоспарлау және желілік трафикті оңтайландыру кезінде ескерілуі керек.

Дегенмен, VRF арасындағы бағыттаудың бастапқы мәселесіне оралайық. Брандмауэрді қосу нәтижесінде біз брандмауэр барлық VRF туралы білуі керек деген қорытындыға келеміз. Бұл әрекетті орындау үшін, барлық VRF-тер де Leafs шекарасында конфигурациялануы керек және брандмауэр әрбір VRF-ге бөлек сілтеме арқылы қосылуы керек.

Нәтижесінде желіаралық қалқанмен схема:

Яғни желіаралық қалқанда желіде орналасқан әрбір VRF интерфейсін конфигурациялау қажет. Жалпы, логика күрделі болып көрінбейді және маған ұнамайтын жалғыз нәрсе - желіаралық қалқандағы интерфейстердің көптігі, бірақ мұнда автоматтандыру туралы ойланатын кез келді.

Жақсы. Біз желіаралық қалқанды қосып, оны барлық VRF құрылғыларына қостық. Бірақ қазір біз әрбір жапырақтан трафикті осы желіаралық қалқан арқылы өтуге қалай мәжбүрлей аламыз?

Брандмауэрге қосылған жапырақта ешқандай проблемалар туындамайды, өйткені барлық маршруттар жергілікті:

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

Дегенмен, қашықтағы жапырақтар туралы не деуге болады? Оларға әдепкі сыртқы маршрутты қалай өткізуге болады?

Бұл дұрыс, VxLAN матасындағы кез келген басқа префикс сияқты 5-түрдегі EVPN маршруты арқылы. Дегенмен, бұл оңай емес (егер біз Cisco туралы айтатын болсақ, өйткені мен басқа жеткізушілермен тексермегенмін)

Әдепкі маршрут желіаралық қалқан қосылған жапырақтан жариялануы керек. Дегенмен, маршрутты жіберу үшін Жапырақ оны өзі білуі керек. Міне, белгілі бір мәселе туындайды (мүмкін тек мен үшін), маршрут 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 кез келген функционалдығын қарастырыңыз - жазыңыз, біз оны әрі қарай қарастырамыз.

Ақпарат көзі: www.habr.com

VxLAN зауыты. 3-бөлім

пікір қалдыру Жауапты болдырмау