Jump to content
Калькуляторы

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

Есть 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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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)

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
не кажется при поднятии 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

и т.д.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this