The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including N10-008: CompTIA Network+ Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.

Module 4 - Understanding Network Services

1. 4.0 Understanding Network Services

Welcome to Module Four. And this is a really fun module because, now that we understand some of the network's pieces and parts, we can start overlaying that network with some really cool services. For example, in this module, we're going to be talking about things like the Network Time Protocol, which allows us to synchronise the watches, if you will, of our network devices. We'll see how the DynamicHost configuration protocol works. It can save us the tedious work of manually assigning IP address information to all of our different clients. We'll check out software-defined networking, which is changing dramatically what it means to be a network professional. And we're going to begin our journey through network services in our next video, which is all about VPNs—virtual private Private Networks.They allow us to communicate securely over the Internet. Let's check those out in our next video.

2. 4.1 Virtual Private Networks (VPNs)

For the first few years that I was involved in networking, if you wanted to interconnect two different sites and you wanted to do it at a fairly reasonable speed—something faster than a dollar modem—then you would have to get some sort of leased line or frame relay or an ATM connection. It was fairly expensive. You had to have this circuit that your service provider gave you. But things are much easier today. Today we can use the Internet to interconnect different sites. After all, we oftentimes have very fast Internet speeds. A challenge with the Internet, though, is that it's not secure. What if somebody were to eavesdrop on our data? We don't want them to see what we're sending across the Internet. For example, we don't want our passwords or our banking information compromised. How can we securely send data across the untrusted Internet? One option is to use a virtual private network, or VPN. One option for a VPN is a remote access VPN. That's what we see here on screen. We've got a client, and they're away from the headquarters that's on the left. Maybe they're one of those road warriors that travel around to different sites, and this person wants to communicate back with the headquarters. Well, that's what they can do with a remote access VPN. As long as they have access to an Internet connection, they can tunnel over the Internet back to the main site. And one way they can do that is if their company has a web portal that allows someone to set up a secure connection. An example of that is the Client List Cisco SSL VPN option. Or we might have a VPN software installed on that client. So it's going to set up and maintain and tear down and do all the encryption and decryption for that VPN. but that's an option for mobile devices out there. They can just connect to the Internet, and either using some sort of web portal or using software they install, they can get connectivity back to their main site. And something to keep in mind is that the client is running the VPN software. Its network interface card virtually hosts the VPN connection. Does that mean that every packet has to go across the VPN? even if that client is printing locally? Maybe they're sending a print job to a local printer. Does that have to go across the VPN? Maybe not. There's an option called split tunnel, and oftentimes you can set your remote access VPN software to operate in split tunnel mode, which will let local traffic stay local and not be routed over the VPN. A split tunnel differs from a full tunnel in that all traffic is routed through the VPN. Another option that's a bit more scalable is if we want to interconnect two sites. Maybe we've got a remote office location and a headquarters office location. rather than having client software installed on the client or relying on a web portal, which may have limitations. By the way, we could just have a router or a VPN concentrator at each of our sites. Here we've got a couple of routers, and we could let the routers do the heavy lifting of the encryption and the decryption, so everything is completely transparent to the end user. They don't have to fire up a VPN client or give a password. They're just on the network. This is a site-to-site VPN, and it can use common broadband technologies. Maybe you've got gigafiber at each of these sites. You could set up a secure tunnel over that gigabit fiber, and again, it is completely transparent to your end user. And here we're picturing routers. But if the headquarters has multiple sites and it wants to set up a secure connection to all of those different sites, instead of having a router do all of the encryption and decryption, which could start to put a processor burden on the router, some locations might have what's called a VPN concentrator, a device that's dedicated to being an end point on a VPN. And now that we've talked about a couple of types of VPNs—remote access and site-to-site—let's see how that secure tunnel gets set up across the Internet. There are a couple of different VPN protocols I'd like you to know about. The first one is generic routing encapsulation, abbreviated GRE. We can set up this GRE tunnel between routers R-1 and R two.There's a big downside to a GRE tunnel, though. It does not provide security at all. It doesn't do encryption; it doesn't do authentication. It just gives you a virtual path between these two different sites. The good thing about GRE is that it is very flexible. It can encapsulate nearly any type of data that you can send out of a router interface. and that would include things like IP, unicast, multicast broadcast, even protocols that are not even IP. You could send them over a GRE tunnel. So it's very flexible. But we've got that issue of it not being secure. Well, there's another protocol that is secure, and it's called Ipsecurity, or IPsec for short. And this is going to provide a lot of security. It can do things like ensure confidentiality by encrypting our data, so if somebody intercepts it, they're not going to be able to make any sense of it because it's all scrambled up. We can make sure that the data is not modified in transit. We can authenticate users to make sure they are who they claim to be. If somebody captures packets that are part of avalid session, they're not going to be able tocome back later and replay those packets and geta valid session of their own. because IPsec has anti-replay protection. Imagine that we're assigning serial numbers to each packet. Imagine if somebody captured those packets and tried to play them back later while those numbers were out of order with what was currently going across the wire. That's how we get the anti-replay protection. However, IPsec only has the ability to encapsulate unicast IP packets. It's not as flexible as Gre could be. Unicast broadcast multicast IPsec is somewhat limited. It only does a unicast. Is that a problem? It could be because our routing protocols oftentimes, as just one example, need to use multicast to set up neighbourhoods between different routers. So this could be an issue for us, and we'll talk in a moment about how we can address that potential issue. I do want you to know that there are two modes of operation. There are two modes: transport mode and tunnel mode. And here it's sort of a tradeoff between being a little extra secure or saving a little extra bandwidth. With transport mode, the original packet header that has the source and the destination, IP address information, and quality of service information, all that stuff, is kept intact. It's not put inside of this encrypted packet in tunnel mode; it's in title mode. We're encrypting the entire packet. So with transport mode, we're not protecting that original header, but we're saving a bit of bandwidth because we don't have to put on an extra header while we're encrypting the original header. tunnel mode a little bit more secure. But because we're adding an extra header, it's going to take up a bit more bandwidth. Now, let's talk a bit more about authentication and encryption. Encryption is what gives us confidentiality. and we've got a couple of approaches here. We could use "Ah, that's the authentication header, and it does a really good job of authenticating an IP packet." And by that, I mean it's going to authenticate the entire IP packet, including that IP packet's header. However, it does not do encryption. The other option is Encapsulating Security Payload, or ESP. It can also do authentication, but not as well as Ah. It can authenticate an IP packet but not its IP header. But on the positive side, it can perform encryption. So it almost seems like we have a paradox. Do I want better authentication with Ah at the expense of encryption, or do I want both encryption and authentication at the expense of better authentication? Well, a really common approach is to use both. You can use Ah in combination with ESP, but I want you to know the distinction between each one. And finally, I want you to know the steps involved in setting up an IPsec tunnel. It's really a two-step process. There's an IC phase one tunnel and an IC phase two tunnel. And IC stands for Internet Key Exchange. And this secure tunnel is set up as an IKE phase one tunnel or an ISOCAMP tunnel. And it's within the protection of that IKE phase one tunnel that we negotiate the parameters of the IKE phase two tunnel, which is the actual IPsec tunnel as a metaphor. Have you ever seen the old TV show Get Smart? Or more recently, there's the movie with Steve Carell, Get Smart, which is hilarious, by the way. I highly recommend it if you've ever watched it. Max, when he wants to talk to the chief, insists that they lower the cone of silence for security. Consider the Ike phase one-tunnel to be a cone of silence. It's a protected environment where you can have a secure conversation. It doesn't work out for Max that often, but it does for IPsec. We're going to have this protected by IKE Phase One, also known as an isocamp tunnel. And then we're going to negotiate the parameters of the IPsec or the IP Phase 2 tunnel. So we have a challenge going. We have GRE, which is very flexible but not secure, and we've got iPSC, which is very secure but not flexible. Here's what we can do. We can do something called GRE over IPsec. In other words, we take any traffic and we put it inside that GRE tunnel. After all, GRE can encapsulate unicast, broadcast, multicast, or whatever, and we encapsulate it inside of a GRE packet. What is a GRE packet? That's right, it's a unicast IP packet. Now, we have broadcast, multicast, or unicast anything encapsulated inside of these unicast IP packets. We can send these GRE packets over the IPsec tunnel and protect them. They can be encrypted. That's a way that we can get the best of both worlds by doing GR over IPsec. And that's a look at VPNs—virtual private networks.

