The web site of jiawp

TCP/IP Networking for Developers

Module Introduction In this module, we're going to cover the very basics in networking. First, we're just going to take a logical overview of a network request and we're going to look at what happens when your web browser tries to get to a web page. Then we're going to look at basic client IP configuration. We're going to look at what an IP address is, how does a computer get an address, and what type of information about a network does a computer need. And then we're quickly going to talk about IPv6 - the next generation of IP networking.

Overview of Network Request Here's a logical overview of a network. On the left, we have a client that is going to try to reach the web server on the bottom right. So I'm going to walk you through the process of what's required to make this happen. By the end of this course, we'll have talked about all the pieces of this diagram and you will understand troubleshoot the various pieces. The first thing the client computer needs to do to reach the web server is convert the URL into an IP address. So, for example, if the web server we were trying to reach is Pluralsight.com, it needs to find out what is the IP address for Pluralsight.com. It does this with a service called DNS or Domain Naming System. So it reaches out to its configured DNS servers and asks it: What's the IP address for Pluralsight.com? The DNS servers go out finds that IP address and returns it to the client. Now that the client knows the IP address it needs to connect to, it will go across the internet, go out of its switch, through its router, out into the internet, eventually reaching the data center that the web server is located at, it's going to pass through a firewall and switches, and it's finally going to reach the web server. As it reaches that web server, it enters the networking stack of the operating system, there's usually a host based firewall that it has to traverse and then finally it reaches the process that's the actual web server. Then this process is reversed. The data is sent back to the client and the web page renders on the client machine.

Client IP Configuration Now let's look at the network configuration of a note on a network. First, we have the IP address. IP addresses are made up of four octets. So we have one, two, three, four. Next, we have the subnet mask. The subnet mask defines which part of the IP address is the subnet and which part is the specific note on that network. We'll get into what a subnet is later in the routing module, but for now, just know that if a IP address you're trying to reach is not part of your subnet, it has to go through the default gateway. And then we have the DNS servers that our computer will use to turn names into IP addresses. Now let's open the command prompt and run the command IPconfig. This command without any arguments will show me my basic network information. So we see we have my IP address, my subnet mask, and my default gateway here. If I run the command IPconfig/all it shows me a little bit more information. In fact, I'm going to run that again and pipe it to the more command. So now I can see, I have my host name, still have my IP address, my subnet mask, but it shows me things like my DHCP list, which we'll talk about in a little bit, my default gateway, where I got my IP address from, where I, where the DHCP server is located, so it gets a little bit more information about my IP configuration. If I go down one more page here, we'll also see, we almost missed it there, but it also gives me the DNS server that my computer is configured to point to. Now if you're running Vista or above, so it's Vista, Windows 7, Windows 2008, Windows 2008 R2, you may see some adaptors that you're not quite sure where they came from. So here we have ISATAP and the Teredo tunneling adapter. These come from IPv6 connectivity. We're going to talk about IPv6 in a little bit, but by and large, we can ignore these for now. So where did my computer get this IP configuration? Well, it got from the DHCP server, which is Dynamic Host Configuration Protocol. A DHCP server on a large network will be an actual server, like, you know, an enterprise environment, but at home, if you have one of those Linksys routers or NetGate routers or, you know, any of those, those home routers, it has a DHCP server built into it and it hands out addresses. The way this process works is when a machine comes online and it needs IP configuration, it sends out a broadcast message and says, hey, I need an IP address. DHCP servers will find those messages and will respond with an IP address and subnet mask, default gateway, DNS servers that this client machine can use. The client machine will receive that information, will configure itself, and will, then will respond to the DHCP server and say, okay thanks, I'm going to use that address, and it will know not to hand out that address anymore for a specified period of time. One thing you should be aware of is starting with Windows 2000, if a computer is unable to find a DHCP server, it will eventually give itself an address in the 169.254 address range. This is an address range owned by Microsoft and computers will self-configure themselves to use these computers. By and large, it's never used in the real world, but if you have troubles connecting to a network and you see your computer with this IP address, that let's you know that something is wrong, and for some reason, you're not able to get an address from a DHCP server.

IPv6 And now for the last topic in this module IPv6. Currently, we're on IPv4 or IP version 4, sometimes you'll hear it referred to as v4. It has an address space of 2 to the 32nd power. This sounds like a large number, but actually we're running out of IPv4 addresses right now. As we've already seen, an IPv4 address has the four octets. IPv6 has been developed to address this address space problem. It has an address space that's 2 to the 128th power, which means that every atom on earth can have a hundred IP addresses. Last June, we had World IPv6 Day, which means many of the large content providers like Google, Bing, Akamai, the large content providers turned on IPv6 addresses for one day, June 8th. They did this to see if there were any issues with having both an IPv4 and an IPv6 address for a given website on a large scale. The test went very well, so this June, on June 6th many of these same large content providers and more will be turning on IPv6 addresses forever. They'll still have IPv4 addresses also, but this is the first step in moving us towards IPv6 across the world. The address format for IPv6 is changed significantly. As a consumer of network services, there's really nothing you need to worry about as we make this transition to the v6. However, as a developer, if there's anywhere that you capture an IP address whether it's in a form or in a logging scenario, you need to be aware of this new address format and make sure your applications are able to handle this styled address.

Summary To review what we covered in this module. First, we took a logical overview of a network request and looked at what happens from web browser to web server. We talked about client IP configuration for a little bit, we looked at the anatomy of an IP address, how your client gets that address assignment, and finally, we looked at IPv6, which is the next version of the IP protocol.

Name Resolution Module Introduction In this module, we will discuss name resolution which is the process by which a computer turns a name into an IP address. First we'll discuss how DNS works, then we'll look at a tool called NsLookup that allows us to do name resolution. We'll discuss how DNS caching functions, we'll look at how the host file plays a role in name resolution. We'll look at the different types of records available on DNS and finally we'll look at wild card DNS records.

How does DNS work? Let's look at the name resolution process. From the bottom left we have our client. It's configured a point to a DNS server just like we talked about in the last module. In this case it's configured a point to this name server over here on the right NS1.ISP.com. And so when the client tries to look up an IP address for name, it's going to ask NS1.ISP.com to resolve that name for it. So if I'm a client machine, the user would browse www.sevans.info, the client machine would ask its name server "Do you know the address for www.sevans.info?'' Now the name server at my ISP is not going to know the answer for that, so the first thing it's going to do is go to the root name servers and ask "Do you know where www.sevans.info is?" Now the root name servers only contain the name server locations for the top level domains so it knows where the name servers are for dot com for dot net for dot US for dot UK for dot info et cetera, but that's the only things it knows. It doesn't know specific information about anything inside of those top level domains. So the root name servers know where the dot info name servers are. So when the dot info names servers are asked "Do you where www.sevans.info is?" The dot info name servers, they know where the name servers are for all the domains underneath the dot info name space. So for example they know where sevans.info is. If we were talking about the dot com name servers they would know where the name servers for google.com or yahoo.com or microsoft.com were. But they wouldn't know anything about those specific domains other than where the name servers are. So then the Sevans.info name servers are asked "Do you know where www.sevans.info is?" Now the Sevans.info name servers, they do know everything there is to know about the Sevans.info name space. Since they know the answer to this question, they respond to the original name server with the IP address of www.sevans.info and that info is information that's passed back to the client. Now I cheated when I drew the slide, I make it look like the original name server NS1.ISP.com reaches out to the root name server. And the root name server reaches out to the dot info name server and so on. And in reality what happens is name server one goes out to the root name server and it responds and then my original DNS over here goes to the dot info name server and it responds. And then the original DNS server reaches out to the Sevans.info name server and it responds. That original name server is responsible for the entire communication path, if the root name servers or the name servers with a topple of domain names had to pass along all these information and then route it back, it would be a tremendous load on the system. The thing to remember about how name resolution works is that every step along the way has a certain piece of a puzzle, and it gets-- you have to get closer and closer to the final answer before you get the actual question you were originally asking.

nslookup Now let's turn to the command problem and learn how to use a tool called NsLookup. NsLookup allows you to do DNS queries from the command line. There's two modes you can use it in, you can do NsLookup a space and then the name you want to lookup, so let's for example look up parolesite.com and I'll get my response or I can type NsLookup hit enter and then from here, run queries. So all we do is we type in the query and it returns with a response. Lets do some more, so if we do microsoft.com we'll see that it returns with two different addresses. This means that there are two different IP addresses that we can reach microsoft.com at. Let's look at www.mircrosoft.com; here we see that we have aliases so www.microsoft.com has been aliased to these ACOMI addresses. ACOMI is a content distribution network that microsoft.com must be running of. When we're done using NsLookup we can just type exit and that will pull us back to the command line. One other tip if we're going to NsLookup we can use a command server and then the name or IP address of a different DNS server we want to query off of. So for example I know that there is a DNS server at 129.65.16.254 so that changes to a DNS server at a university here in California and now I can run queries off of their DNS server. This is going to be useful to see if you're getting different responses from one DNS server than another DNS server.

DNS Caching One important concept of DNS is caching, all records are cached for some period of time, this includes the DNS server that you're querying of it will cache that information. So if other servers query at the same record it will quickly return the information and your local machine also caches this information. So let's populate our cache by pinging some different records so it's ping microsoft.com lets ping plural site.com and let's ping Sevans.info. I'm going to clear my screen and then lets run the command IP config/display DNS. This shows me all the records that are cached on my local machine. So here we see we have the record plural site.com cached for a period of 3200 seconds roughly. If we were to run IP config/display DNS again, scroll back up to Pluralsite, we'll see it's reduced down to 32/44 so as time goes on this number will tick down till zero when we'll get flushed out of the cache. If we look at sevans.info we see that's it's cached for a longer period of time, 4400 seconds. This is something to be aware of when changing DNS records you can make a change to a DNS record but we'll take some time to propagate it around the internet because the old answer will be cached in various DNS servers and clients. ( Pause )

Hosts File On the individual machine you can override DNS by using the host file. The host file is conveniently located, at C windows system 32 drivers etc. And it's a file called host now it's not host dot text it's just host with no extension, so every time you try to open it you'll need to specify that you want to open it with a text editor. here I'll just use notepad. To add an entry to the host file you use the format IP address you want to override it with so I'm just going to say local host which is 127.0.0.1 that's always the local machine and then the tab and then the name that you want to override. So I'm going to try to type in site 2.com add a tab I'll do site1.com or www.site1.com and you can also have multiple lines so you do www.site1.com down here and just to show what's-- what it's capable of. We can put some made up address there for let's say Sevans.info. I'm going to save that file, I'm going to come back here, I'm going to look at my cache, my DNS cache. So it's IPconfig/display DNS again and we'll see that-- the records I looked up earlier have been cleared out because when I changed the host file it clears the cache and then populates it with what's in the host file. So we see all those entries we just put into our host file are already pre-populated in the cache. Now if I were to ping lets say site1.com, we'll see that it's going to respond with the local host because that's what's specified in my host file. If I ping Sevans.info it's going to turn that made up address I gave it. This can be useful if you're migrating for example a web server from one IP address to another, you can set up your new server with its new IP address and then in your personal machine set that new address in your host file for its URL, in that way you can make sure everything is working properly before you change DNS and point all traffic across the internet to it. Just remember that when you're done testing, that you remove that line from your host file to avoid confusion in the future.

DNS Record Types Now let's go back to NsLookup and talk about record types. All the queries we've seen so far are by default, record types A. A is the record type that turns a name into an IP address but there's other types of records. For example, let's first talk about name server records. So first in NsLookup to query for something other than an A record we use the command set type equals in this case NS for name server. Now if I look up pluralsite.com it's going to return the name servers that are responsible for the pluralsite.com name space. So we see here there's two name servers, and so in the name resolution process, I will-- my computer will randomly pick one of those to query. Let's look for, let's look at microsoft.com, we'll see here they have 5 name servers NS1.MSFT.net through NS5. So in the name resolution process one of these 5 will randomly get picked. There's other types of records, lets do set type equals MX, MX stand for mail exchange. So let's look up microsoft.com and we'll see here if you're sending mail to microsoft.com you're going to send it to mail.message-- messaging.microsoft.com so that's who will accept mail for the microsoft.com name space. Let's look at Sevans.info and we'll see that mail sent to Sevans.info goes through ESPMX.L.Google.com 'cause I host my mail at, on Google on G-mail. Let's look up pluralsite.com's MX record and we'll see they have multiple records. This MX preference means which order should I try this in the mail to, first MX record of one try that one first if that fails then try the next higher level et cetera. Another record type is C name or canonical name think of it as an alias. So if we look up microsoft.com there is no C name we can't have a C name on the root of our domain but www.microsoft.com they have alias to an ACOMI address. So when you go to www.microsoft.com on your web browser via the DNS process you actually end up going to a server, an IP address owned by ACOMI network. One last record type to look at is a quad A record so set type equals AAAA so four As. This is an IPV6 version of an A record so this is going to turn a name into an IPV6 address. If we query Sevans.info, we see that we get a IPV6 style address because Sevans.info has both an IPV4 and an IPV6 address. There's other record types but these are by far the most common ones you'll run into.

Wildcard Records There's one more record type I want to talk about which is a wild card record, wild card record will return a certain IP address for any do-- for any name under a certain domain name. So for example I have a domain, localdev.us. If you query localdev.us you'll get the IP address for the website. If you do www.localdev.us you'll also get the IP address for the website. Any other query under the localdev.us name space overturn local host. So for example clientname.localdev.us overturn 127.0.0.1 or the local, local account. This allows developers to set up their local IIS configuration using host names to grab certain name spaces without having to set up DNS records. So you can have client1.localdev.us, client2.localdev.us. By using those names it goes to the appropriate IIS site without having to configure DNS. Another place where wild card records come into play is certain ISPs will capture any failed DNS query and return the IP address for their own site. This way if you were to mistype a name into your web browser it will redirect you-- you'll end up getting directed via DNS to their web server that will usually show some type of adds in it. It's a revenue-generating system form. It can be quite annoying and there's really no great way around it other than using your own DNS servers. But something to be aware of and they're doing that via the wild card record type.

