NP6 and NP6lite Acceleration

NP6 and NP6lite network processors provide fastpath acceleration by offloading communication sessions from the FortiGate CPU. When the first packet of a new session is received by an interface connected to an NP6 processor, just like any session connecting with any FortiGate interface, the session is forwarded to the FortiGate CPU where it is matched with a security policy. If the session is accepted by a security policy and if the session can be offloaded its session key is copied to the NP6 processor that received the packet. All of the rest of the packets in the session are intercepted by the NP6 processor and fast-pathed out of the FortiGate unit to their destination without ever passing through the FortiGate CPU. The result is enhanced network performance provided by the NP6 processor plus the network processing load is removed from the CPU. In addition the NP6 processor can handle some CPU intensive tasks, like IPsec VPN encryption/decryption.

note icon NP6lite processors have the same architecture and function in the same way as NP6 processors. See NP6Lite processors. All of the descriptions of NP6 processors in this document can be applied to NP6lite possessors except where noted.

Session keys (and IPsec SA keys) are stored in the memory of the NP6 processor that is connected to the interface that received the packet that started the session. All sessions are fast-pathed and accelerated, even if they exit the FortiGate unit through an interface connected to another NP6. There is no dependence on getting the right pair of interfaces since the offloading is done by the receiving NP6.

The key to making this possible is an Integrated Switch Fabric (ISF) that connects the NP6s and the FortiGate unit interfaces together. Many FortiGate units with NP6 processors also have an ISF. The ISF allows any port connectivity. All ports and NP6s can communicate with each other over the ISF. There are no special ingress and egress fast path requirements as long as traffic enters and exits on interfaces connected to the same ISF.

Some FortiGate units, such as the FortiGate-1000D include multiple NP6 processors that are not connected by an ISF. Because the ISF is not present fast path acceleration is supported only between interfaces connected to the same NP6 processor. Since the ISF introduces some latency, models with no ISF provide low-latency network acceleration between network interfaces connected to the same NP6 processor.

Each NP6 has a maximum throughput of 40 Gbps using 4 x 10 Gbps XAUI or Quad Serial Gigabit Media Independent Interface (QSGMII) interfaces or 3 x 10 Gbps and 16 x 1 Gbps XAUI or QSGMII interfaces.

There are at least two limitations to keep in mind:

  • The capacity of each NP6 processor. An individual NP6 processor can support between 10 and 16 million sessions. This number is limited by the amount of memory the processor has. Once an NP6 processor hits its session limit, sessions that are over the limit are sent to the CPU. You can avoid this problem by as much as possible distributing incoming sessions evenly among the NP6 processors. To be able to do this you need to be aware of which interfaces connect to which NP6 processors and distribute incoming traffic accordingly.
  • The NP6 processors in some FortiGate units employ NP direct technology that removes the ISF. The result is very low latency but no inter-processor connectivity requiring you to make sure that traffic to be offloaded enters and exits the FortiGate through interfaces connected to the same NP processor.

NP6 session fast path requirements

NP6 processors can offload the following traffic and services:

  • IPv4 and IPv6 traffic and NAT64 and NAT46 traffic (as well as IPv4 and IPv6 versions of the following traffic types where appropriate)
  • Link aggregation (LAG) (IEEE 802.3ad) traffic and traffic from static redundant interfaces (see Increasing NP6 offloading capacity using link aggregation groups (LAGs))
  • TCP, UDP, ICMP and SCTP traffic
  • IPsec VPN traffic, and offloading of IPsec encryption/decryption (including SHA2-256 and SHA2-512)
  • NP6 processor IPsec engines support null, DES, 3DES, AES128, AES192, and AES256 encryption algorithms
  • NP6 processor IPsec engines support null, MD5, SHA1, SHA256, SHA 384, and SHA512 authentication algorithms
  • IPsec traffic that passes through a FortiGate without being unencrypted.
  • Anomaly-based intrusion prevention, checksum offload and packet defragmentation.
  • IPIP tunneling (also called IP in IP tunneling), SIT tunneling, and IPv6 tunneling sessions.
  • Multicast traffic (including Multicast over IPsec).
  • CAPWAP and wireless bridge traffic tunnel encapsulation to enable line rate wireless forwarding from FortiAP devices (not supported by the NP6lite).
  • Traffic shaping and priority queuing for both shared and per IP traffic shaping.
  • Syn proxying (not supported by the NP6lite).
  • DNS session helper (not supported by the NP6lite).
  • Inter-VDOM link traffic.

