>> Под клиентом имелось в виду любое устройство без таблиц коммутации, в данном способе нет никакой разницы, клиент или UPS, например.
Именно. Зачем такому клиенту влан управления?
>> Чтобы таблицы коммутации устройств были заполнены.
Это заблуждение, они заполняются не от этого. У вас влан управления один на всю сеть, включая сервер, с которого пингуете?
>> Почему не может? Может и содержит:
>> Роутер — свитч1 — свитч2 — свитч3 — клиент
>> Цепочка и есть набор транзитных свитчей, может быть я плохо объяснил.
Снимите со свитча2 айпишник, отключите лишние протоколы, оставьте голую коммутацию, и тогда свит1 и свитч3 не будут ничего знать про свитч2, будут думать, что подключены напрямую, хотя трафик между ними будет ходить через свитч2. В каких-то случаях и айпишник снимать не придется, от ситуации зависит, от аклов, маршрутизации.
>> Для одной пары мак-влан — цепочка
Почему? На каком-нибудь узле Х этот влан может идти на 5 портов, вот и получается дерево.
>> После сортировки:
Тогда это уже получается не цепочка, а просто список устройств. Цепочка не сортируется.
> А вы сами разрабатывали всю логику обнаружения топологии?
Дык, я и говорю, в виду отсутствия полного покрытия всех моделей дискавери-протоколами, нет у нас системы обнаружения. То есть соединили патчкордом два девайса, добавили логическую связь в систему руками, а уже дальше автоматика управления/мониторинга. И кстати, я хотел именно на таком же как у Вас алгоритме делать обнаружение, прежде чем столкнулся с описанной ранее проблемой. А наткнулся я на нее, когда некий тестовый девайс стоял в разрыве между двумя другими девайсами, которые ничего о нем не знали, хотя трафик общения между ними шел именно через него.
> какие алгоритмы используете для обнаружения неверных связей?
Эти алгоритмы не универсальны, опираются на канальную инфраструктуру конкретно нашей сети. Например, если система видит живой порт с mng-вланом и маком на порту, но при этом логической связи нет, тут явно кто-то забыл добавить логическую связь. Или если видим связь между портами, на которых полное расхождение вланов и маков, значит явно связь неверная.
В виду отсутствия LLDP на всех устройствах доступа и вообще каких-либо дискавери-протоколов, определяем физические связи руками. Таким образом мы поддерживаем актуальную базу ребер графа. Затем на основе этих ребер строится неориентированный беспетельный мультиграф (мульти — потому что между двумя устройствами может быть больше одной физической линки). На базе этих алгоритмов работает часть системы мониторинга (определение аплинков, предотвращение логических L2 петель, автоматическая прокладка вланов)
Используем SNMP, Telnet, HTTP для управления и контроля (некоторые девайсы настолько старые, что имеют функции, доступные только по веб-интерфейсу).
Таблицу ребер корректируем всякими алгоритмами, помечающие явно неверные связи. Очень грустим, что нет LLDP.
Теперь по статье:
>>> «Рассмотрим два коммутатора «А» и «Б», расположенные в одной подсети. Если коммутатор «А» видит на порту «а» коммутатор «Б», а коммутатор «Б» видит на порту «б» коммутатор «А» и в их таблицах нет другого сетевого устройства, которое одновременно видимо на портах «а» и «б», то коммутаторы «А» и «Б» соединены напрямую на канальном уровне „
Разве это так? По-моему, это утверждение будет верно, если каждый коммутатор пытался получить доступ к другому коммутатору, после чего в FDB-таблице закешируется запись о соседе. Если же они занимаются коммутацией другого сегмента, но при этом сами живут в отдельном сегменте (общий управляющий сегмент для обоих коммутаторов), то в FDB таблице не должны храниться мак-адреса друг друга в общем случае. На этом алгоритме я и пытался релаизовать автоматический поиск ребер графа, но столкнулся с тем, что это утверждение не всегда верно. Возможно Ваш метод работает в виду постоянной работы всяких дискавери-протоколов, которые действительно пытаются постоянно искать соседей, что поддерживает записи друг о друге в таблице мак-адресов.
У меня был только один такой случай. И в этом случае можно было использовать множественное наследование, так как была исключена возможность появления ромбовидной проблемы, из-за которой множественное наследование обычно бракуют. На словах не смогу рассказать, нужно рисовать рисунков.
Но случай касается борьбы с кривостью китайских разработчиков, которые пишут прошивки для своих девайсов с помощью генератора случайных прошивок.
Имеем несколько наборов:
1. набор функций, которые нужно реализовать, например, управление Vlan, IGMP, Option82, QinQ (но их гораздо больше)
2. имеем (непонятно почему) разные реализации управления на разных прошивках таким образом, что одна функция имеет одинаковую реализацию на моделях A, B, вторая функция — B, C, а третья — на моделях A, C
3. имеем разные способы управления (Telnet, SNMP, Web), т. к. где-то некая функция не реализована по SNMP, а есть только по Web или Telnet, ну и вообще много вариантов.
Я понимаю, что вы хотите сказать, что множественному наследованию сложно найти применение, поэтому оно не нужно. Возможно это просто технология с узкой специализацией.
Но проблему они не решают, а в многоэтажных обработках только ухудшают читабельность. Там читать приходится с середины, двигаясь глазами в обе стороны: влево — для чтения обработки элемента, вправо — для чтения фильтров.
Не описана проблема многоэтажных мапов с лямбдами, где читабельность геометрически регрессирует в связи с тем, что читать приходится с конца, постепенно поднимаясь, без нормальной возможности отладки/временного комментирования/вывода промежуточного результата. Я так и не понял, как можно отлаживать вложенную функциональщину в питоне.
Набросал пример от балды (извините, что на пасте, тут в карму насрали, теги не работают):
pastebin.com/1yQnJPDS
А у меня, а у него, а у них. Причем тут вы? У меня не бывает вирусов ни на фряхе, ни на винде, ни на линуксе, значит я могу сделать вывод, что эти 3 системы неуязвимы к вирусам? А если у меня будет самописная ОС, на которой сижу я, мои родители и моя собака, я могу утверждать, что она безопасная, раз под нее никто дыр не нашел?
Десктопных линуксов и без того мало — 1-2%, так половина из них еще и кастомные ядра ставят, функции выпиливают, настраивают фаерволы. Какому хакеру вы вперлись со своими уязвимостями, если есть 75% пользователей винды, половина из которых тыкают на все, что тыкается?
Я вступил в диалог после двух громких заявлений:
1. «если бы говнокодеры из абобе»
2. (своими словами) «баги внешнего слоя не должны крашить внутренний слой или обходить защиту»
Я доказал, что:
1. линукс пилят такие же говнокодеры
2. линукс крашится и пускает кого попало из внешнего кольца на внутреннее
Отстаивайте свою позицию, а не занимайте новую.
Пока что вы лишь доказали то, что «правильно отключать функцию, а не закрывать в ней дыру», представляю, какой прекрасный софт вы пилите.
Именно. Зачем такому клиенту влан управления?
>> Чтобы таблицы коммутации устройств были заполнены.
Это заблуждение, они заполняются не от этого. У вас влан управления один на всю сеть, включая сервер, с которого пингуете?
>> Почему не может? Может и содержит:
>> Роутер — свитч1 — свитч2 — свитч3 — клиент
>> Цепочка и есть набор транзитных свитчей, может быть я плохо объяснил.
Снимите со свитча2 айпишник, отключите лишние протоколы, оставьте голую коммутацию, и тогда свит1 и свитч3 не будут ничего знать про свитч2, будут думать, что подключены напрямую, хотя трафик между ними будет ходить через свитч2. В каких-то случаях и айпишник снимать не придется, от ситуации зависит, от аклов, маршрутизации.
>> Для одной пары мак-влан — цепочка
Почему? На каком-нибудь узле Х этот влан может идти на 5 портов, вот и получается дерево.
>> После сортировки:
Тогда это уже получается не цепочка, а просто список устройств. Цепочка не сортируется.
откуда на порту клиента влан управления?
>> 3) Перед опросом делается пинг до всех устройств, обладающих собственной таблицей коммутации.
с какой целью?
>> 4) Для каждого мака определяется его конечное устройство из следующих соображений…
Этот пункт вообще не понял. Даже фразу не понял. Что значит определить конечное устройство для мака?
>> 1) Для каждой пары мак-влан определяются цепочки свитчей, на которых эта пара присутствует.
— Эта цепочка может не содержать существующий транзитный свитч, через который идет цепочка.
— Это может быть не цепочка, а дерево
>> 2) Каждая цепочка сортируется по числу маков в параллельных вланах.
что означает процесс сортировки цепочки?
Дык, я и говорю, в виду отсутствия полного покрытия всех моделей дискавери-протоколами, нет у нас системы обнаружения. То есть соединили патчкордом два девайса, добавили логическую связь в систему руками, а уже дальше автоматика управления/мониторинга. И кстати, я хотел именно на таком же как у Вас алгоритме делать обнаружение, прежде чем столкнулся с описанной ранее проблемой. А наткнулся я на нее, когда некий тестовый девайс стоял в разрыве между двумя другими девайсами, которые ничего о нем не знали, хотя трафик общения между ними шел именно через него.
> какие алгоритмы используете для обнаружения неверных связей?
Эти алгоритмы не универсальны, опираются на канальную инфраструктуру конкретно нашей сети. Например, если система видит живой порт с mng-вланом и маком на порту, но при этом логической связи нет, тут явно кто-то забыл добавить логическую связь. Или если видим связь между портами, на которых полное расхождение вланов и маков, значит явно связь неверная.
В виду отсутствия LLDP на всех устройствах доступа и вообще каких-либо дискавери-протоколов, определяем физические связи руками. Таким образом мы поддерживаем актуальную базу ребер графа. Затем на основе этих ребер строится неориентированный беспетельный мультиграф (мульти — потому что между двумя устройствами может быть больше одной физической линки). На базе этих алгоритмов работает часть системы мониторинга (определение аплинков, предотвращение логических L2 петель, автоматическая прокладка вланов)
Используем SNMP, Telnet, HTTP для управления и контроля (некоторые девайсы настолько старые, что имеют функции, доступные только по веб-интерфейсу).
Таблицу ребер корректируем всякими алгоритмами, помечающие явно неверные связи. Очень грустим, что нет LLDP.
Теперь по статье:
>>> «Рассмотрим два коммутатора «А» и «Б», расположенные в одной подсети. Если коммутатор «А» видит на порту «а» коммутатор «Б», а коммутатор «Б» видит на порту «б» коммутатор «А» и в их таблицах нет другого сетевого устройства, которое одновременно видимо на портах «а» и «б», то коммутаторы «А» и «Б» соединены напрямую на канальном уровне „
Разве это так? По-моему, это утверждение будет верно, если каждый коммутатор пытался получить доступ к другому коммутатору, после чего в FDB-таблице закешируется запись о соседе. Если же они занимаются коммутацией другого сегмента, но при этом сами живут в отдельном сегменте (общий управляющий сегмент для обоих коммутаторов), то в FDB таблице не должны храниться мак-адреса друг друга в общем случае. На этом алгоритме я и пытался релаизовать автоматический поиск ребер графа, но столкнулся с тем, что это утверждение не всегда верно. Возможно Ваш метод работает в виду постоянной работы всяких дискавери-протоколов, которые действительно пытаются постоянно искать соседей, что поддерживает записи друг о друге в таблице мак-адресов.
Но случай касается борьбы с кривостью китайских разработчиков, которые пишут прошивки для своих девайсов с помощью генератора случайных прошивок.
Имеем несколько наборов:
1. набор функций, которые нужно реализовать, например, управление Vlan, IGMP, Option82, QinQ (но их гораздо больше)
2. имеем (непонятно почему) разные реализации управления на разных прошивках таким образом, что одна функция имеет одинаковую реализацию на моделях A, B, вторая функция — B, C, а третья — на моделях A, C
3. имеем разные способы управления (Telnet, SNMP, Web), т. к. где-то некая функция не реализована по SNMP, а есть только по Web или Telnet, ну и вообще много вариантов.
Я понимаю, что вы хотите сказать, что множественному наследованию сложно найти применение, поэтому оно не нужно. Возможно это просто технология с узкой специализацией.
Еще вариант: у меня рак архитектурирования.
pastebin.com/1yQnJPDS
а вот через списковые включения:
pastebin.com/DD0aG0U7
читабельность умерла окончательно
Набросал пример от балды (извините, что на пасте, тут в карму насрали, теги не работают):
pastebin.com/1yQnJPDS
Товарищи ФП-шники, научите меня…
Сказануть такое — полный фейл. У меня всё.
А у меня, а у него, а у них. Причем тут вы? У меня не бывает вирусов ни на фряхе, ни на винде, ни на линуксе, значит я могу сделать вывод, что эти 3 системы неуязвимы к вирусам? А если у меня будет самописная ОС, на которой сижу я, мои родители и моя собака, я могу утверждать, что она безопасная, раз под нее никто дыр не нашел?
Десктопных линуксов и без того мало — 1-2%, так половина из них еще и кастомные ядра ставят, функции выпиливают, настраивают фаерволы. Какому хакеру вы вперлись со своими уязвимостями, если есть 75% пользователей винды, половина из которых тыкают на все, что тыкается?
Я вступил в диалог после двух громких заявлений:
1. «если бы говнокодеры из абобе»
2. (своими словами) «баги внешнего слоя не должны крашить внутренний слой или обходить защиту»
Я доказал, что:
1. линукс пилят такие же говнокодеры
2. линукс крашится и пускает кого попало из внешнего кольца на внутреннее
Отстаивайте свою позицию, а не занимайте новую.
Пока что вы лишь доказали то, что «правильно отключать функцию, а не закрывать в ней дыру», представляю, какой прекрасный софт вы пилите.