Symptom: Loss of OSPF adjacency when Primary CPM is reloaded

book

Article ID: 167803

calendar_today

Updated On:

Products

XOS

Issue/Introduction

This document provides the details of the OSPF interactions between the CPM and APM and scenarios when OSPF adacenies are affected when performing CPM maintenance.·   When the primary CPM is reloaded, it is observed that OSPF adjacency goes down and re-establishes as seen below on the neighboring device(s).  This may cause a network outage depending upon network redundancy in the environment.


2013 2013 Dec 12 10:44:44 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.70 on Vlan503 from FULL to EXSTART, BADSEQNUM
2013 Dec 12 10:44:44 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.70 on Vlan503 from EXSTART to EXCHANGE, NEGDONE
2013 Dec 12 10:44:44 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.102 on Vlan504 from FULL to EXSTART, BADSEQNUM
2013 Dec 12 10:44:44 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.102 on Vlan504 from EXSTART to EXCHANGE, NEGDONE
2013 Dec 12 10:44:44 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.70 on Vlan503 from EXCHANGE to FULL, EXCHDONE
2013 Dec 12 10:44:44 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.102 on Vlan504 from EXCHANGE to FULL, EXCHDONE
2013 Dec 12 10:44:47 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from FULL to EXSTART, BADSEQNUM
2013 Dec 12 10:44:47 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from EXSTART to EXCHANGE, NEGDONE
2013 Dec 12 10:44:47 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from EXCHANGE to FULL, EXCHDONE
2013 Dec 12 10:45:40 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from FULL to DOWN, DEADTIME
2013 Dec 12 10:45:56 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from DOWN to INIT, HELLORCVD
2013 Dec 12 10:45:56 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from INIT to EXSTART, ADJOK
2013 Dec 12 10:45:56 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from EXSTART to EXCHANGE, NEGDONE
2013 Dec 12 10:45:56 chassis-1 %OSPF-5-NBRSTATE: ospf-54775 [9794] Process 54775, Nbr 172.16.2.38 on Vlan502 from EXCHANGE to FULL, EXCHDONE
 

Cause

When the primary CPM is reloaded, it takes longer a time for other CPM to take over and start ospf than the dead timer interval configured for OSPF. This causes adjacency to break and re-establish.

FAQ:

Q1) What kind of OSPF interactions, if any, are shared between the APM and the CPM? 
 
While there is no direct OSPF communication between the APM and CPM, the following are some cases where the APM OSPF adjacency is affected:
a. If a Primary CPM is reloaded
b. There is no CPM scenario (e.g. reload all)

Note: The CPM helps control the circuit state on the APMs and that by rebooting and/or having no CPM present, the state of circuits on the APM becomes undetermined and can lead to OSPF bouncing adjacencies.
 
Q2) Is loss of OSPF adjacency expected behavior when there is no CPM in the chassis? 
Yes. 
 
Q3) Is a CPM required for OSPF to perform normally? 
Yes.
 
 

Resolution

n/a

Workaround

Is there a way to avoid this situation? 
Yes, if a reload of CPM is required for maintenance or break-fix, gracefully failover to the other chassis in a DBHA VRRP configuration if maintenance is required on the CPM.