Subnets.ru blog

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

10 декабря прошел очередной (уже 11-ый) пиринговый форум MSK-IX и я снова был одним из участников данного форума.

К сожалению в этот раз программа форума никак не затрагивала глобальную проблему DDoS`а как это было на прошлом форуме и как мне кажется это очень зря, т.к. необходимо обращать внимание участников на данную проблему и совместно бороться с этим. Эта проблема ведь никуда не делась, она осталась.

Чтобы я хотел отметить так это «BGP: к лучшему протоколу и практикам. Неформальная рабочая группа.» в которой я поучаствовал.

В рамках беседы обсуждалась проблема с которой многие уже сталкивались, а именно bgp route leaks. Проблема которая периодически возникает по вине новичков. Тех кто настраивает BGP впервые и зачастую не читая какой либо документации, а лишь какую либо статью на просторах тырнета. Так же снова обсуждался проект MANRS (Mutually Agreed Norms for Routing Security) и звучали призывы присоединиться к данному проекту.

---

 

Mutually Agreed Norms for Routing Security (MANRS)

Данный проект преследует цели объединения IT сферы в соблюдении простых правил:

• Filtering: Предотвращение распространения неправильной маршрутной информации
• Anti-spoofing: Предотвращение трафика с подложными IP-адресами
• Coordination: Содержание контактной и иной информации в up-to-date
• Global Validation: Улучшение информационного обмена и координации между сетевыми операторами в глобальном масштабе

Соблюдение провайдерами и их пользователями данных правил позволит сократить многие проблемы, как то DDoS или BGP route leaks.

Автор проекта Андрей Робачевский уверен в том, что чем больше организаций поучаствуют в данном проекте, подпишутся под MANRS Document и будут соблюдать его тем больше новичков обратят на него внимание. Я не совсем согласен с ним в той части, что это обратит внимание новичков на эти пункты, т.к. скорее всего они даже не увидят данного документа и уж тем более не выполнят озвученные в нем пункты, а если даже увидят, то вряд ли прочтут (документацию то они не читают, к ОГРОМНОМУ сожалению конечно), но я абсолютно согласен с ним в той части, что необходимо хотя бы пытаться что-то с этим делать. Делать надо уже давно и делать уже сейчас, т.к. потом может стать уже слишком поздно и наши маршрутизаторы и каналы будут забиты только DDoS трафиком.

Потому я решил снова написать об этом проекте и просить вас, читателей данной статьи, обратить внимание на соответствие ваших сетей простым правилам данного проекта и если у вас есть «пробелы», то устранить их на вашей сети. Глядишь кол-во ботов и DDoS атак сократиться.

---

 

Александр Азимов из Qrator Labs (создатели QRATOR RADAR MONITOR о котором я так же писал в прошлый раз) предложил внести правки в прокол BGP — проект «A Simple BGP«.

Вкратце озвучу суть предлагаемых изменений. Они состоят в том, чтобы попытаться вовсе искоренить проблему BGP route leak. Проблему которая возникает из-за новичков, которые при настройке BGP сессии указывают лишь IP-адрес BGP соседа и его ASку и имеют несколько BGP сессий.  Да, да, да — такие есть и их много:

Предлагается добавить понятие «роль» в настройки BGP сессии и передавать её в OPEN сообщении, а так же автоматической фильтрации по маркерам основываясь на установленной, в конфигурации, роли.

Соответственно если «роли» не совпадут, то BGP соединение не установится и у вас будет повод обратить внимание вашего клиента на НЕ верную конфигурацию на его стороне, а так же если новичок совсем не сделает никак BGP фильтров, то ПО сделает это автоматически и за него.

Считаю что предложение очень здравое и это действительно помогло бы в борьбе (с озвученной выше) с проблемой.

Пожалуй, это все, что я хотел бы сказать по итогам пирингового форума в этом году.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Вместо вступления: Давненько не писал, все руки как то не доходили. 2015 год заканчивается, надо бы обновить блог 🙂 Напишу те статьи что помню и давно хотел написать.

Итак в данной статье пойдет речь о оч.хор. фишке у Juniper, а именно возможность выполнить анонс сети по BGP от другой AS без поднятия BGP сессии с этой AS.

Зачем это может понадобиться ?

Например:

• ваша компания поглотила другую компанию у которой есть своя AS и свои префиксы. По тем или иным причинам вы не хотите отказываться от второй AS, но и держать два border роутера не хотите
• вам необходимо произвести работы на маршрутизаторе, который анонсирует вашу вторую AS, но в момент работ вы не хотите допустить перерыва в предоставлении сервиса пользователям
• и т.п.

Для понимания того что нам необходимо — читаем мануал «Understanding Aggregate Routes»:

routing-options {
    aggregate {
      (defaults | route) {
      (active | passive);
      as-path    ;
      community [ community-ids ];
      discard;
      (brief | full);
      (metric | metric2 | metric3 | metric4) metric ;
      (preference | preference2 | color | color2) preference ;
      tag string;
      }
   }
}

Вот это то что нам нужно.

В кач-ве примера возьмем следующие данные:

• основная AS: AS100
• вторая AS: AS200
• префикс AS200: 1.1.1.0/24

Правим конфигурацию:

[edit]
root@mx80.domain.ru# set routing-options aggregate route 1.1.1.0/24 as-path path 200 origin igp aggregator 100 2.2.2.2

Не забываем поправить BGP фильтры для анонса данной сети своим апстримам и пирам. Затем коммитим конфиг и у вас он в таблице роутинга появится как:

root@mx80.domain.ru> show route terse 1.1.1.0/24

inet.0: 568282 destinations, 569718 routes (567644 active, 0 holddown, 638 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    A 130                        Reject

А ваши пиры получат вот такой BGP маршрут:

root@external.domain.ru> show route terse 1.1.1.0/24

inet.0: 576181 destinations, 3792790 routes (575034 active, 35 holddown, 93700 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    B 170                                        100 200 I

Т.е. префикс 1.1.1.0/24 принадлежит AS200 и доступен по as-path AS100 -> AS200, но при этом, как мы знаем, BGP сессии между AS100 и AS200 не существует.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ссылка на новость: http://uinc.ru/news/sn22174.html

Попытки решить проблемы с нехваткой IPv4 адресов поставили Всемирную Сеть перед новой значительной проблемой — переполнением глобальной таблицы BGP-маршрутов. В настоящее время глобальная таблица маршрутов BGP на некоторых системах преодолела отметку в 512 тысяч записей, что начало приводить к разнообразным локальным проблемам со связностью. Ожидается, что своего пика проблема достигнет на следующей неделе, когда с переполнением столкнётся большинство провайдеров. Суть проблемы в том, что в процессе оптимизации пространства IPv4-адресов, провайдерам стали выделяться небольшие подсети, что привело к росту размера глобальной таблицы маршрутов BGP. При этом во многих устаревших, но ещё находящихся в эксплуатации, маршрутизаторах Cisco и некоторых других производителей для BGP-таблицы глобальных маршрутов IPv4 по умолчанию установлено ограничение в 512K элементов, что обусловлено размером TCAM-памяти, в которой размещается таблица маршрутов. Например, проблеме подвержены серии Cisco 7600, Cisco ASR 9000 с картами Trident, Cisco ASR 1000 с 4GB ОЗУ, Cisco Catalyst 6500. В зависимости от используемого маршрутизатора переполнение таблицы может привести к разным эффектам, от краха маршрутизатора до выпадания маршрутов и других проблем со связностью. В основном пострадают операторы связи, вынужденные использовать устаревшее оборудование. Крупные провайдеры уже перешли на современные модели маршрутизаторов, которые избавлены от упомянутых ограничений. Проблема также не повлияет на стабильность глобальной системы маршрутизации и будет ограничена только локальными проблемами со связностью у операторов, использующих устаревшие маршрутизаторы. Проблема уже привела к простою в работе таких компаний, как eBay, Comcast, Time-Warner, LastPass, Liquid Web. Так как TCAM-память разделена для таблиц IPv4 и IPv6, одним из решений является выделение дополнительной памяти для таблицы IPv4 за счёт урезания размера таблицы IPv6, но данная манипуляция («mls cef maximum-routes ip 1000») требует перезагрузки маршрутизатора. В настоящее время размер таблицы для IPv6 составляет менее 20 тысяч записей. 

Кратко о BIRD:

 The BIRD project aims to develop a fully functional dynamic IP routing daemon.

 - Both IPv4 and IPv6
 - Multiple routing tables
 - BGP
 - RIP
 - OSPF
 - Static routes
 - Inter-table protocol
 - Command-line interface
 - Soft reconfiguration
 - Powerful language for route filtering

 WWW: http://bird.network.cz/

 Пользователи FreeBSD могут найти демоны BIRD в портах:
    IPv4 версия: /usr/ports/net/bird
    IPv6 версия: /usr/ports/net/bird6

С момента размещения статьи Используем BIRD для создания «пограничного» маршрутизатора размещенную zaikini, я все мечтал найти время и уделить его изучению и пробам BIRD.

О демоне BIRD народ хорошо отзывается, да и многие IX`ы держат свои Route Server`а именно на этом демоне.

И вот наконец мне предоставилась такая возможность. Для одного проекта понадобилось автоматом генерить blackhole маршруты для BGP и тут я вспомнил что как раз давно хотел попробовать BIRD.

Поднял на тестовом стенде из тройки виртуальных машин:

• FreeBSD 9.1 + BIRD 1.3.11
• FreeBSD 8.4 + BIRD 1.3.11
• FreeBSD 7.2 + BIRD 1.3.2
• FreeBSD 7.2 + BIRD 1.3.11

Погонял BGP и OSPF в различных конфигурациях и схемах — понравилось. Даже больше скажу — очень понравилось. Есть конечно в BIRD некоторые вещи пока не совсем мне понятные или как это сказать не до конца логичные, НО в целом абалденный демон. Респект и уважуха разработчикам BIRD.

Итоговый «приговор» по BIRD: must have.

До сего момента мы работали на Quagga, но она иногда реально достает своими непонятными приколами, когда после реконфига чего либо помогает тока рестарт демонов дабы эти изменения наконец сказались.

Рестарт bgpd и о чудо ! Все непонятки устраняются и все работает как и положено. Но сейчас не об этом речь 🙂

Вообщем пересели мы на BIRD. Что дальше ? А дальше, как это водится, понадобился Looking Glass для BIRD`а, не всегда ж есть желание/возможность лазать в консоль 🙂

Погуглил… нагуглил только sileht/bird-lg и ulg—universal-looking-glass — оба написаны на python.

Попытки найти нечто подобное лукинг глассу для Cisco/Quagga/Juniper и на PHP мне не удалось.

«Ну что ж… Толи лыжи, толи … получается что нету… значит надо написать самому.» — сказал я и приступил к реализации :).

Через некоторое время первая версия LG на PHP была готова и протестирована.

Пока из функционала было реализовано самое необходимое — возможность посмотреть маршрут, пингать и трасернуть.

Потом я подумал о том, что скорее всего я не один такой, кто не хочет/может пользоваться LG на питоне, так же о (похоже) единственно существующем варианте LG для BIRD`а, а так же о том что сам пользуюсь бесплатным ПО, которое пишут и выкладывают другие и … и решил что нужно так же поделиться с общественностью своей разработкой.

Итак представляю вам свой труд и новый проект в рамках проекта Subnets.ru: BIRD Looking Glass на PHP.

Для работы LG вам необходимо:

• установленный и запущенный BIRD
• web сервер (аля apache)
• PHP5: модуль для apache и CLI версия

Более детально написано в README и ошибках, которые, если чего то не хватает, вам будет выдавать web интерфейс LG после его установки.

Я не смотрю на свои возможности через «розовые очки», я больше сис.админ чем программист, но все же кое что напрограммить и я могу 🙂

Лично я свою первоочередную задачу (наличие хоть какого LG для BIRD на PHP) решил. Возможно сей «продукт» поможет и вам.

Это явно не последняя версия этого LG, как снова дойдут руки — буду допиливать функционал далее, благо дело мыслей много, а желаний (как это обычно и бывает) ещё больше :).

В LG встроен механизм проверки наличия новой версии, поэтому если таковая появится, то те кто установит и будет использовать узнают об этом зайдя на главную страницу своего LG.

Надо ли пояснять, что для функционирования сего механизма сервер с LG должен иметь доступ к Инету, а если быть точнее то к URL`у http://bird-lg.subnets.ru/.

Работа LG проверена под OS FreeBSD, если у вас другая ось то вы как раз проверите сами.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

В продолжении предыдущей статьи Juniper и Policy-based routing ( PBR ) появилась задача когда необходимо чтобы маршруты из таблицы inet.2 (mBGP) попадали не только в нее, но и в таблицу inet.0 (eBGP).

Расскажу и покажу как это сделали мы.

Дано

• MX80 (JUNOS 10.4R1.9)
• апстрим с двумя BGP сессиями eBGP и mBGP

Задача

Импортировать маршруты принимаемые в сессии mBGP (роутинг таблица inet.2) в таблицу сессии eBGP (таблица inet.0).

Реализация

Состояние ДО изменений:

Для примера возьмем маршрут до подсети 11.11.11.192/28.
Посмотрим текущий маршрут до этой подсети:

juniper-MX80> show route terse 11.11.11.192
inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

Видим что данный маршрут находится только в таблице inet.2, это то мы и будем «исправлять».

Приступим. Как и в случае с PBR нам поможет механизм rib-groups.
Создадим rib группы:

routing-options {
    rib-groups {
        bgp-multicast-rg {
            export-rib inet.2;
            import-rib [ inet.2 inet.0 ];
        }
        bgp-unicast-rg {
            export-rib inet.0;
            import-rib inet.0;
        }
    }
}

Мы создали две rib группы: одну для unicast, другую для multicast. В rib группе multicast в import-rib мы указали, что принимаемые маршруты нужно импортировать и в таблицу inet.0.

Теперь опишем эти rib группы в protocols bgp:

protocols {
    bgp {
        family inet {
            unicast {
                rib-group bgp-unicast-rg;
            }
            multicast {
                rib-group bgp-multicast-rg;
            }
        }
    }
}

Ну и сами BGP пиры, один eBGP, другой mBGP:

protocols {
    bgp {
        log-updown;
        local-as 65000;
        group ebgp {
            type external;
            no-advertise-peer-as;
            neighbor 10.10.10.229 {
                description eBGP_peer;
                import bgp-import;
                family inet {
                    unicast;
                }
                export bgp-export;
                peer-as 65500;
            }
        }
        group mbgp {
            type external;
            no-advertise-peer-as;
            neighbor 20.20.20.209 {
                description mBGP_peer;
                import bgp-mcast-import;
                family inet {
                    multicast;
                }
                export bgp-mcast-export;
                peer-as 65500;
            }
        }
    }
}

После commit`а смотрим появился ли маршрут в таблице inet.0:

juniper-MX80> show route terse 11.11.11.192

inet.0: 51 destinations, 51 routes (44 active, 0 holddown, 7 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

А вот теперь мы видим что наш маршрут присутствует в двух таблицах, что нам и было надо.

Ссылки

• Interdomain multicast routing: practical Juniper Networks and Cisco systems
• rib-group

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)