Всем доброго дня и хорошего настроения!
Свой текущий доклад я хотел бы посвятить практике применения еще одной функции оптимизации работы BGP-среды.
Речь о стандартной функции, описанной в RFC 1191 (развитие для IPv6 = RFC 1981), Path MTU Discovery и ее применимости для BGP-спикеров.
__
Вместо предисловия
Теорию поста я освежил по докам (даже с картинками), просмотрел примеры (ниже будут ссылки), вроде даже и успоколися (речь ведь ВСЕГО об 1 команде :) ), НО вот начал обкатывать и "завис" (ну, не мог я понять то одного, то другого вывода, точнее не понимал их закономерности) почти на два дня :(
А тема-то "Реальная" - IP MTU - тот параметр, который на мультисервисных сетях очень важен для понимания и работоспособности приложений, поэтому и решил "обкатать" от и до именно на практике.
Результат на 100% обкатать не получилось (на eNSP), но накопленный опыт я решил "открыть"
__
Теория вопроса понятна из картинок:
1) Стандартная работа BGP предусматривает сообщение с нагрузкой 8980 байт, но если на пути изменение поля MTU, то BGP-спикер будет фрагментировать наши данные, ЧТО займет и время и ресурсы (особенно понимая масштабы BGP, а м. б. и блочится "соседом" - на то и BGP разработали = соседний админ - это не мы сами):
2) Идея в том, что желательно заранее понять - какие сегменты/пакеты нужно слать? (какого размера)
Функция Path MTU Discovery это "изучит", а далее уже "прикрутим" в нашем случае для BGP, итого получим вариант посылки 2х пакетов ИЗНАЧАЛЬНО (по сумме равных 8980) =
Шаги проверки MTU после включенной функции PMTU на "Device A":
1) Device A отправляет пакеты с битом DF
2) Device B на это возвращает ошибку с просьбой фрагментировать И указывает размер MTU
3) Device A, в зависимости от реализации ПО:
---- либо сразу применяет подсказуку по размеру MTU
---- либо уменьшает на какое-то значение свое MTU и снова пробует отправить пакеты
Вот за это мы и поборимся на приактике.
___
Для внедрения и обкатки собрана схема (будет вложена в пост):
Настроена маршрутизация, сразу предлагаю вывод одного из маршрутов в доказательство:
[~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") =
----
Замечание: 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":
---Если мучительно долго и методично анализровать вложение у данных фрагментов, то можно прийти к выводу, что ДА, все так и есть в точке анализа "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.
Я пробовал "бороться", но увы, пока не получилось: от прямого пиринга (без Loopback), переделки BGP (в одной AS), увеличение размера BGP-update, изменение MTU... до перебора моделей маршрутизаторов (приложил последнюю итерацию - NE-цепочка маршрутизаторов) - не помогает, т. е. мой вывод, что функция для Huawei не отражена (именно на практике) в интернет по причине ее неработоспособности (реализации софта).
Перечитал RFC на предмет ограничений минимального MTU - тоже "мимо".
Так тоже бывает!
P. S.
1) Теория (с матиматикой) есть у нашего вендора =
2) Попытки озвучить функцию уже были, но очень "выдранно" и комками:
Именно этот пост побудил меня к проверке :):
-- обычно, если что-то получается, то как-то выводами подкрепляют, а здесь "обрыв"...
3) RFC https://datatracker.ietf.org/doc/rfc1191/
4) Более-менее стабильная работа схемы (без потери конфигов) получается при последовательном (не одновременном) старте устройств - запсутил --> жди полной загрузки...
