Виртуалка в публичном облаке появилась ближе к концу повествования. А сначала у нас была виртуалка на выделенной железной машине, которую обслуживали полностью мы сами.
Всё ещё далеко не прямая связь между причинами и следствием. Тут должны потрудиться тараканы в голове.
Так можно довести и до того, что производство унитазов - критическая отрасль, от которой зависит жизнь людей. Что если в нём плохо смывается содержимое - и год за годом точит психологическое здоровье владельца?
Ну, согласитесь, это несколько натянутые примеры? Я говорю про смерть или вред здоровью как прямое следствие ошибок или проблем. Нельзя сравнить это с обрушением моста или врачебной ошибкой.
Пограничными на сегодняшний день являются медицина и автомобили, напичканные электроникой.
Под чудовищным legacy я тут подразумеваю такие штуки как Frame Relay, SDH, попытки синхронизации времени через IP-сеть или непосредственно Ethernet. NAT!
И это в некотором смысле добро, потому что всё, что поверх продолжает работать. Просто весь багаж техдолга вынесен на уровень фундамента :)
Я как раз приводил примеры проблем в сети, которые с виду простые, но локализовать их не так-то просто. Тут или нужны хорошие полные инструкции по диагностике, либо профессиональная интуиция.
И они требуют как раз знания инструментария.
Ну а без технических подробностей, потому что публикация рассчитана немного на другую аудиторию, и у меня есть места, где их как раз в достатке)
На самом деле мне близки вещи, которые вы описали. И согласен почти со всем.
Однако для того, чтобы что-то случилось, об этом нужно говорить. Говорить нужно много и при любой возможности, прожужжать всем уши и стучаться через все каналы. И тогда, после того, как каждый будет знать, что есть NETCONF, появится и запрос.
Это мне так кажется. Возможно, ошибаюсь, потому что тот же gRPC элементарно решал насущные задачи разработчиков, поэтому стал стандартом де-факто для межсервисного взаимодействия. Возможно, новые интерфейсы для сети не решают их. Или не делают этого пока - спрос ещё не созрел.
Но, я уверен, что как и со многими другими технологиями (тот же gRPC, или k8s, Go, React, OSquery, GraphQL) они сначала зарождаются в недрах компаний, для которых это вопрос выживания, а потом становятся распространены в индустрии, то же самое произойдёт (уже происходит) с NETCONF/YANG, gNMI и whitebox'ами.
Благо лаба в публичном облаке поднимается очень легко)
В отличие от лабы сетевой.
Вы ведь читали текст? Правда же?
Виртуалка в публичном облаке появилась ближе к концу повествования. А сначала у нас была виртуалка на выделенной железной машине, которую обслуживали полностью мы сами.
Да рейд-то восстановили. Но получили доказательства, что жить так дальше ну никак нельзя.
Ну это же не единственный механизм. 1588 поддерживается не всем оборудованием. Поэтому у кого-то sync e как дешёвый эрзац.
Но даже 1588 - это попытка натянуть сову на глобус)
Всё ещё далеко не прямая связь между причинами и следствием. Тут должны потрудиться тараканы в голове.
Так можно довести и до того, что производство унитазов - критическая отрасль, от которой зависит жизнь людей. Что если в нём плохо смывается содержимое - и год за годом точит психологическое здоровье владельца?
Хабы живы!
Вообще вы, получается, обладатель музейной редкости!
Я не понял, это хорошая ирония или вы всерьёз? :)
Где реализована коммутация/маршрутизация/ACL - в железе или на CPU
Вероятность битовых ошибок и их исправление
Отказоустойчивость компонентов
Качество питания и устойчивость к скачкам в сети
Глубина и качество тестирования ПО, отвечающего за Control Plane
То же, но про взаимодействие с SDK чипа, реализующего программирование правил в железо.
Возможность обновления ПО (неактуально, правда, для старых коробок)
А кольца имело смысл собирать на L3 :)
Один из примеров в публикации - это ядро, собранное на кольцах под управлением RRPP - там одно неловкое движение и критический инцидент.
Подпишусь под каждым словом!
Да, бывало такое. И даже в масштабах ядра оператора сети, где не особо ожидаешь дублирования MAC'ов в отличие от сегмента клиентского оборудования.
И порой изменение MAC'а при вводе в эксплуатацию даже в инструкции по настройке прописывали)
Ну, согласитесь, это несколько натянутые примеры? Я говорю про смерть или вред здоровью как прямое следствие ошибок или проблем. Нельзя сравнить это с обрушением моста или врачебной ошибкой.
Пограничными на сегодняшний день являются медицина и автомобили, напичканные электроникой.
О, дааа, MTU, однозначно, достоин лавров самой неведомой чертовщины!
Под чудовищным legacy я тут подразумеваю такие штуки как Frame Relay, SDH, попытки синхронизации времени через IP-сеть или непосредственно Ethernet. NAT!
И это в некотором смысле добро, потому что всё, что поверх продолжает работать. Просто весь багаж техдолга вынесен на уровень фундамента :)
Я как раз приводил примеры проблем в сети, которые с виду простые, но локализовать их не так-то просто. Тут или нужны хорошие полные инструкции по диагностике, либо профессиональная интуиция.
И они требуют как раз знания инструментария.
Ну а без технических подробностей, потому что публикация рассчитана немного на другую аудиторию, и у меня есть места, где их как раз в достатке)
На самом деле мне близки вещи, которые вы описали. И согласен почти со всем.
Однако для того, чтобы что-то случилось, об этом нужно говорить. Говорить нужно много и при любой возможности, прожужжать всем уши и стучаться через все каналы.
И тогда, после того, как каждый будет знать, что есть NETCONF, появится и запрос.
Это мне так кажется. Возможно, ошибаюсь, потому что тот же gRPC элементарно решал насущные задачи разработчиков, поэтому стал стандартом де-факто для межсервисного взаимодействия.
Возможно, новые интерфейсы для сети не решают их. Или не делают этого пока - спрос ещё не созрел.
Но, я уверен, что как и со многими другими технологиями (тот же gRPC, или k8s, Go, React, OSquery, GraphQL) они сначала зарождаются в недрах компаний, для которых это вопрос выживания, а потом становятся распространены в индустрии, то же самое произойдёт (уже происходит) с NETCONF/YANG, gNMI и whitebox'ами.
Это всё ещё так :) И даже не 1%, а 30-50
С dip-переключателями сам успел ещё на какой-то авайке столкнуться. И да, SSH, конечно, намного удобней) Это бесспорно.
В подкасте как-то была у нас рубрика "История связи". К сожалению, мы не довели её до конца. Но было довольно любопытно.
Нет)
Ответил ниже случайно. А удалить коммент, похоже, нельзя.