ASA active/standby nodes have different routing tables

[oleg.rovenskiy]

I have two ASA 5520 (/asa917-19-k8.bin) active and standby failover mode.

Both use static and OSPF routing. Failover status is OK, running config is synchronized, BUT there are differences at routing table and OSPF database.

Some networks are not reachable from standby ASA, but it is ok from active node.

What can be reason for not synchronized routing tables?

[balaji.bandi]

I would like to see what routing table you were referring, give some example routing information.

ASA  Active is only able to communicate outside as it has active participation.

Standby only wait for Active to fail so it can take over Active Role

in case of multi-context this is a different case.

[oleg.rovenskiy]

The part of routing table and OSPF database

Active:

ASA5520/pri/act# sh route | inc 10.102.1.0

O E2 10.102.170.128 255.255.255.128

O E2 10.102.160.128 255.255.255.128

O E2 10.102.190.128 255.255.255.128

O E2 10.102.180.128 255.255.255.128

O E2 10.102.1.0 255.255.255.0 [110/5] via 10.102.62.7, 1193:02:47, inside

O E2 10.102.170.0 255.255.255.128

O E2 10.102.160.0 255.255.255.128

O E2 10.102.190.0 255.255.255.128 [110/500] via 10.102.62.12, 30:32:26, inside

O E2 10.102.180.0 255.255.255.128 [110/500] via 10.102.62.12, 49:48:38, inside

O E2 10.102.130.0 255.255.255.0 [110/50] via 10.102.62.12, 1193:02:47, inside

O E2 10.102.150.0 255.255.255.0 [110/50] via 10.102.62.12, 889:25:12, inside

MSK-COD-FW-ASA5520/pri/act#

From OSPF database, LSA Type 5

10.102.0.9      10.102.0.3      60          0x8000007e 0x7d66 65077

10.102.0.9      10.102.0.4      759         0x80000231 0xb0b9 65077

10.102.0.10     10.102.0.3      60          0x8000007e 0x736f 65077

10.102.0.10     10.102.0.4      759         0x80000231 0xa6c2 65077

10.102.1.0      10.0.0.110      1794        0x80003abe 0x9f4c 0

10.102.1.0      10.0.0.111      1727        0x80003abe 0xa346 0

10.102.1.0      10.0.0.112      1650        0x80003abe 0xa740 0

10.102.1.0      10.0.0.113      1645        0x80003abe 0xab3a 0

10.102.2.0      10.0.0.110      1764        0x80003abd 0x9655 0

10.102.2.0      10.0.0.111      1757        0x80003abd 0x9a4f 0

10.102.2.0      10.0.0.112      1760        0x80003abd 0x9e49 0

10.102.2.0      10.0.0.113      1765        0x80003abd 0xa243 0

10.102.3.0      10.0.0.110      253         0x80005721 0x6dfc 0

10.102.3.0      10.0.0.111      696         0x80005720 0x73f5 0

10.102.3.0      10.0.0.112      1160        0x80005720 0x77ef 0

Standby:

ASA5520/sec/stby# sh route | inc 10.102.1.0

O E2 10.102.160.128 255.255.255.128

O E2 10.102.190.128 255.255.255.128

O E2 10.102.180.128 255.255.255.128

O E2 10.102.160.0 255.255.255.128

O E2 10.102.190.0 255.255.255.128 [110/500] via 10.102.62.12, 30:32:07, inside

O E2 10.102.180.0 255.255.255.128 [110/500] via 10.102.62.12, 49:48:17, inside

MSK-COD-FW-ASA5520/sec/stby#

From OSPF database, LSA Type 5

10.102.0.2      10.102.62.9     4295442      0x8001504d 0x2ddc 0

10.102.0.8      10.102.0.3      4295153      0x80000158 0xd039 65077

10.102.0.8      10.102.0.4      4294973      0x80000b75 0x1707 65077

10.102.0.9      10.102.0.3      4295153      0x80000158 0xc642 65077

10.102.0.9      10.102.0.4      4294973      0x80000b75 0x d10 65077

10.102.0.10     10.102.0.3      4295153      0x80000158 0xbc4b 65077

