Комментарии 14
Интересная статья, есть над чем подумать. Стандартизировать это очень хорошо и правильно, но на деле, скорее всего, получится как с еще одним универсальным языком программирования. Да и как уже писали — вендоры на это не пойдут, потому что каждый из них хочет что бы сети были моновендорными. Это с одной стороны. С другой стороны, к примеру если вдруг все договорятся, то видятся некоторые проблемы. Система контроля, становясь единым местом сбора такого количества диагностической информации(от версии ПО до конфигов и логов), сама по себе становится никак не резервируемой и генерирующей в своем направлении не малый объем трафика.
0
Всё умрёт, останется openflow. На местах будут тупые железки, конфигурируемые втыкаемым в них токеном (где написан адрес контроллера).
А дальше софтовый openflow-контроллер, энтерпрайз, кластер под этот контроллер и т.д.
А дальше софтовый openflow-контроллер, энтерпрайз, кластер под этот контроллер и т.д.
0
По поводу самодиагностики оборудования на таком высоком уровне — какая-то утопия. И да, уже есть OpenFlow. А про стандарты есть хороший стрип.
0
Ну по сути SDN?
Это в принципе не противоречит тому, о чём говорю я. Даже если будет SDN, нужен этот самый анализатор проблем на сети, автоматический траблшутинг, настройка. SDN — концепция несколько иного толка.
Это в принципе не противоречит тому, о чём говорю я. Даже если будет SDN, нужен этот самый анализатор проблем на сети, автоматический траблшутинг, настройка. SDN — концепция несколько иного толка.
0
Я к тому, что на уровне железок это не решить — только если есть некая центральная точка, которая может показать «типовые топологии» и развернуть на существующих свичах.
Плюс некий момент, что коммутации-то делать всё равно кто-то должен, а это немалый объём работ в построении сети.
Плюс некий момент, что коммутации-то делать всё равно кто-то должен, а это немалый объём работ в построении сети.
0
Именно. Я прихожу к выводу, что роль конечных железок в такой сети — суметь составить топологию. И не важно занимаются они тупой коммутацией или сами принимают всё-таки решения.
Если L3-топологию мы можем получить с помощью IGP, то для L2 сейчас в лучшем случае можно было бы использовать LLDP/CDP. Но это не то пальто.
И даже в случае SDN — сам мозг будет знать только о части проблем — железка должна в стандартном виде суметь сообщить, что у неё есть какая-то аппаратная проблема.
Если L3-топологию мы можем получить с помощью IGP, то для L2 сейчас в лучшем случае можно было бы использовать LLDP/CDP. Но это не то пальто.
И даже в случае SDN — сам мозг будет знать только о части проблем — железка должна в стандартном виде суметь сообщить, что у неё есть какая-то аппаратная проблема.
0
сначала была статика, потом ленивым админам надоело и сделали динамику ( лень не единственная причина :) )
потом всякие BFD и FRR. и те же админы обслуживают другие протоколы. потом придется обслуживать системы, которые следят за системами ( сетями) как мне кажется.
потом всякие BFD и FRR. и те же админы обслуживают другие протоколы. потом придется обслуживать системы, которые следят за системами ( сетями) как мне кажется.
0
Вот в этом и есть мысль — инженеру не придётся следить за отдельными протоколами — достаточно следить за системой контроля.
0
Ну то есть утопическая цель не будет достигнута. Технические специалисты всё равно понадобятся, причем еще более «продвинутые».
0
Более продвинутые будут поддерживать десятки таких систем. А оператору понадобятся только люди, которые смогут протянуть кабель и правильно воткнуть платы, и люди, которые смогут прочитать сообщение об ошибке в системе мониторинга, которая сведётся к следующим ситуациям:
Утрирую, конечно, но это было бы здорово.
- На сети случилось то-то и то-то. Сейчас всё в порядке
- Вышла из строя плата в 9-м слоту на узле 15, находящемся по адресу пр. Ленина, 1. Необходима замена
- Вышел пакет обновлений для оборудования DLink. Обновить?
Утрирую, конечно, но это было бы здорово.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Бесчеловечные сети