Микровыпуск №3. IBGP. 3. Ibgp13 октября 2013, 17 4392
 Скачать 3.56 Mb.
|
|
linkmeup Все выпуски Долго ли коротко ли длилась история linkmeup, но компания росла, развивалась. Счёт маршрутизаторов уже на десятки, свои опто-волоконные линии, развитая сеть по городу. И было принято решение оформлять компанию, как провайдера и предоставлять услуги доступа в Интернет для сторонних в том числе организаций. Сама по себе задача административная — лицензии там, поиск клиентской базы, реклама, поставить СОРМ. Разумеется, с технической стороны тоже нужны приготовления — просчитать ресурсы, мощности, порты, подготовить политику QoS. Но всё это (за исключением QoS) — рутина. Мы же хотим поговорить о другом — IBGP. Возможно, тема покажется вам несколько притянутой за уши, мол, внутренний BGP — прерогатива достаточно крупных провайдеров. Однако это не так, сейчас iBGP задействуется в ентерпрайзах чуть ли не чаще, чем в провайдерах. С целью исключительно внутренней маршрутизации. Например, ради VPN — очень популярное приложение на базе BGP в корпоративной среде. К примеру, возможность организовать периметры, изолированные на L3, на уже используемой инфраструктуре очень ценна. А префиксов-то может быть каких-то полсотни, а то и десяток. Вовсе никакой не Full View, однако все равно удобно. Возможно, к нашей сети Linkmeup это не имеет по-прежнему отношения, но обойти стороной такую концепцию будет совершенно непростительно. Поэтому предположим, что сеть достаточно велика, и у нас есть необходимость в BGP в ядре. Сегодня обсудим Когда нужен IBGP В чём отличия от EBGP Route Re ector’ы Конфедерации Нерассмотренные в основной статье атрибуты BGP Сети для самых маленьких. Микровыпуск №3. IBGP 13 октября 2013, 17:43 92 246464 34 Традиционное видео Сети для самых маленьких. Микровыпуск Сети для самых маленьких. Микровыпуск … … Задачки в этом выпуске не относятся напрямую к IBGP, это, скорее, по BGP в целом. Интересно будет как новичкам поломать голову, так и старожилам размяться Что такое IBGP? Начнём с того, что вообще такое Internal BGP. По сути это тот же самый BGP, но внутри AS. Он даже настраивается практически так же. Основных применения два: Резервирование. Когда есть несколько линков к провайдерам и не хочется замыкать всё на одном своём граничном маршрутизаторе (т.н. бордере (от старославянского border — граница), ставится несколько маршрутизаторов, а между ними поднимается IBGP для того, чтобы на них всегда была актуальная информация обо всех маршрутах. В случае проблем у провайдера ISP2 R2 будет знать о том, что те же самые сети доступны через ISP1. Об этом ему сообщит R1 по IBGP. Подключение клиентов по BGP. Если стоит задача подключить клиента по BGP, при этом у вас больше, чем один маршрутизатор, без IBGP не обойтись. Чтобы R4 передал Клиенту1 Full View, он должен получить его по IBGP от R1 или R2. Повторимся, EBGP используется между Автомномными Системами, IBGP — внутри. Различия IBGP и EBGP 1) Главная тонкость, которая появляется при переходе внутрь Автономной Системы и откуда растут ноги почти всех отличий — петли. В EBGP мы с ними справлялись с помощью AS-Path. Если в списке уже был номер собственной AS, то такой маршрут отбрасывался. Но, как вы помните, при передаче маршрута внутри Автономной Системы AS-Path не меняется. Вместо этого в IBGP прибегают к хитрости: используется полносвязная топология — все соседи имеют сессии со всеми — Full Mesh. При этом маршрут, полученный от IBGP-соседа не анонсируется другим IBGP-соседям. Это позволяет на всех маршрутизаторах иметь все маршруты и при этом не допустить петель. Поясним на примерах. Как это могло бы быть в такой топологии, например, если не использовать технологию избежания петель: R1 получил анонс от EBGP-соседа, передал его R2, тот передал R3, R3 передал R4. Вроде, все молодцы, все знают, где находится сеть Интернет. Но R4 передаёт этот анонс обратно R1. R1 получил маршрут от R4, и он по выгодности точно такой-же, как оригинальный от ISP — AS-Path-то не менялся. Поэтому в качестве приоритетного может выбраться даже новый маршрут от R4, что, естественно, неразумно: мало того, что маршруты будут изучены неверно, так и трафик в итоге может заloopиться и не попадёт к точке назначения. В случае же полносвязной топологии и правила Split Horizon, такая ситуация исключается. R1, получив анонс от ISP1, передаёт его сразу всем своим соседям: R2, R3, R4. А те в свою очередь эти анонсы сохраняют, но передают только EBGP-партнёрам, но не IBGP, именно потому, что получены от IBGP-партнёра. То есть все BGP-маршрутизаторы имеют актуальную информацию и исключены петли. Причём, не имеет значение, подключены соседи напрямую или через промежуточные маршрутизаторы. Так, например, на вышеприведённой схеме R1 не имеет связи с R3 напрямую — они общаются через R2, однако это не мешает им установить TCP- сессию и поверх неё BGP. Понятие Split Horizon тут применяется в более широком смысле. Если в RIP это означало «не отсылать анонсы обратно в тот интерфейс, откуда они пришли», в IBGP это означает «не отсылать анонсы от IBGP-партнёров другим IBGP-партнёрам.» 2) Вторая тонкость — адрес Next Hop. В случае External BGP маршрутизатор при отправке анонса своему EBGP-соседу сначала меняет адрес Next-Hop на свой, а потом уже отсылает. Вполне логичное действие. Вот как анонс сети 103.0.0.0/22 выглядит при передаче от R5 к R1: Если же маршрутизатор передаёт анонс IBGP-соседу, то адрес Next-Hop не меняется. Хм. Непонятно. Почему? Это расходится с привычным пониманием DV-протокола маршрутизации. Вот тот же анонс при передаче от R1 r R2: Дело в том, что здесь понятие Next-Hop отличается от того, которое используется в IGP. В IBGP он сообщает о точке выхода из локальной AS. И тут возникает ещё один момент — важно, чтобы у получателя такого анонса был маршрут до Next-Hop — это первое, что проверяется при выборе лучшего маршрута. Если его не будет, то маршрут будет помещён в таблицу BGP, но его не будет в таблице маршрутизации. Такой процесс называется рекурсивной маршрутизацией. То есть, чтобы R2 мог отправлять пакеты ISP1 он должен знать, как добраться до адреса 101.0.0.1, который в данной схеме и является Next-Hop’ом для сети 103.0.0.0/22. В принципе, практически всё оборудование даёт возможность менять адрес Next-Hop на свой при передаче маршрута IBGP- соседу. На циске это делается командой «neighbor XYZ Next-Hop-self«. Позже вы увидите, как это применяется на деле. 3) Третий момент: если в EBGP обычно подразумевается прямое подключение двух соседей друг к другу, то в Internal BGP соседи могут быть подключены через несколько промежуточных устройств. На самом деле в EBGP также можно настраивать соседей, которые находятся за несколько хопов друг от друга и это на самом деле практикуется, например, в случае настройки Inter-AS Option C. Называется это дело MultiHop BGP и включается командой «neighbor XYZ ebgp-mul hop» в режиме конфигурации BGP. Но для IBGP это работает по умолчанию. Это позволяет устанавливать IBGP-партнёрство между Loopback- адресами. Делается это для того, чтобы не привязываться к физическим интерфейсам — в случае падения основного линка, BGP-сессия не прервётся, потому что лупбэк будет доступен через резервный. Это самая распространённая практика. При этом EBGP однако обычно устанавливается на линковых адресах, потому что как правило имеется только одно подключение и в случае его падения, всё равно Loopback будет не доступен. Да и настраивать ещё какую-то дополнительную маршрутизацию с провайдером не очень-то хочется. Пример конфигурации такого соседства: ===================== Задача № 1 Схема: В таком сценарии у нас два BGP-маршрутизатора R1 и R3, но они находятся в разных концах города и подключены через промежуточный маршрутизатор, на котором BGP не настроен. Условие: IBGP-сессия прекрасно установится, несмотря даже на то, что на промежуточном маршрутизаторе BGP не включен, и мы видим даже маршруты: Но где пинг? Подробности задачи тут. ===================== Вам нужно стараться избегать таких ситуаций, когда между IBGP- соседями будут не-BGP маршрутизаторы. Вообще-то есть механизм, позволяющий если не исправить, то по крайней мере предупредить такую ситуацию, — IGP Synchronization. Он не позволит добавить маршрут в таблицу, если точно такой же маршрут не известен через IGP. Это в какой-то мере гарантирует, что на промежуточных устройствах, независимо от того, активирован на них BGP или нет, будут нужные маршруты. Но я не знаю тех десперадо, которые решились включить IGP Synchronization. Во-первых, каким образом такие маршруты попадут в IGP? Только редистрибуцией. Теперь представьте себе, как Full View медленно наполняет LSDB OSPF, проникая в отдалённые уголки памяти и заставляя процессор до изнеможения выискивать кратчайшие маршруты. Хотите ли вы этого? А, во-вторых, вытекающее из «во-первых», по умолчанию, IGP- synchronization выключен практически на всех современных маршрутизаторах. ===================== Задача № 2 Между AS64504 и AS64509 появился линк, который связывает их напрямую. Обе сети использовали OSPF и без проблем объединили сеть в одно целое. Но, после проверки, оказалось, что трафик ходит через AS64500, а не напрямую от AS64504 к AS64509, через OSPF. Изменить конфигурацию BGP: — R7 должен использовать OSPF, если трафик идет в сеть 109.0.0.0/24 — R9 должен использовать OSPF, если трафик идет в сеть 104.0.0.0/24 Подробности задачи тут ===================== Практика BGP Давайте теперь вернёмся к сети linkmeup и попробуем запустить BGP в ней. Схема будет следующей (по клику более подробная с интерфейсами и IP-адресами): Как видите, мы её значительно видоизменили. Отказались от именования устройств по геолокации и функциям, изменили адресацию в угоду удобства запоминания и понимания. Маршрутизаторы будем называть RX, ликновая подсеть между маршрутизаторами RX и RY назначается следующим образом: 10.0.XY.0/24. Адреса соответственно 10.0.XY.X у RX и 10.0.XY.Y у RY. Сверху всё осталось также, как было в основной статье по BGP. А снизу добавился наш первый коммерческий клиент, который подключился по BGP. ===================== Задача № 3 Наш новый клиент AS 64504 подключен к нашей сети. И в дальнейшем планирует подключение к другому провайдеру и у него уже есть свой PI- блок адресов. Но на данном этапе, есть подключение только к нашей AS и поэтому клиент может использовать приватный номер AS. Задание: При анонсе сети клиента вышестоящим провайдерам, удалить номер приватной AS64504. Конфигурация и схема: базовые. Подробности задачи тут. ===================== EBGP Я думаю, не стоит останавливаться на настройке и работе EBGP — мы сделали это в прошлой статье. Просто для примера приведём конфигурацию сессии с новым клиентом: R4 interface FastEthernet1/0 ip address 100.0.0.5 255.255.255.252 router bgp 64500 network 100.0.0.0 mask 255.255.254.0 neighbor 100.0.0.6 remote-as 64504 R7 interface Loopback1 ip address 130.0.0.1 255.255.255.255 ! interface FastEthernet0/0 ip address 100.0.0.6 255.255.255.252 ! router bgp 64504 network 130.0.0.0 mask 255.255.255.0 neighbor 100.0.0.5 remote-as 64500 Тут всё просто и понятно, после настройки всех внешних соседей мы будем иметь такую ситуацию: На остальных устройствах Каждый BGP маршрутизатор знает только о тех сетях, которые получены им непосредственно от EBGP-соседа. IBGP Теперь обратимся к настройке маршрутизаторов нашей AS с точки зрения IBGP. Во-первых, как мы говорили ранее, IBGP обычно устанавливается между Loopback-интерфейсами для повышения доступности, поэтому в первую очередь создадим их: На всех маршрутизаторах на интерфейсе Loopback0 настраиваем IP-адрес X.X.X.X, где Х — номер маршрутизатора (это исключительно для примера и не вздумайте такое делать на реальной сети): R1 interface Loopback0 ip address 1.1.1.1 255.255.255.255 R2 interface Loopback0 ip address 2.2.2.2 255.255.255.255 R3 interface Loopback0 ip address 3.3.3.3 255.255.255.255 R4 interface Loopback0 ip address 4.4.4.4 255.255.255.255 Они станут Router ID и для OSPF и для BGP. Кстати, об OSPF. Как правило, IBGP «натягивается» поверх существующего на сети IGP. IGP обеспечивает связность всех маршрутизаторов между собой по IP, быструю реакцию на изменения в топологии и перенос маршрутной информации о внутренних сетях. Настройка внутренней маршрутизации. OSPF Собственно к этому и перейдём. Наша задача, чтобы все знали обо всех линковых подсетях, адресах Loopback-интерфейсов и, естественно, о наших белых адресах. Конфигурация OSPF: R1 router ospf 1 network 1.1.1.1 0.0.0.0 area 0 network 10.0.0.0 0.255.255.255 area 0 network 100.0.0.0 0.0.1.255 area 0 R2 router ospf 1 network 2.2.2.2 0.0.0.0 area 0 network 10.0.0.0 0.255.255.255 area 0 network 100.0.0.0 0.0.1.255 area 0 R3 router ospf 1 network 3.3.3.3 0.0.0.0 area 0 network 10.0.0.0 0.255.255.255 area 0 network 100.0.0.0 0.0.1.255 area 0 R4 router ospf 1 network 4.4.4.4 0.0.0.0 area 0 network 10.0.0.0 0.255.255.255 area 0 network 100.0.0.0 0.0.1.255 area 0 После этого появляется связность со всеми Loopback-адресами. Настраиваем BGP На каждом узле нужно настроить всех соседей вручную: R1 router bgp 64500 network 100.0.0.0 mask 255.255.254.0 neighbor 2.2.2.2 remote-as 64500 neighbor 2.2.2.2 update-source Loopback0 neighbor 3.3.3.3 remote-as 64500 neighbor 3.3.3.3 update-source Loopback0 neighbor 4.4.4.4 remote-as 64500 neighbor 4.4.4.4 update-source Loopback0 Команда вида neighbor 2.2.2.2 remote-as 64500 объявляет соседа и сообщает, что он находится в AS 64500, BGP понимает, что это та же AS, в которой он сам работает и далее считает 2.2.2.2 своим IBGP-партнёром. Команда вида neighbor 2.2.2.2 update-source Loopback0 сообщает, что соединение будет устанавливаться с адреса интерфейса Loopback. Дело в том, что на другой стороне (на 2.2.2.2) сосед настроен, как 1.1.1.1 и именно с этого адреса ждёт все BGP-сообщения. Такую настройку применяем на всех узлах нашей AS: 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 3.3.3.3 remote-as 64500 neighbor 3.3.3.3 update-source Loopback0 neighbor 4.4.4.4 remote-as 64500 neighbor 4.4.4.4 update-source Loopback0 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 2.2.2.2 remote-as 64500 neighbor 2.2.2.2 update-source Loopback0 neighbor 4.4.4.4 remote-as 64500 neighbor 4.4.4.4 update-source Loopback0 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 2.2.2.2 remote-as 64500 neighbor 2.2.2.2 update-source Loopback0 neighbor 3.3.3.3 remote-as 64500 neighbor 3.3.3.3 update-source Loopback0 Сейчас мы можем проверить, что отношения соседства установились благополучно Все маршруты есть в нашей таблице BGP. Сеть 130.0.0.0/24 видно на R1: Сеть 103.0.0.0/22 видно на R4: Пора проверить сквозной пинг c R7 (нашего клиента) в Интернет (103.0.0.1)? Приехали. Не будем долго мучить читателя и сразу посмотрим в таблицу маршрутизации, R4. А на R7 при этом: А? Где мои маршруты? Где все мои маршруты? R4 ничего не знает про сети Балаган-Телекома, Филькина Сертификата, Интернета, соответственно нет их и на R7. Помните, мы выше говорили про Next-Hop? Мол, он не меняется при передаче по IBGP? Обратите внимание на Next-Hop полученных R4 маршрутов: Несмотря на то, что они пришли на R4 от R1 и R2, адреса Next-Hop на них стоят R5 и R6 — то есть не менялись. Это значит, что трафик в сеть 103.0.0.0/22 R4 должен отправить на адрес 101.0.0.1, ну, либо на 102.0.0.1. Где они в таблице маршрутизации? Нету их в таблице маршрутизации. Ну, и это естественно — откуда им там взяться. Для решения этой проблемы у нас есть 3 пути: 1) Настроить статические маршруты до этих адресов — то ещё удовольствие, даже если это шлюз последней надежды. 2) Добавить эти интерфейсы (в сторону провайдеров) в домен IGP- маршрутизации. Тоже вариант, но, как известно, внешние сети не рекомендуется добавлять в IGP. 3) Менять адрес Next-Hop при передаче IBGP-соседям. Красиво и масштабируемо. А ситуации, которая нам помешает это реализовать, просто не может быть. В итоге добавляем в BGP ещё такую команду: neghbor 2.2.2.2 Next-Hop-self. Для каждого соседа, на каждом узле. После этого мы видим следующую ситуацию, А уж, как добраться до адреса 1.1.1.1 — мы знаем благодаря OSPF: Как видите в таблице R7 уже появилась все интересные нам сети. Теперь пинг успешной проходит: Очень простой вопрос: откуда такие гигантские задержки в трассировке? А ещё часто и такая ситуация бывает: Конфигурация устройств ===================== Задача № 4 Необходимо настроить такие правила работы с соседними AS: — от всех соседних AS принимаются префиксы только если в них количество автономных систем в пути не более 10 (в реальной жизни порядок этого значения может быть около 100). — все префиксы, которые принимаются от клиентов, должны быть с маской не более 24 бит. Конфигурация и схема: базовые. Подробности задачи тут. ===================== Что мы можем улучшить? Разумеется, процесс настройки BGP. Всё-таки это трудозатраты — сделать весьма похожие настройки на каждом узле. Для упрощения вводится понятие peer-group, которая исходя из названия позволяет объединять соседей в группы и одной командой задавать нужные параметры сразу всем. Дабы не быть голословными, внедрим это на нашей сети: 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 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 AS64500 peer-group создаёт группу соседей AS64500. Команда neighbor AS64500 remote-as 64500 сообщает, что все соседи находятся в AS 64500. Команда neighbor AS64500 update-source Loopback0 указывает, что со всеми соседями соединение будет устанавливаться с адреса Loopback-интрефейса. Команда neighbor AS64500 Next-Hop-self заставляет маршрутизатор менять адрес Next-Hop на свой при передаче анонсов всем соседям. Дальше, собственно, мы добавляем соседей в эту группу. Причём мы можем запросто копировать команды конфигурации группы соседей на другие маршрутизаторы, меняя только адреса соседей. Пара замечаний по Peer-group: 1) Для всех участников группы политики должны быть идентичны. 2) На самом деле cisco уже давно использует динамические Update-группы. Это позволяет сэкономить ресурсы процессора, так как обработка проводится не по разу на каждого члена группы, а один раз на всю группу. Фактические Peer-группы только облегчают конфигурацию, а оптимизация отдана на откуп Update-групп. Наверняка, у молодых зелёных инженеров возник вопрос: почему нельзя информацию про публичные адреса передавать по IBGP? Он же, вроде бы, для этого и предназначен? И даже более общий вопрос, почему нельзя обойтись вообще одним BGP, без OSPF или IS-IS, например? (Нет, серьёзно, на форумах иногда вскипают холивары на тему BGP vs OSPF). Ну, по сути ведь тоже протокол маршрутизации — какая разница, передавать информацию между AS или между маршрутизаторами — есть же Internal BGP. На это я хочу сказать, что достаточно вам будет поработать немного с BGP на реальной сети, чтобы понять всю безумность такой затеи. Самое главное препятствие |