| « Загружаемся с ISO-образов дисков, используя флешку | ATLAC - статус разработки и прогресс » |
Хрупкая вещь - Internet... Или авария на SPB-IX, последствия.
Меткие заметки, Есть ли жизнь в Сети, Сети и администрирование, Cisco Add commentsКакая же все-таки хрупкая вещь - Internet. Авария на одной из сетей может спокойно положить десятки, если не сотни соседних сетей с многими тысячами пользователей.
Upd: чтобы такого не случилось в Вашей сети с 76xx - смотрите в сторону команды mls qos protocol arp police, которая является единственно правильным решением против подобных аномалий трафика.
...
В этот раз авария случилась на SPB-IX. Что у них произошло - ведомо только их инженерам и высшему разуму, но для всех остальных это выглядело как закольцовка трафика. Все бы ничего - оборудование магистрального класса (Cisco старших серий) переварило бы все это легко, если бы не одна особенность. А особенность в том, что в основном включения в SPB-IX гоняют между собой L3, соответственно, ARP-запросов там вагон. А ARP - это хороший такой, замечательный, прямо таки православный броадкаст. И вот тут всплыла одна не менее замечательная особенность оборудования магистрального класса, заключающаяся в том, что под такой лавиной ARP оно... просто и банально ложится. Точнее, не целиком, а только IP-часть (L3). Соответственно - L3-трафик не ходит, BGP и прочее лежит, на управление через сеть не попасть, только физикой, да и та консоль ведет себя, мягко говоря, совсем не резво.Хронология событий:
1. В 17:40 на SPB-IX происходит ЭТО. Начинается лавинный поток ARP на порты бордеров. Бордеры само собой пытаются все это переварить, но куда там - гиг ARP'ов - это вам не penis canina. Соответственно, бордеры хрипят и задыхаются.
2. 17.42 - начался массовый падеж провайдеров. В итоге пострадали, имхо, все, кто был включен в SPB-IX. Естественно, у всех паника, никто не понимает, что произошло. SPB-IX, естественно, фиг кого по телефону оповестил о проблеме, добавив тем самым неразберихи. Замечаю, что отвалился Яндекс, начинаю исследовать сеть, но в это время теряю управление и вообще возможность выйти вовне, да и внутри не все гладко.
3. 17.44 - проблема становится массовой, все поняли, что случился большой *****ц. Резко подрываемся на выезд на ГУС, поскольку ситуация патовая. Аналогичную проблему должно быть испытывали и все остальные, поскольку по приходу домой обнаруживаю, что Interzet тоже лежал.
4. Где-то около 18:00 мы на ГУС, начинаем исследовать проблему. В условиях тормозящей консоли сделать что-то вменяемое трудно. Сразу обнаруживаем 100% нагрузку по прерываниям и большой % процесса ARP Input, понимаем что закольцевались. Экстренно гасим сеть по кусочкам (все равно все, что могло лечь, уже легло), но это не помогает. Становится ясно, что проблема за бордером. Кладем все стыки, и на SPB-IX убеждаемся, что виноват именно он. Время 18:20.
5. 18:22 - еще раз перепроверяем виновника, убеждаемся, что вывод верный, кладем линк c виновником, и начинаем тихонько поднимать сеть обратно. В 18:25 сеть поднята, но сервисному кластеру эксцесс в виде полного обрыва связи с каждым сервером очень не понравился, и сервисный кластер перешел в режим single-mode. Работает, конечно, но в аварийном режиме его оставлять весьма некошерно. Приходится потратить еще 15 минут на восстановление сервисного кластера.
6. 18:40 - авария устранена, делаются выводы, проблема резюмируется, и теперь подлежит тщательному анализу. А на SPB-IX трафика не было где-то 20:00, судя по графикам. Линк с ними так и не поднят - лучше пока не рисковать 
Вот так вот залетевший случайно не туда дятел способен разрушить цивилизацию. Меры противодействия подобному остаются под вопросом, если кто-то когда-то уже с подобным в условиях большой сети боролся - делитесь опытом. Понятно, что в штатных условиях злой клиент такой флуд создать не сможет, да и терминируется не на бордере, но вот если на бордерном стыке такое может возникнуть - значит как-то бороться с этим надо, иначе возможно повторение ахтунгов.
RSS лента комментариев этой записи
XML ленты
В общем я бы наверное воткнул маленькую железку с freebsd, обе сетевушки в медленный поллинг и поснифать эти АРПы.
Если там одни реквесты от нас же, то проблема на транспорте.
Вопрос в том, как с ARP-флудом вообще в перспективе бороться. Это может быть проблема на транспорте, а может быть и сошедший с ума соседний роутер или сознательный DDoS. Всякое может быть.
Кстати говоря, способ борьбы с подобным мы все-таки нашли. Есть замечательная команда - mls qos protocol arp police, которая рубит трафик на фабрике - до того, как он попадет на CPU. Вполне применимо, и на тестовом стенде показало свою эффективность - залитие лимитируется на определенном % нагрузки CPU (естественно, лимит подбирался руками), и нарушения сервиса не происходит.
При этом на штатный сервис при отсутствии флуда данный рейт-лимит визуально не влияет - т.е. дропов нет, объем ARP-трафика весьма небольшой. При залитии, даже когда что-то пилится, "легитимные" хосты всегда могут повторить ARP-запрос. Учитывая, что делается таковой для роутера не часто, разве что трафика долго не было, серьезных проблем можно не ждать. Т.е. подобная превентивная мера дает время разрешить ситуацию с залитием без потери сервиса.