В общем, загадочная система.
нашел команду ip cef load-sharing algorithm
требует задать один из 4-х вариантов:
original
universal [id]
tunnel [id]
include-portsпо умолчанию в sh run all не показывается. но прочитал что по умолчанию стоит в universal c неким уникальным для железки id. Этот id влияет на способ формирования hash-записей для форвардинга. Подробно в это углубляться не стал, попробовал экспериментально.
запустил трафик с одного адреса источника на 4 разных получателя.
с original - весь трафик идет по одному маршруту.
c tunnel - честно и равномерно распределяется по двум имеющимся маршрутам
с universal - без параметра id (когда циска сама его придумывает, уникальный для железки) - весь трафик идет по одному маршруту, но другому, чем с original
если менять id у universal (диапазон громадный, 1-FFFFFFFF, попробовал на вскидку несколько вариантов с маленькими и с большими значениями), то поведение меняется.
то весь трафик по одному маршруту, то по другому, то распределяется равномерно, то с перекосом (поскольку получателей в тесте всего 4, то получается 3:1) на один маршрут. Короткого внятного описания, как устроено хеширование, как на него влияет id и что должно в итоге получаться - не нашел. Есть слова про то, как устроено хеширование, но что из этого следует - сходу не понял, надо толстые книжки читать, видимо...
include-ports (в зависимости от source/dest портов) даже пробовать не стал, не мой случай.
остается надеяться, что на реальном канале с сотнями разных адресов в проходящих пакетах, будет работать честно (и для ситуации "два линка - два провода(туннеля) между маршрутизаторами, как я понял, оптимальный вариант tunnel).
но все оказывается гораздо более заморочено, чем кажется поначалу.