ospf neighbor stucks in init state

mogli · ‎02-08-2006

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,

mheusinger · ‎02-08-2006

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

Richard Burts · ‎02-08-2006

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

HTH

Rick

mogli · ‎02-08-2006

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

Richard Burts · ‎02-08-2006

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

HTH

Rick

mogli · ‎02-10-2006

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

Richard Burts · ‎02-10-2006

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

HTH

Rick

mogli · ‎02-10-2006

hi rick,

the routers find each other as cdp neighbors - layer 2 connection should be proper werking.

regards

Richard Burts · ‎02-10-2006

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

HTH

Rick

ekiriakos · ‎02-08-2006

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.

ankurbhasin · ‎02-08-2006

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

mogli · ‎02-10-2006

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

mogli · ‎02-14-2006

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