Не знаю все ли читают relcom.tcpip и всем ли это интересно.
Однако явно в тему. :)
------
Ilya Shulman ish@east.ru +7-095-956-4951
East Connection ISP, Moscow, Russia.
----------
> From: Rudnev Aleksei <alex@newcom.kiae.su>
> Newsgroups: relcom.tcpip
> Subject: Re: *** Последние событи я в RELCOM - новый канал, и прочее
> Date: 14 мая 1997 г. 12:05
>
> In <3369F05F.53DF090F@sai.msu.su> "Anton V. Smirnov" <binary@sai.msu.su>
writes:
> > Вводная такая: есть сеть некоего конечного пользователя Х, того
> >самого, что
> >к BLN подключена по T3. Что это за организация я не знаю, но сеть жутко
> >здоровая и имеет два выхода в Интернет через разных провайдеров в разных
> >частях страны, а по сему пользующая BGP. Сквозь себя они трафик,
> >разумеется,
> >не пропускают. Поэтому провайдеры отдают им всю свою таблицу
> >маршрутизации,
> >а принимают, как предполагается, только анонс их внутренних сетей.
> > Вот в этом 'как предполагается' и заключалась первая ошибка - MAI
> >принимал
> >все что ни вздумалось бы послать и после отдавал все это во внешний мир.
> >Эта
> >схема работала нормально некоторое время, пока аггрегацию делал
> >маршрутизатор
> >клиента. Но когда в пятницу персонал Х - естественно не уведомляя своего
> >провайдера о каких-то там работах по реконфигурации своих
> >марщрутизаторов, что
> >совершенно нормально - решил что не барское это дело, усложнять
> >конфигурацию
> >своей части и повел себя как грязная эндюзерская свинья, вывалив на
> >провайдера
> >все кишки своей сетки, включая анонсы WAN-сеток на 4 адреса из диапазона
> >RFC 1597, в основном 192.168.х.х. И винить его я за это тоже не могу,
> >поскольку во-первых, у Х были все основания полагать, что провайдер не
> >слушает всю лабуду подряд (см. ниже), а во-вторых, вообще не дело
> >конечного
> >пользователя думать о мировых проблемах, для этого есть провайдер, а
> >персоналу Х и своей сети (тоже не хилой) вполне хватит. Поскольку этих
> >'кишков' вместе с деаггрегированными внешними сетками вывалилось
> >несколько
> >десятков тысяч строк, то как минимум одна проблема Интернету была
> >обеспечена -
> Нет, минуточку... Проблема была в том, что внутренняя сетка умудрилась
> переанонсить внешние сети во внутреннюю AS, при этом проведя их
> деагрегирование, а после вывалить все это обратно (по сути они провели
> измерение числа агрегатированных сетей в мире - если от 72 тысяч вычесть
> 40, то оно и получится). Так первую то часть явления что, как не BAY,
> обеспечило? Вы попробуйте такое на gated-е или на cisco нарисовать, а я
> посмотрю... Я только один способ знаю это сделать - вывалить все BGP в
> RIP на одном роутере, и принять на втором назад, но это же RIP раньше
> сдохнет, чем 72 тысячи сетей проанонсит...
> >гигантский размер таблиц маршрутизации. Ближайший к MAI маршрутизатор
> >достаточно быстро исчерпал всю свою память и регулярно (раз в 5 мин)
> >перезагружался, послужив тем самым естественным верхним барьером для
> >таблиц маршрутизации всего остального Интернета.
> > Будь это единственной ошибкой, мы бы имели двух- или трех- кратное
> >падение
> >производительности маршрутизаторов, занятых постоянным
> >анонсом/вычищением
> Да нет, было все хуже.
>
> Во первых, ближайший роутер имел 64 мега мозгов, и когда он скис,
> число сетей в Интернете оказалось достаточным, чтобы погрохать все
> роутеры о 32 мегах, до которых эти брызги долетели.
>
> Во вторых, в результате некоторой борьбы Cisco и Sprint-а с
> повышенной загрузкой роутеров роутеры Sprint, как оказалось, очень
> неохотно освобождались от этих излишних сетей - сам первоисточник
> неприятностей был удавлен минут через 10 - 20, а 72 тысячи сетей
> порождались Спринтом и другими еще часа полтора (что, кажется, даже
> породило баг-репорт у циськи).
> >мелких сеток + поиск нужных маршрутов в выросших в 1.5 раза базах. Но
> >сеть
> >в целом бы работала! На самом деле, из-за ошибок мелких провайдеров
> >примерно похожие (но все-таки значительно меньшие по масштабам)
> >неприятности
> >происходят регулярно раз в три или четыре месяца. За прошлый год я
> >слышал
> >о как минимум трех случаях, разбиравшихся в NANOG - в начале и в конце
> >весны и в середине осени. По поводу одного из весенних случаев был
> >вполне
> Ну не знаю, не слышал. Хотя NANOG читаю регулярно.
>
> Дальше я сейчас прочитал - по моему, бред все это...
> Проблема была в переанонсе из EGP в IGP с деагрегированием, вызванным
> ошибкой в BAY наложившейся на неудачную конфигурацию у клиента.
> Чего тут за гадания про _какую то причину_, _скорее всего_ и прочее,
> я слабо понимаю.
>
> Кстати, была признана подобная ошибка, выявленная некоторое время
> назад, но в меньшем масштабе, и тоже приведшая к переанонсу с
> деагрегатированием...
>
> И кстати, на все это наложилась еще любовь мелких ISP (а весь NANOG -
> это сборище мелких ISP, неудовлетворенных своим вторичным статусом),
> к использованию первой сети своего блока в личных целях - а как раз
> эти сети и потеряли роутинг...
>
> -----------------------
> >приличный шорох в около- и компьютерной прессе и в одной из статей с
> >умным видом предрекался полный крах Интернет в течение нескольких недель
> >из-за "ошибки в программном обеспечении маршрутизаторов фирмы <имя>,
> >имеющих большое распространение в сети Интнрнет". Какую-нибудь подобную
> >ахинею наверняка можно будет найти и в этот раз, тем более что по
> >последствиям
> >нынешний раз покрасивей будет.
> > Но была еще и вторая ошибка, располагавшаяся в том же BGP accept
> >policy.
> >По какой-то причине номер AS пользователя Х переписывался на собственный
> >ASN провайдера (7007), скорее всего просто конечный пользователь
> >не имел своего зарегистрированного ASN и пользовал произвольный из
> >верхних.
> >Так вот, поскольку ожидалось получение только собственных сетей Х, то
> >AS_PATH не исправлялся, а просто переписывался на ^7007$. Но тут помимо
> >собственных сетей Х в полный рост поперла таблица маршрутизации _всего_
> >Интернет (наверное, Х решил попробовать, каково быть транзитной AS :-),
> >узнанная через второго провайдера, и она _ВСЯ_ получила AS_PATH
> >из одного входа 7007, то есть маршрутизатор 'решил' что любая машина в
> >мире
> >доступна из его AS непосредственно. А поскольку всего через одну AS от
> >него
> >стоял Спринт, который явно относится к тому, что журналисты любят
> >называть
> >'американским бэкбоном', то мания 'пупа Земли' одного из маршрутизаторов
> >была обречена на успех. Любой маршрутизатор в мире пакет для сети более
> >от
> >него далекой чем Спринт посылал его MAI.
> > Интересно с чего вообще зашли разговоры об ошибке в программе
> >маршрутизатора.
> >В момент краха MAI не проводила никаких работ с маршрутизаторами,
> >поэтому
> >они и заподозрить не могли свою ошибку. То что они в момент своего
> >самоотключения (а это было всего 20 минут спустя после звонка из
> >Спринта:
> >"Сволочи, что же вы делаете, вы же Интернет гробите"; как вы думаете,
> >может ли
> >персонал мелкого провайдера за 20 мин разобраться в тонкостях проблемы,
> >когда
> >известно, что в это время по их вине стоит весь мир?) нимало не
> >представляли
> >сути проблемы говорит то, что они физически оборвали все провода со
> >своих
> >маршрутизаторов, причем во всех точках присутствия, даже никакого
> >отношения
> >к проблеме близко не имевших. Зато им сразу вспомнилось проведенное
> >несколько
> >недель назад обновление софта (без изменения версии, только с
> >оптимизацией
> >forwarding-таблиц для ISP).
> > BGP и при правильной-то конфигурации оказался протоколом для большого
> >Интернета довольно дерьмоватым, и даже не столько из-за своей 'плоской'
> >структуры, когда любая, самая мелкая вошка может великолепно обкакать
> >малину
> >всему остальному миру. Уже довольно давно (года полтора) известно, что
> >BGP-4
> >страдает от зацикливания сообщений об изъятии маршрутов, которые
> >составляют
> >97-99 % всех сообщений. Однако поскольку сообщение об изъятии уже
> >изъятого
> >маршрута никакой особенной работы на процессор не возлагает, то этот баг
> >протокола назвали его характерной особенностью и пока закрывают на него
> >глаза,
> >сосредоточив работу по улучшению глобальных протоколов маршрутизации на
> >разработке иерархической схемы обсчета глобальных таблиц, нечто сродни
> >иерархии DNS. Будет немного выделенных главных 'серверов маршрутов',
> >занятых
> >только обсчетом таблиц, вторичных серверов (минимум один на AS) и просто
> >маршрутизаторов, которые получают от них уже готовые таблицы. Эта схема
> >будет иметь как минимум 2 больших плюса: более легкую управляемость и
> >устойчивость к сбоям и разгрузку процессоров маршрутизаторов. Если кто
> >не знаком с претензиями к BGP можно почитать
>
> >
>
> >Это пишет один из специалистов MERIT (Крэйг Лабовиц), задействованный в
> >проекте RSng/routing arbiter - создание серверов маршрутов. Я слышал,
> >что
> >они уже даже продают какой-то сервер маршрутов и он в
> >опытно-эксплуатационном
> >режиме живет в нескольких экземплярах у нескольких крупных провайдеров,
> >в том числе у Спринта и MCI.
>
> >> >Кстати, ошибка с роутингом была вызвана использованием роутеров фирмы
> >> >BAY - ошибкой в коде... Так что любой, у кого есть BAY и BGP-4, ходит
> >> >под богом.
> > Так что 'под Богом' получается ходят просто все, кто пользует BGP-4,
> >безотносительно к фирме-производителю.
> > В одном из RFC, не помню в каком, по-моему в "Requirements for IP
> >Version 4 Hosts" дан следующий совет разработчикам IP-стеков: делайте
> >над пакетом все мыслимые и немыслимые проверки и самые невероятные
> >предположения; Сеть столь огромна и чудаковата в своих проявлениях, что
> >рано
> >или поздно, умышленно или случайно реализуются самые невероятные
> >события.
> >И то сколько различных реализаций оказались подвержены злому влиянию
> >Ping'o'death показывает сколь же мало (или сколь же трудно) людей этому
> >несомненно благому совету следуют. Так вот, это я к тому, что при
> >конфигурировании BGP надо исходить из предположения, что твой сосед в
> >сто раз тебя умнее, знает все твои ошибки конфигурации и имеет по
> >меньшей
> >мере бандитский замысел намеренно убить Интернет :-)
> > Засим свою песню сворачиваю, и не ожидая редких хлопков и тухлых
> >помидоров
> >слезаю со сцены.
> > А.
>
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@east.ru if you want to quit.
