Бесчеловечные сети

[HallEffect]

Интересная статья, есть над чем подумать. Стандартизировать это очень хорошо и правильно, но на деле, скорее всего, получится как с еще одним универсальным языком программирования. Да и как уже писали — вендоры на это не пойдут, потому что каждый из них хочет что бы сети были моновендорными. Это с одной стороны. С другой стороны, к примеру если вдруг все договорятся, то видятся некоторые проблемы. Система контроля, становясь единым местом сбора такого количества диагностической информации(от версии ПО до конфигов и логов), сама по себе становится никак не резервируемой и генерирующей в своем направлении не малый объем трафика.

[eucariot]

Ну так же можно сказать про выделенный маршрутизатор в качестве RR-сервера.Он собирает на себе все маршруты AS.
Есть понятие кластера, можно сделать георезервирования.
Централизация управления — вопрос времени, мне кажется.

[amarao]

Всё умрёт, останется openflow. На местах будут тупые железки, конфигурируемые втыкаемым в них токеном (где написан адрес контроллера).

А дальше софтовый openflow-контроллер, энтерпрайз, кластер под этот контроллер и т.д.

[EvilMan]

По поводу самодиагностики оборудования на таком высоком уровне — какая-то утопия. И да, уже есть OpenFlow. А про стандарты есть хороший стрип.

[amarao]

Насколько я знаю, у openflow по большому счёту никаких прямых конкурентов нет. Есть споры про мелочи, куча проприентарных решений, но вот как стандарт — только openflow. (Что не означает, что он готов к продакту).

[eucariot]

Ну по сути SDN?
Это в принципе не противоречит тому, о чём говорю я. Даже если будет SDN, нужен этот самый анализатор проблем на сети, автоматический траблшутинг, настройка. SDN — концепция несколько иного толка.

[amarao]

Я к тому, что на уровне железок это не решить — только если есть некая центральная точка, которая может показать «типовые топологии» и развернуть на существующих свичах.

Плюс некий момент, что коммутации-то делать всё равно кто-то должен, а это немалый объём работ в построении сети.

[eucariot]

Именно. Я прихожу к выводу, что роль конечных железок в такой сети — суметь составить топологию. И не важно занимаются они тупой коммутацией или сами принимают всё-таки решения.
Если L3-топологию мы можем получить с помощью IGP, то для L2 сейчас в лучшем случае можно было бы использовать LLDP/CDP. Но это не то пальто.

И даже в случае SDN — сам мозг будет знать только о части проблем — железка должна в стандартном виде суметь сообщить, что у неё есть какая-то аппаратная проблема.

[amarao]

«стандартный вид» SNMP trap'ов похож на «стандартный вид сообщения о проблемах»?

[eucariot]

Нет, конечно, нет. Сообщения — для человека. Трапы и логи для машин.

[rdntw]

сначала была статика, потом ленивым админам надоело и сделали динамику ( лень не единственная причина :) )
потом всякие BFD и FRR. и те же админы обслуживают другие протоколы. потом придется обслуживать системы, которые следят за системами ( сетями) как мне кажется.

[eucariot]

Вот в этом и есть мысль — инженеру не придётся следить за отдельными протоколами — достаточно следить за системой контроля.

[ekungurov]

Ну то есть утопическая цель не будет достигнута. Технические специалисты всё равно понадобятся, причем еще более «продвинутые».

[eucariot]

Более продвинутые будут поддерживать десятки таких систем. А оператору понадобятся только люди, которые смогут протянуть кабель и правильно воткнуть платы, и люди, которые смогут прочитать сообщение об ошибке в системе мониторинга, которая сведётся к следующим ситуациям:

• На сети случилось то-то и то-то. Сейчас всё в порядке
• Вышла из строя плата в 9-м слоту на узле 15, находящемся по адресу пр. Ленина, 1. Необходима замена
• Вышел пакет обновлений для оборудования DLink. Обновить?

Утрирую, конечно, но это было бы здорово.