Analyze pvs pxe startup data packets using Wireshark Tracing

Analyze pvs pxe startup data packets using Wireshark Tracing

Citrix Provisioning Service uses PXE technology to start virtual machines for users.

First, the VM must be set to enable the NIC by default. The NIC sends a FIND frame through PXE bootROM in the network. The data frame contains its mac nic address. After the DHCP server receives the data frame, packets are returned to the NIC, including IP addresses, subnet masks, and gateways allocated by DHCP for the NIC. After the NIC receives the parameters assigned by the server, A connection request is sent to the server through TFTP to establish a connection with the server and start data communication.

After the client establishes communication with the TFTP server, it downloads and starts the startup image file from the 67 options configured on the DHCP server, connect to the CitrixProvisioning Service server through the startup image file to enable the VM.

The PXE Boot Process of PVS can be divided into four stages:

DHCP-start and download the boot file through PXE

Log on to the PVS Server

Streaming Pre-BniStack

Determining if BNIStack Driveris up

The test environment is:

PVS server: 10.1.1.1

Target device: 10.1.1.100

Phase 1: DHCP-start to download the boot file through PXE

Note:

1.1 DHCP discovery (DISCOVER)

The target device sends broadcasts on the physical subnet to find available servers. The network administrator can configure a local route to forward the DHCP packet to the DHCP server on another subnet. The target device generates a UDP packet whose destination address is 255.255.255 or a subnet broadcast address.

1.2 DHCP provision (OFFER)

When the DHCP server receives an IP lease request from the target device, it provides an IP lease. DHCP reserves an IP address for the target device, and then broadcasts a DHCPOFFER message to the target device through network unicast. The message contains the MAC address of the target device, the IP address provided by the server, the subnet mask, the lease period, and the IP address of the DHCP server that provides the IP.

The server checks the configuration based on the hardware address of the target device specified in the CHADDR field. Here, the server 10.1.1.1 specifies the IP address in the YIADDR field.

1.3 DHCP REQUEST)

When the target device PC receives an IP lease, it must inform all other DHCP servers that it has accepted one. Therefore, the target device sends a DHCPREQUEST message, which contains the IP address of the server that provides the lease. When other DHCP servers receive the message, they will revoke all leases that may have been provided to the target device. They then restore the address that was previously reserved for the target device to the available address pool so that they can assign the address to other computers. Any number of DHCP servers can respond to the same IP address lease request, but each target device Nic can only accept one lease.

1.4 DHCP confirmation (Acknowledge, ACK)

When the DHCP server receives a REQUEST message from the target device, it starts the final phase of the configuration process. This response phase includes sending a DHCPACK packet to the target device. This package contains all other configuration information that may be requested by the lease term and the target device. At this time, the TCP/IP configuration process is complete.

Note:

1.1 Address Resolution (ARP)

After the target device obtains the IP Address, it queries the MAC Address of the DHCP server through the Address Resolution Protocol to ensure smooth communication. This is because in the TCP/IP protocol, the devices in a LAN must know each other's MAC address, otherwise they cannot communicate directly. It shows the target device broadcasts a packet whose content is 10.1.1.1.

1.2 Address Resolution (ARP)

After receiving the packet, the DHCP server finds itself 10.1.1.1. Therefore, it fills in its MAC address in the response packet and sends it to the MAC address of the target device. The MAC address of 10.1.1.1 is 32: af: 85: d8: 16: be.

1.3 DHCP REQUEST)

The target device initiates a DHCP request again, and finds the IP address we entered, namely the IP address of the PVS server, based on the DHCP configuration options.

1.4 DHCP confirmation (Acknowledge, ACK)

DHCP returns a response packet.

1.5 Address Resolution (ARP)

The target device initiates address resolution to parse the MAC address of the TFTP server. Here, DHCP and TFTP servers are a server.

1.6 Address Resolution (ARP)

The PVS server returns its own MAC response packet. Here, DHCP and PVS servers are a server.

Note:

1.1 TFTP read requests (TFTP)

The target device sends a Read Request (RRQ) packet to the TFTP server, which is on the same role server as the PVS server, including the file name and transmission mode ., The packet content is the data file that reads the boot file as ARDBP32.bin on the TFTP server, followed by the transmission mode.

1.2 TFTP transmission (TFTP)

The TFTP server sends an ampersand packet to the target device. Currently, the Ampersand number is 1.

1.3 ACK response (TFTP)

The target host replies to all data packets with an ACK packet.

We can see the following data packets that have established a TFTP connection and started TFTP transmission.

 

Phase 2: log on to the PVS Server

Note:

2.1 transfer completed (TFTP)

Here you will see the mark of the end of the TFTP transfer. When there are 142 data packets, the last TFTP data packet is added to the data packet transmitted by TFTP, indicating that this is the last TFTP data packet.

2.2 Confirmation completed (TFTP)

In the 143 packet, the target device returns the ACK validation packet. You will know that the transfer has passed verification, and the last TFTP file sent by the server has been correctly verified. The entire TFTP transmission process is complete.

Note:

2.1 log on to PVS (UDP)

Once the boot file is downloaded, the target device continuously sends a series of data packets to the PVS server to attempt to request the source data and log on to the server based on the configuration information.

Note:

2.1 Address Resolution (ARP)

When the logon process is completed, the target device sends an ARP request to the IP address of the Streaming Server. Find the MAC address of the StreamingServer. Here, the StreamingServer and the PVS server are in the same server role.

2.2 Traffic Transmission (UDP)

After logging on to the server, the traffic between the server and the target device continues to use the previous source port and target port for data transmission.

 

Stage 3: Streaming Pre-BniStack (Pre-start)

Note:

3.1 processing traffic (UDP)

Here we continue to use the UNDI driver to process traffic. (Universal Network Driver Interface), and distribute one-to-one packages.

I am not clear about the above, so I will explain it according to my understanding. As you may know, when installing the operating system, the process is divided into two phases: Pre-Installation and formal installation.

In the pre-installation phase, the operating system has not been installed. We need to configure the operating system environment, for example, select the language, input method, version, and license of the operating system to be installed. Similarly, at this stage, PVS is not starting the operating system, but some preparations before preparing to start the operating system, using the UNDI driver, in the above metaphor, the interface for selecting input methods and versions for us during the installation phase is actually a Windows PE interface, it is a micro-interface that Microsoft has prepared for the genuine phase of domain installation. The UNDI driver works similar to Windows PE.

During this period, UNDI identifies the display window of the target device and loads the corresponding underlying driver.

In this step, we need to note that the problem is often related to our network card. during deployment, we will Unmount and close the big data packets of the network card, to avoid conflicts between the UNDI driver and the PVS server.

Stage 4: Determining if BNIStack Driver is up (officially started)

Note:

4.1 Formal transmission of the Operating System (UDP)

Once the UNDI driver to the BNIStack Driver (the main driver of the PVS target device), the target device starts to require more data. This transmission process will continue to the logon window. Just like installing the operating system as described above, the operating system is officially started here.

NOTE: Where is the IP address request packet of the target device displayed in, which is the Identifier from the UNDI driver to the BNIStack driver.

During this period, the problem is usually caused by either the relevant driver or the service and the underlying driver, such as XenTools and VMware Tools or Anti-Virus products, which may cause BNIStack conflicts.

In view of the implementation of Citrix Provisioning Service, the DHCP server needs to be configured, and the broadcast package initiated when the virtual machine starts will affect other regions. If other PCs in the production environment are accidentally set to enable the NIC, they will also enter the PVS environment. Therefore, Citrix PVS is implemented in an isolated environment.

The following figure shows the PVS startup flowchart on the network: