ASA 9.18(2)5, Configuration Replication Issue

[stephan.ochs]

I am doing first tests with the new Secure Firewall 3120 (in application mode with ASA 9.18.2.5).
In these tests I am experiencing configuration replication issues in system context.
When creating a new context only a part of the context configuration is replicated to the standby.
In detail, only the "config-url disk0:/..." is replicated.

Looks like this on active:

context testtest
 member testtest
 allocate-interface Port-channel2.11 visible
 allocate-interface Port-channel2.12 visible
 allocate-interface Port-channel3.11 visible
 config-url disk0:/testtest.cfg
 storage-url private disk0:/private-storage/testtest disk0p
 storage-url shared disk0:/shared-storage disk0s

But on standby only this :

context testtest
  config-url disk0:/ctx_testtest.cfg

It can only be corrected by doing the configuration on both.
With corresponding warnings on standby about configuration replication.
Or rebooting standby to get a full replication from active to standby after reboot.

Every other configuration in system context and in every other context is replicated to standby correctly.

Does anybody else have this issue?
And maybe has solved it?

[Milos_Jovanovic]

Hi @stephan.ochs,

Could you please share configuration from both devices, as it is today (where it doesn work)? I would like to see failover configuration, interface configuration, and the output of "show flash".

Kind regards,

Milos

[stephan.ochs]

Hello Milos
Sorry for the late reply. But I did an update to 9.18.2.7 before re-testing, hoping it would help. Unfortunately it didn't...
Here is the relevant part of my configuration, identical on primary/active and secondary/standby (sensitive data as VLAN and IP addresses are replaced by other values

interface Port-channel1
description LAN/STATE Failover Interface
!
interface Ethernet1/15
 channel-group 1 mode active
!
interface Ethernet1/16
 channel-group 1 mode active
!
failover
failover lan unit [primary|secondary]
failover lan interface failover Port-channel1
failover key *****
failover replication http
failover link failover Port-channel1
failover interface ip failover 10.10.10.10 255.255.255.248 standby 10.10.10.11
failover wait-disable
!
interface Port-channel2
!
interface Port-channel2.100
 vlan 100
!
interface Port-channel2.101
 vlan 101
!
interface Port-channel2.102
 vlan 102
!
interface Port-channel3
!
interface Port-channel3.102
 vlan 102
!

Quick configuration test on primary/active:

.../pri/act(config)# context testtest
Creating context 'testtest'... Done. (5)
.../pri/act(config-ctx)# member testtest
.../pri/act(config-ctx)# allocate-interface Port-channel2.100 visible
.../pri/act(config-ctx)# allocate-interface Port-channel2.101 visible
.../pri/act(config-ctx)# allocate-interface Port-channel3.102 visible

Configuration seen on secondary/standby:

context testtest
!

[Milos_Jovanovic]

Hi @stephan.ochs,

Configuration looks good to me. I would try with removal of encryption key, to see if that makes any difference. If that doesn't provide appropriate results, and given that 3100 is fairly new platform, I would open a TAC case to figure out what is going on.

Kind regards,

Milos

[stephan.ochs]

Hi Milos
I will give it a try, but I don't think, changing the key will help.
Every other configuration in system context and any other context are replicated.
Apparently it only affects some commands within configuration of contexts.
"member ...", "allocate-interface ...", "storage-url ...". Maybe others I didn't use, yet.
The only command, that is replicated, is "config-url ..." which leads in erased interfaces in the context configuration on standby.
Yes, 3100 is fairly new, but it is an issue that should have been hit by any administrator yet, because of it's huge impact.
So I wonder, why I didn't find anything about it (bug search and community).
I will keep on searching and open a TAC case.

Thanks an best regards

[stephan.ochs]

Finally found the corresponding bug description: CSCwd54400 : Bug Search Tool (cisco.com)
Workaround: NO workaround other than reloading the device
Severity: 3 Moderate (!!??!!)
I think, this is anything other than moderate.

[Branimir Turk]

Hi,

It seems that we have hit this bug too.

In our case workaround was "write standby" .

[stephan.ochs]

Thank you for the hint, Branimir.
Didn't mention it.
But one should be aware, that it causes a short outage of standby device.