Надо отметить, что icmp-пакеты (генерируемые командой ping) - это приоритетные для роутера задачи. Т.е. пока он их не отработает, никакие другие пакеты он обрабатывать не будет.
............
Это влечет за собой два вывода:
роутер занимается только icmp пакетами (детектирует и делает ответы, если ip не в бане). Но очередь icmp пакетов растет, потому как не успевает отправлять ответы ввиду низкой скорости канала.
никакие другие пакеты в это время не обрабатываются. Даже пакеты pptp, предназначенные для проверки работоспособности соединения. И одна из сторон, видя нарушение работы протокола, считает соединение разорванным. Это вторая причина, почему рвется соединение.
Я как "инфраструктурщик" с бэкграундом в сетях, такого еще не слышал :)
Ваши выводы выше - являются субъективной "фантазией" о том, как работает сетевое железо роутера. Максимально приоритетными задачами являются роутинг (поддержание работы протоколов динамической маршрутизации и наполнения таблиц форвардинга). Высокий pps ICMP так или иначе будет "резаться" CoPP - такие преднастройки имеет сейчас фактически каждый (даже домашний) маршрутизатор из коробки. Конечно поведение и преднастройки меняются от вендора к вендору и модели оборудования, но ICMP в приоритетах разделения процессорного времени современных моделей где-то "cнизу" уже долгое время (наверное как раз с тех времен, когда было можно еще сделать PingOfDead).
Вероятно у Вас был в полку CPU из-за генерации большого количества логов FW, а не из-за ICMP:
Такое большое количество выставлено в отладочных целях. Чтобы лог роутера поменьше загаживался.
А количество обрабатываемых pps всяких разных пакетов (служебных) - это CoPP. И настройка в 20k pps для ICMP для "филиального" роутера - абсолютный overhead (предположу что это значение по умолчанию от вендора - а значит значимо влиять на CPU не должно было).
В целом сдается мне, что дело не в ICMP как таковом, а каких-то настройках Алисы - почему у меня и десятков тысяч людей использующих любых провайдеров дома, в том числе и для Алисы - "проблем с ICMP" не возникло, где массовость? Вы снимали и раскуривали содержимое дампа?
На srv2 придет (AD directly-connected сети предпочтительней - сеть на R8 в описании дана с "ошибкой" либо специально, либо по невнимательности - /294, но опираясь на то, что мы имеем прямой линк между R8 & SRV2 и на последнем маска /24 - думаю это опечатка. Если все же сеть там /29 - то трафик конечно пойдет по статическому маршруту через R9 и зайдет на SRV1)
Зашел почитать про стеки и как это ужасно и нашел еще и про WiFi :)
Про WiFi - больно будет клиенту или нет при -76dbm зависит от скорости установленного беспроводного линка и SNR. Может быть вполне не больно, а очень хорошо.
Вывод по вай-фай очень обобщенный - зона покрытия нужна и в случае low dencity, и в случае high dencity - но более производительные точки помогут работать более "современным" клиентам на более высоких скоростях:)
Про стекирование добавлю - это про подход к обеспечению хардварной отказоустойчивости группы коммутаторов и линков; упрощение логической топологии на L2 + для избегания блокирования линков (не говорите мне за MSTP - балансировка и администрирование могут быть довольно сложными даже на относительно тривиальных топологиях).
Да, ПО может сбоить. Да, обновлять его трудно и может быть больно. Но посмотрите с другой стороны - ПО может сбоить на любом узле и, к сожалению, это не бинарная сущность - "работает все" или "не работает ничего". Поэтому я бы не ложил это как однозначный "+" в сторону "отказа от виртуализации".
Цискин vPC и прочие пропиетарные варианты в этом плане берут лучшее от стека и добавляют "отказоустойчивости" на software-уровне. Но, прошу заметить, такое делают только в сторону "доступа" :)
А так, как написал коллега выше можно обойтись без всего этого, используя L3 Access в связке с VXLAN - но это не про существующие сети, которые надо как-то поддерживать сейчас.
Думаю, сравнение с OpenVPN в статье, которая написана в угоду пиара "как мы можем и какие услуги у нас есть" лишнее :)
Ибо я не вижу причин не использовать его (ну или другое решение) только лишь по причине "сложности" - как написали выше: разбираться обслуживающему персоналу так или иначе придется, что с Вашим решением, что с другим.
Оператор связи в классическом его понимании уже давно превратился в "трубу" - обязанность у которой только одна: обслуживать андерлей, да так чтобы "сеть зарезервирована, соединение не пропадет даже при разрыве оптических волокон в линках". А оверлейные сети оставьте энтерпрайзам.
А подскажите, почему не решили просто снимать рабочую нагрузку с хостов по одному (переводя их в режим обслуживания, к примеру) и уже потом их переключать в аристу для сбора LACP - и так step-by-step, по одному хосту перевести все на новые Leaf-коммутаторы. Схема с тем, что изменится system-id выглядит приятно - но все же может дать незначительный даунтайм для приклада в процессе переключения линков и сбора LACP.
С переводом шлюза - хорошая хитрость, не всегда очевидная, хоть и не сложная по сути - запомню)
Ну и по поводу:
"Возможность гибкого и почти неограниченного масштабирования сети на любом уровне в результате внедрения технологии VXLAN EVPN и дизайна Leaf-Spine."
Как вы собираетесь масштабировать сеть? Не на уровне топологии clos'а - там как раз все ясно, а на уровне выхода во внешнюю сеть, если capacity FW не будет хватать? Если не секрет - что за вендор был выбран на FW?
"The RSTP Port Information state machine (...) checks that the BPDU’s Message Age is less its MaxAge, and if not, will immediately age out the received information."
Т.е сообщение пройдя 20 свитчей просто отбросится.
Настройка эдж портов тут вообще ни при чем - по умолчанию все фул-дуплекс порты рассматриваются RSTP как p2p.
Скажем прямо - этот протокол НЕ масштабируем в рамках SP и имеет медленную сходимость. В 2008 году это имело место быть в сетях SP, сейчас же, по моему скромному мнению - это моветон.
Но никого не призываю конечно ничего делать - пока есть такие сети, я точно не останусь без работы))
Про случай из практики - проблемы возникают как раз когда такая "гирлянда" начинает то пропускать BPDU, то нет (и это может быть по разным причинам) - вот тогда-то и начинаются "штормы". Возможно, конечно, что установка cisco вам помогла в части надежности пропуска сих замечательных фреймов, но это частный случай - до первого не циско устройства в кольце (не поддерживающего пропиетарного r-pvst т.е)
Про диаметр - я не перепутал, это рекомендации IEEE. Да, может быть до 20 устройств в кольце (циска и другие вендоры "вскользь" разрешают это на Ваш страх и риск - рекомендации я видел такие же, как и от IEEE).
Но 37 устройств и даже 20 в кольце Л2 - это безумно много - и вот почему: при прохождении каждого хопа BPDU от корневого коммутатора "перерождается" каждым коммутатором и он из поля max age вычитает единичку - а это поле по умолчанию равно 20. Если maxage=0, то далее BPDU не отправится - поэтому понятия не имею, как у Вас Висели гирлянды из 28 и 32 коммутаторах (разве что там был BPDU-туннелинг и сами устройства на магистральных портах не работали в rSTP).
Так же, чем больше устройств в плоской л2 топологии - тем выше риск коллизий хешей, сбоя протокола или неудачной настройки и т.п - все, что выше было описано в статье повторять это я не буду
И это мы еще с Вами не обсудили то, что часть канальной ёмкости теряется просто так из-за блокировки порта протоколом RSTP (хотя на уровне Л3 её можно было бы использовать).
RSTP на магистральных портах собранных в кольца? Если при Вас ни разу не сбойнуло - значит масштаб опорных колец сети был ОЧЕНЬ маленький. У RSTP есть такое понятие как diameter - и при более 7 коммутаторах в кольце уже могут начаться side-effects, которые либо пытаются полечить с помощью тюнинга таймеров STP, либо с помощью натягивания другого костыля - MSTP с "сегментацией" по регионам. Но потом поддерживать это очень сложно, да и опять - масштабируемость и скорость сходимости просто отвратительные.
Я как раз своими руками одну из таких "опорных сетей" провайдера переводил на IP/MPLS - потому что по мере роста она столкнулась с чудовищными бродкаст-штормами. Хотя, когда была "маленькой" - все работало "как часы" (за исключением того, что сходимость сети оставляла желать лучшего)
P.S: Единственное, что можно добавить - что я это "наследие" переделывал в 2016 году. Сама архитектура, видимо, закладывалась еще в 2008 году)
Не понял, про какой "цифровой" двойник идет речь, но судя по словам:
«Система мониторинга нужна для того, чтобы на логическом уровне понимать, как трафик ходит между сетями, и иметь возможность предотвращать DDoS- и BGP-атаки, при которых злоумышленник получает доступ к интернет-соединению другого клиента сети и перехватывает его трафик», — уточнил СМИ генеральный директор Института исследований интернета Карен Казарян. По его мнению, такая система мониторинга маршрутов трафика по набору функций будет напоминать интернет-регистратор RIPE (отвечает за распределение IP-адресов по всему миру) и другие сетевые организации.
речь идет о BGP RPKI (против BGP hijacking) и создании некоего "удостоверяющего"/"контролирующего" центра, который не даст анонсить сети без RPKI. В целом инициатива хорошая (хоть и дублирует функциональность RIPE). Вопрос в том - что сделают по итогу.
Я поработал в двух провайдерах на позициях от саппорта до ведущего инженера и смею не согласиться с Вами. Управляемые коммутаторы ставятся в даже небольших провайдерах и не требуют космических денег на порт в условиях централизованной закупки. Даже "говно-палки" ISP может купить легаси циску\длинк за 1-2 тр за (24!) 100mbps порта (50-100 рублей за порт). Неуправляемые новые коммутаторы большой портовой ёмкости сейчас уже де-факто не встретишь. Управляемые коммутаторы нужны прежде всего самому провайдеру - чтобы "управлять" и "мониторить" сеть - конечно, если такие компетенции есть у саппорта\инженеров :) Объясняется это и финансовой моделью - как провайдеру узнать, что у Вас порезали кабель (нет линка) или же коммутатор сдох? По каждому вызову направлять Вам техника? А саппорт, которому Вы позвоните - он только и может, что назначить техника - ведь у него нет "глаз на сети". В общем это тоже деньги - и гораздо большие, чем стоимость порта управляемого коммутатора в разрезе на одного абонента :)
Тут, имхо (видел такое не раз и не два:)) - нет компетенций у обслуживающего персонала сети + нет желания что-то менять (отчасти потому что платят копейки и тот, кто "шарит" не будет там сидеть - в этом я больше чем уверен)
P.S: Можно подсмотреть на капче - есть ли LLDP\CDP трафик с порта - таким образом "понять" управляемый ли коммутатор или нет и его марку модель (в случае, если оно глобально включено на всех портах, а не только на аплинках)
Так я понял говорят именно о "броадкастинге" на L2 - т.е они в одном влане, хотя так не должно было быть (должны были быть в разных - похоже речь о приватном пиринге : https://kb.msk-ix.ru/ix/network/).
«Но гораздо эффективней и рациональней предоставить возможность сервису читать актуальные служебные сообщения OSPF (LSA) в режиме реального времени и таким образом логировать изменения на сети.»
А почему для этой цели выбран новый «велосипед» с GRE и OSPF до (каждой!) ноды под капотом - мне не понятно. Может быть объяснение кроется в том, что хотели получить «вендор-агностик» парсинг на конечной коробке (ospfwatcher)? Но были ли исследованы другие менее "инвазивные" в control-plane методы (например grpc/snmp, в конце-концов парсинг обычных log-сообщений)?
На мой взгляд такая реализация - это дополнительный оверхед + лишняя зависимость на control-plane для железок.
Поясню: имея соседство со всеми железками по OSPF в сети, можно случайно или намеренно выстрелить себе в ногу - например через объявление дефолтного маршрута с этой железки. Кроме того, OSPF может быть многозонным - в какой(их) зоне(ах) делается соседство через GRE?:)
Касаемо тематики самой статьи - для меня здесь виден чисто академический интерес. Ведь с точки зрения решения прикладных задач - у нас не один OSPF в сети может быть, а так же (i)BGP, EIGRP,ISIS, и даже RIP (во всех смыслах:)). На практике это говорит о ненадежности получения информации с данного инструмента для анализа изменений и прокладывания актуального пути трафика. В этом плане для анализа лучше использовать снапшоты таблицы маршрутизации (RIB) (ну и не буду говорить тут про возможные усложнения в виде VRF-leaking и прочем - оставим это за кадром).
Однако очень понравился подход со снапшотами состояний - это круто в том плане, что мы можем посмотреть КОНСИСТЕНТНО, а не в пределах одной ноды, состояние всей сети в определенный момент времени (т.н bird-view). Если этот подход смиксовать с RIB, возможно, получится вполне сносный инструмент для ретроспективного анализа сети - и я даже не исключаю, что такой уже есть, просто я о нем не знаю :)
В любом случае, автору респект, спасибо за статью - заставила вспомнить об OSPF :)
Мы с таким багом тоже сталкивались, но на другой железке от Huawei (AR-серии). И еще, простите за снобизм - а где гарантии, что все 21 vty-линии не займет OPS?
В нашем случае - рекомендовали апгрейдить прошивку\ставить патч.
Ох, очень надеюсь, что все это не останется технологией для "гиперскейла", а выйдет наружу.
В конце-концов мы можем быть подвержены "ошибке выжившего" - ведь на слуху и в ПРОДЕ сейчас действительно много инструментов, которые начинались в "гиперскейлах", но никто не говорит о тулзах, которые были сделаны\открыты "гигантами", но так и не нашли применения в других секторах. Это наверное тема отдельного академического исследования:)
Так же соглашусь с позицией о том, что для того, чтобы что-то изменилось - надо об этом говорить и популяризовать. А еще крайне желательно говорить, показывая use-case для реального применения (желательно в условиях ограниченного бюджета --> и вот он - "бизнес-драйвер" для small/medium-enterprise для Green Field проектов :))
Так же позволю себе поделиться ссылкой на то, что было 8 лет назад:
Уже тогда некоторые "держали нос по ветру" и видели смысл заморачиваться с популяризацией...но только при условии продажи довольно дорогого железа к NOS :)
Прошло 8 лет, стал популярен докер/кубер/CI/CD и прочие DevOps-инструменты для IaaC и...
Я не так давно самостоятельно пытался найти и прощупать тот самый кейс, когда можно взять относительно дешевый L2(L3)-коммутатор типа "пицца-бокс" с ONIE :
стоимостью на уровне D-link, но лучше - ниже -> ниша для ISP;
или стоимостью ниже или паритетное Huawei/Cisco (конечно с учетом скидок от GPL которые дают/давали вендора) -> для Small/Medium Enterprise
стоимость обслуживания сети при этом не должна разительно вырасти (Ops), лучше конечно (утрируя, и как бы страшно это не звучало!) - "чтобы legacy-сетевики были не нужны", а всем ведали DevOps или небольшой отдел NetOps.
Так же внезапно оказывается, что в условиях санкций и ограничений - "драйвер" для бизнеса (особенно Medium/Large) вполне может быть -> т.к если официальной поддержки софта от вендора нет - то может быть рационально инвестировать в развитие собственного инженерного потенциала - развивая и допиливая открытые NOS'ы. Или этим мог бы заняться некий консолидированный "стартап" в РФ, чтобы потом монетизировать все это через поддержку софта (типа как RedHat и Cumulus) - идея не нова... впрочем для того, чтобы пазл сошелся - должен быть масштаб рынка как у RedHat/Cumulus, имхо - весь мир :)
А если этого нет этого рынка, то это либо должно быть сделано политическим усилием (и все-таки с перспективой выхода на международные рынки), либо... у нас есть уже вендоры "второй/третьей" линии (с ТОРП), которые пилят свой проприетарный управляющий софт, дергая за ниточки Broadcom/Realtek SDK - пользуйтесь ими на здоровье :)
В итоге - я так и не смог нащупать данный кейс, потому что не увидел более дешевого или паритетного по ценам железа (c ONIE) с вендорами "второй/третьей" линии. А для "первой" вроде как есть сдерживающий фактор - total cost of ownership (т.е легче купить оборудование "второй" линии и уже каким-никаким софтом на поддержке, чем покупать голую c ONIE и допиливать напильником самому - все же ПРОД!) - я так и не смог понять тот баланс, где начинается реальный буст для новых технологий, а где выгодно использовать то, что есть. Sad story, but true...!
Если у кого-то есть такие use-case или хотя бы что-то отдаленно напоминающее success story не у гиперскейлеров - то было бы здорово ознакомиться с ними.
Огромное спасибо за проделанный труд! Великолепная статья.
Для меня, по окончании её прочтения и вкупе с собственной рефлексией остается "осадочек" - просто потому что есть явное осознание, что в массы (small/midlle enterprise / SP) это двигаться если и будет - то крайне медленно (а возможно и вовсе не будет - ведь нет того самого "бизнес-драйвера"). NETCONF/YANG-стандартизация при выходе за рамки настройки чего-то простого, на мой взгляд, выглядят особенно утопично для самих вендоров (не смогут зарабатывать на "софте", а смогут только на железе).
И, если разложить по полкам, то мы имеем:
Сети гиперскейлеров с десятками/сотнями ДЦ (десятками/сотнями тысяч свитчей и прочего AО): для них "автоматизация" - это вопрос выживания и конкуренции. При таких масштабах есть и тот самый "бизнес-драйвер" =-> уменьшение Time-to-Market и уменьшение затрат на Ops сетей (как минимум в виду не раздувания персонала). Под этими задачами пытаются "прощупывать" всякие решения - есть и попытки развития Open NOS и WhiteBox-коробок, попытки совместить управление коробками разных вендоров через NETCONF/YANG (вместо десятков тулзов вендоров, которым еще и астрономические суммы за софт платить придется).
Сети Провайдеров с "разношерстными" вендорами и десятками тысяч коробок : для них NETCONF/YANG-стандартизация была бы выгодна - по причине экономии и на железе и на Ops, но....
Тут есть понимание, что не все провайдеры "одинаковы" - но для многих в РФ это просто нереально по причине того, что:
1. тех.стек "устоялся" (и никаким NETCONF там не пахнет в виду legacy-коробок, "самописные" костыли - оставим за рамками)
2. инженерная сила (сетевиков) относительно "дешева".
Сомневаюсь, что и в остальном мире (возможно, кроме Китая) подход иной - для рентабельности провайдера необходимо максимально выжимать все "соки" из CAPEX'а на стройку (которая зачастую была когда NETCONF/YANG еще и в проекте не было). Некоторые провайдеры, конечно, стараются быть не "просто трубой". Но, будем честны, эти старания в основном направлены на предоставление каких-то услуг (НЕ ТРАНСПОРТНЫХ!), которые базируются в каких-то ЦОДах. А про сети ЦОДов для негиперскейлеров - см. ниже
Сети Small/Middle Enterprise (от 0 до 10 ДЦ, региональные WAN-сети и прочее) : автоматизация (через NETCONF и прочие gNMI) там вовсе не обязательна. Хватает и более "грубых" инструментов - самописных скриптов/Ansible/Salt/etс.. Да есть и разновендорность - но в виду относительно небольших масштабов нет критической необходимости заморачиваться с NETCONF - разве что инженерное любопытство может заставить разобраться в теме. При этом попытки имплементации могут разбиться о действительность, в которой БИЗНЕС не видит причин для изменения текущей парадигмы. И если уж необходима орекстрация и автоматизация, то зачастую БИЗНЕСУ легче купить решение от какого-то одного вендора (благо они есть) - и отдавать вендору денег за поддержку "софтварной" части этого решения. Ну а инженерам просто придется освоить то решение, которое дал вендор - оно может быть вполне на модном NETCONF, но в рамках работы с одним вендором:)
Мы идем по пути эволюции, но не чистой, а "скорректированой" по коммерческой составляющей (впрочем, в технологиях, так почти везде).
На мой взгляд, единственный фактор буста в сложившейся коньюнктуре для NETCONF/YANG - это дальнейшее развитие NOS с открытым исходным кодом (допиливание фич, OC и драйверов для работы с разными платформами и т.п) && развитие White-box решений (для масс-маркета Enterprise/SP, а не только DC). И да (ура!) - вот тогда это и будет управляться "чисто как сервера" сейчас - и тогда нужны будут NetOps в дополнение к DevOps (ну или DevOps'ам придется освоить еще одну компетенцию:))
Все вышеприведенное - это мое субъективное мнение, буду рад услышать другие взгляды на происходящее в индустрии относительно направления автоматизации!
Еще раз спасибо за проделанную работу - было очень интересно читать!
Мне все время казалось, что 30 секунд для большого энтерпрайза это долго... прямо очень-очень. Ну разве что там не "боевые" сервисы, а тестовые или просто реплики-бекапы\прочий глубокий бэкграунд трафик, деградация которого на 30 секунд будет "не заметна" для фронт-энд пользователя.
Почему Вы не развернули какое-то "свое" решение в виде виртуального(ых) роутер(ов) на (например, CSRv) в Вашей вычислительной инфраструктуре? До него можно было бы и BFD настроить и все, что Вам угодно сделать "поверх" клауда (overlay-сеть), который предоставлял бы Вам просто L3 связность между Вашими WAN-роутерами.
Опять же, если подается оптика (L1) - почему нельзя её терминировать на обычном роутере(ах) в Вашей ЗО, а все остальное (VPC) подключить "стыком" с этого(их) роутеров с клаудом - Вы обсуждали данный подход с оператором облачного сервиса?
В общем кейс интересный, но подходы к снаряду могут быть разные. В виду того, что многие ограничения не описаны или не названы - я бы выбрал другой, на мой взгляд, более "правильный и быстрый" вариант :)
Я как "инфраструктурщик" с бэкграундом в сетях, такого еще не слышал :)
Ваши выводы выше - являются субъективной "фантазией" о том, как работает сетевое железо роутера. Максимально приоритетными задачами являются роутинг (поддержание работы протоколов динамической маршрутизации и наполнения таблиц форвардинга). Высокий pps ICMP так или иначе будет "резаться" CoPP - такие преднастройки имеет сейчас фактически каждый (даже домашний) маршрутизатор из коробки. Конечно поведение и преднастройки меняются от вендора к вендору и модели оборудования, но ICMP в приоритетах разделения процессорного времени современных моделей где-то "cнизу" уже долгое время (наверное как раз с тех времен, когда было можно еще сделать PingOfDead).
Вероятно у Вас был в полку CPU из-за генерации большого количества логов FW, а не из-за ICMP:
А количество обрабатываемых pps всяких разных пакетов (служебных) - это CoPP. И настройка в 20k pps для ICMP для "филиального" роутера - абсолютный overhead (предположу что это значение по умолчанию от вендора - а значит значимо влиять на CPU не должно было).
В целом сдается мне, что дело не в ICMP как таковом, а каких-то настройках Алисы - почему у меня и десятков тысяч людей использующих любых провайдеров дома, в том числе и для Алисы - "проблем с ICMP" не возникло, где массовость? Вы снимали и раскуривали содержимое дампа?
Заголовок статьи "желтит", тема не раскрыта)
Блин. Вот что значит невнимательность - ошибился в третьем октете - мой ответ неверен ))
На srv2 придет (AD directly-connected сети предпочтительней - сеть на R8 в описании дана с "ошибкой" либо специально, либо по невнимательности - /294, но опираясь на то, что мы имеем прямой линк между R8 & SRV2 и на последнем маска /24 - думаю это опечатка. Если все же сеть там /29 - то трафик конечно пойдет по статическому маршруту через R9 и зайдет на SRV1)
Зашел почитать про стеки и как это ужасно и нашел еще и про WiFi :)
Про WiFi - больно будет клиенту или нет при -76dbm зависит от скорости установленного беспроводного линка и SNR. Может быть вполне не больно, а очень хорошо.
Вывод по вай-фай очень обобщенный - зона покрытия нужна и в случае low dencity, и в случае high dencity - но более производительные точки помогут работать более "современным" клиентам на более высоких скоростях:)
Про стекирование добавлю - это про подход к обеспечению хардварной отказоустойчивости группы коммутаторов и линков; упрощение логической топологии на L2 + для избегания блокирования линков (не говорите мне за MSTP - балансировка и администрирование могут быть довольно сложными даже на относительно тривиальных топологиях).
Да, ПО может сбоить. Да, обновлять его трудно и может быть больно. Но посмотрите с другой стороны - ПО может сбоить на любом узле и, к сожалению, это не бинарная сущность - "работает все" или "не работает ничего". Поэтому я бы не ложил это как однозначный "+" в сторону "отказа от виртуализации".
Цискин vPC и прочие пропиетарные варианты в этом плане берут лучшее от стека и добавляют "отказоустойчивости" на software-уровне. Но, прошу заметить, такое делают только в сторону "доступа" :)
А так, как написал коллега выше можно обойтись без всего этого, используя L3 Access в связке с VXLAN - но это не про существующие сети, которые надо как-то поддерживать сейчас.
Думаю, сравнение с OpenVPN в статье, которая написана в угоду пиара "как мы можем и какие услуги у нас есть" лишнее :)
Ибо я не вижу причин не использовать его (ну или другое решение) только лишь по причине "сложности" - как написали выше: разбираться обслуживающему персоналу так или иначе придется, что с Вашим решением, что с другим.
Оператор связи в классическом его понимании уже давно превратился в "трубу" - обязанность у которой только одна: обслуживать андерлей, да так чтобы
"сеть зарезервирована, соединение не пропадет даже при разрыве оптических волокон в линках". А оверлейные сети оставьте энтерпрайзам.А подскажите, почему не решили просто снимать рабочую нагрузку с хостов по одному (переводя их в режим обслуживания, к примеру) и уже потом их переключать в аристу для сбора LACP - и так step-by-step, по одному хосту перевести все на новые Leaf-коммутаторы. Схема с тем, что изменится system-id выглядит приятно - но все же может дать незначительный даунтайм для приклада в процессе переключения линков и сбора LACP.
С переводом шлюза - хорошая хитрость, не всегда очевидная, хоть и не сложная по сути - запомню)
Ну и по поводу:
"Возможность гибкого и почти неограниченного масштабирования сети на любом уровне в результате внедрения технологии VXLAN EVPN и дизайна Leaf-Spine."Как вы собираетесь масштабировать сеть? Не на уровне топологии clos'а - там как раз все ясно, а на уровне выхода во внешнюю сеть, если capacity FW не будет хватать? Если не секрет - что за вендор был выбран на FW?
Так если есть конкретная задача, почему надо прокидывать - прокидывайте Л2 на здоровье. Описанные в статье слова не стоит возводить в абсолют :)
В статье речь скорей о том, что стоит уходить от архитектурных паттернов с "растягиванием" широковещательных доменов, когда того явно не требуется.
Ок, читаем далее внимательно :)
"The RSTP Port Information state machine (...) checks that the BPDU’s Message Age is less its MaxAge, and if not, will immediately age out the received information."
Т.е сообщение пройдя 20 свитчей просто отбросится.
Настройка эдж портов тут вообще ни при чем - по умолчанию все фул-дуплекс порты рассматриваются RSTP как p2p.
Исследований на эту тему было проведено много - вот, например, одно из них - https://miau.my-x.hu/miau/94/rstp.pdf
Скажем прямо - этот протокол НЕ масштабируем в рамках SP и имеет медленную сходимость. В 2008 году это имело место быть в сетях SP, сейчас же, по моему скромному мнению - это моветон.
Но никого не призываю конечно ничего делать - пока есть такие сети, я точно не останусь без работы))
Про случай из практики - проблемы возникают как раз когда такая "гирлянда" начинает то пропускать BPDU, то нет (и это может быть по разным причинам) - вот тогда-то и начинаются "штормы". Возможно, конечно, что установка cisco вам помогла в части надежности пропуска сих замечательных фреймов, но это частный случай - до первого не циско устройства в кольце (не поддерживающего пропиетарного r-pvst т.е)
Про диаметр - я не перепутал, это рекомендации IEEE. Да, может быть до 20 устройств в кольце (циска и другие вендоры "вскользь" разрешают это на Ваш страх и риск - рекомендации я видел такие же, как и от IEEE).
Но 37 устройств и даже 20 в кольце Л2 - это безумно много - и вот почему: при прохождении каждого хопа BPDU от корневого коммутатора "перерождается" каждым коммутатором и он из поля max age вычитает единичку - а это поле по умолчанию равно 20. Если maxage=0, то далее BPDU не отправится - поэтому понятия не имею, как у Вас Висели гирлянды из 28 и 32 коммутаторах (разве что там был BPDU-туннелинг и сами устройства на магистральных портах не работали в rSTP).
Так же, чем больше устройств в плоской л2 топологии - тем выше риск коллизий хешей, сбоя протокола или неудачной настройки и т.п - все, что выше было описано в статье повторять это я не буду
И это мы еще с Вами не обсудили то, что часть канальной ёмкости теряется просто так из-за блокировки порта протоколом RSTP (хотя на уровне Л3 её можно было бы использовать).
RSTP на магистральных портах собранных в кольца? Если при Вас ни разу не сбойнуло - значит масштаб опорных колец сети был ОЧЕНЬ маленький. У RSTP есть такое понятие как diameter - и при более 7 коммутаторах в кольце уже могут начаться side-effects, которые либо пытаются полечить с помощью тюнинга таймеров STP, либо с помощью натягивания другого костыля - MSTP с "сегментацией" по регионам. Но потом поддерживать это очень сложно, да и опять - масштабируемость и скорость сходимости просто отвратительные.
Я как раз своими руками одну из таких "опорных сетей" провайдера переводил на IP/MPLS - потому что по мере роста она столкнулась с чудовищными бродкаст-штормами. Хотя, когда была "маленькой" - все работало "как часы" (за исключением того, что сходимость сети оставляла желать лучшего)
P.S: Единственное, что можно добавить - что я это "наследие" переделывал в 2016 году. Сама архитектура, видимо, закладывалась еще в 2008 году)
Там гораздо больше вариантов, чем два пути, но каждый из этих вариантов имеет свои боли (NETCONF\YANG)
Просто оставлю это здесь - https://habr.com/ru/post/667440/ :)
Не понял, про какой "цифровой" двойник идет речь, но судя по словам:
речь идет о BGP RPKI (против BGP hijacking) и создании некоего "удостоверяющего"/"контролирующего" центра, который не даст анонсить сети без RPKI. В целом инициатива хорошая (хоть и дублирует функциональность RIPE). Вопрос в том - что сделают по итогу.
Я поработал в двух провайдерах на позициях от саппорта до ведущего инженера и смею не согласиться с Вами. Управляемые коммутаторы ставятся в даже небольших провайдерах и не требуют космических денег на порт в условиях централизованной закупки. Даже "говно-палки" ISP может купить легаси циску\длинк за 1-2 тр за (24!) 100mbps порта (50-100 рублей за порт).
Неуправляемые новые коммутаторы большой портовой ёмкости сейчас уже де-факто не встретишь.
Управляемые коммутаторы нужны прежде всего самому провайдеру - чтобы "управлять" и "мониторить" сеть - конечно, если такие компетенции есть у саппорта\инженеров :) Объясняется это и финансовой моделью - как провайдеру узнать, что у Вас порезали кабель (нет линка) или же коммутатор сдох? По каждому вызову направлять Вам техника? А саппорт, которому Вы позвоните - он только и может, что назначить техника - ведь у него нет "глаз на сети".
В общем это тоже деньги - и гораздо большие, чем стоимость порта управляемого коммутатора в разрезе на одного абонента :)
Тут, имхо (видел такое не раз и не два:)) - нет компетенций у обслуживающего персонала сети + нет желания что-то менять (отчасти потому что платят копейки и тот, кто "шарит" не будет там сидеть - в этом я больше чем уверен)
P.S: Можно подсмотреть на капче - есть ли LLDP\CDP трафик с порта - таким образом "понять" управляемый ли коммутатор или нет и его марку модель (в случае, если оно глобально включено на всех портах, а не только на аплинках)
Так я понял говорят именно о "броадкастинге" на L2 - т.е они в одном влане, хотя так не должно было быть (должны были быть в разных - похоже речь о приватном пиринге : https://kb.msk-ix.ru/ix/network/).
У нас было так, что все 15 линий были заняты и не получалось попасть на железку.
Huawei сказал, что это дефект ОС и вот вам исправление, пользуйтесь на здоровье. С тех пор прошло полгода вроде - пока проблем с этим не наблюдали.
«Но гораздо эффективней и рациональней предоставить возможность сервису читать актуальные служебные сообщения OSPF (LSA) в режиме реального времени и таким образом логировать изменения на сети.»
А почему для этой цели выбран новый «велосипед» с GRE и OSPF до (каждой!) ноды под капотом - мне не понятно.
Может быть объяснение кроется в том, что хотели получить «вендор-агностик» парсинг на конечной коробке (ospfwatcher)? Но были ли исследованы другие менее "инвазивные" в control-plane методы (например grpc/snmp, в конце-концов парсинг обычных log-сообщений)?
На мой взгляд такая реализация - это дополнительный оверхед + лишняя зависимость на control-plane для железок.
Поясню: имея соседство со всеми железками по OSPF в сети, можно случайно или намеренно выстрелить себе в ногу - например через объявление дефолтного маршрута с этой железки.
Кроме того, OSPF может быть многозонным - в какой(их) зоне(ах) делается соседство через GRE?:)
Касаемо тематики самой статьи - для меня здесь виден чисто академический интерес. Ведь с точки зрения решения прикладных задач - у нас не один OSPF в сети может быть, а так же (i)BGP, EIGRP,ISIS, и даже RIP (во всех смыслах:)). На практике это говорит о ненадежности получения информации с данного инструмента для анализа изменений и прокладывания актуального пути трафика. В этом плане для анализа лучше использовать снапшоты таблицы маршрутизации (RIB) (ну и не буду говорить тут про возможные усложнения в виде VRF-leaking и прочем - оставим это за кадром).
Однако очень понравился подход со снапшотами состояний - это круто в том плане, что мы можем посмотреть КОНСИСТЕНТНО, а не в пределах одной ноды, состояние всей сети в определенный момент времени (т.н bird-view).
Если этот подход смиксовать с RIB, возможно, получится вполне сносный инструмент для ретроспективного анализа сети - и я даже не исключаю, что такой уже есть, просто я о нем не знаю :)
В любом случае, автору респект, спасибо за статью - заставила вспомнить об OSPF :)
Мы с таким багом тоже сталкивались, но на другой железке от Huawei (AR-серии).
И еще, простите за снобизм - а где гарантии, что все 21 vty-линии не займет OPS?
В нашем случае - рекомендовали апгрейдить прошивку\ставить патч.
Ох, очень надеюсь, что все это не останется технологией для "гиперскейла", а выйдет наружу.
В конце-концов мы можем быть подвержены "ошибке выжившего" - ведь на слуху и в ПРОДЕ сейчас действительно много инструментов, которые начинались в "гиперскейлах", но никто не говорит о тулзах, которые были сделаны\открыты "гигантами", но так и не нашли применения в других секторах. Это наверное тема отдельного академического исследования:)
Так же соглашусь с позицией о том, что для того, чтобы что-то изменилось - надо об этом говорить и популяризовать. А еще крайне желательно говорить, показывая use-case для реального применения (желательно в условиях ограниченного бюджета --> и вот он - "бизнес-драйвер" для small/medium-enterprise для Green Field проектов :))
Так же позволю себе поделиться ссылкой на то, что было 8 лет назад:
https://habr.com/ru/company/etegro/blog/227897/
Уже тогда некоторые "держали нос по ветру" и видели смысл заморачиваться с популяризацией...но только при условии продажи довольно дорогого железа к NOS :)
Прошло 8 лет, стал популярен докер/кубер/CI/CD и прочие DevOps-инструменты для IaaC и...
Я не так давно самостоятельно пытался найти и прощупать тот самый кейс, когда можно взять относительно дешевый L2(L3)-коммутатор типа "пицца-бокс" с ONIE :
стоимостью на уровне D-link, но лучше - ниже -> ниша для ISP;
или стоимостью ниже или паритетное Huawei/Cisco (конечно с учетом скидок от GPL которые дают/давали вендора) -> для Small/Medium Enterprise
стоимость обслуживания сети при этом не должна разительно вырасти (Ops), лучше конечно (утрируя, и как бы страшно это не звучало!) - "чтобы legacy-сетевики были не нужны", а всем ведали DevOps или небольшой отдел NetOps.
Так же внезапно оказывается, что в условиях санкций и ограничений - "драйвер" для бизнеса (особенно Medium/Large) вполне может быть -> т.к если официальной поддержки софта от вендора нет - то может быть рационально инвестировать в развитие собственного инженерного потенциала - развивая и допиливая открытые NOS'ы. Или этим мог бы заняться некий консолидированный "стартап" в РФ, чтобы потом монетизировать все это через поддержку софта (типа как RedHat и Cumulus) - идея не нова... впрочем для того, чтобы пазл сошелся - должен быть масштаб рынка как у RedHat/Cumulus, имхо - весь мир :)
А если этого нет этого рынка, то это либо должно быть сделано политическим усилием (и все-таки с перспективой выхода на международные рынки), либо... у нас есть уже вендоры "второй/третьей" линии (с ТОРП), которые пилят свой проприетарный управляющий софт, дергая за ниточки Broadcom/Realtek SDK - пользуйтесь ими на здоровье :)
В итоге - я так и не смог нащупать данный кейс, потому что не увидел более дешевого или паритетного по ценам железа (c ONIE) с вендорами "второй/третьей" линии. А для "первой" вроде как есть сдерживающий фактор - total cost of ownership (т.е легче купить оборудование "второй" линии и уже каким-никаким софтом на поддержке, чем покупать голую c ONIE и допиливать напильником самому - все же ПРОД!) - я так и не смог понять тот баланс, где начинается реальный буст для новых технологий, а где выгодно использовать то, что есть. Sad story, but true...!
Если у кого-то есть такие use-case или хотя бы что-то отдаленно напоминающее success story не у гиперскейлеров - то было бы здорово ознакомиться с ними.
Огромное спасибо за проделанный труд! Великолепная статья.
Для меня, по окончании её прочтения и вкупе с собственной рефлексией остается "осадочек" - просто потому что есть явное осознание, что в массы (small/midlle enterprise / SP) это двигаться если и будет - то крайне медленно (а возможно и вовсе не будет - ведь нет того самого "бизнес-драйвера"). NETCONF/YANG-стандартизация при выходе за рамки настройки чего-то простого, на мой взгляд, выглядят особенно утопично для самих вендоров (не смогут зарабатывать на "софте", а смогут только на железе).
И, если разложить по полкам, то мы имеем:
Сети гиперскейлеров с десятками/сотнями ДЦ (десятками/сотнями тысяч свитчей и прочего AО): для них "автоматизация" - это вопрос выживания и конкуренции. При таких масштабах есть и тот самый "бизнес-драйвер" =-> уменьшение Time-to-Market и уменьшение затрат на Ops сетей (как минимум в виду не раздувания персонала).
Под этими задачами пытаются "прощупывать" всякие решения - есть и попытки развития Open NOS и WhiteBox-коробок, попытки совместить управление коробками разных вендоров через NETCONF/YANG (вместо десятков тулзов вендоров, которым еще и астрономические суммы за софт платить придется).
Сети Провайдеров с "разношерстными" вендорами и десятками тысяч коробок : для них NETCONF/YANG-стандартизация была бы выгодна - по причине экономии и на железе и на Ops, но....
Тут есть понимание, что не все провайдеры "одинаковы" - но для многих в РФ это просто нереально по причине того, что:
1. тех.стек "устоялся" (и никаким NETCONF там не пахнет в виду legacy-коробок, "самописные" костыли - оставим за рамками)
2. инженерная сила (сетевиков) относительно "дешева".
Сомневаюсь, что и в остальном мире (возможно, кроме Китая) подход иной - для рентабельности провайдера необходимо максимально выжимать все "соки" из CAPEX'а на стройку (которая зачастую была когда NETCONF/YANG еще и в проекте не было).
Некоторые провайдеры, конечно, стараются быть не "просто трубой". Но, будем честны, эти старания в основном направлены на предоставление каких-то услуг (НЕ ТРАНСПОРТНЫХ!), которые базируются в каких-то ЦОДах. А про сети ЦОДов для негиперскейлеров - см. ниже
Сети Small/Middle Enterprise (от 0 до 10 ДЦ, региональные WAN-сети и прочее) : автоматизация (через NETCONF и прочие gNMI) там вовсе не обязательна. Хватает и более "грубых" инструментов - самописных скриптов/Ansible/Salt/etс.. Да есть и разновендорность - но в виду относительно небольших масштабов нет критической необходимости заморачиваться с NETCONF - разве что инженерное любопытство может заставить разобраться в теме. При этом попытки имплементации могут разбиться о действительность, в которой БИЗНЕС не видит причин для изменения текущей парадигмы.
И если уж необходима орекстрация и автоматизация, то зачастую БИЗНЕСУ легче купить решение от какого-то одного вендора (благо они есть) - и отдавать вендору денег за поддержку "софтварной" части этого решения. Ну а инженерам просто придется освоить то решение, которое дал вендор - оно может быть вполне на модном NETCONF, но в рамках работы с одним вендором:)
Мы идем по пути эволюции, но не чистой, а "скорректированой" по коммерческой составляющей (впрочем, в технологиях, так почти везде).
На мой взгляд, единственный фактор буста в сложившейся коньюнктуре для NETCONF/YANG - это дальнейшее развитие NOS с открытым исходным кодом (допиливание фич, OC и драйверов для работы с разными платформами и т.п) && развитие White-box решений (для масс-маркета Enterprise/SP, а не только DC). И да (ура!) - вот тогда это и будет управляться "чисто как сервера" сейчас - и тогда нужны будут NetOps в дополнение к DevOps (ну или DevOps'ам придется освоить еще одну компетенцию:))
Все вышеприведенное - это мое субъективное мнение, буду рад услышать другие взгляды на происходящее в индустрии относительно направления автоматизации!
Еще раз спасибо за проделанную работу - было очень интересно читать!
Мне все время казалось, что 30 секунд для большого энтерпрайза это долго... прямо очень-очень. Ну разве что там не "боевые" сервисы, а тестовые или просто реплики-бекапы\прочий глубокий бэкграунд трафик, деградация которого на 30 секунд будет "не заметна" для фронт-энд пользователя.
Почему Вы не развернули какое-то "свое" решение в виде виртуального(ых) роутер(ов) на (например, CSRv) в Вашей вычислительной инфраструктуре? До него можно было бы и BFD настроить и все, что Вам угодно сделать "поверх" клауда (overlay-сеть), который предоставлял бы Вам просто L3 связность между Вашими WAN-роутерами.
Опять же, если подается оптика (L1) - почему нельзя её терминировать на обычном роутере(ах) в Вашей ЗО, а все остальное (VPC) подключить "стыком" с этого(их) роутеров с клаудом - Вы обсуждали данный подход с оператором облачного сервиса?
В общем кейс интересный, но подходы к снаряду могут быть разные. В виду того, что многие ограничения не описаны или не названы - я бы выбрал другой, на мой взгляд, более "правильный и быстрый" вариант :)