neprden Опубликовано 5 апреля, 2010 · Жалоба Есть 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 Подозреваю что трапы и пересчет оспф зависят от поведения виртуальных интерфейсов, однако в оспф настроено так, что все интефейсы, кроме смотрящих в магистраль, пассивные. Подскажите: как избавится в данном случае от частого пересчета ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 5 апреля, 2010 · Жалоба А можно конфиги двух соседних железок, с настройкой ospf и bgp? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
neprden Опубликовано 6 апреля, 2010 · Жалоба собсно настройки оспф на обоих железках одинаковые : 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) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
neprden Опубликовано 6 апреля, 2010 · Жалоба собсно up Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 6 апреля, 2010 · Жалоба Мне кажется при поднятии ppp сессии происходит пересчет, хотя не понятно зачем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
neprden Опубликовано 7 апреля, 2010 · Жалоба не кажется при поднятии 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 и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
neprden Опубликовано 7 апреля, 2010 · Жалоба моя разобрался, все дело было в сумеречном состоянии души и ip unnumbered Loopback1 на virtual-template. На loopback1 ессно висит адрес который анонсится по ospf. Видимо при падении/поднятии virtual-access одним из концов которого является адрес из 1.1.1.0/24 сети, оспф считает своим долгом пересчитатся. Спасибо за помощь и участие. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...