Микровыпуск №3. IBGP. 3. Ibgp13 октября 2013, 17 4392
 Скачать 3.56 Mb.
|
|
— Full Mesh. Придётся устанавливать соседство со всеми всеми маршрутизаторами вручную. OMG, мне дороги моя жизнь и здоровье. (Да, даже не смотря на наличие Route Re ector’ов и скриптов — это лишние операции) Другая проблема — медленная реакция и Дистанционно-Векторный подход к распространению маршрутной информации. Да и тут можно резонно возразить, что, дескать, существует BFD. Однако он уменьшит время обнаружение проблемы, но сходимость/ восстановление связности всё равно будет медленным. Третий тонкий момент — отсутствие возможности автоматического изучения соседей. Что ведёт к ручной их конфигурации. Из всего вышеуказанного вытекают проблемы масштабируемости и обслуживания. Просто попробуйте сами использовать BGP вместо IGP на сети из 10 маршрутизаторов, и всё станет ясно. То же самое касается и распространения белых адресов — IBGP с этим справится, но на каждом маршрутизаторе придётся вручную прописывать все подсети. Ну например, наша сеть 100.0.0.0/23. Допустим, к маршрутизатору R3 подключены 3 клиента по линковым адресам: 100.0.0.8/30, 100.0.0.12/30 и 100.0.0.16/0. Так вот эти 3 подсети вам нужно будет ввести в BGP тремя командами network, в то время как в IGP достаточно активировать протокол на интерфейсе. Можно, конечно, прибегнуть к хитрой редистрибуции маршрутов из IGP, но это попахивает уже костылями и ещё менее прозрачной конфигурацией. К чему всё это мы ведём? eBGP — протокол маршрутизации, без дураков. В то же время iBGP — не совсем. Он больше похож на приложение верхнего уровня, организующее распространение маршрутной информации по всей сети. В неизменном виде, а не сообщая при каждой итерации соседу «вон туда через меня». У IGP такое поведение тоже иногда встречается, но там это исключение, а тут — норма. Я хочу подчеркнуть ещё раз, IGP и IBGP работают в паре, в связке, каждый из них выполняет свою работу. IGP обеспечивает внутреннюю IP-связность, быструю (читай мгновенную) реакцию на изменения в сети, оповещение всех узлов об этом как можно быстрее. Он же знает о публичных адресах нашей AS. IBGP занимается обработкой Интернетных маршрутов в нашей AS и их транзитом от Uplink’a к клиентам и обратно. Обычно он ничего не знает о структуре внутренней сети. Если вам пришёл в голову вопрос «что лучше BGP или IS-IS?» — это хорошо, значит у вас пытливый ум, но вы должны отчётливо понимать, что верный ответ тут только один — это принципиально разные вещи, их нельзя сравнивать и выбирать мисс “технология маршрутизации 2013”. IBGP работает поверх IGP. ===================== Задача № 5 Вышестоящая AS 604503 агрегирует несколько сетей, в том числе и нашу, в один диапазон 100.0.0.0/6. Но этот суммарный префикс вернулся в нашу автономную систему, хотя и не должен был. Настроить R8 так, чтобы агрегированный префикс не попадал в таблицу BGP маршрутизаторов, которые анонсируют подсети этого префикса. Не использовать фильтрацию для этого. Конфигурация и схема: базовые. Подробности задачи тут. ===================== Проблема Эн квадрат На этом месте тему IBGP можно было бы закрыть, если бы не одно «НО» — Full Mesh. Мы говорили о проблемах полносвязной топологии, когда обсуждали OSPF. Там выходом являлись DR — Designated Router, позволяющие сократить количество связей между маршрутизаторам с n*(n-1)/2 до n-1. Но, если в случае OSPF такая топология была, скорее, исключением, потому что больше 2-3 маршрутизаторов в одном L2-сегменте бывает довольно редко, то для IBGP — это самая обычная практика. У «больших» счёт BGP-маршрутизаторов внутри AS идёт на десятки. А уже для 10 устройств на каждом узле нужно будет прописать 9 соседей, то есть всего 45 связей и 90 команд neighbor как минимум. Не хило так. Итак, мы подошли к таким понятиям, как Route Re ector и Confederation. Уж не знаю почему, но эта тема меня всегда пугала какой-то надуманной сложностью. Route Re ectror В чём суть понятия Route Re ector? Это специальный IBGP- маршрутизатор, который, исходя из дословного его перевода, выполняет функцию отражения маршрутов — ему присылает маршрут один сосед, а он рассылает его всем другим. То есть фактически на IBGP-маршрутизаторах вам нужно настроить сессию только с одним соседом — с Route Re ector’ом, а не с девятью. Всё довольно просто и тут прямая аналогия с тем самым DR OSPF. Чуть больше о правилах работы RR. Во-первых введём понятия клиент RR и не-клиент RR. Для данного маршрутизатора клиент — iBGP сосед, который специально объявлен, как RR client, и для которого действуют особые правила. Не-клиент — iBGP сосед, который не объявлен, как RR client RR серверов может быть (и должно быть в плане отказоустойчивости) несколько. И понятия клиент/не-клиент строго локальны для каждого RR-сервера. RR-сервер (или несколько) в совокупности с со своими клиентами формируют кластер. Правила работы RR Если RR получил маршрут от клиента, он отправляет его всем своим клиентам, не-клиентам-соседям и внешним (EBGP) соседям. Если RR получил маршрут от не-клиента, он отправляет его всем клиентам и EBGP-соседям. Не-клиентам маршруты НЕ отправляются (потому что они эти маршруты уже получили напрямую от исходного маршрутизатора). Если RR получил маршрут от EBGP-соседа, он отправляет его всем своим клиентам, не-клиентам-соседям и внешним соседям. Как мы сказали выше, в сети может быть несколько Route- re ector’ов. Это нормально, это не вызовет образование петли, потому что существует атрибут Originator ID — как только RR получит маршрут, где указан он сам, как отправитель этого маршрута, он его отбросит. Каждый RR в таком случае будет иметь таблицу маршрутов BGP точно такую же, как у других. Это вынужденная избыточность, позволяющая значительно увеличить стабильность, но при этом у вас должна быть достаточная производительность самих устройств, чтобы, например, поддерживать по паре Full View на каждом. Но несколько RR могут собираться в кластеры и разрушать деревни обеспечивать экономию ресурсов — таблица BGP будет делиться между несколькими RR. Принадлежность к одному кластеру настраивается на каждом RR и определяется атрибутом Cluster ID. И вот тут тонкий момент — считается, что Best Practice — это настройка одинакового Cluster-ID на всех RR, но на самом деле это не всегда так. Выбирать нужно, исходя из дизайна вашей сети. Более того, часто рекомендуют даже намеренно разделять Route Re ector’ы — как ни странно, это увеличивает стабильность сети. Дабы не растекаться мысью по древу, просто дам ссылку на материал об этом. Вот так выглядит обычная схема с RR: Если клиент получил маршрут от RR, он его может отправить только EBGP-соседу. Схема с основным и резервным RR: Внутри кластера между всему RR должна быть полная связность. Кластеров может быть несколько и между ними также следует создавать Full-Mesh сеть: Повторимся, что кластер: это Рут-рефлектор (один или несколько) вместе со всеми своими клиентами. Кроме того, часто практикуют иерархические RR. Например, так: RR1 получает маршруты от удалённой AS и раздаёт их своим дочерним RR (Client/RR1), которые в свою очередь раздают их клиентам. Это имеет смысл только в достаточно крупных сетях. Относительно Route Re ector’ов важно понимать, что сам маршрутизатор, выполняющий функции RR не обязательно участвует в передаче данных. Более того, часто RR специально выносят за пределы пути передачи трафика, чтобы он выполнял исключительно обязанности по передаче маршрутов, чтобы не увеличивать нагрузку на него. Практика RR Для примера предположим, что в нашей сети в качестве RR будет выступать R1. Вот конфигурация самого простого случая RR — одинокого, без кластера. R1 router bgp 64500 network 100.0.0.0 mask 255.255.254.0 neighbor AS64500 peer-group neighbor AS64500 remote-as 64500 neighbor AS64500 update-source Loopback0 neighbor AS64500 route-reflector-client neighbor AS64500 Next-Hop-self neighbor 2.2.2.2 peer-group AS64500 neighbor 3.3.3.3 peer-group AS64500 neighbor 4.4.4.4 peer-group AS64500 neighbor 101.0.0.1 remote-as 64501 R2 router bgp 64500 network 100.0.0.0 mask 255.255.254.0 neighbor 1.1.1.1 remote-as 64500 neighbor 1.1.1.1 update-source Loopback0 neighbor 1.1.1.1 Next-Hop-self neighbor 102.0.0.1 remote-as 64502 R3 router bgp 64500 network 100.0.0.0 mask 255.255.254.0 neighbor 1.1.1.1 remote-as 64500 neighbor 1.1.1.1 update-source Loopback0 neighbor 1.1.1.1 Next-Hop-self R4 router bgp 64500 network 100.0.0.0 mask 255.255.254.0 neighbor 1.1.1.1 remote-as 64500 neighbor 1.1.1.1 update-source Loopback0 neighbor 1.1.1.1 Next-Hop-self neighbor 100.0.0.6 remote-as 64504 Обратите внимание на команду «neighbor AS64500 route- re ector-client«, добавившуюся в настройку R1 и то, что конфигурация BGP на всех других устройствах полностью идентична, за исключением внешних соседей (102.0.0.1 для R2 и 100.0.0.6 для R4). В общем-то внешне ничего не поменяется. R4, например, всё будет видеть точно также, за исключением количества соседей: Обратите внимание на то, что Route Re ector не меняет Next-Hop отражённых маршрутов на свой, несмотря на наличие параметра Next-Hop-self. На самом Route Re ector’е отличие будет выглядеть так: Если смотреть по конкретным маршрутам: Здесь видно полную подсеть, количество путей до неё, какой из них лучший, в какую таблицу он добавлен, куда передаётся (update-group 2 — как раз наш кластер). Далее перечисляются все эти пути, содержащие такие важные параметры, как AS-Path, Next-Hop, Origin итд, а также информацию о том, что например, первый маршрут был получен от RR-клиента. Эту информацию можно успешно использовать для траблшутинга. Вот так, например выглядит её вывод, когда не настроен Next-Hop-self: Конфигурация устройств. Проблема резервирования Какая сейчас с рут-рефлектором есть проблема? У всех маршрутизаторов связи установлены только с ним. И если R1 вдруг выйдет из строя, пиши пропало — сеть ляжет. Для этих целей, давайте настроим кластер и в качестве второго RR выберем R2. То есть теперь на R3 и R4 нужно поднимать соседства не только с R1, но и с R2. Теперь sh ip bgp update-group выглядит так: Один внешний, один внутренний — не RR-клиент и два внутренних RR-клиента. Аналогично на R2: На клиентах у нас теперь два соединения с RR: Обратите внимание, в сообщениях Update теперь появились два новых атрибута: Cluster-List и Originator-ID. Исходя из названия, они несут в себе номер RR-кластера и идентификатор отправителя анонса: R1<->R2 Эти параметры добавляются только маршрутам, передающимся по IBGP. Они необходимо для того, чтобы избежать образования петель. Если, например, маршрут прошёл несколько кластеров и вернулся в исходный, то в параметре Cluster-List среди всех прочих, маршрутизатор увидит номер своего кластера, и после этого удалит маршрут. Попробуйте ответить на вопрос, зачем нужен атрибут Originator-ID? Разве Cluster-List не исчерпывает все варианты? Если сейчас даже сжечь R1, то связь частично ляжет только на время обнаружения проблемы и перестроения таблиц маршрутизации (в худшем случае это 3 минуты ожидания Keepalive сообщения BGP и ещё какое-то время на изучение новых маршрутов). Но, если дизайн сети у вас предполагал, что RR — это самостоятельные железки, и через них не ходил трафик (то есть они занимались исключительно распространением маршрутов), то, вполне вероятно, что перерыва трафика не будет вовсе. Во- первых, отправитель только через 3 минуты заметит, что что-то не так с RR — в течение этого времени маршрут у него всё-равно будет, а поскольку он ведёт не через бесславно погибший RR, трафик будет ходить вполне благополучно. По прошествии этих трёх минут отправитель переключится на резервный RR и получит от него новый актуальный маршрут. Таким образом связь не будет прервана. Суть иерархических рут-рефлекторов лишь в том, что один из них является клиентом другого. Это помогает выстроить более понятную и прозрачную схему работы, которую будет проще траблшутить далее. На нашей сети это лишено какого бы то ни было смысла, поэтому данный случай рассматривать не будем. Конфедерации Другой способ решения проблемы Full-Mesh — это конфедерации или иначе их называют sub-AS, под-АС. По сути — это маленькая виртуальная АС внутри большой настоящей АС. Каждая конфедерация ведёт себя как взрослая AS — внутри полная связность, снаружи, как Лейбниц на душу положит — IBGP работает тут по принципу EBGP (с некоторыми оговорками), граничные маршрутизаторы конфедераций, ведут себя как EBGP- соседи, должны быть подключены напрямую. Пример топологии: Когда маршруты передаются внутри АС между конфедерациями в их AS-Path добавляется номер конфедерации (сегменты AS_CONFED_SEQ и AS_CONFED_SET) для избежания петель. Как только маршрут покидает AS, удаляются все эти номера, чтобы внешний мир о них не знал. Встречается он довольно редко из-за своей слабой масштабируемости и непрозрачности, поэтому рассматривать мы его не будем. Более подробно можно почитать на xgu.ru. ____________________________ Атрибуты BGP Последняя тема, которую мы затронем касательно BGP — это его атрибуты. Мы их уже начали рассматривать в основной статье (AS- Path и Next-Hop, например). Теперь же имеющиеся знания систематизируем и дополним. Они делятся на четыре типа: Хорошо известные обязательные (Well-known Mandatory) Хорошо известные необязательные (Well-known Discretionary) Опциональные передаваемые/транзитивные (Optional Transitive) Хорошо известные обязательные (Well-known Mandatory) Опциональные непередаваемые/нетранзитивные (Optional Non-transitive) Это атрибуты, которые должны присутствовать в анонсах всегда, и каждый BGP-маршрутизатор должен их знать. Следующие три атрибута и только они принадлежат к этому типу. Next-Hop говорит маршрутизатору, получающему анонс, о том, куда отправлять пакет. При передаче маршрута между различными AS значение Next- Hop меняется на адрес отправляющего маршрутизатора. Внутри AS атрибут Next-Hop по умолчанию не меняется при передаче от одного IBGP-оратора другому. Выше мы уже рассматривали почему. AS-path несёт в себе список всех Автономных Систем, которые нужно преодолеть для достижения цели. Используется для выбора лучшего пути и для исключения петель маршрутизации. Когда маршрут передаётся из одной AS в другую, в AS-path вставляется номер отправляющей AS. При передаче внутри AS параметр не меняется. Origin сообщает, как маршрут зародился — командой network (IGP — значение 0) или редистрибуцией (Incomplete — значение 2). Значение 1 (EGP) — уже не встречается ввиду того, что протокол EGP не используется. Назначается единожды маршрутизатором- папой, сгенерировавшим маршрут, и более нигде не меняется. По сути означает степень надёжности источника. IGP — самый крутой. Хорошо известные необязательные (Well-known Discre onary) Эти атрибуты должны знать все BGP-маршрутизаторы, но их присутствие в анонсе не требуется. Хочешь — есть, не хочешь — не есть. Примеры: Local Preference помогает выбрать один из нескольких маршрутов в одну сеть. Данный атрибут может передаваться лишь в пределах одной AS. Если анонс с Local Preference приходит от EBGP-партнёра, атрибут просто игнорируется — мы не можем с помощью Local Preference управлять маршрутами чужой AS. Atomic Aggregate говорит о том, что префикс был получен путём агрегирования более мелких. Опциональные передаваемые/ транзитивные (Op onal Transi ve) Атрибуты, которые не обязательно знать всем. Кто знает — использует, кто не знает — передаёт их дальше. Примеры: Aggregator. Указывает на Router ID маршрутизатора, где произошло агрегирование. Community. Про этот атрибут мы подробно поговорим далее, в заключительной части статьи. Опциональные непередаваемые/ нетранзитивные (Op onal Non- transi ve) Атрибуты, которые не обязательно знать всем. Но маршрутизатор, который их не поддерживает, их отбрасывает и никуда дальше не передаёт. Пример: MED — Mul -exit Descriminator. Этим атрибутом мы можем попытаться управлять приоритетами в чужой AS. Можем попытаться, но вряд ли что-то получится Часто этот атрибут фильтруется, он имеет значение только при наличии как минимум двух линков в одну AS, он проверяется после многих очень сильных атрибутов (Local Preference, AS-Path), да и разные вендоры могу по-разному трактовать MED. Упомянутые прежде Cluster List и Originator-ID. Естественно, они являются опциональными, и естественно, передавать их куда-то за пределы AS нет смысла, поэтому и непередаваемые. ===================== Задача № 6* Необходимо изменить стандартную процедуру выбора лучшего маршрута на маршрутизаторах в AS64500: — маршрутизаторы R1 и R2 должны выбирать маршруты eBGP, а не iBGP, независимо от длины AS path, — маршрутизаторы R3 и R4 внутри автономной системы должны выбирать маршруты на основании метрики OSPF. Конфигурация и схема: базовые. Подробности задачи тут. ===================== Community Вот он — один из самых интересных аспектов BGP, вот где проявляется его гибкость — возможность помимо самих маршрутов, передавать дополнительную информацию. С помощью атрибута Community можно из своей AS управлять поведением маршрутизаторов другой AS. Я долгое время по непонятной сейчас для себя причине недооценивал мощь этого инструмента. Управление своими анонсами в чужой AS с помощью community поддерживается подавляющим большинством вендоров. Но на самом деле говорить тут надо не о вендорах, а, скорее, о операторах/провайдерах — именно от них зависит, от их конфигурации, сможете ли вы управлять или нет. Начнём с теории, Community, как было сказано выше, — это опциональный передаваемый атрибут (Optional Transitive) размером 4 байта. Он представляет из себя запись вида AA:NN, где AA — двухбайтовый номер AS, NN — номер коммьюнити (например, 64500:666). Существует 4 так называемых Well-Known community (хорошо известные): Internet — Нет никаких ограничений — передаётся всем. No-export — Нельзя экспортировать маршрут в другие AS. При этом за пределы конфедерации передавать их можно. No-export-subconfed (называется также Local AS) — Как No-export, только добавляется ограничение и по конфедерациям — между ними уже тоже не передаётся. No-adver se — Не передавать этот маршрут никому — только сосед будет знать о нём. ===================== Задача |