Коллеги,
имеется маршрутизатор, к которому поступает один и тот же префикс через IBGP от двух BGP-border-ов, все атрибуты одинаковы, за исключением метрики до next-hop-a. Включил maximum-paths ibgp 4, но маршруты в RIB не добавились, не пойму в чем дело:

R8#router bgp 200
...
maximum-paths ibgp 4

R8#sh ip bgp 66.66.66.66
BGP routing table entry for 66.66.66.66/32, version 8
Paths: (2 available, best #2, table default)
Multipath: eBGP iBGP
  Advertised to update-groups:
     8        
  Refresh Epoch 5
  100
    3.3.3.3 (metric 206080) from 3.3.3.3 (33.33.33.33)
      Origin IGP, metric 0, localpref 100, valid, internal
  Refresh Epoch 4
  100
    5.5.5.5 (metric 156160) from 5.5.5.5 (55.55.55.55)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      DMZ-Link Bw 131250 kbytes
R8#sh ip cef 66.66.66.66
66.66.66.66/32
  nexthop 150.1.58.5 Ethernet0/0

• IBGP unequal multipath load balancing Problem,Merridius, 16:02 , 26-Авг-15
  • IBGP unequal multipath load balancing Problem,Vadim, 16:17 , 26-Авг-15
    • IBGP unequal multipath load balancing Problem,Merridius, 16:19 , 26-Авг-15
      • IBGP unequal multipath load balancing Problem,Vadim, 16:23 , 26-Авг-15
        • IBGP unequal multipath load balancing Problem,Merridius, 16:34 , 26-Авг-15

>[оверквотинг удален]
> valid, internal
>   Refresh Epoch 4
>   100
>     5.5.5.5 (metric 156160) from 5.5.5.5 (55.55.55.55)
>       Origin IGP, metric 0, localpref 100,
> valid, internal, best
>       DMZ-Link Bw 131250 kbytes
> R8#sh ip cef 66.66.66.66
> 66.66.66.66/32
>   nexthop 150.1.58.5 Ethernet0/0

IGP метрика до BGP next-hop'ов должна быть одинаковая.  

> IGP метрика до BGP next-hop'ов должна быть одинаковая.

то есть получается, что механизм называется load-balancing UNequal path, но на самом деле до BGP Border-ов (или только одного Border-a?) должны быть маршруты одинаковой стоимости, а уже сам eBGP border балансирует согласно полосе пропускания линков?

>> IGP метрика до BGP next-hop'ов должна быть одинаковая.
> то есть получается, что механизм называется load-balancing UNequal path, но на самом
> деле до BGP Border-ов (или только одного Border-a?) должны быть маршруты
> одинаковой стоимости, а уже сам eBGP border балансирует согласно полосе пропускания
> линков?

Да, еще поскольку DMZ Link bandwidth - community атрибут, надо не забыть сделать вброс его в локальную AS. (send-community extended)

>>> IGP метрика до BGP next-hop'ов должна быть одинаковая.
>> то есть получается, что механизм называется load-balancing UNequal path, но на самом
>> деле до BGP Border-ов (или только одного Border-a?) должны быть маршруты
>> одинаковой стоимости, а уже сам eBGP border балансирует согласно полосе пропускания
>> линков?
> Да, еще поскольку DMZ Link bandwidth - community атрибут, надо не забыть
> сделать вброс его в локальную AS. (send-community extended)

Спасибо за оперативность, и последнее уточнение - данная схема балансировки применяется когда на границе у может находиться N-ое число eBGP бордеров?

>>>> IGP метрика до BGP next-hop'ов должна быть одинаковая.
>>> то есть получается, что механизм называется load-balancing UNequal path, но на самом
>>> деле до BGP Border-ов (или только одного Border-a?) должны быть маршруты
>>> одинаковой стоимости, а уже сам eBGP border балансирует согласно полосе пропускания
>>> линков?
>> Да, еще поскольку DMZ Link bandwidth - community атрибут, надо не забыть
>> сделать вброс его в локальную AS. (send-community extended)
> Спасибо за оперативность, и последнее уточнение - данная схема балансировки применяется
> когда на границе у может находиться N-ое число eBGP бордеров?

Ну сколько там максимум BGP путей можно, не помню точно.

Кстати, некоторые говорят, что лучший метод балансировки - это MPLS TE туннели.