Comments 12
Поделюсь нашим опытом (ISP):
В виду отсутствия LLDP на всех устройствах доступа и вообще каких-либо дискавери-протоколов, определяем физические связи руками. Таким образом мы поддерживаем актуальную базу ребер графа. Затем на основе этих ребер строится неориентированный беспетельный мультиграф (мульти — потому что между двумя устройствами может быть больше одной физической линки). На базе этих алгоритмов работает часть системы мониторинга (определение аплинков, предотвращение логических L2 петель, автоматическая прокладка вланов)
Используем SNMP, Telnet, HTTP для управления и контроля (некоторые девайсы настолько старые, что имеют функции, доступные только по веб-интерфейсу).
Таблицу ребер корректируем всякими алгоритмами, помечающие явно неверные связи. Очень грустим, что нет LLDP.
Теперь по статье:
>>> «Рассмотрим два коммутатора «А» и «Б», расположенные в одной подсети. Если коммутатор «А» видит на порту «а» коммутатор «Б», а коммутатор «Б» видит на порту «б» коммутатор «А» и в их таблицах нет другого сетевого устройства, которое одновременно видимо на портах «а» и «б», то коммутаторы «А» и «Б» соединены напрямую на канальном уровне „
Разве это так? По-моему, это утверждение будет верно, если каждый коммутатор пытался получить доступ к другому коммутатору, после чего в FDB-таблице закешируется запись о соседе. Если же они занимаются коммутацией другого сегмента, но при этом сами живут в отдельном сегменте (общий управляющий сегмент для обоих коммутаторов), то в FDB таблице не должны храниться мак-адреса друг друга в общем случае. На этом алгоритме я и пытался релаизовать автоматический поиск ребер графа, но столкнулся с тем, что это утверждение не всегда верно. Возможно Ваш метод работает в виду постоянной работы всяких дискавери-протоколов, которые действительно пытаются постоянно искать соседей, что поддерживает записи друг о друге в таблице мак-адресов.
В виду отсутствия LLDP на всех устройствах доступа и вообще каких-либо дискавери-протоколов, определяем физические связи руками. Таким образом мы поддерживаем актуальную базу ребер графа. Затем на основе этих ребер строится неориентированный беспетельный мультиграф (мульти — потому что между двумя устройствами может быть больше одной физической линки). На базе этих алгоритмов работает часть системы мониторинга (определение аплинков, предотвращение логических L2 петель, автоматическая прокладка вланов)
Используем SNMP, Telnet, HTTP для управления и контроля (некоторые девайсы настолько старые, что имеют функции, доступные только по веб-интерфейсу).
Таблицу ребер корректируем всякими алгоритмами, помечающие явно неверные связи. Очень грустим, что нет LLDP.
Теперь по статье:
>>> «Рассмотрим два коммутатора «А» и «Б», расположенные в одной подсети. Если коммутатор «А» видит на порту «а» коммутатор «Б», а коммутатор «Б» видит на порту «б» коммутатор «А» и в их таблицах нет другого сетевого устройства, которое одновременно видимо на портах «а» и «б», то коммутаторы «А» и «Б» соединены напрямую на канальном уровне „
Разве это так? По-моему, это утверждение будет верно, если каждый коммутатор пытался получить доступ к другому коммутатору, после чего в FDB-таблице закешируется запись о соседе. Если же они занимаются коммутацией другого сегмента, но при этом сами живут в отдельном сегменте (общий управляющий сегмент для обоих коммутаторов), то в FDB таблице не должны храниться мак-адреса друг друга в общем случае. На этом алгоритме я и пытался релаизовать автоматический поиск ребер графа, но столкнулся с тем, что это утверждение не всегда верно. Возможно Ваш метод работает в виду постоянной работы всяких дискавери-протоколов, которые действительно пытаются постоянно искать соседей, что поддерживает записи друг о друге в таблице мак-адресов.
А вы сами разрабатывали всю логику обнаружения топологии? Если все это делалось для одной конкретной сети, то усилия впечатляют! Можете рассказать, какие алгоритмы используете для обнаружения неверных связей?
По поводу замечания про алгоритм. Конечно, в его описании мы «срезали углы», чтобы было понятнее. Я попросил разработчиков модуля топологии прокомментировать: Согласны, что это утверждение верно, только в предположении полноты таблиц переадресации на коммутаторах «А» и «Б». Свойство полноты означает, что таблицы содержат все узлы подсети, которым могут быть доставлены пакеты через порты «а» и «б» коммутаторов «А» и «Б», соответственно. Поэтому, если они не соединены напрямую, то существует путь по которому пакеты маршрутизируются из «А» порта «а» в «Б» и из «Б» порта «б» в «А», но так как сеть не содержит циклов, то эти пути будут совпадать и любой промежуточный коммутатор «В» будет виден коммутатором «А» на порту «а» и коммутатором «Б» на порту «б», но тогда рассмотренное нами необходимое условие не выполняется.
В алгоритме автоматического поиска топологии второго уровня мы ставили задачу правильно определить возможные связи между коммутаторами исключив ложные, есть возможность добавить дополнительные связи при необходимости. При неполных таблицах ложные связи можно исключить рассматривая окружение коммутаторов, а именно, так называемое, сквозное множество на порту «а» коммутатора «А» и соответственно, порту «б» коммутатора «Б», это множество всех известных узлов полученных на всех портах коммутатора за исключением выбранного порта. Так вот, если сквозные множества на порту «а» и «б», соответственно, имеют общие узлы, то коммутаторы не могут быть соединены напрямую через порты «а» и «б, при условии, что они находятся в одной подсети.
В целом, конечно, работа модуля обнаружения топологии намного сложнее, чем его краткое описание в статье. Задача статьи — просто рассказать тем, кто не занимался вопросом всерьез, как в целом устроено определение топологии. А ссылочки на статьи мы привели, чтобы те, кто заинтересовался, смогли изучить тему поподробнее.
По поводу замечания про алгоритм. Конечно, в его описании мы «срезали углы», чтобы было понятнее. Я попросил разработчиков модуля топологии прокомментировать: Согласны, что это утверждение верно, только в предположении полноты таблиц переадресации на коммутаторах «А» и «Б». Свойство полноты означает, что таблицы содержат все узлы подсети, которым могут быть доставлены пакеты через порты «а» и «б» коммутаторов «А» и «Б», соответственно. Поэтому, если они не соединены напрямую, то существует путь по которому пакеты маршрутизируются из «А» порта «а» в «Б» и из «Б» порта «б» в «А», но так как сеть не содержит циклов, то эти пути будут совпадать и любой промежуточный коммутатор «В» будет виден коммутатором «А» на порту «а» и коммутатором «Б» на порту «б», но тогда рассмотренное нами необходимое условие не выполняется.
В алгоритме автоматического поиска топологии второго уровня мы ставили задачу правильно определить возможные связи между коммутаторами исключив ложные, есть возможность добавить дополнительные связи при необходимости. При неполных таблицах ложные связи можно исключить рассматривая окружение коммутаторов, а именно, так называемое, сквозное множество на порту «а» коммутатора «А» и соответственно, порту «б» коммутатора «Б», это множество всех известных узлов полученных на всех портах коммутатора за исключением выбранного порта. Так вот, если сквозные множества на порту «а» и «б», соответственно, имеют общие узлы, то коммутаторы не могут быть соединены напрямую через порты «а» и «б, при условии, что они находятся в одной подсети.
В целом, конечно, работа модуля обнаружения топологии намного сложнее, чем его краткое описание в статье. Задача статьи — просто рассказать тем, кто не занимался вопросом всерьез, как в целом устроено определение топологии. А ссылочки на статьи мы привели, чтобы те, кто заинтересовался, смогли изучить тему поподробнее.
> А вы сами разрабатывали всю логику обнаружения топологии?
Дык, я и говорю, в виду отсутствия полного покрытия всех моделей дискавери-протоколами, нет у нас системы обнаружения. То есть соединили патчкордом два девайса, добавили логическую связь в систему руками, а уже дальше автоматика управления/мониторинга. И кстати, я хотел именно на таком же как у Вас алгоритме делать обнаружение, прежде чем столкнулся с описанной ранее проблемой. А наткнулся я на нее, когда некий тестовый девайс стоял в разрыве между двумя другими девайсами, которые ничего о нем не знали, хотя трафик общения между ними шел именно через него.
> какие алгоритмы используете для обнаружения неверных связей?
Эти алгоритмы не универсальны, опираются на канальную инфраструктуру конкретно нашей сети. Например, если система видит живой порт с mng-вланом и маком на порту, но при этом логической связи нет, тут явно кто-то забыл добавить логическую связь. Или если видим связь между портами, на которых полное расхождение вланов и маков, значит явно связь неверная.
Дык, я и говорю, в виду отсутствия полного покрытия всех моделей дискавери-протоколами, нет у нас системы обнаружения. То есть соединили патчкордом два девайса, добавили логическую связь в систему руками, а уже дальше автоматика управления/мониторинга. И кстати, я хотел именно на таком же как у Вас алгоритме делать обнаружение, прежде чем столкнулся с описанной ранее проблемой. А наткнулся я на нее, когда некий тестовый девайс стоял в разрыве между двумя другими девайсами, которые ничего о нем не знали, хотя трафик общения между ними шел именно через него.
> какие алгоритмы используете для обнаружения неверных связей?
Эти алгоритмы не универсальны, опираются на канальную инфраструктуру конкретно нашей сети. Например, если система видит живой порт с mng-вланом и маком на порту, но при этом логической связи нет, тут явно кто-то забыл добавить логическую связь. Или если видим связь между портами, на которых полное расхождение вланов и маков, значит явно связь неверная.
не в ту ветку
Занимаюсь такой же проблемой для сети с примерно десятью тысячами устройств: cisco, d-link, huawei, extreme. С разными вланами для клиентов и управления и разными глюками оборудования.
Несколько уточнений и ограничений моего способа:
1) В каждом влане предполагается наличие только одного роутера. В нашей сети не всегда так, эти вланы не подходят для определения топологии и не учитываются.
2) Под оборудованием будет пониматься устройство, обладающее собственной таблицей коммутации. Под клиентом все остальные (это могут быть как клиенты, так и более «глупое» оборудование).
3) Перед опросом делается пинг до всех устройств, обладающих собственной таблицей коммутации.
4) Параллельные вланы — вланы, которые на всех свитчах выборки обладают одинаковым аплинком (портом в сторону роутера). Порт в сторону роутера определяется по началичию единственного порта с маком шлюза, мак шлюза определяется по IP-адресам роутеров и таблицам арпов.
5) Физическая топология может иметь кольца, логическая нет.
6) Есть устройства, которые не показывают некоторые мак-адреса (привет, des-3028), иногда даже адрес шлюза.
Схема в основном строится по таблицам коммутации (AFT в вашей терминологии, FDB в моей) в несколько этапов:
1) Делается пинг до всех устройств, обладающих собственной таблицей коммутации.
2) Со всех устройств собираются таблицы коммутации, с роутеров собираются ARP.
3) По этой информации определяется порты клиентов. Эти порты не содержат маков оборудования во влане управления (тут был глюк у многих коммутаторов, рассылающих свой мак в каких-нибудь ещё вланах помимо своего влана управления) и не являются транзитными (эта часть полуавтоматическая, система показывает и предлагает отметить вручную такие порты и мак-адреса, которые видны одновременно на нескольких портах, на которых нет мак-адресов оборудования. Я не нашёл способа это автоматизировать).
4) Для каждого мака определяется его конечное устройство из следующих соображений: для мака оборудования (устройства, обладающего собственной таблицей коммутации) это будет устройство с наименьшим числом маков в параллельных вланах, для мака клиента это порт из пункта 3.
На этом первый этап завершён, установлены соединения сети и соединения к клиентам, но не дополнительные, альтернативные или другие параллельные связи.
Второй этап:
1) Для каждой пары мак-влан определяются цепочки свитчей, на которых эта пара присутствует.
2) Каждая цепочка сортируется по числу маков в параллельных вланах.
3) Если нашлись такие четыре коммутатора что число маков (обозначим как a, b, c, d) на них соответствует правилу a>b>c>d, то считаем обнаруженной связь между b и с. Плюс ещё два варианта: a>b>c когда a наибольшее, тогда есть связь между a и b, и b>c>d когда d наименьшее, тогда есть связь между c и d.
4) Для каждой связи подсчитывается число попаданий, связи заносятся в схему начиная со связи с наибольшим весом, конфликтующие связи не учитываются (считаем их ошибками обнаружения).
Этот способ помогает найти все остальные связи, хотя ошибки тоже бывают. Как правило вызваны неодновременностью опроса устройств в сети (когда мак-адрес успел исчезнуть на части оборудования).
Несколько уточнений и ограничений моего способа:
1) В каждом влане предполагается наличие только одного роутера. В нашей сети не всегда так, эти вланы не подходят для определения топологии и не учитываются.
2) Под оборудованием будет пониматься устройство, обладающее собственной таблицей коммутации. Под клиентом все остальные (это могут быть как клиенты, так и более «глупое» оборудование).
3) Перед опросом делается пинг до всех устройств, обладающих собственной таблицей коммутации.
4) Параллельные вланы — вланы, которые на всех свитчах выборки обладают одинаковым аплинком (портом в сторону роутера). Порт в сторону роутера определяется по началичию единственного порта с маком шлюза, мак шлюза определяется по IP-адресам роутеров и таблицам арпов.
5) Физическая топология может иметь кольца, логическая нет.
6) Есть устройства, которые не показывают некоторые мак-адреса (привет, des-3028), иногда даже адрес шлюза.
Схема в основном строится по таблицам коммутации (AFT в вашей терминологии, FDB в моей) в несколько этапов:
1) Делается пинг до всех устройств, обладающих собственной таблицей коммутации.
2) Со всех устройств собираются таблицы коммутации, с роутеров собираются ARP.
3) По этой информации определяется порты клиентов. Эти порты не содержат маков оборудования во влане управления (тут был глюк у многих коммутаторов, рассылающих свой мак в каких-нибудь ещё вланах помимо своего влана управления) и не являются транзитными (эта часть полуавтоматическая, система показывает и предлагает отметить вручную такие порты и мак-адреса, которые видны одновременно на нескольких портах, на которых нет мак-адресов оборудования. Я не нашёл способа это автоматизировать).
4) Для каждого мака определяется его конечное устройство из следующих соображений: для мака оборудования (устройства, обладающего собственной таблицей коммутации) это будет устройство с наименьшим числом маков в параллельных вланах, для мака клиента это порт из пункта 3.
На этом первый этап завершён, установлены соединения сети и соединения к клиентам, но не дополнительные, альтернативные или другие параллельные связи.
Второй этап:
1) Для каждой пары мак-влан определяются цепочки свитчей, на которых эта пара присутствует.
2) Каждая цепочка сортируется по числу маков в параллельных вланах.
3) Если нашлись такие четыре коммутатора что число маков (обозначим как a, b, c, d) на них соответствует правилу a>b>c>d, то считаем обнаруженной связь между b и с. Плюс ещё два варианта: a>b>c когда a наибольшее, тогда есть связь между a и b, и b>c>d когда d наименьшее, тогда есть связь между c и d.
4) Для каждой связи подсчитывается число попаданий, связи заносятся в схему начиная со связи с наибольшим весом, конфликтующие связи не учитываются (считаем их ошибками обнаружения).
Этот способ помогает найти все остальные связи, хотя ошибки тоже бывают. Как правило вызваны неодновременностью опроса устройств в сети (когда мак-адрес успел исчезнуть на части оборудования).
>> По этой информации определяется порты клиентов. Эти порты не содержат маков оборудования во влане управления
откуда на порту клиента влан управления?
>> 3) Перед опросом делается пинг до всех устройств, обладающих собственной таблицей коммутации.
с какой целью?
>> 4) Для каждого мака определяется его конечное устройство из следующих соображений…
Этот пункт вообще не понял. Даже фразу не понял. Что значит определить конечное устройство для мака?
>> 1) Для каждой пары мак-влан определяются цепочки свитчей, на которых эта пара присутствует.
— Эта цепочка может не содержать существующий транзитный свитч, через который идет цепочка.
— Это может быть не цепочка, а дерево
>> 2) Каждая цепочка сортируется по числу маков в параллельных вланах.
что означает процесс сортировки цепочки?
откуда на порту клиента влан управления?
>> 3) Перед опросом делается пинг до всех устройств, обладающих собственной таблицей коммутации.
с какой целью?
>> 4) Для каждого мака определяется его конечное устройство из следующих соображений…
Этот пункт вообще не понял. Даже фразу не понял. Что значит определить конечное устройство для мака?
>> 1) Для каждой пары мак-влан определяются цепочки свитчей, на которых эта пара присутствует.
— Эта цепочка может не содержать существующий транзитный свитч, через который идет цепочка.
— Это может быть не цепочка, а дерево
>> 2) Каждая цепочка сортируется по числу маков в параллельных вланах.
что означает процесс сортировки цепочки?
откуда на порту клиента влан управления?
Под клиентом имелось в виду любое устройство без таблиц коммутации, в данном способе нет никакой разницы, клиент или UPS, например.
с какой целью?
Чтобы таблицы коммутации устройств были заполнены. Ну и чтобы не ломиться на отключенные устройства.
Этот пункт вообще не понял. Даже фразу не понял. Что значит определить конечное устройство для мака?
MAC-адрес клиента светится (присутствует в таблицах коммутации) на всех коммутаторах между роутером и клиентом, конечное устройство это то, в которое включен пользователь.
— Эта цепочка может не содержать существующий транзитный свитч, через который идет цепочка.
Почему не может? Может и содержит:
Роутер — свитч1 — свитч2 — свитч3 — клиент
Цепочка и есть набор транзитных свитчей, может быть я плохо объяснил.
— Это может быть не цепочка, а дерево
Для одной пары мак-влан — цепочка, ветвления ещё нет.
что означает процесс сортировки цепочки?
Каждому коммутатору присваивается вес на основании числа маков в параллельных вланах.
Например для мака 00-01-02-03-04-00 во влане 5 нашлись следующие коммутаторы:
192.168.0.17, 192.168.0.15, 192.168.0.22, 192.168.0.19, 192.168.0.18
Считаем число маков в параллельно идущих вланах:
192.168.0.17 (15 маков), 192.168.0.15 (22 мака), 192.168.0.22 (3 мака), 192.168.0.19 (84 мака), 192.168.0.18 (12 маков)
После сортировки:
192.168.0.19 (84 мака), 192.168.0.15 (22 мака), 192.168.0.17 (15 маков), 192.168.0.18 (12 маков), 192.168.0.22 (3 мака)
Получаем наиболее вероятный порядок включения оборудования:
192.168.0.19 -> 192.168.0.15 -> 192.168.0.17 -> 192.168.0.18 -> 192.168.0.22
Заносим в таблицу пары связей:
192.168.0.19 -> 192.168.0.15 (1 раз)
192.168.0.15 -> 192.168.0.17 (1 раз)
192.168.0.17 -> 192.168.0.18 (1 раз)
192.168.0.18 -> 192.168.0.22 (1 раз)
Повторив достаточно большое количество раз операцию для разных мак-адресов (и отсортировав по тому, как часто встретилась та или иная связь) мы получим что-то такое:
192.168.0.19 -> 192.168.0.15 (300 раз)
192.168.0.15 -> 192.168.0.17 (50 раз)
192.168.0.17 -> 192.168.0.18 (26 раз)
192.168.0.18 -> 192.168.0.22 (10 раз)
И какое-нибудь ошибочное, которое будет отброшено
192.168.0.17 -> 192.168.0.22 (1 раз)
>> Под клиентом имелось в виду любое устройство без таблиц коммутации, в данном способе нет никакой разницы, клиент или UPS, например.
Именно. Зачем такому клиенту влан управления?
>> Чтобы таблицы коммутации устройств были заполнены.
Это заблуждение, они заполняются не от этого. У вас влан управления один на всю сеть, включая сервер, с которого пингуете?
>> Почему не может? Может и содержит:
>> Роутер — свитч1 — свитч2 — свитч3 — клиент
>> Цепочка и есть набор транзитных свитчей, может быть я плохо объяснил.
Снимите со свитча2 айпишник, отключите лишние протоколы, оставьте голую коммутацию, и тогда свит1 и свитч3 не будут ничего знать про свитч2, будут думать, что подключены напрямую, хотя трафик между ними будет ходить через свитч2. В каких-то случаях и айпишник снимать не придется, от ситуации зависит, от аклов, маршрутизации.
>> Для одной пары мак-влан — цепочка
Почему? На каком-нибудь узле Х этот влан может идти на 5 портов, вот и получается дерево.
>> После сортировки:
Тогда это уже получается не цепочка, а просто список устройств. Цепочка не сортируется.
Именно. Зачем такому клиенту влан управления?
>> Чтобы таблицы коммутации устройств были заполнены.
Это заблуждение, они заполняются не от этого. У вас влан управления один на всю сеть, включая сервер, с которого пингуете?
>> Почему не может? Может и содержит:
>> Роутер — свитч1 — свитч2 — свитч3 — клиент
>> Цепочка и есть набор транзитных свитчей, может быть я плохо объяснил.
Снимите со свитча2 айпишник, отключите лишние протоколы, оставьте голую коммутацию, и тогда свит1 и свитч3 не будут ничего знать про свитч2, будут думать, что подключены напрямую, хотя трафик между ними будет ходить через свитч2. В каких-то случаях и айпишник снимать не придется, от ситуации зависит, от аклов, маршрутизации.
>> Для одной пары мак-влан — цепочка
Почему? На каком-нибудь узле Х этот влан может идти на 5 портов, вот и получается дерево.
>> После сортировки:
Тогда это уже получается не цепочка, а просто список устройств. Цепочка не сортируется.
Именно. Зачем такому клиенту влан управления?
Так исторически сложилось, я работаю с тем, что есть.
Если интересно моё личное мнение, то UPS может управляться по SNMP, не вижу смысла изолировать одно оборудование с SNMP от другого.
Это заблуждение, они заполняются не от этого
Таблицы коммутации заполняются на транзитных свитчах от прохождения пакетов от пингуемого оборудования до роутера. Пинг как пакет в этом плане подходит.
У вас влан управления один на всю сеть, включая сервер, с которого пингуете?
Нет, у каждого роутера свой. Роутеры в разных районах города. Компьютер, с которого производится этот массовый пинг находится в отдельном L2 сегменте для мониторинга.
Снимите со свитча2 айпишник, отключите лишние протоколы, оставьте голую коммутацию, и тогда свит1 и свитч3 не будут ничего знать про свитч2, будут думать, что подключены напрямую, хотя трафик между ними будет ходить через свитч2. В каких-то случаях и айпишник снимать не придется, от ситуации зависит, от аклов, маршрутизации.
Да, этим способом нельзя обнаружить неуправляемое оборудование или оборудование, с которого нельзя получить таблицы коммутации.
Почему? На каком-нибудь узле Х этот влан может идти на 5 портов, вот и получается дерево.
Дерево получается для влана в целом, всё верно. Но это не поможет определить что куда (в каком порядке) включено.
Влан без мак-адресов не информативен.
Имея мак-адрес конкретного устройства (назовём устройство Х) и мак-адрес шлюза (где терминируется сеть этого Х) мы можем определить группу устройств (какое-то подмножество от дерева) где мак устройства Х и мак шлюза на разных портах. Это транзитные коммутаторы для этого Х. В дереве они следуют друг за другом, нужно только определить их порядок.
Тогда это уже получается не цепочка, а просто список устройств. Цепочка не сортируется.
Упорядоченный список, это важно для метода. Потому что потом мы проверяем на соответствие критерию a>b>c>d
Приблизительно понял вашу схему сети и методику построения топологии. Эта методика не идеальна, но максимально подходит под вашу сеть.
Как долго проходит цикл опроса сети из 10 килодевайсов? Кешируете в базе? Какие L2, L3-кольца используете?
Как долго проходит цикл опроса сети из 10 килодевайсов? Кешируете в базе? Какие L2, L3-кольца используете?
Опрос происходит где-то за час. Могло бы быть и быстрее, но пока это не критично.
Да, в базе хранится информация за несколько дней для обработки (чтобы аварии в отдельных сегментах не приводили с исчезновению части схемы), а также история для поиска.
Около 2 млн записей о мак-адресах, примерно 100 тыс записей ARP.
Да, в базе хранится информация за несколько дней для обработки (чтобы аварии в отдельных сегментах не приводили с исчезновению части схемы), а также история для поиска.
Около 2 млн записей о мак-адресах, примерно 100 тыс записей ARP.
Sign up to leave a comment.
Определение топологии сети на уровнях 2/3 модели OSI