Хорошо

BGPv4: выбор оптимального направления с т. з. MTU (PMTU) Популярное

Последний ответ июн 16, 2021 14:55:11 704 13 11 0 1

Всем доброго дня и хорошего настроения!
    Свой текущий доклад я хотел бы посвятить практике применения еще одной функции оптимизации работы BGP-среды.

    Речь о стандартной функции, описанной в RFC 1191 (развитие для IPv6 = RFC 1981), Path MTU Discovery и ее применимости для BGP-спикеров.
__

Вместо предисловия

    Теорию поста я освежил по докам (даже с картинками), просмотрел примеры (ниже будут ссылки), вроде даже и успоколися (речь ведь ВСЕГО об 1 команде :) ), НО вот начал обкатывать и "завис" (ну, не мог я понять то одного, то другого вывода, точнее не понимал их закономерности) почти на два дня :(
А тема-то "Реальная" - IP MTU - тот параметр, который на мультисервисных сетях очень важен для понимания и работоспособности приложений, поэтому и решил "обкатать" от и до именно на практике.
Результат на 100% обкатать не получилось (на eNSP), но накопленный опыт я решил "открыть"

__

    Теория вопроса понятна из картинок:

1) Стандартная работа BGP предусматривает сообщение с нагрузкой 8980 байт, но если на пути изменение поля MTU, то BGP-спикер будет фрагментировать наши данные, ЧТО займет и время и ресурсы (особенно понимая масштабы BGP, а м. б. и блочится "соседом" - на то и BGP разработали = соседний админ - это не мы сами):

download?uuid=f3a45e11b55e4e68a7b9442e621c7ceb

2) Идея в том, что желательно заранее понять - какие сегменты/пакеты нужно слать? (какого размера)
Функция Path MTU Discovery это "изучит", а далее уже "прикрутим" в нашем случае для BGP, итого получим вариант посылки 2х пакетов ИЗНАЧАЛЬНО (по сумме равных 8980) =

download?uuid=2cbae3187ad24ecf836e080a2a9f71ea

Шаги проверки MTU после включенной функции PMTU на "Device A":

1) Device A отправляет пакеты с битом DF

2) Device B на это возвращает ошибку с просьбой фрагментировать И указывает размер MTU

3) Device A, в зависимости от реализации ПО:

---- либо сразу применяет подсказуку по размеру MTU

---- либо уменьшает на какое-то значение свое MTU и снова пробует отправить пакеты

Вот за это мы и поборимся на приактике.

___

Для внедрения и обкатки собрана схема (будет вложена в пост):


BGP_PMTU

Настроена маршрутизация, сразу предлагаю вывод одного из маршрутов в доказательство:

[~R1]display ip routing-table 20.20.20.0 verbose
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
 route
------------------------------------------------------------------------------
Routing Table : _public_
Summary Count : 1

Destination: 20.20.20.0/24       
     Protocol: EBGP               Process ID: 0              
   Preference: 255                      Cost: 0              
      NextHop: 2.2.2.2             Neighbour: 2.2.2.2
        State: Active Adv Relied         Age: 00h41m17s           
          Tag: 0                    Priority: low            
        Label: NULL                  QoSInfo: 0x0           
   IndirectID: 0x1000066            Instance:                                 
 RelayNextHop: 192.168.13.3        Interface: Ethernet1/0/2
     TunnelID: 0x0                     Flags: RD             
[~R1]

Т. е. пиринг R1 -- R2 работает, и маршрут "проходит" через R3 (в BGP НЕ применяется).

Если "передернуть" BGP, то видим на снифере (исходящий интерфейс R1) то, что основная масса сеток "уходит" одним сообщением Update (в точке анализа "1") =

BGP_PMTU2

----
Замечание: R4 на схеме используется как независимая точка генерации маршрутов, причем вся технка становится хоть как-то оправданной, если маршрутов не менее 10 - выше на рисунке именно этот десяток сетей...(опять же все можно "пощупать" самостоятельно...)
----

В точке анализа 2 этот BGP update будет идентичным (вывод не прикладываю)

        Меняем MTU на R3 (выбор этой точки - такой же как в "букваре" теории):

[~r3]int ethe 1/0/1
[~r3-Ethernet1/0/1]mtu 160
[*r3-Ethernet1/0/1]comm

Если посмотреть BGP UPDATE теперь, то видно фрагментирование в точке анализа "2":

BGP_PMTU_2_1

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

Далее собственно суть поста с т. з. настроек =
Запускаем функцию PMTU для BGP + даем команду (ради команды в моем случае) для корректировки периода "опроса" ICMP-пакетами пути на предмет понимания MTU

[~R1]bgp 100

[~R1-bgp]peer 2.2.2.2 path-mtu auto-discovery
...

[*R1]tcp timer pathmtu-age ?
  INTEGER<10-100>  aging time for the TCP PMTU(in minutes) - Думаю, смысл понятен

[*R1]tcp timer pathmtu-age 20
[*R1]comm

              Видно, что функция применилась:

<R1>display bgp peer 2.2.2.2 verbose

         BGP Peer is 2.2.2.2,  remote AS 200
         Type: EBGP link

...

...

 Path MTU discovery has been configured

    Вот с этого момента я долго пытался заставить работать методику как нужно на eNSP.

НЕ получилось в последнем шаге (скрины не привожу - и так объемно для такой задачки) :

1) R1 отправляет обновление BGP с битом DF - четко!

1-1) причем сеток добавил на R4, чтобы наверняка - около 20 штук...--> размер BGP Update приблизился к 300Байтам

2) R3 (Транзитер) принимает это, НЕ передают (DF работает), НО возвращает на R1 призыв к фрагментации:

3) R1 получил команду на фрагментацию:


и ВСЕ. Тишина. А должен применить и отправить BGP Update 1 + Update 2.

t_0031.gif

Я пробовал "бороться", но увы, пока не получилось: от прямого пиринга (без Loopback), переделки BGP (в одной AS), увеличение размера BGP-update, изменение MTU... до перебора моделей маршрутизаторов (приложил последнюю итерацию - NE-цепочка маршрутизаторов) - не помогает, т. е. мой вывод, что функция для Huawei не отражена (именно на практике) в интернет по причине ее неработоспособности (реализации софта).
Перечитал RFC на предмет ограничений минимального MTU - тоже "мимо".

Так тоже бывает!

P. S.
1) Теория (с матиматикой) есть у нашего вендора =

https://support.huawei.com/enterprise/ru/doc/EDOC1100125834/6d8206cd/configuring-path-mtu-auto-discovery

2) Попытки озвучить функцию уже были, но очень "выдранно" и комками:

https://forum.huawei.com/enterprise/en/how-to-deploy-the-bgp-path-mtu-auto-discovery/thread/482559-861

Именно этот пост побудил меня к проверке :):

-- обычно, если что-то получается, то как-то выводами подкрепляют, а здесь "обрыв"...

3) RFC https://datatracker.ietf.org/doc/rfc1191/

4) Более-менее стабильная работа схемы (без потери конфигов) получается при последовательном (не одновременном) старте устройств - запсутил --> жди полной загрузки...



У статьи есть другие ресурсы

Требуется войти для загрузки или просмотра. Нет аккаунта? Register

x
  • x

2559godji
Опубликовано 2021-6-15 10:32:41
Тема действительно "реальная". Однажды я работал на провайдера, который базовые станции стал переводить на MPLS. Потратил миллионы на коммутаторы S EI кажется... Что-то они там около полумиллиона за штуку стоили. В основным каналы для базовых станции были последними милями. И часто мы слышали, что оператор не мог расширить MTU на своей стороне до нужным тогда 1552
Развернуть
  • x

