NAT, and then finally the ACLs to control whether traffic is allowed to get to a
particular VM. The VFP is also used for outbound traffic from the VM, with the layers
implemented in reverse order (ACLs, then SLB NAT, and finally the virtual network).
The order of application is logical: For incoming traffic, the IP address has to first be
mapped to the virtual network address space by removing the encapsulation, which
currently would be addressed using the datacenter address space; then any NAT has to
be performed, which ensures that all of the packets are now in the virtual network
address space; and finally, ACLs can be applied. All of these flow tables are populated
with policies from the network controller which is another new SDNv2 component
inspired by Azure that is covered in more detail later in this chapter.
Applying all of these layers of rules to every packet would incur a significant
performance penalty. To remediate this, the VFP implements a table-typing algorithm;
a hash-lookup flow-caching table is generated for each flow (connection), and the
complete set of rules are stored. This means that only the first packet for any flow
goes through all of the rules (which could be complex). Subsequent packets from the
same flow would find a match in the flow-caching table and apply those actions. Say
that the final ACL discards the traffic after going through all of the rules. By caching
the result for all future packets, no processing needs to be performed for packets that
are ultimately deleted anyway. This is shown in Figure 3.6, and it is what enables the
VFP to support the fast network speeds that are used in today’s datacenters—40Gbps
and beyond. Additionally, the use of the VFP does not block any offloads to the NIC,
which is critical to ensure optimal performance.