Здравейте, и първо малко лирика. Понякога завиждам на колегите, които работят дистанционно — прекрасно е да имаш възможността да работиш от всяко място, свързано с Internet, почивка по всяко време, отговорност за проекти и срокове, а не да си в офис от 8 до 17. Моята позиция и работни задължения практически изключват възможността за дълго отсъствие от датацентъра. Все пак — периодично се случват интересни случаи, подобни на описания по-долу — и осъзнавам, че има малко позиции, в които има такова пространство за творческо изразяване на вътрешния troubleshooter.
Небольшо предупреждение — в момента на написването на статията случаят все още не е решен, но имайки предвид скоростта на отговор на доставчиците, пълното решение може да отнеме още месеци, а искам да споделя откритията си веднага. Надявам се, уважавани читатели, да ми простите тази припряност. Но достатъчно с водата — какво се случва с случая?
Първо малко въведение: има фирма (където работя като мрежов инженер), която хоства клиентски решения в частно облако VMWare. Повечето нови решения се свързват към VXLAN сегменти, управлявани от NSX-V — не бих искал да оценявам колко време ми спести това решение, накратко казано — много. Успях дори да обуча колегите да конфигурират NSX ESG и малки клиентски решения вече се разгръщат без моето участие. Важно уточнение — control plane при нас е с unicast репликация. Хипервизорите са свързани излишно с два интерфейса към различни физически комутатори Juniper QFX5100 (сглобени в Virtual Chassis) и политиката за синхронизация е route based on originating virtual port — за пълнота.
Клиентските решения са много разнообразни: от Windows IIS, където всички компоненти на уеб сървъра са инсталирани на една машина, до доста големи — например load-balanced Apache уеб фронтове + LB MariaDB в Galera + сървъри за споделяне, синхронизирани с помощта на GlusterFS. Почти всеки сървър трябва да се наблюдава поотделно, а публични IP адреси нямат всички компоненти — ако сте се сблъсквали с тази задача и имате по-елегантно решение, ще се радвам на съвет.
Моето решение за мониторинг се състои в "подключването" на фаервола (Fortigate) към всяка вътрешна клиентска мрежа (+SNAT и, разбира се, строги ограничения по отношение на разрешения трафик) и наблюдение на вътрешните адреси - по този начин се постига някаква унификация и опростяване на мониторинга. Самият мониторинг се извършва от клъстера на сървърите PRTG. Схемата на мониторинга изглежда горе-долу така:
Докато работехме само с VLAN, всичко беше напълно нормално и предсказуемо работеше, като часовник. След внедряването на NSX-V и VXLAN се сблъскахме с въпроса - може ли да продължим мониторинга по стария начин? В момента на поставяне на този въпрос най-бързото решение беше да се разположи NSX ESG и да се свърже VXLAN trunk интерфейс в VTEP мрежата. Бързо в кавички - тъй като използването на GUI за конфигуриране на клиентски мрежи, SNAT и правила на фаервола може и да унифицира управлението в единен интерфейс vSphere, но според мен е доста тромаво и освен всичко друго ограничава набора от инструменти за отстраняване на проблеми. Тези, които са използвали NSX ESG като заместител на "истинския" фаервол, мисля, че ще се съгласят. Въпреки това, вероятно, такова решение би било по-стабилно - все пак всичко се случва в рамките на един доставчик.
Още едно решение е да се използва NSX DLR в режим на бридж между VLAN и VXLAN. Тук мисля, че всичко е ясно – просто потенциалът от приложението на VXLAN се губи, защото все пак трябва да се прекарат VLAN към инсталацията за мониторинг. Между другото, по време на разработката на това решение се сблъсках с проблема, при който DLR-бриджът не изпращаше пакети до виртуалната машина, с която се намираше на един хост. Знам, знам – в книгите и указанията за NSX-V е посочено, че за NSX Edge трябва да бъде предоставен отделен клъстер, но това е в книгите… В крайна сметка, след няколко месеца с поддръжката, не успяхме да решим проблема. В принципе разбрах логиката – модулът на хипервизора, отговорен за инкапсулацията на VXLAN, не се активираше, ако DLR и наблюдаваният сървър бяха на един хост, тъй като трафикът не напуска хоста и според логиката трябва да бъде свързан към сегмента VXLAN – инкапсулацията не е необходима. С поддръжката стигнахме до виртуалния интерфейс vdrPort, който логически обединява аплинковете и осъществява бриджиране/инкапсулация – там беше забелязано несъответствие във входящия трафик, което взех за обработка в текущия случай. Но както беше казано, не довърших този случай, тъй като бях пренасочен към друг проект, освен това клонът първоначално беше без изход и нямах особено желание да го развивам. Ако не се лъжа, проблемът се наблюдаваше в версии на NSX 6.1.4 и 6.2.
И тук – бинго! Fortinet анонсира нативна . И не просто point-to-point или VXLAN-over-IPSec, не софтуерен бриджинг VLAN-VXLAN – всичко това започна да се внедрява още от версия 5.4 (и е представено и от други ), а настоящата поддръжка unicast control plane. При внедряване на решението се сблъсках с още един проблем — проверяваните сървъри периодично „изчезваха“ и след това отново се появяваха в мониторинга, въпреки че самата виртуална машина беше активна. Причината, както се оказа, беше, че забравих да разреша Ping на VXLAN-интерфейса. По време на ребалансирането на клъстерите виртуалките се местеха, а с Ping’а завършваше vMotion, за да обозначи новия ESXI хост, на който се е преместила машината. Глупост от моя страна, но този проблем отново подрива доверието в поддръжката на производителя — в този случай Fortinet. Да не споменавам, че всеки случай, свързан с VXLAN, започва с въпроса „къде ви е настройката на софтуерния комутатор VLAN-VXLAN?“ Тази връзка ми беше предложена да променя MTU — това е за Ping’а, който е 32 байта. След това „поиграй се“ с tcp-send-mss и tcp-receive-mss в политиката — за VXLAN, който се инкапсулира в UDP. Уф, извинявайте — просто накипя. В обобщение, реших този проблем самостоятелно.
След успешното тестване на трафика, беше решено да внедрим това решение. И в продукцията се оказа, че след ден-два постепенно всичко, което се мониторира през VXLAN, започва да „отпада“. Деактивацията/активацията на интерфейса помагаше, но само за известно време. Имайки предвид бавното действие на поддръжката на производителя, се заех с проследяването на проблемите от своя страна — в крайна сметка моята компания, моята мрежа — моя отговорност.
Под спойлера е ходът на желаещите да се занимават с проследяването на проблемите. Който е уморен от букви и хвалби — нека пропусне и премине директно към пост-анализата.
Ход на проследяване на проблемитеБлагодаря, че продължихте да четете — да продължим!
И така, мониторингът работи известно време, след което сам по себе си „отпада“. Значи проблеми в политиките на фаервола вероятно няма. Въпреки това, тъй като съм се сблъсквал с проблеми със засядащи системни процеси в Fortigate версии 5.6+, първо поглеждам „diagnose debug flow“ — очаквано трафикът се разрешава и напуска интерфейса, а очаквано нищо не идва в отговор. Значи продължаваме по стека. За съжаление, ще трябва да скрия адресите дори и да са RFC1918, но се надявам да снабдя процеса с достатъчно описание за разбиране. Сървърът вътре в VXLAN има адрес х.х.х.15, интерфейсът на Fortigate е х.х.х.254, а всички останали адреси принадлежат на мрежата VTEP.
За успешното предаване на VXLAN инкапсулирани пакети е необходимо наличие на коректна информация в няколко таблици. За overlay това са ARP и OVSDB, а за underlay са ARP и CAM. В случая на Fortigate, VXLAN FDB е също OVSDB. Там ще започнем:
fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=у.у.у.47 port=4789 vni=5008 ifindex=7
Тук всичко е достатъчно просто — MAC адресът на виртуалната машина трябва да се намира на VTEP с адрес у.у.у.47. Проверявайки съдържанието и настройките на ESXI клъстера, установявам, че MAC адресът на виртуалната машина е верен, а адресът на VTEP също. Проверявам CAM/ARP таблицата на Fortigate — отново всичко съвпада с настройките на ESXI хоста:
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
Таблиците са верни и трафикът си отива — може би проблемът не е във Fortigate? Умишлено пропуснах анализа на комутацията на трафика на Juniper — логиката е, че там следва да се направи следващата стъпка в тръблшутинга, но мрежата ми е проста — има само един VLAN за VTEP и всички компоненти са свързани директно. Плюс си припомням случая с DLR моста, VDR и изчезващия трафик — отивам да sniff на ESXI хоста, като същевременно създавам случай вече за VMWare. По-долу MAC „97:6e“ принадлежи на Fortigate, vmnic1 — това е интерфейсът, който има VTEP с адрес у.у.у.47, sniffing в двете посоки "—dir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Напредък — в sniff-а виждам ARP запитване и идващ отговор. Показвам само ARP отговора и там всичко е вярно. Не споменах, но през цялото време сървърът за мониторинг пингова адрес х.х.х.15 — къде е ICMP трафикът? Спомням си, че имам два uplink-a. Тук може да се според и да се каже, че виртуалният порт на източника е един и същ (моята политика за свързване), т.е. за една и съща vNIC трябва да се избира един и същ uplink, но понеже съм на хоста, проверката на другия uplink не е проблем:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Получават се заявки от Fortigate, но отговори няма. Тоест, проблемът не е във Fortigate. Е, всичко — мисля си — пак същият проблем с изчезващия трафик на VDR, отново за няколко месеца насочване на случая в правилната посока. След няколко дни, след като се успокоих и не желаейки да се примиря с пречката, реших да събера допълнителни sniff-ове за поддръжката, за да ускоря процеса. И тук „случайно“ погледът ми пада на Ethernet инкапсуляцията underlay. Царят не е истински и MAC адресът на VTEP не съвпада с неговия IP. Нулирам, sniff-ам, копая — вярно е, че не е вярно. Ще поставя ARP таблица до мен, за да е по-удобно за сравнение. Обърнете внимание на първата Ethernet инкапсуляция на картинката горе:
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep у.у.у.42
у.у.у.42 0 00:50:56:6a:78:86 dmz
И така, какво имаме в крайна сметка — след миграцията на виртуалната машина, Fortigate се опитва да изпрати трафик на VTEP от (коректната) VXLAN FDB, но използва неправилен DST MAC и трафикът логично се отхвърля от интерфейса на хипервизора, който го получава. В един случай от четири, този MAC принадлежеше на изходния хипервизор, от който започнахме миграцията на машината.
Вчера получих имейл от техническата поддръжка на Fortinet — по моя случай е отворен бъг 615586. Направо не знам дали да се радвам или да се оплаквам: от една страна — проблемът не е в настройките, от друга — корекцията ще дойде само с обновление на фърмуера, в най-добрия случай следващото. ЧСВ подогрява също друг бъг, който открих миналия месец, но в този случай в HTML5 GUI vSphere. Направо локален QA отдел при вендорите...
Рискнувам да предположа следното:
1 — multicast контролният план вероятно няма да бъде подложен на описания проблем — тъй като MAC адресите на VTEP се получават от IP адреса на групата, на която е подписан интерфейсът.
2 — вероятно проблемът на Fortigate е в офлоуда на сесиите на Network Processor (приблизително аналог на CEF) — ако пропускате всеки пакет през CPU, ще се използват таблици, съдържащи верната — поне визуално — информация. В подкрепа на това предположение е фактът, че помага да затворите/отворите интерфейса или да изчакате известно време — над 5 минути.
3 — промяната на политиката на екипиране, например на explicit failover, или внедряването на LAG, няма да реши проблема, тъй като се наблюдава „застряване“ на MAC адреса на изходния хипервизор в инкапсулираните пакети.
В светлината на това мога да споделя, че наскоро открих за себе си , където в една от статиите се твърдеше, че stateful фаерволи и кешируеми методи за предаване на данни са просто опорни точки. Както и да е, не съм толкова опитен в ИТ, за да правя подобни твърдения, освен това не съм напълно съгласен с всички твърдения в блог статиите. Въпреки това, нещо ми подсказва, че в думите на Иван има доза истина.
Благодаря за вниманието! Ще се радвам да отговоря на въпроси и да чуя конструктивна критика.
Източник: habr.com
