Протокол IP : Протокол BGP

Используйте BGP "медленная одноранговая" функция для решения медленных одноранговых вопросов

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (21 апреля 2016) | Отзыв

Введение

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

Внесенный Люком Де Гееном, специалистом службы технической поддержки Cisco.

Общие сведения

Этот раздел предоставляет обзор медленной одноранговой функции и использование групп обновления.

Update Groups

Медленная одноранговая функция использована в группах обновления. Группа обновления является динамическим методом, который используется для группировки Одноранговых соединений по протоколу BGP с той же политикой ограничения исходящего трафика. Преимущество групп обновления - то, что групповая политика используется для форматирования сообщений однажды, и затем они реплицированы и переданы другим участникам группы. Этот метод более эффективен, чем потребность отформатировать Обновления BGP для каждого узла отдельно.

Если изменения исходящей политики, группы одноранговых узлов изменяются на группу обновления, когда внедрен этот метод. Группы обновления сформированы на Семейство адресов (AF).

Вот пример двух Одноранговых соединений по протоколу BGP в других группах обновления для индивидуальной рассылки IPv4 AF, но с той же группой обновления для VPNv4 AF:

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
 Has 1 member (* indicates the members currently being sent updates):
  10.1.3.4

BGP version 4 update-group 2, external, Address Family: IPv4 Unicast
 Has 1 member (* indicates the members currently being sent updates):
  10.1.2.3

R2#show ip bgp vpnv4 all update-group
BGP version 4 update-group 1, external, Address Family: VPNv4 Unicast
 Has 2 members (* indicates the members currently being sent updates):
  10.1.2.3        10.1.3.4

Группа обновления становится более эффективной как Одноранговые соединения по протоколу BGP номера, которые включены в увеличения группы обновления. Как правило, внутренний BGP (iBGP) узлы имеет ту же политику ограничения исходящего трафика. Для iBGP Рефлектор маршрута (RR) может иметь много равноправных объектов IBGP; таким образом это будет иметь многочисленные группы обновления. Маршрутизаторы Границы провайдера (PE) могут иметь много узлов подключенный по внешнему протоколу bgp (EBGP) к маршрутизаторам Порта заказчика Customer Edge (CE) в одной Действительной Передаче (VRF) / Передача Маршрутизации (VRF). Периферийные маршрутизаторы могут иметь многочисленные группы обновления также для равноправных информационных обменов с Маршрутизаторами CE на интерфейсах VRF.

Проблема

Медленный узел является узлом, который не может не отставать от скорости, на которой маршрутизатор генерирует сообщения Обновления BGP за длительный период времени (в заказе минут) в группе обновления. Причина для этого может быть персистентными сетевыми проблемами. Сетевые причины могли быть потерей пакета и/или загрузили ссылки или проблемы пропускной способности с сеансами BGP. Кроме того, Одноранговое соединение по протоколу BGP могло бы быть в большой степени загружено с точки зрения ЦП и не может обслужить TCP - подключение на требуемой скорости.

Медленные узлы влияют на согласование BGP завершенной группы обновления. Если одно Одноранговое соединение по протоколу BGP является медленным, оно заставляет всю группу обновления замедляться. Результат состоит в том, что другие элементы группы обновления будут иметь более медленную конвергенцию также. Поэтому вопрос должен быть решен.

Можно определить медленный узел и переместить его из группы обновления. Для выполнения этой задачи можно изменить политику ограничения исходящего трафика для того Однорангового соединения по протоколу BGP; однако, это - ручная задача. Необходимо сначала определить узел, который является медленным, и затем переместите его из группы обновления. Медленная одноранговая функция может сделать это автоматически, так, чтобы не требовалось никакое вмешательство пользователя.

Решение

Существует три части к медленной одноранговой функции:

  • Обнаружение медленного узла

  • Перемещение медленного узла в медленную группу обновления

  • Восстановление медленного узла (который кладет обратно восстановленный узел его исходной группе обновления),

Эти процессы описаны более подробно в разделах, которые придерживаются.

Обнаружение

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

Вот пример такого кэша группы обновления:

R2#show ip bgp replication

                                                                   Current   Next
Index Members         Leader      MsgFmt   MsgRepl    Csize   Version Version
   1       1       10.1.1.1           0         0   0/100          6/0
   2       3       10.1.2.3           2         6   0/1000         6/0
   3       1       10.1.2.6           3         0   0/100          6/0

Размер кэша динамично вычислен и зависит от:

  • Количество узлов в группе обновления

  • Установленная системная память

  • Тип узлов в группе обновления

  • Тип AF

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

Для медленной одноранговой функции для определения медленного узла это обращается к меткам времени Обновления BGP и одноранговым параметрам TCP.

Медленное одноранговое обнаружение отключено по умолчанию. Для включения медленного однорангового обнаружения используйте один из этих методов:

  • Активируйте опцию для процесса BGP (может быть настроен от AF/VRF):
    bgp slow-peer detection [threshold <seconds>]

    [no] bgp slow-peer detection

    Примечание: Пороговое значение может расположиться между 120 и 3,600 секундами, и значение по умолчанию составляет 300 секунд.

  • Активируйте опцию на узел:
    neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection [threshold < seconds >]

    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection
  • Активируйте опцию через одноранговый шаблон политики:
    slow-peer detection [threshold < seconds >]

    [no] slow-peer detection

Когда медленный узел обнаружен, сообщение системного журнала, подобное этому, распечатано:

%BGP-5-SLOWPEER_DETECT: Neighbor IPv4 Unicast 10.1.6.7 has been detected
as a slow peer.

Можно ввести эти команды показа для просмотра медленных узлов:

  • медленный show ip bgp summary

  • медленный show ip bgp neighbors

  • медленная сводка show ip bgp update-group

Когда медленное ключевое слово используется, вот выходные данные команды show в качестве примера:

R2#show ip bgp update-group summary slow
Summary for Update-group 1, Address Family IPv4 Unicast
Summary for Update-group 2, Address Family IPv4 Unicast
Summary for Update-group 3, Address Family IPv4 Unicast
Summary for Update-group 4, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 966013, main routing table version 966013
BGP main update table version 966013
50000 network entries using 6050000 bytes of memory
50000 path entries using 2600000 bytes of memory
5001/5000 BGP path/bestpath attribute entries using 700140 bytes of memory
5000 BGP AS-PATH entries using 183632 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9533772 total bytes of memory
BGP activity 208847/158847 prefixes, 508006/458006 paths, scan interval 60 secs
Neighbor       V   AS MsgRcvd MsgSent  TblVer InQ OutQ Up/Down State/PfxRcd
10.1.6.7       4    7    165  50309       0   0 100 00:10:35       0

Как показано в выходных данных, узел 10.1.6.7 является медленным узлом для индивидуальной рассылки IPv4 AF. Другой AFS не показывает медленных узлов.

Чтобы проверить, выполняется ли таймер обнаружения в настоящее время и его значение, введите эту команду:

R2#show ip bgp update-group
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
 BGP Update version : 116013/0, messages 164 queue 164, not converged
 Private AS number removed from updates to this neighbor
 Update messages formatted 5948, replicated 11589
 Number of NLRIs in the update sent: max 249, min 1
 Minimum time between advertisement runs is 30 seconds
Slow-peer detection timer (expires in 111 seconds)
 Has 3 members (* indicates the members currently being sent updates):
  10.1.4.5        10.1.5.6        10.1.6.7       

Как показано в примере выходных данных, таймер обнаружения запустился. Когда кэш группы обновления полон, таймер обнаружения запускается.

В данном примере вы видите, что медленный узел обнаружен, но это только перемещается из группы обновления после того, как истекает медленный одноранговый таймер обнаружения:

R2#show ip bgp update-group

BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
 BGP Update version : 516013/566013, messages 357 queue 357, not converged
 Private AS number removed from updates to this neighbor
 Update messages formatted 27044, replicated 53645
 Number of NLRIs in the update sent: max 249, min 0
 Minimum time between advertisement runs is 30 seconds
 Slow-peer detection timer (expires in 20 seconds)
 Has 3 members (* indicates the members currently being sent updates)
 (1 dynamically detected as slow):

 *10.1.4.5       *10.1.5.6        10.1.6.7

Медленная одноранговая идентификация

