Comments 74
Назовите вендора сих великолепных девайсов!
А какая разница? Уж 10 тысяч раз говорили, что моновендор - крест на сети, не говоря о моножелезке на определенном уровне.
Со стороны закупа и сто вагон одинаковых железок одного вендора звучит великолепно, а получается в итоге вот такое.
Остается вспомнить эпичные аварии мегафона, когда у них несколько регионов лежали по вине хпе.
Мы считаем что ошибки могут быть в любом ПО. Наша сеть одна из самых сложных в мире, о чем мы регулярно рассказываем на nexthop, мы сотрудничаем со многими производителями сетевого оборудования, и за, более чем 20 лет, встречали много разных ошибок, которые производители в последствии исправляли. Поэтому, из этических соображений, не хотим раскрывать имя производителя
>>Поэтому, из этических соображений, не хотим раскрывать имя производителя
Готов сделать это за вас !)
Ещё бы сервера Толоки сделали. Исполнители жалуются почти ежедневно.
Здравствуйте! Подскажите, пожалуйста, на что конкретно жалуются исполнители? Мы посмотрим.
Самозанятые жалуются что их банят как ботов, хотя они прошли через госуслуги. Остальные жалуются что приёмка заданий бывает дольше выполнения задания (это про задания с немедленной оплатой). А вообще советую почитать комментарии в вашей же группе в ВК, заодно может от троллей почистите.
Ну и на курс доллара жалуются, но к технической части это не относится.
Кто в теме по описанию поймет производителя.
Ц?
Написано, как расследование авиакатастрофы. Очень круто
Спасибо. Полезно это читать.
Эту проблему могла бы предотвратить резервная управляющая плата, но она отказала ещё 22 января
А через пару недель основная. "Штирлиц насторожился" (с). У вас еще есть такие маршрутизаторы? :)
Я думаю, здесь как с дисками в RAID1: пока они оба работают - вероятность отказа ниже 50%, но как падает 1 - вероятность того, что посыпится второй повышается.
Тут скорее всего ставка была сделана на то что у них достаточно связанностей с миром чтобы пережить выход из строя целиком одного из узлов. Да вполне себе провести аналогию с RAID1, но тогда там не 2 диска, а десяток и проценты там совсем другие.
Аналогия с рейдом неверная, но причины близких по времени отказов в ряде сценариев иногда могут быть схожи (типа бага в прошивке, который превращает девайс в тыкву через определенное время аптайма или по накоплению какого-то другого счетчика). С учетом отказа двух одинаковых компонент одной железки в довольно короткий период времени и неизвестности точных обстоятельств произошедшего тут в любом случае есть над чем подумать, причина может в дальнейшем аукнуться на другом аналогичном оборудовании.
Было похожее в датацентре одной далёкой нефтегазодобывающей. Как-то в дисковом массиве прилёг один диск. Spare - штатно отработал. Сделали заказ интегратору. Тот отправил диск на замену. Пока этот диск ехал в далёкую сибирь, в корзине прилёг второй диск. Фсё. Как потом клялись вендор с интегратором - вероятность такого - ничтожно мала. Оргвыводы - хранить в датацентре пару дисков на замену, чтобы как в евроконтрактах - 2 часа на устранение.
Но, к сожалению, используемая нами функциональность медленно разрабатывается другими производителями.
Выглядит что root cause на самом-то деле вот тут. Было бы очень интересно ознакомиться с оценкой рисков "уникальный функционал vs затраты на альтернативное массовое решение")
Но, к сожалению, используемая нами функциональность медленно разрабатывается другими производителями
И что это за особенная функциональность у секретного вендора (под кодовой буквой J, я полагаю), которой нет у других?
Мне кажется что по разбору этой аварии хорошо видно к каким последствиям приводит "срезание углов" при эксплуатации сложных систем. Проблема №1 - вышедшая из строя управляющая карта не была заменена в течении 2х недель! Понятно, что карты зарезервированы, стыки с внешней сетью тоже, но две недели менять вышедший из строя модуль - перебор. Проблема №2 - BGP, рефлектора, и т.д. сложно конечно говорить не зная деталей, но как по мне, на оборудовании не корректно настроены тайминги. При падении IGP нужно просто опустить BGP сессию. При помощи упомянутого в тексте BFD или костюмного скрипта. Проблема №3 - в работу выкачен софт полностью не оттестированный в лаборатории. Да, довольно сложно все проверить в лаборатории но факт остается фактом.
Проблема №4 - а устройствах не отключен не задействованный функционал.
ИТОГ: множество маленьких недочетов, совокупность которых привела к простою в 1 час.
Точно также происходят все техногенные аварии, авиакатастрофы и т.п.: каждое мелкое обстоятельство по отдельности несерьезное, но в один момент все они входят в резонанс с катастрофическими последствиями.
Да, достаточно, я не знаю, тот же Чернобыль или Фукусиму вспомнить. Ну или банальное рассыпание RAID-массива — как в статье — единственный резервный диск заместил полетевший и… дождались.
Оставлю: https://how.complexsystems.fail/
Вот это вообще бессмертно и жиза:
Because overt failure requires multiple faults, there is no isolated
‘cause’ of an accident. There are multiple contributors to accidents.
Each of these is necessarily insufficient in itself to create an
accident. Only jointly are these causes sufficient to create an
accident. Indeed, it is the linking of these causes together that
creates the circumstances required for the accident. Thus, no
isolation of the ‘root cause’ of an accident is possible. The
evaluations based on such reasoning as ‘root cause’ do not reflect a
technical understanding of the nature of failure but rather the
social, cultural need to blame specific, localized forces or events
for outcomes.
Таки, судя по тексту, проблема была ровно одна - подлый непродуманный статический маршрут на подхвате. Всё остальное - мелкие, относительно штатные ситуации. Отказ одного бордера их многих, как в статье правильно замечено, не должен приводить к такому. И не привёл бы, не будь этого статика.
Потому, уважаемые, и существует достаточно разумная практика делать "аварийные" статические маршруты в blackhole. Пусть лучше железо выкидывает пакеты при пропадании динамического маршрута, чем вот такое творится.
Именно так. Static default route - это 100% red flag. Static default в Null0 это тоже самое что его отсутствие, так что это просто засорение конфига.
Скорее всего этот статик им нужен для чего-то вроде возвращения траффика в сеть после scrubbing. Тут действительно потенциально возможны непредусмотренные ситуации при длительном перестроении BGP и чехарде с next hops. Обычно такие вещи topology- и situation-dependant. Без детального знания топологии и конкретных обстоятельств вряд ли стоит делать выводы.
вышедшая из строя управляющая карта не была заменена в течении 2х недель
в силу известных причин логистика этой платы могла оказаться отнюдь не NBD
Проблема №3 - в работу выкачен софт полностью не оттестированный в лаборатории.
А какой вендор вам даст 100% гарантию что софт не кривой ?
Я бы еще сюда посмотрел "Из-за отсутствия IS-IS маршрута разрешение происходило через маршрут по умолчанию, который, в свою очередь, был статическим.", очень сомнительная конструкция
Мне интересно, Яндекс использует или пробовал смотреть железки типа white label? Или это только реально для datacentre свичей?
>Чтобы избежать повторения данной проблемы, мы выключили функциональность DHCP на коммутаторах пиринговой фабрики.
У меня нет опыта взаимодействия с коммутаторами Enterprise-уровня, но зачем на них DHCP, и почему он не отключен, когда не используется?
Если проблема только после обновления, не может ли она быть намеренно привнесена?
"Наша сеть одна из самых сложных в мире, "
Гдето рядом ржет cloudflare , и магистрально континентальный дата центр в Амстердаме
Проблему потери связности по BGP между коробками вследствие падения нижестоящего протокола , думается, вполне решило бы наличие аварийного статич. маршрута для общего префикса подсети опорных loopback интерфейсов со сбросом в Null (чуть выше в комментах упомянули о blackhole). В нормальном рабочем состоянии системы данный маршрут less specific, и ни на что не влияет. Кажется, этого было бы достаточно, чтобы п.п.2-3 не триггернули. По этой проблеме видится ошибка проектирования.
Интересно, для чего на коробках clos фабрики на М9 потребовался dhcp функционал
Заметил что когда у Яндекса что-то ломается/утекает/падает, то появляется представитель компании и говорит:
Ой, а мы но виноваты, это не мы, это другая организация отвечает нас там нет.
Верим.
На сколько я помню, когда-то у Яндекса уже была схожая авария на уровне сети, только тогда проблема пошла с глюкнувшего маршрутизатора по BGP..
Как я понимаю, тогда с выводами особо не заморачивались?)
Думаю, корень проблемы был тут:маршрут по умолчанию, который, в свою очередь, был статическим.
Ну и замена отказавшей 22 января платы, которая не была завершена 6 февраля...
Это - очень странно...
А вот теперь, хотелось бы услышать ответ на следующий вопрос:
когда у вас всё завалилось, мои пользователи, при входе в почту, стали получать вот такое сообщение:
У нас нет ни каких подписок. Что это было за вымогательство такое? На волне отказов сервисов заработать пытались?
У других пользователей (другой домен) вот такое:
Хочу каких-то объяснений. Хотя предполагаю, что это тоже не вы, а какой-то сторонний вендор или подрядчик....
Подписки как раз есть, и с апреля станут обязательными
Я с Яндекса почту на домене убрал. Жадные уж очень стали.
Дайте угадаю, мммм, скорее все железо которое не отработало dhcp пакетик, начинается на букву ж, ptx10000? 10016? Мне это напомнило фразу из фильма "если бы вы знали что искать, то увидели алгоритм на окне в мою спальню")))
Лучше расскажите как недавно Яндекс сделал крупный вклад в опенсорс, кек
Осталась нераскрытой тема, что было аварией затронуто. Какие именно сервисы сколько времени не работали. Я, например, вообще не заметил никаких проблем. У меня есть сервера, с которых каждые 5 минут делается запрос на ya.ru, просто чтобы убедиться, что прокси работает, и этот мониторинг ни разу не мигнул.
А в Яндексе разве не Яндекс.Маршрутизация используется ?
Он указывал в таблицу маршрутизации, с которой и начался процесс нашего рекурсивного лукапа.
Насколько я знаю, Juniper расскажет при коммите, что статик написан на ту же таблицу.
admin@mx5# show | compare
[edit routing-instances VRF1]
+ routing-options {
+ static {
+ route 10.0.0.0/8 next-table VRF1.inet.0;
+ }
+ }
[edit]
admin@mx5# commit check
error: [rib VRF1.inet.0 routing-options static]
next-table may loop
error: configuration check-out failed
[edit]
admin@mx5# То есть в лоб такое не удастся. Предположу, что статиков много было на пути из таблицы в таблицу и круг замкнулся. Такие конструкции применяются для сложносочиненного ликинга, который наблюдать на бордерах несколько непривычно.
Написано хорошо. А по факту - именно это и происходит, когда у руля финансисты, а не технари. Касается и крохоборства с подписками, кумулятивный эффект от которого тоже приносит ущерб, но более растянутый во времени.
@aglazkov отличная статья, спасибо что делитесь с подписчиками. Вы написали что "В современных аппаратных маршрутизаторах это (lookup) происходит индивидуально для каждого пакета" и это показывает недостаток аппаратных решений. Пробовали ли вы что-нибудь software-based что-то вроде TNSR от Netgate? Сейчас есть множество решений которые построены на open-source проектах как fd.io, DPDK, VPP что может во много раз ускорить скорость принятия решений. Одно едро может обрабатывать трафик 15 миллионов пакетов в секунду и даже больше. Если что-то подобное уже тестировали пожалуйста поделитесь. Спасибо.
Потом мы посмотрели, что происходит на транзитных устройствах, и выяснили, что на подключении между магистралью и бордером циклически переустанавливается контрольный протокол BFD и это приводит к постоянному перестроению сети.
в вот можно детальней описать вот этот момент c mac-flapping и тп ?
О проблеме №5 забыли. Точнее это даже проблема №0 - которая превыше всех. Проблема, присущая всем крупным компаниям-толстосумам, проблема экономии на спичках. Срезали на квалифицированном персонале - поэтому и карта "менялась" две недели, и софт долго апдейтился, и флаппинг из-за проблемы №0 случился, и всё остальное. И никакая это не проблема в железе. Было бы больше людей - протестили бы девайсы где-то в песочнице на предмет всех фитч получше. Все стресс тесты прогнали бы. Представляю, как немногочисленные сетевики получили по бошке за. Когда уже до начальников дойдёт что сокращенный штат и перегруженность сотрудников рано или поздно приводит к тому что случилось.
Эту проблему могла бы предотвратить резервная управляющая плата, но она отказала ещё 22 января, а работы по её замене были запланированы, но не завершены.
Дальше, как говорится, можно не читать. Знаю, видел, что вот подобные "потом заменим" в замене резервного оборудования которое вышло из строя, потом и приводят к авариям. Мой опыт подсказывает о том, что подобный факт длительной замены оборудования, многое говорит о компании. Не стоило вам писать эту фразу.
а вендор J продолжает поддержку своих устройств в России и вендор C ?
и поставки новых устройств?
Не совсем ясно из текста, у них что-ли внешние BGP peerings подключены через CLOS switch fabric? Тем более IX?
Это печально, но яндекс давно заслуживал.
О сетевой аварии в Яндексе