Comments 30
Как говорил мой дедушка Ирико: "ни разу не обосрался тот, кто с рождения не ел"
TL;DR: админы залили в железку протухший на полгода конфиг и ушли спать:)
А статья интересная, спасибо!
Респект и уважуха, что тут сказать.. Косякнули, починили, компенсировали согласно прейскуранту, отчитались с тех. подробностями. Браво! Почаще бы так относились к ошибкам!
Ностальгично. ТСПУ -1 в карму. Жаль только ответственные за тспу его kpi не в карме считают.
ТСПУ увидело, что трафик автономки не совпадает с их базами, и нам начали резать трафик, потому что явно же какие-то мошенники
А автоматически уведомить владельца сетки об инциденте - у него лапки?
Да ладно бы просто уведомить, кто вообще придумал в случае кривых анонсов резать трафик, а не эти кривые анонсы?
Чтобы знать, чтобы трафик не резать, а посылать его получателю, надо знать куда посылать - то есть, иметь маршрут к его сети ("префиксу"), по крайней мере - адрес следующего перехода. А маршруты как раз этими самыми аносами и рассылаются. Нет анонса - нет маршрута - нет трафика, как-то так.
PS А вообще IMHO статья бы много выиграла, если в ней было бы слово из трех букв - BGP, а не то что многие подумали при виде слова из четырех букв "ТСПУ". Тогда те, кто с маршрутизацией IP за пределами default gateway по жизни не сталкивался, хотя бы ключевое слово для загуглить имел.
Но отключить трафик от ТСПУ нельзя, у нас и доступа к нему нет, да и оператор связи не имеет на это права.
Вот кстати на фоне замедления ютуба я пару раз видел комментарии от людей "мы в своём городе так задолбали техподдержку провайдера жалобами на медленный ютуб, что он сдался и отключил замедление".
Интересно, возможно ли это?
Провайдеру потом от РКН прилететь может
Т.е. технически он всё-таки может отключить ТСПУ или пустить свой трафик в обход его?
Ну оно ж стоит на площадке провайдера. Так что технически - может.
Просто "у нас и доступа к нему нет" из поста прозвучало так, будто физического доступа нет. Живо представилось, что ТСПУ стоит в отдельной комнате, на двери висит амбарный замок и рядом строгий дедушка-охранник.
Я так понимаю, что для операторов санкции за обход ТСПУ такие, что уж лучше бы дедушка-охранник с берданкой стоял.
У провайдера нет возможности поменять конфиги или вообще хоть какие то настройки ТСПУ, но пустить траффик в обход он может. Когда работал в ТП крупного провайдера у нас офисная сетка ходила мимо ТСПУ, всякие инстаграмы фейсбуки открывались без ВПН
так в данном случае тспу стоит в цоде у «магистрала» для хостинга. у них доступа скорее всего и правда нет.
VVV
KA
GD GLD
Пост-фактум, действительно выглядит, ну очень - очень весело,
а в реальности: отсутствие штатного уровневнего взаимодействия при подобных: "стечение обстоятельств", явно чья-то недоработка плана восстановления из актуальной резервной копии, которая в трёх экземплярах, минимум, должна была храниться у всех участников "возможного инцидента", до всех описанных событий, после изменений.
Почему у оперативного персонала "под рукой" оказалась такая не актуальная резервная копия (?),
после внесения изменений, фактически в "продакшн" (?);
Проверка процедуры восстановления из крайней-актуальной резервной копии
входит в обязательные штатные мероприятия, при планировании процедур восстановления.
Админы?
Разумеется, люди.
Первое Админское правило: сделай резервную копию перед внесением любых изменений.(!);
Очевидно, поскольку источник проблемы не был локализован,
Админы и откатились на "пылящуюся в архиве" древнюю,
снятую до внесения актуальных крайних изменений;
Вполне штатный отклик: трезво,
по-админски (!);
Ну, и классика "жанра": 2N+1, -
на всё что 999;
А "запасной" рояль в кустах,
с хранения, так и не понадобился...
Очень - очень впечатляющий кейс;
73
EE
Старая Пара: Номер AS + старый блок IP адресов, - в старой резервной копии, снятой до описанных событий;
Новая Пара: Номер AS + новый блок IP адресов, - в действующей конфигурации.
Не распределённый блок IP-адресов, выделенный для AS, сконцентрированный у одного провайдера, -
Единая точка отказа (!).
Нет анонсов с интерфейса маршрутизатора (оборудование провайдера) в сторону магистралей, через какое-то время никто не знает куда "перенаправлять траффик" предназначенный для актуального блока IP-адресов.
Динамика.
В котором месте отвалилось можно узнать обычной трассировкой по известным IP-адресам нового блока. Да и доступность старого блока тоже можно проверить, чтобы оценить масштаб происходящего.
А дальше ?
Проверять работу того устройства которое выдаёт с интерфейса анонсы. Что с ним происходит.
Автор рассказал, что провайдер заменил коммутатор уровня ядра
( неуправляемый switch у провайдера ?)
Или управляемый коммутатор: агрегация-распределение, а это минимум L2+ или полноценный L3, со своей таблицей маршрутизации
и наверняка "горячим" резервированием-дублированием.
В общем, тоже "кусок работы".
В чьей компетенции функции:
ядро и распределение,
из описания не слишком ясно изложено, могут быть не только разные индивиды, но и целые команды, а у них единоначалие: технический директор, главный инженер и т.д.
Если выход из подобной ситуации "сработал" исключительно на организационном уровне "Топ-Топ", значит нет соответствующих полномочий-процедур у технических специалистов дежурной смены в Центре Управления Сетью (?);
Человеку всегда нужен Человек.
Опять же "откат" на не актуальную резервную копию со старой связкой выдачи анонса "номер AS + блок IP адресов" никого не спас, пока не возникла требуемая компетенция в виде ведущего специалиста (?);
В общем вывод:
Изменения в действующую конфигурацию внесены, а плановые штатные процедуры на случай возможного-вероятного отказа обновления не получили.
По чьей инициативе процедура, со всеми последующими?
Остаточный риск присутствует всегда.
Одна хорошая вспышка на Солнце
и всё что не в свинцовой оболочке "хандрит".
Два провайдера, блок адресов для AS с сегментацией, плюс резерв, - это НОРМА: необходимое и достаточное, минимум;
Админы действовали штатно, в пределах своей компетенции: взяли резервную копию и вернули в продакшн "нулевой отсчёт".
Третья сторона, в виде специальной железяки, как правило работает в прозрачном режиме, но если, что записанный траффик можно приложить при разборе инцидента.
По Действующей НОРМЕ так.
А каков ПРЕЦЕДЕНТ?
73
EE
У вас один аплинк?
ОДИН АПЛИНК????
Два независимых ввода? Ахахах, тракторист смеётся вам в лицо!
Работы на сети аплинка и у вас недоступны ВСЕ виртуалки клиентов, т.к. работы на сети аплинка??
Как вы вообще сущуствуете на рынке?
Подождите, М9 - это ведь Новая Рига, а то что Вы имеете в виду - это М IX?
А как же "интернет - это децентрализованная, самоорганизующаяся сеть, способная пережить любые размыкания графа, в том числе ядерную войну"?...
Наше время: залили вронг бекап, правильный админ спал...
Автоматизируйте тесты - запрашивайте таблицу свотх анонсов у аплинка и сверяйте с оргиналом, если есть расхождения бейте в колокол.
человеческий фактор, ошибка админа
Это не ошибка. Это наступившая эпоха всеобщей безответственности.
Какие-то сказки для детей, а не техническое описание...
1. ТСПУ спокойно переводится в режим байпас по запросу оператора и аргументации для проверки.
2. Про старые и новые записи в RIPE вообще умиляет, надо в RIPE рассказать, а то они спрашивают при переводе удалить или сами удалите?
3. Всё это результат деградации или отсутствии знаний у инженерного состава...
Вся документация как правильно сделать доступна.
Авария на М9 в начале июля — я обещал разбор