Network Layer Supporting Applications

Having covered addressing and forwarding mechanics, let’s turn to common tools that assist Network layer function, care, and feeding.

DHCP

Every device on the network needs an IP address, but manually configuring an address for each and every device presents logistical challenges as the network grows. Certain impor- tant devices—routers, switches, and servers, for example—should be configured manually, with static IP addresses that do not ever change. This ensures that these devices are always reachable at the expected address. Other devices, typically end-user devices, might have more transient connections and as such not need permanent, manually assigned addresses. For these devices, Dynamic Host Configuration Protocol (DHCP) can be used to allow the device to temporarily borrow, or lease, an IP address. DHCP also allows an adminis- trator to configure other information including the default gateway address, DNS server addresses (more on that in a bit), and domain names.

51

Network Layer Supporting Applications

When DHCP is used, a DHCP server maintains a list of various pools of IP addresses that can be used for each subnet. Devices configured to use DHCP issue a broadcast DHCP Discover message on their subnet. A DHCP server earmarks an IP address in its pool and responds with a broadcast DHCP Offer message directed to the client, which includes a proposed IP address, subnet mask, lease duration, and the IP of the DHCP server. The client then responds to the server via broadcast with a DHCP Request, indicating that the client has accepted the offer. A client might receive offers from multiple DHCP serv- ers, but will respond with a request to only one. Any other DHCP servers that had sent offers will see the broadcast request and return their offered address to their pools. The DHCP server then issues a DHCP Acknowledgement to the client, confirming the reser- vation. The acknowledgment includes any additional configuration parameters that might be specified.

DNS

While some of us are cursed with being able to recall IP addresses they used 20 years ago (but not what their wife asked them to do this morning), this is not a fair expectation of your end users.

Domain Name Service (DNS) is a centralized mechanism for mapping user-friendly names to IP addresses. When a host is configured to use a DNS server, it will send DNS requests to the specified server, asking for translation. The DNS server will then reply with the IP address matching the friendly name. Multiple DNS servers can be specified, so if the client cannot reach the first server listed, it will try the next server in the list until a response is received.

ARP

Remember that each IP packet must be encapsulated in a Layer 2 frame before it can be sent to the next hop. The Address Resolution Protocol (ARP) is used to determine the des- tination media access control (MAC) address for that frame.

After a client has resolved a name to an IP address, it determines whether that IP address is on its local subnet. If it is, it issues an ARP broadcast on the segment asking for the holder of that IP address to respond with its MAC address. If the destination host is not on the local subnet, the client issues an ARP request for the default gateway IP address. ARP requests are not issued for every bit of communication. As a client makes requests, the replies are remembered in the ARP cache. Each time a client needs to encapsu- late a packet in a frame, it checks the ARP cache to see if it has a MAC match for the destination IP.

52 CHAPTER 5 Layer 3

Ping

The ping command allows you to test basic IP connectivity between hosts. It uses the Internet Control Message Protocol (ICMP) to send an ICMP echo request to the destina- tion host. The host is then expected to reply with an ICMP echo reply. When successful, you have confirmed that the network can deliver a packet from the source to the destina- tion and back again.

Ping was named after the sound sonar makes, as the echo request and echo reply function is similar to the process of active sonar.

Summary

In this chapter, we reviewed the functions of Layer 3, the Network layer. We described the Network layer functions, Network layer addressing, the routing and forwarding pro- cesses, and some utilities that function at and support this layer. In the next chapter, we break away from networking theory to investigate a relatively new infrastructure consump- tion model.

Chapter 6

Converged Infrastructure

Key Concepts

Q Nutanix Virtual Computing Platform

Introduction

Let’s take a quick detour before we get into virtual networking. Think of it as a quick breather, an opportunity to come up for air after the networking concepts we just threw at you. So far, we’ve gone over a good bit of networking fundamentals, at some length. It’s easy to get lost here, to get so caught up in the particulars of interconnecting devices to the point where you forget that those devices are the reason for the network to be there in the first place. Something similar often happens with server people, storage people, desktop people—everyone with a specialization. When these technologies are treated as discrete islands, staffed and procured separately, silos develop and inefficiencies abound.

Converged infrastructure is one approach to solving this problem. A converged infrastruc-

ture solution packages or otherwise integrates compute, networking, and storage technolo- gies into a solution that is (ideally) easier to consume, deploy, and manage. In this chapter, we go over the basic concepts and provide a few examples of converged solutions that we often run into.

54 CHAPTER 6 Converged Infrastructure

Concepts

To begin, let’s look at a typical IT shop that has the traditional set of datacenter compo- nents: rack-mount servers tethered to network switches and a storage array. The personnel that manage and maintain this equipment are grouped into teams—the storage team, net- work team, and server team—and together they make up the Infrastructure Team.

When a new server needs to be added to the datacenter, quite a bit of activity needs to take place. Barring any political or procurement shenanigans, the three teams must work in harmony in order to get the new server into a production state.

The Server Team has to “rack and stack” the server. This is the process of unloading the server into the datacenter, removing it from the packaging, and then finding a rack loca- tion and mounting it to the rack. They can also be tasked with assigning the server name, applying an IP address, and working to complete any other personality attributes of the server.

The Network Team might cable the server into the nearby switch and ask the Server Team exactly how to configure the port for this server. They often ask questions about the VLAN configuration, number of cables needed, and the Maximum Transition Unit (MTU) settings to ensure that the port will correctly talk back and forth with the server. They might also want to investigate the Network Interface Cards (NICs) to verify what MAC addresses will be discovered by the switch for security purposes.

And finally, the Storage Team might need to examine the Host Bus Adapters (HBAs) to identify the World Wide Port Names (WWPNs) for building a Storage Area Network (SAN) and corresponding zoning configuration. They would then be able to build storage constructs, such as Logical Unit Numbers (LUNs) or Volumes, and present them to the server.

Sounds exhausting, doesn’t it? Lots of hands are involved, and there are many opportuni- ties for errors even if everything is communicating perfectly. And while no single set of tasks takes too terribly long, the logistics of coordinating the work and conforming to change control policies can compound delays, stretching delivery time to crazy lengths. We’ve worked with companies that consider a 90-day turnaround from delivery to produc- tion to be a job well done.