Спасибо. Приятно смотреть и слушать. Освежил память
@simplyexplained2642Ай бұрын
Спасибо!
@maisonkepval3338Ай бұрын
Годно! Но, немного критики: я б не стал в описании писать "простое", мне так не показалось. Простое - это когда всё просто, никаких свичингоф и роутингоф, берите пример с Олиферов - у них всё на аналогиях. Это первое. Второе, на будущее, поменьше англицизмов: не "лэйбл", а метка, не "вендор", а поставщик. И третье, бессмысленное гоняние курсором по экрану немного отвлекает от повествования. Всё это лично моё мнение. Возможно, я не прав. Спасибо.
@simplyexplained2642Ай бұрын
Вы правы в том, что можно больше упростить, тут я ищу баланс между "упростить чтобы было понятно всем" и "рассказать так, чтобы было проще читать спецификацию". И при работе со всеми этими протоколами обязательно читать спецификацию, даже если инженер думает, что читал и помнит :) Про мышку - спасибо за замечание, прослежу.
@user-ne4bd3ry1n2 ай бұрын
vtep интерфейс включаем в bridge (linux) в который включена виртуалка?
@simplyexplained26422 ай бұрын
Короткий ответ: 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
@user-ne4bd3ry1n2 ай бұрын
что за срез? может это широковещательный домен?
@simplyexplained26422 ай бұрын
Уточните пожалуйста вопрос. Где именно? Это схематическое представление router, потому что VxLAN в части передачи пакетов по туннелю работает по IP/UDP. Сторона, содержащая непосредственно станции/hosts (те станции которые общаются с другими станциями через туннель) могут использовать как L2 (VLAN) так и L3 (IP networks/sub-nets)
@user-ne4bd3ry1n2 ай бұрын
@@simplyexplained2642 host он же не знает ничего про VxVLAN. ip протокол хоста без arp запросов (они широковещательные) не сможет общаться с другими хостами. Один и тот же VxVLAN на разных площадках объединяет широковещательные домены хостов. arp запрос как попадает через VXVLAN на другую физическую ноду/узел
@user-ne4bd3ry1n2 ай бұрын
@@simplyexplained2642 почему то исчез мой вопрос про широковещание и arp ы между хостами на разных железках но в одной VxVLAN
@manya2493 ай бұрын
Видео супер, удивлена, что у канала так мало подсписчиков. Очень доступно и понятно рассказывает!
@simplyexplained26423 ай бұрын
Спасибо!
@natikxairov40733 ай бұрын
спасибо, коротко ясно
@simplyexplained26423 ай бұрын
Спасибо!
@user-hn2tj8jf9j3 ай бұрын
просто топ
@simplyexplained26423 ай бұрын
Спасибо!
@bulba19954 ай бұрын
Я вам признателен за данный материал , очень просто и понятно все обьяснили .
@simplyexplained26424 ай бұрын
Спасибо!
@titlemin25764 ай бұрын
Спасибо вам,отлично и понятно все объяснили
@simplyexplained26424 ай бұрын
Спасибо!
@AalexVerr5 ай бұрын
Спасибо за доклад. Было бы интересно послушать про RT & RD.
@simplyexplained26425 ай бұрын
Спасибо! Спасибо за идею!
@lekseiagrafenin24975 ай бұрын
Спасибо большое за ваш труд. Это реально все очень полезно. Но прошу вас выпустить ролик про Multichassis LAG EVPN. Я так понимаю эта реализация имеет rfc
@simplyexplained26425 ай бұрын
Спасибо! Если вы имеете в виду комбинацию настроек MC-LAG (Multichassis LAG ) + EVPN, то это интересная комбинация, никогда такой не встречал, уточню. Возможно я что-то неправильно понял в вашем вопросе, если можете - уточните пожалуйста.
@lekseiagrafenin24975 ай бұрын
Я прошу прощения, это я не правильно понял. Я имею в виду EVPN мультихоминг. Это же может называться rfc реализацией mc-lag, на сколько я понимаю.
@simplyexplained26425 ай бұрын
@@lekseiagrafenin2497 Спасибо за идею!
@dmitry75445 ай бұрын
айпишка, айдишка - блювануть хочется
@simplyexplained26425 ай бұрын
Приятного!
@alexeikuleshov1936 ай бұрын
К сожалению не объяснили как dhcp сервер различает подсети, если запрос пришел от relay
@simplyexplained26426 ай бұрын
Спасибо за вопрос. Отвечу кратко и детально. Кратко: Задача 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
@albanec47026 ай бұрын
Отлично, всё по полочкам и наглядно, спасибо огромное!
@simplyexplained26426 ай бұрын
Спасибо!
@AalexVerr7 ай бұрын
Большое спасибо, коротко, ясно и по делу! Собственно, возникает вопрос исходя из Вашего видео, как VTEP понимает на какой DST-IP (VTEP) нужно отправить пакет, при условии, например, у нас множество VTEP и за каждым хост (виртуалка) в одном VNI Segment?
@simplyexplained26427 ай бұрын
Спасибо! Ответ на ваш вопрос получается большим. Если ответ получился и непонятным - напишите, я попробую переформулировать. Термин "туннель" не совсем точно визуализиреут происходящее с трафиком. Это не две дыры в земле с соединяющими их дорогой. Это скорее два почтовых пункта. На оригинальном пакете указан конечный пункт назначения. Вы приносите этот пакет на ближайший к вам (в вашем 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.
@johnlong69887 ай бұрын
Интересный контент! Спасибо! Интересно узнать о дальнейших планах на контент, какие темы хотели бы обозреть.
@simplyexplained26427 ай бұрын
Спасибо. Сейчас готовлю видео по MPLS. И если у вас есть идеи о том, какие ещё важные и запутанные протоколы нуждаются в объяснении - пожалуйста, пишите.
@johnlong69887 ай бұрын
@@simplyexplained2642 было бы интересно послушать про statefull/stateless
@evgeniykapitonenko85538 ай бұрын
+
@user-oc7jl6yx7t8 ай бұрын
Отличный материал, четко, понятно, спасибо!
@simplyexplained26428 ай бұрын
Спасибо!
@Dr.Livsi108 ай бұрын
очень круто все объяснено, коротко и понятно
@simplyexplained26428 ай бұрын
Спасибо!
@yuchizhou69489 ай бұрын
nice ! thank you, it helps!
@simplyexplained26429 ай бұрын
Thank you!
@unicoxr5tj4179 ай бұрын
о, наконец-то мультикаст))) автор, а практика настройки будет?)
@simplyexplained26429 ай бұрын
Пока что не планирую долгие нудные лекции с деталями и нюансами. По Cisco видео с примерами много, а детали настройки зависят от конкретного производителя маршрутизатора, и, как правило, для каждого конкретного семейства устройств у производителя в документации примеры прописаны лучше всего. Эти видео планируются для того, чтобы максимально просто объяснить основные понятия и операции, и дальше, читая документацию с конкретными деталями люди кивали и говорили "угу, угу, угу" а не "это вообще они что кому на каком написали?"
@unicoxr5tj4179 ай бұрын
@@simplyexplained2642 буду ждать долгие нудные лекции с деталями и нюансами. Уже давно перерос джун-уровень)
@vadimelshin26489 ай бұрын
Спасибо!
@pavelkryachko10 ай бұрын
А как используется адрес подсети? Какая там служебная информация ходит?
@simplyexplained264210 ай бұрын
Если я словами сформулирую не совсем понятно - скажите, я попробую картинку нарисовать. Адрес подсети это "условная величина". В подавляющем большинстве случаев это число используется, чтобы определить направление, в котором находится хост, чтобы роутить туда трафик, предназначенный этому хосту. Представьте себе маршрутизатор (роутер), с тремя интерфейсами. И на нём сконфигурированы роуты (маршруты), которые говорят, что за одним интерфейсом находится подсеть с "адресом подсети" 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 может оказаться проблемным (зависит от того, что у вас за устройства и какие защиты у них включены по умолчанию)
@pavelkryachko10 ай бұрын
@@simplyexplained2642 задал вопрос, так как арендую сервер на hetzner с белой 29ой сеткой, подключенной через бридж гипервизора. Получается, что из сети теряется адреса: 1 для бриджа, 1 для сети, 1 для бродкаста, 1 для шлюза (это такие рекомендации от hetzner). И как бы что остается? Да ничего не остается... Есть идеи как это сделать по другому, но останавливать нельзя, да и IPMI там нет. А после прочтения комента думаю, что наверное можно навешать все, (кроме бродкаста) на адрес сети.
@pavelkryachko10 ай бұрын
Офигительный канал! Автор очень крут! Одна гигантская просьба к автору, разбить все по плейлистам.
@simplyexplained264210 ай бұрын
Спасибо! Я не разбивал нетворкинговые видео по плейлистам потому что они в некоторых протоколах взаимосвязаны и плей-листы будут пересекаются, но с учётом получившегося количества видео - согласен, я попробую их сгруппировать.
@unicoxr5tj41710 ай бұрын
так, разобрали теорию, а практика будет?)
@simplyexplained264210 ай бұрын
Если практика - это пройтись по конкретным протоколам мультикаст роутинга, вроде IGMP или DVMRP - да, есть планы. Если видео по настройке мультикаст в каких-то эмуляторах - то пока что нет в планах.
@unicoxr5tj41710 ай бұрын
@@simplyexplained2642 да, я про эмуляторы
@unicoxr5tj41710 ай бұрын
мля, у мекня глаз от англицкага выпал, но есть на русском. Благодарка
@unicoxr5tj41710 ай бұрын
а за мультикаст поговорим?)
@simplyexplained264210 ай бұрын
Хорошая идея, спасибо!
@unicoxr5tj41710 ай бұрын
@@simplyexplained2642 я точно посмотрю про мультик
@simplyexplained264210 ай бұрын
@@unicoxr5tj417 Тема мультикаста очень обширная, новое видео с обзором мультикаста тут: kzbin.info/www/bejne/hYmwoWqAeqyVY8U
@unicoxr5tj41710 ай бұрын
@@simplyexplained2642 посмотрел
@user-lz5or7zg9s10 ай бұрын
Настроил на коммутаторах Dell пока ради теста. Хост подключенный к зеленому порту устройства 2 не пингует хост подключенный к зеленому порту устройства 3, и наоборот. Это нормально? Причина в том что обучения через пир линк не происходит. мак-таблица устройства 2 не содержит записей по устройствам подключеным к зеленым портам устройства 3, и наоборот. Видимо неправильно хотеть от этой схемы такой работы
@simplyexplained264210 ай бұрын
В целом - да, задача MC-LAG в том, чтобы гарантировать связность для того устройства, которое находится на вершине этого треугольника: для синего устройства. И всё таки вы можете решить, что связность хостов за устройством 2 и хостов за устройством 3 вам всё таки нужна, и другого, хорошего, способа организовать её - нет. И тогда вы можете, например: - настроить роутинг (маршрутизацию) через УС как через маршрутизатор. У некоторых производителей роутинг на тот же интерфейс запрещён (если это по сути отражение/reflection пакета), по этому вы можете, к примеру, развести подсети по разным VLAN. Это усложняет общую конфигурацию MC-LAG :( - если Dell позволяет - настроить роутинг (маршрутизацию) через подсеть Peer портов. Но это всегда самый плохой способ, даже если разрешено вашим Dell, считается разумным блокировать не MC-LAG связность по Peer Ports. Там и так кипит работа. В принципе, фантазия и готовность выйти за границы разумного помогут вам в организации почти любой топологии. Когда получится настроить - поделитесь пожалуйста, как :) .
@exploreyourdreamlife10 ай бұрын
This explanation has everything I could need to understand the difference between GARP and ARP proxy. Simply wow. Liked and Subbed!
@simplyexplained264210 ай бұрын
Thank you!
@user-ty9ke8gw4q11 ай бұрын
Спасибо посмотрел. Стало понятнее)
@simplyexplained264211 ай бұрын
Спасибо!
@user-le8cx3uy3x11 ай бұрын
Здравствуйте! А будет информация как обработка пакета происходит когда большая нагрузка на интерфейсе устройства. Интересует вопрос, как влияет нагрузка на задержки и как рассчитать какую задержку следует ожидать при определенной нагрузки линка между устройствами.
@simplyexplained264211 ай бұрын
Здравствуйте! Спасибо за вопрос, я коротко :) отвечу на него в комментариях и потом попробую снять видео на эту тему. 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 Если есть вопросы или хорошие идеи о чём ещё надо снять видео - пишите.
@user-le8cx3uy3x11 ай бұрын
@@simplyexplained2642 Это из реального кейса, между двумя маршрутизатора линк в 100Гбит. При штатной работе пинг с маршрутизатора 1 до маршрутизатора 2 ~1 мсек. Трафик ~ 5-10 Гбит. В чнн трафик поднимается до 80-90 Гбит пинг увеличивается до 50мсек.
@simplyexplained264211 ай бұрын
@@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, стало лучше, хуже, не поменялось) и надо что-то по этому поводу предпринять. Или нет. - Вы сравниваете производителей маршрутизаторов, и при одинаковой конфигурации и с таким же трафиком маршрутизатор другого производителя показал пинг ххх мсек, и вы, сравнив все параметры, выбираете производителя ...
@angelicamichelle1646 Жыл бұрын
At was that?
@simplyexplained2642 Жыл бұрын
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.