Troubleshooting Tip: How to check packet drop by traffic shaper in NP6, NP6xlite and NP6lite unit

[nevan]

Description	This article describes how to check if the packet is getting dropped by traffic shaper in NP6, NP6xlite and NP6lite unit.
Scope	FortiGate [NP6, NP6xlite and NP6lite].
Solution	If the packet is dropping while passing through FortiGate without any packet loss or high latency in the local interface, it can happen due to the traffic overflow in the traffic shaper policy. This drop can be found by checking the dce drops in NPU.  It can be checked if the network process is NP6, NP6lite or NP6xlite. It is important to identify the network processor to check the drop. It can be checked by following command 'diagnose hardware deviceinfo nic <interface>' and checking any of the interfaces.   Once the network processor is identified, the following command can be run to see if it is getting dropped by the shaper. Run it for couple of times to see which counter is raising. CLI Session: LAB1 # diagnose npu np6 dce 0 MACFIL_BASE1 :0000000000001783 [01] IHP1_PKTCHK :0000000000340041 [5b]           XHP0_PKTCHK :0000000000000129 [5e] XHP1_PKTCHK :0000000000000089 [5f]           IPSEC0_ENGINB0 :0000000000083540 [80] IPSEC0_ENGINB1 :0000000000001484 [81]           IPSEC0_ENGINB2 :0000000000000018 [82] IPSEC1_ENGINB0 :0000000000009691 [89]           IPSEC1_ENGINB1 :0000000000000596 [8a] IPSEC1_ENGINB2 :0000000000000019 [8b]           IPSEC1_ENGINB3 :0000000000000001 [8c] TPE_SHAPER :0000001096653472 [94]     LAB1# diagnose npu np6 dce 0           TPE_SHAPER :0000000000000799 [94]     LAB1 # diagnose npu np6 dce 0           TPE_SHAPER :0000000000000135 [94]     LAB1# diagnose npu np6 dce 0           TPE_SHAPER :0000000000000234 [94]     LAB1# diagnose npu np6 dce 0           TPE_SHAPER :0000000000000197 [94] If it is being seen that the TPE_SHAPER is countering and without getting zero the value is changing, it indicates that the traffic shaper packets are getting dropped. To resolve the drop need to reshape or modify the traffic shaper. The possible case might be the shaper is getting overloaded and traffic is dropping due to lack of bandwidth. To identify which shaper is hitting the traffic it can be shown from the session list. LAB1 # diagnose sys session list session info: proto=1 proto_state=00 duration=238 expire=48 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=4 origin-shaper=TEST-Traffic-Shap prio=4 guarantee 0Bps max 625000Bps traffic 486Bps drops 0B reply-shaper=TEST-Traffic-Shap prio=4 guarantee 0Bps max 625000Bps traffic 486Bps drops 0B per_ip_shaper= class_id=0 shaping_policy_id=3 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/1 state=log may_dirty npu os rs f00 statistic(bytes/packets/allow_err): org=9840/164/1 reply=11100/185/1 tuples=2 tx speed(Bps/kbps): 41/0 rx speed(Bps/kbps): 46/0 orgin->sink: org pre->post, reply pre->post dev=219->205/205->219 gwy=172.25.210.66/172.25.219.250 hook=pre dir=org act=noop 172.25.219.250:1->198.19.192.213:8(0.0.0.0:0) hook=post dir=reply act=noop 198.19.192.213:1->172.25.219.250:0(0.0.0.0:0) misc=0 policy_id=206 pol_uuid_idx=1815 auth_info=0 chk_client_info=0 vd=5:10 serial=56f12978 tos=ff/ff app_list=0 app=0 url_cat=0 rpdb_link_id=00000000 ngfwid=n/a npu_state=0x4000c00 ofld-O ofld-R npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=188/188, ipid=188/188, vlan=0x0cb2/0x0d8c vlifid=188/188, vtag_in=0x0cb2/0x0d8c in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=7/2 total session 1 Related articles: Technical Tip: Monitoring 'Traffic Shaping' Technical Tip: How to configure and check which traffic shaper is used