Есть два маршрутизатора А и Б
Каждый присоединен к интернет двумя интерфейсами. Между собой маршрутизаторы связаны парой туннелей.

Маршрутизатор А

int fa0/1.102
ip add 1.2.3.4 255.255.255.252

int fa0/1.103
ip add 2.3.4.5 255.255.255.252

int tun0
ip add 172.16.0.1 255.255.255.0
tun source fa0/1.102
tun dest 3.4.5.6

int tun1
ip add 172.16.1.1 255.255.255.0
tun source fa0/1.103
tun dest 4.5.6.7

ip route 0.0.0.0 0.0.0.0 1.2.3.3

Маршрутизатор Б

int fa0/1.102
ip add 3.4.5.6 255.255.255.252

int fa0/1.103
ip add 4.5.6.7 255.255.255.252

int tun0
ip add 172.16.0.1 255.255.255.0
tun source fa0/1.102
tun dest 1.2.3.4

int tun1
ip add 172.16.1.1 255.255.255.0
tun source fa0/1.103
tun dest 2.3.4.5

ip route 0.0.0.0 0.0.0.0 3.4.5.6

Соответственно по одному дефолтному маршруту.

Необходимо, чтобы tun1 взаимодействовал именно по второму провайдеру.
Вариант с прописыванием статических маршрутов не подходит.
Есть свои мысли по поводу policy routing, но не хочу пока озвучивать, чтобы не сбивать с толку, хочу услышать свежих мыслей.

• Как при помощи route-map отфильтровать GRE траффик?,fantom, 20:56 , 06-Фев-07
  • Как при помощи route-map отфильтровать GRE траффик?,sergjack, 22:38 , 06-Фев-07
    • Как при помощи route-map отфильтровать GRE траффик?,fantom, 11:41 , 07-Фев-07
      • Как при помощи route-map отфильтровать GRE траффик?,sergjack, 12:10 , 07-Фев-07

А чем статика неподходит?
ip route 2.3.4.5 255.255.255.255 <IPвторого прова>
Ну или роут-мап.

>А чем статика неподходит?
>ip route 2.3.4.5 255.255.255.255 <IPвторого прова>
>Ну или роут-мап.

Статика не подходит тем, что в реальности все чуть посложнее.
Используется DMVPN и таких удаленных маршрутизаторов за 30 штук
Плюс у удаленных маршрутизаторов достаточно часто меняются IP адреса, так что статика - не решение.

Вот я и бьюсь над роут-мапой, которая если пакет имеет source адрес одного провайдера, то отправлять пакет на next-hop одного, если другого - то на next-hop другого.
Роут мапу я прикрутил как ip local policy route-map, и создается впечатление, что все работает (трейс правильно ходит, туннели поднимаются), до тех пор, пока не падает один из провайдеров.
Просто то ли пакеты не подпадают под local policy, то ли при формировании GRE пакета ему уже надо обязательно знать на какой next-hop его надо отправить.

А если падает один из провайдеров, отваливается ВСЕ или только линк, через него ходящий?

Кроме того, обратные маршруты совпадают или нет? если пакет ушел на провайдера 1 есть ли уверенность что ответ придет тоже через провайдера 1 а не провайдера 2????

Что показывают трейсы с другой стороны туннеля?

>А если падает один из провайдеров, отваливается ВСЕ или только линк, через
>него ходящий?
>
>Кроме того, обратные маршруты совпадают или нет? если пакет ушел на провайдера
>1 есть ли уверенность что ответ придет тоже через провайдера 1
>а не провайдера 2????
>
>Что показывают трейсы с другой стороны туннеля?

Если роут-мапы прикручены с обеих сторон - то все работает правильно.
Трэйсы с указанием соответствующенго source интерфейса идут правильно.
На сам маршрутизатор можно попасть по внешнему IP через любого из провайдеров, даже если вообще убрать ip route 0.0.0.0 0.0.0.0

А вот с GRE что-то не так. Толи они не подпадают под локальную политику или в момент формирования пакета маршрутизатору уже нужно знать, куда пакет отправить.

Вот мой вариант:

ip local policy route-map isp

route-map isp permit 10
match ip address bcl
set interface GigabitEthernet0/1.20
set ip next-hop 1.2.3.4

!
route-map isp permit 20
match ip address smart
set interface GigabitEthernet0/1
set ip next-hop 2.3.4.5

ip access-list extended bcl
permit ip 1.2.3.2 0.0.0.3 any

ip access-list extended smart
permit ip 2.3.4.4 0.0.0.3 any

При этом циска доступна извне (могу попасть телнетом) и по адресу 1.2.3.4 и по адресу 2.3.4.5 даже при отстутствии DG или одного из провайдеров.
Кроме того, устанавливаются IPSEC и ISAKMP туннели, а вот траффик внутри туннелей не идет.