cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
18725
Views
9
Helpful
13
Replies

OSPF-5-ADJCHG

vishal.rane
Level 1
Level 1

Hi All

I am repeatedly get this message on 4500 box, the WAN link is stable with no drops but ospf shows loading similar after every few minutes.

anyone can guide to the right path

*Jul  7 10:13:10.991 RYD: %OSPF-5-ADJCHG: Process 100, Nbr 10.100.101.1 on Vlan8 from LOADING to FULL, Loading Done

*Jul  7 10:14:30.987 RYD: %OSPF-5-ADJCHG: Process 100, Nbr 10.100.101.1 on Vlan8 from LOADING to FULL, Loading Done

Thanks

Vishal

13 Replies 13

Peter Paluch
Cisco Employee
Cisco Employee

Hello Vishal,

I am aware of no quick fix nor a typical cause for these problems. I am afraid that it will be necessary to perform more elaborate investigation. These issues have been discussed here from time to time but no straightforward solution was ever presented, to my best knowledge.

First, I suggest adding the log-adjacency-changes detail command to the OSPF configuration on your router. This should allow us to see more information about changes in the neighbor states.

Second, what is the 10.100.101.1 router exactly? Is it a Cisco device? What kind and what IOS version? When did this issue start occuring? Were there any changes to the network? Also, can you verify if there are any possible data delivery issues (packet drops, multicast filtering, ...) present between your router and the 10.100.101.1?

Also, can you post the output of the show ip ospf neighbor 10.100.101.1 command?

Best regards,

Peter

Tharak Abraham
Level 3
Level 3

Vishal,

If possible try to do a "deb ip os adj" which will make it very clear.

Mismatch MTU, Corrupt LSAs, Unidirectional flow, unexpected DBD, sequence number issue etc. can be

Are you using tunnels ?

A debug should really help out.

-Tharak

Hi Tharak,

Regarding the MTU issues, I thought of that as well but the fact is that if MTU issues were present, the router would most probably not get over the ExStart/Exchange state with the neighbor. The fact that the adjacency to the neighbor reaches the FULL state and then for some reason drops back to some preceding state is something requiring more in-depth investigation.

Thanks for joining the thread! Let's see what we can find out.

Best regards,

Peter

Thanks Peter ! (infact i was far away from this community)

You are correct, i did take that into account.

But even though we can stop/solve MTU issues at the control plane by ignoring them (ip os mtu-ignore),

synchronization sometimes fails at the data plane when a LSA replication event/flooding causes packet sizes generated by each routers to be different.

Thanks Peter and Abraham

outdoor wireless unit is getting terminated at both ends on Catalyst switch 4507

Outdoor Wireless unit link -->> http://www.ubnt.com/airmax#rocketm -

CMI#show ip ospf neighbor 10.100.101.1

Neighbor 10.100.101.1, interface address 172.16.20.53

    In the area 0 via interface vlan8

    Neighbor priority is 1, State is FULL, 64850 state changes

    DR is 172.16.20.50 BDR is 172.16.20.53

    Options is 0x2 in Hello (E-bit )

    Options is 0x42 in DBD (E-bit O-bit)

    Dead timer due in 00:00:35

    Neighbor is up for 00:00:28

    Index 1/1, retransmission queue length 0, number of retransmission 18285

    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)

    Last retransmission scan length is 0, maximum is 40

    Last retransmission scan time is 0 msec, maximum is 4 msec

*Jul  8 06:51:28.882 RYD: OSPF: First DBD and we are not SLAVE

*Jul   8 06:51:28.886 RYD: OSPF: Rcv DBD from 10.100.101.1 on vlan8 seq  0x56AB9 opt 0x42 flag 0x2 len 1472  mtu 1500 state EXSTART

*Jul  8 06:51:28.886 RYD: OSPF: NBR Negotiation Done. We are the MASTER

*Jul  8 06:51:28.886 RYD: OSPF: Send DBD to 10.100.101.1 on vlan8 seq 0x56ABA opt 0x52 flag 0x3 len 1452

*Jul   8 06:51:28.890 RYD: OSPF: Rcv DBD from 10.100.101.1 on vlan8 seq  0x56ABA opt 0x42 flag 0x2 len 1472  mtu 1500 state EXCHANGE

*Jul  8 06:51:28.890 RYD: OSPF: Send DBD to 10.100.101.1 on vlan8 seq 0x56ABB opt 0x52 flag 0x3 len 1452

*Jul   8 06:51:28.894 RYD: OSPF: Rcv DBD from 10.100.101.1 on vlan8 seq  0x56ABB opt 0x42 flag 0x2 len 1472  mtu 1500 state EXCHANGE

*Jul  8 06:51:28.894 RYD: OSPF: Send DBD to 10.100.101.1 on vlan8 seq 0x56ABC opt 0x52 flag 0x3 len 1452

*Jul   8 06:51:28.902 RYD: OSPF: Rcv DBD from 10.100.101.1 on vlan8 seq  0x56ABC opt 0x42 flag 0x2 len 172  mtu 1500 state EXCHANGE

