Comments 54
Я тут дома играюсь с построением отказоустойчивой сетевой инфраструктуры для сети устройств умного дома, так я отказался от dhcp как от единой точки отказа. Шанс что после выключения света dhcp сервер не проснётся гораздо больше чем то, что не проснётся тупой свитч.
Так делайте DHCP на свиче, это же очевидно
а потом в сети появляется стремная железка со стремным ethernet-контроллером от не менее стремной конторы synopsys. их gmac где только не встречается...
и вот иногда он может быть не то криво сконфигурирован при синтезе, или еще что-нибудь случиться, но как только закончится dhcp lease (и ос сходит на dhcp-сервер за новым)- железка с этим контроллером просто перестанет отвечать даже на пинги. при этом с самой железки tcp-коннекты поднимаются и работают.
а потом захочется воткнуть в usb ему другую сетевуху- а usb-то тоже от synopsys. dwc_usb. те, кто пробовал его попрогать на расте в микроконтроллерах- поймут xD
(он проваливается в stall, если процессор слишком медленно работает. или сборка дебажная (и поэтому достаточно медленная))
извините, я опять трогала стремные платы. а вон та проблема с гмаком лечится установкой этой железке статического адреса и ни в коем случае не использования конкретно на ней dhcp.
Ну давайте посмотрим что у вас происходит в сети. Ваш умный дом связывается с другим устройством по IP, допустим вы добились огромной отказоустойчивости отказавшись от DHCP. Во-первых у вас идет общение по какому-то протоколу из набора 802.3 или 802.11 который тоже может отказать. Причем в них заложен механизм CSMA/CD (CSMA/CA) который вообще создан для нарушения передачи данных а 802.3af и аналоги еще при сбое могут и выжечь сетевой порт. Нужно от него избавится. Дальше избавьтесь от 802.1d и аналогов которые сейчас даже в домашних роутерах встречаются - он тоже умеет блокировать работу портов, бродкастовый шторм менее опасен - хоть какие-то данные при нем будут ходить. Дальше на очереди arp - если он сбойнет - то все, никакая связь работать не будет. Для отказоустойчивости рекомендую заполнять arp таблицы статикой. Для пущей надежности работы сети еще хорошо inarp заполнять статикой. Следом если он стучится в интернет у нас как бы DNS - я напоминаю что для работы с ним используется и UDP и TCP, смотрите чтобы ваш домашний роутер не запутался от этого! Нужно избавится от этого!! Переделайте прошивки! Ну и собственно UDP ненадежен и не имеет подтверждения - его бы хорошо бы из стэка вообще выпилить. Но это еще не все! У вас там еще маршрутизация, а это возможность отправить пакет не туда куда надо, тоже ненадежно! Лично видел отказ ядра маршрутизации включая статику на чекпоинтах R81.10 при включенной опции ptp в OSPF. Избавляйтесь, что-нибудь придайте вместо этого. И вишенка на торте - у вас там еще маршрутизатор который ПЕРЕПИСЫВАЕТ каждый пересылаемый сетевой пакет, понимаете насколько это ненадежно и недоверенно? А если он ошибется? А уже с криптографией вообще трэш творится, это намеренная порча пересылаемых данных чтобы они при перезаписи стали как белый шум! Намеренная, понимаете?!
А если серьезно - забудьте вообще о отказоустойчивости в домашних условиях. Особенно с мнением что отключение DHCP хоть как-то повышает отказоустойчивость домашних устройств подключенных одним сетевым проводом и/или в перегруженном радиоэфире. И да, тупой свич за 1,5 тыс рублей по надежности проиграет даже 15-ти летнему 2950, несмотря на все умные фишки последнего.
А почему именно "тупой свич за 1,5 тыс рублей по надежности проиграет даже 15-ти летнему 2950"?
Потому что цена подсказывает экономию на компонентах. Ну и все-таки опыт в проектировании железа тоже что-то значит, ну немного так, не находите? И когда дядюшка Ляо производит скажем маршрутизатор с типа 802.11ac и 100 Мбит портами (лично видел) - я не думаю что такие люди в принципе о чем-то думают при проектировании.
А можно ещё более конкретно? Мне пока в голову приходит только очень дешёвая схема питания, которая может негативно влиять на надёжность свитча за полторы тысячи.
С опытом проектирования железа тоже не всё очевидно - за 15 лет больше людей-непрофессионалов стало сталкиваться с железом (Arduino и другие подобные платформы набирают популярность) и получать связанные с этим знания, хорошие решения стали становиться массовыми и дешёвыми из-за упаковки их в одну микросхему или модуль, CAD-софт стал больше уметь делать автоматически.
Я никогда видел разобранного Catalyst, но дешёвых китайских свитчей разобрал некоторое количество, и там внутри почти ничего нет - трансформаторы (а иногда даже их нет, и стоят MagJack), линейный стабилизатор, генератор, десяток пассивных компонентов и одна микросхема, которая делает всё. Какие компоненты и решения, использованные в Catalyst 2950 делают его более надёжным?
Где реализована коммутация/маршрутизация/ACL - в железе или на CPU
Вероятность битовых ошибок и их исправление
Отказоустойчивость компонентов
Качество питания и устойчивость к скачкам в сети
Глубина и качество тестирования ПО, отвечающего за Control Plane
То же, но про взаимодействие с SDK чипа, реализующего программирование правил в железо.
Возможность обновления ПО (неактуально, правда, для старых коробок)
Ну почему. Если mimo у клиента нет, и ширина канала 20мгц, то теоретическая максимальная скорость около 100мегабит грязными.
из них чистыми около 80 мегабит в многопоточной нагрузке при идеальных условиях.
в однопоточном режиме в идеальных условиях вы получите уже чуть более 50 мегабит.
Так что железка хоть и странная, но не бесполезная.
Или вот вам реальный кейс.
Дача. интернет через вышку ДО 40 мегабит.
витуху тянуть лениво, но локалку хочется побыстрее чтоб была.
Итого максимально быстрый Wi-fi требуется, а между точкой доступа и модемом может быть и кабель на 100 мегабит.
Класс, спасибо. Ёмко, популярно. Как я жил без mtr?
А зачем вы так утрированно все описали? Вы же прекрасно знаете кучу существующих технологий в сетевом оборудовании которые решают определенные задачи, acl, dhcp snooping итд. Зачем гадания на кофейной гуще, сетевик должен знать как у него формируется путь из точки а в точку б, и какие технологии применены и какие эффекты могут принести. Rspan нет?
Я как раз приводил примеры проблем в сети, которые с виду простые, но локализовать их не так-то просто. Тут или нужны хорошие полные инструкции по диагностике, либо профессиональная интуиция.
И они требуют как раз знания инструментария.
Ну а без технических подробностей, потому что публикация рассчитана немного на другую аудиторию, и у меня есть места, где их как раз в достатке)
Сразу видно, что не сетевик.
Вот, кстати, у серверника тоже куча существующих технологий, от логов до strace, и должен знать, какой процесс какие данные куда перекидывает....
и чё он там часами выясняет, почему у него загрузка под 100%, почему диски захлёбываются и какого чёрта политики частью ПК игнорируются. Как опять SCCM начал швырять софт через всю удалённым ПК, вместо использования регионального сервера.
Вот, я - не сетевик, скорее, серверник. strace мне как-то помог выяснить, что сервер 1С в Linux без настроенного обратного DNS не работает. С "потерявшимися сайтами" и раскатыванием обновления из хранилища за ~3500 км, вместо локального - тоже сталкивался, а вот почему диски захлёбываются - до сих пор не могу выяснить (вернее, выяснил - "кто-то" при построении отчётов активно использует временные таблицы, но вот кто это - осталось загадкой)...
А из непонятного в сетях - была как-то партия материнских плат, которые при "выключенном" компьютере время от времени начинали слать в сеть кучу пакетов, маркированных рандомными MAC-адресами, в итоге таблицы свитчей переполнялись и сеть "ложилась"; перезагрузка коммутаторов спасала минут на 15, после чего опять "опа!"... чуть меньшее зло - какие-то контроллеры СКУД попались с одинаковыми MAC-адресами, и когда объединили два соседних заводских корпуса, постоянно стал срабатывать RSTP, хотя при ручном контроле никаких петель выявить не удавалось...
Мир сетевых технологий удивителен — в нём прогрессивные вещи, вроде SDN и прямой программируемостью структур в чипах коммутации сочетаются с чудовищным legacy времён рассвета информационных технологий.
С верхних этажей небоскреба сложно разглядеть фундамент. Однако что, что вы так смело считаете "чудовищным legacy" на деле является надежным фундаментом. Для всего. Если опуститься вниз, то на медь влияют соседние кабели, грозы, силовая электроника, а на оптику даже смена дня и ночи (и тепловой расширение).
Впрочем, фраза о том, что "мир сетевых технологий удивителен" - она абсолютно правильная.
Могу привести краткий рецепт отказоустойчивой сети, где многое разрулено на L2 (дело было в 2008 году, так что вспомню не всё, но общую картину думаю обрисую)
В реальной сети (на момент внедрения 20к абонентов, при расчетной ёмкости до 16М абонентских подключений, которую после мы расширили ещё в разы) использовалось следующее оборудование:
коммутаторы последней мили LinkSys SPS 224G4
опорные пункты 802.1ad инкапсуляции пользовательских VLAN и в качестве ядра сети (терминирование 802.1ad + OSPF) Cisco ME 3400
Firewall + DMZ Cisco ASA 5500
в DMZ стойка с серваками под gentoo c vmware
Border не вспомню, но не суть - это уже другая история
Изначально идея топологии была такой: VLAN на пользователя, пользовательские вланы инкапсулируются в транспортные, от ядра кольца по опорникам, магистральные порты тегированы 802.1ad, от опорников кольца по абонентским свичам, магистральные порты тегированы 802.1q, везде на магистральных портах rSTP, на пользовательских DHCP Snooping + IP Source Guard + STP Root Guard + IGMP Snooping + терминирование пользовательских VLAN (в общем полная L2 изоляция абонентов)
Затем мы открыли для себя чудесную магию L2 DHCP Relay + Option 82, чем многократно увеличили теоретический предел ёмкости сети, то есть, если сперва мы выдавали сети на основе назначенного пользователю VLAN ID, то затем стали на основе MAC адреса свича и номера порта. У нас пользовательские вланы на порт остались только для корпоративных клиентов, для которых необходимо было организовывать L2 транспорт между удалёнными сегментами (2 офиса в разных концах города в одном бродкаст домене), все обычные домашние абоненты прекрасно помещались, по 256 /30 сетей в одном VLAN а изоляция, или наоборот разрешение маршрутизации (например по просьбам геймеров) клиентов достигалась за счет вышеописанных мер безопасности на порту и за счет ACL + OSPF в ядре
В такой конфигурации у нас ни разу не было ни одного шторма, а весь L3, вся фильтрация, маршрутизация, биллинг, шейпинг и тд были сосредоточены в ядре сети и DMZ. Да, это создавало на ядро ядрёную нагрузку, по этому у нас там было МЕ-шек с запасом, но я периодически пересекаюсь с техниками, текущими админами, от которых знаю, что покрытие и абонентская база разрослась в сотни раз, а сеть работает до сих пор как часы.
RSTP на магистральных портах собранных в кольца? Если при Вас ни разу не сбойнуло - значит масштаб опорных колец сети был ОЧЕНЬ маленький. У RSTP есть такое понятие как diameter - и при более 7 коммутаторах в кольце уже могут начаться side-effects, которые либо пытаются полечить с помощью тюнинга таймеров STP, либо с помощью натягивания другого костыля - MSTP с "сегментацией" по регионам. Но потом поддерживать это очень сложно, да и опять - масштабируемость и скорость сходимости просто отвратительные.
Я как раз своими руками одну из таких "опорных сетей" провайдера переводил на IP/MPLS - потому что по мере роста она столкнулась с чудовищными бродкаст-штормами. Хотя, когда была "маленькой" - все работало "как часы" (за исключением того, что сходимость сети оставляла желать лучшего)
P.S: Единственное, что можно добавить - что я это "наследие" переделывал в 2016 году. Сама архитектура, видимо, закладывалась еще в 2008 году)
Подпишусь под каждым словом!
А кольца может имело смысл собирать на erps? Там и собираются они меньше 50мс.
Вы что то путаете, диаметр 7 - это про STP, а не про rSTP, у которого максимальный диаметр 18, при том, что Cisco рекомендует использовать 10.
... и при более 7 коммутаторах в кольце...
Диаметр определяет расстояние от корневого коммутатора до самого дальнего коммутатора в кольце, без учета самого рута, а не общее количество коммутаторов, то есть при диаметре Dmax = 7 (STP), максимальное количество коммутаторов будет определено как Dmax * 2 + 1 = 15, при Dmax = 18 (rSTP), соответственно кольцо ограничено 37 устройствами, при рекомендациях Cisco для rSTP D = 10, рекомендованное количество = 21 коммутатор.
Мы посчитали, что с учетом резерва на расширение абонентской ёмкости кольца ну и, понятно, из соображений минимизации времени обновления таблиц MAC адресов, разумно будет ограничиться 16 коммутаторами (17, если считать рута, то есть сам опорник, соответственно решили отталкиваться от диаметра 8), хотя у нас было 2 сегмента сети по удалённым регионам, где в кольцах (на разных опорниках) было 28 и 32 коммутатора, но я, подготавливая сетевого инженера себе на замену, оставил ему четкие рекомендации докинуть туда ещё МЕ-шек и разделить эти кольца на меньшие, что он впоследствии добросовестно выполнил. Я более чем уверен, что при расширении сети, ребята не раз раздували кольца, всовывая туда свичей чуть ли не под лимит, для быстрого покрытия, просто затем докидывая МЕ 3400 и разбивая их на более мелкие. То же правило действовало и для опорников - по 16 штук в кольце от ядра.
Про диаметр - я не перепутал, это рекомендации IEEE. Да, может быть до 20 устройств в кольце (циска и другие вендоры "вскользь" разрешают это на Ваш страх и риск - рекомендации я видел такие же, как и от IEEE).
Но 37 устройств и даже 20 в кольце Л2 - это безумно много - и вот почему: при прохождении каждого хопа BPDU от корневого коммутатора "перерождается" каждым коммутатором и он из поля max age вычитает единичку - а это поле по умолчанию равно 20. Если maxage=0, то далее BPDU не отправится - поэтому понятия не имею, как у Вас Висели гирлянды из 28 и 32 коммутаторах (разве что там был BPDU-туннелинг и сами устройства на магистральных портах не работали в rSTP).
Так же, чем больше устройств в плоской л2 топологии - тем выше риск коллизий хешей, сбоя протокола или неудачной настройки и т.п - все, что выше было описано в статье повторять это я не буду
И это мы еще с Вами не обсудили то, что часть канальной ёмкости теряется просто так из-за блокировки порта протоколом RSTP (хотя на уровне Л3 её можно было бы использовать).
Во первых читаем внимательно:
RSTP (IEEE 802.1w) natively includes most of the Cisco proprietary enhancements to the 802.1D spanning tree, such as BackboneFast, UplinkFast, and PortFast. RSTP can achieve much faster convergence in a properly configured network, sometimes in the order of a few hundred milliseconds. Classic 802.1D timers, such as forward delay and max_age, are only used as a backup and are not necessary if point-to-point links and edge ports are properly identified and set by the administrator. Also, the timers are not necessary if there is no interaction with legacy bridges.
Во вторых, при грамотной настройке edge ports, при 32 свитчах в кольце, получаем 2 ветки по 16 свитчей
Если вы сталкивались с проблемами на "legacy bridges" или использовали оборудование неведомого Китайского бренда, то возможно Вы и правы, однако у нас вся сеть была построена на Cisco и всё работает как часы
... В третьих, был инцидент, когда в кольце с 28 свичами, оборвало линк повалившимся деревом (на том сегменте пришлось тянуть по столбам, так как в частный сектор не было пути прокладки по ГТС), RSTP отработал как надо и в одной из веток получилось 26 свитчей (как Вы выразились, гирлянда), ни каких проблем не возникло - это реально факт из практики.
Ок, читаем далее внимательно :)
"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 т.е)
Отрасль ИТ от других отличает то, что в ней, обычно, от качества результата не зависит жизнь человека. Во всяком случае, напрямую.
Не соглашусь.
Банальный пример: Сетевой сервис по ошибке списал сумму денег за услугу, которую не оказал. Именно в этот момент начинает ухудшаться качество жизни человека.
человек потерял деньги
человек нервничает, что может повлиять на здоровье
тратит время на возврат своих денег
Еще пример: Через интернет человек, который имеет ограниченные возможности заказал лекарство от которого зависит его жизнь, но произошел системный сбой и привезли не то лекарство или вообще не привезли. В такие моменты и возникают вопросы зависимости жизни человека от IT.
Чем глубже интегрируется IT в общество, тем зависимее становится жизнь человека от IT.
«Мы в ответе за тех, кого приручили»
Лис, Маленький принц, Антуан де Сент-Экзюпери
Ну, согласитесь, это несколько натянутые примеры? Я говорю про смерть или вред здоровью как прямое следствие ошибок или проблем. Нельзя сравнить это с обрушением моста или врачебной ошибкой.
Пограничными на сегодняшний день являются медицина и автомобили, напичканные электроникой.
Ну, согласитесь, это несколько натянутые примеры?
Реал: некая электрокомпания решила сэкономить на сотрудниках, обходящих дома и сверяющих показания счетчиков с теми данными, которые эти счетчики автоматически передают в компанию.
Создали сайт, на котором пользователь сети самостоятельно вручную вводит показания своего счетчика.
Все ок и супер.
За исключением пустяка — если пользователь не обновляет через установленный интервал показания счетчика через свой личный кабинет — то ему автоматом начисляется предполагаемая сумма платежа (какой там алгоритм расчета, я не знаю)
И вот бабушке-божьему одуванчику внезапно приходит платежка с суммой платежа за э/э, достойной завзятого майнера… причину смерти не смогут установить ни полиция, ни родственники.
(по счастью, в реале смертей еще не было, но за сердце таки хватались)
Ну и в большом пролете те, кто надолго уехал из дома — сидят и гадают, что там: может квартиру взломали и там сейчас живут местные сквоттеры — проверить то показания удаленно нельзя, без посторонней помощи.
Всё ещё далеко не прямая связь между причинами и следствием. Тут должны потрудиться тараканы в голове.
Так можно довести и до того, что производство унитазов - критическая отрасль, от которой зависит жизнь людей. Что если в нём плохо смывается содержимое - и год за годом точит психологическое здоровье владельца?
Deleted
Застал материнские платы с одинаковыми mac адресами на сетевухах. Типа обновил комп, все летает кроме сети, она тупит страшно. Но у соседей вроде тоже тупит...
Да, бывало такое. И даже в масштабах ядра оператора сети, где не особо ожидаешь дублирования MAC'ов в отличие от сегмента клиентского оборудования.
И порой изменение MAC'а при вводе в эксплуатацию даже в инструкции по настройке прописывали)
Ещё можно вспомнить прошивки "от Олега", естественно с одинаковыми маками. веселье начиналось сразу везде - и в биллинге (особенно если там какой-нибудь ip-mac-port-binding), и на l2
Появилось желание использовать chatGPT для отфильтровывания безусловно интересной но не несущей полезную информацию стилистической оболочки
никто и не думал о том, что жизнь кадра должна быть конечной и скоротечной.
Думали, у вас на картинке с шиной показаны терминаторы.
картинка со cвичем NetGear GS105
У меня внешне точно такой же хаб NetGear FE104 все еще стоит дома и работает как вспомогательное устройство :)
Отрасль ИТ от других отличает то, что в ней, обычно, от качества результата не зависит жизнь человека. Во всяком случае, напрямую
Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25.
На самом деле, очень сложно притянуть сбой ИТ к конкретным смертям. Сколько уже был массовых сбоев в госпиталях, когда вставали лаборатории, нарушался документоборот и, соответственно, замедлялось оказание медпомощи пациентам?
Или когда АСУТП колом встаёт и спасают "аналоговые технологии", своевременно останавливающие техпроцесс.
Кстати, что касается Therac-25 - предыдущая модель тоже имела эти ошибки, но там были "аналоговые" датчики, которые останавливали установку при возникающей угрозе пациенту. В 25 - их убрали.
Большое спасибо за примеры с bash скриптами! Отличная идея, как быстро организовать перебор портов при проверке и выдавать данные о доступности через AND/OR. Век живи - век учись:)
новый эфемерный src port из диапазона
1024-6535
У вас тут пятёрочка потерялась
Есть только одна причина, растягивать L2: вам чересчур спокойно живётся и хорошо спится и руководство разделяет вашу тоску.
1)Не прокидывать несколько L3, если нужно несколько протоколов.(привет ipx)
2)А что если софт не умеет в L3? На практике не сталкивался, но сталкивался к примеру с тем, что софт не умеет выбирать нужный IP(если у устройства 2 IP адреса). Подозреваю L3 может не уметь что-то типа потоковой трансляции steam.
Сеть виновата