07-07-2012 07:34 AM - edited 03-04-2019 04:54 PM
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
07-07-2012 09:52 AM
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
07-07-2012 09:54 AM
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
07-07-2012 09:59 AM
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
07-07-2012 10:47 AM
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.
07-08-2012 07:30 AM
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
07-08-2012 09:10 AM
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.
07-08-2012 10:21 AM
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
07-08-2012 08:34 PM
Hi Peter... NBMA is a very good suggestion in this case.
07-09-2012 02:09 AM
Talha,
Thank you!
Best regards,
Peter
07-08-2012 10:43 PM
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
07-09-2012 02:09 AM
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:
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
07-09-2012 02:44 AM
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
07-09-2012 02:46 AM
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
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: