When a device on a TCP/IP network starts up and is not configured for a static IP address, it needs to receive an IP address before it can communicate with other devices on the network. A standard computer with a hard disk can be enabled for static configuration but a diskless device that does not have any storage, only has an option to acquire an IP address from the network. This process of getting a new machine up and running is commonly referred to as bootstrapping. To provide this functionality, the TCP/IP Bootstrap Protocol (BOOTP) was created. 

The Bootstrap Protocol, or BOOTP, is a network protocol used by a network client to obtain an IP address from a configuration server. In order to get an IP address the network clients contact other devices on the network. Initially (ages ago) a boot floppy disk had to be inserted to establish the initial network connection, but later on Network Interface card manufacturers embedded the protocol in the ROM of the interface card as well as on motherboards that have onboard network adapters, thereby avoiding the need for floppy disks and allowing for direct network booting.

During the bootstrap process when a computer is starting up, the BOOTP protocol is used. A BOOTP server assigns an IP address to each client from a pool of addresses and based on the configuration of the server. BOOTP generally uses the User Datagram Protocol (UDP) as the transport protocol. Earlier, BOOTP has also been used for diskless workstations to obtain the network location of their boot image in addition to an IP address using protocols like PXE, and also by enterprises to roll out pre-configured client installations to newly installed PCs.

Although BOOTP provides a very important function, it is not used frequently today and has been superseded by DHCP (Dynamic Host Configuration Protocol) which is a more advanced protocol for the same purpose. Most DHCP servers also offer BOOTP support and are the most prevalent method used today to assign IP addresses to diskless workstations and clients that require IP addresses.

Booting your host from the network without the need to rely on the local operating system or hard disks is a technology that is not used very often in the corporate environment today with some people never having heard that such a thing is possible. With the way things are moving today with virtual machines, virtual storage, dynamic infrastructure, I feel that the trend would be reversed with few folks storing data on local hard drives and more moving to virtual environments and booting from remote storage at least as far as the backend infrastructure is concerned because of the advantages of flexibility, backup, deployment, etc.

Preboot eXecution Environment (PXE) or ‘pixie’ as it is popularly called is one of the many technologies that helps in booting hosts using a Network Interface with the help of images stored remotely. PXE consists of a suite of protocols like IP, UDP, DHCP, TFTP and concepts like Globally Unique Identifier (GUID) and Universal Network Device Interface (UNDI). The firmware of the PXE client is extended with the help of API’s. The PXE client refers to any hardware host device (server, notebook, PC) that is included with the PXE boot code.

PXE is an open industry standard developed by a number of software and hardware vendors. It was initially designed by Intel, with input from several other vendors including 3Com, HP, Dell, Compaq, and Phoenix Technologies. PXE works with a USB adapters and network interface card (NIC) in the PC, making the PC boot over the network.

Hosts that support booting from PXE, have a firmware that tries to locate a PXE redirection service (Proxy DHCP) to get a list of PXE boot servers that are available. After going through the reply, the firmware software will request an appropriate boot server for the file path of the network bootstrap program (NBP) like xxx and download it on the local Random Access Memory (RAM) using TFTP generally, verify and execute it.

If a common NBP is used by all PXE clients it could be specified by BOOTP thereby not needing a proxy DHCP, but the TFTP server is still required.

PXE Protocol

The PXE protocol is a combination of modified versions of DHCP and TFTP. DHCP is used to locate the appropriate boot servers and TFTP is used to download the bootstrap program and other files to the PXE client. Initiation of a PXE bootstrap session is done by the PXE firmware broadcasting a DHCPDISCOVER packet with PXE options (extended DHCPDISCOVER) to port 67 UDP (DHCP Server port). The PXE options identify the firmware of the sending host as capable of PXE, but this message is ignored by standard DHCP servers. If the PXE client receives DHCPOFFERS from such servers, it may request for one of the offered configurations.

PROXY DHCP

When a PXE redirection service (Proxy DHCP) receives an extended DHCPDISCOVER, it replies by sending back a broadcast called an extended DHCPOFFER (DHCPOFFER with extended PXE options) to port 68/UDP (DHCP client port). The reason this packet is broadcasts back because the IP address of the PXE client is not included in DHCPDISCOVER message. The client is mainly identified by its GUID/UUID

Extended DHCPOFFER contains mainly:

 - PXE Discovery Control field to decide whether Multicasting, Broadcasting, or Unicasting is to be used for contacting PXE boot servers
- List of IP addresses of each available PXE Boot Server Type
- PXE Boot Menu with each entry representing a PXE Boot Server Type
- PXE Boot Prompt telling the user to press <F8> to see the boot menu
- Timeout to launch the first boot menu entry if it expires.

The Proxy DHCP service may also be run on the same host as the standard DHCP service. Since both services cannot share port 67/UDP, the Proxy DHCP runs on port 4011/UDP and expects the extended DHCPDISCOVER packets from PXE Clients to be DHCPREQUESTs. The standard DHCP service has to send a special combination of PXE options in its DHCPOFFER, so the PXE client knows to look for a Proxy DHCP on the same host, port 4011/UDP.

Boot Server

To contact any PXE Boot Server the firmware must have an IP address and has to consider all information from exactly one extended DHCPOFFER. After choosing an appropriate PXE Boot Server Type the firmware multicasts or unicasts a DHCPREQUEST packet extended with PXE-specific options (extended DHCPREQUEST) to port 4011/UDP or broadcasts it to port 67/UDP. This packet mainly contains the PXE Boot Server Type and the PXE Boot Layer, allowing to run many boot server types with one boot server daemon (or ‘program’). The extended DHCPREQUEST may also be a DHCPINFORM.

If a PXE Boot Server receives an extended DHCPREQUEST as described above and if the boot server is configured for the requested PXE Boot Server Type and client architecture, it must respond by sending back an extended DHCPACK to the source port of the extended DHCPREQUEST.

Extended DHCPACK contains mainly:
- The complete file path to download the NBP via TFTP.
- PXE Boot Server Type and PXE Boot Layer the boot server answered to
- Multicast TFTP configuration, if MTFTP as described in the PXE specification should be used

Additionally the PXE firmware extension was designed as an Option ROM for the IA-32 BIOS so you can get a personal computer (PC) PXE-capable by installing a NIC that provides a PXE Option ROM as can be seen in the figure below

The PXE Client/Server Protocol was designed so:

- It can be used in the same network as an existing DHCP environment without interference
- It can be integrated completely into standard DHCP services

I use the NETSTAT command frequently during my consulting assignments, however apart from the common options; I never delved into using all options of the command. My curiosity got the better of me and I went on to explore all the options of the NETSTAT command, so here goes

NETSTAT (network statistics) is a command-line utility that displays incoming & outgoing network connections, routing tables and various network interface statistics. The command has various parameters that can be used and is available on Unix, Linux and Windows based operating systems

Parameters of the netsat command on Windows based systems. Linux, Unix, BSD based systems have most of the parameters common with a few exceptions

A quick output of the help of the netstat command by appending /? gives us the following parameter options

A detailed explanation of each parameter with examples follows

-a   Displays all connections and listening ports

Running the netstat command with the -a parameter displays the of active connections as is displayed in the output below

C:\>netstat

Active Connections

  Proto  Local Address          Foreign Address              State
  TCP    host540:19208          microsoft.com:http    CLOSE_WAIT
  TCP    host540:19473          yahoo.com:http             ESTABLISHED

Starting with the protocol as the first column which could be either TCP/UDP based. The “host540:19208″ in the second column is a combination of the host name of the computer that the command is being run on which in this case is host540 and the local port number which is 19208. For well known services the protocol would be appended, for example host540:ntp but for services that are not well known the local port number would be mentioned

The foreign address is the website and the service that the connection was opened to which is microsoft.com:http in this case with port 80 (http) or web traffic and the connection state is CLOSE_WAIT

If the port is not yet established, the port number is shown as a * which would normally be seen in the output as “*:*”

-b   Displays the executable involved in creating each connection or listening port. In some cases well-known executables host multiple independent components, and in these cases the sequence of components involved in creating the connection or listening port is displayed.

C:\>netstat -b

Active Connections

Proto  Local Address          Foreign Address               State                        PID
  TCP    host540:19208       microsoft.com:http   CLOSE_WAIT       1148
  [iexplore.exe]

  TCP    host540:19473       yahoo.com:http             ESTABLISHED   7848
  [firefox.exe]

 

Additionally the process id of the process is also available. In this case the executable name is in [] at the bottom, on top is the component it called, and so forth until TCP/IP was reached. Note that this option can be time-consuming and will fail unless you have sufficient permissions

-e   Displays Ethernet statistics. This may be combined with the -s option
 

C:\>netstat -e
Interface Statistics

                                                    Received            Sent

Bytes                                              41185465        10381455
Unicast packets                      248414             246100
Non-unicast packets           48535               303
Discards                                        0                          0
Errors                                             0                          1
Unknown protocols             0

The number of packets, bytes, errors and other information received and sent is displayed. This may be useful when tracking network usage and can be combined with the -s option.  For example one may only want to see received packets of type http, which can be done using the -e and -s options

-n   Displays addresses and port numbers in numerical form

This is similar to the standard netstat option without any parameters, however dns queries are done to convert all addresses and port numbers into numerical form. For example, in the output microsoft.com would be listed as its corresponding ip address and http would be displayed as 80
 

-o   Displays the owning process ID associated with each connection

The process ID which owns the connection can be viewed and then other utilities like Sysinternals Process Explorer can be used to drill down and get further information. The process id is also displayed other options like -b as was mentioned above

-p proto   Shows connections for the protocol specified by proto; proto may be any of: TCP, UDP, TCPv6, or UDPv6.  If used with the -s option to display per-protocol statistics, proto may be any of IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6

This is one of the most useful options to view specific connections opened by the protocol specified. For example, if one wants to view the opened UDP connections, the command netstat -p proto UDP could be used

-r   Displays the routing table

Here all interfaces present in the system with their netmask, gateway, metric and name of the ethernet adapter is displayed. It gives you  a quick overview of ip addresses assigned and interface name, etc. Active as well as persistent routes are displayed

-s   Displays per-protocol statistics.  By default, statistics are shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6; the -p option may be used to specify a subset of the default

Another useful option to view statistics per protocol. For example, to view only UDP statistics, the following command could be used

C:\>netstat -s -p UDP

UDP Statistics for IPv4

  Datagrams Received    = 328852
  No Ports              = 16880
  Receive Errors        = 79
  Datagrams Sent        = 197475

Active Connections

  Proto  Local Address          Foreign Address        State

  The output above does not have any active UDP connections

-v            When used in conjunction with -b, will display sequence of components involved in creating the connection or listening port for all executables.

After we have used the -b option to drill down and find out that a component [iexplore.exe] as well as other components were involved in creating the connection, we can further use the -v option to order the components involved in creating the connection. This is useful when understanding the sequencing of connection requests by an arbitrary application. It gives you an internal listing of .dll’s being called in real time

interval      Redisplays selected statistics, pausing interval seconds between each display.  Press CTRL+C to stop redisplaying statistics.  If omitted, netstat will print the current configuration information once

This is a good way to auto refresh the screen with any output desired. I might want to see the output of the netstat -n every 5 seconds. I would then use the netstat -n 5 command

To summarize, netstat is an external tool that is built into Windows, Unix, Linux, etc and displays a lot of useful information