Sessions that are offloaded must be fast path ready. For a session to be fast path ready it must meet the following criteria:

  • Layer 2 type/length must be 0x0800 for IPv4 or 0x86dd for IPv6 (IEEE 802.1q VLAN specification is supported).
  • Layer 3 protocol can be IPv4 or IPv6.
  • Layer 4 protocol can be UDP, TCP, ICMP, or SCTP.
  • In most cases, Layer 3 / Layer 4 header or content modification sessions that require a session helper can be offloaded.
  • Local host traffic (originated by the FortiGate unit) can be offloaded.
  • If the FortiGate supports, NTurbo sessions can be offloaded if they are accepted by firewall policies that include IPS, Application Control, CASI, flow-based antivirus, or flow-based web filtering.

Offloading Application layer content modification is not supported. This means that sessions are not offloaded if they are accepted by firewall policies that include proxy-based virus scanning, proxy-based web filtering, DNS filtering, DLP, Anti-Spam, VoIP, ICAP, Web Application Firewall, or Proxy options.

note icon If you disable anomaly checks by Intrusion Prevention (IPS), you can still enable hardware accelerated anomaly checks using the fp-anomaly field of the config system interface CLI command. See Configuring individual NP6 processors.

If a session is not fast path ready, the FortiGate unit will not send the session key or IPsec SA key to the NP6 processor. Without the session key, all session key lookup by a network processor for incoming packets of that session fails, causing all session packets to be sent to the FortiGate unit’s main processing resources, and processed at normal speeds.

If a session is fast path ready, the FortiGate unit will send the session key or IPsec SA key to the network processor. Session key or IPsec SA key lookups then succeed for subsequent packets from the known session or IPsec SA.

Packet fast path requirements

Packets within the session must then also meet packet requirements.

  • Incoming packets must not be fragmented.
  • Outgoing packets must not require fragmentation to a size less than 385 bytes. Because of this requirement, the configured MTU (Maximum Transmission Unit) for a network processor’s network interfaces must also meet or exceed the network processors’ supported minimum MTU of 385 bytes.

Mixing fast path and non-fast path traffic

If packet requirements are not met, an individual packet will be processed by the FortiGate CPU regardless of whether other packets in the session are offloaded to the NP6.

Also, in some cases, a protocol’s session(s) may receive a mixture of offloaded and non-offloaded processing. For example, VoIP control packets may not be offloaded but VoIP data packets (voice packets) may be offloaded.

NP6Lite processors

The NP6Lite works the same way as the NP6. Being a lighter version, the NP6Lite has a lower capacity than the NP6. The NP6lite max throughput is 10 Gbps using 2x QSGMII and 2x Reduced gigabit media-independent interface (RGMII) interfaces.

Also, the NP6lite does not offload the following types of sessions:

  • CAPWAP
  • Syn proxy
  • DNS session helper

NP6 and NP6Lite processors and sFlow and NetFlow

NP6 and NP6Lite offloading is supported when you configure NetFlow for interfaces connected to NP6 or NP6Lite processors. Offloading of other sessions is not affected by configuring NetFlow.

Configuring sFlow on any interface disables all NP6 and NP6Lite offloading for all traffic on that interface.

NP6 processors and traffic shaping

NP6-offloaded traffic supports traffic shaping just like any other traffic with one exception: configuring in bandwidth traffic shaping has no effect on NP6 accelerated traffic. In bandwidth traffic shaping sets the bandwidth limit for incoming traffic for an interface.

Out bandwidth traffic shaping is supported. Out bandwidth traffic shaping sets the bandwidth limit for outgoing traffic for an interface. You can use the following command to configure out bandwidth traffic shaping:

config system interface

edit port1

set outbandwidth 2000

end

NP Direct

On FortiGates with more than one NP6 processor, removing the Internal Switch Fabric (ISF) for NP Direct architecture provides direct access to the NP6 processors for the lowest latency forwarding. Because the NP6 processors are not connected, care must be taken with network design to make sure that all traffic to be offloaded enters and exits the FortiGate through interfaces connected to the same NP6 processor. As well Link Aggregation (LAG) interfaces should only include interfaces all connected to the same NP6 processor.

Example NP direct hardware with more than one NP6 processor includes:

  • Ports 25 to 32 of the FortiGate-3700D in low latency mode.
  • FortiGate-2000E
  • FortiGate-2500E

Viewing your FortiGate NP6 processor configuration

Use either of the following commands to view the NP6 processor hardware configuration of your FortiGate unit:

get hardware npu np6 port-list

diagnose npu np6 port-list

If your FortiGate has NP6lite processors, you can use either of the following commands:

get hardware npu np6lite port-list

diagnose npu np6lite port-list

For example, for the FortiGate-5001D the output would be:

get hardware npu np6 port-list
Chip   XAUI Ports            Max   Cross-chip 
                             Speed offloading 
