Routers and Routing

Routers and Routing
As you already know, routing is the process of getting your data from point A to point B. Routing datagrams is similar to driving a car. Before you drive off to your destination, you determine
which roads you will take to get there. And sometimes along the way, you may change your mind and alter your route.
         The IP portion of the TCP/IP protocol inserts its header in the datagram, but before the datagram can begin its journey, IP determines whether it knows the destination. If it does, it sends
the datagram on its way. If it doesn’t know and can’t find out, IP sends the datagram to the host’s default gateway.

Note:

One key to understanding some of the original Internet documents, as well as some of the legacy terminology, is to realize that every router in the Internet was once referred to as a gateway. Therefore, a default gateway is really a default router.

 Each host on a TCP/IP network can have a default gateway, an off-ramp for datagrams not destined for the local network. They’re going somewhere else, and the router’s job is to forward
them to that destination if it knows where it is. Each router has a defined set of routing tables that tell the router the route to specific destinations.
             Because routers don’t know the location of every IP address, they have their own default gateways that act just like any TCP/IP host. In the event that the first router doesn’t know the
way to the destination, it forwards the datagram to its own default gateway. This forwarding, or routing, continues until the datagram reaches its destination. The entire path to the destination is known as the route.
Datagrams intended for the same destination may actually take different routes to get there. Many variables determine the route. For example, overloaded routers may not respond in a


All TCP/IP Devices Route
Technically, end devices and routers both work similarly when deciding what to do with an IP packet. In fact, any packet that leaves one of these devices toward a destination does so because the transmitting device knew what to do with it, even if it is sent out to the default gateway address. The default gateway is actually a statically or dynamically learned route entry, just like every other entry in the routing table. Any potential destination address is ANDed (ANDing is a Boolean algebra operator that produces a 0, unless two 1s are ANDed) with each route entry’s mask, the result compared to the entry’s network address. All matches are then
compared for the longest prefix length, which means the most 1s in the mask, which is the one chosen when more than one match is found. Since the default gateway’s entry always has a prefix length of 0, it will only be chosen when no other match is found, leading to the use of the word default. Therefore, even when the default gateway is used, it is because the destination is “known.” Any packet whose destination address produces no matches with the route entries in the routing table is dropped.

timely manner or may simply refuse to route traffic and so they time out. That time-out causes the sending router to seek an alternate route for the datagram.
         Routes can be predefined and made static, and alternate routes can be predefined, providing a maximum probability that your datagrams travel via the shortest and fastest route.

Note:

If you configure the TCP/IP settings for a computer on a LAN that has a router through which the Internet is accessible, there are certain settings that must be made and others that just make life easier but without which reliable Internet access cannot be achieved. These are an IP address for the computer, a common subnet mask for the LAN, a default gateway IP address for the local router interface, and the address of a DNS server. While the last two settings are not technically mandatory, it’s easier to consider these four parameters as requirements than it is to explain the extra and meticulous configuration that must be made to get around the last two settings, which includes manual routing table manipulation and the use of hosts files.

Read More

Address Resolution Protocol (ARP) and Reverse ARP (RARP)

Address Resolution Protocol (ARP) 
The Network layer protocol, ARP, associates the physical hardware address of a network node to its already known IP address. Using ARP, an IP process constructs a table (known as the ARP cache) that maps logical addresses to the hardware addresses of nodes on the local network. When a node needs to send a packet to a known IP address on the local subnet, it first checks the ARP cache to see if the physical address information is already present. If so, that address is used and network traffic is reduced; otherwise, a normal ARP request is made to determine the address.

Note:

See Chapter 4, “TCP/IP Utilities,” for more on ARP.

 Reverse ARP (RARP)
 is nothing more than ARP packets with different codes in the header, indicating to devices receiving RARP packets that these are requests by the source device for its own IP configuration, meaning RARP replies should be handled by a RARP server and that any device not fulfilling this role need not process these requests any further. If, however, the receiving device is a RARP server, it is incumbent upon that device to find the requesting device’s MAC address in a configured list (RARP is an older, manual process, unlike DHCP). The server sends the IP address it finds associated with the requesting MAC address back to the requesting device. RARP was adequate for diskless workstation initial IP configuration but fell short as an be-all, end-all supplier of detailed IP-related information, which is why DHCP has supplanted
RARP for supplying network-based IP configuration in most modern networks.

Read More

Internet Control Message Protocol (ICMP)

Internet Control Message Protocol (ICMP)
ICMP works at the Network layer and provides the functions used for Network layer management and control. Routers send ICMP messages to respond to undeliverable datagrams by placing
an ICMP message in an IP datagram and then sending the datagram back to the original source. The ping command—used in network troubleshooting and described in Chapter 5,
“Major Network Operating Systems”—uses ICMP.

Read More

The Internet Layer Protocols

The Internet Layer Protocols
The Internet layer of the DoD model is made up of various protocols, with the three main protocols being the Internet Protocol (IP), the Internet Control Message Protocol (ICMP), and the
Address Resolution Protocol (ARP). The following sections introduce these three protocols and provide more detail. And no discussion of things layer 3 would be complete without mentioning
routers and the process of routing.

The Internet Protocol
The Network layer portion of the DoD model is called the Internet layer. Not surprisingly, the main protocol at this layer is the Internet Protocol (IP). IP is what actually moves the data from point A to point B, a process that is called routing. IP is considered connectionless; that is, it does not swap control information (or handshaking information) in order to establish an end-to-end connection before starting a transmission. This is also known as best effort transmission. Additionally, if a packet is lost in transmission, IP must rely on TCP to determine if the data did not arrive successfully at its destination and, if not, to retransmit the entire segment, which could be more data than was carried by the lost packet

