02-08-2006 06:51 AM - edited 03-03-2019 01:44 AM
hi,
after a link down between a cisco 7300 and a 1841 which had esteblished ospf neighborship relation, this esteblishment stucks in init state on the 1841 when the link comes back again (the 73k doesn't see the 1841 at all). the cisco 7300 sends ospf hellos to the 1841, but doesn't receive any hello packet from 1841.
the 1841 receives and sends (in my oppinion in the correct way) ospf hellos.
has anyone had a problem like this with on ospf neighbor stuck in init state?
kind regards,
02-08-2006 07:06 AM
Hello ;-)
Well there can be many reasons. some things to check: Is the MTU the same at both sides of the link? OSPF checks the MTU within the Database Description Packets. You should however get to ExStart then.
Do you have connectivity (ping 1841 interface IP from 7300 is ok?)?
What type of link are we talking about (NBMA)?
Can you please post the relevant part of the configuration (OSPF + interface config) of the 1841 and the 7300? This would help to understand, whether you can do something by configuration or only by IOS upgrade ;-)
Hope this helps! Please rate all posts.
Regards, Martin
02-08-2006 07:15 AM
The symptoms sound a bit like a one way traffic flow. I have seen symptoms similar to this when there was a problem on the physical media and the transmit on one side was bad. I have also seen similar symptoms when the interface connector was not fully seated (allowing the receive side to work but not the transmit).
I have also seen similar symptoms when an access list on one of the interfaces was denying the OSPF hello traffic from the neighbor router. But that seems less likely to be the case here since the original post says that the problem started after a link down problem.
I agree with Martin that a ping between the routers would be a good place to start in troubleshooting.
HTH
Rick
02-08-2006 10:08 AM
hello,
the router are connected via ethernet interfaces - the link between goes over a optical provider network (i guess). the mtu size should be correct. we used pings with mtu 1500 and df set to tests this (so we also have connectivity between the devices). we are talking about an point-to-point link, which is also so configured.
here's are parts of the configs:
c1841:
interface FastEthernet0/0.11
description to central
encapsulation dot1Q 11
ip address 10.85.1.13 255.255.255.254
ip ospf network point-to-point
router ospf 27
router-id 10.85.1.100
log-adjacency-changes
area 11 nssa
redistribute static subnets
passive-interface default
no passive-interface FastEthernet0/0.11
network 10.85.1.12 0.0.0.1 area 11
------
c73k:
interface FastEthernet0/1.11
description to c1841jtp
encapsulation dot1Q 11
ip address 10.85.1.12 255.255.255.254
no ip redirects
no ip unreachables
no ip proxy-arp
ip ospf network point-to-point
router ospf 27
router-id 10.85.7.100
log-adjacency-changes
area 11 nssa default-information-originate no-summary
network 10.85.1.12 0.0.0.1 area 11
default-information originate always metric 10
maybe you can see something that we can do by configuration ;-)
kind regards
02-08-2006 10:22 AM
Bernhard
Thanks for posting the additional information. It seems a bit odd to have FastEthernet interfaces configured with IP addresses with mask 255.255.255.254. But if it was that way and working before then it would not be a problem now. Otherwise I do not see any particular issue in the config.
On both of the routers if you do show cdp neighbor do both of the routers see the other router as a neighbor?
If you perform showdown and then no shutdown on both of the router interfaces, does the behavior change?
HTH
Rick
02-10-2006 04:11 AM
hi rick,
we did shutdown of the interfaces on both routers, but the behavior doesn't change.
would it be an idea the clear the ospf process?
regads
02-10-2006 06:07 AM
Bernhard
Thanks for the additional information and for trying my suggestion. I have seen situations where there was an interface issue and a shutdown/no shutdown would clear it. This seems to not be one of those but I thought it was worth trying.
It might be helpful to know the answer to the question that I asked about CDP and whether both of the routers see each other as neighbors. Since CDP actually runs at layer 2 but can show some information about layer 3 it is frequently a good troubleshooting tool. If both routers do see each other as neighbors then we have assurance that layer 2 has proper connectivity and can focus on finding layer 3 problems. But if one of the routers did not see the other router as a neighbor then it would indicate that we should be looking for problems in connectivity not for problems in IP operations.
HTH
Rick
02-10-2006 06:48 AM
hi rick,
the routers find each other as cdp neighbors - layer 2 connection should be proper werking.
regards
02-10-2006 07:45 AM
Bernhard
It is helpful to have some assurance that there is basic connectivity. So we are probably looking at some kind of layer 3 issue.
Your previous post had asked about clearing the OSPF process. I am not optimistic that it will fix the issue but it may be worth a try. Clear the process and let us know what happens.
It might be helpful is you would post the output of show ip ospf interface. It might also be helpful to run debug ip ospf adjac and post the output.
HTH
Rick
02-08-2006 02:33 PM
Hi Bernhard,
Try configuring on the two interfaces:
no ip directed-broadcast
Since you use the /31 subnet, I think you may need it. Although this doesn't match the usage of the command, I have come across a cco doc which shows it in the config. Worth a try
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ft31addr.htm
I haven't tested, so let us know if it works..-)
Regards,
E.
02-08-2006 11:17 PM
Hi Bernhard,
Can you also check if the ARP entry is complete cause its an ethernet interface I faced exactly the same problem few days back. My config was fine, ping was fine and no MTU related issued and the problem was realated to incomplete ARP entry for multicast mac address which is used in OSPF hello packet to move ahead from init state to different stage.
Reseating the card resolved my issue. Can you check the ARp entry and see if that is not the issue.
HTH
Ankur
02-10-2006 04:02 AM
hi ankur,
how can i check arp entries for multicast mac addresses? when using "show arp" i can't see any multicas mac address (even though ospf is working on other interfaces).
kind regards
02-14-2006 01:30 AM
hi@all,
problem solved, everything works fine again !!!!
thanks a lot for all your support - the source of trouble was not the c73k. it was device between the two routers, a catalyst switch how was silently dying.
For what reason ever, this switch didn't forward multicast packets only on that vlan on the trunk connected to the "predtending faulty" Sub-Interface on the c73k (only in the direction of the c73k - the other direction works, the c18xx get's the ospf hellos from the c73k).
we got this recognition, after traceing on the said trunk interface (in the direction to the c73k). we see ospf hellos on other vlans on this trunk, but not on our faulty connection. so it was clear, that the sub-interface on the c73k never get's the ospf hellos from the c18xx. since this was an unidirectional problem, (from c18xx to c73k) the 18xx receives the hellos from the c73k and than stucks in init state.
yesterday this catalyst switch crashed completly. after changing it through a maintainence device, the ospf routing process functions correctly again.
thank's for your support,
kind regards
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide