Перейти к содержимому
Калькуляторы

Частый пересчет 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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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)

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не кажется при поднятии 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

и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.