Если медленная одноранговая опция обнаружения не активирована, то необходимо определить медленный узел вручную. Во-первых, проверьте версию таблицы и очередь вывода узлов в группе обновления:

R2#show ip bgp update-group 3 summary
Summary for Update-group 3, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 552583, main routing table version 552583
BGP main update table version 552583
37870 network entries using 4582270 bytes of memory
37870 path entries using 1969240 bytes of memory
5002/3788 BGP path/bestpath attribute entries using 700280 bytes of memory
5001 BGP AS-PATH entries using 183656 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7435446 total bytes of memory
BGP activity 158847/108847 prefixes, 295876/258006 paths, scan interval 60 secs
Neighbor       V   AS MsgRcvd MsgSent  TblVer InQ OutQ Up/Down State/PfxRcd
10.1.4.5       4    5     77  26840  516013   0   0 01:07:12       0
10.1.5.6       4    6     69  26833  516013   0   0 01:00:30       0
10.1.6.7       4    7     79  26761  516013   0 194 00:45:42       0

В данном примере проверьте, догоняет ли версия таблицы (TblVer) узлов когда-нибудь основную версию таблицы BGP или является ли это всегда позади. Во-вторых, проверьте для одного или более узлов со значениями очереди очень высокой производительности. Вероятно, что это медленные узлы.

Когда вы просматриваете подозреваемое медленное Одноранговое соединение по протоколу BGP, рассматриваете эти вопросы (с обеих сторон сеанса BGP):

  • Когда была выполнена последняя запись?

  • Пакеты Keepalive в дросселе?

  • Очередь вывода высоко?

  • SRTT/RTTO высоко?

  • Количество повторно передает увеличение?

  • Есть ли, кто-либо помещенный в очередь повторно передает пакеты?

  • TCP, передают окно очень низко или нуль?

Например:

R2#show ip bgp neighbors 10.1.6.7
BGP neighbor is 10.1.6.7, remote AS 7, external link
Member of peer-group group3 for session parameters
 BGP version 4, remote router ID 10.1.6.7
 BGP state = Established, up for 00:56:09
 Last read 00:00:43, last write 00:00:17, hold time is 180, keepalive interval
is 60 seconds
 Keepalives are temporarily in throttle due to closed TCP window
 Neighbor capabilities:
   Route refresh: advertised and received(new)
   Address family IPv4 Unicast:
advertised and received
 Message statistics
   InQ depth is 0
   OutQ depth is 0   Partial message pending
                        Sent      Rcvd
   Opens:                 5         4
   Notifications:         0         0
   Updates:           29004         0
   Keepalives:            0      1426
   Route Refresh:         0         0
   Total:             30336      1431
 Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
 BGP table version 250001, neighbor version 200001/250001
 Output queue size : 410
 Index 3, Offset 0, Mask 0x8
 3 update-group member
 group3 peer-group member
 Inbound soft reconfiguration allowed
 Private AS number removed from updates to this neighbor
 Inbound path policy configured
 Route map for incoming advertisements is eBGP-in
                                Sent      Rcvd
 Prefix activity:              ----      ----
   Prefixes Current:           2596         0
   Prefixes Total:           102624         0
   Implicit Withdraw:            28         0
   Explicit Withdraw:        100000         0
   Used as bestpath:            n/a         0
   Used as multipath:           n/a         0
                                  Outbound   Inbound
 Local Policy Denied Prefixes:   --------   -------
   Total:                               0         0
 Maximum prefixes allowed 20000
 Threshold for warning message 80%, restart interval 300 min
 Number of NLRIs in the update sent: max 249, min 0
 Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
 Oldest update message was formatted: 00:02:24
 Address tracking is enabled, the RIB does have a route to 10.1.6.7
 Connections established 4; dropped 3
 Last reset 00:57:39, due to User reset
 Transport(tcp) path-mtu-discovery is enabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0      
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.6.2, Local port: 20298
Foreign host: 10.1.6.7, Foreign port: 179
Connection tableid (VRF): 0

Enqueued packets for retransmit: 15
, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x4A63D14):
Timer         Starts   Wakeups           Next
Retrans          697        29      0x4A6590C
TimeWait           0         0            0x0
AckHold           64        63            0x0
SendWnd            0         0            0x0
KeepAlive          0         0            0x0
GiveUp             0         0            0x0
PmtuAger         128       127      0x4A64CB7
DeadWait           0         0            0x0
Linger             0         0            0x0

