В статье о EVPN я упомянул о необходимости во включении composite-next-hop для работы EVPN, после чего как минимум 10 человек задали мне один и тот же вопрос — что же такое composite-next-hop. И я так полагаю, что composite-next-hop для многих является загадочной технологией, позволяющей резко уменьшить количетсво next-hop-ов. Очень хорошо эта тема раскрыта в книге “MPLS in SDN era”, я же на основании статьи из данной книги вкратце опишу как это работает.

Думаю что все инженеры, имеющие дело с маршрутизаторами знают, что существует routing information base (RIB) и FIB (forwarding information base). RIB составляется на основании информации, полученной от протоколов динамической маршрутизации, а также на основании статических маршрутов и connected интерфейсов. Каждый протокол, будь то bgp или isis инсталируют маршруты в свою базу данных из которых лучшие маршруты на основании protocol preference (administrative distance в терминах циско) уже инсталлируются в таблицу маршрутизации (RIB) и, что очень важно, именно из RIB маршруты начинают анонсироваться далее. Вот к примеру запись в rib маршрута до префикса 10.0.0.0/24:

bormoglotx@RZN-PE2> show route table VRF1.inet.0 10.0.0.0/24           

VRF1.inet.0: 8 destinations, 13 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24        *[BGP/170] 15:42:58, localpref 100, from 62.0.0.64
                      AS path: I, validation-state: unverified
                      to 10.0.0.0 via ae0.1, Push 16
                    > to 10.0.0.6 via ae1.0, Push 16, Push 299888(top)
                    [BGP/170] 15:42:58, localpref 100, from 62.0.0.65
                      AS path: I, validation-state: unverified
                      to 10.0.0.0 via ae0.1, Push 16
                    > to 10.0.0.6 via ae1.0, Push 16, Push 299888(top)

RIB нам предоставляет полную информацию по каждому маршруту, такую как: протокол, который инсталировал данный маршрут, метрика маршрута, наличие эквивалентных путей, коммьюнити и т д, а также причины неактивности маршрута в настоящее время. Но RIB — это control plane в чистом виде, и использовать данную таблицу для форвардинга маршрутизатору не удобно. Поэтому на основании RIB маршрутизатор (если быть точнее это делает RE) формирует FIB и отправляет ее на все PFE. В FIB уже нет избыточной информации о протоколах и метриках — все что PFE надо знать, это сам префикс, next-hop, через который данный префикс доступен, а так же метки, которые надо навесить при отправке пакета:

bormoglotx@RZN-PE2> show route forwarding-table vpn VRF1 destination 10.0.0.0/24                  
Routing table: VRF1.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.0.0.0/24        user     0                    indr  1048576     4
                                                 ulst  1048575     2
                              0:5:86:71:49:c0   Push 16      572     1 ae0.1
                              0:5:86:71:9d:c1   Push 16, Push 299888(top)      583     1 ae1.0

Примечание: Обычно в FIB попадет только один маршрут, но у нас используется балансировка по ECMP и RE отправляет на PFE два маршрута, если есть эквивалентный путь.

Сегодня мы о next-hop-ах и поговорим. На оборудовании Juniper существует несколько типов next-hop-ов:

VMX(RZN-PE2 vty)# show nhdb summary detail    
      Type              Count
    ---------         ---------
     Discard          18
      Reject          17
     Unicast          47
     Unilist          4
     Indexed          0
    Indirect          4
        Hold          0
     Resolve          5
       Local          20
        Recv          17
    Multi-RT          0
       Bcast          9
       Mcast          11
      Mgroup          3
    mdiscard          11
       Table          17
        Deny          0
     Aggreg.          18
      Crypto          0
      Iflist          0
      Sample          0
       Flood          0
     Service          0
    Multirtc          0
      Compst          7
   DmxResolv          0
      DmxIFL          0
     DmxtIFL          0
       LITAP          0
        Limd          0
          LI          0
      RNH_LE          0
        VCFI          0
        VCMF          0

Многие из них интуитивно понятны, часть из представленных выще вы вообще не встретите в своей практике. Мы же остановимся на некоторых из вышеперечисленных и начнем с простого прямого next-hop-а, которые в терминах Juniper называется unicast.

Unicast next-hop.

                604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0)      <<<<<<
                605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0)      <<<<<<
                606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0)      <<<<<<

Самый простой вид next-hop-а — это прямой next-hop. Он указывает прямиком на физический интерфейс, через который префикс доступен. Если бы данный тип next-hop-а был единственным, то для каждого префикса создавался бы отдельный next-hop и не важно в какой таблице маршрутизации этот префикс находится — в vrf или grt. Да, это очень просто и понятно, но не все что с первого взгляда понятно инженеру — значит хорошо. Приведем пример: если у нас будет 100 vrf-ов, в каждом из которых будет по 100 префиксов, то мы получим 10 000 физических next-hop-ов (это только для vrf-ных префиксов). Прибавьте еще маршруты протоколов isis, ldp, rsvp и т д.

Примечание: для простоты рассуждений и более простого понимания будем считать, что у нас нет эквивалентных путей и агрегационных интерфейсов. Об иерархии next-hop-ов при наличии оных мы поговорим чуть позже.

В итоге лимита по next-hop-ам вы можете достичь очень быстро. Но это не главная проблема — сейчас железки выдерживают более 1М IPv4 префиксов в FIB. Дело в том, что в случае падения одного из интерфейсов и пересчете маршрутов, маршрутизатору придется перезаписать все next-hop-ы, которые в данный момент установлены в таблице форвардинга (в нашем случае все 10 000). Да, igp маршруты перезапишутся быстро — их не так много, а вот с vpnv4/l2vpn/evpn маршрутов как правило по несколько десятков (порой и сотен) тысяч. Естественно перезапись такого количества next-hop-ов будет занимать какое то время и вы можете потеряете часть трафика. И это мы в расчет еще не брали возможность наличия на коробке FW, которая сейчас насчитывает 645К маршрутов.

Самое интересное при использовании прямого next-hop-а то, что даже если все эти 10 000 префиксов будут прилетать с одной и той же PE-ки (то есть иметь один и тот же protocol next-hop), то все равно придется обновить все 10 000 next-hop-ов. А ведь если подумать логически, то по факту в данной ситуации у нас то будет всего 100 уникальных next-hop-ов (при условии распределения сервисных меток per-vrf), которые отличаются только сервисной меткой — транспортная метка и исходящий интерфейс будут абсолютно одинаковы. Сейчас прямой next-hop для префиксов в vrf вы не найдете (на Junos во всяком случае) — если быть точнее, то на картах с TRIO чипсетом вы даже при всем желании не сможете включить прямой next-hop для L3VPN и других сервисов — это просто не поддерживается. Но отказаться от него совсем тоже не получится — unicast next-hop указывает прямиком в интерфейс в который надо отправить пакет и при использовании иерархического next-hop (о котором мы поговори позже) на последнем уровне иерархии будет именно unicast next-hop. Ну а как иначе? Следует упомянуть, что помимо исходящего интерфейса данный вид next-hop-а включает и стек меток и инкапсуляцию, но об этом позже.

Выглядит unicast next-hop для маршрут, полученного по isis, вот так:

bormoglotx@RZN-PE2> show route forwarding-table destination 10.0.0.2/31 table default          
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.0.0.2/31        user     0 10.0.0.6           ucst      693    19 ae1.0

bormoglotx@RZN-PE2> show route forwarding-table destination 10.0.0.2/31 table default extensive    
Routing table: default.inet [Index 0] 
Internet:
    
Destination:  10.0.0.2/31
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Multicast RPF nh index: 0             
  Flags: sent to PFE, rt nh decoupled  
  Nexthop: 10.0.0.6
  Next-hop type: unicast               Index: 693      Reference: 19   
  Next-hop interface: ae1.0

Aggregate next-hop

            584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0)      <<<<<<<<
                585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0)
                586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0)
            603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0)      <<<<<<<
                604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0)
                605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0)
                606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0)

Тут все очень просто — думаю вы сами догадываетесь, что эта иерархия появляется, когда у нас префикс виден через агрегационный интерфейс. Агрегационный next-hop по сути это лист из реальных next-hop-ов (физических интерфейсов), которые входят в агрегат. Если вы используете агрегаты, то количество next-hop-ов увеличивается пропорционально количеству линков в агрегате. В выводе выше вы видите два Aggregate next-hop-а, каждый из которых в свою очередь указывают на физические next-hop-ы, которые в эти агрегаты и входят.

Unilist-next-hop

        1048574(Unilist, IPv4, ifl:0:-, pfe-id:0)      <<<<<<<<
            584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0)
                585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0)
                586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0)
            603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0) 
                604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0)
                605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0)
                606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0)

Собственно это тоже очень простая иерархия и чем то сходна с aggregate. Появляется она только тогда, когда у нас есть эквивалентные пути и по своей сути это просто перечисление всех эквивалентных путей. В нашем случае у нас два эквивалентных пути и оба через агрегаты.

Примечание: в нашем случае звезды сошлись так, что unicast id (585, 586) идут по порядку после Aggregate id (584) (в плане цифр, а не в порядке в иерархии), но это не всегда так.

Все перечисленные next-hop-а не помогают сократить количество физических next-hop-ов, а наоборот увеличивают их количество. Следующие два ��ида next-hop-а предназначены для оптимизации FIB и сокращения количества unicast next-hop-ов.

Indirect next-hop.

    1048577(Indirect, IPv4, ifl:327:ae1.0, pfe-id:0, i-ifl:0:-)      <<<<<<
        1048574(Unilist, IPv4, ifl:0:-, pfe-id:0)
            584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0)
                585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0)
                586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0)
            603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0)
                604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0)
                605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0)
                606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0)

Дословно слово indirect переводится как непрямой. Данный тип next-hop-а используется для сокращение количества физических next-hop-ов. Все же 10 000 next-hop-ов, которые мы получили методом несложных вычислений при рассмотрении unicast next-hop-а как то слишком много. Теперь почитаем наши next-hop-а снова. У нас есть 100 vrf-ов, в которых по 100 префиксов (префиксы генерируются per-vrf) и анонсируются с одной и той же PE-ки. Получается, что у всех этих префиксов в таком сценарии будет один и тот же protocol-next-hop (лупбек удаленной PE-ки) и исходящий интерфейс (ну и как следствие одинаковая транспортная метка). Разница будет только в сервисной метке. Но так как метки мы генерируем per-vrf, то у нас всего будет 100 меток. В итоге мы получаем что 10 000 прямых next-hop-ов можно съагрегировать в 100 next-hop-ов, которые будут иметь абсолютно одинаковый стек меток.

Концепция indirect next-hop-а позволяет для всех префиксов, которые достижимы через один и тот же protocol next-hop использовать один и тот же indirect-next-hop. Хотелось бы акцентировать внимание читателя, что агрегация происходит именно по protocol next-hop, так как сервисной метки может вообще не быть (например маршр��ты в интернет), но ее наличие оказывает большое влияние на indirect-next-hop.

Увы, но основной проблемой indirect-next-hop-а является то, что он ссылается на unicast-next-hop, в котором указывается полный стек меток, включая и сервисную метку:

bormoglotx@RZN-PE2>show route forwarding-table table VRF1 destination 10.2.0.0/24 extensive    
Routing table: VRF1.inet [Index 9] 
Internet:
    
Destination:  10.2.0.0/24
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Multicast RPF nh index: 0             
  Flags: sent to PFE 
  Next-hop type: indirect              Index: 1048587  Reference: 2    
  Nexthop: 10.0.0.6
  Next-hop type: Push 24008, Push 299920(top) Index: 706 Reference: 2    
  Load Balance Label: None              
  Next-hop interface: ae1.0

Эта строчка описывает полный стек меток:

  Next-hop type: Push 24008, Push 299920(top) Index: 706 Reference: 2

Как видите метка 24008 является сервисной меткой и включена в стек на последнем уровне иерархии next-hop. Исходя из этого невозможно, чтобы несколько indirect-next-hop-ов указывали в один и тот же физический — сервисная метка у всех то разная. К тому же например у L2CKT и VPLS используют разную инкапсуляцию. Поэтому при определенных условиях, описанных выше, indirect-next-hop может не дать никакого профита.

Не трудно догадаться, что если мы будем использовать распределение меток per-prefix (по какой то неизвестной мне причине этот метод распределения меток используется по дефолту на Cisco и Huawei), то indirect-next-hop нам не особо помжет, так как теперь у нас на каждый префикс будет отдельная сервисная метка. В итоге мы не можем несколько префиксов объединить в один next-hop, так как они хоть и достижимы через один и тот же protocol next-hop, но имеют разную сервисную метку, что в итоге в самом плохом для нас сценарии приводит к появлению 10 000 next-hopов, правда не прямых а indirect. Получилось как в пословице-”хрен редьки не слаще“… Плюс ко всему прочему у всех L2CKT, даже если они будут терминироваться на одной и той же паре PE-шек, будут разные метки (и тут уже вообще ничего не поделаешь — генерировать одну метку на несколько L2CKT-ов никак не получится). Как разработчики победили эту проблему будет описано далее.

Конечно, в реальных условиях indirect-next-hop позволяет нам значительно сократить количество next-hop-ов (так как мало кто не использует vrf-table-label или распределение меток per-vrf). К тому же на Juniper MX indirect-net-hop включен по умолчанию и отключить эту функцию не получится. К тому же если у вас есть FW на маршрутизаторе, то у этих префиксов вообще не будет сервисной метки (если вы FW в vrf не засунули конечно) и для всех префиксов в интернет будет один и тот же inirect-next-hop.

Но ведь нет предела совершенству и нам хочется еще более масштабируемое решение. К тому же повторюсь, но L2CKT-ты всегда будут иметь разные сервисные метки, а значит и разные indirect next-hop-ы. Решение, которые позволяет исправить эту проблему называется chained-composite-next-hop (в терминах Juniper, у Cisco несколько иначе).

Chained-composite-next-hop

607(Compst, IPv4->MPLS, ifl:0:-, pfe-id:0, comp-fn:Chain)      <<<<<<<
    1048577(Indirect, IPv4, ifl:327:ae1.0, pfe-id:0, i-ifl:0:-)
        1048574(Unilist, IPv4, ifl:0:-, pfe-id:0)
            584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0)
                585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0)
                586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0)
            603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0)
                604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0)
                605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0)
                606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0)

Как мы выяснили indirect-next-hop — это матрешка из next-hop-ов. Точно такая же матрешка и chained-composite-next-hop, но теперь у нас появился еще один уровень в иерархии. Как еще можно объединить префиксы по группам и ассоциировать их с одним и тем же next-hop-ом? Что еще общего у всех L3VPN или всех L2CKT-ов? Верно — это семейство адресов. На самой вершине иерархии next-hop-а находится composite next-hop, который объединяет маршруты по сервисной метке, но в отличии от indirect-next-hop-а, composite next-hop ссылается на эту метку. То есть сервисная метка теперь указывается не на самом последнем уровне иерархии — uniast, а на первом уровне иерархии. Это позволяет победить ту проблему, которую мы обозначили при обсуждении indirect-next-hop. Для примера посмотрим на запись в FIB для того же префикса 10.2.0.0/24 но уже со включенным composite-next-hop:

bormoglotx@RZN-PE2> show route forwarding-table table VRF1 destination 10.2.0.0/24 extensive    
Routing table: VRF1.inet [Index 9] 
Internet:
    
Destination:  10.2.0.0/24
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Multicast RPF nh index: 0             
  Flags: sent to PFE 
  Nexthop:  
  Next-hop type: composite             Index: 608      Reference: 2    
  Load Balance Label: Push 24008, None  
  Next-hop type: indirect              Index: 1048578  Reference: 3    
  Nexthop: 10.0.0.6
  Next-hop type: Push 299920           Index: 664      Reference: 3    
  Load Balance Label: None              
  Next-hop interface: ae1.0

В строке Load Balance Label указана сервисная метка

Load Balance Label: Push 24008, None

Методом банальной эрудиции можно прийти к следующему выводу: сколько у нас будет сервисных меток, cтолько будет и composite next-hop-ов. На следующем уровне иерархии располагается indirect next-hop, правда немного не тот, который мы обсудили ранее. При использовании композитного next-hop-а прерогатива indirect-next-hop-а заключается в том, что он производит агрегацию по семейству адресов и protocol-next-hop-у. То есть, как вы понимаете, для всех vpnv4 префиксов, которые имеют одинаковый protocol next-hop будет один и тот же indirect-next-hop. Ну а далее indirect-next-hop будет указывать в реальный next-hop (как правило или в unilist или aggregate). Самое главное то, что теперь несколько indirect-next-hop-ов могут указывать на один и тот же unilist next-hop, так как теперь в unilist next-hop-е указывается не полный стек меток, а только транспортная метка, а как вы понимаете, до одной и той же PE-ки будет одна и та же транспортная метка.

