Принципы маршрутизации в Internet. Самое полное описание протокола BGP 4 - Сэм Хелеби

Любой маршрут между подсистемами AS имеет длину 0. Посмотрим, как двумя способами получаются сведения о префиксе 192.68.222.0/24: через внутренний маршрут (65060) 2 и через внешний маршрут 1 2. Длина внутреннего маршрута (65060) 2 считается меньшей, так как подсистемы AS при вычислении длины маршрута не учитываются. Именно поэтому был выбран внутренний маршрут.

Листинг 12.81. Конфедерации (таблица BGP-маршрутов на маршрутизаторе

RTA)

В таблице BGP на маршрутизаторе RTF, представленной в листинге 12.82, все маршруты от подсистемы AS65050 считаются внешними маршрутами конфедерации (внешние конфедераты). Внутри конфедерации решение принимается на основе следующих положений: маршруты EBGP более предпочтительны, чем внешние конфедераты, которые, в свою очередь, более предпочтительны, чем внутренние маршруты.

Листинг 12.82. Конфедерации (BGP-таблица на маршрутизаторе RTA)

RTF#show ip bgp 172.16.220.0

BGP routing table entry for 172.16.220.0/24, version 22 Paths: (1 available, best #1, advertised over IBGP)

(65050)

from 172.16.50.2 (172.16.112.1)

Origin IGP, metric 0, localpref 100, valid, confed-external, best

Управление маршрутами и аннулирование содержимого кэша

Традиционным требованием в протоколе BGP был сброс TCP-соединения между взаимодействующими узлами для того, чтобы изменения, внесенные в правила маршрутизации возымели действие (clear ip bgp [* / address peer-group]). При сбрасывании сеансов подобным образом фаза переговоров повторяется с самого начала, при этом аннулируется все содержимое кэша для пересылки IP-пакетов, что существенно влияет на функционирование сети.

Основные причины этого, как уже отмечалось в главе 6, заключаются в том, что маршруты, сведения о которых получены от других узлов, помешаются в базу Adj-RIB-In. Затем эта информация передается входным правилам маршрутизации, соответствующим образом модифицируется и передается процессу принятия решения в BGP. Так как

немодифицированная копия маршрута (которая изначально хранится в Adj-RIB-In) обычно недоступна, но требуется для вступления в действие новых правил маршрутизации, то можно поступить следующим образом.

1.Источник BGP-маршрута можно вручную заставить повторить сведения о маршруте.

2.Может произойти полный сброс сеанса TCP.

3.Чтобы сохранить данные из Adj-RIB-In в памяти, можно воспользоваться мягкой перенастройкой (soft reconfiguration) BGP.

4.Чтобы запросить удаленную сторону о повторе ее Adj-RIB-Out, можно использовать

обновление BGP-маршрутов (BGP Route Refresh).

Что касается первого исхода, то маловероятно, что в реальной жизни вы будете иметь доступ к маршрутизатору, который сгенерировал исходный маршрут. Второй подход есть проявление грубой силы, что повлечет за собой непредсказуемые последствия, повышающие нестабильность сети. Мягкая перенастройка — очень хороший и элегантный способ решения проблемы, но он требует большого количества памяти. Обновление маршрутов BGP — относительно новое решение, которое со временем будет самым эффективным. Ниже мы обсудим варианты 3 и 4 более подробно.

Мягкая перенастройка BGP

Мягкая перенастройка (soft reconfiguration) BGP — один из методов, позволяющих настройку и введение в действие правил маршрутизации без сброса TCP-сеанса. Это позволяет применять новые правила маршрутизации практически незаметно для сети. Мягкая перенастройка может применяться двумя путями — по входящей и исходящей базам маршрутной информации. Для этого используется следующая команда EXEC:

clear ip bgp [* / address / peer-group] [soft [in\out]]

Мягкая перенастройка по информационной базе исходящих маршрутов

Всегда при использовании мягкой перенастройки по информационной базе исходящих маршрутов новые правила маршрутизации автоматически вступают в силу и генерируются соответствующие обновления маршрутов (из базы Adj-RIB-Out). Дополнительных ресурсов памяти этот тип мягкой перенастройки не требует. Для осуществления настройки выполняется следующая команда EXEC:

clear ip bgp [* / address / peer-group] soft out

Мягкая перенастройка по информационной базе входящих маршрутов

Мягкая перенастройка по информационной базе входящих маршрутов проводится немного сложнее. Все входящие обновления маршрутов (из Adj-RIB-In) от заданного узла хранятся в памяти без изменений. Когда вводятся новые правила маршрутизации, то база Adj-RIB-In, которая находится в памяти просто еще раз передается для обработки с помощью входных правил маршрутизации. Для этого используется дополнительная субкоманда:

neighbor {address / peer-group} soft-reconfiguration inbound

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

clear ip bgp [* / address / peer-group] soft in

Чтобы избежать излишней нагрузки на память, тот же результат может быть

достигнут и путем использования мягкой перенастройки по информационной базе исходящих маршрутов, но на другом конце соединения, что также вызовет повторное объявление базы Adj-RIB-Out.

Если параметр in/out не указан (clear ip bgp [* | address | peer-group] soft), то выполняется мягкая перенастройка и по входящим, и по исходящим базам маршрутной информации.

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

Опираясь на схему, приведенную в рис. 12.14, рассмотрим, как сконфигурирован маршрутизатор RTA, посылающий сообщения об обновлении маршрутов на RTC с метрикой 5000 (листинг 12.83).

Листинг 12.83. Мягкая перенастройка по информационной базе входящих маршрутов (конфигурация маршрутизатора RTA)

route-map setmetric permit 10 set metric 5000

Обратите внимание на команду neighbor 172.16.20.1 soft-reconfiguration inbound в

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

Чтобы новые правила маршрутизации вступили в силу, необходимо сбросить BGPсеанс между двумя маршрутизаторами, как это показано в листинге 12.84.

Листинг 12.84. Мягкая перенастройка по информационной базе входящих маршрутов (сброс BGP-сеанса между двумя маршрутизаторами)

RTA#clear ip bgp 172.16.20.1

BGP: 172.16.20.1 reset requested BGP: no valid path for 192.68.11.0/24 BGP: 172.16.20.1 reset by Ox27B740

BGP: 172.16.20.1 went from Established to Idle

BGP: nettable_walker 192.68.11.0/255.255.255.0 no best path selected BGP: 172.16.20.1 went from Idle to Active

BGP: 172.16.70.2 computing updates, neighbor version 21, table version 23, starting at 0.0.0.0 BGP: 172.16.70.2 send UPDATE 192.68.11.0/24 - unreachable

BGP: 172.16.70.2 1 updates enqueued (average=27, maximum=27)

BGP: 172.16.70.2 update run completed, ran for Oms, neighbor version 21, start version 23, throttled to 23, check point net 0.0.0.0

BGP: scanning routing tables BGP 172.16.20.1 went from Active to OpenSent BGP: 172.16.20.1 went from OpenSent to OpenConfirm

BGP: 172.16.20.1 went from OpenConfirm to Established

BGP: 172.16.20.1 computing updates, neighbor version 0, table version 23, starting at 0.0.0.0 BGP: 172.16.20.1 send UPDATE 172.16.25.0/24, next 172.16.20.2, metric 5000, path 3

BGP: 172.16.20.1 send UPDATE 172.16.30.0/24, next 172.16.20.2, path (65060)

BGP: 172.16.20.1 send UPDATE 172.16.50.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.60.0/24, next 172.16.20.2, path (65060)

BGP: 172.16.20.1 send UPDATE 172.16.70.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.90.0/24, next 172.16.20.2, path (65060)

BGP: 172.16.20.1 send UPDATE 172.16.65.0/26, next 172.16.20.2, path (65060) BGP: 172.16.20.1 send UPDATE 172.16.112.0/24, next 172.16.20.2, path

BGP: 172.16.20.1 send UPDATE 172.16.220.0/24, next 172.16.20.2, path

BGP: 172.16.20.1 send UPDATE 192.68.222.0/24, next 172.16.20.2, metric 5000, path 3 2 BGP: 172.16.20.1 4 updates enqueued (average=58, maximum=68) BGP: 172.16.20.1 update run

completed, ran for 24ms, neighbor version 0, start version 23, throttled to 23, check point net 0.0.0.0

BGP: 172.16.20.1 rev UPDATE about 192.68.11.0/24, next hop 172.16.20.1, path 1 metric 2000 BGP: 172.16.20.1 rev UPDATE about 192.68.222.0/24, next hop 172.16.20.1, path 1 2 metric 2000 BGP: 172.16.20.1 rev UPDATE about 172.16.25.0/24 - denied

BGP: 172.16.20.1 rev UPDATE about 172.16.30.0/24 - denied BGP: 172.16.20.1 rev UPDATE about 172.16.50.0/24 - denied BGP: 172.16.20.1 rev UPDATE about 172.16.60.0/24 - denied BGP: 172.16.20.1 rev UPDATE about 172.16.70.0/24 - denied BGP: 172.16.20.1 rev UPDATE about 172.16.90.0/24 - denied BGP: 172.16.20.1 rev UPDATE about 172.16.65.0/26 - denied BGP: 172.16.20.1 rev UPDATE about 172.16.112.0/24 - denied BGP: 172.16.20.1 rev UPDATE about 172.16.220.0/24 - denied

BGP: nettable_walker 192.68.11.0/255.255.255.0 calling revise_route BGP: revise route installing 192.68.11.0/255.255.255.0 -> 172.16.20.1

BGP: 172.16.70.2 computing updates, neighbor version 23, table version 24, starting at 0.0.0.0 BGP: NEXT_HOP part 1 net 192.68.11.0/24, neigh 172.16.70.2, next 172.16.20.1

BGP: 172.16.70.2 send UPDATE 192.68.11,0/24, next 172.16.20.1, metric 2000, path 1 BGP: 172.16.70.2 1 updates enqueued (average=59, maximum=59)

BGP: 172.16.70.2 update run completed, ran for 4ms, neighbor version 23, start version 24, throttled to 24, check point net 0.0.0.0

BGP: 172.16.20.1 rev UPDATE about 172.16.25.0/24 •- withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.30.0/24 •- withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.50.0/24 •- withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.60.0/24 •- withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.70.0/24 •- withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.90.0/24 •- withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.65.0/26 -- withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.112.0/24 - withdrawn BGP: 172.16.20.1 rev UPDATE about 172.16.220.0/24 - withdrawn

BGP: 172.16.20.1 computing updates, neighbor version 23, table version 24, starting at 0.0.0.0 BGP: 172.16.20.1 update run completed, ran for Oms, neighbor version 23, start version 24, throttled to 24, check point net 0.0.0.0

BGP: scanning routing tables

Как видно из листинга 12.84, при сбросе TCP-сеанса между двумя маршрутизаторами ведется обмен огромными объемами информации, и сеанс начинает повторно устанавливаться с самого начала.

Примечание

Подобная нагрузка на маршрутизатор также будет заметна, если вы просмотрите нагрузку на процессор или текущую информацию о BGP с помощью команд show process cpu или show ip bgp sum. Вы сможете увидеть реальную нагрузку на процессор маршрутизатора и изменения в BGP-таблице, происходящие с маршрутами. Кроме того, вы сможете наблюдать активный обмен маршрутной информацией со всеми взаимодействующими узлами (это происходит обновление маршрутных таблиц).

Далее в отчете о работе системы вы увидите, что BGP-сеанс сброшен, затем выбор взаимодействующего узла переходит из состояния ожидания в фазу "Соединение установлено", после чего происходит обмен информацией об обновлении маршрутов.

В листинге 12.85 показан тот же самый сброс сеанса, но уже с использованием мягкой перенастройки. Обратите внимание, что метрика 5000 посылается без сброса сеанса BGP, и общая нагрузка на маршрутизатор намного ниже.

Листинг 12.85. Мягкая перенастройка по информационной базе входящих

маршрутов (сброс BGP-сеанса между двумя маршрутизаторами с применением мягкой перенастройки)

RTA#clear ip bgp 172.16.29.1 soft out

BGP: start outbound soft reconfiguration for 172.16.20.1

BGP: 172.16.20.1 computing updates, neighbor version 0, table version 24, starting at 0.0.0.0 BGP: 172.16.20.1 send UPDATE 172.16.25.0/24, next 172.16.20.2, metric 5000, path 3

BGP: 172.16.20.1 send UPDATE 172.16.30.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.50.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.60.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.70.0/24, next 172.16,20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.90.0/24, next 172.16.20.2, netric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.65.0/26, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.112.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.220.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 192.68.11.0/24 — unreachable

BGP: 172.16.20.1 send UPDATE 192.68.222.0/24, next 172.16.20.2, metric 5000, path 3 2 BGP: 172.16.20.1 5 updates enqueued (average=52, maximum=68)

BGP: 172.16.20.1 update run completed, ran for 24ras, neighbor version 0, start version 24, throttled to 24, check point net 0,-0.0.0

BGP: scanning routing tables

Обновление BGP-маршрутов

Функция обновления BGP-маршрутов (BGP Route Refresh) входит в состав возможностей протокола BGP (которые мы обсуждали в главе 5). При установлении соединения по протоколу BGP взаимодействующие узлы объявляют о поддержке функции обновления маршрутов. Если они поддерживают эту функцию, то могут динамически запрашивать удаленный узел о повторном объявлении его базы Adj-RIB-Out (что обычно происходит и при выполнении мягкой перенастройки по информационной базе исходящих маршрутов). Так как при этом для хранения информации дополнительной памяти не требуется, этот способ более эффективен, чем мягкая перенастройка, и не вызывает дополнительных колебаний маршрутов, как при сбросе BGP-сеанса. Когда запрашивающая сторона получает базу Adj-RIB-Out, то передает ее входным правилам маршрутизации (и новым правилам маршрутизации).

Из листинга 12.86 видно, что поддержка функции обновления маршрутов определяется путем проверки выражения Neighbor capabilities в результате выполнения команды show ip bgp neighbor x.x.x.x.

Листинг 12.86. Подтверждение о выполнении обновления BGP-маршрутов

R1#show ip bgp n 1.1.2.2

BGP neighbor is 1.1.2.2, remote AS 2, external link BGP version 4, remote router ID 3.3.3.1

BGP state = Established, up for 2wOd

Last read 00:00:15, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities:

Route refresh: advertised and received

Address family IPv4 Unicast: advertised and received Received 20674 messages, 0 notifications, 0 in queue Sent 20675 messages, 0 notifications, 0 in queue Route refresh request: received 1, sent 2

Minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast

BGP table version 6, neighbor version 6 Index 1, Offset 0, Mask 0x2

NEXT_HOP is always this router

Community attribute sent со this neighbor 1 accepted prefixes consume 36 bytes

Prefix advertised 4, suppressed 0, withdrawn 0

Connections established 1; dropped 0 Last reset never

Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 1.1.2.1, Local port: 179

Foreign host: 1.1.2.2, Foreign port: 11000

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is Ox49ED7420):

SRTT: 301 ms, RTTO: 621 ms, RTV: 9 ms, KRTT: 0 ms minRTT: 4 ms, maxRTT: 600 ms, ACK hold: 200 ms Flags: passive open, nagle, gen tcbs

Datagrams (max data segment is 1460 bytes):

Rcvd: 39791 (out of order: 0), with data: 20674, total data bytes: 392861 Sent: 40473 (retransmit: 0), with data: 20674, total data bytes: 392914

Как видите, обновление маршрутов поддерживается только одной стороной. Это видно из записи Route Refresh, где указано количество объявленных (advertised) и/или принятых маршрутов (received).

В листинге 12.87 показано, как запросить удаленный узел о повторном объявлении его базы Adj-RIB-Out.

Листинг 12.87. Принуждение удаленного узла к повторному объявлению базы

Adj-RIB-Out

rl# clear ip bgp 1.1.2.2 soft in rl#

2wOd: BGP: 1.1.2.2 sending REFRESH^REQ for afi/safi: 1/1

2wOd: BGP: 1.1.2.2 send message type 128, length (incl. header) 23 2wOd: BGP: 1.1.2.2 send message type 4, length {incl. header) 19 2wOd: BGP: 1.1.2.2 rev message type 4, length (excl. header) 0

Таким образом вы посылаете взаимодействующему узлу запрос на обновление маршрутов и на повторное объявление базы Adj-RIB-Out.

Из листинга 12.86, где представлены результаты выполнения команды show ip bgp neighbor, видно, что существует также несколько счетчиков, которые фиксируют количество запросов на обновление маршрутов, поступивших и переданных узлом.

Организация работы маршрутизатора в режиме фильтра исходящих BGPмаршрутов

Функция фильтра исходящих BGP-маршрутов (Outbound Route Filter — ORF) также предусмотрена возможностями BGP (которые мы обсуждали в главе 5). Эта функция способствует сбережению ресурсов системы во время обработки обновлений BGPмаршрутов. Если функция ORF объявляется соседним узлом в течение фазы установки сеанса, то это означает, что локальный BGP-спикер разрешит соседнему узлу передавать сведения через его фильтр исходящих префиксов. После того как эти данные получены, локальный BGP-спикер устанавливает фильтр дополнительно к исходящим фильтрам, установленным ранее для соседнего узла. Использование ORF ВОР имеет неоспоримые преимущества.

Локальный BGP-спикер не тратит ресурсы на генерацию обновлений маршрутов, которые фильтруются соседним узлом.

Обновления маршрутов не занимают полезную полосу пропускания.

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

Примечание

Очень важно понимать, что применение фильтра BGP ORF может оказать очень серьезное влияние на работу сети. Например, если BGP-узел поспал глобальную таблицу маршрутов сети Internet (а это более 75000 маршрутов) на низкопроизводительный маршрутизатор, у которого недостаточно памяти, то это может привести к "зависанию" последнего вследствие недостатка памяти даже при установленных входных фильтрах. Кроме того, такая операция может вызвать перегрузку полосы пропускания на низкоскоросгных соединениях.

Функция фильтра исходящих запросов идеально подходит для провайдеров Internet, у которых развиты инструменты автоматизированной генерации фильтров маршрутов и маршрутизаторы связаны с огромным количеством BGP-узлов. Если фильтр сгенерирован и развернут на границе сети провайдера, его действие распространяется и на маршрутизатор клиента, что позволяет сберегать ресурсы и провайдера, и его клиента.

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

В результате того, что синтаксис для задания BGP ORF в различных версиях IOS очень сильно изменялся, мы решили включить в книгу Приложение В, "Фильтр исходящих маршрутов BGP", где содержатся все информационные бюллетени касающиеся поддержки BGP ORF в оборудовании Cisco. Дополнительную информацию о возможности использования этой функции вы можете найти в документации на вашу версию Cisco IOS.

Разгрузка маршрутов

Разгрузка маршрутов (route dampening) — это механизм, который используется в целях минимизации нестабильностей, вызванных колебаниями маршрутов в сети. Для управления процессом разгрузки маршрутов используется следующая команда:

bgp dampening [[route-map map-name] [half-life-time reuse-value sup-press-value maximum-suppress-time] ]

Ниже приведены диапазоны изменения различных параметров.

half-life-time — интервал времени от 1 до 45 минут. Значение по умолчанию — 15 минут.

reuse-value — от 1 до 20000. По умолчанию — 750.

suppress-value — от 1 до 20000. По умолчанию — 2000.

maximum-suppress-time — максимальное время, в течение которого может подавляться маршрут. Оно изменяется в диапазоне от 1 до 255. По умолчанию оно равно 4х half- life-time.

Карта маршрутов может быть связана с разгрузкой маршрутов для избирательной применения параметров разгрузки по заданному критерию. Примером такого критери; может служить определенный IP-маршрут, атрибуты AS_PATH или COMMUNITY.

На рис. 12.15 показаны две AS, AS1 и AS3. Маршрутизатор RTA в AS3 поддержи вает протокол 1BGP при взаимодействии с маршрутизатором RTG и протоко; EBGP — для работы с RTC в AS1. Информация, получаемая от AS3 по EBGP, переда ется протоколу OSPF в AS1.

Рис. 12.15. Разгрузка маршрутов

Допустим, что маршрутизатор RTC отмечает большое число колебании в сеп 172.16.220.0/24, сведения о которой поступают от AS3, что вызывает колебания в BGP н; самом RTC и, следовательно, в OSPF. При этом маршрут в сеть 172.16.220.0/24 постоянн< появляется и исчезает из маршрутной таблицы маршрутизатора RTH. Чтобы исправит положение, на RTC применяется разгрузка BGP-маршрутов с использованием картъ маршрутов, благодаря чему разгружается только маршрут 172.16.220.0/24. В листингах 12.8; и 12.89 приведены конфигурации маршрутизаторов RTG и RTAjuw этого случая.

Листинг 12.88. Разгрузка маршрутов (конфигурация маршрутизатора RTG)

router bgp 3

no synchronization

network 172.16.112.0 mask 255.255.255.0 neighbor 172.16.70.1 remote-as 3

no auto-summary

Листинг 12.89. Разгрузка маршрутов (конфигурация маршрутизатора RTA)

router bgp 3

no synchronization

network 172.16.220.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0

no auto-summary

Итак, маршрутизатор RTC взаимодействует по протоколу EBGP с RTA и по IBGP —

с RTH. Все принимаемые маршруты RTC далее передает с помощью протокола OSPF по всей AS1. На этом маршрутизаторе используется карта маршрутов SELECTIVE_DAMPENING, с помощью которой параметры разгрузки применяются только к маршруту в сеть 172.16.220.0/24. Все остальные маршруты, такие как 172.16.112.0/24, разгружаться не будут.