Vasyo
Vasyo Опубликовано 2021-6-15 10:37 (0) (0)
MPLS не поддерживает дефрагментацию да. OSPF кажется тоже  
Vasyo
Админ Опубликовано 2021-6-15 10:44:08
@mkabanov А как вы к GNS3 относитесь? На IOS работает корректно?
Развернуть
  • x

mkabanov
HCIE MVE Author Опубликовано 2021-6-15 14:04:36
ООО! Благодаря Dynamips (основа для GNS3) я в принципе состоялся как инженер!
Это же решение по работе с реальным софтом у себя на ноуте: 3620 серия маршрутизаторов (с софтом поддержки BGP, IS-IS) у меня запускалась в кол-ве 7 штук одновременно еще 12 лет назад :))
Для некоторых фич приходилось "заряжать" 3725, но это уже не более 4х одновременнно
Краем глаза следил я за развитием GNS3 - очень "прокачали" - молодцы!
Развернуть
  • x

Vasyo
Админ Опубликовано 2021-6-15 15:26:56
Опубликовано пользователем mkabanov в 2021-06-15 14:04 ООО! Благодаря Dynamips (основа для GNS3) я в принципе состоял ...
Да, это не ущербный пакет трайсер)) Это круто, да. Лично мне он дал первое представление о виртуализации
Развернуть
  • x

mkabanov
mkabanov Опубликовано 2021-6-17 11:23 (0) (0)
У PT четкое позиционирование - начальный уровень ОБУЧЕНИЯ. В этом он - шедевр!  
TinaSehm
Опубликовано 2021-6-15 18:35:51
Как вы подробно и с иллюстрациями "открыли" свой опыт! Круто! Как только добьётесь желаемого результата - дополните статью?
Развернуть
  • x

mkabanov
mkabanov Опубликовано 2021-6-15 21:35 (0) (0)
Спасибо!
Да, есть еще надежда на результат (на железе) - конечно, дополню!  
TinaSehm
TinaSehm Ответить mkabanov  Опубликовано 2021-6-17 16:41 (0) (0)
Верю в результат!  
A_Litvin
Author Опубликовано 2021-6-15 21:41:31
Не зря " зависли" на два дня! :) Опыт есть опыт! Спасибо, что делитесь!
Развернуть
  • x

mkabanov
mkabanov Опубликовано 2021-6-15 22:15 (0) (0)
 
2559godji
Опубликовано 2021-6-16 14:55:11
GNS3 ведь открытая система, почему не сделать образы хувиков для нее...
Развернуть
  • x

mkabanov
mkabanov Опубликовано 2021-6-17 11:22 (0) (0)
Так это моментально и сразу приведет к созданию вендора типа 'соф-ноф-нетворк'...  

Комментарий

Выполните вход в систему, чтобы ответить на пост. Вход | Регистрация
Отправить

Внимание! В целях защиты правовых интересов Вас, сообщества и третьих лиц, не публикуйте любой материал, содержащий политические высказывания, порнографию, упоминание азартных игр, употребление наркотиков, а также материал, нарушающий коммерческую тайну или содержащий персональные данные пользователей. Также не предоставляйте данные от вашей учетной записи. Вы будете нести ответственность за все действия, выполняемые под вашим аккаунтом. Подробная информация: “Пользовательское соглашение.”

My Followers

Авторизуйтесь и пользуйтесь всеми преимуществами участника!

Вход

Заблокировать
Вы уверены, что хотите заблокировать этого пользователя?
Пользователи из вашего черного списка не могут комментировать ваши посты, не могут упоминать вас, не могут отправлять личные сообщения.
Напоминание
Пожалуйста, привяжите свой мобильный номер чтобы получить бонус за приглашение.
О защите информации
Благодарим за использование Huawei ICT Club! Мы хотим рассказать вам о том, как мы собираем, используем и храним ваши данные. Пожалуйста, внимательно ознакомьтесь с Политикой конфиденциальности и Пользовательским соглашением.