*Jul  8 06:51:28.902 CAL: OSPF: Send DBD to 10.100.101.1 on vlan8 seq 0x56ABD opt 0x52 flag 0x3 len 232

*Jul  8 06:51:28.906 CAL: OSPF: Rcv DBD from 10.100.101.1 on vlan8 seq 0x56ABD opt 0x42 flag 0x0 len 32  mtu 1500 state EXCHANGE

*Jul  8 06:51:28.906 CAL: OSPF: Send DBD to 10.100.101.1 on vlan8 seq 0x56ABE opt 0x52 flag 0x1 len 32

*Jul  8 06:51:28.910 CAL: OSPF: Rcv DBD from 10.100.101.1 on vlan8 seq 0x56ABE opt 0x42 flag 0x0 len 32  mtu 1500 state EXCHANGE

*Jul  8 06:51:28.910 CAL: OSPF: Exchange Done with 10.100.101.1 on vlan8

*Jul  8 06:51:28.910 CAL: OSPF: Synchronized with 10.100.101.1 on vlan8, state FULL

*Jul  8 06:51:28.910 CAL: %OSPF-5-ADJCHG: Process 100, Nbr 10.100.101.1 on vlan8 from LOADING to FULL, Loading Done

*Jul  8 06:51:29.890 CAL: OSPF: Rcv LS UPD from 10.100.101.1 on vlan8 length 220 LSA count 1

*Jul  8 06:51:34.790 CAL: OSPF: Rcv LS UPD from 10.100.101.1 on vlan8 length 220 LSA count 1

*Jul  8 06:51:38.882 CAL: OSPF: Neighbor change Event on interface vlan8

*Jul  8 06:51:38.882 CAL: OSPF: DR/BDR election on vlan8

*Jul  8 06:51:38.882 CAL: OSPF: Elect BDR 10.100.101.1

Vishal,

Index 1/1, retransmission queue length 0, number of retransmission 18285

Can you do an extended ping with "df" bit set with sweep size from 1450 to 1550 and check if there are any ping drops ?

If there are drops, then please lower the interface MTUs between the neighbors to a fair value as per the ping.

Tharak and Vishal,

In addition to what Tharak suggested (and it's a very fine suggestion!), I also suggest modifying the OSPF configuration on the wireless link to NBMA network type and specify neighbors statically by their IP address using the neighbor command.

It appears that wireless links may have degraded performance when it comes to delivering multicasts or broadcasts. Converting the OSPF configuration to employ unicast addressing using the NBMA mode could prove helpful here. Some time ago, I have been involved in solving a similar issue here on CSC, only with EIGRP: when left running in native multicast over a WiFi link, intermittent adjacency failures occured. After reconfiguring the EIGRP using static neighbor commands and forcing it to work using unicast addressed packets, we were able to work around this problem.

Best regards,

Peter

Hi Peter... NBMA is a very good suggestion in this case.

Talha,

Thank you!

Best regards,

Peter

Hi Peter

you want the config to look like the following example

Router OSPF 1

Neighbor 10.100.101.1

I remove the network statement for that link

thanks

Vishal

Hello Vishal,

you want the config to look like the following example

Router OSPF 1

Neighbor 10.100.101.1

I remove the network statement for that link

Multiple changes will have to be done:

  1. On both routers, the interface that connects to the WiFi link must be configured using the ip ospf network non-broadcast command. Otherwise, the interface will still be treated as broadcast network and the router will not allow you to configure the neighbor statements later. I assume here that there are only two OSPF routers on this wireless link. Correct me if I am wrong here.
  2. Do not remove the network command from any of the two routers. This command must remain in place.
  3. On both routers, in the OSPF configuration, you will need to add the neighbor command pointing to the neighbor's IP address (i.e. not the RouterID of the neighbor).

Please also note that the change of the network type will lead the OSPF Hello/Dead timers to change from 10/40 to 30/120. These values may be tuned later after we get this basic configuration change working.

We could also use the point-to-multipoint nonbroadcast OSPF network type here but I don't want to overcomplicate things... let's try to get this working and perhaps we can optimize it later - if this solution even brings an improvement (which is not guaranteed yet).

Best regards,

Peter

Thanks Peter

[S1] 4507-------Wireless---------------------------------Wireless-------4507 [S2]

Current config On 4507

interface vlan 8

ip addresss x.x.x.x 255.255.255.248

interface Giga 2/3

switchport mode access

switchport access vlan 8

router ospf 2

network x.x.x.x 0.0.0.7 area 0

Looking at above I will configure

I would configure the 'ip ospf network non-broadcast' on giga 2/3 or vlan 8

thanks

vishal

Hello Vishal,

The ip ospf network non-broadcast command will be placed into the interface Vlan8 configuration. In addition, you will need to add the neighbor y.y.y.y to the router ospf 2 configuration (y.y.y.y being the IP address of the second 4507 in the same network as the x.x.x.x).

Best regards,

Peter

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

Ā