if IP had to fragment the segment. IP’s only job is to route the data to its destination. In this effort, IP inserts its own header in the datagram once it is received from TCP (or UDP or another
higher-layer protocol). The main contents of the IP header are the source and destination addresses, the protocol number, and a checksum.

Note:
IP is considered unreliable. This is because it contains no error detection or recovery capability, not because it is  ndependable. For these reasons, UDP is also an unreliable protocol. Conversely, TCP is considered reliable.

      Without the header provided by IP, intermediate routers between the source and destination— originally called gateways in the RFCs—would not be able to determine where to route the datagram. Figure 3.3 shows the layout of the datagram with the IP header in place, followed by the upper-layer header and data, which IP sees as just upper-layer information.

FIGURE 3 . 3 A datagram with TCP and IP headers

The fields in the IP header include the following:

      Version Defines the IP version number. Version 4 is the current standard. IP version 6 is currently supported by the newest equipment and may quickly become the new standard.

IHL (Internet Header Length) Defines the length of the header information. The header length can vary; the standard header is five 32-bit words, and the sixth and subsequent words are for options and padding.

TOS (Type of Service) Originally, these eight bits were broken into four fields in the first six bits, with 0s in the last two bits. The first three bits are called the precedence bits and allow the specification of eight levels of priority, with 0 being lowest and 7 being highest. The next three bits specify normal or low delay, normal or high throughput, and normal or high reliability, depending on values of 0 or 1, respectively, meaning 0 is normal for each field. Note that a value of 1 for each of these bits would be preferred. In some implementations, the first six bits are collectively used for prioritization of traffic. When used for this purpose, the first six bits are called  Differentiated Services Code Point (DSCP) bits. In still other implementations, the last two bits can be used to give TCP the ability to communicate congestion details, in which case they are

referred to as Explicit Congestion Notification (ECN) bits.

Note:

While all of this detail is pertinent to the TOS field, only a basic understanding is necessary for Network+ proficiency.

Total Length Specifies the total length of the datagram, which has no specified minimum but should be supported in all implementations up to 576 bytes. Being 16 bits, the length field can

specify a maximum packet length of 65,535 bytes.

Identification An identifying number that the receiving system can use to reassemble fragmented datagrams. Each fragment produced from the same datagram will bear the same identifying number in this field.

Flags When set to 1, the second flag bit specifies that the datagram should not be fragmented and must therefore travel over subnetworks that can handle the size without fragmenting it; the

third flag bit being set indicates that the packet is the last of a fragmented segment. When reset to 0, these two flags have the opposite meanings. The first flag bit is not used and always must

be set to 0.

Fragmentation Offset Indicates, in units of 8 octets (64 bits), the original position of the fragmented data and is used during reassembly. The first fragment of a set of fragmented packets

or non-fragmented packets have a value of 0 in this field, as you might expect.

Time to Live (TTL) Originally, the time in seconds that the datagram could be in transit; if this time was exceeded, the datagram was considered lost. Now interpreted as a hop count and

usually set to the default value of 32 (for 32 hops), this number is decremented by each router through which the packet passes. The router that decrements this field to 0, which is known as the executioner, drops the packet and sends an ICMP time exceeded message back to the original source of the packet.

Protocol Identifies the protocol whose header and data follow the IP header, allowing the interleaving or multiplexing of multiple protocols. For example, a value of 6 indicates TCP, a

value of 17 indicates User Datagram Protocol (UDP), and a value of 1 indicates ICMP. Multiplexing of upper-layer information means that one protocol, such as TCP, does not need to finish

its transmission before another, such as UDP, begins using the services of IP. Without the use of such a field, only one protocol could be used in any given implementation of IP.

Header Checksum An error-checking value that is recalculated at each packet processing point (for example, each router). Recalculation is necessary because certain IP header fields change, such as TTL. The checksum is computed only on the bits of the IP header, with the checksum field initially set to all 0s before the computation.

Source Address The 32-bit IP address of the original transmitting device. Note that this value can change along the path of transmission if certain technologies, such as Network Address

Translation (NAT), are in use.

Note:

NAT is the process of converting between the IP addresses used on a corporate intranet or other private network and Internet IP addresses. This process makes it possible to use a large number of addresses within the private network without depleting the limited number of available registered IP addresses. NAT is

usually performed within a router or firewall.

Destination Address      The 32-bit IP address of the original destination device. This address can be altered along the transmission path in the same way as noted for the source address.

Options and Padding      IP options are a set of variable fields that may or may not be present in each IP packet. While the presence of options is not mandatory, the support of all possible IP

options is required by each IP implementation. This means that if an IP host includes an option, all IP devices will understand it. Examples of standards-based options are Security, Record

Route, and Internet Timestamp. If any options are included in the IP header, it is necessary to verify that the IP header ends on a 32-bit boundary. If not, it is necessary to pad with 0s at the end of the last option, until the total length of the IP header is a multiple of 32 bits.

Upper-Layer Information The header and user data handed down by a protocol, such as TCP. The header will not appear for non-initial IP fragments. The data in the packet immediately follows this header information, which may correspond to a complete TCP segment, UDP datagram, or other IP-supported PDU or to a portion thereof when fragmentation has occurred.

Read More