Black Fox писал(а):
Немного не понял вопрос. У вас есть метрика E1, которая распространяется с внешним маршрутом. У вас есть локальная топология, которая расчитывается внутри зоны, потом эти значения складываются и результат помещается в таблицу маршрутизации. Указанные Вами метрики распространяются в отдельных LSA. OSPF же не дистанс-вектор, всё считается по-другому. Или я вопрос не понял?
Все на самом деле гораздо сложнее. Видно, придется рассказывать всю топологию. Ну да ладно.
Вложение:
Комментарий к файлу: Структура сети
structure.jpg [ 50.1 КБ | Просмотров: 6835 ]
Есть два роутера с белыми адресами в инете: ESKO-gw и FREGAT-gw, на их базе созданы два независимых DMVPN-облака (фаза 2), на всех роутерах им соответствуют Tunnel0 (основной) и Tunnel1(резервный). У DMVPN0 хаб ESKO-gw, у DMVPN1 хаб FREGAT-gw.
ESKO-gw цепляется к FREGAT-gw через резервного провайдера (NAT-res-gw) - через мобильного оператора (дорогой траффик, идет через провайдерский NAT и должен использоваться в самую последнюю очередь).
Так же есть два споука (RL21-1 и RL21-2), они так же выходят в инет через мобильного оператора и его NAT.
К ESKO-gw и FREGAT-gw цепляются два linux-based роутера (RUH2-4775 и RUH2-List) посредством IpSEC Site-to-Site(в GNS я их подключил через serial для большей наглядности). Ввиду некоторых причин, на них невозможно запустить ospf, на ESKO-gw и FREGAT-gw мы имеем к ним только статический маршрут. Более того, траффик к ним натится, что бы не усложнять на них таблицу маршрутизации.
Поверх всего этого безобразия запущен ospf и статические маршруты к этим недороутерам редестрибуцированы в ospf.
Таким образом, на споуках к linux-роутерам есть такие записи:
Код:
O E1 172.17.1.0/26 [110/1020] via 172.17.254.130, 00:02:12, Tunnel1
[110/1020] via 172.17.254.129, 00:02:12, Tunnel1
[110/1020] via 172.17.254.2, 00:01:20, Tunnel0
[110/1020] via 172.17.254.1, 00:01:20, Tunnel0
Получается, что маршрут доступен как через ESKO-gw, так и через FREGAT-gw, причем к каждому роутеру есть доступ и через Tunnel0 и через Tunnel1.
Наверное, для лучшего понимания имеет смысл указать ip адреса на интерфейсах (маска везде /25):
Код:
ESKO-gw#sh ip int br
Interface IP-Address OK? Method Status Protocol
...
Tunnel0 172.17.254.1 YES NVRAM up up
Tunnel1 172.17.254.129 YES NVRAM up up
FREGAT-gw#sh ip int br
Interface IP-Address OK? Method Status Protocol
...
Tunnel0 172.17.254.2 YES NVRAM up up
Tunnel1 172.17.254.130 YES NVRAM up up
Все бы ничего, если бы не NAT. Т.е. пинги ходить будут без проблем, а вот TCP-сессии...
Ввиду того, что в DMVPN1-облаке на одного мобильного провайдера больше, приоритет за DMVPN0.
Расставляем ip ospf cost на всех четырех маршрутизарорах в DMVPN следующим образом:
Код:
int t0
ip ospf cost 128
int t1
ip ospf cost 4096
Смотрим таблицу маршрутизации на споуках:
Код:
O E1 172.17.1.0/26 [110/148] via 172.17.254.2, 00:01:07, Tunnel0
[110/148] via 172.17.254.1, 00:01:07, Tunnel0
Tunnel1 теперь не в приоритете, но и через Tunnel0 можно отправлять траффик двумя путями.
Теперь поднимем метрику редистрибуции на резервном хабе (заодно приведу настройки ospf):
Код:
router ospf 100
router-id 172.17.2.1
redistribute static metric-type 1 subnets route-map STATIC-REDISTR-rm
network 172.17.0.0 0.0.255.255 area 0
...
route-map STATIC-REDISTR-rm permit 10
match ip address prefix-list SUB-pl
set metric +1024
Казалось бы, все хорошо:
Код:
O E1 172.17.1.0/26 [110/148] via 172.17.254.1, 00:05:23, Tunnel0
Но, если вдруг на головном роутере основной канал отвалится и останется только резервный, то произойдет следующее:
Код:
O E1 172.17.1.0/26 [110/4116] via 172.17.254.129, 00:00:01, Tunnel1
Т.е. теперь траффик идет все так же на головной роутер, но через резервный канал (более дорогой в денежном смысле), хотя есть возможность идти через бэкап.
Вот и получается, что ospf прибавляет метрики только к ПОЛУЧЕННЫМ маршрутам через редистрибьюцию, а как настроить так что бы в один интерфейс уходил LSA с большей метрикой, чем в другой, я пока что не допер.