Comments 10
А что за устройство "hab"?
Про "hub" (англ. "центр") слышал и использовал, а вот о hab слышу в первый раз.
Крайне плохой гуглоперевод с кучей ошибок и опечаток. Публиковать такое - полное неуважение к читателям.
Но зачастую бывает, что в одной партии у сетевого оборудования имеются одинаковые MAC-адреса, а то и во всей партии.
Неужели в @Timeweb_Cloud используют настолько некачественное железо, что в одной партии (а то и во всей!) могут оказаться одинаковые маки?
Или это "зачастую бывает", но не у вас конкретно? В любом случае хотелось бы услышать наименование производителя, который присылал автору сетевое оборудование с одинаковыми маками.
Здравствуйте! Это авторская статья, не относящаяся к работе Timeweb Cloud. Давайте дождемся автора и узнаем, что он имел в виду)
Тут дело не только в качестве железа, а в банальной ошибке на производстве. Встречался с таким часто. Из последних это Российский производитель коммутаторов. В одной партии был один мак. Конкретного производителя указывать не буду, но их на нашем рынке не так много (думаю догадаетесь). Так же после закрытия границ, сталкивался с проблемами на китайских карточках Lr-link. И из интересного могу еще добавить про GUID (уникальный идентификатор) на usb носителях. Разворачивал siem и использовал usb носители с одним GUID на всю партию. Пришлось выбросить, так как siem детектила одну и туже флешку у всех работников на производстве.
Подождите: было утверждение, что "в целой партии был один мак-адрес на всём оборудовании". Это явное нарушение RFC 5342 (https://www.rfc-editor.org/rfc/rfc5342.txt), что является или признаком заводского брака, или признаком подделки. Почему не можете явно назвать производителя?
На будущее: большие организации при таких косяках немедленно возвращают всю партию оборудования поставщику и заносят его в чёрный список (надолго).
Намного чаще одинаковые маки появляются в случае кривых настроек виртуальных машин, если они на гипервизоре через бридж подключаются ещё и к физическим интерфейсам.
Но и это не проблема, ибо вменяемые сетевые инженеры вспоминают, что использование всяческих (R)STP позволит автоматически отключить хулигана.
Когда у вас всего несколько вендоров которые предоставляют свои продукты, очень не хочется ни кого заносить в черный список. Особенно если вы большая компания. Все что является заводским браком, всегда является просто браком. К этому можно относиться по-разному. Можно внести всех в черный список и везти «качественную» продукцию из-за рубежа, но без гарантии или не покупать ничего. Или мириться с косяками и сыростью Российских решений и адаптироваться.
Производителя называть не буду, так как все еще продолжаю с ними работать. Не хочется дискредитировать.
К гипервизорам всегда много вопросов. Я знаю из нормальных только esxi. Но там полнейший ужас с поддерживаемыми сетевыми карточками. А добавить драйверы в файл установщик тот еще геморрой.
Я уже лет 9 сетями не занимаюсь, но не понимаю каким образом STP способен защитить от коллизии МАКа. В худшем варианте, когда у вас коллизия по младшим адресам свитчей, то у вас будет 2 дерева. Но как правило, часто руками пишут BridgeID для корневого коммутатора. В остальных - как бы пофиг, ибо вычисляется кратчайший путь до корня, без учета там каких либо коллизий. Тут механизмы Loopback detection(который раньше не работал на портах с STP) или защита от МАК-спуфинга должна сработать.
Но принципиально, это все пофиг - т.к. это МАКи свитчей, а они сами не передают данные, только всякое служебное BPDU, IGMP, etc...
И вот тут вопрос к автору, почему не затронули вышеупомянутые протоколы, почему не раскрыли тему CSMA/CD, для ВиФи оно как бы актуально, та же общая среда.
И самый главный вопрос: Автор поднял тему коллизий адресов, но не рассказал про коллизию хешей, что как бы вполне себе реальная штука, особенно на стареньком недорогом железе, которое может достаться по наследству.
Сложно о простом. Канальный уровень (L2) модели OSI