Symptom

Conditions

Workaround

Further Problem Description

Customer is running C8300 with Zone-Based firewall and is seeing the SIP ALG incorrectly dropping traffic from an 8851 and 7841 phones using SIP via TCP From the collected packet traces, (attaching the text file with interested output, as well as the pcap), we see that the packet trace #481 is the last packet we get from Call manager before things break. packet- #482 is sent from SIP phone to call manager, and this is dropped by the ZBFW SIP ALG 478 internal0/0/recycle:0 CONS Packet Consumed Silently 479 INJ.21 Gi0/0/4 FWD 480 Tu4 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet) 481 Tu2000000001 Gi0/0/0.1111 FWD <<<<<<<<<< 482 Gi0/0/0.1111 Tu4 DROP 189 (FirewallL7) <<<<<<<<<< 483 INJ.6 internal0/0/recycle:0 PUNT 22 (QFP Fwall generated packet 484 INJ.6 internal0/0/recycle:0 PUNT 22 (QFP Fwall generated packet 485 INJ.6 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet) Attached the full decode of both 481 and 482 packets in a text file. Feature: VTCP Action : CONSUMED Feature: ALG PARSER Type : SIP ALG Caller : FW Action : RESET THE CONNECTION Feature: OUTPUT_FNF_DROP_SDWAN Entry : Output - 0x814067dc Input : GigabitEthernet0/0/0.1111 Output : Tunnel4 Lapsed time : 5736 ns Feature: OUTPUT_DROP Entry : Output - 0x813f3dfc Input : GigabitEthernet0/0/0.1111 Output : Tunnel4 Lapsed time : 114 ns Feature: MPLS_OUTPUT_INSPECT_FIA Entry : Output - 0x8141eab8 Input : GigabitEthernet0/0/0.1111 Output : Tunnel4 Lapsed time : 37443 ns From the attached pcap file, you will see that the connection is not being resetted all the time, whenever the sip traffic is there, however, it seems as if it randomly decides to drop. The issue seems to be very similar to the defect below. However, it is supposed to be fixed in 17.3.4a as per the defect. So not entirely sure if it exactly matches the defect. However, on some of the packets before the RST packets, I do see PSH bit set as mentioned on this defect. https://cdetsng.cisco.com/summary/#/defect/CSCvw42048 This issue also is similar to what's mentioned in below DDTS. https://cdetsng.cisco.com/summary/#/defect/CSCwa24747 Another issue with this customer is that after our troubleshooting call, a couple of cEdges were crashed while generating the admin-tech. so customer is hesitant to generate admin-tech. So we need to request any additional data if needed as they are not able to generate admin-tech. So far I have show tech but not sure if that would be much useful. I have tried to push for admin-tech, however, keeping the customer sentiment in mind, I think we will have to work with them to fetch any additional data when needed. So apologies in advance for that. Please let me know what info is needed I will reach out to them and gather on call.