|
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 the 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 a couple of times to see which counter is rising.
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, indicating that the traffic shaper packets are getting dropped. To resolve the drop, it is necessary to reshape or modify the traffic shaper. The possible case might be that the shaper is getting overloaded, and traffic is dropping due to a lack of bandwidth.
Depending on the type of the NPU processor, the command will vary:
For np6xlite: diagnose npu np6xlite dce 0.
For np6lite: diagnose npu np6lite dce 0.
Furthermore, in the device is an NP6 with multiple processors. The command should be executed for all the processors. For example, if the device has two NPU processors, the following commands should be executed:
diagnose npu np6 dce 0
diagnose npu np6 dce 1
To identify which shaper is hitting the traffic, it can be shown from the session list.
LAB1 # diagnose sys session filter src 172.25.219.250 <--- To filter source IP.
LAB1 # diagnose sys session filter dst 198.19.192.213 <--- To filter destination IP.
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
|