10.102.0.10     10.102.0.4      4294973      0x80000b75 0x 319 65077

10.102.3.0      10.0.0.110      4296313      0x800018dd 0xb13b 0

10.102.3.0      10.0.0.111      4296280      0x800018dd 0xb535 0

[balaji.bandi]

Active me is main participant, so good document provided by @Marius Gunnerud (cheers!)

[Marius Gunnerud]

This is by design.  See the following link for more information:

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/117816-qa-asa-00.html

[oleg.rovenskiy]

Yes, thanks.

From the document:

“Cisco Adaptive Security Appliance (ASA) code Version 8.4.1 and later synchronize dynamic

routes from the ACTIVE unit to the STANDBY unit. In addition, deletion of routes is also

synchronized to the STANDBY unit. However, the state of peer adjacencies is not synchronized;

only the ACTIVE device maintains the neighbor state and actively participates in dynamic routing.”

Yes, only active has OSPF adjacencies:

ASA5520/pri/act# sh ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

10.0.0.110        1   2WAY/DROTHER    0:00:35     10.102.62.7     inside

10.0.0.111        1   2WAY/DROTHER    0:00:32     10.102.62.8     inside

10.0.0.113        1   2WAY/DROTHER    0:00:39     10.102.62.11    inside

10.102.62.9       1   FULL/BDR        0:00:34     10.102.62.9     inside

10.0.0.112        1   2WAY/DROTHER    0:00:39     10.102.62.10    inside

10.102.66.9       1   FULL/DR         0:00:39     10.102.62.12    inside

ASA5520/sec/stby# sh osp nei

ASA5520/sec/stby#

But why the routing and OSPF are different I do not understand. According the docs the standby ASA should get routing from active. For me it is meen that routing tables should be equal.

Cluster was implemented a few year ago, I have got it for support recently. The routing question was discovered when I was not able to get SSH access to standby ASA from 10.102.1.0 network. According to monitoring the connection was lost two weeks ago on Sunday, when no one do any changes.

[balaji.bandi]

just want to know other note : below route is still valid. - update time show long back ?

O E2 10.102.1.0 255.255.255.0 [110/5] via 10.102.62.7, 1193:02:47, inside

[oleg.rovenskiy]

Yes, it is working

From active:

ASA5520/pri/act# sh rou | inc 10.102.1.0

O E2 10.102.170.128 255.255.255.128

O E2 10.102.160.128 255.255.255.128

O E2 10.102.190.128 255.255.255.128

O E2 10.102.180.128 255.255.255.128

O E2 10.102.1.0 255.255.255.0 [110/5] via 10.102.62.7, 1193:02:47, inside

O E2 10.102.170.0 255.255.255.128

O E2 10.102.160.0 255.255.255.128

O E2 10.102.190.0 255.255.255.128 [110/500] via 10.102.62.12, 53:52:51, inside

O E2 10.102.180.0 255.255.255.128 [110/500] via 10.102.62.12, 73:09:03, inside

O E2 10.102.130.0 255.255.255.0 [110/50] via 10.102.62.12, 1193:02:47, inside

O E2 10.102.150.0 255.255.255.0 [110/50] via 10.102.62.12, 912:45:37, inside

ASA5520/pri/act# tra

ASA5520/pri/act# traceroute 10.102.1.108

Type escape sequence to abort.

Tracing the route to 10.102.1.108

 1  core-n9k-1.mgc.local (10.102.62.7) 0 msec 0 msec 0 msec

 2  mgc-admin_ts (10.102.1.108) 0 msec *  0 msec

MSK-COD-FW-ASA5520/pri/act#

From standby:

ASA5520/sec/stby# traceroute 10.102.1.108

Type escape sequence to abort.

Tracing the route to 10.102.1.108

 1  A.B.C.D 0 msec 0 msec 0 msec

 2   *  *  *

 3   *  *  *

 4   *

ASA5520/sec/stby#

A.B.C.D – is public IP from route 0.0.0.0/0 (Gateway of last resort)

[Marius Gunnerud]

I came accross the following bug. Perhaps this is the reason for your issue.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq13182/?rfs=iqvred