------ ---- -------          ----- ---------- 
np6_0  0    port3            10G   Yes        
       1    
       2    base1            1G    Yes        
       3    
       0-3  port1            40G   Yes        
       0-3  fabric1          40G   Yes        
       0-3  fabric3          40G   Yes        
       0-3  fabric5          40G   Yes        
------ ---- -------          ----- ---------- 
np6_1  0    
       1    port4            10G   Yes        
       2    
       3    base2            1G    Yes        
       0-3  port2            40G   Yes        
       0-3  fabric2          40G   Yes        
       0-3  fabric4          40G   Yes        
------ ---- -------          ----- ---------- 

For more example output for different FortiGate models, see FortiGate NP6 architectures and FortiGate NP6lite architectures.

You can also use the following command to view the offloading features enabled or disabled on each of the NP6 processors in your FortiGate unit:

diagnose npu npu-feature
                    np_0      np_1    
------------------- --------- --------- 
Fastpath            Enabled   Enabled   
Low-latency-mode    Disabled  Disabled  
Low-latency-cap     No        No        
IPv4 firewall       Yes       Yes       
IPv6 firewall       Yes       Yes       
IPv4 IPSec          Yes       Yes       
IPv6 IPSec          Yes       Yes       
IPv4 tunnel         Yes       Yes       
IPv6 tunnel         Yes       Yes       
GRE tunnel          No        No        
IPv4 Multicast      Yes       Yes       
IPv6 Multicast      Yes       Yes       
CAPWAP              Yes       Yes       

Optimizing NP6 performance by distributing traffic to XAUI links

On most FortiGate units with NP6 processors, the FortiGate interfaces are switch ports that connect to the NP6 processors with XAUI links. Packets pass from the interfaces to the NP6 processor over the XAUI links. Each NP6 processor has a 40 Gigabit bandwidth capacity. The four XAUI links each have a 10 Gigabit capacity for a total of 40 Gigabits.

On many FortiGate units with NP6 processors, the NP6 processors and the XAUI links are over-subscribed. Since the NP6 processors are connected by an Integrated Switch Fabric, you do not have control over how traffic is distributed to them. In fact traffic is distributed evenly by the ISF.

However, you can control how traffic is distributed to the XAUI links and you can optimize performance by distributing traffic evenly among the XAUI links. For example, if you have a very high amount of traffic passing between two networks, you can connect each network to interfaces connected to different XAUI links to distribute the traffic for each network to a different XAUI link.

For example, on a FortiGate-3200D (See FortiGate-3200D fast path architecture), there are 48 10-Gigabit interfaces that send and receive traffic for two NP6 processors over a total of eight 10-Gigabit XAUI links. Each XAUI link gets traffic from six 10-Gigabit FortiGate interfaces. The amount of traffic that the FortiGate-3200D can offload is limited by the number of NP6 processors and the number of XAUI links. You can optimize the amount of traffic that the FortiGate-3200D can process by distributing it evenly amount the XAUI links and the NP6 processors.

You can see the Ethernet interface, XAUI link, and NP6 configuration by entering the get hardware npu np6 port-list command. For the FortiGate-3200D the output is:

get hardware npu np6 port-list 
Chip   XAUI Ports   Max   Cross-chip 
                    Speed offloading 
------ ---- ------- ----- ---------- 
np6_0  0    port1   10G   Yes        
       0    port5   10G   Yes        
       0    port10  10G   Yes        
       0    port13  10G   Yes        
       0    port17  10G   Yes        
       0    port22  10G   Yes        
       1    port2   10G   Yes        
       1    port6   10G   Yes        
       1    port9   10G   Yes        
       1    port14  10G   Yes        
       1    port18  10G   Yes        
       1    port21  10G   Yes        
       2    port3   10G   Yes        
       2    port7   10G   Yes        
       2    port12  10G   Yes        
       2    port15  10G   Yes        
       2    port19  10G   Yes        
       2    port24  10G   Yes        
       3    port4   10G   Yes        
       3    port8   10G   Yes        
       3    port11  10G   Yes        
       3    port16  10G   Yes        
       3    port20  10G   Yes        
       3    port23  10G   Yes        
------ ---- ------- ----- ---------- 
np6_1  0    port26  10G   Yes        
       0    port29  10G   Yes        
       0    port33  10G   Yes        
       0    port37  10G   Yes        
       0    port41  10G   Yes        
       0    port45  10G   Yes        
       1    port25  10G   Yes        
       1    port30  10G   Yes        
       1    port34  10G   Yes        
       1    port38  10G   Yes        
       1    port42  10G   Yes        
       1    port46  10G   Yes        
       2    port28  10G   Yes        
       2    port31  10G   Yes        
       2    port35  10G   Yes        
       2    port39  10G   Yes        
       2    port43  10G   Yes        
       2    port47  10G   Yes        
       3    port27  10G   Yes        
       3    port32  10G   Yes        
       3    port36  10G   Yes        
       3    port40  10G   Yes        
       3    port44  10G   Yes        
       3    port48  10G   Yes        