Review of DNS Trace Now let's tie together all these things we've learned about DNS, here I have a pack of trace of my computer doing an NsLookup on parks.ca.gov. We'll talk about packet traces on a later module but for now you just need to know that this is the log of everything that happened on the network. In the first line, we have my computer, ASCUS DNS server, what the record, what the address for parks.ca.gov is, and it's looking for record type A. In the second line, the DNS server goes and ask the root name server "do you know where parks.ca.gov is?" It's asking for an A record. In the third line, one of the root name servers responded and said-- basically it's saying, I don't know where parks.ca.gov is, but here are all the authority of name servers for dot GOV and you can see there that name server type records and here is the locations of those name servers. It also includes the additional records of all those name servers and their IP addresses. So we can see that is one of the name servers for the dot GOV name space. We also see its TTL is listed as 2 days. Generally speaking the higher level the domain, so the root name servers, the top level domain in name servers have longer TTLs than A records down at the very bottom. So then my DNS server goes and queries one of those dot GOV name severs and ask it, a question it's been asking this entire time, "do you have an A record for parks.ca.gov?" When the dot GOV name servers responds with the authoritative name servers for CA dot GOV. So it passes along the name servers for the CA dot GOV name space and see there's 3 of them, here they are, and also returns those addresses for each of them. Then my name server goes and asks the same question, do you have an A record for parks.ca.gov? Now at this point, the CA dot GOV name servers could have the A records for parks.ca.gov. The reason I chose this example is parks.ca.gov is actually split out into separate DNS servers in the root of CA. dot Gov. So the CA dot GOV name server responds with, here are the 3 name servers for parks.ca.gov. We then go ask one of those name servers the exact same question again, when the parks.ca.gov name server is actually authoritative for parks.ca.gov so it has the A record and here is the record we've been looking for this entire time. We can see here that its TTL is only 1 hour, so I'll be able to cache this information for 1 hour before I have to ask again to make sure that the information has not changed. My DNS server then returns that information to the client computer that originally asked the question. One interesting thing to note from this process is that although it took a long time to walk through it manually, it only took 0.3 seconds for that entire transaction to take place. Now remember, all this information was cached and to show how that works, I did the exact same query again just moments later and I did a packet trace and here we can see that my computer asked its DNS server that exact same question, do you have the A record for parks.ca.gov? And my DNS server was able to immediately respond with the answer because it already have that information cache. You notice the TTL on this is only 59 minutes and 27 seconds because 33 seconds have passed since it originally got that information. And actually, to even make this happen, I had to clear the cache on the computer that was originally asking this 110.51 I cleared its DNS cache before I made this query otherwise, it would have already have that information and we have seen nothing happen in the packet trace.

Summary Let's review what we've covered in this module. First we took a high-level overview of how the DNS system works. We talked about how to use the tool NSlookup to do queries on the DNS system, we talked about how DNS caching works and TTLs, we looked at how we can use the host file to override the values of DNS for a local machine, we looked at the different DNS record types like NS records, A records, MX records, Quad As, we talked about how wildcard records work and what we can use them for.

IP Routing Module Introduction In this module, we're going to learn how traffic gets routed from one network to another. First, we're going to look at what IP routing actually is. We're going to look at tools called Tracert and PathPing to observe this routing take place. We're going to discuss subnets and subnet masks. We're going to discuss route tables and the role they play in routing. And then we're going to talk about network address translation. And lastly, we're going to discuss how private network ranges along with NAT are used to conserve public IP addresses.

IP Routing Overview and Troubleshooting First let's discuss the purpose of IP routing. We have these subnets represented by these green ovals. In a bit, we're going to talk about what a subnet is. For now, it's a collection of computers that can talk to each other without needing to go through a router. A router connects different subnets where routes traffic between different subnets. So whether this computer here on the 10.18.164.0 subnet wanting to talk to a computer in a 10.18.165.0 subnet or computer in this 10.18.164 subnet wanting to talk to a computer in a 10.23.85.0 subnet, the traffic is going to pass through one or more routers. We're going to talk about how subnets are defined in a little bit. But first, let's look at some tools where we can watch IP routing happen. So let's open up a command prompt and the first that we're going to talk about is Tracert and that's spelled T-R-A-C-E-R-T. So to get started, I'm going to run a Tracert on either a name or an IP address, I'm going to the Tracert to Pluralsight.com. So this is going to determine what the route is, what the series of routers this traffic has to pass through to reach Pluralsight.com. It's I'm going to take some measurements on how long each hop takes. So we see that we're passing through 10.0.1.1, that's my local router connected to my cable modem here, then it passes through some unknown IP address and then you can watch it geographically move. First it goes through a comcast router here in San Jose where I'm currently located then it passes through Oakland, Sacramento up to Seattle over to Denver and then we see it pass through some unknown locations here and eventually it reaches a network called ViaWest, looks like it's located in Denver region. And so we can see here are all the hops that our traffic had to take to get from my current location to the Pluralsight.com web server. These numbers here in milliseconds represent how long each hop took. In we're having some type of routing issue, we might see extremely large numbers or even time outs on various hops along the way. Now, if we were to find a link that was bad, there's really nothing we can do, especially as a developer but even me as a system's engineer, the routing happens by, you know, high level network professionals but it's just good to be able to diagnose this information and it can give you a possible clue to possible issues that are happening. Let's take another Tracert. I'm going to take a Tracert to sevans.info, just so we can see a different path across the internet. So here we start off with my local router, through San Jose, Oakland, Sacramento down to Los Angeles and into a network owned by DreamHost where I host my website. So we can see much fewer hops, lower route times, so slightly better performance. But when you think about this geographically, we're going from San Jose to Los Angeles, a distance of about 400 miles, compared to San Jose to Denver, a distance of, I don't know, couple of thousand miles. So this brings up one interesting point. If you have traffic, a lot of users that come from say Europe, you may want to place your web servers on the East Coast of United states so that it's geographically centrally located between your Western United States and European customers. So Tracert is helpful, it gives us a snapshot in time but there's another tool called PathPing that can give us slightly more detailed and robust reporting. So I'm going to run PathPing with the exact same arguments. So let's do PathPing to Pluralsight.com. And so it's going to find that same route again. Now if you're doing the same demo at home, you're going to find different routes. Routes change throughout time and also from your location, you're going to have different-- you're going to have a different route from wherever you're located compared to where I'm currently located. So here we are, it finds the exact same route. And then it's going to perform a series of tests on these links over a long period of time. So it's actually going to hit every single link a hundred times and then report on some statistics. So we see here, it's going to take 400 seconds for this test to complete. So it's going to take longer, but it's going to give us more reliable on accurate results. ( Pause ) So here we are, through the magic of editing. I turned that 400 seconds into a 4 seconds. And here, we have our results. If we scroll up to the top, we see it shows us which hop it was, the roundtrip time and the number of lost packets at sent out of a hundred. So it lost 0 packets of the 100 it sent and that's true all the way down the line. So we have a nice healthy connection here. So we've had 0 lost packets. So this is exactly the-- this-- what we-- you should expect to see in a nice healthy connection.

