Эта публикация была автоматически переведена с английского языка.

Вчера у нас произошел длительный сбой в работе сети во время планового технического обслуживания: обновления прошивки основного маршрутизатора. Мы хотим быть открытыми в отношении того, что произошло, и почему потребовалось столько времени для решения проблемы.

Что произошло

Само по себе обновление прошивки, по-видимому, завершилось без проблем. Маршрутизатор успешно запустился, интерфейсы были доступны, и локальный трафик между серверами на маршрутизаторе работал нормально. Однако наши подключения BGP и туннели VXLAN не могли восстановиться.

За этим последовало примерно восемь часов диагностики одних из самых странных сетевых проблем, с которыми мы сталкивались. Разрешение ARP на транзитных портах было непоследовательным. Сессии BGP устанавливались, трафик начинал маршрутизироваться, а затем соединение «фактически» отключалось — не на уровне интерфейса, а просто переставало передавать пакеты, при этом не регистрировалось ни одного потерянного пакета. Все диагностические тесты, которые мы проводили на маршрутизаторе, не показывали никаких проблем: ни ошибок, ни записей в журналах, ничего.

Мы связались с нашим провайдером, который также подтвердил, что не видит никаких проблем со своей стороны. Мы попробовали различные конфигурации. Мы даже переместили конфигурации BGP и туннелей с маршрутизатора на отдельный Linux-сервер, чтобы изолировать проблему, и столкнулись с точно такой же проблемой. В этот момент сам маршрутизатор, казалось, был исключен, поскольку проблема возникала на транзитных портах независимо от того, что их обслуживало.

После того как мы исчерпали все другие возможности, мы в качестве крайней меры выполнили сброс маршрутизатора к заводским настройкам и применили минимальную конфигурацию с нуля — только настройку моста и VLAN. К нашему удивлению, это сразу же заработало. Идеально.

Причина

Насколько мы можем определить, обновление прошивки привело к некоторому виду скрытой коррупции данных в состоянии маршрутизатора, которая повлияла на то, как транзитные интерфейсы обрабатывали трафик. Несмотря на то, что обновление, казалось, прошло полностью успешно, маршрутизатор не сообщал об ошибках, и проблема воспроизводилась даже тогда, когда BGP обслуживался совершенно другой машиной, сброс к заводским настройкам и чистая конфигурация решили проблему. Это остается одной из самых загадочных проблем, с которыми нам приходилось справляться.

Что вам, возможно, потребуется сделать

• Если ваша виртуальная машина недоступна, пожалуйста, остановите и перезапустите ее из панели управления. В большинстве случаев это восстановит подключение.
• Если после остановки/перезапуска она по-прежнему недоступна, пожалуйста, свяжитесь со службой поддержки, и мы проведем расследование.
• Если при подключении к вашей виртуальной машине вы видите предупреждение об изменении ключа SSH, это ожидаемо. Виртуальные машины были массово переконфигурированы для работы с новой настройкой, и cloud-init перегенерировал ключи в рамках этого процесса. Это стандартное поведение cloud-init, когда виртуальная машина переинициализируется — вы можете безопасно принять новый ключ.

Мы приносим извинения за длительный простой и вызванное им разочарование. Мы пересматриваем наши процедуры обновления, чтобы обеспечить возможность более быстрого выявления и устранения подобных проблем в будущем.