Комментарии 17
Наша команда вдыхает жизнь в железо — создает софт для коммутаторов KORNFELD, которые встают в серверные стойки рядом с СХД.
Статья отличная, но я не до конца понял на платформе какого роутера всё происходит? вашей линейки, если да, то понимаю, что у него нет веб интерфейса?
Ни разу не сталкивался, чтобы на Cisco или Mikrotik слетал NTP сервер неожиданно и при этом не сгорал роутер. Почему на вашем роутере сразу слетело всё?
Ещё такой вопрос возможно не до конца понял, по схеме, зачем в этой связки и коммутатор и маршрутизатор? Если данный маршрутизатор умеет L3, то он умеет общаться IP пакетами без посредников вроде.
В статье описаны принципы, которые можно встретить в white box-решениях, в частности SONiC. Антон поделился своим опытом в надежде, что он будет кому-то полезен. Коммутатор KORNFELD в этой статье не рассматривается, но здорово, если вам интересно узнать о нем больше. Можем подумать об отдельной статье.
Кейс с клиентом, который не может достучаться до сервера, выбран как вариант, позволяющий погрузить читателя в более-менее конкретную проблему, но оставить внешние детали и погрузиться в мир внутреннего устройства коммутатора. История со сгоревшим коммутатором не представляет такого практического интереса, как ситуация, когда коммутатор работает, но немного не так.
На одном конце нашей сети — компьютер пользователя, на другом — сервер, к которому нет доступа. Между ними — L3-коммутатор и маршрутизатор.
Вот не понял я этой схемы. Клиентский компьютер, как и switch1, имеет адрес из подсети 10.1.1.0/24 или нет? switch1 в общении клиентского компьютера с сервером времени 10.2.2.1 работает как коммутатор (только L2) или как маршрутизатор (ещё и L3)? Судя по дальнейшим объяснениям - первое, но тогда неясно, почему проверки не начались с самогО клиентского компьютера. Сразу бы обнаружилось, что связи со switch1 нет.
С маршрутизатора доступ есть. Это значит, что проблема находится до маршрутизатора.
Да с чего бы? Зафильтруйте на роутере на выходе трафик на 10.1.1.1 - получите ровно эту картину.
Вот не понял я этой схемы.
Из схемы убраны некоторые детали, так как автор не хотел ее перегружать. В листингах аналогично убраны детали, не относящиеся к теме.
Схема IP-адресов может быть такой:
PC1:
IP: 192.168.1.100/24
GW: 192.168.1.1
Switch:
Ethernet1 : 10.1.1.1/24
Ethernet2 : 192.168.1.1/24
Router:
Порт1 : 10.1.1.2/24
Порт2 : 10.2.2.2/24
Сервер:
IP: 10.2.2.1/24
GW: 10.2.2.2
Да с чего бы? Зафильтруйте на роутере на выходе трафик на 10.1.1.1 - получите ровно эту картину.
Хотя статья про коммутатор, замечание про фильтрацию на роутере верное. Действительно, проблема может быть по оба конца кабеля. А кроме фильтрации 10.1.1.0/24, можно накинуть и других вариантов — например, заблекхолить соседа 10.1.1.1 или прописать 10.1.1.1/32 доступным через совершенно другой хост.
Switch:
Ethernet1 : 10.1.1.1/24
Ethernet2 : 192.168.1.1/24
Тогда это не свитч/коммутатор, а маршрутизатор. И неважно, что маршрутизатор является составной частью L3-коммутатора. При поиске проблемы надо работать с функциональной схемой, а не тупо считать корпуса. Только запутываете... Если читатель в этой области новик, то в лучшем случае он ничего не поймёт. А в худшем - поймёт неправильно.
Это сродни откуда-то появившемуся и невероятно популярному заблуждению, что в каждом вилане должна ходить только одна подсеть, причём в каждом своя. Уже и не скажешь, откуда это вылезло - но адепты аж в драку кидаются, словно фанатики религиозные, и ничем не свернуть.
это не заблуждение, а здравый подход. Да в дефолтном вилане ползают все подсети, но если уж виланы делать, то наверное они должны быть понятны/прозрачны с внятной адресацией -).
Ну и чего тут здравого? Чистой воды масло масляное. На L2 разделим, на L3 тоже разделим, правда, там уже всё однородно, но на всякий случай всё одно разделим, а ну как на L2 чего не так сработает?
Это ж как в том анекдоте, где программист одно и то же выражение считал дважды, в две разные переменные, а потом сравнивал - на всякий случай, вдруг один раз неправильно посчитается...
Разработчики сетевого оборудования живут в парадигме: что доступно для конфигурации, то обязательно будет сделано.
На хост можно повесить два IP-адреса на один интерфейс, от коммутатора тут уже мало что зависит.
Несколько сетей в одном широковещательном домене — возможно, но это может вызвать некоторые проблемы. Навскидку:
1. Много лишнего широковещательного трафика.
2. Сложности у DHCP-сервера, которому надо выдавать IP-адреса из разных подсетей.
3. Труднее отлаживать и документировать сеть.
1. Много лишнего широковещательного трафика.
Процент широковещательного трафика от общего трафика подсети слабо зависит от присутствия другой подсети. Так что если суммарный трафик всех подсетей не выедает полосу почти нацело, то совершенно непонятно, почему это вообще может быть проблемой. Да, если такой процент высок, то проблема есть - но она никак не связана с наличием других подсетей.
2. Сложности у DHCP-сервера, которому надо выдавать IP-адреса из разных подсетей.
А вот этого не понял вообще, в принципе. Серверу вообще-то глубоко сиренево, один скоп обслуживать или несколько. Ему надо одно - вменяемые и однозначные правила определения, из какого скопа выдавать адрес конкретному узлу. Конечно, сервер с несколькими скопами настраивать чуть сложнее, чем с одним - но эта сложность не чрезмерная, да к тому же одноразовая.
3. Труднее отлаживать и документировать сеть.
Если мы одинаково понимаем термин "документирование сети", то я не понимаю, откуда возьмётся трудность. Какая собственно разница, одна подсеть или несколько?
Про отладку ничего не скажу - не моя область. Но мне на практике никогда не приходилось сталкиваться с проблемами, хоть как-то похожими на описанные в ваших статьях.
А вот этого не понял вообще, в принципе.
Имеется в виду задача, когда DHCP-сервер должен выдать клиенту на один интерфейс (соответственно на один MAC-адрес) primary и secondary IP-адреса. Этого можно добиться, например, двумя запросами с разными "client-identifier" в опции 61 (rfc2131, rfc6842). Но конфигурирование в каждом VLAN только одной подсети видится более простым вариантом.
когда DHCP-сервер должен выдать клиенту на один интерфейс (соответственно на один MAC-адрес) primary и secondary IP-адреса
Гм... но если делать то же в разных VLAN, то как вы вообще сможете это обеспечить с выполнением условия одного МАС-адреса? Я что-то себе слабо представляю, как это будет выглядеть на стороне клиента - даже если это будет один физический интерфейс в trunk или mixed порте, всё равно внутри ОС это будут два разных виртуальных интерфейса с разными МАС.
Третья типичная категория проблем — многоэтажная конфигурация. Например, мы создаем интерфейс уровня L3, на него вешаем IP-адрес, потом вешаем еще один адрес, следом на этом интерфейсе поднимаем VRRP, и напоследок нам хочется переместить этот интерфейс в другую VRF-систему:
Спасибо за статью! Вопрос: почему изначально не рассматривался YAML-формат для конфигурации роутера? Это ведь актуальный (и, на самом деле, весьма востребованный) тренд среди большинства вендоров на рынке. Помимо прочих, очевидных преимуществ YAML (структурированность в формате ключ-значение), он решает описанные в статье сложности с выстраиванием иерархии конфигурации, позволяя задать все параметры в более логичной форме.
При управлении через YAML часто получаются длинные строки, например в openconfig, поэтому посчитали этот формат менее подходящим для статьи. YAML очень хорошо подходит для систем автоматизации и действительно распространен.
Описанная проблема с VRRP может возникнуть при любом способе задания конфигурации. Даже после "commit check" можно получить проблему, если в системе валидации присутствует ошибка для какой-то комбинации настроек.
Многие вендоры переходят на json. YAML более привередливый к оформлению.
И я так понял, для тех кому лень читать этот же автор рассказывает все тут https://youtu.be/mXpKVs2hrUk?si=i120CV_fpKjBuarr
На некстхопе был хороший доклад про работу с вайтбоксами на низком уровне без аналогий про города, а тут наглядный пример под switchdev.
Спасибо, что читали и сохраняли статью! Не томим вас ожиданием второй части: https://habr.com/ru/companies/yadro/articles/866430/ Делимся разгадкой проблемы с картинками котиков.
Как устроен L3-коммутатор: разбираемся с железом и настройками конфигурации на примере проблемы с котиками