Теперь вернемся к рассматриваемому нами случаю со 100 vrf-ми. В самом плохом сценарии при использовании indirect-next-hop мы получили 10 000 indirect next-hop-ов ну и, как следствие, столько же реальных next-hop-ов. Теперь посмотрим, что даст нам composite-next-hop. Сначала идет иерархия composite next-hop, и при условии, что метки у нас генерируются per-prefix, мы получим 10 000 различных сервисных меток а значит столько же composite-next-hop-ов. Но, в отличии от предыдущего случая, composite next-hop будет ссылаться не на реальный next-hop, а на indirect-next-hop, который агрегирует vpnv4 префиксы назначения по семейству адресов и protocol next-hop. А это очень резко сокращает количество реальных next-hop-ов. В нашем сценарии всего одно семейство адресов — vpnv4 и один protocol-net-hop, а значит все 10 000 composite-next-hop-ов будут ссылаться на один единственный indirect next-hop, а он, в свою очередь будет указывать в один реальный next-hop! То есть мы в итоге получили всего один реальный next-hop!

Могу сказать из собственной практики, что включение composite-next-hop для ingress lsp позволяет в 5-8 раз сократить общее число next-hop-ов (к примеру, ральный показатель, уменьшение с 1,1М next-hop-ов (до включения данной функции) до 170К (после ее включения), то есть сокращение в 6,5 раза — согласитесь, неплохой показатель).

Примечание: при включении composite-next-hop вы не будите видеть в таблице форвардинга стек меток, так как он указывается в двух иерархиях и выводится только при extensive выводах, для примера:

Indirect-next-hop:
bormoglotx@RZN-PE2> show route forwarding-table table VRF1 destination 10.0.0.0/24                
Routing table: VRF1.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.0.0.0/24        user     0                    indr  1048578     4
                                                 ulst  1048577     2
                              0:5:86:71:49:c0   Push 16      699     1 ae0.1
                              0:5:86:71:9d:c1   Push 16, Push 299888(top)      702     1 ae1.0
Composite-next-hop:
bormoglotx@RZN-PE2> show route forwarding-table table VRF1 destination 10.0.0.0/24                   
Routing table: VRF1.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.0.0.0/24        user     0                    comp      608     2

Примечание: если в составе шасси Juniper MX есть DPC платы (кроме сервисных), то включить composite-next-hop не получится, о чем говорит данное сообщение на сайте Juniper:

On MX Series 3D Universal Edge Routers containing both DPC and MPC FPCs, chained composite next hops are disabled by default. To enable chained composite next hops on the MX240, MX480, and MX960, the chassis must be configured to use the enhanced-ip option in network services mode.

Тут прямо не сказано, что включить не получится, но кому то может оказаться сюрпризом, но DPC платы не поддерживают работу в режиме enhanced-ip:

Only Multiservices DPCs (MS-DPCs) and MS-MPCs are powered on with the enhanced network services mode options. No other DPCs function with the enhanced network services mode options.

Но не стоит думать, что composite next-hop нужен исключительно на PE маршрутизаторах, хотя пригодится он в основном на них (просто на Р-как как правило маршрутов не так много). Composite-next-hop можно включить для ingress lsp (на PE) и для transite lsp (на P). Кроме того возможно у вас будут стероидные PE-ки, которые будут выполнять и роль P-маршутизаторов (ну или ваш дизайн сети вообще не предусматривает FREE CORE), либо у вас ядро (P-level) будет получать маршруты в другие автономные системы (Option C) не через редистрибуцию BGP-LU маршрутов в igp на бордерах, а через BGP-Labeled unicast сессии с рефлекторами.

Если для ingress lsp мы можем включить composite-next-hop только для сервисов типа L3VPN, L2VPN, EVPN, а так же BGP-LU:

  evpn                 Create composite-chained nexthops for ingress EVPN LSPs
  fec129-vpws          Create composite-chained nexthops for ingress fec129-vpws LSPs
  l2ckt                Create composite-chained nexthops for ingress l2ckt LSPs
  l2vpn                Create composite-chained nexthops for ingress l2vpn LSPs
  l3vpn                Create composite-chained nexthops for ingress l3vpn LSPs
  labeled-bgp          Create composite-chained nexthops for ingress labeled-bgp LSPs

