Technical Tip: Explanation of log deny_cause=packet-sanity

[maydin]

Description	This article explains in which scenarios FortiCarrier can drop GTP packets with deny_cause=packet-sanity. Each GTP packet is validated against 3GPP standards, and if it fails any mandatory checks, it may be dropped. Only packets that fail specific mandatory checks are logged with this deny cause.
Scope	All FortiCarrier.
Solution	A brief overview of Packet sanity checking can be found in FortiOS Carrier documentation:  Packet sanity checking Below is a more detailed description: When GTP packets are processed, FortiCarrier checks them against 3GPP specifications (TS 29.060 and TS 29.274). The following mandatory checks are performed: Check the mandatory header of the GTP packet (8 octets). Check whether actual packet length is fit to the length field in the packet. Check extension header(If there is one). Check the message type, whether it falls into the reserved message. Check the length of the packets. It should be between the min-max length configured in the profile. Check the IE(Information elements) inside the packet. Important: Only the failures highlighted in red are logged as deny_cause=packet-sanity. Example Case: In the provided packet log (Delete Bearer Response, type 100, ietype=93), the Cause value was 0, which is invalid per ETSI 3GPP TS 29.274 (Section 8.4, Page 251). Such packets are dropped for packet sanity legitimately: Log: Packet capture: See in the above capture screenshot, the Cause value for IE type 93 is 0. 3GPP on Cause value 0:   How to troubleshoot similar issues: Capture and analyze the dropped GTP packet and relevant IE fields. Verify IE fields against the 3GPP specifications: 3GPP TS 29.060 V15.5.0 0 - GTPv1. 3GPP TS 29.274 V15.9.0 - GTPv2. Confirm whether the peer device is sending packets with invalid header/IE values.