Конфликт правил маршрутизации BGP с внутренними маршрутами по умолчанию

В зависимости от физической топологии AS и установленных правил маршрутизации BGP могут возникать определенные конфликтные ситуации. Так. трафик внутри AS. следующий согласно маршрутам по умолчанию протокола IGP на граничный BGP-маршрутизатор, может образовать петлю, если граничные BGP-маршрутизаторы имеют правила маршрутизации, протиBGPечащие правилам для протокола IGP, что в результате приведет к возвращению трафика в исходную точку.

В этом разделе мы рассмотрим ситуации, приводящие к образованию петель в маршрутизации, а также возможные пути решения этих проблем. Мы  рассмотрим следующие два случая.

·                           Маршруты по умолчанию внутри AS и их взаимодействие с правилами маршру

тизации BGP с использованием основного и резервного канала.

·                           Маршруты по умолчанию внутри AS и их взаимодействие с другими правилами маршрутизации BGP.

Маршруты по умолчанию внутри AS: правила маршрутизации BGP по основному и запасному маршруту

Рассмотрим вариант организации маршрутизации, представленный на рис. 8.2. Здесь AS1 подключается к сети Internet по двум каналам. На маршрутизаторе RTC, который находится в Сан-Франциско, поддерживается протокол внешнего граничного шлюза (Exterior Border Gateway Protocol — EBGP) с одним провайдером, в то же время в Нью-Йорке через маршрутизатор RTD организовано еще одно соединение также с использованием протокола EBGP. Внутри AS маршрутизаторы RTC и RTD общаются по протоколу IBGP. Однако, как видите, они не имеют между собой прямого физического соединения, т.е. весь трафик между RTC и RTD будет передаваться через маршрутизаторы RTA и RTB.

Рис. 8.2. Образование петли маршрутизации при использовании маршрутов по умолчанию

Предположим, что маршрутизаторы RTC и RTD принимают полные маршруты от провайдеров. Кроме того, они посылают в AS1 маршрут по умолчанию 0/0, который будет использоваться протоколом IGP. Также представим, что в AS1 требуется обеспечить схему работы с использованием основного и запасного канала, что позволяет выбрать в качестве основного канал ТЗ с провайдером в Нью-Йорке. Таким образом, для маршрутов, которые используют  канал  в  Нью-Йорке,  в  ASI  будут  устанавливаться  наивысшие  локальные предпочтения, что и позволит использовать его как основной. Канал Т1 с провайдером в Сан- Франциско будет использоваться как резервный для всего исходящего трафика, который приходит на маршрутизатор RTC. Тогда он будет направлен обратно на маршрутизатор RTD.

Маршрутизаторы RTA и RTB являются внутренними, и они не поддерживают работу по протоколу BGP. Эти маршрутизаторы обмениваются маршрутами между собой и другими маршрутизаторами  внутри AS посредством одного из  протоколов IGP. Они не могут работать с внешними маршрутами. Все, что они могут делать, — посылать трафик, сведения о пункте назначения которого неизвестны, согласно маршрутам по умолчанию в направлении  маршрутизаторов  RTC  или  RTD,  в  зависимости  от  того,  какой  из  этих

маршрутов будет иметь меньшую метрику IGP. Так, трафик из внешних сетей, попав на маршрутизатор RTA, будет направлен по умолчанию на RTC, a  трафик, пришедший на маршрутизатор RTB, будет возвращен на RTD.

Когда   маршрутизатор   RTC   принимает   какой-либо   трафик,   он   изменяет   его

траекторию в направлении маршрутизатора RTD, так как согласно оговоренным нами правилам работы по BGP для данной AS, канал с провайдером в Нью-Йорке является основным. Ввиду того что маршрутизатор RTC не имеет прямого соединения с RTD он посылает весь трафик на маршрутизатор RTA. Маршрутизатор RTA принимает трафик и … направляет его обратно на RTC! Как видите, мы получили петлю маршрутизации между RTA и RTC.

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

Вариант 1: управление метрикой IGP

В этом варианте мы попытаемся предотвратить образование петли, направляя весь

трафик для внешних узлов через маршрут по умолчанию в направлении маршрутизатора RTD. Это можно осуществить, заставив маршрутизатор RTC распространять маршрут по умолчанию 0/0 внутри AS с очень высокой метрикой, что сделает маршрут 0/0 от маршрутизатора RTD более коротким, а следовательно, и более привлекательным для любого внутреннего маршрутизатора. Трафик в этом случае ни при каких обстоятельствах не должен поступать на маршрутизатор RTC в поисках маршрута к неизвестному пункту назначения (на внешний узел), если только не выйдет из строя канал с провайдером в Нью- Йорке.

Вариант 2: IBGP-маршрут короче IGP-маршрута

Существование более короткого маршрута между IBGP-маршрутизаторами дает уверенность в том, что трафик не будет возвращен обратно на IGP-маршрутизаторы, чтобы попасть в пункт назначения. Это необходимо только в тех  случаях, если правила маршрутизации по BGP требуют перенаправлять трафик с одного BGP-маршрутизатора на другой. Подобные ситуации имеют место когда IBGP-маршрутизатор не имеет внешнего соединения, по которому он мог бы направить трафик. Если же у него есть  подобное внешнее соединение, то оно не используется в качестве наилучшего маршрута (см. случай с маршрутизатором RTC на рис. 8.2).

На схеме, представленной на рис. 8.2, избежать образования петли можно, если граничные маршрутизаторы RTC и RTD, которые поддерживают работу по протоколу IBGP, также совместно используют один и тот же физический сегмент, такой как канал связи. В таком случае трафик, поступающий от маршрутизатора RTA на RTC, будет направлен по физическому каналу (он не показан на рис. 8.2), который обеспечивает в данном случае более короткий прямой маршрут между маршрутизаторами RTC и RTD, а также вносит элемент избыточности, так как по нему будет проходить весь трафик в случае выхода из строя всех остальных каналов.

Вариант 3: поддержка BGP в транзитных маршрутизаторах

Поддержка   протокола   BGP   во   всех   транзитных   маршрутизаторах   позволяет

направлять трафик за пределы AS, как только он поступит на эти маршрутизаторы. Как показано на рис. 8.2, если бы маршрутизаторами RTA и RTB совместно с RTC и RTD поддерживался протокол IBGP, то для всего трафика, поступающего на эти маршрутизаторы, можно было бы элегантно определить подходящий маршрут за пределы сети. Хотя легче всего просто нагрузить маршрутизаторы RTA и RTB полными BGP-маршрутами, вы можете также реализовать обработку на этих маршрутизаторах частичных маршрутов и/или BGP- маршрутов по умолчанию, что потребует дополнительной конфигурации. Отметим, что, хотя AS1 может и не являться транзитной AS, маршрутизаторы RTA и RTB могут использоваться для обработки трафика между граничными маршрутизаторами. Внутренние IGP-маршруты могут использовать облако IBGP, чтобы выйти во внешний мир, как показано на рис. 8.2.

Вариант 4: кто и как генерирует маршрут по умолчанию?

В этом варианте избежать образования петли можно, если основной маршрутизатор генерирует IGP-маршрут по умолчанию, а второй маршрутизатор не делает этого. В этом случае маршрутизатор RTD будет генерировать IGP-маршрут по умолчанию 0/0, a RTC не будет. Тогда весь трафик будет следовать согласно маршруту по умолчанию на маршрутизатор RTD.

Однако такая схема работает только в нормальных условиях, а что делать, если основной канал или маршрутизатор выйдут из строя9 Если канал с провайдером в Нью- Йорке выйдет из строя, IGP-маршрутизаторы потеряют единственный маршрут по умолчанию 0/0. А так как маршрутизатор RTC не генерирует маршрута по умолчанию, то трафик, адресованный узлам за пределами AS, будет потерян, так как маршрутизаторы не

будут "знать" что с ним делать.

Идеальным решением в этом случае является анонсирование маршрута по умолчанию от RTC только тогда, когда канал в Нью-Йорке выходит из строя. Если канал в Нью-Йорке выходит из строя, то маршрутизатор RTD должен прекратить объявление IGP- маршрута по умолчанию, a RTC, наоборот, должен начать эту процедуру. Для реализации такого механизма маршрутизаторы должны принять на себя следующие обязательства.

·          BGP-маршрутизатор должен прекратить объявление IGP-маршрута по умолчанию, если его внешний канал выходит из строя. Это требование довольно легко реализовать, если в  IGP  поддерживается  преобразование  внешнего маршрута по умолчанию 0/0. Когда маршрут 0/0 прекращает свое существование, то IGP-маршрут по умолчанию также исчезает вместе с ним. Возможность преобразования и поведение маршрута по умолчанию зависит от протокола IGP, который вы используете, и от производителя конкретного сетевого оборудования. Так, например, способ преобразования в оборудовании компании Cisco может отличаться от способов, реализованных в устройствах других производителей.

·          BGP-маршрутизатор должен объявлять IGP-маршруг по умолчанию только в том случае, если маршрут по умолчанию будет использовать локальный внешний канал. Таким образом, это правило обязывает любой маршрутизатор прекратить генерирование маршрута по умолчанию, если маршрут по умолчанию, который он предпочитает использовать, приходит от другого маршрутизатора внутри AS, а не из другой AS. То есть, если второй маршрутизатор предпочитает использовать маршрут по умолчанию, поступивший от другого маршрутизатора внутри AS, то это означает, что основной канат исправен и для работы следует использовать именно его. Однако когда основной канал выходит из строя, второй маршрутизатор воспользуется  IGP-маршрутом по умолчанию из другой AS и самостоятельно объявит его. Эту ситуацию дня лучшего понимания лете рассмотреть на примере.

См. в главе 12 раздел "Установка маршрутов по умолчанию"

Следующие два примера подчеркивают отличия между маршрутами по умолчанию, сгенерированными протоколами RIP и OSPF на базе оборудования компании Cisco.

Маршрут по умолчанию, сгенерированный протоколом RIP

На рис. 8.3 маршрутизаторы RTC и RTD могут получить сведения о маршруте по умолчанию 0/0 или статически сконфигурировать его в направлении соответствующих узлов провайдеров. При нормальных условиях работы маршрутизатор RTD автоматически (или через управляемое преобразование) вставляет маршрут 0/0 в протокол RIP. Маршрутизатор RTC обнаруживает присутствие маршрута по умолчанию, поступающего от RTD, и прекращает генерировать свой собственный маршрут по умолчанию. Весь трафик направляется на маршрутизатор RTD.

В случае выхода из строя канала с провайдером в Нью-Йорке, маршрутизатор RTD

прекращает генерировать RIP-маршрут по умолчанию. Маршрутизатор RTC обнаруживает

отсутствие RIP-маршрута 0/0 и подставляет собственный маршрут по умолчанию. Обратите внимание, что RTC получает маршрут по умолчанию 0/0 посредством EBGP (от внешней сети, подключенной к этому маршрутизатору), RIP и, возможно, IBGP, если в течение IBGP- сеанса маршрутизатор RTD передает сведения о маршруте 0/0. Вследствие более высокого значения локального предпочтения маршрута через  RTD, маршрутизатор RTC выбирает IBGP-маршрут 0/0. Так как административная дистанция на RTC (200) больше, чем административная дистанция RIP, которая равна 120 (см. табл. 6.1), то будет выбираться RIP- маршрут по умолчанию 0/0 с меньшей административной дистанцией.

Рис. 8.3. Преобразование маршрута по умолчанию 0/0 в протоколе RIP

Маршрут по умолчанию, сгенерированный протоколом OSPF

Протокол OSPF ведет себя совершенно по-другому. BGP-маршрут 0/0 не может быть напрямую преобразован в  OSPF. В протоколе OSPF предусмотрены различные приемы, позволяющие в любое время сгенерировать маршрут 0/0 в OSPF, поэтому даже лучше, если обнаружено его присутствие в таблице IP-маршрутов. Теперь рассмотрим это все на примере, представленном на рис. 8.4.

Рис. 8.4. Преобразование маршрута по умолчанию 0/0 в протоколе OSPF

Маршрутизаторы RTD и RTC получают EBGP-маршрут 0/0 или самостоятельно статически указывают маршрут по умолчанию на узел провайдера. Если RTD и RTC сконфигурированы так, что маршрут по умолчанию вида 0/0 преобразуется для работы по OSPF при появлении в их маршрутных IP-таблицах, модель с использованием основного и резервного каналов больше не будет работать. Это происходит потому, что и RTD и RTC получают IBGP-маршрут 0/0 друг от друга. То есть маршрутизатор RTC всегда будет вставлять префикс 0/0 в OSPF, независимо от состояния канала с провайдером в Нью-Йорке. К тому же, в отличие от схемы  работы по протоколу RIP, маршрутизатор RTC будет игнорировать OSPF-маршрут по умолчанию, поступающий от RTD, так как он сконфигурирован самостоятельно генерировать собственный маршрут по умолчанию.

Чтобы    исправить    эту    ситуацию    необходимо    прибегнуть    к    дальнейшему

конфигурированию маршрутизаторов RTD и RTC. Их нужно настроить таким образом, чтобы они генерировали OSPF-маршрут 0/0, только если их собственный маршрут по умолчанию указывает на узел провайдера.

По существу, если маршрутизатор RTD среди других выбирает маршрут по умолчанию, который указывает на узел провайдера, то он преобразует его в OSPF-маршрут. Точно так же маршрутизатор RTC предпочитает маршрут по умолчанию, который указывает на узел его провайдера и преобразует маршрут 0/0 в OSPF-маршрут.

В подобной модели происходят следующие процессы.

·                       Нормальная работа обеспечивается, когда канал с провайдером в Нью-Йорке исправен.

·                       Маршрутизатор RTD предпочитает внешний маршрут по умолчанию  всем другим и преобразует маршрут 0/0 в OSPF-маршрут.

·                       Маршрутизатор RTC, работающий по EBGP (от своего провайдера), IBGP и OSPF получает маршрут по умолчанию 0/0. Он игнорирует маршрут по умолчанию, полученный по OSPF, как мы уже отмечали ранее.

·                       Маршрутизатор RTC использует маршрут 0/0, полученный от RTD no IBGP, так как последний имеет более высокое локальное предпочтение.

·                       Поскольку маршрут 0/0 получен маршрутизатором RTC не от провайдера, маршрутизатор не анонсирует никакого OSPF-маршрута по умолчанию.

·                       Если канал в Нью-Йорке выходит из строя, то маршрутизатор RTD прекращает получать маршрут 0/0 от своего провайдера, но продолжает принимать маршрут 0/0 по IBGP и генерировать его для OSPF, так как он не получен от провайдера.

·                       Маршрутизатор RTC прекращает получать маршрут 0/0 по IBGP и использует маршрут по умолчанию через своего провайдера. Затем, он начинает анонсировать маршрут по умолчанию 0/0 в протокол OSPF.

Источник: Сэм Хелеби, Денни Мак-Ферсон, Принципы маршрутизации в Internet, 2-е  издание.  : Пер. с англ. М. : Издательский дом «Вильямс», 2001. — 448 с. : ил. — Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100