Добрый день.Сначала пройдемся по Вашему решению:
Проблема с туннелями, я полагаю, потому, что local PBR не отрабатывает transport туннеля и он всегда ходит с учетом таблицы маршрутизации.
ip sla стоит сделать следующим образом:
- выбрать статический адрес в сетях провайдера (IPa & IPb);
- создать local pbr, которая рулит icmp any host IPa echo в Dialer1 + icmp any host IPb ech в Dialer2; использовать именно интерфейс без условий и без next-hop.
Туннели:
- по-любому всегда будет работать только половина туннелей (кроме случая с VRF);
- единственное, что можно сделать - обеспечить максимально быстрое переключение между ними (время за которое isakmp согласуется) + скорость сходимости IGP;
- кстати, на туннелях не заметил tunnel protection... они что - не шифруются?
NAT:
- в любом случае Вы не сможете одновременно работать на два туннеля по одному сервису... за исключением случая, когда static nat разрешается в другой адрес\порт
т.е. в моем понимании схема:
ip nat source static tcp 192.168.1.25 25 85.15.66.116 25 extendable no-alias
ip nat source static tcp 192.168.1.25 25 109.197.18.64 25 extendable no-alias
работать не будет (хотя я не силен в NAT), т.к. routing\PBR выполняется до NAT, т.о. это не очень надежно и через оба интерфейса нельзя будет одновременно получать почту.
Версия двух IP для каждого сервиса и NAT каждого провайдера в свой IP + последующий PBR на обратном пути сможет решить проблему.
Корректно работаеющий ip sla + static def.route track object решают проблему пользовательского PAT.
***********************************
Вариант, который напрашивается в случае, если все туннели должны работать одновременно - это VRF или два адреса на remote end.
***********************************
PS: если надумаете фиксить, то начинайте с ip sla - как заработает - двигайтесь дальше. Фрагменты конфига выкладывайте здесь.