Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to parse the vRouter architecture, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something from this article.

Let's first take a look at a conceptual view of the Tungsten Fabric vRouter functional components.

The vRouter agent runs in the user space of the host operating system, while the transponder can be a kernel module that runs in user space when using DPDK, or in a programmable network interface card (also known as "smart NIC"). These options are described in more detail in future articles, where the more commonly used kernel module modes are explained. The agent maintains a session with the controller and sends the VRF, routing, and access control list (ACL) information it needs. The agent stores the information in its own database and uses that information to configure the transponder. The interface is connected to the VRF, and the forwarding information base (FIB) in each VRF is configured with forwarding entries. Each VRF has its own forwarding table and flow table, while the MPLS and VXLAN tables are global in vRouter. The forwarding table contains routes to the IP and MAC addresses of the destination, and the IP-to-MAC association is used to provide proxy ARP functionality. When the VM interface starts, vRouter selects the tag values in the MPLS table, and these values are valid only locally for that vRouter. Within a Tungsten Fabric domain, the VXLAN network identifier is global for all VRF of the same virtual network in different vRouters. Each virtual network has a default gateway address assigned to it, and each VM or container interface receives that address in the DHCP response it gets at initialization. When a workload sends a packet to an address outside its subnet, it ARP the MAC corresponding to the IP address of the gateway IP, and the vRouter responds with its own MAC address. Therefore, vRouters supports the fully distributed default gateway function of all virtual networks. Detailed vRouter packet processing logic the logical details of packets flowing out of VM and into VM are slightly different, as described in the following two figures and instructions. When a packet is sent from VM through a virtual interface, after the transponder receives the packet, it first checks whether there is an entry in the VRF flow table where the interface resides that matches the quintuple of the packet (including protocol, source and destination IP addresses, source and destination TCP or UDP).

If this is the first packet in the flow, there is no entry, and the forwarder sends the packet to the agent through the pkt0 interface. The agent determines the operation of the flow based on the VRF routing table and access control list, and updates the flow table with the result. The action can be DROP, FORWARD, NAT, or MIRROR. If the packet is to be forwarded, the forwarder checks whether the destination MAC address is its own MAC address, and if the VM sends the packet to the default gateway when the destination is outside the subnet of the VM. In this case, the next hop of the destination will be looked up in the IP forwarding table, otherwise the MAC address will be used for lookup. Although within the compute node, vRouter performs the IRB (Integrated routing and bridging) function of the physical router here. When a packet arrives from a physical network, vRouter first checks whether the packet has a supported encapsulation. If not, the packet is sent to the host operating system.

For UDP-based MPLS and GRE-based MPLS, the label identifies the VM interface directly, but the VXLAN needs to find the destination MAC address in the internal header in the VRF identified by the VLAN Network Identifier (VNI).

Once the interface is identified, if no policy flag is set for the interface (indicating that all protocols and all TCP / UDP ports are allowed), vRouter can forward the packet immediately. Otherwise, use the quintuple to find the flow in the flow table and use the same logic described for the outgoing packet. Packet flow between virtual machines on the same subnet

When an application in VM first sends a packet to another VM, the sequence of actions that occur is shown in the following figure. The starting point is that both VM are started and the controller has sent L2 (MAC) and L3 (IP) routes to both vRouter to enable communication between VM. The data has not been sent to another VM before sending the VM, so the target name was not previously resolved through the DNS. 1. VM1 needs to send a packet to VM2, so first look up its own DNS cache to get the IP address, but since this is the first packet, there is no entry.

2. VM1 sends a DNS request to the DNS server address provided in the DHCP response when its interface starts. 3. VRouter captures the DNS request and forwards it to the DNS server running in the Tungsten Fabric controller. 4. The DNS server in the controller responds with the IP address of the VM2. 5. VRouter sends the DNS response to VM1. 6. VM1 needs to form an Ethernet frame, so it needs the MAC address of the VM2, and it checks its own ARP cache, but there is no entry, because this is the first packet. 7. VM1 issues an ARP request. 8. VRouter captures the ARP request and looks for the MAC address of the IP-VM2 in its own forwarding table, and finds the association in the L2 / L3 route sent by the controller for VM2. 9. VRouter sends an ARP reply to VM1 using the MAC address of VM2. 10. A TCP timeout occurred in the network stack of VM1. 11. VM1's network stack retries sending packets, this time finding the MAC address of VM2 in the ARP cache, and can form an Ethernet frame and send it out. 12. VRouter looks up the MAC address of VM2 and finds the encapsulation route, and vRouter builds the external header and sends the resulting packet to S2. 13. The vRouter on S2 decapsulates the packet and looks for the MPLS tag to identify the virtual interface to which the original Ethernet frame is sent. The Ethernet frame is sent to the interface and received by VM2. Packet flow between virtual machines in different subnets

When packets are sent to destinations in different subnets, the order is the same, except that vRouter responds as the default gateway. VM1 sends a packet in an Ethernet frame containing the MAC address of the default gateway whose IP address is provided in the DHCP response provided by vRouter when VM1 starts.

When VM1 makes an ARP request to the gateway IP address, vRouter responds with its own MAC address. When VM1 uses this gateway MAC address to send an Ethernet frame, vRouter uses the destination IP address of the intra packet to look up the forwarding table in VRF for a route that will be connected to the host that is running the destination through an encapsulated tunnel.

After reading the above, do you have any further understanding of how to parse the vRouter architecture? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.