То для транзитных устройств доступны опции composite next-hop для LDP, RSVP и даже static lsp:

 l2vpn                Create composite-chained nexthops for transit l2vpn LSPs
  l3vpn                Create composite-chained nexthops for transit l3vpn LSPs
  labeled-bgp          Create composite-chained nexthops for transit labeled BGP routes
  ldp                  Create composite-chained nexthops for LDP LSPs
  ldp-p2mp             Create composite-chained nexthops for LDP P2MP LSPs
  rsvp                 Create composite-chained nexthops for RSVP LSPs
  rsvp-p2mp            Create composite-chained nexthops for RSVP p2mp LSPs
  static               Create composite-chained nexthops for static LSPs

Это позволяет существенно сократить количество next-hop-ов для транзитных lsp. Для примера у меня в лабе всего 5 устройств — то есть таблица mpls.0 на P-ке выглядит мягко говоря маленькой:

bormoglotx@RZN-P2> show route table mpls.0 | find ^2[0-9]+ 
299872             *[LDP/9] 1w1d 12:59:13, metric 1
                    > to 10.0.0.5 via ae0.0, Pop      
299872(S=0)        *[LDP/9] 1w1d 12:59:13, metric 1
                    > to 10.0.0.5 via ae0.0, Pop      
299888             *[LDP/9] 1w1d 12:58:30, metric 1
                    > to 10.0.0.5 via ae0.0, Swap 299792
299904             *[LDP/9] 1w1d 12:55:57, metric 1
                    > to 10.0.0.7 via ae1.0, Pop      
299904(S=0)        *[LDP/9] 1w1d 12:55:57, metric 1
                    > to 10.0.0.7 via ae1.0, Pop      
299920             *[LDP/9] 1w1d 12:47:06, metric 1
                    > to 10.0.0.5 via ae0.0, Swap 299824

Но вот эффект от включения composite-next-hop для LDP будет уже виден даже в такой маленькой лаборатории. Вот суммарное количество net-hop-ов до включения composite-next-hop:

VMX(RZN-P2 vty)# show nhdb summary    
 Total number of  NH = 116

VMX(RZN-P2 vty)# show nhdb summary detail    
      Type              Count
    ---------         ---------
     Discard          12
      Reject          11
     Unicast          32      <<<<<<<<<<<<<<
     Unilist          0
     Indexed          0
    Indirect          0
        Hold          0
     Resolve          2
       Local          13
        Recv          8
    Multi-RT          0
       Bcast          4
       Mcast          7
      Mgroup          1
    mdiscard          7
       Table          11
        Deny          0
     Aggreg.          8      <<<<<<<<<<<<<<
      Crypto          0
      Iflist          0
      Sample          0
       Flood          0
     Service          0
    Multirtc          0
      Compst          0      <<<<<<<<<<<<<<
   DmxResolv          0
      DmxIFL          0
     DmxtIFL          0
       LITAP          0
        Limd          0
          LI          0
      RNH_LE          0
        VCFI          0
        VCMF          0

Теперь включим chained-composite-next-hop для ldp и проверим результат:

bormoglotx@RZN-P2> show configuration routing-options 
router-id 62.0.0.65;
autonomous-system 6262;
forwarding-table {
    chained-composite-next-hop {
        transit {
            ldp;
        }
    }

В таблице маршрутизации все тоже самое, правда маршруты обновились, что видно по их времени жизни (это стоит учитывать при включении composite-next-hop на транзитных устройствах):

bormoglotx@RZN-P2> show route table mpls.0 | find ^2[0-9]+ 
299872             *[LDP/9] 00:00:57, metric 1
                    > to 10.0.0.5 via ae0.0, Pop      
299872(S=0)        *[LDP/9] 00:00:57, metric 1
                    > to 10.0.0.5 via ae0.0, Pop      
299888             *[LDP/9] 00:00:57, metric 1
                    > to 10.0.0.5 via ae0.0, Swap 299792
299904             *[LDP/9] 00:00:57, metric 1
                    > to 10.0.0.7 via ae1.0, Pop      
299904(S=0)        *[LDP/9] 00:00:57, metric 1
                    > to 10.0.0.7 via ae1.0, Pop      
299920             *[LDP/9] 00:00:57, metric 1
                    > to 10.0.0.5 via ae0.0, Swap 299824

А теперь проверим суммарное количество маршрутов в FIB:

VMX(RZN-P2 vty)# show nhdb summary    
 Total number of  NH = 94

VMX(RZN-P2 vty)# show nhdb summary detail    
      Type              Count
    ---------         ---------
     Discard          12
      Reject          11
     Unicast          10      <<<<<<<<<<<<<<
     Unilist          0
     Indexed          0
    Indirect          0
        Hold          0
     Resolve          2
       Local          13
        Recv          8
    Multi-RT          0
       Bcast          4
       Mcast          7
      Mgroup          1
    mdiscard          7
       Table          11
        Deny          0
     Aggreg.          2      <<<<<<<<<<<<<<
      Crypto          0
      Iflist          0
      Sample          0
       Flood          0
     Service          0
    Multirtc          0
      Compst          6      <<<<<<<<<<<<<<
   DmxResolv          0
      DmxIFL          0
     DmxtIFL          0
       LITAP          0
        Limd          0
          LI          0
      RNH_LE          0
        VCFI          0
        VCMF          0

Так как у нас было несколько транзитных меток, то для каждой указывался свой unicast next-hop и JunOS не сильно волновало, что у нас то всего два интерфейса, в которые мы можем отправить транзитный трафик и в итоге получилось что у нас 8 агрегационных next-hop-ов, что естественно повлекло за собой увеличение и unicast next-hop-ов. После включения composite-next-hop вместо того, чтобы для каждой метки генерировать собственный next-hop, composite-next-hop-ы уже ссылаются на имеющиеся два агрегационных next-hop-а.

Хотелось бы еще добавить, что при включении composite-next-hop для ingress LSP дернутся все BGP сессии, при включении composite-next-hop для transit LSP — сессии не дернутся (даже при включении BGP-LU), но все mpls метки будут сброшены и снова установлены в таблицу форвардинга.

В заключении хотелось бы наглядно сравнить indirect-next-hop и composite-next-hop в картинках.
В лаборатории было запущено три L3VPN, причем с PE3 префиксы (10.2.0.0/24 и 10.3.0.0/24) анонсируются с меткой per-prefix, а c PE1 — per-vrf:

и три L2CKT — два до PE1 и один до PE3:

К тому же, схема собрана на агрегационных интерфейсах, а до PE1 есть эквивалентные пути.

На данной иллюстрации представлено “дерево” next-hop-ов при использовании indirect-next-hop:

Для префиксов 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 — у нас одна серисная метки, так же и для перфиксов 20.0.0.0/24, 20.0.1.0/24, 20.0.2.0/24 — тоже одни сервисная метка — все они анонсируются с PE1. Как видите эти префиксы доступны через одни и те же indirect-next-hop-ы. А вот 10.2.0.0/24 и 10.3.0.0/24 имеют разные метки (метки для них генерируются per-prefix), а значит имеют разные indirect-next-hop-ы. Ну с L2CKT думаю все и так ясно — у всех разные сервисные метки и indirect-next-hop-ы. В итоге имеем 29 unicast next-hop-ов.

Теперь тоже самое, но с включенным composite-next-hop:

Тут next-hop-ов уже меньше. Префиксы, которые имеют одну и ту же сервисную метку доступны через одни и те же composite-next-hop-а. Как вы помните, сервисная метка указывается в иерархии composite-next-hop. Далее все composite-next-hop-ы ссылаются в indirect next-hop-ы. В схеме выше у нас два protocol-next-hop (PE1 и PE3) и два сервиса L3VPN и L2CKT. В итоге получается что у нас 4 indirect next-hop-а:

L3VPN, PE1
L3VPN, PE2
L2CKT LDP, PE1
L2CKT LDP, PE2
А так как теперь на уровне иерархии unicast next-hop у нас только транспортная метка, то теперь indirect next-hop-ы могу ссылаться на одни и те же unicast-next-hop-ы. В итоге количество unicast-next-hopов с 29 сократилось до 8.

Спасибо за внимание.

Juniper: composite-next-hop