OSPF Too many DBD retransmitions

[smif101]

Hey Group,

Has anybody seen a problem where you have ip ospf network point-to-multipoint enabled (with OSPF neighbor statements) on an interface that is actually in an ethernet broadcast segment and get the error to many DBD retransmitions. The problem eventually solved itself after many hours (after giving up on it) and all the neighbor relationships came up but of course, that is unsat. The problem we think it might be is that it is multicasting and unicasting out to its neighbors at the same time and it might be causing problems. Seen a few threads online where adding the non-broadcast keyword to the network type actually fixed this problem. Would you agree to this or know of any documentation that states this issue and the reason behind it.

Thanks for your help! Let me know if you have any questions.

Jun 2 20:26:32: %OSPF-5-ADJCHG: Process 11456, Nbr 0.0.0.0 on GigabitEthernet4/0.100 from DOWN to DOWN, Neighbor Down: Ignore timer expired

Jun 2 20:47:49: %OSPF-5-ADJCHG: Process 11456, Nbr 10.10.64.8 on GigabitEthernet4/0.100 from EXSTART to DOWN, Neighbor Down: Too many DBD retransmitions

Jun 2 20:48:49: %OSPF-5-ADJCHG: Process 11456, Nbr 0.0.0.0 on GigabitEthernet4/0.100 from DOWN to DOWN, Neighbor Down: Ignore timer expired

Jun 2 20:50:02: %OSPF-5-ADJCHG: Process 11456, Nbr 10.10.64.8 on GigabitEthernet4/0.100 from EXSTART to DOWN, Neighbor Down: Too many DBD retransmitions

interface GigabitEthernet4/0.100

description [internal]_Connects to_RPR#1

encapsulation dot1Q 100

ip address 10.10.252.4 255.255.255.224

no ip directed-broadcast

ip ospf network point-to-multipoint

ip ospf cost 10

ip ospf hello-interval 7

ip ospf dead-interval 21

ip ospf mtu-ignore

mpls label protocol ldp

tag-switching ip

service-policy output CORE-ONS

router ospf 11456

log-adjacency-changes

no auto-cost

area 0 authentication

passive-interface Loopback9

network 10.10.252.0 0.0.0.31 area 0

network 10.10.253.0 0.0.0.31 area 0

neighbor 10.10.253.1 cost 21

neighbor 10.10.253.11 cost 21

neighbor 10.10.253.2 cost 17

neighbor 10.10.253.12 cost 17

neighbor 10.10.253.7 cost 20

neighbor 10.10.253.17 cost 20

neighbor 10.10.253.8 cost 16

neighbor 10.10.253.18 cost 16

neighbor 10.10.253.5 cost 11

neighbor 10.10.253.15 cost 11

neighbor 10.10.253.14 cost 10

neighbor 10.10.252.18 cost 16

neighbor 10.10.252.8 cost 16

neighbor 10.10.252.17 cost 20

neighbor 10.10.252.2 cost 17

neighbor 10.10.252.5 cost 11

neighbor 10.10.252.12 cost 17

neighbor 10.10.252.11 cost 21

neighbor 10.10.252.1 cost 21

neighbor 10.10.252.15 cost 11

neighbor 10.10.252.7 cost 20

neighbor 10.10.252.14 cost 10

maximum-paths 8

default-metric 1

distribute-list route-map OSPF_ROUTES in

Thanks,

Jason Smith

CCIE #12097

[kerek]

Hi Jason,

First I'm not an OSPF expert.

Normally the router on Ethernet interface uses ospf network type broadcast and using multicast addressing. The routers are electing DR, BDR. In case of network type point-to-multipoint the addressing is still multicast but there is no DR, BDR. The broadcast and non-broadcast keyword I think only mean that whether to use multicast or unicast furthermore you have to configure statically neighbors if u use non-broadcast. Anyway why don't you leave it on the default-network type (broadcast)?

Krisztian

[smif101]

Yeah we have static neighbors all ready setup there in the config. What we are thinking is that OSPF is messed up with sending and receiving both unicast and multicast. We had to set up the point-to-multipoint configuration because we need to a way to set the cost differently between sites because we run anycast. This is a RPR Ring country wide so we want anycast traffic to look differently from different areas of the country and not all look to be the same cost.

[ariela]

Hi Jason,

in my experience, the "too many DBD retransmitions" problem is caused by mismatched MTU ... I see that your interface is MPLS enabled, and the "ip ospf mtu-ignore" is another bit of puzzle, so ... Have you checked a "debug ip packet" and a "debug ip ospf adj"?

Just for your information:

http://www.cisco.com/warp/public/104/12.html

HTH

Andrea

[smif101]

yeah the mtu isn't the issue, all the interfaces are set to 4096 and MPLS doesn't come into play because OSPF doesn't come yet so nothing would be MPLS Switched. But these are directly connected and would only be sent IP switched to the directly connected interfaces. Another reason it isn't a MTU problem is because this didn't come up until we changed it to point-to-multipoint, when it was just regular broadcast everything worked fine. Yeah the debugs didn't state anything obvious to look at. The ip ospf mtu-ignore command didn't work either, we tried it the night we had issues.

[mikebrsnet]

We had a similar problem whereas the ospf adjacency was stuck in LOADING state and after many hours...went to FULL.Even though we have implemented OSPF in subinterfaces we configured under the subinterfaces with the ip mtu 1500 command and the physical interface with mtu 1600 (we pass MPLS traffic) the adjacency went from LOADING to FULL in miliseconds!!! You could try this command to see if it helps!!

PLEASE RATE IF IT HELPS

[Giuseppe Larosa]

Hello Jason,

neighbor ... cost commands can be used with ip ospf network point-to-multipoint non-broadcast

that is Cisco proprietary

ip ospf network point-to-multipoint is RFC2328 and doesn't require the neighbor commands

check the ip ospf network type on all routers

Hope to help

Giuseppe