OSPF stuck in Exchange/DR

[mistryj]

We have a point to point 100MG connection between a 6509 gig interface and a 3750G-48TS Gig interface.

Its a basic point o point but the OSPF fails to load and gets stuck in Exchange/DR as below.

The circuit has been tested by the provider and they have said that there are no issues and MTU has been set correctly to 1500.

Has anyone come across this problem before and how we can over come this ?

Neighbor ID Pri State Dead Time Address Interface

10.137.243.1 1 EXCHANGE/DR 00:00:14 10.128.0.173

[Peter010101]

Neighbor ID Pri State Dead Time Address Interface

10.137.243.1 1 EXCHANGE/DR 00:00:15 10.128.0.173

3750_CS01#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface

10.134.243.2 1 INIT/DROTHER 00:00:13 10.128.0.174 GigabitEthernet1/0/47

OSPF: Nbr 10.134.243.2 10.128.0.174 GigabitEthernet1/0/47 is currently ignored

Common causes are

INIT - ACL blocking, corrupt database

EXSTART/EXCHANGE mtu mismatch- fix mtu or ip ospf mtu-ignore

Take a look at the acl's on the 6509.

[Mohamad Qayoom]

Did you try removing CoS on the 6509 switch?

[Giuseppe Larosa]

Hello Jaya,

I noticed that when the C6500 sends a bigger DBD with size 1412 bytes it is never received by c3750

example from your logs

255334: .Feb 26 11:04:46.296 GMT: OSPF: Send DBD to 10.137.243.1 on GigabitEthernet7/48 seq 0x99B opt 0x52 flag 0x2 len 1412

255335: .Feb 26 11:04:46.296 GMT: OSPF: Send with youngest Key 1

if you look in C3750 log and search for string Rcv DBD you can find only:

005726: .Feb 26 11:05:48.618: OSPF: Rcv DBD from 10.134.243.2 on GigabitEthernet1/0/47 seq 0x11BC opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART

005727: .Feb 26 11:05:48.618: OSPF: First DBD and we are not SLAVE

on the c6500 the same search gives much more matches

So the question can be at the physical layer check cables:

it looks like that small frames are received but when C6500 says it sending a DBD with size 1412 bytes it is not seen on the other side

check for errors in interfaces

with sh int g1/0/47

sh int g7/48

Hope to help

Giuseppe

[mistryj]

Hi All,

I have tried removing access-lists and COS but no luck.

Giuseppe there are no errors on the interface and I do feel there is some configuration missing on the provider side. Do they need to have DF bit set on their equipment along with MTU 1500 ?

Hence the reason 6509 is not sending more than 1400 bytes ?

[Giuseppe Larosa]

Hello Jaya,

I've never realized up to now there is another device in the middle or at least a L2 transport service of a service provider.

DF can be set on packets not on equipment. In our case DBD packets have the DF bit set in the IPv4 header.

Call them and explain that packets from one side (C6500) are not received on the other end (C3750) if their size is near to 1500.

the c6500 sends a DBD packet of 1412 bytes or with payload 1412 bytes but it is not seen on the C3750 side

You can also check yourself using extended ping and debug ip icmp if there are MTU issues on the link.

You can use the sweep option to explore a range of packet sizes while you have debug ip icmp on the other switch.

Hope to help

Giuseppe

[mistryj]

Hi Giuseppe,

I have connected a laptop at one end and PC at the other end of the circuit and tested ping using different packet sizes and this was fine.

The provider configured a router and connected at the 6509 end with the 3750 at the other end and the connection worked for them. They are saying the circuit is fine and are not helping to resolve this any more.

What I cant understand is what different the 6509 IOS switch is doing compared to a Cisco 3750/Cisco Router. If I have a Cisco 3750 switch connected at both ends OSPF works fine.

Its getting to the point where we will have to put in a 3750 infront of the 6509 just to get this to work, its not a solution we want but we are running out of time.

[Giuseppe Larosa]

Hello Jaya,

at this point I think there is a physical layer problem:

some years ago to have a correct working ethernet 10 Mbps link over SDH an older switch had to be inserted:

switch -- older switch -- sdh interface

the fact is that the DBD from the C6500 was not seen on the other side.

Only last attempt could be to reduce the ip mtu to something less then 1500 on both sides

Hope to help

Giuseppe

[mistryj]

Hi Giuseppe,

I dont think the 3750 allows you to set the mtu. I can only set it on the 6509.

Also what affect will this have on performance if I set it to 1400 ?

Setting ip ospf mtu-ignore does this not have the same affect ?

[Giuseppe Larosa · Accepted solution]

Hello Jaya,

by setting a lower ip mtu on the C6509 side you can be sure that is not trying to build a packet that is bigger then 1500.

mtu-ignore disable a check but doesn't influence the size of packets that are sent out the interface

you may combine

ip ospf mtu-ignore on 3750 side

with

ip ospf mtu-ignore

ip mtu 1400

on c6509 and see what happens

Hope to help

Giuseppe

[mistryj]

Hi Giuseppe

This works !

I have set the 6509 with the lowest possible mtu which was 1456 and the OSPF has formed adjacency.

As I understand there are 2 methods of changing the MTU on the interface on the 6509 one is a L2 setting 'mtu 1500' and the other 'ip mtu' which is L3.

1. Is setting the mtu to 1456 on the packets likely to cause issues later on with other applications ?

2. Is there anything that the provider needs to do to resolve this issue ?

[mistryj]

THE MTU issue finally resolved the provider upgraded the IOS on their network !!!

[Giuseppe Larosa]

Hello Jaya,

so at the end the problem was in the middle in the provider network

It has been kind of you to provide feedback this completes this case and makes it useful for other people

Best Regards

Giuseppe

[mistryj]

Hi Giuseppe,

Yes I thought it best to. The provider upgraded the IOS one of their switches, but unfortunately they wont give us details on the upgrade and any configuration changes made on their network but we are glad its all working as it should now.

Many Thanks for your help.