iss: 130287252 snduna: 131516888 sndnxt: 131532233    sndwnd: 16384
irs: 1184181084 rcvnxt: 1184182346 rcvwnd:     15123 delrcvwnd:  1261

SRTT: 20122 ms, RTTO: 20440 ms, RTV: 318 ms, KRTT: 0 ms
minRTT: 20028 ms, maxRTT: 20796 ms, ACK hold: 200 ms
Status Flags: none
Option Flags: nagle, path mtu capable, higher precendence

Datagrams (max data segment is 1460 bytes):
Rcvd: 922 (out of order: 0), with data&colon; 65, total data bytes: 1261
Sent: 1463 (retransmit: 29 fastretransmit: 1),with data&colon; 1391, total
data bytes: 1245129

Перемещение

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

Перемещение без медленной одноранговой функции

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

Прежде чем медленная одноранговая функция была доступна, вы были обязаны определять медленный узел и затем перемещать его из группы обновления вручную. Это завершено с изменением к политике ограничения исходящего трафика того Однорангового соединения по протоколу BGP. Эта политика ограничения исходящего трафика должна быть другой, чем кто-либо другой, который используется, поскольку необходимо гарантировать, что медленный узел не перемещается к другой группе обновления, которая в настоящее время существует (и переместите проблему к той группе обновления). Лучшее изменение, которое можно применить, является тем, которое не влияет на фактическую политику. Например, вы могли изменить Минимальный интервал объявления маршрута (MRAI) узла (под определенным AF).

Вот пример, который показывает ручное перемещение медленного узла, когда медленная одноранговая функция не доступна:

RR1#debug ip bgp groups 
BGP groups debugging is on

RR1(config)#router bgp 1                                   
RR1(config-router)#address-family vpnv4                          
RR1(config-router-af)#neighbor 10.100.1.3 advertisement-interval 3 

BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
mismatch
BGP(4): Scheduling withdraws and update-group membership change for 10.100.1.3
BGP(4): Resetting 10.100.1.3's version for its transition out of update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
mismatch
BGP-DYN(4): Removing 10.100.1.3 from update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
mismatch
BGP-DYN(4): Created update-group 0 from neighbor 10.100.1.3
BGP-DYN(4): Adding 10.100.1.3 to update-group 0

Статическое медленное одноранговое перемещение

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

Для перемещения медленного узла статически, можно настроить его с использованием этих команд:

  • Включите перемещение статического однорангового узла на соседний узел или на группу равных узлов:
    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group static
  • Включите перемещение статического однорангового узла через одноранговый шаблон политики:
    [no] slow-peer split-update-group static

Динамическое медленное одноранговое перемещение

Медленное одноранговое перемещение отключено по умолчанию. Для включения медленного однорангового перемещения можно настроить его с помощью одного из этих методов:

  • Включите медленное одноранговое перемещение за процесс BGP:
    bgp slow-peer split-update-group dynamic [permanent]

    [no] bgp slow-peer split-update-group dynamic

    Примечание: Это может быть настроено от представления address-family/топологии/VRF.

  • Включите медленное одноранговое перемещение на узел:
    neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group dynamic [permanent]

    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group dynamic
  • Включите медленное одноранговое перемещение через одноранговый шаблон политики:
    slow-peer split-update-group dynamic [permanent]

    [no] slow-peer split-update-group dynamic

Примечание: Постоянное ключевое слово указывает, что медленный узел не восстановится автоматически. В этом случае можно положить обратно восстановленный медленный узел его исходной группе обновления через одну из команд clear.

Статические медленные узлы и динамические медленные узлы находятся в той же медленной одноранговой группе обновления. В данном примере вы видите один медленный узел в медленной группе обновления:

R2#show ip bgp update-group

BGP version 4 update-group 4, external, Address Family: IPv4 Unicast
 BGP Update version : 0/566013, messages 100 queue 100, not converged
 Slow update group
 Private AS number removed from updates to this neighbor
 Update messages formatted 2497, replicated 0
 Number of NLRIs in the update sent: max 10, min 1
 Minimum time between advertisement runs is 30 seconds
 Has 1 member (* indicates the members currently being sent updates)
 (1 dynamically detected as slow):
 *10.1.6.7

Восстановление

Медленный узел может быть перегруппирован под его исходной группой обновления (который совпадает с политикой ограничения исходящего трафика), как только подтверждено, что это больше не медленный узел (это нагоняет). Когда медленная одноранговая группа обновления сходилась, таймер восстановления запускается. Когда таймер восстановления истекает, медленный узел попятился группе регулярного обновления.

Примечание: Для наблюдения поведения, которое отнесено к обнаружению/таймеру восстановления, введите команду событий debug ip bgp updates.

Когда медленный узел попятился исходной группе обновления (это означает восстановление), сообщение системного журнала, подобное этому, распечатано:

%BGP-5-SLOWPEER_RECOVER: Slow peer IPv4 Unicast 10.1.6.7 has recovered.

Чтобы проверить, выполняется ли таймер восстановления в настоящее время и значение, введите эту команду:

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
 BGP Update version : 165973/0, messages 0 queue 0, converged
 Route map for outgoing advertisements is dummy
 Update messages formatted 0, replicated 0
 Number of NLRIs in the update sent: max 0, min 0
 Minimum time between advertisement runs is 30 seconds
 Slow-peer recovery timer (expires in 16 seconds)
 Has 1 member (* indicates the members currently being sent updates):
  10.1.1.1

В данном примере таймер восстановления, со значением 16 секунд, указывает, что возможно медленный узел мог бы попятиться своей исходной группе обновления через 16 секунд.

В данном примере вы видите узел, который восстановился с медленного состояния однорангового узла:

R2#show ip bgp neighbor 10.1.6.7 

BGP neighbor is 10.1.6.7, remote AS 7, external link
Member of peer-group group3 for session parameters
 BGP version 4, remote router ID 10.1.6.7

3 update-group member
 group3 peer-group member

Number of NLRIs in the update sent: max 249, min 0
 Last detected as dynamic slow peer: 00:12:49
 Dynamic slow peer recovered: 00:01:57
Oldest update message was formatted: 00:00:55

Очистите медленное состояние однорангового узла

Медленное состояние однорангового узла может быть очищено вручную с этими командами:

  • медленный clear ip bgp *

  • AF clear ip bgp {unicast|multicast} <медленный number> AS

  • AF clear ip bgp {unicast|multicast} группа равных узлов медленный <group-name>

  • clear ip bgp медленный <адрес соседа>

  • AF clear bgp {unicast|multicast} * медленный

  • AF clear bgp {unicast|multicast} <медленный number> AS

  • AF clear bgp {unicast|multicast} группа равных узлов медленный <group-name>

  • AF clear bgp {unicast|multicast} медленный <адрес соседа>

Примечание: Когда вы используете эти команды, заменяете AF семейством фактического адреса.

С использованием этих команд узел попятился исходной группе обновления.

Введите внутреннюю команду show ip bgp для просмотра медленных одноранговых параметров настройки обнаружения и перемещения:

R2#show ip bgp internal
Time left for bestpath timer: 593 secs
Address-family IPv4 Unicast, Mode : RW
   Table Versions : Current 622091, RIB 622091
   Start time : 00:00:01.168   Time elapsed 01:21:56.740
   First Peer up in : 00:00:07   Exited Read-Only in : 00:02:16
   Done with Install in : 00:02:26   Last Update-done in : never
   0 updates expanded
   Attribute list queue size: 0
   Slow-peer detection is enabled Threshold is 300 seconds
   Slow-peer split-update-group dynamic is enabled

   BGP Nexthop scan:-
       penalty: 0, Time since last run: never, Next due in: none
       Max runtime : 0 ms Latest runtime : 0 ms Scan count: 0
   BGP General Scan:-
       Max runtime : 14572 ms Latest runtime : 14572 ms Scan count: 78
   BGP future scanner version: 79
   BGP scanner version: 0

Примечание: Таким образом, BGP, медленный узел является функцией, которая обнаруживает медленный узел в группе Обновления BGP и обеспечивает более быстрое согласование BGP с перемещением медленного узла из группы обновления.



Document ID: 119000