02-20-2020 06:40 AM - edited 02-21-2020 09:56 AM
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?
02-20-2020 07:03 AM
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.
02-20-2020 07:17 AM
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
02-20-2020 10:56 PM
Active me is main participant, so good document provided by @Marius Gunnerud (cheers!)
02-20-2020 02:37 PM
This is by design. See the following link for more information:
02-20-2020 11:13 PM
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.
02-20-2020 11:49 PM
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
02-21-2020 06:42 AM
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)
02-21-2020 12:05 PM
I came accross the following bug. Perhaps this is the reason for your issue.
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq13182/?rfs=iqvred
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide