Kris Plunkett

Protocol of the Week: ARP (Address Resolution Protocol)

Kris Plunkett — Sun, 05 Oct 2008 22:48:11 GMT

The Address Resolution Protocol lives in some of the deeper and darker realms of the networking stack and is never of any concern to the every day user. Nonetheless, it provides a critical service, without which IP-based networking could not function. In OSI terms, ARP is a "connecting protocol" that lies between the Networking layer and the Data Link protocol known as Ethernet, and since we have discussed neither IP's network protocol (namely IP itself) nor Ethernet, I'll briefly explain what we need to know of each to understand the role of ARP.

All that we need to know about these two protocols that ARP glues together is how their addressing scheme works. IP is responsible for assigning a unique (32-bit) address (looks like this: 24.120.50.23 and is simply called an "IP address") to each device on a network. Ethernet has a similar addressing scheme, with three notable exceptions: Addresses are 48-bit (looks like this: 00:01:D7:3E:E2:84 and is called a Medium Access Control (MAC) address), are assigned to each Network Interface Card (NIC) rather than to the device itself (one device can have multiple NICs), and only need to be unique among the NICs that are directly connected to one another. This latter difference is because the Data Link layer can't see past the devices that are directly connected to each other, while IP must consider networks of arbitrary size, where not all devices in the network are necessarily directly attached to one another.

So why do we care about all of these addresses? Well it just so happens that they are the things ARP glues together. Remember, each layer on the networking stack knows nothing about any of the other layers (see the first bit on the OSI model if this seems foreign to you). So when IP has data to send, it will push it down the stack to Ethernet and give it the only piece of information it knows about the destination: its IP address. Therefore IP says "Ethernet, please send this data to IP address 24.120.50.23." Ethernet, naturally, has no clue where 24.120.50.23 is. The only language it knows is that of MAC addresses. Thus (get out your spoon for the alphabet soup) Ethernet must find the MAC address of the NIC that is attached to the device with the given IP address. This is where ARP comes in. Ethernet will broadcast an "ARP request" to all devices that it is attached to. This request says "Hello everyone, please tell me which of you is attached to device with IP 24.120.50.23." If a NIC on a connected device picks up this plea and confirms that the device it is attached to does indeed have this IP address, it will reply, "Good sir! I do own this IP address, so please send your data to me. My MAC address is 00:01:D7:3E:E2:84." The original sender now knows where the data it got from the IP layer is supposed to go, and communication can proceed. This information is then stored in a cache so that future communication with that IP address can happen without needing to send another ARP request.

That's all there is to it, and if you think this sounds very simple, you're right. ARP was intentionally kept small and simple to minimize overhead introduced in the lower layers. Now, there are alternate forms of ARP, such as RARP (Reverse ARP) and GARP (Gratuitous ARP), that do complicate things a bit, but I will leave learning about them as exercises for the reader.

Now, finally coming to BIG-IP and its dealings with ARP, it has come to my attention that BIG-IP does some tricky stuff with ARP to enable a feature known as "VLAN groups." However, rather than doubling the size of this post, I will wait until next week, and thus postpone our next protocol, to divulge the juicy details on this nifty feature. Until then!

(RFC for ARP) - The official IETF document for the ARP protocol. I will link to each protocol's RFC as I discuss them.

Protocol of the Week

Kris Plunkett — Sat, 27 Sep 2008 02:04:00 GMT

My original motivation for joining the DevCentral blogging community was an idea for a weekly blog post titled "Protocol of the Week". The idea spawned from the desire to become acquainted with the protocols that govern modern day networking, from the small Local Area Network to the Internet itself. A significant part of my work rests on these protocols and their impact on inter-computer communication, so the benefit to me for learning all I can about them is clear. However, I knew that simply reading about them in books, blog posts, articles, and the RFCs (Request for Comment...the official protocol documentation) would lead to a lonely and dreary road of learning. The obvious solution: Reach out to and engage with the Web 2.0 community, and this is the perfect place for it.

So each week I'm going to pick a protocol and write a short, high level piece on that protocol's origins, purpose, evolution, and (since I do work at F5 after all) how F5's products, specifically BIG-IP, handle/manipulate that protocol.

Now my call to the readers:

At the end of each post, I will say what protocol I will be learning about next so that I may invite readers to suggest resources for research. If you know some great article about the upcoming protocol, please, please share it with me via e-mail or with everyone via a blog comment.
I am no expert on networking protocols. As I said, this is a learning endeavor on my part, and though I will be careful with my research, inevitably I will say something not quite accurate or flat out wrong. Thus I ask that you be (positively) critical of my work and let me know if you spot mistakes. I would hate to misguide my learning and that of others.
If you have any feedback on the way I present this blog or its content, or you are dying to learn about some protocol, definitely let me know.

Finally, I'd like to finish by briefly answering the question, "What exactly is (and isn't) a protocol?". When someone goes to the bank to withdraw money, for example, they approach a teller and make their request. The teller then asks for the account number and a form of identification. They then pull up the account on their computer and verify that the identification matches the owner of the account. The teller also needs to make sure that there is enough money left in the account to satisfy the request. Assuming this is so, the teller makes the transaction and pulls out the appropriate amount of cash. Finally, the teller counts the cash in front of the patron and hands them a receipt with their money. People may not know this, but in doing this whole process, they are partaking in a protocol. A protocol is a step-by-step outline on how to accomplish a particular task. In this case the protocol's goal was a cash withdrawal from a bank account. This particular example could get more complicated when you include all that happens behind the scenes in the computer software that is run to perform the actual transaction.

The Internet operates on a very large set of protocols, where each protocol defines how a particular networking task is accomplished. IP (Internet Protocol) defines how nodes on the Internet are uniquely addressed and how data is routable between these nodes. TCP (Transmission Control Protocol) works on top of IP and defines a method for providing a reliable data stream between two nodes on the Internet. HTTP (HyperText Transfer Protocol) works on top of TCP and defines how web pages and other data is transferred. As noted, protocols sometimes use one another and therefore form a stack. The most common categorization of this stack is called the OSI model. Together these protocols provide a standard by which varyin g software and hardware packages can communicate with each other over a network. Not all sets of protocols, however, are compatible. The ones listed above, and any those that are compatible with them, are called "IP-based" protocols and are the most popular today.

My last point is that protocols, though they define steps for accomplishing certain networking tasks, do NOT define exactly how those tasks should be done. How software and hardware execute these protocols is called the protocol's implementation, and this varies from system to system. Linux and Windows, though they both support IP-based networking and are able to communicate with one another, have different code and varying parameters that get the job done. The standards only dictate enough information to guarantee interoperability between varying implementations.

That's it, and I hope you stay tuned next Friday for our first protocol: ARP (Address Resolution Protocol), which is a cornerstone of IP-based networking.

Have a great weekend!

Hello F5, Hello World

Kris Plunkett — Thu, 18 Sep 2008 23:40:31 GMT

When I was 12 years old, with school out and most of my local friends out of town, I spent the better part of an entire summer cooped up at home with not much to do. This was years before I would be cruising the streets of Olympia with my slicked out '95 Dodge Neon. So what did I do? I discovered the inner geek in me through a 1000+ page QBasic book that I had borrowed from a friend's mom's dusty bookshelf. I had been playing computer games for almost three years on our family's Gateway (Pentium 120Mhz, 16MB RAM, 1.2GB HDD...what more could you need?), everything from Doom, Dune 2, to SimCity, but it wasn't until I opened that book and saw computer code for the first time that I became fascinated with the inner workings of these, by this time, ubiquitous machines.

Ten years later I find myself deep in my second year as an intern here at F5 Networks, one of the greatest software engineering gigs this side of the Mississippi. Where most of the big software names hire college interns for a summer only, taking them in June and spitting them back out in September, F5 hires most interns with the intention of keeping them around until they're ripe for the picking; that is, until they graduate and are able to work full-time. Doesn't it make sense though? First, three months is hardly enough time for anyone, even a seasoned professional, to become familiar with a software company's engineering practices. Second, once you've got an intern up to speed and (at least somewhat) productive, why would you throw that away? So in December, when I graduate from the University of Washington with my B.S. in Computer Engineering, I hope to get the chance to reward the best ADN player in today's market with yet another dedicated and driven engineer, while rewarding myself with a more permanent position at the only place where the beer flows freely, every Beer Friday that is.

The greatest part about an internship like this, though, is the opportunity to learn from and get connected with a professional community of computer engineers. Needless to say, I was thrilled when I found out that I could have my very own blog here on DevCentral where I can reach out to F5 and its beneficiaries, the many computing professionals who visit DevCentral daily, with my thoughts. So Hello World, Hello F5, welcome and stay tuned, 'cause I have much more to come.