Subnets So now we've learned that routers route traffic between different subnets but how is a subnet defined. A subnet is defined by a combination of the IP address and the subnet mask. Here we see we have an IP address, 192.168.114.230 with a subnet mask of 255.255.255.0. The subnet mask has 4 octets just like an IP address. It's called an octet because it's 8 bits. So the first 3 octets of the subnet mask have 8 bits turned on. 8 bits in binary is 255. So we see here that when the bits are on, that represents the network or the subnet, when the bits are off, that represents a specific note on the subnet. Here's another example, where we have the same IP address but a subnet mask of 255.255.0.0, when the subnet mask's bits are on, it represents the network, when it's off, it represents the specific note on that network or subnet. So let's look at subnet mask in detail. Here we have a subnet mask of 255.255.255.0. That breaks into 3 octets, the bits being on and 1 octet of the bits being off, so we have a total of 24 bits that are on. So we can represent this as a hypothetical network, 192.168.12.0/24 because we have 24 bits of the subnet mask on, or 192.168.12.0/255.255.255.0, or the range of possible IP addresses is 192.168.12.0 to 192.168.12.255. So if a computer on this network was to send traffic to anything inside of that range, it can reach it directly there on the same subnet. If it's trying to reach an IP address outside of that range, it needs to go through its default route. Let's look at another example. Here we have a subnet mask of 255.255.0.0, so we have the first 16 bits on, second set of 16 bits are off. So we have a hypothetical network of 192.168.0.0/16 or 192.168.12.0.255.255.0.0 or a range of IP addresses going from 192.168.0.0 all the way to 192.168.255.255. Now the subnet mask doesn't always have to be a clean break like that. Here we have a subnet mask of 255.255.254.0.0 so that's 8 bits on, 8 bits on, 7 bits on, 0 bits on. So that's a 23-bit subnet and the range of possible IP addresses expands to class C networks. So it goes from 192.168.12.0 to 192.168.13.255. So it combines what you would normally think of as 2 different subnets. And one more example, this one's 255.255.255.240, so here we've taken what we normally think of as a clean subnet and broken it up into smaller pieces. So here we have the first 3 octets are all on and that last octet has 4 bits on and 4 bits off, so this is a slash 28 network. We look at the range of possible IP addresses, it goes in this hypothetical situation from 192.168.12.16 to 192.168.12.31. So this is a subnet that's extreme-- very small.

Routes So now we understand that routers route traffic between subnets. We understand how a computer can determine if an IP addresses on the same subnet or on a different subnet. But what-- how does a computer determine how to reach other subnets? This is defined by the route table. So here I have a very simplified route table. In the first row we see that if the destination is 0.0.0.0 and the subnet mask is 0.0.0.0, this means any IP address, it's going to use a gateway. In this example, it's 192.168.114.1, this is going to be the default route or the default gateway on my subnet. But when traffic's being sent, it's going to look for the most specific match possible. So on the second line we see a destination of 127.0.0.0 with a 8 bit subnet mask with 255.0.0.0. The 127 network is always the local host. So 127. anything to my local machine. So you see the gateway there is on-link, meaning it does not need to go through a default route because it never leaves the physical computer. The third line we see a destination of 192.168.114.0 with a 24-bit subnet mask. This is the subnet that the computer is currently located in. So again, it doesn't need to use a default route or the gateway, it can use on-link, it just needs to send directly to that destination IP address. And then this fourth row is a special entry. This is for a broadcast. This is when we're going to send traffic that's destined for anything on my subnet. Broadcast don't cross routers. So we do not see any need to send it to the default gateway, we just broadcast it out to the entire subnet. Let's open up a command prompt and let's actually look at a route on this computer. So we use that with the route command. If we type route, we get the instructions. There's really only one command you need to be familiar with and that's "route print". That's going to print my route table. Now it's possible to add and remove items from the route. Generally speaking as a developer, you'll never going to need to do that. So let's scroll up a little bit and here we have our IPv4 route table. So we see we're going to recognize a lot of these entries from my PowerPoint slide before. Here we have network destination of 0.0.0 and net mask of 0.0.0. So this kind of have to go through my gateway 10.0.1.1. On the interface, 10.0.1.11, that's my current IP address. This last entry is the metric. It's going to go for the lowest metric possible. It's possible to have 2 different default gateways and it will go through the lowest metric, the lowest cost possible. And we can see there's going to be other entries in here that we'll be familiar with, 10.0.1.0 with a 24-bit subnet masks on-link, that's my local computer, and different representations of the same thing here. We also have an IPv6 route table which has become a lot more important to us as we start to have IPv6 connectivity. So how does it know the gateway is 10.0.1.1? That comes through the network configuration. By doing "ipconfig", we'll see that one of the things that's defined is the default gateway. So any traffic that's destined for another network goes through my default gateway, just 10.0.1.1 in this case.

NAT and Private IP's One more note on routing, in IPv4 we have 3 network ranges that are for private use only, meaning they're not routable on the public internet. The way this works is let's say at home I have a phone, a computer, a laptop, other devices but for my ISP, I only get one public IP address because there's quite-- there's a shortage of them. As I mentioned, we're running out of them. So my ISP gives me one IP address and then internally, I use a lot of these private IP addresses. And then a process called NAT or network address translation takes these addresses as they exit my house, exit my router and converts them into this external IP address and as a traffic comes back, it converts them back to the correct internal IP address. One thing to be aware of is if you want to host any services on the internet, you need a public IP address. Even the cheap home routers like the Linksys routers, the Netgear routers, et cetera have the ability to say a certain port coming into my public IP address will get routed to a specific address internally. So for example, if on your work station you wanted to host a web server, you could say any traffic destined for each-- for port 80, which is what HTTP transports on, to route it to this IP address internally. But you couldn't have port 80 mapped to 2 different internal IP addresses. The 3 network ranges that are for private use only is 10.0.0.0 with a slash 8 subnet, 172.16.0.0 with a slash 12 subnet and 192.168.0.0 with a slash 16 subnet.

Summary In this module, we learned what IP routing is, we looked at using the tools Tracert and PathPing to diagnose and troubleshoot routing issues. We looked at subnets and subnet masks and learned how to define what a subnet actually is. We looked at a route table and how that's used to determine how to route traffic around the internet. And then we looked at what network address translation is and the role it has with private network ranges to conserve public IP addresses.

Port Connectivity Module Introduction We've talked about how to resolve a name to an IP address using name resolution. We've talked about how routing works and how to do some basic troubleshooting. So now, let's talk about port connectivity where the ability to connect to the process we want to talk to on the server side. In this module on port connectivity, we're going to compare TCP and UDP to transport layer protocols. We're going to test port connectivity or we're going to see if we can connect to the process we're trying to connect to. We're going to see how port scanning works to be able to show us which services are available on a box. We're going to discuss firewalls and how they play a role on port connectivity. Then we're going to talk about network address translation.

