Hi there,
I'm having a strange issue with OSPF fast hello's. We are currently implementing a new MAN in the Netherlands with two new C6500 sup720-10G core routers and multiple C6500 sup720-3b. The core-routers are currently only connected to two distribution routers on two locations. Next month we will connect multiple sites and the two core-locations using ethernet connections over a DWDM infrastructure.
On both core-routers OSPF is currently active over the direct connections to two distribution routers with a UTP cable. This worked fine for months, until a colleague swapped the cables at the one site two weeks ago. Now every day the OSPF adjacency between the PLW OSPF neighbors is reset multiple times at irregular intervals. Always for both distribution routers at the same time. However a third OSPF neighbor, a backup connection to a C3750 at a remote site, is not being reset. We did obviously replace the cables at this location once more, but without result; the neighborship is still being reset. The only thing that helps is removing the “ip ospf dead-interval minimal hello-multiplier 4” command, or to adjust the hello timers to a higher value, I used 1 second, so the Dead interval is 4 seconds. This is not a satisfactionary solution though, as we want to use the fast convergence of the fast hellos and I really don’t see any reason why this shouldn’t work on our Gigabit MAN.
I also had this issue on an inter-connection between two distribution routers at another site, but since this port-channel link was going to be replaced by a L3 vlan and is not very important anyway, I ignored it. But now that I am having this same problem also on the core-router, I am getting afraid that we will be running into more of these problems when we activate all the Ethernet-over-DWDM-links in our new core in October.
I did some research on the Cisco support site and some other sites but I couldn’t find a note on a similar problem. Are there any issues known with OSPF fast-hellos? Any idee to what direction I need to look to solve this problem? I think it's very strange that both links from core to ditribution routers are always reset at the same time.
I hope someone can help me.
Beste regards,
Joris van Rooden
sh version:
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)
Config:
router ospf 1
router-id 10.100.0.102
log-adjacency-changes detail
auto-cost reference-bandwidth 40000
area 0 authentication message-digest
timers throttle spf 10 100 5000
timers throttle lsa all 10 100 5000
timers lsa arrival 80
passive-interface default
no passive-interface GigabitEthernet1/3
no passive-interface GigabitEthernet1/20
no passive-interface GigabitEthernet2/3
network 10.100.0.102 0.0.0.0 area 0
network 10.100.0.0 0.0.255.255 area 0
!
!
interface GigabitEthernet1/3
description Distribution-router-1 Gi3/13
dampening
mtu 9216
ip address 10.100.102.9 255.255.255.248
ip ospf message-digest-key 1 md5 7 xxxxxxxx
ip ospf network point-to-point
ip ospf dead-interval minimal hello-multiplier 4
logging event link-status
load-interval 30
carrier-delay msec 0
mpls ip
end
sh ip ospf neighbor:
Neighbor ID Pri State Dead Time Address Interface
10.100.0.127 0 FULL/ - 812 msec 10.100.113.10 GigabitEthernet1/20
10.100.0.106 0 FULL/ - 00:00:03 10.100.102.26 GigabitEthernet2/3
10.100.0.105 0 FULL/ - 852 msec 10.100.102.10 GigabitEthernet1/3
Sh log:
002913: Sep 13 07:52:29.842 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from INIT to 2WAY, 2-Way Received
002914: Sep 13 07:52:29.842 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from 2WAY to EXSTART, AdjOK?
002915: Sep 13 07:52:29.842 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from EXSTART to EXCHANGE, Negotiation Done
002916: Sep 13 07:52:30.138 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from EXCHANGE to LOADING, Exchange Done
002917: Sep 13 07:52:30.138 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from LOADING to FULL, Loading Done
002918: Sep 13 08:16:40.210 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.105 on GigabitEthernet1/3 from FULL to INIT, 1-Way
002919: Sep 13 08:16:40.498 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from FULL to INIT, 1-Way
002920: Sep 13 08:16:40.758 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.105 on GigabitEthernet1/3 from INIT to 2WAY, 2-Way Received
002921: Sep 13 08:16:40.762 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.105 on GigabitEthernet1/3 from 2WAY to EXSTART, AdjOK?
002922: Sep 13 08:16:40.762 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.105 on GigabitEthernet1/3 from EXSTART to EXCHANGE, Negotiation Done
002923: Sep 13 08:16:40.818 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.0.105 on GigabitEthernet1/3 from EXCHANGE to LOADING, Exchange Done
002924: Sep 13 08:16:40.818 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.105 on GigabitEthernet1/3 from LOADING to FULL, Loading Done
002925: Sep 13 08:16:40.954 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from INIT to 2WAY, 2-Way Received
002926: Sep 13 08:16:40.954 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from 2WAY to EXSTART, AdjOK?
002927: Sep 13 08:16:40.954 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from EXSTART to EXCHANGE, Negotiation Done
002928: Sep 13 08:16:41.034 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from EXCHANGE to LOADING, Exchange Done
002929: Sep 13 08:16:41.034 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.106 on GigabitEthernet2/3 from LOADING to FULL, Loading Done
002930: Sep 13 08:52:56.226 CEST: %OSPF-5-ADJCHG: Process 1, Nbr 10.100.0.105 on GigabitEthernet1/3 from FULL to INIT, 1-Way
