🥇VxLAN фабрика. Част 3

Здравей, Хабр. Завършвам поредица от статии, посветен на стартирането на курса "Системен инженер" от OTUS, използвайки VxLAN EVPN технология за маршрутизиране в рамките на тъканта и използване на защитна стена за ограничаване на достъпа между вътрешни услуги

Предишни части от поредицата можете да намерите на следните линкове:

Днес ще продължим да изучаваме логиката на маршрутизиране във VxLAN структурата. В предишната част разгледахме маршрутизирането в рамките на един VRF. Възможно е обаче да има огромен брой клиентски услуги в мрежата и всички те трябва да бъдат разпределени в различни VRF, за да се разграничи достъпът между тях. В допълнение към разделянето на мрежата, бизнесът може да се наложи да свърже защитна стена, за да ограничи достъпа между тези услуги. Да, това не може да се нарече най-доброто решение, но съвременните реалности изискват „модерни решения“.

Нека разгледаме две опции за маршрутизиране между VRF:

Маршрутизиране без напускане на VxLAN тъканта;
Маршрутизиране на външно оборудване.

Нека започнем с логиката на маршрутизиране между VRF. Има определен брой VRF. За да маршрутизирате между VRF, трябва да изберете устройство в мрежата, което ще знае за всички VRF (или части, между които е необходимо маршрутизиране). Такова устройство може да бъде например един от превключвателите Leaf (или всички наведнъж) . Тази топология ще изглежда така:

Какви са недостатъците на тази топология?

Точно така, всеки лист трябва да знае за всички VRF (и цялата информация, която е в тях) в мрежата, което води до загуба на памет и увеличено натоварване на мрежата. В края на краищата доста често всеки Leaf превключвател не трябва да знае за всичко, което е в мрежата.

Нека обаче разгледаме този метод по-подробно, тъй като за малки мрежи тази опция е доста подходяща (ако няма специфични бизнес изисквания)

В този момент може да имате въпрос как да прехвърляте информация от VRF към VRF, тъй като целта на тази технология е точно разпространението на информация да бъде ограничено.

И отговорът се крие във функции като експортиране и импортиране на информация за маршрутизиране (настройването на тази технология беше разгледано в втори части от цикъла). Нека повторя накратко:

Когато настройвате VRF в AF, трябва да посочите route-target за информация за маршрутизиране на импортиране и експортиране. Можете да го посочите автоматично. Тогава стойността ще включва ASN BGP и L3 VNI, свързани с VRF. Това е удобно, когато имате само един 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.

Има няколко опции за работа чрез външно устройство:

Устройството знае какво е VxLAN и можем да го добавим към част от мрежата;
Устройството не знае нищо за VxLAN.

Няма да се спираме на първия вариант, тъй като логиката ще бъде почти същата, както е показано по-горе - пренасяме всички VRF в защитната стена и конфигурираме маршрутизирането между VRF на него.

Нека разгледаме втория вариант, когато нашата защитна стена не знае нищо за VxLAN (сега, разбира се, се появява оборудване с поддръжка на VxLAN. Например Checkpoint обяви поддръжката си във версия R81. Можете да прочетете за това тук, но всичко това е на етап тестване и няма увереност в стабилността на работата).

Когато свързваме външно устройство, получаваме следната диаграма:

Както можете да видите от диаграмата, в интерфейса със защитната стена се появява тясно място. Това трябва да се вземе предвид в бъдеще при планирането на мрежата и оптимизирането на мрежовия трафик.

Нека обаче се върнем към първоначалния проблем с маршрутизирането между VRF. В резултат на добавянето на защитната стена стигаме до заключението, че защитната стена трябва да знае за всички VRF. За да направите това, всички VRF трябва също да бъдат конфигурирани на граничните листове и защитната стена трябва да бъде свързана към всеки VRF с отделна връзка.

В резултат на това схемата със защитната стена:

Тоест на защитната стена трябва да конфигурирате интерфейс към всеки VRF, разположен в мрежата. Като цяло логиката не изглежда сложна и единственото нещо, което не ми харесва тук, е огромният брой интерфейси на защитната стена, но тук е време да помислим за автоматизацията.

Глоба. Свързахме защитната стена и я добавихме към всички VRF. Но как сега можем да принудим трафика от всяко листо да преминава през тази защитна стена?

На Leaf, свързан към защитната стена, няма да възникнат проблеми, тъй като всички маршрути са локални:

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

Но какво да кажем за отдалечените листа? Как да им предам външния маршрут по подразбиране?

Точно така, чрез EVPN route-type 5, като всеки друг префикс над VxLAN тъканта. Това обаче не е толкова просто (ако говорим за Cisco, тъй като не съм проверявал с други доставчици)

Маршрутът по подразбиране трябва да бъде обявен от листа, към който е свързана защитната стена. Въпреки това, за да предаде маршрута, 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 и се предава на останалата част от 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

В 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

Добавяне на нов коментар Отказване на отговора

Добавяне на нов коментар