TCP and UDP ( Pause ) The Translation Control Protocol or TCP is the most common transport layer protocol by far. Almost all the web's traffic runs over TCP. This includes HTTP traffic, mail traffic, et cetera. On the left side, we have our client computer or our sending computer. And on the right side, we have our server or our receiving computer. So the sending computer is going to establish a session with the receiving side. The receiving side is going to establish that session is going to say, "Okay, I'm ready. Send me some data." So the sending computer is going to send several data sets. So in this example, it sends data set one, data set two, and data set three. Let's say data set two goes missing, for whatever reason somewhere along the way it just disappeared, which happens, it's areal life scenario on the internet. The receiving computer will confirm receipt of the data sets. So, it will say, "I received data set one and data set three." After a time out period, data set one will realize that data set two was never received since it never received confirmation. So it will automatically resend data set two. The receiving computer will confirm that data set two was received and now the receiving or the sending computer will know that the entire data set was received by the sending side. All that happens automatically by the networking stack, your application knows nothing about this process. Let's compare this to UDP or User Datagram Protocol and then we'll discuss the pros and cons of the various-- of each protocol. So in UDP, the sending computer does not establish a session first. It just starts sending data. Here's data set one, here's data set two, here's data set three. Again, let's say data set two goes missing for whatever reason. The way-- what will happen next is the sending computer will send data set four, data set five, data set six. In the transport layer protocol, there is no built-in mechanism to resend lost packets. UDP is great if it's okay to be missing some data. Video conferencing is a great example. Let's say data set two represented second two in a video conference. By the time that TCP would realize that data set two is missing and the sending computer resent that packet, we would already be several seconds down in the conversation. So taking that second of the video conference and replaying it five or six seconds later would be completely inappropriate. So UDP with the lower overhand, there's not-- all the overhead of the session's process is much more efficient, so it's better for something like video conferencing. Usually, we care about the data. We need all the data, so TCP is the preferable choice. Web pages are a great example. If it takes three data sets to transmit a web page to your computer, you can't have one of the data sets missing and still be able to render the page.

Testing Port Connectivity ( Pause ) Let's turn at the command line and test port connectivity. Now, we can only test TCP connectivity. With UDP, all we do is you just send some data, and we hope that it's received. There's never a session established. So it's really hard to determine if the UDP port is available. But with TCP, we can create that session and see if we're able to successfully do so. We're going to test TCP connectivity using the Telnet Command. The Telnet Command simply just connects to a service and then expects you to write the commands, for example, a web browser would. So we're going to use Telnet space the name or IP address that we want to connect to. So we're going to use Pluralsight.com and then the port number we want to connect on. Since HTTP runs on port 80, we'll try to connect to port 80. So it's Telnet Pluralsight.com80. So we hit Enter and here we have successfully connected to the Pluralsight.com web server. Now, unfortunately our sign of success is this blank screen. What's happening right now is the Pluralsight.com web server is waiting for what it assumes as a web browser to say what it want-- what I want. So, it would expect me to issue a HTTP GET command and pass the appropriate parameters. And then it would return whatever I requested. But it's just sitting here waiting for me. I'm going to hit Ctrl C to exit out. And it's going to send back a HTTP 400 error, bad request. So, what's happened here is, you know, it didn't understand what I was saying and so it's responding and saying, "I don't know what that was, that's a bad request," so it sends back an HTTP 400. In fact, you can even see the HTML page it sent back that it would expect a web browser to, you know, format and display it for me. But, we prove that we are able to connect to IIS, we're able to prove that we are able to, on that IP address, connect to port 80 and that's all we're trying to prove right now. So let's try another example. Let's connect to Pluralsight.com on port 81. Now, there's nothing listening on port 81 on the Pluralsight.com web server. So, we're going to try to connect and right now what's happening is the networking stack of the operating system is trying to establish that connection. So it is sending out a session request on port 81. And it's making it over to probably the firewall on the Pluralsight.com network and that firewall is not allowing it. We're going to talk about firewalls in a bit. But even if the firewall wasn't there, it would make it to the operating system and there would be nothing listening on that operating system. So, it would-- there would be nothing to connect to. So eventually we get this response that connecting to Pluralsight.com, it couldn't open a connection to port 81, so that's our-- that's our sign of failure. Let's use another example. Let's connect to-- I have a machine on the network here called Pluralsight02. Let me ping it. I'm sorry, Pluralsight02, not dot com. Let me get that mouse cursor out of the way. And so we can see it's a machine here in the local network and it's-- it happens to be running SQL. So I'm going to connect to Telnet Pluralsight02 on port 1433. 1433 is the standard port for SQL Server. So we're connecting again. We get this blank screen. So it's expecting me to issue whatever a SQL client would normally say at this point in the conversation. I don't, you know, know what that would be. And this is the service I can't figure out how does it exit out off gracefully. So in this case, we're just going to have to close the window and open up a new one. Let me do one more example which is connecting to a mail server. So mail servers issue a banner message when you connect to them. So, I just want to show the example of when it will actually display something for you. So we're going to go back to our name resolutions skill set we learn. And we're going to look up a mail record for-- let's just look up for gmail.com, I'm pretty confident that will be up. I'm going to exit out of that, so now we know where Gmail accepts connections on or accepts some mail on. So let me expand this window a little bit so we can get it all. So here is the server that accepts mail for gmail.com. So we're going to Telnet to that name on port 25, so SMTP or mail traffic is on TCP 25. So we're going to connect to that and I get this banner message. So 220, name of the server, ESMTP which stands for Enhanced SMTP service and so now it's expecting me to issue the mail commands that would send the mail. I'm not going to go through that process. I'm going to say quit and I exit out of that process. So, let's clear the screen. So Telnet's great if we're-- we know that specific port we want to connect to. But let's say we have a machine and I'm not exactly sure which port a specific service is running on. In that case, we could port scan the server. So, I'm going to use a tool called Nmap. So Telnet's built-in to Windows and in most operating systems. Nmaps are free open source utility, you can get it from nmap.org and it does port scanning for us. So, I'm going to Nmap and if you run it without commands, it will give you the help file. But we're just going to do nmap-v for verbose, that's just going to make the scan more interesting, the demo more interesting. And then I'm going to port scan that server I talked about earlier, Pluralsight02 that's running IIS SQL Server along with some standard Windows services. So I'm going to start that scan, so it's going to reach out cross and it's going randomly try to connect to various TCP ports and then let me know the ones it was able to successfully connect to. So we see here it connected to these ports successfully. And when possible, it gives us the name of that service or the assumed name of that service. So 80 is probably HTTP 135 and 445, that's used for you know, Windows File Services, 1433 is my Microsoft SQL Server. And then we have this port 49154 which is unknown, it's not really sure what that port is. So again, this can be helpful if we just need to know the list of services available on a box, we're not really sure exactly what's available on a particular server. And then the last thing I want to do, and clear the screen again, is connect to or see which ports, which processes are listening on which port. So I have an executable here, all it does, it's a .NET application. All it does is listening on port 3000. So I want to us-- I want to determine which ports my machine here has open and which processes are listening on which ports. So I'm going to run the command netstat-ANO. So this shows me all the listening ports. So we can see there's a whole host of them here. The 0.0.0.0 means it's going to listen on every IP address that's available on this machine and that will list the port's numbers. And so we can see that right here, we have that port 3000, okay? And if we slide over a bit, we see that port 3000 is being listened to on process ID in 1944. Now what we can do is open up the task manager and sort by process ID. Now by default, process ID won't be available, so the way you can add that to the list is you go to view select columns and select process ID. So I'm going to sort by process ID. So what was the number again? 3000 is process ID 1944, so we can come down here and see that process ID 1944 is this listen on port.exe. If I had SQL Server running on this box, over here we would see port 1433, we would see a corresponding process ID and we'd be able to find the SQL Server service executable listed on the-- in the process list here. So that can be really helpful if you have open ports and you're not exactly sure why they're listening or you're trying to add a new service on a certain port and that port is already being used by another process and you need to figure out where your confliction is there.

Firewalls ( Pause ) Firewalls are a common cause of port connectivity problems. Let's look at what a firewall does. A firewall determines what connections are allowed in to the operating systems and which ones are not. So for example, this firewall is allowing port 80 or HTTP traffic into the operating system. The firewall have a set of rules that says what traffic's allowed in and what traffic's not. Whereas if other traffic where there's no rule that defines the traffics allowed in comes to the firewall, the firewall will not allow it through into the operating system. So for example in this case, port 25 or SMTP traffic, there's no rule, it will not allow it through the firewall. I'm going to open the Windows firewall with advanced security. So this is the firewall that's available in Vista or above, so it's Vista, Windows 7, Windows 2008, and Windows 2008R2. And I'm going to show how to create some rules and how to manage this firewall. So the first thing we see is the status of the firewall. I'm going to come here to Windows firewall properties. And we can see that we have domain, private, and public profile. Depending on the state of Windows, rules for these various profiles will be used. I generally recommend you set them to the same unless there's a specific reason why you wouldn't want, for example, when you're connected to your domain in your enterprise network to have different rules than when you're at home. Generally for a developer, you're going to want the same rules across the board though. We see we can set the firewall state, by default it's on. And by default we block inbound connections, so traffic coming into our machine and we allow any traffic going out. So any traffic that originates from our machine. And another thing we can look at, and this can be useful, is to turn on logging. So by default, no dropped or successful connections are logged. If we think we might have an issue with the firewall dropping a packet, it could be useful to come in here to log drop packets and change that to yes. And then wherever you specify by default it says pfirewall.log inside the Windows folder. It will log those connections, so you're able to see if the Windows firewall is dropping packets that are inbound to your machine. Now let's look at rules. I'm going to come to my inbound rules here and you see there's already a bunch defined. This is just out-of-the box, the default list of rules that are available. We're going to add some additional rules. So we're going to right click inbound rules and say new rule. You can see in this wizard we have four options, create a rule by program, port, a predefined set of rules, or custom. Let's start with program. A program rule says that a specific executable, whatever port it's trying to listen on, we can allow those ports in. So for example, I'm going to use my listen on port executable that we used in the previous clip and then it's going to ask you, I want to allow the connection? Allow the connection if it's secure or block the connection. Generally, you're going to allow the connection 'cause you're blocking all traffic by default. You allow the connection if secure, that entails having a what's called an IPC-- IP set connection between two computers. It's not commonly used by developers, so we're just going to ignore it. We're either going to go with allow a connection or block the connection. And since we almost always are going to block the traffic by default, all we're going to do is create rules to allow specific traffic in. So we can almost always leave this and allow the connection. Then I ask which profiles do we want this rule to apply to. We're going to use the same rules in every profile, the main private and public so we're just going to leave all three boxes checked, and then we give it a name. So in this case, we're going to call it TCP Listener Process. Click Finish, I'm going to close my PowerPoint. And we're going to see we have up here the TPC-- TCP Listener Process. Now when this process starts, whatever ports it opens to listen on, the firewall will allow that traffic through. This can be really handy for applications that use multiple ports and it's sometimes difficult to know which ones need to be used. This allows you to just say, this process, this specific executable, allow whatever traffic it needs, and it simplifies the firewall rules for you. Let's create some more rules. Now we're going to create one by port. So in this case, let's come in, we're going to do a TCP port and we're going to specify-- we can choose between TCP and UDP, we're going to choose TCP, we can say all ports, which we probably don't want to do, and we can say-- specify the local ports. So, I'm going to say port 80,443. So this will allow HTTP or HTTPS traffic. We say next and again we're going to allow the connection, domain private public, give it a name, so this is going to be HTTP slash HTTPS RULE, say finish and now we have a rule that allows HTTP and HTTPS traffic in. So this would be a rule you'd want to set on your web server. Let's do another type of rule. Let's do a predefined rule. So here we have a bunch of predefined rules. This list is populated by the-- those services that have been installed on your-- the Windows services that have installed on this particular machine. I'm going to come down here to remote desktop so that's, you know, RDP or remotely connect to a computer. I'm going to use a predefined remote desktop rule. We'll see that it's the inbound rule, you know, kind of specifies a rule set for us. It's going to allow TCP 3389, that's the port used by T-- by remote desktop protocol. So it just gives us a predefined set of rules. Let me go back and find a more complicated one. Let's use routing volume management. It's going to have several rules that it needs. So this just allows for the more complicated services that Windows provides to kind of have a predefined set of rules and make it easy for administrators to add those rule sets. So we added the remote desktop rule. Then lastly, let's look at the custom rule. So the custom rule is going to give us a lot more options, where in here we're going to choose all programs. Let's come down to the protocol type. So we've talked about TCP and UDP, but there's lots of different types of protocols. There's one we haven't talked about called ICMP. This is what the ping protocol uses. So when I ping another computer that doesn't use TCP or UDP that actually uses ICMP protocol. So I'm going to select ICMP. I could even come in here and specify specifically what type of ICMP packets to allow. I'm going to allow all of them. We can specify which local IP address does this rule that apply to, we're going to apply to any of them. And where do we want to allow this traffic from? We're going to-- for now we're going to allow it this is from anywhere. We're going to look at this in further detail in a second. We're going to allow the connection, all of our profiles again, give it a name, I'm just going to call it ICMP, but let's put ping in quotation marks there 'cause that's the common-- that's the most common use of ICMP traffic, finish that and there we have our ICMP rule. So let's look at this remote desktop rule. Let's go into the property zone and we can further define this rule. So, it's on the system program, that's what RDP runs under. We can say which computer is authorized from; this would only be used in the domain type environment. We can say which users are allowed to use this, again, most likely in the domain type environment. Here we specify which profiles it applies to, but here's the one I really want to get to is the scope. So here, as you looked at earlier, we can define where the traffic's can be allowed from, which remote IP addresses this rule applies to. By default, it applies to any IP addresses. That may be an appropriate rule for say a web server with HTTP traffic. But for RDP, maybe we only want to allow it from the local subnet. So, I can say from these IP addresses, then I can specify a network range. Or I can use a predefined set of computers, so default gateway, my DNS servers. Here's an interesting one, the local subnet. So going back to our routing module, we can say computers are on the local subnet that don't need to go through a router, they're allowed to connect to this service. We could also say there's another subnet, let's say it's 192.168.16.0/24, we want to allow computers from that subnet to connect to this service. So we can define the scope of this rule and narrow it down to just these-- the subnets that we need to allow it from. And click okay and now that rule has been modified.

