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

Откидные створки Соседнего BGP узел с техническими примечаниями по поиску и устранению проблем MTU

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

Введение

Этот документ описывает, как определить, вызваны ли внутренний или внешний протокол пограничного шлюза (BGP) соседние откидные створки проблемами максимального размера передаваемого блока данных (MTU).

Внесенный Амером Ибрагимовичем, Mani Ganesan, и Джеем Калкарни, специалистами службы технической поддержки Cisco.

Предварительные условия

Гарантируйте, что вы выполняете эти задачи на обоих маршрутизаторах под управлением BGP перед завершением процедур в этом документе:

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

Проблема

Форма Соседних BGP узел; однако, во время префиксного обмена, отбрасывания состояния BGP и журналы генерируют недостающий BGP привет, пакеты Keepalive или другой узел завершают сеанс.

Выполните эти шаги, чтобы определить, заставляет ли MTU Соседние BGP узел колебаться:

  1. Используйте ниже команд для проверки, на какой соседний узел влияют и связанный интерфейс на обоих маршрутизаторах под управлением BGP. Если пиринговый адрес является адресом обратной связи, проверьте связанный интерфейс, через который loopback достижим. Кроме того, проверьте для BGP OutQ на обоих маршрутизаторах равноправного информационного обмена. Последовательный ненулевой OutQ является надежной индикацией, которая обновления не достигают узла из-за проблемы MTU в пути.
    Router#show ip bgp summ | in InQ|10.10.10.2
    Neighbor    V  AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    10.10.10.2   4  3    64     62 3   0   0 00:00:3      2
    Router#show ip route 10.10.10.2
    Routing entry for 10.10.10.0/24
     Known via "connected", distance 0, metric 0 (connected, via interface)
     Routing Descriptor Blocks:
     * directly connected, via GigabitEthernet1/0
         Route metric is 0, traffic share count is 1
  2. Проверьте максимальный размер блока данных (MTU) интерфейса с обеих сторон:
    Router#show ip int g1/0 | i MTU
    MTU is 1500 bytes
    Router#
  3. Подтвердите, что TCP согласовал Max. сегмент данных для обоих динамиков BGP:
    Router#show ip bgp neigh 20.20.20.2 | inc segment
    Datagrams (max data segment is 1460 bytes):
    Router#

    В приведенном выше примере 1460 корректен, поскольку 20 байтов назначены на заголовок TCP и еще 20 к IP - заголовку.

  4. Подтвердите, включен ли используемый path mtu BGP:
    Router#show ip bgp neigh 10.10.10.2 | in tcp
    Transport(tcp) path-mtu-discovery is enabled
    Router#
  5. Пропингуйте Одноранговое соединение по протоколу BGP с Max. максимальным размером блока данных (MTU) интерфейса, и DF (не Фрагментируйте), установленный бит:
    Router#ping 10.10.10.2 size 1500 df

    Type escape sequence to abort.
    Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
    Packet sent with the DF bit set
    .....
    Success rate is 0 percent (0/5)
  6. Уменьшите значение размера ICMP для определения размера максимального значения размера блока данных, который может использоваться:
    ping 10.10.10.2 size 1300 df 

Решение

Вот некоторые возможные причины:

  • Максимальный размер блока данных (MTU) интерфейса на обоих маршрутизаторах не совпадает.
  • Максимальный размер блока данных (MTU) интерфейса на обоих соответствиях маршрутизаторов, но домен Уровня 2, по которому сформирован сеанс BGP, не совпадает.
  • Обнаружение MTU-маршрута определило неправильный Max. размер данных для сеанса BGP TCP.
  • Обнаружение Максимального размера передаваемого блока данных Пути BGP (PMTUD) могло отказывать из-за заблокированных пакетов ICMP PMTUD (межсетевой экран или ACL)

Вот возможные способы для решения вопросов MTU:

  1. Максимальный размер блока данных (MTU) интерфейса на обоих маршрутизаторах должен быть тем же; всем заправляйте IP интервал | в команде MTU для проверки текущих Параметров MTU.

  2. Если максимальный размер блока данных (MTU) интерфейса на обоих маршрутизаторах корректен (например, 1500), но эхо - тесты (ping test) с Набором битов DF не превышают 1300, то домен Уровня 2, о котором, сформирован сеанс BGP, на который влияют, мог бы включать противоречивые конфигурации MTU. Проверьте каждый MTU Интерфейса 2 уровня. Исправьте MTU Интерфейса 2 уровня для решения вопроса.

  3. Если вы неспособны проверить/изменить домен Уровня 2, можно установить команду global ip tcp mss в меньшее значение как 1000, который вызовет весь локально инициируемый TCP Max. сеансы сегмента данных (который включает BGP) к 1000. Для получения дополнительной информации об этой команде обратитесь к разделу ip tcp mss Справочника по командам Cервисов IP-приложения Cisco IOS.

    Кроме того, можно использовать команду ip tcp adjust-mss для устранения проблем далее; эта команда настроена в уровне интерфейса и влияет на все сеансы TCP. Для получения дополнительной информации об этой команде обратитесь к разделу ip tcp adjust-mss Справочника по командам Cервисов IP-приложения Cisco IOS.

  4. (Необязательно) Обнаружение Максимального размера передаваемого блока данных Пути BGP (PMTUD) не могло бы генерировать корректный максимальный размер данных. Можно отключить его глобально или на соседний узел, чтобы подтвердить, является ли это причиной. Когда PMTUD BGP отключен, настройки по умолчанию Maximum Segment Size (MSS) BGP к 536, как определено в RFC 879.

    Для получения информации о том, как отключить PMTUD, обратитесь к Поддержке BGP Настройки для Обнаружения MTU-маршрута TCP на Раздел сеансов руководства по конфигурации BGP Cisco IOS.

    Для получения дополнительной информации о PMTUD обратитесь к тому, Что такое PMTUD?


Document ID: 116377