DNAC - templates invisible after failover in Disaster Recovery system.

[olivier vigeant]

Hi,

I have deployed several Disaster Recovery systems for a customer, some are 1+1+1 and some are 3+3+1, using version 2.3.5.5.

After a failover, my templates are not visible in the Template Hub. It happened on each of my 5 DR system. Everything is detailed in the attached document. 

TAC didn't succeed to reproduce in their lab, but saw the issue during a webex on one of my DR system.
Before failover, the template are present in database on both sites, but after failover they are not visible in the GUI of the new Active site.

Did anyone also had this behavior ?

Regards.

[balaji.bandi]

After a failover, my templates are not visible in the Template Hub. It happened on each of my 5 DR system

if you fail back to original position is the templates visible ?

[olivier vigeant]

Hi 

in my attached document, I performed the failover back to Main site and my intials templates created on the Main were still visible, but not the templates created on Recovery site while it was the Active site.

And since I had to proceed with my workaround on all my DR systems, I can not reproduce any of the situations, as it seems the workaround solves the issue permanently.

During the webex, TAC engineer checked in the cli and the templates were present in database on both sites. But after failover from Main to Recovery, the template were not visible in the GUI on Recovery site.

Regards

[maflesch]

The HAR file from the browser should have been collected and inspected to see why the browser was not displaying the contents, especially if they existed in postgres. Or if the API calls were completing and not containing the content. Regardless, that is an invalid point now as you are no longer facing this issue. If you happen to come across this issue again, I strongly suggest capturing the API calls in the browser developer tools while accessing the template page to help better access why they are not displaying.

[olivier vigeant]

Hi,

I don't know what is this HAR file, but I haven't been ask to collect and provide it to the TAC. And I've hit a new behavior that I didn't noticed yet :

1. I have a template version 2 in template history on my Main Active.
2. New failover from Main to Recovery. The template on the Recovery Active are not synced (last commit date is incorrect).
3. Failover again and back to Main Active : the templates commit date are as on step 1, so not synced from Recovery to Main while Recovery as Active.

TAC asked me to provide output of this command on both Main and Recovery, and the output were identical :
docker exec -it $(docker ps | awk '/postgres_postgres-[0-2]+_fusion/ {print $1}') psql -d campus -h localhost -U appuser -c 'SELECT id,classname,displayname,createtime,operationname,lastupdatetime,versiontime,sdntemplate_id,compositetemplatename,softwaretype,version FROM public.sdnconfig ;'

TAC last answer was : "Investigate browser developer tools to identify the API calls responsible for populating template data in the UI." so I think your suggestion might be the good one. Thanks.

[maflesch]

If you press F12 (usually) or go to the menu -> more tools -> developer tools in your browser, I am using Chrome, then you will pull up the developer console on your browser. If you click the tab that says Network, you will see all the APIs that come across your browser when you click on something in the web page. If you hover over the up or down arrow, you will see that it is Import/Export HAR. That's what the HAR file is, it's the browsers API history while you were recording the session.

[cid:image001.png@01DADC0E.15EFC960]

[DJW487]

On both my standalone Catalyst Centre boxes, after upgrade from 2.3.3 to 2.3.5, my composite templates lost all included templates. I had to readd all sub templates to the composites. I also had issues where the templates were constantly saying they were not committed even though you could commit, then go out and it would say not committed on next refresh.

I eventually exported all templates, then reimported and it seems to have fixed that.