06-06-2007 12:11 PM - edited 03-05-2019 04:32 PM
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
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
service-policy output CORE-ONS
router ospf 11456
area 0 authentication
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
distribute-list route-map OSPF_ROUTES in
06-07-2007 04:14 AM
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)?
06-07-2007 06:03 AM
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.
06-07-2007 05:47 AM
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:
06-07-2007 05:57 AM
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.
07-30-2008 05:03 AM
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
07-30-2008 08:35 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: