Частый пересчет SPF на BRASе

[neprden]

Есть Bras на cisco 7206, на котором терминируются pppoe клиенты. НА ней же поднят ospf и ibgp. по ibgp анонсируются клиентские префиксы по ospf ТОЛЬКО ! лупбеки серверов доступа и соотв лупбек этого браса.

НА брасе вижу достаточно большое кол-во пересчета spf (на несколько порядков больше чем на других ospf соседях, на прочих оно вообще замерло). 72-я то и дело плюется трапами что-то типо : enterprise=1.3.6.1.2.1.14.16.2, enterprise_mib_name=ospfTraps, agent_ip=x.x.x.x, generic_num=6, specificTrap_num=16, specificTrap_name=ospfIfStateChange, version=Ver1, ospfRouterId=x.x.x.100, ospfIfIpAddress=0.0.0.0, ospfAddressLessIf=151, ospfIfState=down

enterprise=1.3.6.1.2.1.14.16.2, enterprise_mib_name=ospfTraps, agent_ip=x.x.x.100, generic_num=6, specificTrap_num=16, specificTrap_name=ospfIfStateChange, version=Ver1, ospfRouterId=x.x.x.100, ospfIfIpAddress=0.0.0.0, ospfAddressLessIf=151, ospfIfState=pointToPoint

Подозреваю что трапы и пересчет оспф зависят от поведения виртуальных интерфейсов, однако

в оспф настроено так, что все интефейсы, кроме смотрящих в магистраль, пассивные. Подскажите: как избавится в данном случае от частого пересчета ?

[pliskinsad]

А можно конфиги двух соседних железок, с настройкой ospf и bgp?

[neprden]

собсно настройки оспф на обоих железках одинаковые :

router ospf 1

log-adjacency-changes

passive-interface default

no passive-interface FastEthernet0/1.777

network 1.1.1.0 0.0.0.255 area 0

сеть 1.1.1.0/24 поделена на 4 подсети в одой из которых лупбеки в другой транспортная сеть. на fa 0/1.777 всех железок адреса из 1.1.1.128/26

сети клентов ну допустим 2.2.0.0/22

настройки бгп в общем тоже простые :

router bgp XXX

bgp log-neighbor-changes

redistribute connected route-map CLIENTS

redistribute static route-map CLIENTS

neighbor 1.1.1.101 remote-as XXX

neighbor 1.1.1.101 update-source Loopback1

neighbor 1.1.1.101 next-hop-self

no auto-summary

no synchronization

 

route-map CLIENTS, permit, sequence 10

Match clauses:

ip address prefix-lists: CLIENTS

 

ip prefix-list CLIENTS:

seq 5 permit 2.2.0.0/22 le 32

видим, что редистрибъюции никакой в оспф нет. однако, что видно из дебага, при падении любого virtual-access происходит пересчет SPF, причом только на brasе.

Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1)

 

 

[neprden]

собсно up

[SokolovS]

Мне кажется при поднятии ppp сессии происходит пересчет, хотя не понятно зачем.

[neprden]

не кажется при поднятии ppp сессии происходит пересчет, хотя не понятно зачем.

в том то и дело что при поднятии пересчета нет. при завершении есть .

 

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

deb ip ospf spf

deb ip ospf events

000173: Apr 7 09:57:40.908 MSD: OSPF: Interface Virtual-Access40 going Down

000174: Apr 7 09:57:41.408 MSD: OSPF: Schedule SPF in area 0

Change in LS ID 1.1.1.100, LSA type R, spf-type Full

000175: Apr 7 09:57:41.408 MSD: OSPF: forcing SPF in area 0

000176: Apr 7 09:57:41.904 MSD: OSPF: Address removed from Virtual-Access40: 0.0.0.0

000177: Apr 7 09:57:41.908 MSD: OSPF: Address added to Virtual-Access40: 0.0.0.0

data1#

000178: Apr 7 09:57:42.408 MSD: OSPF: Schedule SPF in area 0

Change in LS ID 1.1.1.100, LSA type R, spf-type Full

000179: Apr 7 09:57:42.408 MSD: OSPF: forcing SPF in area 0

data1#

000180: Apr 7 09:57:43.416 MSD: OSPF: Rcv hello from 1.1.1.101 area 0 from FastEthernet0/1.777 1.1.1.130

000181: Apr 7 09:57:43.416 MSD: OSPF: End of hello processing

data1#

000182: Apr 7 09:57:46.408 MSD: OSPF: running SPF for area 0, SPF-type Full

000183: Apr 7 09:57:46.408 MSD: OSPF: Initializing to run spf

000184: Apr 7 09:57:46.408 MSD: OSPF - spf_intra() - rebuilding the tree

It is a router LSA 1.1.1.100. Link Count 3

000186: Apr 7 09:57:46.408 MSD: Processing link 0, id 1.1.1.100, link data 255.255.255.255, type 3, cost 1

и т.д.

[neprden]

моя разобрался, все дело было в сумеречном состоянии души и ip unnumbered Loopback1 на virtual-template. На loopback1 ессно висит адрес который анонсится по ospf. Видимо при падении/поднятии virtual-access одним

из концов которого является адрес из 1.1.1.0/24 сети, оспф считает своим долгом пересчитатся. Спасибо за помощь и участие.