3. 4.2 Dynamic Multipoint VPNs (DMVPNs)

We know that we can set up a VPN, a virtual private network, to give us secure communication between a couple of sites across the Internet. However, if our company has lots of sites, how do we do that? What if Brent Che wants to talk to Brent C? Do we have to have a full mesh of connectivity where every site directly connects to every other site? That's not going to be very scalable. We could do what we see here on screen. We could use a hub-and-spoke topology, with the headquarters serving as the hub and connecting to the Brighton sites. Or, in other words, the spokessides are the challenge with this, though. Let's say that Branch A wants to talk to Bright C. There's no direct connection. It would have to go back to the headquarters, back to our one, and then over to R-4 at Great C. So it would be nice to have a direct connection. But that's a lot of configuration to have a full mesh of connectivity between our sites. Fortunately, we can use something called DMVPNs—dynamic multipoint virtual private networks. For example, let's say that Brent C wants to talk to Brent B. We can bring up on demand a tunnel. We dynamically bring up that tunnel because the interface that we're using to connect into the Internet is configured as a multipoint GRE connection. That's a single interface that allows us to reach out to multiple GRE destinations. And the protocol that's running behind the scenes is called NhRP, the next top resolution protocol. Here's what that's going to do for us. Let's imagine that Branch A, Branch B, and Branch C have private IP addressing within each of their sites and have networks within each of their sites. And those networks with those private IP addresses are being advertised to the different routers. Their advertisements go back to the headquarters and then out to the other sites. So Branchb knows about the private networks at Bridge A, and it knows the next top IP address, which is going to be some sort of private IP address. The challenge is French Bee doesn't know how to get to a private IP address across the public Internet. That's not allowed. So how is it going to set up a tunnel with Two if it doesn't know its publicly accessible IP address? That's where NhRP can help us out. We can have our spoke routers educate the headquarters router, which is going to maintain this NhRP database. Rachel may say, "I've got these private IP addresses in my network, and the next top IP address to get to any of those is the private IP address of 100 zero one." Well, that's not reachable directly over the public Internet, but what we tell the headquarters—in other words, we tell the headquarters in the HRP database—is. If anyone wants to get to 100 010, we tell them to set up a tunnel with 192 010. That's my publicly accessible address. R Two communicates with the Internet using this address. And our three might say, "Yeah, if anybody wants to get to any of my internal networks, they need to use the next top number of 100 zero two." How do you get to that private IP address? You set up a tunnel with the publicly routed address of 2 30 113 1. Similarly, for branch C, we say that if you want to get to any of my networks inside the brain CE site, you need to use the next top number of 100 zero three. And to get to that private IP address, you're going to set up a VPN tunnel with the public IP address of 198 51 101.and the headquarters router are one. In our case, it's going to maintain this database. So let's go through a scenario. Let's say that R Four wants to communicate with R Three. It's going to send an NhRP query. It's going to go up to the headquarters and ask what physical interface IP address is associated with the tunnel interface IP address of 100 zero two. In other words, I've learned via some routing protocol about a network I want to reach. And that network advertisement said, "I need to use the next-top IP address of 100 zero two." I can't access it through the public internet. However, the headquarters is going to tell me a publicly written IP address with which I can setup a tunnel, and that's going to let me get to that next top IP address. So the headquarters is going to respond, and it's going to say, "Oh, if you want to get to 100 zero two, you need to set up a tunnel with 2030 113 one." That's our three internet-facing IP addresses, and that tunnel is dynamically formed between Branch C and Branch V. So to sum up, a dynamic multi-point VPN uses a multipoint GRE interface on a router to connect out to potentially multiple remote destinations across the Internet. And we can have a database that knows these private IP addresses at these various locations; they can be reached via the publicly accessible IP address of the location. And we can hand that information out to our spoke routers. And those spoke routers can then dynamically form a tunnel directly to whatever destination they're trying to reach.

4. 4.3 Web Services

In this video, we want to consider Web services. And I'm guessing you've visited a few websites while surfing the Internet. But let's take a look behind the scenes and see what's going on when you visit that website. Let's say that you're on this desktop computer on theleft and you have an IP address of 199, 2210,and you want to get a web page from theweb server with an IP address of 2030, 113, 100. Now let's say that you've already learned the IP address of the Web server. You've already done a DNS lookup, which is the domain name system. That's a topic for another video. But you have looked up the IP address of that web server, and you're ready to send traffic over to that web server requesting a page. Here's what that packet would look like. It's got to have a source IP address, which is you; it's got to have a destination IP address, which is the web server. And it has to have port numbers. And we have a group of well-known port numbers, such as Http, the hypertext transfer protocol that the web server is running. So the destination port, the port pointing to the web server, is going to be port 80. That's the number you need to know. But what about our number? We've got to have a return number to come back to us at the desktop computer. Well, we somewhat randomly picked a number. It's called an ephemeral port number or a dynamic port number. Here, I'm just somewhat randomly chosen. 44,001. That's our port number. And when the web server gets our request, it says, "Oh, I see that this desktop computer wants this web page." All right, here you go. And it sends the Web page back to us. But notice that things have been transposed. The source IP address is now the Web server. The destination IP address is now the desktop computer because the packet is coming back to us at the desktop computer. The source port is now 80 because that's the Web server. And the destination port is that ephemeral port number that we came up with of 44,001. And that's what this exchange looks like when we get a web page. But besides just pointing to the Web server, what is the desktop computer actually saying? Well, it can use a series of HTTP verbs. And just as a reference, here are some of the more common verbs. This is not comprehensive, but some of the verbs that might be used would be post, which would create a new record on the web server. Get, get, get! That's probably what we're doing when we're getting a web page Put that where we're updating an existing record; delete it where we're deleting a record. But those are the types of instructions we're sending over to the Web server. And I said that when we were going to this webserver, we were using port 80, which is the well-known HTTP port. However, we probably would not want to use that if we were sending credit card information over the Internet. If we were going to buy something in a case like that, we would instead want to use HTTPS, which is HTTP secure. It uses TCP port four four three,as opposed to TCP port 80. So, while HTTP has the well-known port number of 80, for secure communication with a web server, we'll want to use Https, which will use the TCP port of 443.