------ ---- ------- ----- ----------

In this command output you can see that each NP6 has for four XAUI links (0 to 3) and that each XAUI link is connected to six 10-gigabit Ethernet interfaces. To optimize throughput you should keep the amount of traffic being processed by each XAUI port to under 10 Gbps. So for example, if you want to offload traffic from four 10-gigabit networks you can connect these networks to Ethernet interfaces 1, 2, 3 and 4. This distributes the traffic from each 10-Gigabit network to a different XAUI link. Also, if you wanted to offload traffic from four more 10-Gigabit networks you could connect them to Ethernet ports 26, 25, 28, and 27. As a result each 10-Gigabit network would be connected to a different XAUI link.

Increasing NP6 offloading capacity using link aggregation groups (LAGs)

NP6 processors can offload sessions received by interfaces in link aggregation groups (LAGs) (IEEE 802.3ad). A 802.3ad Link Aggregation and it's management protocol, Link Aggregation Control Protocol (LACP) LAG combines more than one physical interface into a group that functions like a single interface with a higher capacity than a single physical interface. For example, you could use a LAG if you want to offload sessions on a 30 Gbps link by adding three 10-Gbps interfaces to the same LAG.

All offloaded traffic types are supported by LAGs, including IPsec VPN traffic. Just like with normal interfaces, traffic accepted by a LAG is offloaded by the NP6 processor connected to the interfaces in the LAG that receive the traffic to be offloaded. If all interfaces in a LAG are connected to the same NP6 processor, traffic received by that LAG is offloaded by that NP6 processor. The amount of traffic that can be offloaded is limited by the capacity of the NP6 processor.

If a FortiGate has two or more NP6 processors connected by an integrated switch fabric (ISF), you can use LAGs to increase offloading by sharing the traffic load across multiple NP6 processors. You do this by adding physical interfaces connected to different NP6 processors to the same LAG.

Adding a second NP6 processor to a LAG effectively doubles the offloading capacity of the LAG. Adding a third further increases offloading. The actual increase in offloading capacity may not actually be doubled by adding a second NP6 or tripled by adding a thrid. Traffic and load conditions and other factors may limit the actual offloading result.

The increase in offloading capacity offered by LAGs and multiple NP6s is supported by the integrated switch fabric (ISF) that allows multiple NP6 processors to share session information. Most FortiGate units with multiple NP6 processors also have an ISF. However, FortiGate models such as the 1000D, 2000E, and 2500E do not have an ISF. If you attempt to add interfaces connected to different NP6 processors to a LAG the system displays an error message.

There are also a few limitations to LAG NP6 offloading support for IPsec VPN:

  • IPsec VPN anti-replay protection cannot be used if IPSec is configured on a LAG that has interfaces connected to multiple NP6 processors.
  • Because the encrypted traffic for one IPsec VPN tunnel has the same 5-tuple, the traffic from one tunnel can only can be balanced to one interface in a LAG. This limits the maximum throughput for one IPsec VPN tunnel in an NP6 LAG group to 10Gbps.

NP6 processors and redundant interfaces

NP6 processors can offload sessions received by interfaces that are part of a redundant interface. You can combine two or more physical interfaces into a redundant interface to provide link redundancy. Redundant interfaces ensure connectivity if one physical interface, or the equipment on that interface, fails. In a redundant interface, traffic travels only over one interface at a time. This differs from an aggregated interface where traffic travels over all interfaces for distribution of increased bandwidth.

All offloaded traffic types are supported by redundant interfaces, including IPsec VPN traffic. Just like with normal interfaces, traffic accepted by a redundant interface is offloaded by the NP6 processor connected to the interfaces in the redundant interface that receive the traffic to be offloaded. If all interfaces in a redundant interface are connected to the same NP6 processor, traffic received by that redundant interface is offloaded by that NP6 processor. The amount of traffic that can be offloaded is limited by the capacity of the NP6 processor.

If a FortiGate has two or more NP6 processors connected by an integrated switch fabric (ISF), you can create redundant interfaces that include physical interfaces connected to different NP6 processors. However, with a redundant interface, only one of the physical interfaces is processing traffic at any given time. So you cannot use redundant interfaces to increase performance in the same way as you can with aggregate interfaces.