NAT and Private IP's ( Pause ) The last thing we're going to cover in this module is Network Address Translation or NAT. What NAT allows us to do is have multiple internal IP addresses or private IP addresses and have them translated to a single external public IP address. Public IP addresses are scarce and expensive. A home ISP is only going to give you one IP address even though any modern home has multiple devices behind that. Even in a business environment, you're going to have a lot of computers that don't need public addresses. They don't need to be accessible across the Internet. So what NAT allows us to do is take these addresses, translates them to a single external IP address. And then the NAT device in a home environment, it's usually your router, your Linksys or Netgear router or anything on those lines, that translates those sessions back and forth between the internal and external addresses. One side effect of this is, is if we were running any type of service we wanted to have reachable in the internet and let's say your-- a work station in our home, the incoming traffic to our external IP address is not going to be able to route to that internal IP address unless you set up a specific net rule on your home, you know, on you routing device that says any traffic inbound for this-- for my external IP address, route to a specific internal IP address. Or on your internal or on your routing device, you can say traffic destined for this specific port, route to a specific internal IP address; and any traffic destined to its other specific port, route to a different IP address. This can be useful if you want to host a website off of your home ISP connection. Or let's say you want to be able to RDP to a specific computer in your house. But you're not going to be able to have multiple services on different computers internally come in on the same port. So you can't host a web server on two different devices and have them both use port 80. Now the easiest way to find out what your external IP addresses is, is to switch over to a web browser here, is to use a service at www.whatismyip.com. You go to this address and it's just going to tell you what your-- what the IP address that you're coming from is. So this is a quick and easy way to find out what your current IP address is.

Summary ( Pause ) In this module, we learned about port connectivity. First, we compared the differences between TCP and UDP and learned the strengths and weaknesses of both of them. Then we learned how to test port connectivity using the Telnet command. We did some port scanning with the Nmap tool. We looked at firewalls and what they do and we looked at how to add rules to our Windows firewall. And then we looked at Network Address Translation and the role it plays in port connectivity.

Network Capture Module Introduction Steve Evans: In this last module, we're going to look at network captures. Network captures are tools that allow you to look at traffic going across your network card and you're able to view in parts that data. First, we're going to use a tool called Wireshark to take a packet trace of any arbitrary network data. Then we're going to look at a tool called Fiddler, which is specific to http traffic.

Wireshark Here, we have the tool Wireshark. It's a free open source network capture tool, so it allows us to capture any traffic that's happening on a network card and then view in parts that data. Wireshark used to be called Ethereal, I'm not even sure that's how it's pronounced and that's largely why they changed the name of it to Wireshark. So you get started and come up here to the Network Capture icon and I'm going to select which network card I want to run a trace on. I'm just going to say Start on the only network card I have on this machine and pretty soon here we're going to start seeing some stuff happen on the network. Now on every computer, there's some background stuff that happens, different machines are talking to each other, just sorting out who's on the network. So here we see, we saw some DHCP traffic and usually there's going to be a little bit more than this. I'm on a fairly isolated network for the demonstration purposes. On a real network, you're going to see quite a bit more chatter. So, let's capture me connecting to the file share on another computer I have here on the network. Now normally when we do a packet trace, we want to capture as, as short of a time as period to make it easier to find the data that we're looking for. So I'm going to hit this Restart a Running Life Capture button. So it's going to just reset the capture and just start capturing right away again. Then I'm going to do what I, what I want to capture as quickly as I can and then stop the capture to, you know, really narrowing on, on what I'm trying to, to achieve. So I'm going to restart the capture and then from the run menu, I'm going to go to PluralsightO2/C$ so there I pulled up the file system I was trying to capture the, the communication of, and so now I see that you know captured a, a bunch of traffic. I mean if you look at each packet individually here, so let's find out what's the, my local machine is 182.131 so here we see that, you know, the, the initial communication of 182.131 to the other machine, it looks like it was 182.129. So here's that very first packet and we can see all the information about it here. We can see that it used the TCP protocol, all kinds of information about it and then we can see, you know, more specific what exactly it was trying to accomplish. We saw this tool in, in the name resolution module and this is just, you know, the exact same thing, except different type of traffic. So here we've, you know, there's, we were looking at one specific packet, but let's look at the entire transmission and see it all as, as one piece of information. What we can do is right click on any of the packets as part of that session and say follow TCP stream, that's going to go through and find all the packets related to the session and display them all in one piece. But it'll be a little bit easier to see in a bit when we do an http transmission, but the red is my machine sending data and the blue is my, the my computer receiving data. You can, you know, it's kind of hard to read, but you can kind of see that here's the PluralsightO2 that, that I went out and connected to and so you can kind of piece together what happened here, but not super useful in this case. So now let's go and let's do the exact same thing, except let's pull up a webpage, so I'm going to restart a running capture, then I clear out the filter that I had, so we're, you know, all the traffic that's happening will come across now will be visible. I'm going to ppen up Internet Explorer, and I'm going to go to my own webpage because it's a fairly simple one. So I'm going to go to sevans.info and it's going to pull out my, my website here in a little bit. Okay, there is my, my website pulled up and I'm going to go back to Wireshark and I'm going to stop that capture. So let's scroll back up to the top, and you see there is some chatter on the network there, but really what we're looking for is, you know, what happened in that what I just did there in, in Internet Explorer. So here we see the DNS traffic, so just like we saw before in the name resolution series, module, here's, you know, here's my query for sevans.info and then here's the response coming back with the IP address for sevans.info. Just like we saw before in name resolution, so there's a DNS traffic and we should see the http traffic shortly after that. And here we go, here is, here's an http packet coming from my machine, so I'm going to right click that guy and say follow TCP stream and we're going, we'll be able to see the entire http transmission. So here we are in red, here's what my computer sent to the destination computer, so I, it sent a get command and then the other http headers that sends including like here's the host name when I went to sevans.info and then in blue here's the response. So here's the http 200, some other http headers and then the G zipped html file. So they're, they're always in a compressed format. Then we can see there is another get command for a javascript file, there is the response. If we get past this javascript file eventually, we'll see, you know, here's a, a PNG file, so it went out and grabbed an image file. We see this over, you know, we're going to see this for quite a while. So there's a http session that, you know, I was, I was able to capture. So let's clear this out and let's do, now let's do an SSL page. So I'm going to say start a new capture, go back to my web browser and I'm going to go to gmail.com that sends me to an https page, so I'm going to come back, I'm going to stop it, and when we come up we're going to see a bunch of this TLF stuff, that's SSL traffic. So let's go all the way back up to the top and we can see there is the http request and somewhere in here, somewhere right around here, here's the key certificate exchange, server key exchange, so let's, let's just right click that guy and say follow TCP stream and here we have a bunch of encrypted traffic, let's clear that out and go back and look again. Here's a bunch of http traffic mixed in with this, so it's makes it a little harder to follow. So we can just start following TCP streams until we find what we want, but you get the idea. So, oh, so here we go again a thought certificate, clear that out, jus look at this guy, follow TCP stream here. Here's some more thought certificate stuff. Clear that guy out. Sometimes it's handy to pull from the very last, very end of the capture since we know nothing else was pretty much done by that point. Here's some https traffic. So we're going to this gstatic page. So you kind of get the idea, so yeah, you can see it, but it's all encrypted, it's not very useful, it's kind of hard to look up. But you know, if you're looking at something that, you know, you just really need to dig into what's going on, you're able to dig in and find out exactly what happened on the network. Let's start another capture and this time let's do, let's do, let's open up SQL server management studio. So I'm going to connect to SQL server, I'm going to run a query. So let's just do, I have a database called test, I'm just going to select everything from a table I have called persons. So when we run that, we see, you know, it returns four rows, really nothing that exciting. I'm going to clear that out and I'm going to restart that capture. I'm going to capture just exactly where I want and then stop that capture as quickly as I can. If we come in here, we'll see we have my SQL connection, so I'm going to follow that TCP stream. And here we have in red what, what I sent so you can read, you know, used test, so let's start from persons and then here's my response, you know, John Doe, Jane Doe, Fred Smith, Heather Smith, etcetera. So then we went through and we captured a bunch of different traffic from different sources. And you might say like for SQL you, you would probably use SQL tracing tool instead of Wireshark and for http you might use an http, http specific capture tool, which we'll look at in a little bit with Fiddler, but you can see with Wireshark, we really captured everything that happens. So whether it's a custom protocol you've written or a SQL server that you can't trace for some reason, we're just able to see everything that's happened on your computer and it gets to you past that point where you think something's happening, but actually something else is happening and you just didn't realize it. So let's start a capture here and let's just go do a bunch of stuff, then we're going to look at how filtering works a little bit. So I'm just going to, you know, I'm just going to go to, to techmean.com and then go to Pluralsight.com go to my own webpage, and there's a bunch of random stuff. Let's do some name resolution stuff. So I'm going to, you know, look up the IP address for yahoo.com, for Microsoft.com, google.com, and just to round it out let's look up apple.com also, so just a bunch of random stuff. Come back here, we're going to stop that. Now let's say all that happened and I want to find the transmission that happened with Pluralsight.com. Well how could we do that? Well, one, one way we can do it is we can say well we know it's http traffic, so here in our filter, we can pull up the expression dialogue and so we know that http traffic is TCP port 500, so we can come down here to TCP and we can say the destination port equaled 80 and so that gives us an expression we can apply that. So now it's only showing as http traffic, but remember we looked at a bunch of different http pages and a lot of things run over http as it is, so that might not be super helpful. Now we know we could figure out what the IP address for Pluralsight.com is so we could figure out Pluralsight.com is 64.78.158.232 so we come back here in our expression wizard here, we can go to IP, and under IP, that's the wrong one, IPv4, the IP destination equaled 64, no let's get that previous guy out of there, you know, the, the IP address we looked up for Pluralsight.com, so here's everything that happened between my computer and the destination computer of the Pluralsight IP address, okay, so we can see we, we have different filtering mechanisms here. We can say IP address, so we don't care what site it's on, is double equal sign there, apply that so we can whether it's on the source or the destination, it gives us the packets for either site. So, you know, the expression, the filtering capabilities are quite powerful, in fact, somewhat overwhelming, but you'll start to learn the ones that are really relevant to you and be able to narrow in on those. And one thing to remember with using any type of capturing tool is, you can only capture traffic that's passed across your network card. So I'm not going to be able to capture traffic between two remote endpoints, but I could capture traffic that originates or, or ends at, at my specific computer. Now if I had enterprise networking equipment, it's able to capture traffic that's flowing through various network equipment, but as a developer you're not going to have access to that type of equipment. ( Pause )

Fiddler Now let's look at Fiddler. Fiddler is a free http specific capture tool. So we can, from my computer here open up a web browser, browse to a webpage, and it's going to show us everything that happened over http. So here we are, we can see it even captured the update check it does when you open Fiddler. So let's open up a web browser. Now I'm just going to navigate to my own website again, because it's fairly simple. So here we go, it pulls out, and we see that everything that happened is now listed in, in the list here. So first we have the original http request of the default page. We can see it has various information about it, so here's some header information, here's, you know, further header information. Here's the text that was sent back and so all types of information about this, this page. Any cookie information that was available, etcetera, any authentication happened. And we can come in here, it can give us some estimates of how long it would take to get to this page from this, this request would take from various locations. Let's come down here, we see we have a, you know, we pulled a javascript file here. Here's a javascript file, so if we come back and we can see all the various information, here's the header information. Here as it's pulling up a form of javascript here, but all the various information about these specific requests. If we come down, here is a image file on my page, that's the TechHead logo, so here's the, you know, the TechHead image. So you can see all the various things that happen. Let's delete these guys and then let's, let's go to Pluralsight.com and we'll see the difference between using Wireshark to look at this http traffic and, and Fiddler. So we see here that it's a lot easier to understand what's going on with Pluralsight. So at Pluralsight we get a 301 response that redirects us to... redirects us... so we get this document moved, redirects us to a 302, Pluralsight, at Pluralsight-training.net, the 302 sends us to Pluralsight-training.net/Microsoft and here's where we strike to get all the various resources for that page. So all types of great, great information here about the various http requests we're, we're doing. Let's go into the tools Fiddler options. If we come over to https, we see by default it capture https traffic, but doesn't decrypt it. So first let's go to our the Pluralsight sign in page, wait for that to pull up, come down here we'll see all this https traffic, but it doesn't quite have everything we want. If we come back in here to Fiddler options, we say decrypt the https traffic from, we're going to do it from all processes, we'll say okay, I'm going to close out Fiddler, reopen it back up to for that change to take effect. Then we do a hard refresh on that page, just so that it pulls, has pulled all this information again. Come in here to this https connections and we'll see that we got lot more information about, it was able to decrypt all that data that happened. Coming to the headers and we can see all the headers that happened, even though those headers were encrypted in the, in the regular network capture tool. So all types of great things you can do here with Fiddler, I'm not going to dig too deep into it, but it gives you an idea of here's a tool for a very specific protocol, so it will give us even more information, more useful... information displayed in a better way than a more general purpose tool like Wireshark would do.

Summary In this module, we looked at packet tracing. First, we looked at packet tracing with Wireshark, in a general purpose tool that allows us to capture any type of traffic and then we looked at Fiddler which is specific to http traffic and gives us a lot more information, a lot easier to view information about http traffic, but only about that one specific protocol.