День добрый,Подскажите, что еще может влиять на решение о помещении марщрута ospf в routing table кроме cost?
У меня роутер упорно заносит маршрут в большим cost от туннеля оканчивающегося на нем, хотя имеется 2 более дешевых маршрута:
#sho ip route 192.168.25.0
Routing entry for 192.168.25.0/24
Known via "ospf 1", distance 110, metric 112, type intra area
Last update from 192.168.57.74 on Tunnel7811, 00:14:48 ago
Routing Descriptor Blocks:
* 192.168.57.74, from 192.168.37.209, 00:14:48 ago, via Tunnel7811
Route metric is 112, traffic share count is 1#
#sho ip ospf database summary | beg 192.168.25.0
Link State ID: 192.168.25.0 (summary Network Number)
Advertising Router: 192.168.4.5
LS Seq Number: 80000002
Checksum: 0xDFF6
Length: 28
Network Mask: /24
TOS: 0 Metric: 112LS age: 829
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 192.168.25.0 (summary Network Number)
Advertising Router: 192.168.37.221
LS Seq Number: 80000001
Checksum: 0x7672
Length: 28
Network Mask: /24
TOS: 0 Metric: 101LS age: 137
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 192.168.25.0 (summary Network Number)
Advertising Router: 192.168.37.254
LS Seq Number: 80000276
Checksum: 0xC8B9
Length: 28
Network Mask: /24
TOS: 0 Metric: 51
inter/intra area
>inter/intra areaда, похоже дело в этом - тот который появляется с tu7811 опознается intraarea, а с соседних роутеров interarea. Схема такова:
/ ---(main)----- R1 area 0
branch area 78 |
\ ---(backup)--- R2 area 0Ареа 78 stub no-summary
Как же сделать, чтобы R2 при обоих работающих линках роутил на R1, а не в сторону бранча?
Можно сделать тоннельчег с R2 на интерфейс бранча, смотрящий в R1. И поместить его в area 78. Тогда он построится через R1 и трафег будет идти в него...
>Можно сделать тоннельчег с R2 на интерфейс бранча, смотрящий в R1. И
>поместить его в area 78. Тогда он построится через R1 и
>трафег будет идти в него...:) Не айс.
Кажется придется все бранчи в ареа 0 переводить.