Examining Network Topologies and Traffic Flows, and Networking Protocols and Services

Welcome and thanks so much for joining us for this episode. We're going to be getting more into some network topologies in this episode as well as traffic flows. So we've got a couple of different diagrams here we're going to take a look at and they are quite fun. There are a lot of shapes involved and I do enjoy shapes. So Wes, where do you want to start today? >> I think what we would do is just maybe start with topology, just the discussion on what a topology is before we talk about the types of topology. And it's interesting, Sophia, because from a physical and a logical standpoint, there are different topologies, not just how they're structurally arranged. Let's go ahead and define what a physical topology is and the difference between that and a logical topology. So a physical topology is really about the physical layout of your network. What is the relationship with the nodes to maybe connectivity devices? Remember, we've talked about our endpoints and we have redistribution points. Well, how are those endpoints? You know, the servers and PCs, laptops, tablets, you name it today, a lot of endpoints out there. How are they arranged within and compared to the redistribution points? Like, for instance, a switch, right? Do we have it connected in a star pattern, right? What kind of cables are we using? Are we using 10G cables? Are we using cat cables? Are we using cat 6, cat 7? Or are we using old cables, right? Those are the physical makeup of your network and all of the connections and the nodes' relationships really to the connectivity devices. But, and we're not going to go to the actual topologies yet, but let's say that I've got a star topology. I just want you to think of a centralized Nexus, right? And you've got some spokes and then you've got those spoke devices, right? So you've got a star, right? It might be a physical star pattern, right? It's laid out to a central connectivity device, but that connectivity device might do polling, right? Well, in the old days it would do polling and it might ask every device individually so the data starts to look like it's flowing in a ring even though physically it's set up like a star. So I want you to know that the logical topology is how the data moves across that network and it's not contingent on the physical layout. I'll show you a little bit more about that, but it is important to understand what topology is. We talk physical topology, the structural layout of the network and the nodes and the cables and relationships to their connectivity devices. Logical topology, that's the data path. >> Okay, so now that we are familiar with what its topology actually is or what that means, we do have a couple we want to go through. I know you mentioned star, we've got ring, we've got bus. Where do you want to start? Sure, let's go back. Let's get in our DeLorean and let's go 88.5 miles an hour and go way back in time. So we're going to go back to one of the earliest network models >> that we were using. And it's this one right here, it's called bus. All right, now bus topology essentially, you might think of it as a linear topology. We really don't call it a linear topology, but that's how it's arranged in a linear fashion. And what you would have is a centralized backbone cable. In the early days, it would be the 10-base-2 and 10-base-T thin-net and thick-net, right? And these devices on the ends of this centralized linear cable would have these terminators, not the governator, but they would have resistors. And what that would do is you would terminate the ends of the cable to prevent signal reflection, right? Essentially, it's a resistor that absorbs the signal rather than it meeting an abrupt change in impedance and bouncing back to its source. Now if you removed those resistors of that termination, the whole entire network would fail. So it wasn't very scalable. Another thing too is that when these networks were implemented, all we were using was what was known as carrier sense multiple access over coaxial media. That was actually the precursor to what would later become ethernet. It was actually originally just coaxial media that we were sending collision detection, carrier sense multiple access collision detection. So what does that translate to? I know there's a lot of jargon here. What that means is that as I add computers to this bus, right, what we're going to do is we're going to add more contention on this network because what happens is in these old bus networks, when this computer would send information onto the wire, it'd go to everybody. And when this computer here would send communications onto the wire, it'd go to everybody, right? Well you can probably imagine that as we start adding more computers through this network, we start getting a lot more contention. And I'm just dragging these out here to kind of show you because now we got a bunch of computers all contending for the same media. So it wasn't really scalable. Even some of the larger scales I think didn't even go past 500 users, right? And that seems like a lot and it certainly was in those days. But today we have thousands. But you could have a thousand people in these big businesses. So scalable models that you have, not very scalable. And due to the fact that it didn't really have, it doesn't have any fault tolerance, right? A break in the cable, guess what? Whole network's down. Well, it doesn't matter if the cable's down, if the computer goes down, guess what? Whole network goes down. Pull the resistor off the end of the terminator, essentially the termination off the end of the cable, guess what? Whole network goes down, right? So you start to see a pattern and that's why these kind of got phased out because they weren't very scalable in large networks and as we needed to grow, we needed to go farther. Now around the same time, we had competing technologies. This goes back to the days of the 802 body from the IEEE. They met in 1980 February, the second month of 1980. It's how the 802 term came about. And we had all different kinds of companies that joined that committee. Microsoft, IBM, DEC, which I don't know, they might've been compact at that time. But anyways, Digital Equipment Corporation, all these major companies, Cisco, all of them, right? Well, guess what? A little company named IBM, not so little, put all of their money into something known as Token Ring. We would later have a standardization called Token Ring, but then there would be the IBM Token Ring that would be proprietary. These were deterministic media. They were not the contention based media of Ethernet. And what that means is I have this abstractly right here, looking like a ring. You would have a connectivity device right in the middle of this. And what it would do is it would pull the devices. Well, polling came a little bit later. They would have what's known as a token. It was a special set of bits that could be captured by a device saying, hey, I've got some information to send. And that information would be sent back out onto the wire in a unidirectional pattern to the next one downstream neighbor. All right, well, there's a problem with this type of topology. If that downstream neighbor went offline, guess what? The whole network went offline. And that was a problem in those days. It didn't have a lot of fault tolerance. Now, I say that, but let me say this. They did find a way later on to make it a little bit more fault tolerant in the fact that the connectivity devices would go to send a token to a device that wouldn't respond and it would reverse the order of the token. Right. So it would go back the other way. Right. They could keep doing that until that come back online. But that's really just kind of a stopgap. Right. Now, you don't really see these anymore. Almost none. There was another one that they tried to implement that did implement this ring topology. And that was something known as FIDI. I just like saying it. Fiber Distributed Data Interface, F-D-D-I, we called it FIDI. All right. And the fiber distributed data interface for the time, very expensive, but very, very fast. Very fast. There's not many of these networks left. If they are, they're pretty much isolated networks, very specialized people that are trying to get their return on investments. Maybe some schools might have it. Maybe transportation systems. But these have been phased out. Now, there is one place you still see ring networks. And technologies. Sonnet. Synchronous Optical Networking. Sonnet. That's what they call it here in the States. If you're in the European nations, it's SDN. It's Synchronous Digital Hierarchy. Same standard, different parts of the globe. This is a dual ring. Oh, and by the way, FIDI was a dual ring topology too, which was really good. And so when I mentioned that, let me go ahead and just say it would have been more like a dual ring topology. So what could happen is you could aggregate both of those FIDI rings and you could get like, I think like 200 megs. That was a lot in the day. Or what they would do is they would use that backup ring for exactly that backup and control data. We still see dual ring topologies in the Synchronous Digital Networking. Oh, excuse me. Synchronous Digital Hierarchy in Europe and Sonnet here in the States. And those are fiber optic communications. If you have ever heard of OC-192 or your different optical carriers, those OC are carrier standards for Synchronous Sonnet communication. So we do see these still, but not in land. Not land. How about land environments? They're all on land. They're bounded media. So that's the ring topology there, Sophia. Now the one, because of the lack of fault tolerance to the bus networks and the ring networks, FIDI was great, but it was astronomically expensive in the day, right? Fiber optics back in those days, $1,500 a port. We have ports right now in our server closet here that have 100 fiber optic ports. They're nowhere near that. They were very expensive. Can you imagine that? $1,500 and you got 10 of them? Yeah, you're $15,000, you know, hundreds of thousands of dollars. So because of that, the expense, because of the lack of fault tolerance, this became the most popular and still is the most popular networking topology in modern networks. It is the star topology. The star topology is exactly what it sounds like. You're a smart crew out there. We've got a Nexus device, the centralized connectivity device, otherwise known as our redistribution point. Our endpoints are connected to that and a star topology. Now why is this beneficial? Let's go ahead and talk about some of the links, right? Well, guess what? Computer goes offline? That isolates that one computer. All the other computers that are connected to the switch operate like it's business as usual. All right, so that's the computer. What happens if the link goes down? You just isolate that one computer. So that's one of the reasons that this became a very popular type of network topology because it would isolate only the system that was having the issue and not bring that one system down and, you know, chew down the whole network. So that's the star topology, right? You have a central connectivity device and you have the devices arranged in a star pattern. Now I want to take a second if I could, Sophia, and I want to stop right here because a ring topology actually looks like this. You're connected to a connectivity device. But what would happen was instead of me saying like switches do, I could say, okay, this computer wants to send information to this computer, forward it to the switch. Got a Mac table? Knows exactly where it goes, right? In these earlier connectivity devices, what they would do is they would pull this device and say, hey, you have any information to send? No? Okay. Do you have any information to send? Oh, you do? Okay, we'll go ahead and send it to this person, then send it to this person, and then send it to this person. So I want you to see here that when we talk about that, even though this is a physical star topology, which is really what token ring would have been, it operated in a ring logical topology. It is the connection device that is actually saying, computer one, do you have something right up here at the top? Look at what we're doing. We're going in a circle here, right? One, two, three, all in a ring, right? That's the device, the connectivity device that's doing that polling. Pros and cons, deterministic media, right? Why would you want to use something that is so contention based that you could have collisions? Because it's cheap. There's not a lot of logic. There is logic. Don't give me your-- switches are very expensive. But compared to deterministic media, they have to have a lot more logic built into them. Why? Because they have to do that communication. I'm going to poll you. Do you have information? Oh, you do. Well, here, let me go ahead and pass that to you. But oh, wait, that node's down. Let's reroute the whole entire community. There's a lot of extra stuff, so it was very, very expensive. So this ended up becoming the topology that really kind of won out. I want to talk about one that's more of a logical topology today. And you don't really see it too much in a physical topology. That's a tree topology. The tree topology, you have these tiers, right? And typically, you used to have a formula. And I can't remember the formula. The formula said for every many second level tiers you have, you have the same amount of level, third level tiers for each node. So if you'll notice here, I've got, starting at the hierarchy, but then I've got three second tier nodes. Well, that means each of these nodes must have three nodes. And then yes, if we go a little bit farther, then down here, this node would have three nodes, three nodes. And I'm not going to keep convoluted in this. But that's how that formula would be. But we don't really see this in physical implementation. We see it in logical implementation. Let me tell you where that is. DNS. The domain name system. We have the root hints that are the highest part of the hierarchy. We have the top level domain controllers that are just under them. And we have second level domain controllers under them. And finally, we have the businesses that own their own domain controllers under them. It is a tree topology. And it does flow from the root down to the top level domains and down to the second level domains when you're doing name resolution. So that's an example of where the physical topology and the logical topology do not necessarily match. >> My only criticism so far is that that double ring that you showed us, I feel like they should have called that a donut, but they didn't. So that's my only criticism. I guess it doesn't matter because it's not really around anymore. >> So that tree one you said is not one you'd see very often. What about this this one next to it? Everything's connected and crossed over and convoluted. This is one you will not see in a wired network. I do it just for visualization purposes. And this is what's called the mesh network. >> So the mesh network is one that's not really implemented in wired connections with a caveat. A mesh network is a network in which every node has a connection to every other node within the network. It is almost next to impossible to do within a wired connection because the exponential connection increases every time you add a single node. So where do you actually see this? Wireless. If I have a wireless ad hoc infrastructure mode, right, you have infrastructure mode where you're going through an access point. You have ad hoc mode where every other wireless laptop can talk to every other wireless laptop without going through an access point. That is a wireless ad hoc or mesh network. Let me show you where you see this as well in WAN environments. WAN environments use mesh topologies when they don't want a portion of the network to go dark when a router goes down. So if you were to replace every one of these with routers, you would see WAN technologies that are being used as mesh networks. Now Anthony pointed something out. Anthony Sequerri, he's our resident Cisco expert. He mentioned also remember, so thank you Anthony, remember the partial mesh too. I'm just going to take some of these connections out here and I'm not going to delete all the connections. That would be a partial mesh, right? Or something like this where maybe you don't have all of the connections out here. You don't have a full mesh, right? So in one portion of the mesh isn't connected to every other node. That's a partial mesh. So I want you to know that you still see these in WAN environments where you have ISPs that have multiple backbone routers in a mesh environment with connections to other routers. So if one of them goes dark, we don't go offline. So another place that you would see these mesh networks is in like the old frame relay networks. The frame relay network is like kind of like a cloud base where you had this logical identifier on one side and a logical identifier on the other side. It really didn't map to anything physical within the frame relay network because it was a mesh network that was abstracted and controlled through the ISP. You only see the identifiers on the end, right? So that's the mesh network. And these are some of those major topologies that we really need to talk about. >> As we get further into this document, there are some diagrams here that look to me like Star Wars ships. Yes. Star of Stars, Ring of Stars, are these things we'll see pretty often? >> Not really. Okay. So you're going to hear the term hybrid topology. What is a hybrid topology? Take any of the ones that we've given you and blend two or more. You need at least two, right? Or it's not hybrid. It's just the model. All right. They don't usually, we don't set out on purpose to set these this way, right? Let me give you an example, right? Mergers, right? We have one company that has one network model and they've been using it. We have another company that comes in and they merge and they're using another networking model. Well, now we have one company that has two different networking models. So collectively they have what's known as a hybrid model or an acquisition. You see it in M&A. We don't set out to design a convoluted network. You shouldn't. If not, you should probably try a different industry. But we don't set these in play to get started. So let me give you an example. Now, this one you might actually see at Star of Stars because if I was to replace these with just network IP addresses, then we could potentially have a router that is routing information into these, like for instance, autonomous systems that have star networks behind them, right? But this is what's an example. Like, for instance, a Star of Stars, right? We have a central main connectivity device, maybe a core backbone router and it's connected to sub routers within a star pattern. It's a Star of Stars. These are just a couple of examples. You can mix a lot of them, a star ring pattern, right? What I could do is I could have stars. Well, actually, a ring of stars, right? So now I have three star patterns, but the connectivity devices like Sonnet, the WAN environment would be the ring. All right. Again, we don't set out for these. This is a ring of stars and that was the whole Ringo star. I love it. That's how I'm going to tell people to remember it. But you have bus star patterns, right? We don't try to set out for these. I just wanted you to know what a hybrid is in case maybe they ask you. Just remember it's a blending of two or more of the network topologies that we've talked about. >> We also mentioned at the beginning of the episode that we were going to get a little bit into traffic flow as well. I understand there's traffic going into the firewall and then there's traffic that happens behind the firewall. So what's the difference? Sure. Perfect. So let's go ahead. Let me show you. Let's start with north to south. All right. When we talk about north to south, >> traditionally from a security standpoint, really, the traffic flows are still the same, but they haven't really become really, we haven't really focused on them as much since this term zero trust came into play. North to south traffic is the traffic that comes from, let's base it, an external network that you don't own into your network. It's typically the internet, right? But whoever's past that, you don't own that network. It'd be an ISP. That's the north to south traffic. In fact, Sophia, you mentioned the firewall. I really like that. That comes from the internal or an external network through your firewall into your network. That's a great way to put it. That's north to south traffic. >> Now you understand the term lateral movement, right? But from a security standpoint, what does lateral movement mean to you? I'm going to throw a question at you. Sure. So from what I remember, if you've got access to a network and you're able to stay on the same level, maybe my job, my permissions are the same as yours, but maybe you're in a different department and I can jump from one profile to the other. That's lateral. And if I were to move up, that's not lateral. If I were to get into my boss's position, that would not be lateral movement. >> That's about right. How about a pivot? What is a pivot? >> Oh, gosh. All right. So pivot is where you have compromised a system and now you're going to pivot laterally somewhere else within the system. Oh, okay. Makes sense. All of that. The reason I say that is because maybe you haven't heard it in a network and communication standpoint, but from a security standpoint, that's internal communications inside of your network, right? Oops. And I'll get it there eventually. That's the east to west traffic. And I'm not going to bring this up too much because these auto adjustments will drive me crazy. Your east to west traffic is exactly like Sophia said, right? Your lateral. Who, once I'm here, right, and I communicate with a station in here, well, that's east to west. That's inside the perimeter of your network, right? It is important to understand traffic flows, right? And it's not only important to know traffic flows just from a basic networking standpoint, but also from a security standpoint. I'm going to just briefly mention something called zero trust because you will start to hear more of it. The reason this started to become so important, right, is because in today's day and age, we always assume breach. We always verify and re-verify. We never trust, right? That's zero trust. We don't trust anybody. And when I authenticate you, I don't care if you're an employee, I'm going to authenticate you again and I'm going to keep authenticating you. But we do that because traditionally we were only worried about protecting our north to south traffic and we can do that through firewalls and IDS's, IDS IPS's, right? But then once somebody got into the network, they didn't have to work quite as hard because there was an implicit trust. It was implied that once you had authenticated and you're in the network, you should have access. Well, that is not the case. It hasn't been the case for a very long time. That's where the east to west traffic protection came in. And now we not only protect the north to south traffic flows, we also protect those traffic flows inside of our networks. Absolutely. Like you said, zero trust, better safe than sorry. That's right. Just because I think people are after me doesn't mean they're not. Right, exactly. Just because you're paranoid >> doesn't mean they're not watching you. That's right. So we also have a couple more things here in this document, a couple of different network models. Can we walk through those real quick? Sure. And I didn't really put this in the title, but it is important because network models and network topologies, they are close, but not really the same. I'm going to go ahead and I want to talk about, I'm going >> to talk about three here. So let me go ahead and just breeze by them real quick. Take your motion sickness pills. So we got centralized, we got client server, and we got peer to peer. I'm going to come back. Let me not drive our poor director crazy. Let's just focus in on one of them. We'll come back to the other. And centralized was one of the very earliest models. Now, networking models, all right, a little bit different, all right. Who controls the communications within the network, right? Well, in the early days, we had mainframes that would be connected to terminals, dumb terminals. The terminal was called a dumb terminal because it just had a keyboard. It didn't even have a mouse in those days, a keyboard and a freaking monitor. And that was it because the centralized mainframe, I'm calling it a host computer. And I got to be careful with that today. The host computer controlled all the processing, controlled all the network communication and controlled all of the data storage. That's why it's called a centralized networking model. Well, you might see that, well, that's good for very large corporations that can can really afford a two to three million dollar mainframe. Well, what about the smaller companies? Well, this wasn't really something that smaller companies could have. So one of the things that we would find. So how about this? If we lost connection to the mainframe, guess what? That terminal went dark. You no longer could get any work done. Right. So it wasn't very what happens with the host. Host goes offline. All the terminals go down, right? So it's not very if as far as fault tolerance goes, there was a better way to do it. And they came up with the most common model that we have today. And that's the client server model. All right. In the host model, the centralized model, that host controls everything. In the client server model, you have clients. Clients is just an operating system that is requesting a service. Hey, I need a file out there. In my case, I said, hey, I need a resource. Could be a file, could be a website, could be any one number of things. But then the server is the one that is playing a role out there, listening out and saying, hey, yeah, you need that file? I'm an FTP server over here. You can find that file over here. So the client server relationship, what that means is clients are operating systems requesting servers and servers are those operating systems providing the services that our clients need to perform or need to use. How does this model benefit us versus the old model? Well, your clients are self-sufficient computers. They do their own processing, their own storage. They control their own network communications. So if I lose access to the server, I'm still productive. I could still work. I have a self-sufficient computer. And that's why this has been more of a popular model, especially in an enterprise. Last one, but not least, if you've been around a Windows environment, Windows calls this a workstation or I'm sorry, a workgroup, not a workstation, a workgroup. All right. The industry as a collectively knows it as a peer to peer model. Now, what's the difference between the client server model and the peer to peer? Well, just really only one thing. What makes them peers is that in a peer to peer group, a computer can act at sometimes like a server providing a service, but then at other times it can act as a client requesting a service. All right. So what we have as far as peers are is that they are equal in the client and the server mentality. Let me give you an example. One computer can be offering a print service and have a printer connected to it where another peer says, hey, I need to print something. Come on over here. I'm acting like a print server right now and I can provide you with that service. That same computer is now storing a file and it says to the rest of the peers, I have that file you need. It is now acting like a server. So >> the roles are >> basically every computer can act as a server and a client. It's what makes them peers. These are the three networking models that I would be aware of and some of the other topologies and some of the considerations when it comes to whether you might be taking an exam or maybe you were just trying to move up the you know, the help desk ladder. If you know these and you can identify their strengths and weaknesses, it can help you tremendously. >> These different network models and topologies and traffic flows, they're all separate topics, but they all kind of blend together. They all kind of have to do with each other. So it's good to talk about them collectively in one episode and talk about how they relate. Thank you for walking us through all this, Wes. I really did like those diagrams. They were fun. It was like looking at Star Wars battleships. And thank you for joining us for this episode and we'll see you next time.

Welcome and thanks for joining us for this episode. We're going to be getting more into networking protocols and services. Lots of port numbers, lots of names in this episode, lots of acronyms. And >> if I'm not mistaken, this is probably where our flashcards are going to come in handy. Is that right? Most definitely, because at the end of the day, we're going to tell you what a protocol is, and we have a variety. >> So I think that's, you know, in this episode, there are a variety of common protocols that I want you to be aware of. Sophia wants you to be aware of. And I tell you what, we find them a lot in modern networking, and that's why they're important. But I want you to know that as we go through some of these protocols, these aren't the only protocols that you're going to encounter, but these are kind of like what I say the fundamental protocols of networking. You're going to see a lot of them, and they form a lot of the basic, you know, functions that we need when we need to communicate across networks, or we need to, you know, maybe connect to resources. So that's what we're going to look at in this episode. And you know, Sophia, what I was thinking of is how about we step back for a second before we say, here's a laundry list of protocols. We define what a protocol is. Sound good? >> Yeah, yeah, absolutely. Start with the basics. All right. So a protocol, right? I want you to think about two people speaking the language, all right? >> If they're both speaking English or they're both speaking Spanish, French, German on each side, right? We can have a communication, no problem. Why is that? Well, in language, right, it has a set of rules for communication, how those words are structured, how they're pronounced, right? And if you're speaking the same language, well, you shouldn't have too hard of a time understanding those rules. Now, I'm not saying you have to be some collegiate expert. I speak three languages, you know, English, bad English, and worcher English, right? So the point being is that commonality, right, that structure allows you to form a communication between you and somebody else. Now, I don't speak Spanish. I would love to learn Spanish. It's a beautiful language. We've got a lot of people here at ACI that speak Spanish. And if I was to try to speak to them in their native language, I would be lost, right? I wouldn't be able to communicate. So I would grab somebody wonderful like, you know, maybe Miss Corolla on our team, one of the ACI employees here, and she would be able to translate for me, all right? So I want you to think about that communication and that commonality between the languages as what a protocol brings to us when we need to act as a service across the network. A protocol is nothing more than a set of rules that define how a communication is going to happen, all right? But it also defines the type of service that is provided by that protocol, and that's what we're going to look at today. Now, the other thing I want to mention, too, and this is where Sophia kind of alluded to, there's a lot of port numbers, right? You're going to find these port numbers that are associated with these protocols that are also called services, and let me just give you a-- before we go to a diagram, if I say DHCP, that is a protocol. That is the dynamic host configuration protocol that we use to make IP addressing in large environments a lot easier, right? It's a protocol that defines the rules for accessing the DHCP service, right? When I communicate with a web server, I need to have the communication structure that that web server is speaking so that my operating system knows how to translate that data, back up the OSI model, and display it to me, right? HTTP, HTTPS, all right? Now, what are the port values? One final thing I wanted to mention here, too, what is a port value? A port value, you will hear them say, "It's a logical endpoint of a connection." What the heck does that mean? A port is a session identifier. When I have a communication that goes outbound to a web server, that web server needs to know what application on my computer to send it back to. Well, when I'm sending information to the web server, the web server is listening out on a logical connection point called a port. It's listening out on port 80 by default. Now, you can change some of these ports, if you will, but we have what are called well-known ports. All right, well-known ports are all these port values. They go from zero all the way up to 33536, because zero is included. You have what's known as a well-known port range, and that's zero to 1023, and those are where the common protocols sit in. And by the way, this is all by INA, the Internet Assigned Numbering Authority. They're the ones that set these port values. And you can go, and I encourage you, go out to INA and find the port values. I'm going to give you some of the common ones here. But now, when that web server responds back to me, that web server isn't only responding to me, it's responding to, you know, potentially thousands of other people. Or what if I connect to the same web server and I've got multiple tabs open with different results going to the same web server? How does it keep track of those connection points, which essentially are other tabs? Those are other HTTP requests that you're sending against that web server. Well, when it sends it back, it sends a port value attached to it, and my computer can identify that as, "Oh, that goes to this connection. This port value goes to that connection." So there's another port range I want you to be aware of, too, and that's 1024 to 49,150 EU1. That's the registered port range, right? These are more of guidelines. Your RDP protocol, port 3389, sits within that range, right? These are typically registered as software. But then when you get to that 49,152, all the way up to the 5,000, what is it, 65,535, I got it wrong, 36, but zero counts. So it's 65,535 ports, all right? So that 49,192 to 65,535 are what are known as the ephemeral ports, right? These are the ports that don't really, they get reused, right? Those ports are used to determine those endpoints, like, for instance, in those browsers. When the connection stops, those ports that are in that last port range, right? Those private ports, they essentially get thrown back in the pool for additional connections. So there's the port range that I want you to be aware of. The port is nothing more than an identifier that identifies that logical endpoint of the connection. >> And some of these services we're going to talk about, it looks like they have multiple port numbers listed, and I guess that's because maybe you've got a service on one port and then the secure version of that service on a different port. Is that right? Couldn't have said it better. That's exactly right. And what I did to make this a little bit easier, you're going to see that some of these >> can have S behind them. In fact, I say that and I didn't put it in this one. So let me go ahead and keep myself honest right here on camera. And remember that some of these will have an S before or behind them. And what that does is I went ahead and I kind of shortened the list by saying, hey, that's the secure version. And usually what it means is whatever the protocol is providing, it's an encrypted version of that, right? So let's go ahead and let's start with the first one that I want you to know, right? That's TFTP. That's the Trivial File Transfer Protocol. This is like FTP. I always say, yeah, it's like FTP, but it's trivial. What's the trivial part? Well, it uses UDP. It doesn't have all of the functionality that FTP has. FTP has a wide range file transfer protocol. This is Trivial File Transfer Protocol. Let me give you an example of where we use this. When I worked at New Horizons, you know, a technical training institute years ago, one of the things that we would do is we had a bunch of thin clients set up, right? And we had a server, that main server that all of those thin clients would connect to, and they would pull down a config file. That config file would come down to the local thin client, set the session up for that time, but it was done over TFTP. Why? Why would you use an unreliable protocol for something that's a file transfer? Well, because you're doing very, very small files, and speed is of the essence, not reliability. And if I had the reliability, well, then we're going to slow things down. We're going to wait for all those packets to come back, right? That's Trivial File Transfer Protocol. Now, I'm going to throw Sophia some curve balls here. And with the Trivial File Transfer Protocol, do you happen to know what this one might be on, what ports this might be on? >> I know that the standard file transfer protocol is either port 20 or 21. You got it. So is the Trivial File Transfer Protocol anywhere near there, or is it further out? It is not. And I am so glad you said that, because those of you that might be answering exams in well-lit rooms, answers might need to know that, all right? But if you're in support, right, you can-- this is >> the Google-- let's Google this, right? But again, in an exam environment, you'll have to know this. And I'm glad you kind of put it as an association with FTP, and the answer is no. It wouldn't be that easy, right? Right. So this is port 69. So thank you for trying. But let's go ahead and let's do exactly what she said. Let's just drop down right to the file transfer protocol. Now, remember, this goes over transmission control protocol. It's more robust, and it's highly optimized for large file transfers. This has been around since the days of ARPANET. This is an oldie but goodie. All right. And then the reason it stays around is because how optimized it is for large file transfers, the command sets that you can throw at it. But here's a problem. When it came out, just like the one below it, it was not as scary of an internet as it is today. So in those early days, they didn't bake in security because there were only about five entities even connected to ARPANET back in those days. We had the government and universities, right? And then you had Steve Wozniak hopping up on there and hacking the system across from California. Great story if you get a chance to look it up. It's fun. But they didn't have any security because back in those days, there wasn't anybody on the networks. That day is far long gone. So now what we do, because it is what's known as a clear text protocol, which means, and I know she can do it, if Sophia was on this network and she fired up a wire capture software and I logged into an FTP server, she could see everything that I just typed. However, since we want a little bit of security, we want to change that plain text and cipher text. We do that by adding SSH. SSH extension to FTP. Now, what do I mean by that? It's really just an SSH tunnel. And I'm going to go ahead and mention SSH out of order. You'll see it's in the next column, but since I'm mentioning it, let's not have you flying blind. SSH is the secure shell. And it allows you to do tunneling, a tunneled encryption between your endpoints so that now, let's say the same scenario, Sophia's out there. She's got the auditor's hat on. She's doing a legitimate pen test. Now she can't see the information because it's encrypted between the endpoints. Now, it is not the port of unencrypted FTP. You had already mentioned those. Data goes over port 20, commands port 21. Data over commands, I always remember that. That's how I try to remember it. My data is more important than the command, so 20 comes first. If it doesn't work for you, that's okay. But when we say FTP, we actually wrap that in an SSH tunnel, so the port is 22. And I want you to know that. SSH secure shell, you're going to see it's the first one in the next column, this kind of hidden. That is one that we can do encrypted remote connections. Versus the one that's right below FTP on your screen, that's Telnet. That's the terminal emulation software, and it has been around for a very long time. And what it does is it does exactly what it sounds like. It emulates a terminal that would make a connection into a mainframe. And back in those days, those were really closed systems, so you didn't really worry about encryption back in those days. Today, you do not want to make any remote connection to any device where you have a clear or plain text protocol. So Telnet could be used to test port connections, but past that, I would not be using it to connect to remote. Devices being plain text. How about this port? Do you know this port here? Telnet? Telnet? Is it 23? 23, you got it. See? Now, we've kind of already talked about this next one, right? I'm going to go ahead and just open up the whole column so we don't have to do this one by one by one. We talked about SSH, right? SSH is the way today you want to make a remote connection into a connectivity device because it encrypts the communication. And then, you know, you can't have people eavesdropping on it, right? It helps to prevent the bring down those man in the middle or on path attacks as they sometimes call them. Now, we've got some other protocols here that I want to talk about. These first two or the last two in this column are some of your mail protocols, right? Your email protocols, the oldest one here being the Simple Mail Transfer Protocol. And that is for forwarding email. The direction of these protocols, so when it comes to the email, is going to be important, especially if you're in an exam environment, but definitely in a support environment, too. You have to make sure that you are using the right protocol. So SMTP goes over port 25. SMTP-S, remember, we're encrypting SMTP with TLS. That is going to be port 587. Now, there's another one, IMAP. IMAP is the Internet Message Access Protocol, and this is one in which you can get a lot of information. This one in which you are actually working with your emails up on the message server, up on the email server. This one, the Internet Message Access Protocol, by default is port 143, and then you have your secure. And I did have to write these down in full transparency, and I encourage you to do this as well. Remember, at the end of the day, if you've passed an exam, you can Google this stuff, especially if you're on support desk, but these really do have to become a thing in the past. You really do have to kind of know them. So IMAP secure, that's going to be port 993. And I want you to be careful with that, because I'm going to go into the last column for this table, and we have POP3. That is the Post Office Protocol version 3. I do not know what happened to version 2, but apparently it didn't make the grade. This is one that was kind of like the precursor to IMAP, and this is for receiving email. But it's a little bit different than IMAP in the fact, in those days when you would pull your email down, you pull it to your local hard drive, and you would erase it off the server. That's why in those days you would connect, let's say your Outlook client, pull down your emails, and then when you would maybe go home and then try to log back in, and all those emails are gone. So this is for downloading or receiving email, and POP3 has a port value of 110. The secure POP3S is port 995. I'm going to take a little stop right there, exam alert. Remember, IMAPS port 993, POP3S port 995. All right, so Sophia, do you know this next one in here, DNS? I'm pretty sure you're familiar with that protocol. Domain name service, right? Absolutely. And that is 53? You got it, that's right. 53. Now this goes over TCP and it goes over to UDP as well. I don't know that that's going to be something for an exam, really, that you need to worry about. But I do make mention of it only because when two DNS servers talk to each other, right, they're going to use port 53 over TCP because when we're doing things like zone transfers enough, we want to keep those databases safe and we don't want them corrupted. If I'm making a DNS query, like maybe I throw a DNS query against Sophia's server, I'm like, what is www.google.com? I'm looking for a name query, but I don't really care about it being uncorrupted, right? It's a very small packet, so that type of query, when the client queries a DNS server, that's going to be over to UDP because we don't really care about the connection-oriented service. Very good. Next one is DHCP, dynamic host configuration protocol, kind of like we open the episode up. Remember, this is the way that we can, I don't want to say automatically because it's not automatic until you set it up, but dynamically, rather than manually going to thousands of computers and statically mapping their IP addresses, we can have them connect to the network, call out and say, hey, who's got an IP address? And if your DHCP server is configured and authorized, it will respond back with an IP package offer options and all that. All right, Sophia, this one's a little tricky because this one has two ports. >> That's what I thought because you talked about like FTP and how that has two different ports, but they're for different things, right? Right, absolutely. So I know it's somewhere in the 60s. I don't know the exact number, and >> I couldn't tell you what each of the ports does. All right, well, I'll tell you, it's 6768, and this is one where I always remember DHCP 68, or 6768, Trivial File Transfer Protocol 69 right after that. That is just something I do. It might not help you at all, but that is absolutely right. So remember the two port values for them. And like I said, I know it is a lot of flashcard stuff, but we're also talking about what the protocols do and what the services are that they provide behind them. All right, so without further ado, yes, we've got a laundry list and more. Let's go ahead and let's work our way through these. We have what's known as HTTP, that is the Hypertext Transfer Protocol. We also have a secure version of them. The unsecure version is going to be port 80. The secure version is going to be port 443. Be careful. Do not confuse that with IMAPs 143. That might be a little bit of an exam alert for you. NTP, that is the Network Time Protocol. When we need to synchronize time across the Internet, we have various stratum layers depending on how accurate you want. Some of them you can't connect to because they're like the atomic clocks like at the United States Naval Observatory and stuff. And then prioritize lower that closer to you. Now, this one's easy. Yes, I know this one. Go ahead, Sophia. One, two, three. One, two, three, right? So time, it's the one, two, threes of time. Right, if you're counting up the seconds. Absolutely. And that is exactly how I would remember it too. All right, great. Next one is a management protocol that we use quite often, especially for our connectivity devices. This is the Simple Network Management Protocol, SNMP. Sophia? It's two different ports. It is. Right. 161? Yep, we've got it. And then 162. Yeah, so you have your management stations that actually offer solicitations and then the clients respond. So it does have two different ports there. 161 and 162, remember this helps us to manage and monitor our network devices and their health and condition because we definitely want them healthy. All right, so I know laundry list. Without further ado, let's keep going. All right, we have the Lightweight Directory Access Protocol. If you're going to work in an Active Directory environment around directory services, you are going to need to know this protocol. If you're in an Active Directory environment, it's one of the protocols we use to query a directory services database. LDAP is a ClearText protocol. This goes over port 389. Be careful with that one because the one that is all the way down at the bottom of this list, I'm going to go ahead and mention it now. That's the remote desktop protocol and it is 3389. Extra three. Might be a little bit of an exam alert on there. Sometimes with the fact that you are using directory services and you're communicating with them, you do not want anybody to be able to capture that information. So we also have a way to send it over TLS and that is LDAP secure. That is port 636. All right, >> moving on. All right, take a deep breath. We don't have too many more, I promise you. All right, so the next one is we kind of mentioned is our--well, we didn't mention syslog. Syslog is a--it is a long-time protocol for logging system events, actually reporting system events to a centralized syslog server. We use our--I think it's our sync now. But syslog is still out there and we can still use it. Again, remember, it's just essentially nothing more for us, a standard messaging language, right? And syslog, you know, honestly, I'm going to help--I'm going to ask you for this one. I don't know this one. Do you know this one? >> It is 514, but I only know that because I googled it. All right, okay. Well, we do have it in the notes and that lets me know. She knows where to find that information when she's studying. I would take that advice. All right, so RDP is the Remote Desktop Protocol. It is how we make remote connections to Windows machines and it goes over port 3389. All right, well, I think we're kind of coming up to the end here. We've got the last one. This is the Session Initiation Protocol. I think I've heard this one. Yeah, so when we do Voice Over IP Communications, the Session Initiation Protocol and one that I didn't put up here because I don't know that it's really relevant is STP, SDP, Session Description Protocol. These are two Voice Over IP Protocols. Okay. SIP use is two different in the registered port range. Remember, that's the 1024 to 49,151. This is going to be 5060. That's one word. Number. Let's try that again. I know how numbers work. 5060, one number and then it's going to be 5061. All right, so remember, this is for the signaling and controlling of. They say multimedia communications, real-time streams and stuff. A lot of times you'll see SIP communications. If you've ever worked in Voice Over IP, you'll see a SIP call come in. A lot of times we use it in Voice Over IP Communications. But, you know, there's only one that I noticed I didn't put in the list. I'm going to go ahead and mention here and I apologize ahead of time. You need to know SQL. All right. And more so, know what it is in the port, right? That's the structured query language. Essentially, it is a language that is how we structure databases. And how we query them is with that structured query language or SQL. That's going to be port 1433. And I mention that because in networking, you are going to come across databases. And as you progress in your networking career, it is important to understand the languages that we use. It's not all the languages out there. This just happens to be a relational database language. There are others non-relational. But we don't have to worry about that too much. But SQL is definitely, or SQL is something that is very important. So I decided to put it in the list, but I forgot to put it in the table. >> There was one other one in the list that I know I've heard of. I'm not really sure what it's for. SMB. SMB. >> Oh, I'm glad you mentioned that one. Boy, keeping me honest. That's right. Server message block. Server message block is the file sharing protocol for all Windows environments. So that is a very important one. Thank you for having my back on that one. That's port 445. Okay. And we do need to know that. So if I'm going to make a connection to, let's say, a shared folder in a Windows environment, if I were to add a packet capture utility, well, you might not see the application layer stuff, but it would be SMB that we're connecting to. In non--and now that brings up another one, thank you. In non-Windows environments, we're going to be using NFS, the network file system. So another protocol I want you to know about a couple right there at the end. Okay. And that's port 445, >> which is right near HTTPS, which is 443. So don't get that confused because I definitely would. >> I'm glad we were able to kind of go through these and get familiar with the port numbers. I noticed they're all--most of them are pretty early >> in the giant long thousands of thousands of ports. But it's good to know some of these more common ones. We won't have time to get into all thousands of them. Thank you for walking us through these, Wes, and thank you for joining us, and we'll see you next time.