cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
26030
Views
10
Helpful
27
Replies

OSPF stuck in Exchange/DR

mistryj
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

27 Replies 27

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Jaya,

try to use

debug ip ospf adj

on your side to see what is happening.

Being the C6509 a multi layer switch it can have different ip settings at physical interface level and at the SVI (interface vlan) if the port is not a routed port.

A MTU mismatch is probably the reason.

Also check the ospf network type with

sh ip ospf interface

have you used

ip ospf network point-to-point on your side or on the provider side they used it ?

feel to free to post debug outputs if public ip addresses are not involved

Hope to help

Giuseppe

Hi Giuseppe,

Please find attached outputs as requested.

Regards,

Jaya

Hello Jaya,

to be able to distingush from different possible problems I would suggest to remove OSPF authentication configuration.

From the debugs we see that the C3750 is elected DR and tries to send first Database Descriptor packet but it never receives an ack from the C6500.

So after some attempts 14 the neighbor state is restarted.

02.554 GMT: OSPF: Send DBD to 10.134.243.2 on GigabitEthernet1/0/2 seq 0x17DA opt 0x52 flag 0x7 len 32

001170: *Mar 1 18:22:02.554 GMT: OSPF: Send with youngest Key 1

001171: *Mar 1 18:22:02.554 GMT: OSPF: Retransmitting DBD to 10.134.243.2 on GigabitEthernet1/0/2 [11]

001172: *Mar 1 18:22:03.141 GMT: OSPF: Send with youngest Key 1

001173: *Mar 1 18:22:03.477 GMT: OSPF: rcv. v:2 t:1 l:48 rid:10.134.243.2

aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x4980537F from GigabitEthernet1/0/2

I think you need to verify if NTP in sync in the second device :

the second device thinks it March 1

the c6500 thinks it is Feb 23

this can make them to use a different key.

then also enable datetime in logging

on C3750 with

service timestamps log datetime msec

service timestamps deb datetime msec

So disable the authentication and see what happens

Hope to help

Giuseppe

Hi Giuseppe,

The clock was set manually on the 3750 and removed ip ospf authentication message-digest and message-digest key.

But still no change.

The ospf works if you put another 3750 instead of using the 6509, why is that ?

Also check to make sure your network statements are correct on each side with the correct masking .

"The ospf works if you put another 3750 instead of using the 6509, why is that?"

What is the difference between the two configurations?

We had two 6509s back to back with interfaces set at 9216 mtu.  Then replaced one with a 3600 and ospf wouldn't pass Exchange.  Used the ip ospf mtu-ignore on the 3600 as a temp workaround.  OSPF came up.  Found in our scenario the DWDM transport in the middle was the culprit.  Transport interfaces in the middle of the circuit were at the default, max mtu 1600.  I'll be honest, it took me a day to look there.

Initially 6500s on either end were set to MTU 9216, fat dumb and happy.  Perhaps the 3600 was doing something the 6500 wasnt, like sending DBD packets larger than 1600bytes and the 6509 wasn't getting them.  After adjusting the DWDM to support max frame size of 9600 I took the ip ospf mtu-ignore off the interface and it still worked fine.

Hi Jaja,

Did you remove authentication on both the 6500 and the 3750?

Looking at the show ip ospf int config both the 6500 and 3750 think its the DR.

On one of the interfaces add ip ospf priority 255 and on the other ip ospf priority 0.

ip ospf priority 255 - higher # is preferred. - Always become the DR.

ip ospf priority 0 - never become the DR

Let me know of this works for you.

CSCO11188854
Level 1
Level 1

Try on the 6509 interface facing the 3750

switch-if#ip ospf mtu-ignore

see how that goes.

Thank you all for you replies unfortunately no change tried all the following suggestions :-

1. The Network statements have correct subnet masks.

2. I have tried removing the following authentication but no change.

ip ospf authentication message-digest

ip ospf message-digest-key 1 md5 7 050F5501351C40

3. I set 6509 interface to priority to 255 and 3750 to priority to 0. Still no change its now stuck in Exchange/DROTHER.

4. I have 'ip ospf mtu-ignore' set on both interfaces but no change same results.

Hello Jaya,

after removing the authentication and changing the ip ospf priority the problem is still there.

I would suggest you to do the following:

Do

sh system mtu

on the C3750

a) remove ip ospf mtu-ignore on both sides

apply

ip mtu 1500

b) collect output of debug ip ospf adj on both sides

if you have changed the system MTU on c3750 there can be a side effect on SVIs and size of DBD packets.

I now remember I had problems with a C3550 to build OSPF adjacency with routers.

Hope to help

Giuseppe

Giuseppe,

With ip ospf mtu-ignore then the MTU is ignored so it does not matter if the MTU on one side is different. I've used this successfully where the switch MTU was 1504 and the router MTU was 1500.

What issues have you run into using ospf mtu-ignore?

Jaya for troubleshooting please remove it as Giuseppe suggests.

Peter010101
Level 1
Level 1

Please paste the output of the following commands from both ends.

show ip ospf

show ip ospf neighbor

debug ip ospf adj

debug ip ospf events

Hello all,

Please find attached debug files.

I have removed ip ospf mtu-ignore but left the ospf authentication statements in.

The outputs include :-

3750_CS01#sh system mtu

System MTU size is 1500 bytes

System Jumbo MTU size is 1500 bytes

Routing MTU size is 1500 bytes

3750_CS01#

show ip ospf

show ip ospf neighbor

debug ip ospf adj

debug ip ospf events

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco