OSPF communication problem

[Petar Chonkov]

Hello,

We have a strange problem with two 5300xl switches and ospf routing.

Equipment:
1. 2 x 5300xl switches (E.10.23)
2. several cisco 3845
3. several vanguard 6455
4. Linux box running Quagga routing software

The routing table contain about 200 entries.

Everything worked fine till last week. The two ProCurve 5300xls stopped to commuicate the routing info with the linux box (neither send nor receive). We thought that the problem is the linux box and removed it from the network.

Two days after that the 5300xls stopped to communicate the routing info (neither send nor receive) with one of the Cisco routers.

This problem continued to appear with arbitrary devices. We was forced to turn off the ospf routing and use static routes.

Everything in the configuration of the 5300xls looks normal.

We use the ospf specification form RFC 2328. The ospf interface parameters (dead-interval, hello-interval, retransmit-interval, transit-delay) have the default values set.

Please help ...

Any suggestion will be highly appreciated.

Thank you in advance.

[Sergej Gurenko · Accepted solution]

Here is the related problem. Ask support for a special firmware E.10.24
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1006260

[Ben Dehner]

OSPF problems can be a pain. I'm not familiar with your particular hardware, but I've had some dealings with OSPF. From the description above, here's a few things to check.

First, I'd check the router IDs. Each router ID is suppose to be unique, but different manufactures have different ways of defaulting the router ID. It may be that a couple of devices have inadvertently defaulted to having the same ID. (Also, different manufacturers may have there own way of "defaulting the defaults" for RFC 2328.)

Next I'd check is to see who all of the OSPF neighbors are. If the routers aren't seeing their neighbors, then there's no OSPF communication taking place. This can obviously be caused by a mis-match in the OSPF settings, and be sure to check the area ID's as well. Also, if there are multiple routers on a subnet, see who the designated router (DR) and backup designated router (BDR) are. Theoretically it shouldn't matter, but some devices may not make a good choice for DR or BDR. Then look at what state the various neighbors are in. Every router in a network should be a in FULL state with both the DR and BDR, and it should also be in a FULL state with any point-to-point connected routers.

Finally, I'd check the link state databases on the routers. If routers aren't seeing each other as neighbors, this is a moot point. Othwerwise, if two routers are neighbors, they'd better have the same LSDB for each area that they are in.

Hope this helps.

[Petar Chonkov]

Thank you for the answers,

The mentioned network is in production state and we cannot implement your advices in the middle of the week.

We will try to find the real problem this weekend.

I hope your suggestions will help us.

Wait for more questions next week.