ASA interface monitoring in waiting state with RPF enabled

[klaus.kruse]

Hello!

I've a pair of ASA5585 running some dated version 9.2(3)4 . It's a failover cluster and we use interface monitoring. I wondered that on secondary one monitored interface was in state "Normal (Waiting)". I did an ICMP packet trace and found this result:

Result:
input-interface: VPN
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (rpf-violated) Reverse-path verify failed

After deactivating RPF, status went to "Normal (Monitored)". Then I activated RPF again and status keeps like this. Looks like a bug for me, but I haven't found the right one in bugsearch. Can anyone help?

Kind regards

Klaus Kruse

[Marius Gunnerud]

Could you do a show running-config for the VPN interface and make sure that there is a standby IP configured for that interface?  Usually when the interface is in Normal(Waiting) state it means that a standby IP has not yet been configured on that interface.

[klaus.kruse]

Hello @Marius Gunnerud ,

Thanks for your suggestion, but standby IP is configured correctly:

interface Port-channel1.100
description VPN
vlan 100
nameif VPN
security-level 60
ip address 10.127.255.9 255.255.255.248 standby 10.127.255.10
ospf database-filter all out

I have this console log for reference:

ASA/act/pri# ping 10.127.255.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.127.255.10, timeout is 2 seconds:
?????

ASA/act/pri# conf t

ASA/act/pri(config)# no ip verify reverse-path interface VPN

ASA/act/pri(config)# exit

ASA/act/pri# ping 10.127.255.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.127.255.10, timeout is 2 seconds:
!!!!!

What do you think?

[Marius Gunnerud]

Interesting.

Would it be possible to remove the ospf database-filter all out command from the interface for a test?

[klaus.kruse]

I can try that, will let you know the outcome.

[klaus.kruse]

Just to give you an update: We didn't test removal of OSPF-filter but urged customer to upgrade and test again. SW is from 2015, we assume a bug.

[Heino Human]

Is there any reason you are not using a /30? 

If you could, change it to a /30 and test again. 

I bet if you look at the arp table on that interface, you will notice the counter/timer will reset over and over again.