Спасибо!

Вы правы в том, что можно больше упростить, тут я ищу баланс между "упростить чтобы было понятно всем" и "рассказать так, чтобы было проще читать спецификацию". И при работе со всеми этими протоколами обязательно читать спецификацию, даже если инженер думает, что читал и помнит :) Про мышку - спасибо за замечание, прослежу.

Короткий ответ: VTEP это ещё один интерфейс, нужный чтобы совершить некоторые действия с пакетом (добавить/убрать/изменить поля пакета нужные для операций с туннелем). VTEP связывает "Интерфейс локального конца туннеля" с "Интерфейсом для взаимодействия с host/станцией". К портам, на которых сконфигурирован "Интерфейс для взаимодействия с host/станцией" - подключаете виртуалки. К порту, на котором сконфигурирован "Интерфейс локального конца туннеля" - подключаете устройства нужные для дальнейшего выхода в сеть. Более развёрнутый ответ: Думал добавить схему, но в комментарии нельзя. Представьте себе схему прохождения пакета через маршрутизатор, от стороны host до входа в туннель, так Станция (host) -> Физический порт подключения host -> Интерфейс для взаимодействия с host (VLAN или IP интерфейс) -> VTEP -> Интерфейс локального конца туннеля ( Всегда IP интерфейс) -> Выходной физический порт --- ... ---> Второй конец туннеля Пакет проходит от выхода из туннеля в сторону host схематически так: Второй конец туннеля --- ... ----> Входной физический порт -> интерфейс локального конца туннеля (всегда IP интерфейс) -> VTEP -> Интерфейс для взаимодействия с host/станцией (VLAN или IP интерфейс) -> Физический порт подключения станции -> Станция (host) Я в этом видео рассказываю, что для упрощения сложных схем, можно рассматривать все так: есть порт - физическая дырка. Он нужен для физического подключения. Потом вы конфигурируете интерфейсы для определения того, какие наборы полей пакета и по каким правилам будут использоваться дальше (VLAN, Router Interface), и все остальные интерфейсы и протоколы это набор дополнительных правил либо реакции на значения полей пакета, либо для изменения полей пакета, их добавления/удаления. kzbin.info/www/bejne/oaq6k6uviM-bp6c

Уточните пожалуйста вопрос. Где именно? Это схематическое представление router, потому что VxLAN в части передачи пакетов по туннелю работает по IP/UDP. Сторона, содержащая непосредственно станции/hosts (те станции которые общаются с другими станциями через туннель) могут использовать как L2 (VLAN) так и L3 (IP networks/sub-nets)

@@simplyexplained2642 host он же не знает ничего про VxVLAN. ip протокол хоста без arp запросов (они широковещательные) не сможет общаться с другими хостами. Один и тот же VxVLAN на разных площадках объединяет широковещательные домены хостов. arp запрос как попадает через VXVLAN на другую физическую ноду/узел

@@simplyexplained2642 почему то исчез мой вопрос про широковещание и arp ы между хостами на разных железках но в одной VxVLAN

Спасибо!

Спасибо!

Спасибо!

Спасибо!

Спасибо!

Спасибо! Спасибо за идею!

Спасибо! Если вы имеете в виду комбинацию настроек MC-LAG (Multichassis LAG ) + EVPN, то это интересная комбинация, никогда такой не встречал, уточню. Возможно я что-то неправильно понял в вашем вопросе, если можете - уточните пожалуйста.

Я прошу прощения, это я не правильно понял. Я имею в виду EVPN мультихоминг. Это же может называться rfc реализацией mc-lag, на сколько я понимаю.

@@lekseiagrafenin2497 Спасибо за идею!

Приятного!

Спасибо за вопрос. Отвечу кратко и детально. Кратко: Задача DHCP Relay - настроить промежуточный девайс так, чтобы DHCP пакеты доходили до нужных устройств. А уже DHCP Server оперирует сетевыми адресами и прочими настройками. Детальнее: Я разобью ответ на 2 части: 1. Как выбрать подсеть для устройства (девайса) и 2. Как DHCP Relay знает кому куда отвечать. 1.). Выбор подсети IP address конкретного устройства - это настройка DHCP Server. В конфигурационном файле указываются правила, по которым девайсу с каким-то MAC address выдаётся IP address в конкретной подсети (или даже конкретный IP address). У каждого девайса уникальный MAC address, который указан в DHCP пакетах (как минимум в Request/Reply, как Client Hardware Address) и по нему DHCP Server ищет настройки в своём конфигурационном файле, и предлагает IP address в нужной подсети, в зависимости от настроек администратора. 2.). Передача DHCP пакетов в правильные VLAN - это настройка DHCP Relay + FDB (устройство выучило, в каком VLAN на каком порту был получен пакет от устройства с MAC address = Source MAC из DHCP пакета). Я напомню, что все фактические операции с пакетами сводятся к нескольким базовым сетевым функциям - коммутации (switching), маршрутизации (routing) или нескольким другим. Все остальные протоколы, по сути нужны для уточнения параметров этих сетевых функций и/или для обработки данных на данном устройстве. studio.kzbin.infokyWbxySjhqE/edit

Спасибо!

Спасибо! Ответ на ваш вопрос получается большим. Если ответ получился и непонятным - напишите, я попробую переформулировать. Термин "туннель" не совсем точно визуализиреут происходящее с трафиком. Это не две дыры в земле с соединяющими их дорогой. Это скорее два почтовых пункта. На оригинальном пакете указан конечный пункт назначения. Вы приносите этот пакет на ближайший к вам (в вашем VNI) пункт ЗАпаковки (VTEP_1). У пункта ЗАпаковки есть адрес ближайшего к конечному адресу пункту РАСпаковки (VTEP_2). Дальше ваш оригинальный пакет запаковывают ещё раз, и на новой упаковке указывают адрес пункта РАСпаковки (VTEP_2). И дальше по существующим дорогам и способам доставки отправляют в пункт РАСпаковки. Там его развернут (он попадёт в нужный VNI) и отправят к конечному адресату. Система работает точно так же. Мы на устройстве с VTEP_1 должны запаковать пакет и указать в новом IP-layer информацию об устройстве, на котором пакет распакуется. Другими словами мы знаем, что наш трафик должен достичь VTEP_2 - выхода из туннеля. В дополнительном IP указывается DST_IP = IP VTEP_2. SRC_IP = IP VTEP_1 (наш VTEP, на котором мы запаковываем пакеты). И дальше запакованный пакет маршрутизируется (routes, роутится) через существующие сети на VTEP_2, используя DST_IP = IP VTEP_2. Туннель должен иметь точку входа и точку выхода - они конфигурируются на устройстве !входа! с указанием нужных данных. На устройстве VTEP_1 мы конфигурируем информацию о VTEP_2, его IP и т.п. Если есть несколько разных туннелей, начинающихся на нашем устройстве - мы конфигурируем их все указывая наш VTEP_1 -> VTEP_2; VTEP_1 -> VTEP_3 и т.п. Или можно VTEP_1.1 -> VTEP_2, VTEP_1.2 -> VTEP_3, тут уже зависит от того, действительно ли вы хотите сконфигурировать несколько разных точек входа на одном и том же устройстве. Просто напоминаю, что туннель IPinIP и VxLAN однонаправленный. На точке входа конфигурируете туннель VTEP_1 - > VTEP_2. Если вам надо, чтобы трафик бежал обратно, вы на втором устройстве должны сконфигурировать туннель VTEP_2 -> VTEP_1.

Спасибо. Сейчас готовлю видео по MPLS. И если у вас есть идеи о том, какие ещё важные и запутанные протоколы нуждаются в объяснении - пожалуйста, пишите.

@@simplyexplained2642 было бы интересно послушать про statefull/stateless

Спасибо!

Спасибо!

Thank you!

Пока что не планирую долгие нудные лекции с деталями и нюансами. По Cisco видео с примерами много, а детали настройки зависят от конкретного производителя маршрутизатора, и, как правило, для каждого конкретного семейства устройств у производителя в документации примеры прописаны лучше всего. Эти видео планируются для того, чтобы максимально просто объяснить основные понятия и операции, и дальше, читая документацию с конкретными деталями люди кивали и говорили "угу, угу, угу" а не "это вообще они что кому на каком написали?"

@@simplyexplained2642 буду ждать долгие нудные лекции с деталями и нюансами. Уже давно перерос джун-уровень)

Если я словами сформулирую не совсем понятно - скажите, я попробую картинку нарисовать. Адрес подсети это "условная величина". В подавляющем большинстве случаев это число используется, чтобы определить направление, в котором находится хост, чтобы роутить туда трафик, предназначенный этому хосту. Представьте себе маршрутизатор (роутер), с тремя интерфейсами. И на нём сконфигурированы роуты (маршруты), которые говорят, что за одним интерфейсом находится подсеть с "адресом подсети" 11.12.13.0/24, за вторым 22.23.24.0/24, а за третьим 33.34.35.0/24. Тогда, если вам надо отправить пакет хосту 22.23.24.157, система выберет отправить его за второй интерфейс, потому что хост - где то там, в подсети с "этим адресом". При этом, сам по себе 0 в конце ничего не значит. Если у вас адрес хоста 44.55.66.0, но в этом сегменте так много хостов, что он имеет "адрес подсети" 44.55.0.0/16 - то адрес хоста ни у кого не вызывает вопросов. Даже больше, вы можете пользоваться "адресом подсети" как адресом хоста внутри своей подсети, например, у вас будет хост с IP 10.10.10.0 и второй 10.10.10.1, и они будут пингать друг друга в подсети 10.10.10.0/31 и даже 10.10.10.0/24, но вот уже настроить роутинг так, чтобы снаружи без проблем роутился трафик с dst IP 10.10.10.0 может оказаться проблемным (зависит от того, что у вас за устройства и какие защиты у них включены по умолчанию)

@@simplyexplained2642 задал вопрос, так как арендую сервер на hetzner с белой 29ой сеткой, подключенной через бридж гипервизора. Получается, что из сети теряется адреса: 1 для бриджа, 1 для сети, 1 для бродкаста, 1 для шлюза (это такие рекомендации от hetzner). И как бы что остается? Да ничего не остается... Есть идеи как это сделать по другому, но останавливать нельзя, да и IPMI там нет. А после прочтения комента думаю, что наверное можно навешать все, (кроме бродкаста) на адрес сети.

Спасибо! Я не разбивал нетворкинговые видео по плейлистам потому что они в некоторых протоколах взаимосвязаны и плей-листы будут пересекаются, но с учётом получившегося количества видео - согласен, я попробую их сгруппировать.

Если практика - это пройтись по конкретным протоколам мультикаст роутинга, вроде IGMP или DVMRP - да, есть планы. Если видео по настройке мультикаст в каких-то эмуляторах - то пока что нет в планах.

@@simplyexplained2642 да, я про эмуляторы

Хорошая идея, спасибо!

@@simplyexplained2642 я точно посмотрю про мультик

@@unicoxr5tj417 Тема мультикаста очень обширная, новое видео с обзором мультикаста тут: kzbin.info/www/bejne/hYmwoWqAeqyVY8U

@@simplyexplained2642 посмотрел

В целом - да, задача MC-LAG в том, чтобы гарантировать связность для того устройства, которое находится на вершине этого треугольника: для синего устройства. И всё таки вы можете решить, что связность хостов за устройством 2 и хостов за устройством 3 вам всё таки нужна, и другого, хорошего, способа организовать её - нет. И тогда вы можете, например: - настроить роутинг (маршрутизацию) через УС как через маршрутизатор. У некоторых производителей роутинг на тот же интерфейс запрещён (если это по сути отражение/reflection пакета), по этому вы можете, к примеру, развести подсети по разным VLAN. Это усложняет общую конфигурацию MC-LAG :( - если Dell позволяет - настроить роутинг (маршрутизацию) через подсеть Peer портов. Но это всегда самый плохой способ, даже если разрешено вашим Dell, считается разумным блокировать не MC-LAG связность по Peer Ports. Там и так кипит работа. В принципе, фантазия и готовность выйти за границы разумного помогут вам в организации почти любой топологии. Когда получится настроить - поделитесь пожалуйста, как :) .

Thank you!

Спасибо!

Здравствуйте! Спасибо за вопрос, я коротко :) отвечу на него в комментариях и потом попробую снять видео на эту тему. 1. Измерение задержек в зависимости от нагрузки - это часть Performance Benchmarking testing. Могут быть требования к задержкам в зависимости от условий эксплуатации устройства, или их измеряют по стандартам, чтобы сравнить с конкурентами. Для сетевых устройств стандарт: rfc 2544. datatracker.ietf.org/doc/html/rfc2544 Для датацентров стандарт rfc 8239 datatracker.ietf.org/doc/html/rfc8239 2. Hardware platforms for automated network testing такие как IXIA и Spirent имеют встроенную поддержку как минимум для тестирования по RFC2544, (проверьте, есть ли у вас соответствующие лицензии). 3. Допустимые значения задержек сильно зависят от типа сетей и оборудования, их назначения и т.п., их скорее всего надо искать в требованиях к проекту или к оборудованию для проекта, я даже не могу вспомнить, видел ли я хоть в каком-то стандарте такие требования. разве что в IEEE 802.3, но он чудовищный по размерам, просто не помню. 4. И коротко о собственно задержках. 4.1 Нагрузки на систему должны никак не влиять на возможности принять входной трафик. Это касается всех типов портов ethernet устройств. Система должна быть физически не в состоянии перегрузить вход. 4.2 Задержки "физически" появляются на выходе из устройства, после прохождения пакета от входа до выхода, сильно зависят от устройства, типа трафика, количества и типа активных протоколов и функций и т. п. Механизмы уменьшения задержек зависят от всего этого зоопарка. Важно: В стандарте описаны настройки и процедуры для измерения работы параметров системы !согласно стандарта! Если у вас специализированная система - вам надо мерять параметры системы и в условиях приближённых к фактическим условиям работы. 5. Борьба с задержками делиться на: a) собственно борьбу с задержками, например, самый простой способ влияния на свич (коммутатор) - store-and-forward поменять на cut-through b) реакцию на нагрузку ( CoS-QoS-DiffService) c) борьба с нагрузкой: паузы (PFC), можете посмотреть их обзор тут: kzbin.info/www/bejne/Zn_bp6Z9gat7g5o Если есть вопросы или хорошие идеи о чём ещё надо снять видео - пишите.

@@simplyexplained2642 Это из реального кейса, между двумя маршрутизатора линк в 100Гбит. При штатной работе пинг с маршрутизатора 1 до маршрутизатора 2 ~1 мсек. Трафик ~ 5-10 Гбит. В чнн трафик поднимается до 80-90 Гбит пинг увеличивается до 50мсек.

@@user-le8cx3uy3x О, хороший пример, поможет показать, почему в технических проектах так важно всё записывать. Вот смотрите, с человеческой точки зрения рост пинга во много раз - это слишком много и так быть не должно. С технической точки зрения - возникает 2 вопроса: 1) в каких условиях (что за конфигурация и трафик)? и 2) а какой рост в этих условиях допустимый? В вашем примере поведение можно разбить на четыре основных роли: - Пользователь продукта: начинает жаловаться на то, что при каких-то там 80-90 Гбит пинг увеличивается с 1 мсек до 50 мсек, ужасно, так жить нельзя, сделайте что-то и т.п. Что вполне ожидаемо. - Менеджер продукта (не технический): начинает бегать по офису с криком "Всё пропало, немедленно исправить, клиент уезжает, продукт простаивает а-а-а-а-а-а" - Девелопер, разрабатывающий этот маршрутизатор: спрашивает "а как должно то быть?" - Тестер продукта: Смотрите, пинг это IP/ICMP, который обрабатывается, скажем так, CPU маршрутизатора. Это полноценная обработка IP пакета (убрать Ethernet header, отправить на CPU, получить ответ с CPU, найти соответствующий IP Interface, проверить таблицу ARP и если нет записи опросить соседей, добавить Ether header, отправить). Это долго само по себе. Если вырос трафик, и это просто data-traffic который должен просто по L2 форвардиться по существующим правилам - то пинг, по идее так сильно расти не должен, если... : - если это не какой-то маршрутизатор, который всё делает через CPU. - Или если это какой-то трафик, который заставляет маршрутизатор интенсивно перестраивать таблицу машрутизации в X тысяч записей (смотря сколько поддерживается) или интенсивно учить ARP, или делать другие действия которые дополнительно грузят CPU. Тогда, в некоторых условиях, рост в 25 раз - это всего в 25 раз. - если есть конфигурация, которая позволяет дать пингу более высокий приоритет при обработке, и снизить задержку при сильных нагрузках, и эта конфигурация не срабатывает - ...... (другие варианты) Поэтому нужна дополнительная информация для того, чтобы реагировать на увеличение времени пинга: - Есть документ, в котором написано, что пинг соседа для 100Гбит подключения, в данной конфигурации и для данного типа трафика, или независимо от трафика, не должен превышать ххх мсек (сильно меньше или больше 50). - Вы сравниваете версии маршрутизаторов, и с таким же трафиком и конфигурацией, прошлая версия маршрутизатора проводила пинг за xxx мсек (ххх>50 или xxx<50, стало лучше, хуже, не поменялось) и надо что-то по этому поводу предпринять. Или нет. - Вы сравниваете производителей маршрутизаторов, и при одинаковой конфигурации и с таким же трафиком маршрутизатор другого производителя показал пинг ххх мсек, и вы, сравнив все параметры, выбираете производителя ...

Idea is to detect all yogurt logos visible on the shelf. Photo was done at the shop, just passing by the shelf. Code is written on Python, and processing is just math (visual scene analysis), no ML. Simple segmentation mechanism is used (color-based) and algorithm have to use 3 detection params except of 2, but it's expected for simple segmentations.

Спасибо! :)