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

Традиционным требованием в протоколе 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)

router bgp  65050 no synchronization

bgp  confederation identifier 3

network  172.16.220.0 mask 255.255.255.0

network 172.16.70.0 mask 255.255.255.0

neighbor 172.16.20.1  remote-as  1

neighbor 172.16.20.1  soft-reconfiguration inbound neighbor 172.16.20.1  filter-list 10 out

neighbor   172.16.20.1   route-map setmetric out neighbor   172.16.70.2   remote-as   65050

no auto-summary

ip  as-path access-list 10  permit   A$ 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

Как видно из листинга 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         u                                    n                                    r                                    e                                    a           c                                                                                                                                                        h                                                                                                                                                        a                                                                                                                                                        b                                                                                                                                                        l                                                                                                                                                        e            

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

Источник: Сэм Хелеби, Денни Мак-Ферсон, Принципы маршрутизации в 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