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 комутатор не му е нужно да знае за всичко, което има в мрежата.

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

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

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

При задания VRF в AF е необходимо да се укаже route-target за импортиране и експортиране на маршрутна информация. Може да се зададе в автоматичен режим. Тогава в стойността ще попадне ASN BGP и L3 VNI, свързан с VRF. Това е удобно, когато в фабриката ви се използва само една ASN:

vrf контекст PROD20
  адресно семейство ipv4 unicast
    маршрутна цел експортиране авто      ! В автоматичен режим се експортира RT-65001:99000
    маршрутна цел импортиране авто

Но ако имате повече от една ASN и е необходимо да предавате маршрути между тях, по-удобният и мащабируем вариант ще бъде ръчното настройване route-target. Препоръката за ръчно настройване — първото число, използвайте удобно за вас, например, 9999.
Второто следва да бъде равно на VNI за този VRF.

Нека настроим по следния начин:

vrf контекст PROD10
  адресно семейство ipv4 unicast
    маршрутна цел експортиране 9999:99000          
    маршрутна цел импортиране 9999:99000
    маршрутна цел импортиране 9999:77000         ! Пример 1 импорт от друг VRF
    маршрутна цел импортиране 9999:88000         ! Пример 2 импорт от друг VRF

Как изглежда в таблицата за маршрутизация:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *via 10.255.1.20fault, [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.

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

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

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

Както се вижда от схемата — появява се тясно място на връзката с Firewall. Необходимо е да се вземе предвид това при планирането на мрежата и оптимизацията на мрежовия трафик.

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

В резултат на това схемата с Firewall:

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

Добре. Свързахме Firewall, добавихме го във всички VRF. Но как сега да накараме трафика от всеки Leaf да преминава през този Firewall?

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

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

Въпреки това, как да бъдем с отдалечените Leaf? Как да им предадем външен маршрут по подразбиране?

Верно, чрез EVPN route-type 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 route-type 5 и се предава на останалите Leaf:

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

В таблицата BGP също можем да наблюдаваме получен route-type 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 — пишете, ще го обсъдим допълнително.

Източник: habr.com