Comments 72
Будучи студентом, никогда не думал, что скажу эту фразу — а вывод? Опыт использования? Помогло?
И сколько времени длится определение петли по сравнению с STP реквестирую. А еще лучше с RSTP.
Да вот всё про тестировать негде (не случаются петли). На столе проверили, битые порты, петли всех видов и мастей определялись на ура.
Область применения везде где нужно найти петлю и есть возможность подключится непосредственно в сеть. В сравнении с tcpdump сильно экономит ресурсы головного мозга.
Область применения везде где нужно найти петлю и есть возможность подключится непосредственно в сеть. В сравнении с tcpdump сильно экономит ресурсы головного мозга.
Игра — угадай язык программирования. Чур, в тэги не смотреть.
<hr />
В 21 веке такие сети долго не живут — мультикаст, броадкаст/arp флуд,, торренты убивают такие сети легко и не принужденно. Все клиенты разбегутся по значимым конкурентам типа билайна, интерзета и т.д.
Но не так уж мало сетей где к одному порту подключена цепочка из 5 — 6 неуправляемых коммутаторов.
В 21 веке такие сети долго не живут — мультикаст, броадкаст/arp флуд,, торренты убивают такие сети легко и не принужденно. Все клиенты разбегутся по значимым конкурентам типа билайна, интерзета и т.д.
За мкадом и кадом жизнь тоже есть.
Управляемое оборудование которое имеет минимальный функционал стоит на ebay от 20 до 50 баксов, доставка 30. Это в основном 24 порта, а бывает и 48. Так что не надо про МКАД рассказывать — желание сэкономить 3 копейки нельзя оправдать МКАДом
ебей какой-то, баксы. «Страшно далеки они от народа».
Реальная отмазка бывшего директора: «управляемое оборудование не нужно, бо спи....»
Отмазка-неотмазка, но ведь реально сопрут. :-) Корбиновскими/Билайновскими DES-3526 еще недавно все рынки были завалены — не знаю как сейчас. Собственно, как только нашли, как у них пароль сбрасывать — сразу и повалили пачки… Потом волна чуть схлынула, но пошла другая тема — те же Корбиновские/Билайновские, но списанные по причине блоков питания (2 конденсатора перепаять — стоимость и время ремонта стремятся к нулю) и продаваемые самими сотрудниками… И это в Москве. Что творится в регионах я вообще боюсь представить…
Там где Я давно работал DES-2108 на дом (саппорт радовался бы на 3-5 домов) хватило бы (3-5 этажей и 3-5 клиентов с линками до 190метров). Настоящая гавносеть, так как самы длиный участок: 7 км и over 50 тупых свичей (общее под 600 шт). Спасали от флуда самые дешевые домашние роутеры на 3-5 домов (в сторону от «магистрали») + VPN.
Сеть осенью (грозы) поднималась до 1 месяца :)
Сеть осенью (грозы) поднималась до 1 месяца :)
Сейчас, я полагаю, это уже неактуально, но тогда я бы вам посоветовал посмотреть в сторону любых коммутаторов на чипах rtl83xx и OpenRRCP. У меня на медной сети с около 3 тыс. клиентов во вполне промышленной эксплуатации даже IPTV мультикастовое работало. И красивая карта была, где домики радостно «горели» зеленым цветом, так что даже в случае чего было сразу ясно, куда идти. :-) Особенно доставлял феерический коммутатор Compex SDS1224 (ныне снятый с производства), который стоил 1100 руб. за 24 порта (16-портовый Компекс стоил 900 рублей или типа того). Длинки со своими ценниками нервно курили в сторонке. ;-)
А какая разница для неуправляемых коммутаторов между броадкастом\мультикастом и юникастом?
Ну про броадкаст я говорил в ключе что никто не сможет быстро найти такого человека на неуправляемом свиче.
А про мультикаст — свич 5 портов (типовая ситуация таких сетей), все одновременно включают iptv. Разные каналы. 4-5 мбит на канал, во все порты долбится поток в 4 потока по 20 мбит. Не очень мощные роутеры дохнут. На компе (в зависимости от сетевой карты и процессора) может начатся свистопляска.
А про мультикаст — свич 5 портов (типовая ситуация таких сетей), все одновременно включают iptv. Разные каналы. 4-5 мбит на канал, во все порты долбится поток в 4 потока по 20 мбит. Не очень мощные роутеры дохнут. На компе (в зависимости от сетевой карты и процессора) может начатся свистопляска.
Для l2 коммутаторов, я бы сказал. Управляемость дело в общем-то второстепенное.
Да нет, почему, вроде для управляемых коммутаторов IGMP Snooping дело сейчас достаточно распространенное.
Потому что IGMP это L3, а так всё ок.
IGMP — это L3. Я говорил про IGMP Snooping — это L2. Почитайте хотя бы в википедии.
Ну при чём тут википедия. Коммутатор разбирает кадр до заголовка IP? Разбирает. Всё, L3. Почему L2-то.
Я специально перечитал про IGMP и не нашел в IGMP-запросах заголовков IP. Поясните?
а их там и нет.
tools.ietf.org/html/rfc1112
2я версия. По идее, самая распространенная. На практике — хз.
tools.ietf.org/html/rfc1112
2я версия. По идее, самая распространенная. На практике — хз.
The multicast extensions to a host IP implementation are specified in
terms of the layered model illustrated below. In this model, ICMP
and (for level 2 hosts) IGMP are considered to be implemented within
the IP module, and the mapping of IP addresses to local network
addresses is considered to be the responsibility of local network
modules.
terms of the layered model illustrated below. In this model, ICMP
and (for level 2 hosts) IGMP are considered to be implemented within
the IP module, and the mapping of IP addresses to local network
addresses is considered to be the responsibility of local network
modules.
И дальше по тексту:
This model is for expository purposes only, and should not
be construed as constraining an actual implementation.
И потом, IGMP и IGMP Snooping — разные протоколы. Никто не спорит с тем, что IGMP — это L3.
This model is for expository purposes only, and should not
be construed as constraining an actual implementation.
И потом, IGMP и IGMP Snooping — разные протоколы. Никто не спорит с тем, что IGMP — это L3.
И что там дальше по тексту? Дальше по тексту говорится что это обобщённая, упрощённая для понимания абстракция, что из этого?
Я в курсе что такое IGMP, IGMP Snooping и прочие вещи. Я не понимаю, как не очевидно то, что в снупинге свитчу приходится раскручивать фрейм до третьего уровня. Или тут тоже возражения? IGMP Snooping работает на втором и третьем уровнях, такое бывает.
Изначально мне резануло упоминание «управляемых коммутаторов», которые вообще ни к селу ни к городу в контексте бродкастов/юникастов, совершенно технически безграмотная фраза.
Я в курсе что такое IGMP, IGMP Snooping и прочие вещи. Я не понимаю, как не очевидно то, что в снупинге свитчу приходится раскручивать фрейм до третьего уровня. Или тут тоже возражения? IGMP Snooping работает на втором и третьем уровнях, такое бывает.
Изначально мне резануло упоминание «управляемых коммутаторов», которые вообще ни к селу ни к городу в контексте бродкастов/юникастов, совершенно технически безграмотная фраза.
Изначально мне резануло упоминание «управляемых коммутаторов»Изначально не были упомянуты управляемые коммутаторы вообще.
Изначально мне резануло упоминание «управляемых коммутаторов», которые вообще ни к селу ни к городу в контексте бродкастов/юникастов, совершенно технически безграмотная фраза.Докажете? Я вот считаю, что юникасты на управляемых и неуправляемых коммутаторах обрабатываются по-разному.
Я в любом случае прошу Вас привести цитаты конкретные. Нигде в стандарте не написано, что снупинг работает на 3-ем уровне, и везде в литературе я встречал только 2-й. Так что я солидарен с фразой из английской википедии:
Essentially, IGMP snooping is a layer 2 optimization for the layer 3 IGMP.
Господь с вами, почитайте что такое transparent bridge. Если не включать всякие разные навороты, типа mac acl, unicast flooding control и прочее, прочее, что умеют современные управляемые свитчи, юникаст трафик умные и тупые коммутаторы передают абсолютно одинаково.
далее про мультикаст. клиент посылает ip пакет на мультикастовый адрес 224.0.0.22 с типом протокола верхнего уровня igmp, где уже в igmp заголовке написано на какую группу клиент хочет подписаться. Свитч увы должен этот пакет вскрыть аж до igmp заголовка, чтобы узнать в какую мультикаст группу стоит отнести данный порт. Собственно называть вы это можете хоть технологией третьего уровня, хоть технологией второго уровня, но технически прав allarm
далее про мультикаст. клиент посылает ip пакет на мультикастовый адрес 224.0.0.22 с типом протокола верхнего уровня igmp, где уже в igmp заголовке написано на какую группу клиент хочет подписаться. Свитч увы должен этот пакет вскрыть аж до igmp заголовка, чтобы узнать в какую мультикаст группу стоит отнести данный порт. Собственно называть вы это можете хоть технологией третьего уровня, хоть технологией второго уровня, но технически прав allarm
И зачем вообще тогда снупинг, почему нельзя обрабатывать тогда тупо IGMP, коль уровень третий?
Вы все-таки не правы. IGMP snooping — это вообще не протокол, а просто технология коммутации. И таки да — она может быть только L3, т.к., как вам сказали выше, коммутатор разбирает проходящие пакеты вплоть до тела самого IGMP, который действительно инкапсулирован внутрь IP (http://tools.ietf.org/html/rfc3376#section-4). А разбирает он их в любом случае, т.к. ему нужно определить, к какой группе подключается клиент, чтобы именно эту группу слать ему на порт (а потом отслеживает репорты от клиента, чтобы когда их не будет и пройдет таймаут — перестать слать эту группу).
Вся прелесть в том, что поддержка коммутатором IGMP snooping совершенно не эквивалентна поддержке им самого IGMP. IGMP — это протокол в общем-то маршрутизации. Им пользуются клиенты, подключающиеся к группам, и маршрутизаторы (Querier'ы в терминологии IGMP), которые эти группы им отдают. Коммутаторы уровня распределения, через которые идет сигнал от маршрутизатора до клиента, в обмене сообщениями IGMP не участвуют. Максимум, что они делают — фильтруют сообщения, что нужно делать, если используется IGMP v3 (а то один отключившийся от группы клиент при включенном на коммутаторе снупинге всех остальных клиентов этого коммутатора тоже от группы отключит).
Вся прелесть в том, что поддержка коммутатором IGMP snooping совершенно не эквивалентна поддержке им самого IGMP. IGMP — это протокол в общем-то маршрутизации. Им пользуются клиенты, подключающиеся к группам, и маршрутизаторы (Querier'ы в терминологии IGMP), которые эти группы им отдают. Коммутаторы уровня распределения, через которые идет сигнал от маршрутизатора до клиента, в обмене сообщениями IGMP не участвуют. Максимум, что они делают — фильтруют сообщения, что нужно делать, если используется IGMP v3 (а то один отключившийся от группы клиент при включенном на коммутаторе снупинге всех остальных клиентов этого коммутатора тоже от группы отключит).
IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2.
RFC 3376, Internet Group Management Protocol, Version 3
А по поводу снупинга — как иначе по вашему свич понимает, что это IGMP-запрос, не добравшись до его уровня инкапсуляции?
RFC 3376, Internet Group Management Protocol, Version 3
А по поводу снупинга — как иначе по вашему свич понимает, что это IGMP-запрос, не добравшись до его уровня инкапсуляции?
Сможете объяснить тогда как работает ip acl на реаальном l2 коммутаторе?
А это не философские ли споры пошли? По мне так если свитч умеет работать с ip то это L3 свитч.
Так Вы изначально не говорите так что мол l3 и баста. Не начинайте на it ресурсы такие споры.
Если свитч умеет работать с л3 то это л3 свитч и баста, ок.
На управляемых свичах есть телнет, значит они — L7-свичи?
Вы не правы. Вспомним о том, что «свич» — это коммутатор. :-) Уровень коммутатора определяется по тому, какие пакеты он может коммутировать. Если он может коммутировать только L2 пакеты — значит это L2 коммутатор/свич. Если может коммутировать L3 пакеты (выражаясь бытовым языком — выступать в качестве IP-маршрутизатора, хотя так говорить и безграмотно) — значит это L3 коммутатор/свич. :-)
Наличие в L2 коммутаторе функционала по работе с содержимым пакетов дальше 2 уровня (ACL, фильтры всякие, снупинги и т.п.) совершенно не делает его L3 коммутатором. :-) По маркетинговым соображениям такие коммутаторы называют L2+ и хотя соображения явно маркетинговые, лучшей альтернативы, вроде, никто не придумал. :-)
Наличие в L2 коммутаторе функционала по работе с содержимым пакетов дальше 2 уровня (ACL, фильтры всякие, снупинги и т.п.) совершенно не делает его L3 коммутатором. :-) По маркетинговым соображениям такие коммутаторы называют L2+ и хотя соображения явно маркетинговые, лучшей альтернативы, вроде, никто не придумал. :-)
Насколько мне известно, L3 означает, что коммутатор обладает базовыми функциями маршрутизации. Т.е. он может оперировать не только фреймами, но и IP-пакетами (ну или другими пакетами уровня 3).
Именно. И для l2 управляемость дело как раз таки одно из первостепенных.
1. Port security
2. Acl
3. Igmp snooping
4. Диагностика неисправностей. Начиная от проблем с кабелем заканчивая просто посмотреть маки на порту.
5. Ну и конечно же мониторинг.
Я может что то забыл, но без этих вещей я бы точно не взял l2 коммутатор. Не добавляю сюда loopback detection ибо фича за которую надо переплачивать. А начали мы разговор с МКАД.
1. Port security
2. Acl
3. Igmp snooping
4. Диагностика неисправностей. Начиная от проблем с кабелем заканчивая просто посмотреть маки на порту.
5. Ну и конечно же мониторинг.
Я может что то забыл, но без этих вещей я бы точно не взял l2 коммутатор. Не добавляю сюда loopback detection ибо фича за которую надо переплачивать. А начали мы разговор с МКАД.
Да нормально работают. Я не к тому, что ставить неуправляхи это хорошо, но такие цепочки живут и нельзя сказать чтобы часто что-то виснет.
Живут, и уже довольно долго. Естественно, это не радует, но приходится работать с чем есть. Да и преувеличиваете Вы, по-моему, насчёт убийственного влияния «мультикаст, броадкаст/arp флуд,, торренты» на жизнеспособность неуправляемого сегмента. По крайней мере, я сам не могу сказать, что я ночами не сплю из-за того, что подключен в неуправляемое оборудование. =)
семейство протоколов stp позволяет специально строить кольцевую топологию (для повышения отказоустойчивости и надёжности)
Какую какую топологию? И это — в разделе матчасть?
Основной задачей STP является приведение сети Ethernet с множественными связями к древовидной топологии, исключающей циклы пакетов. © Wikipedia Уж простите.
Только зачем все это? кто-то строит сети на тупых свитчах и роутит потом это писюками?
Была ситуация, когда медные линки заменялись на оптические и коммутаторы даже виду не подали по началу. Проблема началась когда при построении кольца я отключил RSTP на всех портах, на которых он был не нужен. После этого появились явные признаки закольцовки. В конце концов нашли причину. Если бы я не трогал STP, так и не узнал бы о том, что техники забыли отключить медную «витуху».
DES-3016 (глинк) вообще не может определить петлю если просто соединить два его порта.
А это вполне понятно. В DLink'ах loopdetect реализован по принципу, что если кадры ethernet, ушедшие из порта, в него же возвращаются, то петля есть. Например, если подключить «тупой» свитч (1008D, 1016D) в один из портов управляемого коммутатора и уже на нём замкнуть пару других портов, то управляемый сразу же определит петлю. А передача между двумя портами управляемого коммутатора dlink не будет обнаружена.
Таки смотря на каком. Как я помню, у них это как отдельная функция реализована. Loopdetect обычный — как элемент RSTP, а соединение своих же портов — совсем-совсем отдельно и не у всех. Но есть! И мне даже пригодилось один раз в захламленной серверной, где было непонятно, какие провода из свича куда идут! ;-)
Такое должен определять stp со включенным bpduguard
Вопрос к автору, не силен в питоне, но насколько я понял ваш скрипт определяет просто наличие петли в сети?
В чем тогда его практический смысл? узнать что петля есть — это конечно хорошо, но важно ее найти и устранить. а как ваш скрипт помогает в этом деле, я пока не понимаю…
В чем тогда его практический смысл? узнать что петля есть — это конечно хорошо, но важно ее найти и устранить. а как ваш скрипт помогает в этом деле, я пока не понимаю…
Кстати вот еще метод (правда, довольно индусский) определения петель. Я столкнулся с тем, что в сегменте, в котором есть закольцовки или коммутаторы-зомби, очень плохо работает PPPoE, возникает ошибка «линия занята». Возникает она по понятной причине — фрейм PADI приходит на сервер два раза, для первого он пытается инициировать сессию, для второго тут же отказывает. Получается что клиенту приходит и приём и отказ одновременно.
Так вот, о методе. PPPoE-сервер у меня на Linux. В опциях включено журналирование пакетов с некорректным адресом источника и назначения (martian source / destination). Если закольцовка есть — в логах начинают бешеными темпами появляться сообщения о том, что в VLAN'е, принадлежащем неисправному сегменту, обнаружены пакеты с «марсианскими» адресами источника. Скрипт, каждые пять минут запускаемый кроном, проверяет нет ли в последних строчках лога таких сообщений, если есть — сигнализирует. Плюс к этому — срабатывание loopdetect можно фиксировать по icmp trap.
Так вот, о методе. PPPoE-сервер у меня на Linux. В опциях включено журналирование пакетов с некорректным адресом источника и назначения (martian source / destination). Если закольцовка есть — в логах начинают бешеными темпами появляться сообщения о том, что в VLAN'е, принадлежащем неисправному сегменту, обнаружены пакеты с «марсианскими» адресами источника. Скрипт, каждые пять минут запускаемый кроном, проверяет нет ли в последних строчках лога таких сообщений, если есть — сигнализирует. Плюс к этому — срабатывание loopdetect можно фиксировать по icmp trap.
Sign up to leave a comment.
Loopdetect своими руками