The ability to add redundnat interfaces connected to multiple NP6s is supported by the integrated switch fabric (ISF) that allows multiple NP6 processors to share session information. Most FortiGate units with multiple NP6 processors also have an ISF. However, FortiGate models such as the 1000D, 2000E, and 2500E do not have an ISF. If you attempt to add interfaces connected to different NP6 processors to a redundant interface the system displays an error message.

Configuring Inter-VDOM link acceleration with NP6 processors

FortiGate units with NP6 processors include inter-VDOM links that can be used to accelerate inter-VDOM link traffic.

  • For a FortiGate unit with two NP6 processors there are two accelerated inter-VDOM links, each with two interfaces:
  • npu0_vlink:
    npu0_vlink0
    npu0_vlink1
  • npu1_vlink:
    npu1_vlink0
    npu1_vlink1

These interfaces are visible from the GUI and CLI. For a FortiGate unit with NP6 interfaces, enter the following CLI command to display the NP6-accelerated inter-VDOM links:

get system interface

...

== [ npu0_vlink0 ]

name: npu0_vlink0 mode: static ip: 0.0.0.0 0.0.0.0 status: down netbios-forward: disable type: physical sflow-sampler: disable explicit-web-proxy: disable explicit-ftp-proxy: disable mtu-override: disable wccp: disable drop-overlapped-fragment: disable drop-fragment: disable

 

== [ npu0_vlink1 ]

name: npu0_vlink1 mode: static ip: 0.0.0.0 0.0.0.0 status: down netbios-forward: disable type: physical sflow-sampler: disable explicit-web-proxy: disable explicit-ftp-proxy: disable mtu-override: disable wccp: disable drop-overlapped-fragment: disable drop-fragment: disable

 

== [ npu1_vlink0 ]

name: npu1_vlink0 mode: static ip: 0.0.0.0 0.0.0.0 status: down netbios-forward: disable type: physical sflow-sampler: disable explicit-web-proxy: disable explicit-ftp-proxy: disable mtu-override: disable wccp: disable drop-overlapped-fragment: disable drop-fragment: disable

 

== [ npu1_vlink1 ]

name: npu1_vlink1 mode: static ip: 0.0.0.0 0.0.0.0 status: down netbios-forward: disable type: physical sflow-sampler: disable explicit-web-proxy: disable explicit-ftp-proxy: disable mtu-override: disable wccp: disable drop-overlapped-fragment: disable drop-fragment: disable

...

By default the interfaces in each inter-VDOM link are assigned to the root VDOM. To use these interfaces to accelerate inter-VDOM link traffic, assign each interface in the pair to the VDOMs that you want to offload traffic between. For example, if you have added a VDOM named New-VDOM to a FortiGate unit with NP4 processors, you can go to System > Network > Interfaces and edit the npu0-vlink1 interface and set the Virtual Domain to New-VDOM. This results in an accelerated inter-VDOM link between root and New-VDOM. You can also do this from the CLI:

config system interface

edit npu0-vlink1

set vdom New-VDOM

end

Using VLANs to add more accelerated Inter-VDOM links

You can add VLAN interfaces to the accelerated inter-VDOM links to create inter-VDOM links between more VDOMs. For the links to work, the VLAN interfaces must be added to the same inter-VDOM link, must be on the same subnet, and must have the same VLAN ID.

For example, to accelerate inter-VDOM link traffic between VDOMs named Marketing and Engineering using VLANs with VLAN ID 100 go to System > Network > Interfaces and select Create New to create the VLAN interface associated with the Marketing VDOM:

Name Marketing-link
Type VLAN
Interface npu0_vlink0
VLAN ID 100
Virtual Domain Marketing
IP/Network Mask 172.20.120.12/24

Create the inter-VDOM link associated with Engineering VDOM:

Name Engineering-link
Type VLAN
Interface npu0_vlink1
VLAN ID 100
Virtual Domain Engineering
IP/Network Mask 172.20.120.22/24

Or do the same from the CLI:

config system interface

edit Marketing-link

set vdom Marketing

set ip 172.20.120.12/24

set interface npu0_vlink0

set vlanid 100

next

edit Engineering-link

set vdom Engineering

set ip 172.20.120.22/24

set interface npu0_vlink1

set vlanid 100

Confirm that the traffic is accelerated

Use the following CLI commands to obtain the interface index and then correlate them with the session entries. In the following example traffic was flowing between new accelerated inter-VDOM links and physical ports port1 and port 2 also attached to the NP6 processor.

diagnose ip address list

IP=172.31.17.76->172.31.17.76/255.255.252.0 index=5 devname=port1

IP=10.74.1.76->10.74.1.76/255.255.252.0 index=6 devname=port2

IP=172.20.120.12->172.20.120.12/255.255.255.0 index=55 devname=IVL-VLAN1_ROOT

IP=172.20.120.22->172.20.120.22/255.255.255.0 index=56 devname=IVL-VLAN1_VDOM1

 

diagnose sys session list

session info: proto=1 proto_state=00 duration=282 expire=24 timeout=0 session info: proto=1 proto_state=00 duration=124 expire=59 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3

origin-shaper=

reply-shaper=

per_ip_shaper=

ha_id=0 policy_dir=0 tunnel=/

state=may_dirty npu

statistic(bytes/packets/allow_err): org=180/3/1 reply=120/2/1 tuples=2

orgin->sink: org pre->post, reply pre->post dev=55->5/5->55 gwy=172.31.19.254/172.20.120.22

hook=post dir=org act=snat 10.74.2.87:768->10.2.2.2:8(172.31.17.76:62464)

hook=pre dir=reply act=dnat 10.2.2.2:62464->172.31.17.76:0(10.74.2.87:768)

misc=0 policy_id=4 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0

serial=0000004e tos=ff/ff ips_view=0 app_list=0 app=0

dd_type=0 dd_mode=0

per_ip_bandwidth meter: addr=10.74.2.87, bps=880

npu_state=00000000

npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=160/218, ipid=218/160, vlan=32769/0

 

 

session info: proto=1 proto_state=00 duration=124 expire=20 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3

origin-shaper=

reply-shaper=

per_ip_shaper=

ha_id=0 policy_dir=0 tunnel=/

state=may_dirty npu

statistic(bytes/packets/allow_err): org=180/3/1 reply=120/2/1 tuples=2

orgin->sink: org pre->post, reply pre->post dev=6->56/56->6 gwy=172.20.120.12/10.74.2.87

hook=pre dir=org act=noop 10.74.2.87:768->10.2.2.2:8(0.0.0.0:0)

hook=post dir=reply act=noop 10.2.2.2:768->10.74.2.87:0(0.0.0.0:0)

misc=0 policy_id=3 id_policy_id=0 auth_info=0 chk_client_info=0 vd=1

serial=0000004d tos=ff/ff ips_view=0 app_list=0 app=0

dd_type=0 dd_mode=0

per_ip_bandwidth meter: addr=10.74.2.87, bps=880

npu_state=00000000

npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=219/161, ipid=161/219, vlan=0/32769

total session 2

Disabling offloading IPsec Diffie-Hellman key exchange

You can use the following command to disable using ASIC offloading to accelerate IPsec Diffie-Hellman key exchange for IPsec ESP traffic. By default hardware offloading is used. For debugging purposes or other reasons you may want this function to be processed by software.

Use the following command to disable using ASIC offloading for IPsec Diffie Hellman key exchange:

config system global

set ipsec-asic-offload disable

end

Configuring individual NP6 processors

You can use the config system np6 command to configure a wide range of settings for the NP6 processors in your FortiGate unit including enabling/disabling fastpath and low latency, enabling session accounting and adjusting session timeouts. As well you can set anomaly checking for IPv4 and IPv6 traffic. You can also configure different settings for each NP6 processor.

The settings that you configure for an NP6 processor with the config system np6 command apply to traffic processed by all interfaces connected to that NP6 processor. This includes the physical interfaces connected to the NP6 processor as well as all subinterfaces, VLAN interfaces, IPsec interfaces, LAGs and so on associated with the physical interfaces connected to the NP6 processor.

note icon Some of the options for this command apply anomaly checking for NP6 sessions in the same way as the command described in Offloading NP4 anomaly detection applies anomaly checking for for NP4 sessions.

config system np6

edit <np6-processor-name>

set fastpath {disable | enable}

set low-latency-mode {disable | enable}

set per-session-accounting {all-enable | disable | enable-by-log}

set session-timeout-random-range <range>

set garbage-session-collector {disable | enable}

set session-collector-interval <range>

set session-timeout-interval <range>

set session-timeout-random-range <range>

set session-timeout-fixed {disable | enable}

config fp-anomaly

set icmp-frag {allow | drop | trap-to-host}

set icmp-land {allow | drop | trap-to-host}

set ipv4-land {allow | drop | trap-to-host}

set ipv4-optlsrr {allow | drop | trap-to-host}

set ipv4-optrr {allow | drop | trap-to-host}

set ipv4-optsecurity {allow | drop | trap-to-host}

set ipv4-optssrr {allow | drop | trap-to-host}

set ipv4-optstream {allow | drop | trap-to-host}

set ipv4-opttimestamp {allow | drop | trap-to-host}

set ipv4-proto-err {allow | drop | trap-to-host}

set ipv4-unknopt {allow | drop | trap-to-host}

set tcp-land {allow | drop | trap-to-host}

set tcp-syn-fin {allow | drop | trap-to-host}

set tcp-winnuke {allow | drop | trap-to-host}

set tcp_fin_noack {allow | drop | trap-to-host}

set tcp_fin_only {allow | drop | trap-to-host}

set tcp_no_flag {allow | drop | trap-to-host}

set tcp_syn_data {allow | drop | trap-to-host}

set udp-land {allow | drop | trap-to-host}

end

config fp-anomaly-v6

set ipv6-daddr_err {allow | drop | trap-to-host}

set ipv6-land {allow | drop | trap-to-host}

set ipv6-optendpid {allow | drop | trap-to-host}

set ipv6-opthomeaddr {allow | drop | trap-to-host}

set ipv6-optinvld {allow | drop | trap-to-host}

set ipv6-optjumbo {allow | drop | trap-to-host}

set ipv6-optnsap {allow | drop | trap-to-host}

set ipv6-optralert {allow | drop | trap-to-host}

set ipv6-opttunnel {allow | drop | trap-to-host}

set ipv6-proto-err {allow | drop | trap-to-host}

set ipv6-saddr_err {allow | drop | trap-to-host}

set ipv6-unknopt {allow | drop | trap-to-host}

end

Command syntax
Command Description Default
fastpath {disable | enable} Enable fastpath acceleration to offload sessions to the NP6 processor. You can disable fastpath if you don’t want the NP6 processor to offload sessions. enable
low-latency-mode {disable | enable} Enable low-latency mode. In low latency mode the integrated switch fabric is bypassed. Low latency mode requires that packet enter and exit using the same NP6 processor. This option is only available for NP6 processors that can operate in low-latency mode, currently only np6_0 and np6_1 on the FortiGate-3700D and DX. disable
per-session-accounting {all-enable | disable | enable-by-log} Disable NP6 per-session accounting or enable it and control how it works. If set to enable-by-log (the default) NP6 per-session accounting is only enabled if firewall policies accepting offloaded traffic have traffic logging enabled. If set the all-enable, NP6 per-session accounting is always enabled for all traffic offloaded by the NP6 processor.

Enabling per-session accounting can affect performance.
enable-by-log
garbage-session-collector {disable | enable} Enable deleting expired or garbage sessions. disable
session-collector-interval <range> Set the expired or garbage session collector time interval in seconds. The range is 1 to 100 seconds. 8
session-timeout-interval <range> Set the timeout for inactive sessions. The range is 0 to 1000 seconds. 40
session-timeout-random-range <range> Set the random timeout for inactive sessions. The range is 0 to 1000 seconds. 8
session-timeout-fixed {disable | enable} Force session timeouts at fixed instead of random intervals. disable
config fp-anomaly
fp-anomaly Configure how the NP6 processor does IPv4 traffic anomaly protection. You can configure the NP6 processor to allow or drop the packets associated with an attack or forward the packets that are associated with the attack to FortiOS (called “trap-to-host”). Selecting “trap-to-host” turns off NP6 anomaly protection for that anomaly. If you require anomaly protection you can enable it with a DoS policy.  
icmp-frag {allow | drop | trap-to-host} Detects Layer 3 fragmented packets that could be part of a layer 4 ICMP anomalies. allow
icmp-land {allow | drop | trap-to-host} Detects ICMP land anomalies. trap-to-host
ipv4-land {allow | drop | trap-to-host} Detects IPv4 land anomalies. trap-to-host
ipv4-optlsrr {allow | drop | trap-to-host} Detects IPv4 with loose source record route option anomalies. trap-to-host
ipv4-optrr {allow | drop | trap-to-host} Detects IPv4 with record route option anomalies. trap-to-host
ipv4-optsecurity {allow | drop | trap-to-host} Detects security option anomalies. trap-to-host
ipv4-optssrr {allow | drop | trap-to-host} Detects IPv4 with strict source record route option anomalies. trap-to-host
ipv4-optstream {allow | drop | trap-to-host} Detects stream option anomalies. trap-to-host
ipv4-opttimestamp {allow | drop | trap-to-host} Detects timestamp option anomalies. trap-to-host
ipv4-proto-err {allow | drop | trap-to-host} Detects invalid layer 4 protocol anomalies. trap-to-host
ipv4-unknopt {allow | drop | trap-to-host} Detects unknown option anomalies. trap-to-host
tcp-land {allow | drop | trap-to-host} Detects TCP land anomalies. trap-to-host
tcp-syn-fin {allow | drop | trap-to-host} Detects TCP SYN flood SYN/FIN flag set anomalies. allow
tcp-winnuke {allow | drop | trap-to-host} Detects TCP WinNuke anomalies. trap-to-host
tcp_fin_noack {allow | drop | trap-to-host} Detects TCP SYN flood with FIN flag set without ACK setting anomalies. trap-to-host
tcp_fin_only {allow | drop | trap-to-host} Detects TCP SYN flood with only FIN flag set anomalies. trap-to-host
tcp_no_flag {allow | drop | trap-to-host} Detects TCP SYN flood with no flag set anomalies. allow
tcp_syn_data {allow | drop | trap-to-host} Detects TCP SYN flood packets with data anomalies. allow
udp-land {allow | drop | trap-to-host} Detects UDP land anomalies. trap-to-host
config fp-anomaly-v6
fp-anomaly-v6 Configure how the NP6 processor does IPv6 traffic anomaly protection. You can configure the NP6 processor to allow or drop the packets associated with an attack or forward the packets that are associated with the attack to FortiOS (called “trap-to-host”). Selecting “trap-to-host” turns off NP6 anomaly protection for that anomaly. If you require anomaly protection you can enable it with a DoS policy.  
ipv6-daddr_err {allow | drop | trap-to-host} Detects destination address as unspecified or loopback address anomalies. trap-to-host
ipv6-land {allow | drop | trap-to-host} Detects IPv6 land anomalies trap-to-host
ipv6-optendpid {allow | drop | trap-to-host} Detects end point identification anomalies. trap-to-host
ipv6-opthomeaddr {allow | drop | trap-to-host} Detects home address option anomalies. trap-to-host
ipv6-optinvld {allow | drop | trap-to-host} Detects invalid option anomalies. trap-to-host
ipv6-optjumbo {allow | drop | trap-to-host} Detects jumbo options anomalies. trap-to-host
ipv6-optnsap {allow | drop | trap-to-host} Detects network service access point address option anomalies. trap-to-host
ipv6-optralert {allow | drop | trap-to-host} Detects router alert option anomalies. trap-to-host
ipv6-opttunnel {allow | drop | trap-to-host} Detects tunnel encapsulation limit option anomalies. trap-to-host
ipv6-proto-err {allow | drop | trap-to-host} Detects layer 4 invalid protocol anomalies. trap-to-host
ipv6-saddr_err {allow | drop | trap-to-host} Detects source address as multicast anomalies. trap-to-host
ipv6-unknopt {allow | drop | trap-to-host} Detects unknown option anomalies. trap-to-host

Enabling per-session accounting for offloaded NP6 sessions

For NP6 processors, you can use the following command to enable per-session accounting for the NP6_0 and -byNP6_1 NP6 processors in a FortiGate unit:

config system np6

edit np6_0

set per-session-accounting enable-by-log

next

edit np6_1

set per-session-accounting enable-by-log

end

Per session accounting is a logging feature that allows the FortiGate to report the correct bytes/pkt numbers per session for sessions offloaded to an NP6 processor. This information appears in traffic log messages as well as in FortiView. When offloaded sessions appear on the FortiView All Sessions console they include an icon identifying them as NP sessions:

You can hover over the NP icon to see some information about the offloaded sessions.

By default, per-session-accounting is set to enable-by-log, which results in per-session accounting being turned on when you enable traffic logging in a policy. You can disable per-session accounting or set all-enable to enable per-session accounting whether or not traffic logging is enabled. Note that this configuration is set separately for each NP6 processor.

Per-session accounting can affect NP6 offloading performance. So you should only enable per-session accounting if you need the accounting information.

Enabling per-session accounting only supports traffic log messages and does not provide traffic flow data for sFlow or NetFlow.

Configure the number of IPsec engines NP6 processors use

NP6 processors use multiple IPsec engines to accelerate IPsec encryption and decryption. In some cases out of order ESP packets can cause problems if multiple IPsec engines are running. To resolve this problem you can configure all of the NP6 processors to use fewer IPsec engines.

Use the following command to change the number of IPsec engines used for decryption (ipsec-dec-subengine-mask) and encryption (ipsec-enc-subengine-mask). These settings are applied to all of the NP6 processors in the FortiGate unit.

config system npu

set ipsec-dec-subengine-mask <engine-mask>

set ipsec-enc-subengine-mask <engine-mask>

end

<engine-mask> is a hexadecimal number in the range 0x01 to 0xff where each bit represents one IPsec engine. The default <engine-mask> for both options is 0xff which means all IPsec engines are used. Add a lower <engine-mask> to use fewer engines. You can configure different engine masks for encryption and decryption.