5. 4.4 Voice Services

Let's consider how traditional voice services have migrated over to our network, which was previously a data-only network, but now it might be able to carry voice and video data. But to go back in time just a bit, large companies traditionally owned their own private telephone system called a PBX for a private branch exchange. Smaller organisations might have something called a keysystem, but the general idea was the same. Since not everybody is going to be using the phone at the same time, we don't have a bunch of lines that we pay for every month going back to the central office. I used to work at a university, and we had about 6000 phones on campus between the faculty and staff and some of the students about 6000 phones.But did we have 6000 phone lines going to the local telephone company? No, because statistically not everybody is going to be going to the telephone company. at the same time. I think we had just over 200 lines—all we needed to support 6000 phones. So a PBX was a great way to save money. And we had remote campus locations as well. And we connected to those remote campus locations over some sort of a tie line.This might be analog, or it might be digital, but for years, this is the way it worked. and some companies still use this. Assume that extension 1050 wishes to contact extension 2020. Well, we go off hook, and we dial 2020. The PBX interprets those dial digits, and it's going to send that signalling information to the neighbouring PBX, which is then going to send ringing voltage out to directory number 2020, and it's going to ring. And as a first step towards moving away from this architecture to a voiceover IP-based network, we could keep the PBXs and preserve the customers' existing investment in those PBXs. By inserting routers in the mix, we can get rid of the tie line and put routers there instead. The PBX is now connecting to a router, which we're assuming was already there. We already had a connection between these two sites. So now the voice is just going to ride over what was previously a data-only network. Again, we want a 1050 extension to call a 2020 extension. So we dial 2020, the PBX interprets those digits, and it sends that signalling information out to our one through some sort of telephony interface on R One.and it's going to packetize that. It's going to put it inside IP packets and send it over the network to R2, which is then going to send it to the PBX in that PBX's language using whatever signalling it needs from another telephony interface. And that PBX is going to send the ringing voltage down to 2020, and it's going to ring. So that's the first step toward transitioning from a traditional telephony network to a Voice over IP network. But we can go a lot further. We can start moving away from traditional phones like these, these analogue phones, or even phones that were made for a PBX. We can now have IP-based phones like we see here on the screen. And the PBX replacement is called a call agent. and it's going to have dial plan information. It knows where different phone numbers live. And let's say that we still have our two sites. And at one side, I've got extension 3800. At another site, I've got an extension at 1012. And 3800 wants to call 1012. Well, what it's going to do is send those dial digits of 3800 up to the call agent. But it's going to do that using a signalling protocol. Typically, that signalling protocol is SIP. That stands for the session initiation protocol. We're saying I want to invite directory number 1012 into this session. in other words, into this phone call. And the call agent says, Oh, I know where 1012 lives; it's registered with me already. I know it's at this IP address. So let me reach out to them using the SIP protocol again, and I'll tell them that you would like to invite them into a session. and we'll negotiate all the parameters for that session. We'll negotiate things like how we're going to encode voice; if we're going to support fax machines, what rate are we going to support? And there are a lot of other parameters that we can agree on during that negotiation. But once the call is setup, 3800 can call 1012 directly. Notice the call agent is not involved in this exchange. We're sending our actual voice media to 1012. We send the alerting information, it answers, and we reexchange voice packets in the form of RTP packets. RTP. That stands for the Realtime Transport Protocol. That's a UDP-based protocol, and it's going to carry our voice media. Oh, and notice the phone on the left. It has a camera on it. Some IP phones can send video as well. And if we send video in addition to audio, that video is also carried into RTP packets, the Real-Time Transport Protocol that can carry both voice and video.