В первой части статьи я попытался описать возможности некоторых подходов к балансировке трафика в MPLS домене, идея была в том чтобы показать уникальные требования к аппаратной реализации чипа, которые позволяют достигнуть успеха, в том или ином случае. Вторая часть будет посвящена рассказу об относительно свежем драфте [Multi-path Label Switched Paths Signaled Using RSVP-TE] от Kireeti Kompella, и описанию применения его реализации от Juniper к решению некоторых задач.
Задача эффективной утилизации каналов связи в RSVP-TE сети имеет много общего с задачей упаковки вещей в сумки, чемоданы или контейнеры перед отпуском. Каждый кто это делал скажет что вещи примерно равного размера укладываются гораздо проще и равномернее. Хорошо если размер вещей заметно меньше размера контейнера, но вот когда внезапно возникает необходимость вместить в одну из уже готовых к отъезду сумок объемный предмет, пересортировка неизбежна. В мире RSVP-TE подобное называют bin-packing проблемой, чтобы понять о чем я говорю, посмотрите на рисунок 1, зеленая и синяя линии это установленные LSP1 по пути A-C-D-E и LSP2 по пути B-C-E в моменты времени T=1 и T=2, соответственно. Если в момент времени T=3 полосу LSP2 потребовалось бы расширить до значения 8, емкость канала C-E не позволила бы это сделать. В мире вещей и чемоданов, мы потратили бы немного времени на пересортировку вещей для решения этой задачи. RSVP-TE позволяет с определенными оговорками поступить также, для этого придумали setup и hold приоритеты LSP, потенциально более широким LSP можно присвоить высокий приоритет, чтобы узкие LSP подвинулись, однако этот подход работает ровно до того момента пока в игру вступают LSP с одинаковыми приоритетами, а дальше все повторяется.
Так происходит по двум причинам:
Возвращаясь к проблеме чемоданов, мы могли бы попробовать разобрать внезапно обнаруженную вещь до такой степени чтобы все ее части равномерно заполнили свободное пространство нескольких чемоданов. Похожую идею предложил Kireeti Kompella для оптимальной утилизации каналов связи в среде RSVP-TE. Вместо того чтобы сигнализировать один толстый путь, маршрутизатор, с учетом текущей топологии и утилизации каналов, обсчитывает и сигнализирует несколько менее требовательных к полосе путей, в драфте они называются sub-LSPs. На рисунке 2 показано как это могло бы выглядеть применительно к расширению полосы LSP2 до значения 8, маршрутизатор прокладывает пару sub-LSP с полосами по 4 и раскладывает трафик по двум возможным путям.
Итак, в драфте появляется новое понятие MLSP или контейнер, это понятие определяет объект конфигурации и управления набором sub-LSPs. Иными словами, TE свойства и требования, зафиксированные в контейнере, порождают некоторый набор физических LSP, удовлетворяющих
заданным ограничениям и возможностям сети. Точный алгоритм расчета количества sub-LSPs и полосы резервируемой sub-LSP не описан, это все отдано на вольную реализацию вендорам, на этот счет есть только две оговорки:
sub-LSPs, принадлежащие конкретному экземпляру MLSP, сигнализируются таким образом чтобы транзитные маршрутизаторы могли определить эту принадлежность, для этого в сообщении Path предполагается использование RSVP объекта ASSOCIATION с уникальными значением для каждого MLSP. Интересно, что до 4-й версии драфта в качестве идентификатора предполагалось использовать поля Sender Template. Идентификация принадлежности sup-LSP полезна тем что позволяет реализовать довольно простой механизм экономии меток, downstream маршрутизатору нет нужды резервировать уникальную метку под каждый sub-LSP, достаточно определить к какому именно MLSP принадлежит устанавливаемый sub-LSP и вернуть общую метку в сторону upstream маршрутизатора.
В зависимости от возможностей коммутационного чипа транзитного маршрутизатора драфт описывает две варианта организации передачи трафика на уровне data plane. Первый вариант, называемый Equi-bandwidth LSP, заключается в равномерном распределении потоков трафика по всем sub-LSP на каждом транзитном маршрутизаторе, поведение потоков трафика при этом полностью соответствует per-hop ECMP балансировке с возможностью использовать все, а не только IGP Best, пути. Вторая возможность предполагает весовое распределение потоков трафика по sub-LSP в соответствии с зарезервированной полосой. Также оговаривается возможность альтернативных (на усмотрение вендора) вариантов организации data-plane.
У такой организации data-plane есть интересное свойство — в некоторых топологиях быстрая сходимость в случае аварий является само собой разумеющимся следствием даже без привлечения механизмов наподобие MPLS TE Protection, так при выходе из строя канала B-C на рисунке 3 маршрутизатор B, не устанавливая никаких repair путей, способен самостоятельно восстановить передачу трафика просто изъяв один next-hop из таблицы еще до того как информация об аварии будет доступна маршрутизатору А.
Дальнейший анализ драфта рискует превратиться в пересказ, поэтому перейдем к примерам использования. На текущий момент мне известен только один вариант, который с определенными оговорками можно назвать как минимум идейной реализацией драфта. Основная претензия заключается в том что механизмы экономии меток и идентификации sub-LSP пока не реализованы, тем не менее получился удобный инструмент решения некоторых TE задач. Кстати сказать, Juniper Container LSP полностью совместим с классическими реализациями RSVP-TE других производителей, это, на мой взгляд, серьезный плюс именно такой формы реализации.
Привлекательным выглядит возможность применения Full Mesh Container LSP между PE маршрутизаторами в сочетании P устройствами без серьезных возможностей хеширования стека меток. Вместо балансировки трафика на каждом транзитном маршрутизаторе, в Container LSP используется гибкий механизм расчета и сигнализации sub-LSP. Алгоритм способен автономно приводить в соответствие количество sub-LSP, их пути и занимаемые полосы к возможностям и топологии сети. На вход алгоритма передается конфигурационные параметры контейнера, или набора sub-LSP, их свойства и ограничения:
Агрегированная полоса периодически обновляется на основе статистики полосы каждого sub-LSP и представляет собой сумму этих значений. Остальные параметры контейнера задаются в ручную в соответствии с желаемыми значениями. Автономная работа поддерживается за счет периодически повторяющегося события нормализации, в этот момент времени алгоритм принимает одно из следующих решений:
Текущая версия алгоритма нормализации осуществляет расчет, в результате которого появляется набор sub-LSP с равной полосой. Например если агрегированная полоса равна 10 в результате расчета могут появится sub-LSP с такими параметрами: 2 по 5, 5 по 2, или 3 по 3.3, если есть несколько вариантов алгоритмом выбирается тот что требует меньшее количество sub-LSP. Между событиями нормализации полоса каждого sub-LSP может быть изменена индивидуально с помощью механизма auto-bandwidth. На следующей итерации нормализации алгоритм соберет текущие показания полосы и выполнит одно из своих возможных действий, действия удаления или добавления sub-LSP выполняются если актуальная полоса какого либо sub-LSP выходит за диапазон расщепления/слияния. Добавление или удаление sub-LSP сопровождаются перерасчетом полосы с учетом следующих ограничений:
Наименьшее значение N, удовлетворяющее этим неравенства, используется для расчета новой полосы sub-LSP по просто формуле
Если CSPF алгоритм не в состоянии найти пути с требуемой свободной полосой, например из-за фрагментации свободной полосы, N увеличивается на единицу, что снижает индивидуальную полосу sub-LSPs, и процесс поиска путей повторяется.
Для демонстрации поведения Container LSP я собрал вот такую схему. Полоса каждого интерфейса уменьшена до 10Mbit/s.
Начнем с конфигурации на маршрутизаторе A, нужно явно включить сбор статистики LSP (строчки 1-3), указать шаблон, из которого будут создаваться sub-LSP (строчки 4-11) и написать свойства контейнера LSP в сторону маршрутизатора B (строчки 12-22)
После активации кода происходит инициализация контейнера, и, так как. статистики трафика еще нет устанавливается минимальное количество sub-LSP с полосой равной полосе расщепления. Через некоторое время механизм auto-bandwidthнакопил статистику (нулевую в данном случае) и скорректировал полосу.
В живой сети лучше заранее оценить порядок трафика, и подготовить нужное количество sub-LSP с примерной полосой. Это можно сделать с помощью параметров minimum-member-lsps и merging-bandwidth (строки 15 и 17).
Теперь сгенерируем что-то около 7Mbps трафика, и проанализируем что получилось. Я подождал некоторое время чтобы разобрать хронологию после события нормализации.
До наступления событий актуализации полосы auto-bandwidth и нормализации меняется только статистика. Обратите внимание на значения Max AvgBW util и Sampled Aggregate bandwidth, первое — актуальная полоса sub-LSP, второе — актуальная полоса контейнера.
Через некоторое время механизм auto-bandwidthскорректировал полосу единственного sub-LSP, в истории это видно по записи
Еще через какое-то время настал момент нормализации, и так как полоса реально занимаемая LSP находится вне диапазона слияния/расщепления алгоритм принял решение добавить еще одну sub-LSP.
Теперь добавим еще около 2Mbps трафика, судя по показаниям Sampled Aggregate bandwidth и
Max AvgBW util статистика поползла вверх.
Еще через некоторое время auto-bandwidth поправил полосу обоих sub-LSB.
А алгоритм нормализации добавил еще одну sub-LSP.
В том случае когда энтропия передаваемых в LSP пакетов высока, можно активировать пассивный режим auto-bandwidth, в этом случае актуализация полосы будет производится только во время процесса нормализации, тем самым можно добиться некоторой экономии процессорного времени.
Задача эффективной утилизации каналов связи в RSVP-TE сети имеет много общего с задачей упаковки вещей в сумки, чемоданы или контейнеры перед отпуском. Каждый кто это делал скажет что вещи примерно равного размера укладываются гораздо проще и равномернее. Хорошо если размер вещей заметно меньше размера контейнера, но вот когда внезапно возникает необходимость вместить в одну из уже готовых к отъезду сумок объемный предмет, пересортировка неизбежна. В мире RSVP-TE подобное называют bin-packing проблемой, чтобы понять о чем я говорю, посмотрите на рисунок 1, зеленая и синяя линии это установленные LSP1 по пути A-C-D-E и LSP2 по пути B-C-E в моменты времени T=1 и T=2, соответственно. Если в момент времени T=3 полосу LSP2 потребовалось бы расширить до значения 8, емкость канала C-E не позволила бы это сделать. В мире вещей и чемоданов, мы потратили бы немного времени на пересортировку вещей для решения этой задачи. RSVP-TE позволяет с определенными оговорками поступить также, для этого придумали setup и hold приоритеты LSP, потенциально более широким LSP можно присвоить высокий приоритет, чтобы узкие LSP подвинулись, однако этот подход работает ровно до того момента пока в игру вступают LSP с одинаковыми приоритетами, а дальше все повторяется.
Так происходит по двум причинам:
- локальный, не детерминированный порядок вычисления и оптимизации путей на каждом маршрутизаторе;
- отсутствие механизмов, позволяющих координировать вычисление путей между маршрутизаторами.
Возвращаясь к проблеме чемоданов, мы могли бы попробовать разобрать внезапно обнаруженную вещь до такой степени чтобы все ее части равномерно заполнили свободное пространство нескольких чемоданов. Похожую идею предложил Kireeti Kompella для оптимальной утилизации каналов связи в среде RSVP-TE. Вместо того чтобы сигнализировать один толстый путь, маршрутизатор, с учетом текущей топологии и утилизации каналов, обсчитывает и сигнализирует несколько менее требовательных к полосе путей, в драфте они называются sub-LSPs. На рисунке 2 показано как это могло бы выглядеть применительно к расширению полосы LSP2 до значения 8, маршрутизатор прокладывает пару sub-LSP с полосами по 4 и раскладывает трафик по двум возможным путям.
Итак, в драфте появляется новое понятие MLSP или контейнер, это понятие определяет объект конфигурации и управления набором sub-LSPs. Иными словами, TE свойства и требования, зафиксированные в контейнере, порождают некоторый набор физических LSP, удовлетворяющих
заданным ограничениям и возможностям сети. Точный алгоритм расчета количества sub-LSPs и полосы резервируемой sub-LSP не описан, это все отдано на вольную реализацию вендорам, на этот счет есть только две оговорки:
- sub-LSPs должны наследовать все (кроме bandwith) TE ограничения контейнера, например должны наследоваться Administrative group или Setup/Hold Priority;
- сумма резервируемой полосы sub-LSPs должна быть не меньше требований контейнера.
sub-LSPs, принадлежащие конкретному экземпляру MLSP, сигнализируются таким образом чтобы транзитные маршрутизаторы могли определить эту принадлежность, для этого в сообщении Path предполагается использование RSVP объекта ASSOCIATION с уникальными значением для каждого MLSP. Интересно, что до 4-й версии драфта в качестве идентификатора предполагалось использовать поля Sender Template. Идентификация принадлежности sup-LSP полезна тем что позволяет реализовать довольно простой механизм экономии меток, downstream маршрутизатору нет нужды резервировать уникальную метку под каждый sub-LSP, достаточно определить к какому именно MLSP принадлежит устанавливаемый sub-LSP и вернуть общую метку в сторону upstream маршрутизатора.
В зависимости от возможностей коммутационного чипа транзитного маршрутизатора драфт описывает две варианта организации передачи трафика на уровне data plane. Первый вариант, называемый Equi-bandwidth LSP, заключается в равномерном распределении потоков трафика по всем sub-LSP на каждом транзитном маршрутизаторе, поведение потоков трафика при этом полностью соответствует per-hop ECMP балансировке с возможностью использовать все, а не только IGP Best, пути. Вторая возможность предполагает весовое распределение потоков трафика по sub-LSP в соответствии с зарезервированной полосой. Также оговаривается возможность альтернативных (на усмотрение вендора) вариантов организации data-plane.
У такой организации data-plane есть интересное свойство — в некоторых топологиях быстрая сходимость в случае аварий является само собой разумеющимся следствием даже без привлечения механизмов наподобие MPLS TE Protection, так при выходе из строя канала B-C на рисунке 3 маршрутизатор B, не устанавливая никаких repair путей, способен самостоятельно восстановить передачу трафика просто изъяв один next-hop из таблицы еще до того как информация об аварии будет доступна маршрутизатору А.
Дальнейший анализ драфта рискует превратиться в пересказ, поэтому перейдем к примерам использования. На текущий момент мне известен только один вариант, который с определенными оговорками можно назвать как минимум идейной реализацией драфта. Основная претензия заключается в том что механизмы экономии меток и идентификации sub-LSP пока не реализованы, тем не менее получился удобный инструмент решения некоторых TE задач. Кстати сказать, Juniper Container LSP полностью совместим с классическими реализациями RSVP-TE других производителей, это, на мой взгляд, серьезный плюс именно такой формы реализации.
Привлекательным выглядит возможность применения Full Mesh Container LSP между PE маршрутизаторами в сочетании P устройствами без серьезных возможностей хеширования стека меток. Вместо балансировки трафика на каждом транзитном маршрутизаторе, в Container LSP используется гибкий механизм расчета и сигнализации sub-LSP. Алгоритм способен автономно приводить в соответствие количество sub-LSP, их пути и занимаемые полосы к возможностям и топологии сети. На вход алгоритма передается конфигурационные параметры контейнера, или набора sub-LSP, их свойства и ограничения:
- агрегированная полоса;
- минимальное и максимальное количество sub-LSP;
- полосы расщепления и слияния.
Агрегированная полоса периодически обновляется на основе статистики полосы каждого sub-LSP и представляет собой сумму этих значений. Остальные параметры контейнера задаются в ручную в соответствии с желаемыми значениями. Автономная работа поддерживается за счет периодически повторяющегося события нормализации, в этот момент времени алгоритм принимает одно из следующих решений:
- добавить один или несколько sub-LSP
- удалить один или несколько sub-LSP
- оставить все как есть
Текущая версия алгоритма нормализации осуществляет расчет, в результате которого появляется набор sub-LSP с равной полосой. Например если агрегированная полоса равна 10 в результате расчета могут появится sub-LSP с такими параметрами: 2 по 5, 5 по 2, или 3 по 3.3, если есть несколько вариантов алгоритмом выбирается тот что требует меньшее количество sub-LSP. Между событиями нормализации полоса каждого sub-LSP может быть изменена индивидуально с помощью механизма auto-bandwidth. На следующей итерации нормализации алгоритм соберет текущие показания полосы и выполнит одно из своих возможных действий, действия удаления или добавления sub-LSP выполняются если актуальная полоса какого либо sub-LSP выходит за диапазон расщепления/слияния. Добавление или удаление sub-LSP сопровождаются перерасчетом полосы с учетом следующих ограничений:
N - количество sub-LSP, X - агрегированная полоса, minimum-member-lsps - минимальное количество sub-LSP, maximum-member-lsps - максимальное количество sub-LSP, splitting-bandwidth - полоса расщепления, merging-bandwidth - полоса слияния
[X/splitting-bandwidth] ≤ N ≤ [X/merging-bandwidth]
minimum-member-lsps ≤ N ≤ maximum-member-lspsНаименьшее значение N, удовлетворяющее этим неравенства, используется для расчета новой полосы sub-LSP по просто формуле
B = X / N Если CSPF алгоритм не в состоянии найти пути с требуемой свободной полосой, например из-за фрагментации свободной полосы, N увеличивается на единицу, что снижает индивидуальную полосу sub-LSPs, и процесс поиска путей повторяется.
Для демонстрации поведения Container LSP я собрал вот такую схему. Полоса каждого интерфейса уменьшена до 10Mbit/s.
Начнем с конфигурации на маршрутизаторе A, нужно явно включить сбор статистики LSP (строчки 1-3), указать шаблон, из которого будут создаваться sub-LSP (строчки 4-11) и написать свойства контейнера LSP в сторону маршрутизатора B (строчки 12-22)
[edit protocols mpls]
- set protocols mpls statistics file mpls-lsp-stats
- set protocols mpls statistics interval 50
- set protocols mpls statistics auto-bandwidth
- set protocols mpls label-switched-path lsp-template template
- set protocols mpls label-switched-path lsp-template retry-timer 3
- set protocols mpls label-switched-path lsp-template optimize-timer 0
- set protocols mpls label-switched-path lsp-template least-fill
- set protocols mpls label-switched-path lsp-template adaptive
- set protocols mpls label-switched-path lsp-template auto-bandwidth adjust-interval 300
- set protocols mpls label-switched-path lsp-template auto-bandwidth minimum-bandwidth 1k
- set protocols mpls label-switched-path lsp-template auto-bandwidth maximum-bandwidth 10m
- set protocols mpls container-label-switched-path to-b-cnt label-switched-path-template lsp-template
- set protocols mpls container-label-switched-path to-b-cnt to 172.19.1.2
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging maximum-member-lsps 50
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging minimum-member-lsps 1
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging splitting-bandwidth 4m
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging merging-bandwidth 2m
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization normalize-interval 650
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization failover-normalization
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization normalization-retry-duration 5
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization normalization-retry-limits 3
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging sampling use-percentile 95
[edit protocols mpls]
После активации кода происходит инициализация контейнера, и, так как. статистики трафика еще нет устанавливается минимальное количество sub-LSP с полосой равной полосе расщепления. Через некоторое время механизм auto-bandwidthнакопил статистику (нулевую в данном случае) и скорректировал полосу.
aandreev@a.lab# run show mpls container-lsp ingress extensive
Ingress LSP: 1 sessions
Container LSP name: to-b-cnt, State: Up, Member count: 1
Normalization
Min LSPs: 1, Max LSPs: 50
Aggregate bandwidth: 1000bps, Sampled Aggregate bandwidth: 57.6003bps
NormalizeTimer: 650 secs, NormalizeThreshold: 10%
Max Signaling BW: 4Mbps, Min Signaling BW: 2Mbps, Splitting BW: 4Mbps, Merging BW: 2Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 0, Percentile 95 of Aggregate
Normalization in 639 second(s)
14 Apr 26 22:21:25.954 Avoid normalization: not needed as already running with max-members
13 Apr 26 22:21:25.954 Normalize: normalization with aggregate bandwidth 57 bps
12 Apr 26 22:21:25.954 Normalize: normalizaton with 57 bps
11 Apr 26 22:21:22.050 Avoid normalization: not needed as already running with max-members
10 Apr 26 22:21:22.050 Normalize: normalization with aggregate bandwidth 56 bps
9 Apr 26 22:21:22.049 Normalize: normalizaton with 56 bps
8 Apr 26 22:21:03.558 Clear history and statistics: on container (to-b-cnt)
7 Apr 26 22:20:29.353 Avoid normalization: not needed as already running with max-members
6 Apr 26 22:20:29.353 Normalize: normalization with aggregate bandwidth 56 bps
5 Apr 26 22:20:29.353 Normalize: normalizaton with 56 bps
4 Apr 26 22:17:43.539 Normalization complete: container (to-b-cnt) with 1 members
3 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) into 1 members - each with bandwidth 2000000 bps
2 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) create 1 LSPs, min bw 2000000bps, member count 0
1 Apr 26 22:17:43.529 Normalize: normalization with aggregate bandwidth 0 bps
172.19.1.2
From: 172.19.1.1, State: Up, ActiveRoute: 0, LSPname: to-b-cnt-1
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Least-fill
Autobandwidth
MinBW: 1000bps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 57.6003bps, Bandwidth Adjustment in 67 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 1000bps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1)
172.19.250.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
172.19.250.2
17 Apr 26 22:21:23.060 Make-before-break: Switched to new instance
16 Apr 26 22:21:22.370 Self-ping ended successfully
15 Apr 26 22:21:22.057 Record Route: 172.19.250.2
14 Apr 26 22:21:22.057 Up
13 Apr 26 22:21:22.057 Manual Autobw adjustment succeeded: BW changes from 2000000 bps to 1000 bps
12 Apr 26 22:21:22.057 Self-ping started
11 Apr 26 22:21:22.057 Self-ping enqueued
10 Apr 26 22:21:22.050 Originate make-before-break call
9 Apr 26 22:21:22.050 CSPF: computation result accepted 172.19.250.2
8 Apr 26 22:17:44.002 Self-ping ended successfully
7 Apr 26 22:17:43.539 Selected as active path
6 Apr 26 22:17:43.538 Record Route: 172.19.250.2
5 Apr 26 22:17:43.538 Up
4 Apr 26 22:17:43.538 Self-ping started
3 Apr 26 22:17:43.538 Self-ping enqueued
2 Apr 26 22:17:43.530 Originate Call
1 Apr 26 22:17:43.530 CSPF: computation result accepted 172.19.250.2
Created: Wed Apr 26 22:17:44 2017
Retrytimer: 3
Total 1 displayed, Up 1, Down 0
[edit protocols mpls]
aandreev@a.lab#
В живой сети лучше заранее оценить порядок трафика, и подготовить нужное количество sub-LSP с примерной полосой. Это можно сделать с помощью параметров minimum-member-lsps и merging-bandwidth (строки 15 и 17).
Теперь сгенерируем что-то около 7Mbps трафика, и проанализируем что получилось. Я подождал некоторое время чтобы разобрать хронологию после события нормализации.
aandreev@a.lab# run show mpls container-lsp ingress extensive
Ingress LSP: 1 sessions
Container LSP name: to-b-cnt, State: Up, Member count: 2
Normalization
Min LSPs: 1, Max LSPs: 50
Aggregate bandwidth: 7.10478Mbps, Sampled Aggregate bandwidth: 6.94114Mbps
NormalizeTimer: 650 secs, NormalizeThreshold: 10%
Max Signaling BW: 4Mbps, Min Signaling BW: 2Mbps, Splitting BW: 4Mbps, Merging BW: 2Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 0, Percentile 95 of Aggregate
Normalization in 497 second(s)
23 Apr 26 22:27:43.570 Clear history and statistics: on container (to-b-cnt)
22 Apr 26 22:26:07.615 Normalization complete: container (to-b-cnt) with 2 members
21 Apr 26 22:26:07.562 Normalize: container (to-b-cnt) into 2 members - each with bandwidth 3552392 bps
20 Apr 26 22:26:07.562 Normalize: normalization with aggregate bandwidth 7104784 bps
19 Apr 26 22:26:07.562 Normalize: normalizaton with 7104784 bps
18 Apr 26 22:25:59.138 Avoid normalization: not needed as already running with max-members
17 Apr 26 22:25:59.138 Normalize: normalization with aggregate bandwidth 57 bps
16 Apr 26 22:25:59.138 Normalize: normalizaton with 57 bps
15 Apr 26 22:22:43.557 Clear history and statistics: on container (to-b-cnt)
14 Apr 26 22:21:25.954 Avoid normalization: not needed as already running with max-members
13 Apr 26 22:21:25.954 Normalize: normalization with aggregate bandwidth 57 bps
12 Apr 26 22:21:25.954 Normalize: normalizaton with 57 bps
11 Apr 26 22:21:22.050 Avoid normalization: not needed as already running with max-members
10 Apr 26 22:21:22.050 Normalize: normalization with aggregate bandwidth 56 bps
9 Apr 26 22:21:22.049 Normalize: normalizaton with 56 bps
8 Apr 26 22:21:03.558 Clear history and statistics: on container (to-b-cnt)
7 Apr 26 22:20:29.353 Avoid normalization: not needed as already running with max-members
6 Apr 26 22:20:29.353 Normalize: normalization with aggregate bandwidth 56 bps
5 Apr 26 22:20:29.353 Normalize: normalizaton with 56 bps
4 Apr 26 22:17:43.539 Normalization complete: container (to-b-cnt) with 1 members
3 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) into 1 members - each with bandwidth 2000000 bps
2 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) create 1 LSPs, min bw 2000000bps, member count 0
1 Apr 26 22:17:43.529 Normalize: normalization with aggregate bandwidth 0 bps
172.19.1.2
From: 172.19.1.1, State: Up, ActiveRoute: 0, LSPname: to-b-cnt-1
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Least-fill
Autobandwidth
MinBW: 1000bps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 3.56199Mbps, Bandwidth Adjustment in 147 second(s).
Overflow limit: 0, Overflow sample count: 1
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 3.55239Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1)
172.19.250.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
172.19.250.2
39 Apr 26 22:28:01.331 Make-before-break: Cleaned up old instance: Hold dead expiry
38 Apr 26 22:27:00.512 Make-before-break: Switched to new instance
37 Apr 26 22:26:59.981 Self-ping ended successfully
36 Apr 26 22:26:59.509 Record Route: 172.19.250.2
35 Apr 26 22:26:59.509 Up
34 Apr 26 22:26:59.509 Self-ping started
33 Apr 26 22:26:59.509 Self-ping enqueued
32 Apr 26 22:26:59.503 Autobw adjustment succeeded due to normalization: BW changes from 7105130 bps to 3552392 bps
31 Apr 26 22:26:59.501 Originate make-before-break call
30 Apr 26 22:26:59.501 CSPF: computation result accepted 172.19.250.2
29 Apr 26 22:26:59.498 Make-before-break: Cleaned up old instance: Hold dead expiry
28 Apr 26 22:26:07.563 Pending old path instance deletion
27 Apr 26 22:26:00.148 Make-before-break: Switched to new instance
26 Apr 26 22:25:59.874 Self-ping ended successfully
25 Apr 26 22:25:59.146 Record Route: 172.19.250.2
24 Apr 26 22:25:59.146 Up
23 Apr 26 22:25:59.146 Manual Autobw adjustment succeeded: BW changes from 1000 bps to 7105130 bps
22 Apr 26 22:25:59.145 Self-ping started
21 Apr 26 22:25:59.145 Self-ping enqueued
20 Apr 26 22:25:59.139 Originate make-before-break call
19 Apr 26 22:25:59.139 CSPF: computation result accepted 172.19.250.2
18 Apr 26 22:22:24.539 Make-before-break: Cleaned up old instance: Hold dead expiry
17 Apr 26 22:21:23.060 Make-before-break: Switched to new instance
16 Apr 26 22:21:22.370 Self-ping ended successfully
15 Apr 26 22:21:22.057 Record Route: 172.19.250.2
14 Apr 26 22:21:22.057 Up
13 Apr 26 22:21:22.057 Manual Autobw adjustment succeeded: BW changes from 2000000 bps to 1000 bps
12 Apr 26 22:21:22.057 Self-ping started
11 Apr 26 22:21:22.057 Self-ping enqueued
10 Apr 26 22:21:22.050 Originate make-before-break call
9 Apr 26 22:21:22.050 CSPF: computation result accepted 172.19.250.2
8 Apr 26 22:17:44.002 Self-ping ended successfully
7 Apr 26 22:17:43.539 Selected as active path
6 Apr 26 22:17:43.538 Record Route: 172.19.250.2
5 Apr 26 22:17:43.538 Up
4 Apr 26 22:17:43.538 Self-ping started
3 Apr 26 22:17:43.538 Self-ping enqueued
2 Apr 26 22:17:43.530 Originate Call
1 Apr 26 22:17:43.530 CSPF: computation result accepted 172.19.250.2
Created: Wed Apr 26 22:17:43 2017
Retrytimer: 3
172.19.1.2
From: 172.19.1.1, State: Up, ActiveRoute: 0, LSPname: to-b-cnt-2
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Least-fill
Autobandwidth
MinBW: 1000bps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 3.5582Mbps, Bandwidth Adjustment in 147 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 1, Underflow Max AvgBW: 3.53934Mbps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 3.55239Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
172.19.250.25 S 172.19.250.9 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
172.19.250.25 172.19.250.9
8 Apr 26 22:26:07.888 Self-ping ended successfully
7 Apr 26 22:26:07.615 Selected as active path
6 Apr 26 22:26:07.613 Record Route: 172.19.250.25 172.19.250.9
5 Apr 26 22:26:07.613 Up
4 Apr 26 22:26:07.613 Self-ping started
3 Apr 26 22:26:07.613 Self-ping enqueued
2 Apr 26 22:26:07.564 Originate Call
1 Apr 26 22:26:07.564 CSPF: computation result accepted 172.19.250.25 172.19.250.9
Created: Wed Apr 26 22:26:07 2017
Retrytimer: 3
Total 2 displayed, Up 2, Down 0
[edit protocols mpls]
aandreev@a.lab#
До наступления событий актуализации полосы auto-bandwidth и нормализации меняется только статистика. Обратите внимание на значения Max AvgBW util и Sampled Aggregate bandwidth, первое — актуальная полоса sub-LSP, второе — актуальная полоса контейнера.
Через некоторое время механизм auto-bandwidthскорректировал полосу единственного sub-LSP, в истории это видно по записи
23 Apr 26 22:25:59.146 Manual Autobw adjustment succeeded: BW changes from 1000 bps to 7105130 bps
Еще через какое-то время настал момент нормализации, и так как полоса реально занимаемая LSP находится вне диапазона слияния/расщепления алгоритм принял решение добавить еще одну sub-LSP.
22 Apr 26 22:26:07.615 Normalization complete: container (to-b-cnt) with 2 members
21 Apr 26 22:26:07.562 Normalize: container (to-b-cnt) into 2 members - each with bandwidth 3552392 bps
Теперь добавим еще около 2Mbps трафика, судя по показаниям Sampled Aggregate bandwidth и
Max AvgBW util статистика поползла вверх.
aandreev@a.lab# run show mpls container-lsp ingress extensive | match "Max AvgBW util|Bandwidth:"
Aggregate bandwidth: 7.13661Mbps, Sampled Aggregate bandwidth: 9.07548Mbps
Max AvgBW util: 4.79669Mbps, Bandwidth Adjustment in 5 second(s).
Bandwidth: 3.57257Mbps
Max AvgBW util: 4.80336Mbps, Bandwidth Adjustment in 5 second(s).
Bandwidth: 3.56403Mbps
[edit protocols mpls]
aandreev@a.lab#
Еще через некоторое время auto-bandwidth поправил полосу обоих sub-LSB.
aandreev@a.lab# run show mpls container-lsp ingress extensive | match "Max AvgBW util|Bandwidth:"
Aggregate bandwidth: 9.60991Mbps, Sampled Aggregate bandwidth: 9.57293Mbps
Max AvgBW util: 4.79669Mbps, Bandwidth Adjustment in 254 second(s).
Bandwidth: 4.79669Mbps
Max AvgBW util: 4.81322Mbps, Bandwidth Adjustment in 253 second(s).
Bandwidth: 4.81322Mbps
[edit protocols mpls]
aandreev@a.lab#
А алгоритм нормализации добавил еще одну sub-LSP.
aandreev@a.lab# run show mpls container-lsp ingress extensive | match "Max AvgBW util|Bandwidth:"
Aggregate bandwidth: 9.57292Mbps, Sampled Aggregate bandwidth: 9.57293Mbps
Max AvgBW util: 4.79669Mbps, Bandwidth Adjustment in 110 second(s).
Bandwidth: 3.19098Mbps
Max AvgBW util: 4.81322Mbps, Bandwidth Adjustment in 210 second(s).
Bandwidth: 3.19098Mbps
Max AvgBW util: 0bps, Bandwidth Adjustment in 10 second(s).
Bandwidth: 3.19098Mbps
[edit protocols mpls]
aandreev@a.lab#
В том случае когда энтропия передаваемых в LSP пакетов высока, можно активировать пассивный режим auto-bandwidth, в этом случае актуализация полосы будет производится только во время процесса нормализации, тем самым можно добиться некоторой экономии процессорного времени.