Добрый день!
Есть схема сети (во вложении).
Основная проблема в том, что eigrp на центральном маршрутизаторе не понимает разницы в каналах филиалов и в таблице маршрутизации по 2 маршрута на каждую сеть филиала.
Настройка какой-либо разницы (BW, delay...) между двумя туннельными инт-сами центрального маршрутизатора проблемы не решает, просто заворачивает все в сторону одного конкретного облака mGRE...

Можно было бы не загоняться и наделать p-pGRE, но парк планируется большой, конфиг нихилый будет в центре, да и туннели между филиалами были бы кстати.

Есть у кого какие мысли как это побороть? Может как-то можно устанавливать метрику на анонсы с туннельных инт-сов филиалов? Или еще какие решения есть?

чего Вы хотите добиться? балансировки? Но вообще видится действительно установкой на туннельных интерфейсах филиалов метрикообразующих параметров

Мне нужна правильная машрутизация, балансировку пока не рассматриваю. чтобы от центра трафик уходил в широкие каналы филиалов. Узкие каналы как резерв.

Знать бы еще каких "метрикообразующих параметров"... В моем понимании это те параметры, по которым EIGRP высчитывает метрику. Как ими не играйся в филиалах, центр все-равно будет понимать, что анонсы пришли с 20 Mbps канала. Как жестко задать метрику в анонсах EIGRP с интерфейса, я пока не встречал

В принципе-то сеть небольшая, насколько я понимаю вам в центре всего лишь нужно уйти правильным GRE в споки.
Можно пойти по одному из 2 путей (изменение лишь в центре)
1) заморочиться с редистрибуцией
2) использовать PBR

Это не схема реальной сети, а пример описывающий проблему на участке реальной сети.
Реальная схема очень большая и замороченная.

Кстати, сейчас вроде костыли придумал: А что если на туннель более широкого канала повесить суммирование eigrp?



В eigrp же 2 метрики: обычная и суммированных маршрутов. Таким образом я раскидаю более широкие каналы по облакам mGRE.

вернее их даже 3. Но решение красивое, должно сработать

точно, их 3: внешние, внутренние и суммированные.
Спасибо, что поправили!

А вот у меня ввечеру родилася мысля....

А что если на каждом маршрутизаторе запускать по 2 протокола маршрутизации (например, ОСПФ и EIGRP), при этом
1. На центральном маршрутизаторе оба протокола запущены в обоих облаках
2. На удаленных маршрутизаторах EIGRP запущен на быстром канале, а OSPF - на медленном

Получится так, что для разных маршрутизаторов ОСПФ будет то в одном, то в другом облаке, но будет менее приоритетен, т.к. имеет АД 110, с другой стороны он анонсит маршруты, доступные через медленные каналы, так что задача вроде решена.

Тоже вариант, но как я говорил, это не реальная схема, а схема проблемы. За филиальными маршрутизаторами в реальной схеме еще несколько маршрутизаторов, локалок, еще dmvpn, еще локалки совсем маленьких филиалов ... Да и центральный маршрутизатор 2мя dmvpn не ограничивается.

В общем при 2х протоколах придется заморачиваться с редистрибуцией, как мне кажется, иначе при обрыве eigrp канала филиала, отвалятся и все "хозяйство" за ним.

Вот сейчас думаю, как при всех этих вариантах решения проблемы еще и балансировку прикрутить ...

для потомков отвечаю как порешал проблему.

На каждое облако прова делается по 2 DMVPN. У каждого прова первое облако отвечает за высокоскоростные каналы, второе - за медленные каналы. Итого получается на центральном маршрутизаторе 4 туннеля mGRE: 2 "высокоскоростных", 2 "медленных", по 1 на каждого прова. В филиалах по 2 туннеля, которые раскидываются по определенным DMVPN.

Плюсы, минусы данного решения думайте сами. У меня другие варианты в реальной схеме просто не "пролазили".
Вот так

ЗЫ Кстати и балансировка при такой схеме работает.

Я метрику вручную рассчитывал и подкручивал с помощью bandwitch и delay.

Балансировка - через коэффициент variance 2 (может принимать от 1 до 128) и опять же расчет метрик)