Cisco SCPS traffic being dropped

[migration]

I thought I'd ask this here as I feel like it may show up again sometime if someone has an answer.  We're deploying Palo Alto behind a pair of Cisco ASAs and there's a minor issue.  It looks like (through packet capture on the Palo Altos) SCPS traffic is being dropped between the ASAs on their inside interfaces.  The ASAs report an error about every 10 seconds that their internal interfaces can't communicate.  I do have a permit any any for all traffic right now although if I read documentation correctly, the traffic isn't getting to the Palo Alto firewall rules, it's being dropped due to processing errors.  If anyone's seen this before I'd be interested in the solution, if I find the answer I will post it.

Thanks!

Corbett

[migration]

In this case, I suggest you to use (always) "debug log":

debug dataplane packet-diag set filter match source XX destination YY
debug dataplane packet-diag set filter on
debug dataplane packet-diag set log feature flow basic
debug dataplane packet-diag set clear log log
debug dataplane packet-diag set log on
--initiate the traffic---

This will tell you why some PAN process is blocking some traffic.

[mrajdev]

Just wanted to add a word of caution here, the flow basic debug is CPU intensive, If you have regular traffic causing a moderate CPU for your DP (dataplae), the flow basic debug would cause a spike in the CPU and may cause other traffic issues.

[migration]

iceman and mrajdev,

  Thanks very much for your input.  In doing my own troubleshooting, being provided some assistance from technical support, and learning some commands from you I think it's been resolved.  The traffic is on IP port 105 and doesn't contain session information.  When I created a custom rule for it I was expecting it to work and it didn't.  Reason being (I think) was that the traffic was already blocked (as evidenced by our ASA behavior and some Palo Alto logs tech support showed me) and a new session never started up as the traffic wasn't session-based.  Once tech support cleared the sessions the ASA failover traffic resumed.  I'm sure the traffic was probably originally blocked because we were playing with rules.  On up the learning curve we go.  Thanks again!