Микровыпуск №3. IBGP. 3. Ibgp13 октября 2013, 17 4392
 Скачать 3.56 Mb.
|
|
№ 7 Наш новый клиент AS 64504 подключен к нашей сети. И пока что не планирует подключение к другому провайдеру. На данном этапе клиент может использовать номер автономной системы из приватного диапазона. Блок адресов, который использует клиент, будет частью нашего диапазона сетей. Задание: Так как сеть клиента является частью нашего блока адресов, надо чтобы сеть клиента не анонсировалась соседним провайдерам. Не использовать фильтрацию префиксов или фильтрацию по AS для решения этой задачи. Конфигурация и схема: Community. Отличия только в том, что сеть, которую анонсирует AS64504: 100.0.1.0/28, а не 130.0.0.0/24 Подробности задачи тут. ===================== В сети тысячи примеров настройки таких базовых коммьюнити и крайне мало примеров реального использования. А меж тем одно из самых интересных применений этого атрибута — блэкхоулинг от старославянского black hole — способ борьбы с DoS-атаками. Очень подробно с примером настройки о нём уже было рассказано на хабре. Суть в том, что когда началась атака на какой-то из адресов вашей AS, вы этот адрес передаёте вышестоящему провайдеру с комьюнити 666, и он отправляет такой маршрут в NULL — блэкхолит его. То есть до вас уже этот паразитный трафик не доходит. Провайдер может передать такой маршрут дальше, и так, шаг за шагом, трафик от злоумышленника или системы ботов будет отбрасываться уже на самых ранних этапах, не засоряя Интернет. Достигается такой эффект расширяющейся чёрной дыры именно благодаря коммьюнити. То есть в обычном случае вы анонсируете этот адрес в составе большой сети /22, например, а в случае DoS’а передаёте самый специфичный маршрут /32, который будет, естественно, более приоритетным. О таких атаках вы, кстати, можете послушать в шестом выпуске нашего подкаста linkmeup. Другие примеры — управление атрибутом Local Preference в чужой AS, сообщать ему, что анонсу нужно увеличить AS-path (AS- path prepending) или не передавать маршрут каким-либо соседям. Насчёт последнего. Как, например, вы решите следующую задачу? Имеется сеть, представленная на рисунке ниже. Вы хотите отдавать свои маршруты соседям из AS 100 и 200 и не хотите 300. Без использования коммьюнити силами только своей AS сделать это не представляется возможным. Кстати, как бы это ни было прискорбно, но такие ограничения реально используются в нашей жизни. Распространены ситуации, когда несколько провайдеров устанавливают между собой пиринговые отношения — трафик между их сетями не ходит через вышестоящих провайдеров, не даёт круг через пол-России, но кого-то не пускают — кому-то свои сети не анонсируют. Интереснейшие статьи об Интернете и BGP и о пиринговых войнах. Практика Community Мы же в качестве примера рассмотрим следующую ситуацию. Основная схема статьи дополняется ещё одним маршрутизатором клиента и двумя линками. R7 и R9 разнесены территориально — так называемое георезервирование. Главным является его правый сайт, левый — резервный. Внутри своей AS он без проблем настроил передачу исходящего трафика в нужном месте — через R3. А вот со входящим посложнее — MED не позволяет использовать религия, да и доверия ему нет. Поэтому мы разработали схему взаимодействия, используя community. На самом деле она будет общая для всех. Например, ниже мы установим правило — если получили маршрут с коммьюнити 64500:150, увеличить Local Preference для него до 150. А потом такую политику применяем к нужным нам маршрутам. На нашем оборудовании (на всём) мы определяем ip community- list: ip community-list 1 permit 64500:150 Задаём правило обработки: route-map LP150 permit 10 match community 1 set local-preference 150 Это общий блок, который будет одинаков для всех устройств. После этого клиент может сказать, что хочет воспользоваться этой функцией и мы применяем карту на BGP-соседа: Применяем карту к BGP-соседу на R3: router bgp 64500 neighbor 100.0.0.10 remote-as 64504 neighbor 100.0.0.10 route-map LP150 in Итак, если в анонсе от соседа 100.0.0.10 community совпадает со значением в условии, установить Local Preference для этих маршрутов в 150. Часто такие политики (route-map) применяются по умолчанию на всех внешних соседей. Клиентам остаётся только настроить передачу нужной коммьюнити и даже не нужно просить о чём-то провайдера — всё сработает автоматически. Это наша политика по использовании коммьюнити. О ней мы сообщаем клиенту, мол, хочешь Установить для своего маршрута Local Preference в 150 в нашей AS, используй community 64500:150 И вот он настраивает на R9: router bgp 64504 neighbor 100.0.0.9 remote-as 64500 neighbor 100.0.0.9 route-map LP out neighbor 100.0.0.9 send-community route-map LP permit 10 set community 64500:150 При необходимости то же самое он может настроить на R7. После clear ip bgp * so в отправляемых анонсах мы можем увидеть community: В итоге R3 имеет маршрут с более высоким Local Preference: Передаёт его рут-рефлектору (R1 и R2), который делает выбор и распространяет всем своим соседям: И даже R4, которому рукой дотянуться до R7, будет отправлять трафик на R3: Трафик идёт именно тем путём, который мы выбрали. Пусть вас не пугает по 3 записи для каждого хопа — это говорит о балансировке трафика между равноценными линками R1<->R2<->R3 и R1<- >R4<->R3. Просто один раз он идёт по одному пути, второй по другому. А вот вы лучше попробуйте ответить на вопрос, почему на первом хопе 1-я и 3-я попытки идут через R4, а вот на втором хопе на R3. Почему пакет “перепрыгивает”? Как так получается? Кстати, не стоит забывать команду ip bgp-community new-format, а иначе вместо этого: вы увидите это: Отправляться будет то же самое, но в выводах show команд будет отображаться в удобном виде. ===================== Задача № 8 В нашей AS для настройки политик с клиентскими AS, используются community. Используются такие значения: 64500:150, 64500:100, 64500:50, 64500:1, 64500:2, 64500:3. Кроме того, маршрутизаторы нашей AS также используют community для работы с соседними AS. Их формат: 64501:xxx, 64502:xxx. Задание: — все значения community приходящие от клиентов, которые не определены политикой, должны удаляться, — значения community, которые проставлены клиентами, должны удаляться, при передаче префиксов соседним вышестоящим AS. При этом не должны удаляться другие значения, которые проставлены маршрутизаторами нашей AS. Конфигурация и схема: базовые. Подробности задачи тут. ===================== Конфигурация устройств В приведённом примере видно, что коммьюнити позволяет работать не с отдельными анонсами и для каждого из них отдельно применять какие-то политики, а рассматривать их сразу как группу, что естественно, значительно упрощает обслуживание. Иными словами, коммьюнити — это группа анонсов с одинаковыми характеристиками. При работе с community важно понимать, что настройка необходима с двух сторон — чтобы желаемое заработало, у провайдера тоже должна быть выполнена соответствующая конфигурация. Часто у провайдеров бывает уже выработанная политика использования коммьюнити, и они просто дают вам те номера, которые необходимо использовать. То есть после того, как вы добавите к анонсу номер коммьюнити, провайдеру не придётся ничего делать руками — всё произойдёт автоматически. Например, у Балаган-Телекома может быть такая политика: Значение Действие 64501:100Х При анонсировании маршрута соседу A добавить Х препендов, где Х от 1 до 6 64501:101X При анонсировании маршрута соседу B добавить Х препендов, где Х от 1 до 6 64501:102X При анонсировании маршрута соседу C добавить Х препендов, где Х от 1 до 6 64501:103X При анонсировании маршрута в AS64503 добавить Х препендов, где Х от 1 до 6 64501:20050Установить Local Preference для полученных маршрутов в 50 64501:20150Установить Local Preference для полученных маршрутов в 150 64501:666 Установить Next-Hop для маршрут в Null — создать Black Hole 64501:3333 выполнить скрипт по уничтожению конфигурации BGP на всех маршрутизаторах AS Исходя из этой таблички, которая опубликована на сайте Балаган- телекома, мы можем сами принять решение об управлении трафиком. Как это реально может помочь нам? У нас Dual-homing подключение к двум различным провайдерам — Балаган Телеком и Филькин Сертификат. У датацентра подключение также к обоим провайдерам. Он принадлежит какому-то контент-генератору, допустим это оператор потового видео. По умолчанию, в нашу сеть всё ходит через Балаган-Телеком (AS64501). Канал там хоть и широкий, но его утилизация уже достаточно высока. Мы хотим продавать домашним клиентам услугу IPTV и прогнозируем значительный рост входящего трафика. Неплохо было бы его завернуть в Филькин Сертификат и не бояться о том, что основной канал забьётся. При этом, естественно, весь другой трафик переносить не нужно. В таблице BGP проверяем, где находится сеть 103.0.0.0. Видим, что это AS64503, которая достижима через обоих провайдеров с равным числом AS в AS-Path. Вот как видит нас маршрутизатор из AS 64503: Маршрут в Балаган-Телеком выбран предпочтительным Какие мысли? Анонсировать определённые сети в Филькин Сертификат, а остальные оставить в Балаган Телеком? Негибко, немасштабируемо. Вешать препенды на маршруты, отдаваемые в Балаган Телеком? Тогда, скорее всего, куча другого трафика перетечёт на Филькин Сертификат. Попросить инженера Балаган-Телекома вручную удлинить наши маршруты при передаче их в AS64503. Уже ближе к истине, и это даже сработает, но, скорее всего, инженер провайдера пошлёт вас… на сайт с табличкой, где прописана их политика Community. Собственно, всё, что нужно сделать нам — на маршрутизаторе R1 применить route-map по добавлению коммьюнити 64500:1031 к соседу R5(напоминаем, что 103Х — это для соседа из AS 64503). Дальше всё сделает автоматика. Вот как R5 видит маршрут сам: Всё без изменений. Вот как его видит R8: Как видите, галочка стоит напротив более короткого пути через Филькин Сертификат, чего мы и добивались. ===================== Задача № 9 Одним из наших клиентов стала крупная компания. Платят они нам довольно много, но тут возникла проблема с тем, что когда происходят какие-то проблемы с провайдером AS64501, то качество связи, которую обеспечивает линк с провайдером AS64502, не устраивает клиента. Главное для нашего клиента, хорошее качество связи к филиалам. Так как клиент солидный, то пришлось установить пиринг с еще одним провайдером AS64513. Но он нам дорого обходится поэтому использовать его мы будем только когда провайдер AS64501 недоступен и только для этого важного клиента. Задание: Надо настроить работу сети таким образом, чтобы через провайдера AS64513 сеть клиента 150.0.0.0/24 анонсировалась только в том случае, если через провайдера AS64501 недоступна сеть 103.0.0.0/22 (она используется для проверки работы провайдера). Кроме того, от провайдера AS64513 нам надо принимать только сети филиалов клиента (50.1.1.0/24, 50.1.2.0/24, 50.1.3.0/24) и использовать их только если они недоступны через провайдера AS64501. Остальной трафик клиента будет ходить через AS64502. Конфигурация: базовая. Подробности задачи тут. ===================== Материалы выпуска Повесть о настоящем Интернете BGP Blackhole — эффективное средство борьбы с DDoS Сравнение функций и мест использования EBGP и IBGP Основы BGP Конфигурация устройств: базовый IBGP, Route Re ectors, Community. Послесловие Вот на этом знакомство с BGP можно считать законченным. Теперь мы вернёмся к нему ни много ни мало при рассмотрении MPLS L3VPN. За траблшутинг статьи спасибо JDIMA Задачки предоставлены Наташей — автором лучшего викисайта по сетевым протоколам и технологиям — xgu.ru. 92 246464 34 34 коментария Dmitry Alekseev Войдите, чтобы ответить Добрый день. Прошу уточнить по Well-Known community, нет ли ошибки? т.к. согласно tools.ietf.org/html/rfc1997: «NO_EXPORT (0xFFFFFF01) |