Previous Table of Contents Next A Couple of Milliseconds in the Life of Joe Packet Let's follow a concrete example by tracing a packet through the network shown in Figure 14.3. The PC at point A wants to telnet to the UNIX server at point B. Because we're talking about routing, we don't care about the specifics of the network conversation; we just want to trace how the call gets from point A to point B. Here are the steps: 1. The "middleware" that allows an application program to talk to your network card's driver is called a stack. Your PC's TCP/IP protocol middleware (stack) must open up a connection to the UNIX server at 192.168.4.10. The TCP/IP stack knows what its own IP address is (192.168.1.20) and sees that 192.168.4 is not on the same network. Therefore, instead of establishing a conversation with the destination, the IP stack will establish a conversation with the router. 2. The IP stack passes the first packet of the Telnet conversation to the router at 192.168.1.1 (Router 1). 3. The router first looks up the destination network in its routing table. In this case, the destination is listed in Router 1's routing table as being reachable through the 192.168.2.1 router (Router 2). ______________________________________________________________ If the destination network is not in the routing table, the router drops the packet and sends back a special IP packet saying that this destination is unreachable. ______________________________________________________________ 4. Router 1 starts a conversation up with Router 2, whose routing table is shown in Table 14.2. CAPTION: Table 14.2 Routing Table for Router 2 _________________________________________________________________ Network Next Hop Metric _________________________________________________________________ 192.168.2.0 192.168.2.2 0 (Direct) 192.168.3.0 192.168.3.1 0 (Direct) 192.168.1.0 192.168.2.1 1 192.168.4.0 192.168.3.2 1 _________________________________________________________________ 5. The packet still needs to get to point B from Router 2. Router 2 looks up the destination network (192.168.4) in its routing table and finds out that it does not have a direct connection to that network. Instead, the next hop is at 192.168.3.2 (Router 3), which is on the other side of the wide-area connection. Router 3's routing table is shown in Table 14.3. CAPTION: Table 14.3 Routing Table for Router 3 _________________________________________________________________ Network Next Hop Metric _________________________________________________________________ 192.168.3.0 192.168.3.2 0 (Direct) 192.168.4.0 192.168.4.1 0 (Direct) 192.168.1.0 192.168.3.1 2 192.168.2.0 192.168.3.1 1 _________________________________________________________________ 6. Finally! The destination, 192.168.4.10, is on a directly connected network! All Router 3 needs to do is to establish an Ethernet-level connection with the UNIX host and hand off all the PC's packets that it receives from Router 2. The packets are flowing and the planets are starting to align-what could be better? Of course, responses from the UNIX host destined for the PC at point A go from the UNIX host to Router 3, to Router 2, to Router 1, and then to the PC. This might seems confusing when you say it like that, but take a look at the map and refer to each routing table, keeping in mind that the destination is 192.168.1 this time, and you'll see that each lookup will lead to the next correct router. In real life, this can be somewhat more complicated. Instead of each routing table having four entries, they can have hundreds-or even thousands-of entries. However, the basic principles are unchanged; much of what you need to figure out from a troubleshooting standpoint is how to command your router to show you what its routing table looks like. This way, you can do a sanity check on it. For example, if Router 1's table showed that the next hop to 192.168.4.0 was 192.168.2.10 (the file and print server), you'd raise your eyebrows and start to investigate why Router 1 thought that the best way to 192.168.4 was through a server. (Going through a server isn't in itself terrible-if the server is a multihomed server acting as a router to the proper network. But in this case, it's a dead end.) Those Dynamic Routers I heard you ask about four paragraphs ago, "How does the routing table get built?" I wasn't ignoring you; it's a good question. To begin to answer it, let's discuss basic route entry types. There are two types of routes that can be established in a routing table: o Static routes A static route is one you type in yourself at the router console. This gets extremely tedious and isn't the greatest way to have a flexible and easily reconfigurable network. o Dynamic routes Dynamic routing entries are built via routing protocols. ______________________________________________________________ There's one special static route you'll want to know about called the default route. This is represented by the destination network 0.0.0.0 and is the route used when a packet has a destination that isn't covered by anything else in the routing table. ______________________________________________________________ Routing protocols are based on the concept that each router "knows" which network it lives on, and that it can communicate which networks it knows about to other routers. Looking at Figure 14.3 again, it makes sense that Router 1 could tell Router 2 about the 192.168.1 network, and that Router 2 could tell Router 1 about the 192.168.3 network-along with the 192.168.4 network, once Router 3 told Router 2 about it. Whoa. It's a good thing this happens more or less automatically, because in a large network, writing this out could get really hairy. Again, here's how dynamic routes would work in this sample network: Router 1 Tells Router 2 about 192.168.1 Router 2 Tells Router 1 about 192.168.3 Tells Router 3 about 192.168.1 Tells Router 1 about 192.168.4 Router 3 Tells Router 2 about 192.168.4 Previous Table of Contents Next