Container LSP

В первой части статьи я попытался описать возможности некоторых подходов к балансировке трафика в 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 должны наследовать все (кроме 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]

[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, в этом случае актуализация полосы будет производится только во время процесса нормализации, тем самым можно добиться некоторой экономии процессорного времени.

Автор: a_andreev

Источник