cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
1763
Views
0
Helpful
2
Replies

ASA 5585-X upgrade to 9.2.3 leads to continuous SCPS reverse path check alerts

Cathy Ellis
Level 1
Level 1

Hi All,

Today I completed an upgrade of an Active/ Active ASA set-up based on 5585-X hardware. The original software version was 9.1(4), the newly installed version is 9.2(3).

Since reloading with the new version alerts (severity 1) related to SCPS are continually generated: -

> Deny SCPS reverse path check from 10.252.19.202 to 10.252.19.201 on interface NAME19

followed by severity 7 messages:

> SCPS request discarded from 10.252.19.202 to NAME19:10.252.19.201

We also notice that the failover status of the corresponding interfaces is shown as 'Normal (Waiting)' instead of the expected 'Normal (Monitored)'.

e.g. CONTEXTNAME Interface NAME19 (10.252.19.201): Normal (Waiting)

Alongside these waiting interfaces there are also interfaces which are giving the correct status

e.g. CONTEXTNAME Interface NAME08 (10.252.8.201): Normal (Monitored)

There is another related alert: -

> (Primary_group_1) Testing on interface NAME19 Passed

In the context we have 25 logical interfaces all set-up in the same way. Interface numbers 01 to 14 all seem normal, while numbers 15 and 17 to 26 exhibit behaviour described above. The subnet is a /29 e.g. 10.252.8.200/29 where IP .201 belongs to the primary ASA and .202 to the secondary ASA. IP addresses .204 and .205 reside within VRFs on connected routers. The routers are physically connected with the ASAs by means of Trunked Etherchannel.

Routing protocol is EIGRP.

Any insights and assistance would be greatly appreciated.

Thanks

Cathy

 

2 Replies 2

Cathy Ellis
Level 1
Level 1

We fixed this issue by first disabling and then re-enabling anti-spoofing on all of the monitored logical interfaces.

Discovered today that the 'fix' I mention above is more of a workaround, because when I initiated a manual failover for one of the failover groups, the alerts returned. And the failover status was again on Normal (Waiting) for a couple of monitored logical interfaces.

I was able to workaround the problem as described above.

Review Cisco Networking for a $25 gift card