В конфигурации маршрутизатора RTC, приведенной в листинге 12.90, задаются следующие параметры разгрузки.

•Интервал времени half-life-time — 20 минут.

•Повторное использование маршрута ограничено 950.

•Маршруты будут подавляться, если сумма штрафов превысит 2500.

•Маршрут может подавляться не более 80 минут.

Листинг 12.90. Разгрузка маршрутов (конфигурация маршрутизатора RTC)

router ospf 10 redistribute bgp 1 subnets

network 192.68.0.0 0.0.255.255 area 0

router bgp 1

bgp dampening route-map SELECTIVE_DAMPENING network 192.68.11.0

neighbor 172.16.20.2 remote-as 3 neighbor 192.68.6.1 remote-as 1 no auto-summary

access-list 1 permit 172.16.220.0 0.0.0.255

route-map SELECTIVEJDAMPENING permit 10 match ip address 1

set dampening 20 950 2500 80

route-map SELECTIVE_DAMPENING permit 20

Как видно из листинга 12.90, маршрутизатор RTC обрабатывает только колебания маршрута 172.16.220.0/24. Колебанием маршрута считается любое изменение информации о нем. В листинге 12.91 представлена BGP-таблица до колебания маршрута.

Листинг 12.91. Разгрузка маршрутов (BGP-таблица на маршрутизаторе RTC перед колебанием маршрута)

RTC#show ip bgp 172.16.220.0

BGP routing table entry for 172.16.220.0/24, version 326 Paths: (1 available, best #1, advertised over IBGP)

3

172.16.20.2 from 172.16.20.2 (172.16.220.1) Origin IGP, metric 0, valid, external, best

В листинге 12.92 показано состояние маршрута после колебания. Маршрут не используется и переведен в состояние history. По умолчанию маршруту задан штраф 1000, который уже "возмещен'1 в размере 997.

Листинг 12.92. Разгрузка маршрутов (BGP-таблица на маршрутизаторе RTC

после первого колебания маршрута)

В листинге 12.93 показано, как выглядит информация о маршруте после второго колебания (он снова возвращается в рабочее состояние). Здесь снова добавляется штраф 1000, и после его частичного погашения суммарная величина штрафа составляет 1454.

Листинг 12.93. Разгрузка маршрутов (BGP-таблица на маршрутизаторе RTC

после второго колебания маршрута)

172.16.20.2from 172.16.20.2 (172.16.220.1)

В листинге 12.94 показано состояние маршрута после четырех колебаний. Теперь величина штрафа составляет 2851, что превышает установленный лимит 2500. Теперь маршрут подавляется (разгружается) и не передается маршрутизатору RTH. Маршрут будет снова доступен для использования через 31 минуту и 40 секунд. В то же время штраф будет снижать величину интервала повторного использования до 950.

Листинг 12.94. Разгрузка маршрутов (BGP-таблица на маршрутизаторе ЯТС после четырех колебаний маршрута)

Листинг 12.95 отображает состояние маршрута после шести колебаний. Различие состоит в том, что время half-life-time здесь составляет уже 5 минут, а не 20 минут, А время maximum-suppress-time составляет 20, а не 80 минут. За более короткое время half-fife-time штраф будет возмещен намного быстрее, и маршрут может использоваться гораздо раньше. Обратите внимание, что интервал времени повторного использования теперь составляет всего 8 минут 10 секунд.

Листинг 12.95. Разгрузка маршрутов (BGP-таблица на маршрутизаторе RTC после шести колебаний маршрута)

Изменение настроек таймеров, управляющих разгрузкой, становится крайне необходимым, если администраторы не могут позволить долго отсутствовать тому или иному маршруту. Разгрузка маршрутов в BGP с помощью карт маршрутов представляет собой мощнейшее средство для избирательного подавления аномальных маршрутов, которое позволяет управление и настройку со стороны пользователя.

Забегая вперед

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

Протоколы маршрутизации, начиная от раннего EGP до последних версий BGP, подвергаются серьезным испытаниям, поскольку запросы постоянно растут. Протокол BGP также задумывался как простой протокол для внешней маршрутизации, но со временем превратился в стандарт де-факто, который по сути "склеивает" Internet в одну сеть. На самом деле все приемы и уловки, которые предлагаются в BGP, уже давно были использованы, но каждый день мы сталкиваемся с необходимостью реализации новых возможностей на его базе. В результате рождаются новые протоколы и новые технические приемы. Делают ли они