Networking Functions – CompTIA Network+ N10-009 – 1.2

If you were to somehow get inside of the networking cable and see what was going back and forth over that connection, you would see there was a lot of different activity going on across many, many different systems. All of these are designed to focus on specific functions. For example, we may need to get a piece of data from our network to a network that is on another part of the world. Or we might need to access a system that is already located somewhere else and provide technical support or be able to share a screen.

There’s also a need to have traffic management on our network so that certain applications have a higher priority than other applications. And lastly, we need to be sure that all of our systems are up and available. And it may take specialized protocols to make sure that that occurs every step along the way.

One way to speed up the process of getting access to data is through the use of a CDN. This is a Content Delivery Network, and as the name implies, it is designed to provide a way to get data very efficiently from one central point to an end user. These are often set up in geographical areas, so there might be a CDN server in North America, South America, Africa, Asia, other parts of the world. And you’re able to cache information at each one of these points.

It takes time to get data sent from one part of the world to the other. So if you can have all of your North America users access the North American CDN, it’s much faster than having them all go out to a centralized server that might be located in Europe. So if you’re watching this video on YouTube or on the Professor Messer website, you’re using a CDN right now. It’s a way for very small or very large sites to be able to distribute their data to users all over the world and make sure that that data is as accessible and efficient as possible.

For those of you that work outside of your corporate facility or perhaps do a lot of work from home, then you’re probably already familiar with a virtual private network, or a VPN. This allows you to connect to a remote network while sending all of this data encrypted across the network. It’s a very secure way to transfer data even across networks that would be inherently insecure, such as the public internet.

VPNs often use a device called a concentrator or a head-end device to be the central connection point for all of the users who are accessing that VPN. This is often a purpose-built appliance that’s designed to do high-speed encryption and decryption of network data in real time so that you can have many people being able to send secure data across the network, decrypt all of that data, send it to the inside of the network, and then reverse that process to get the response back to the user.

This can be a standalone device, but very commonly, we integrate this VPN concentrator function within a next-generation firewall itself. Because of the encryption and decryption process required to perform this VPN concentration, we usually will use a purpose-built appliance or a piece of hardware to be able to do this that provides very high throughput and can support hundreds or even thousands of users simultaneously.

But if you have a smaller network, you may not need a purpose-built appliance, and there are many VPN concentrators that will run as software on an existing operating system. You may have to install a specialized piece of software to be able to use a manufacturer’s VPN, although there is VPN software that does ship with Windows, MacOS, and Linux operating systems so that you can connect to many different kinds of VPNs using that generic software.

Not all applications are designed to run simultaneously on a network. And certainly, some applications may have a higher priority to your organization than other applications. For example, there might be a real-time audio or video stream that has a higher priority than a file transfer.

Because of these requirements, it’s very common for network administrators to provide some type of prioritization to these applications. This is often done through a quality of service, or QoS, configuration. You might also refer to this as traffic shaping or packet shaping. This allows the administrator to control what type of applications can flow through their network, usually based on bandwidth usage or particular data rates. This might allow your real-time applications to have full control or access to the network and put a lower priority on other applications that may simply be transferring files.

To control this quality of service, you may need to make configuration changes inside of a firewall, a router, or a switch. These devices might have a pre-built list of applications and might also allow you to add your own applications to the list. And at that point, you can decide what priority the applications might have relative to everything else that’s running on the network.

One of the challenges we often run into with technology is that it’s very good at performing a task. And often, it can perform these tasks over and over and over again without any type of human intervention. Unfortunately, this could also put a device into a state where it’s performing the task over and over and over again and never finds a way to complete or end that particular task.

For that reason, we’ve often built in different functions with our protocols so that we can recognize when a task may be going on too long and simply remove that task from the network. One common way to provide this identification is through the use of a time to live, or TTL. A time to live is effectively some type of timer. This timer may be based on the time of day, or it may be based on the number of iterations that a particular task completes. Once that timer hits zero, we can then have that task stop what it’s doing, or we can drop that task from the network.

There are many different cases for a time to live. One is a packet that is constantly looping between different routers. We might want to have that packet automatically dropped if that loop occurs a certain number of times.

Another good example of a time to live might be to clear a cache, where we might access a website, have that website stored in a cache, and then that cache is only available for the next 60 seconds or a number of minutes. When that timer hits zero, the cache is cleared. And the next time that website is accessed, you would have to go all the way out to the site to be able to bring that information back, at which point that is placed in the cache, and another timer starts.

Another example of using a time to live to stop traffic that is looping around your network is through the use of a routing loop. This is a really good example of where you might have Router A thinks the next hop is Router B. And Router B thinks the next hop is Router A. And what you’ll find is that the packet goes back and forth between those routers over and over and over again.

If you were going to perform a trace route, you would see this loop in the trace route itself, where the route goes to 10.1.10.1. Then it goes to 10.2.10.2, then back to 10.1.10.1, then back to 10.2.10.2 and so on. And this will continue all the way through until it reaches a time to live.

This is something that does occur occasionally because you might have many different routers. And those routers have many different routes. So it’s very easy to make one single IP address mistake in a static route and create this routing loop on your network.

For routing loops, we use a TTL field inside of the IP packet itself. This allows us to identify and stop a loop automatically if one occurs. In this example, we have Router 1, and Router 1’s next hop is Router 2. We’ve configured Router 2 with a next hop of Router 1, which means that this packet is going to go back and forth between these routers until something stops that loop from occurring.

Fortunately, we’ve built functions within IP, or the Internet Protocol, to look for this loop to occur and stop it if it finds that it’s occurring over and over again. In IP, the time to live is referring to the number of hops that a packet will go through a router. Each time a router processes a packet, it decreases the time to live by one. And when that value gets down to zero, it discards the packet, effectively ending the loop.

The default time to live for MacOS and Linux is usually 64 hops, and the default time to live for Windows is 128 hops. Since the router is decreasing the time to live by one each time the packet goes through, it’s watching that number decrease every time it goes through a looped connection. And when the time to live gets to zero, the router drops that particular packet.

If we were to look at the frame of IP, you could see there’s version numbers, header length, type of service, total length, and other fields within the IPv4 header. The one we’re interested in is the one called Time to Live. And that’s the one that the router will use to determine if it’s gotten down to zero and if it should discard this packet from the network.

Here’s a very simple protocol decode of an IP header. You can see this is frame 1. We have the Ethernet information with the Mac addresses for the source Mac address and the destination Mac address. And this is an IP version four header. You can see the source IP address and the destination IP address in the header itself.

If we were to break this header open and look at those individual fields that we mentioned from that previous slide, you can see there is a Differentiated Services field, a Total Length field, an Identification field, and right here is a Time to Live field. The time to live for this particular packet is 58 hops. So this packet would need to go through 58 more routers until this got down to zero, at which point it would be removed from the network.

In most cases, our total number of hops between us and the destination that we’re trying to visit somewhere on the internet is usually around 12 to 16 hops, sometimes more and sometimes less. But that’s a relatively small number when you consider that the total default time to live on MacOS or Linux is 64 hops, and the default on Windows is 128 hops. That gives us plenty of room to be able to get data from one side of the internet to the other and not have that information accidentally dropped by a router.

Depending on the protocol you’re using, time to live may have a different definition. With routers, time to live is associated with the number of hops. But in DNS, or the Domain Name System, the time to live is associated with the total number of seconds.

Let’s take a scenario where we’re performing a DNS lookup. And you can do this yourself by using nslookup or dig, and you can resolve or look for the device www.professormesser.com. And your DNS server will return some type of IP address associated with the Professor Messer web server.

Inside of that DNS resolution is information about time to live. This tells us how long we should cache this local entry on our system. So we want to cache it for a certain number of seconds. How many seconds? Well, we’re going to cache it for the time to live seconds. The time to live is included with the configuration on a DNS server, and this is the output from the command dig www.professormesser.com.

You can see that the Answer Section, where the DNS server is providing us information, says that the server www.professormesser.com has a time to live of 300. This is an internet address. The A is for address. And then we have three different IP addresses associated with my web server.

This 300 value is the one telling our local machine, keep this IP address in your cache for 300 seconds. If you do the math, that is five minutes. Once that five minutes has elapsed, our local cache removes that particular resolution. And if you want to know the IP address for that same server, you would need to perform another DNS query to update your cache for another five minutes.

This allows me, as the administrator of my web server, to be able to change the IP address in my DNS configuration. And I can feel relatively secure that most people will have an updated version of that IP address within five minutes. We use time to live for many other protocols as well, so make sure you look at the documentation for that protocol to understand exactly how we’re measuring time to live for that particular protocol.