Routing and Addressing
| 
| 
CCNA Cisco study guide of the fundamentals of IP addressing and routing
The OSI layer 3 protocols defines how packets can be delivered from the computer that created them to the computer that needs to receive them. To achieve this goal, the OSI layer 3 or Network layer defines the following:
1. Routing
2. Logical Addressing
3. Routing Protocol
4. Utilities: ARP, DNS, DHCP, PING
The OSI layer 3 defines routing and logical addressing and is considered to be a network layer. OSI defines CLNS (Connectionless Network Services). Today, the only widely used layer 3 protocol is IP out of TCP/IP. The main job of IP is to route data from source host to destination host. Because the network needs to route a large number of packets, the IP routing process is simple. IP does not require any overhead agreements or messages before sending a packet, making it a connectionless protocol. IP tries to deliver a packet but if it fails, it is discarded with no error recovery. TCP provides error recovery, resending lost data.
Network layer interaction with the Data Link layer.
When the Network layer protocol sends the packet it passes it over to the Data link layer which adds the frame header and trailer to the packet creating a frame. Each router along the path strips the header and trailer and re encapsulates the packet.
IP packets and the IP header
|
IPv4 Header, standard 20 bytes |
||||
|
0-7 |
8-15 |
16-23 |
24-31 |
|
|
Version (4) |
Header Lenght (4) |
DS Field (8) |
Packet Lenght (16) |
|
|
Identification(16) |
Flags (3) |
Fragment Offset (13) |
||
|
Time to Live(8) |
Protocol (8) |
Header Checksum (16) |
||
|
Source IP Address (32) |
||||
|
Destination IP Address (32) |
||||
|
Options (1-variable) |
||||
|
Data, not part of header (0-65535-header lenght) |
||||
|
IPv4 Header fields meaning |
|||||||
|
Field |
Meaning |
||||||
|
Version |
Version of the IP protocol, 4 for IPv4, 6 for IPv6 |
||||||
|
IHL |
IP header lenght, number of 32 bit words, 160 to 480 bits |
||||||
|
DS |
Differentiated services, bits 0–2: Precedence (111 - Network Control, 110 - Internetwork Control, 101 - CRITIC/ECP, 100 - Flash Override, 011 - Flash, 010 - Immediate, 001 - Priority, 000 - Routine), bit 3: 0 = Normal Delay, 1 = Low Delay, bit 4: 0 = Normal Throughput, 1 = High Throughput, bit 5: 0 = Normal Reliability, 1 = High Reliability, bit 6: 0 = Normal Cost, 1 = Minimize Monetary Cost (defined by RFC 1349), bit 7: never defined |
||||||
|
Packet lenght |
This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 — the maximum value of a 16-bit word. The minimum size datagram that any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or packet switch in IPv4 |
||||||
|
Identification |
This field is an identification field and is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet-tracing information to datagrams in order to help trace back datagrams with spoofed source addresses. |
||||||
|
Flags |
A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order): Reserved; must be zero. As an April Fools joke, proposed for use in RFC 3514 as the "Evil bit". Don't Fragment (DF), More Fragments (MF). If the DF flag is set and fragmentation is required to route the packet then the packet will be dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation. When a packet is fragmented all fragments have the MF flag set except the last fragment, which does not have the MF flag set. The MF flag is also not set on packets that are not fragmented — an unfragmented packet is its own last fragment. |
||||||
|
Fragment offset |
The fragment offset field, measured in units of eight-byte blocks, is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 – 1) × 8 = 65,528 which would exceed the maximum IP packet length of 65,535 with the header length included. |
||||||
|
TTL |
Time to live. An eight-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1. In latencies typical in practice, it has come to be a hop count field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded. Typically, an ICMP message (specifically the time exceeded) is sent back to the sender that it has been discarded. The reception of these ICMP messages is at the heart of how traceroute works. |
||||||
|
Protocol |
This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of Protocol numbers which was originally defined in RFC 790. 1: Internet Control Message Protocol (ICMP). 2: Internet Group Management Protocol (IGMP). 6: Transmission Control Protocol (TCP). 17: User Datagram Protocol (UDP). 89: Open Shortest Path First (OSPF). 132: Stream Control Transmission Protocol (SCTP). |
||||||
|
Header Checksum |
The 16-bit checksum field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded. Note that errors in the data field are up to the encapsulated protocol to handle — indeed, both UDP and TCP have checksum fields. Since the TTL field is decremented on each hop and fragmentation is possible at each hop then at each hop the checksum will have to be recomputed. The method used to compute the checksum is defined within RFC 1071: The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented and this final value is inserted as the checksum field. To validate a header's checksum the same algorithm may be used - the checksum of the header with the checksum field filled in should be a word containing all zeros (value 0). |
||||||
|
Source IP address |
An IPv4 address is a group of four octets for a total of 32 bits. The value for this field is determined by taking the binary value of each octet and concatenating them together to make a single 32-bit value. For example, the address 10.9.8.7 would be 00001010000010010000100000000111. This address is the address of the sender of the packet. Note that this address may not be the "true" sender of the packet due to network address translation. Instead, the source address will be translated by the NATing machine to its own address. Thus, reply packets sent by the receiver are routed to the NATing machine, which translates the destination address to the original sender's address. |
||||||
|
Destination IP address |
Identical to the source address field but indicates the receiver of the packet. |
||||||
|
Options |
Additional header fields may follow the destination address field, but these are not often used. Note that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integral number of 32-bit words). The list of options may be terminated with an EOL (End of Options List, 0x00) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header. The possible options that can be put in the header are as follows: Copied, 1 bit, Set to 1 if the options need to be copied into all fragments of a fragmented packet. Option class, 2 bits, A general options category. 0 is for "control" options, and 2 is for "debugging and measurement". 1, and 3 are reserved. Option number, 5 bits, Specifies an option. Option lenght, 8 bits, Indicates the size of the entire option (including this field). This field may not exist for simple options. Option data, variable, Option-specific data. This field may not exist for simple options. If the Header Length is greater than 5, i.e. it is between 6-15, it means that the Options field is present and must be considered. The Copied, Option Class, and Option Number are sometimes referred to as a single eight-bit field - the Option Type. The use of the LSRR and SSRR options (Loose and Strict Source and Record Route) is discouraged because they create security concerns; many routers block packets containing these options. |
||||||
|
Data |
The last field is not a part of the header and, consequently, not included in the checksum field. The contents of the data field are specified in the protocol header field and can be any one of the transport layer protocols. |
||||||
Logical Addressing
Classes of networks
|
Public network classes |
|||||||
|
Class |
Leading bits |
First octet range |
Number of networks |
Addresses per network |
Start address |
End address |
Last valid network number |
|
A |
0 |
1 to 126 |
126 (2^7-2) |
16,777,214 (2^24-2) |
1.0.0.0 |
126.255.255.255 |
126.0.0.0 |
|
B |
10 |
128 to 191 |
16,384 (2^14) |
65,534 (2^16-2) |
128.0.0.0 |
191.255.255.255 |
191.255.0.0 |
|
C |
110 |
192 to 223 |
2,097,150 (2^21-2) |
256 (2^8) |
192.0.0.0 |
223.255.255.255 |
223.255.255.0 |
|
Multicast (Formerly class D) |
1110 |
224 to 239 |
not defined |
not defined |
224.0.0.0 |
239.255.255.255 |
not defined |
|
Reserved (Formerly class E) |
1111 |
240 to 255 |
not defined |
not defined |
240.0.0.0 |
255.255.255.255 |
not defined |
|
Private network classes |
|||
|
Class |
Start IP |
Finish IP |
Number of addresses |
|
A |
10.0.0.0 |
10.255.255.255 |
16,777,216 |
|
B |
172.16.0.0 |
172.31.255.255 |
1,048,576 |
|
C |
192.168.0.0 |
192.168.255.255 |
65,536 |
|
Reserved addresses blocks |
|||
|
CIDR |
Start IP |
End IP |
Description |
|
0.0.0.0/8 |
0.0.0.0 |
0.255.255.255 |
Current network |
|
10.0.0.0/8 |
10.0.0.0 |
10.255.255.255 |
Private network class A |
|
127.0.0.0/8 |
127.0.0.0 |
127.255.255.255 |
Loopback |
|
169.254.0.0/16 |
169.254.0.0 |
169.254.255.255 |
Link-Local |
|
172.16.0.0/12 |
172.16.0.0 |
172.31.255.255 |
Private network class B |
|
192.0.0.0/24 |
192.0.0.0 |
192.0.0.255 |
Reserved IANA |
|
192.0.2.0/24 |
192.0.2.0 |
192.0.2.255 |
TEST-NET-1 |
|
192.88.99.0/24 |
192.88.99.0 |
192.88.99.255 |
IPv6 to IPv4 relay |
|
192.168.0.0/16 |
192.168.0.0 |
192.168.255.255 |
Private network class C |
|
198.18.0.0/15 |
198.18.0.0 |
198.19.255.255 |
Network benchmark tests |
|
198.51.100.0/24 |
198.51.100.0 |
198.51.100.255 |
TEST-NET-2 |
|
203.0.113.0/24 |
203.0.113.0 |
203.0.113.255 |
TEST-NET-3 |
|
224.0.0.0/4 |
224.0.0.0 |
239.255.255.255 |
Multicast (Former class D) |
|
240.0.0.0/4 |
240.0.0.0 |
255.255.255.255 |
Reserved (Former class E) |
|
255.255.255.255 |
255.255.255.255 |
255.255.255.255 |
Broadcast |
IP subnetting
Subnet = Subdivided Network
|
Class A subnetting |
||
|
8 |
24-x |
x |
|
Network |
Subnet |
Host |
|
Class B subnetting |
||
|
16 |
16-x |
x |
|
Network |
Subnet |
Host |
|
Class C subnetting |
||
|
24 |
8-x |
x |
|
Network |
Subnet |
Host |
|
Classless subnetting |
|
|
32-x |
x |
|
Subnet or Prefix |
Host |
Routing
IP Routing
Host routing. A host sends a packet. If destination IP is on the same subnet, the packet is sent directly to the destination host. If destination IP is not on the same subnet, it sends the packet to the default gateway.
Router routing process:
1. Check frames FCS for errors. If errors discard.
2. Discard frame header and trailer.
3. Compare destination IP to the routing table and find route that reaches destination. This route will identify outgoing router interface and possibly, the next hop router.
4. Encapsulate IP packet inside a new frame header and trailer appropriate for the outgoing interface and forward the frame.
Routing Protocol
IP Routing Protocols
Goals of a routing protocol:
1. Dynamically learn and fill the routing table with a route to all subnets in the network.
2. When more than one route available to a subnet, place the best route in the routing table.
3. To notice when routes in table are no longer valid and remove them from the table.
4. If a route is removed and another route through a neighboring router is available add it to the routing table.
5. Add new routes and/or replace lost routes with the best available route as quickly as possible. The time between loosing a route and finding a replacement is called convergence time.
6. Prevent routing loops.
Routing protocols:
1. Each router adds a route to its routing table for each subnet connected directly to the router.
2. Each router tells its neighbours about all routes in its routing table, both directly connected routes as routes learned from its neighbours.
3. After learning a new route from a neighbour, the router adds the route to its routing table, with the next hop router being typically the neighbour from which the route was learned.
Utilities
Network layer utilities
ARP
Address Resolution protocol
It correlates MAC addresses with IP addresses. Translates layer 3 addresses into layer 2 addresses.
Inverse ARP or InARP is used to obtain layer 3 addresses from layer 2. Needed for Frame Relay (DLCI) or ATM.
Reverse ARP or RARP, was replaced with BOOTP and then DHCP.
DNS
Domain name system
It correlates URL's with IP's. Translates domain names into IP addresses.
DHCP
Dynamic host configuration protocol
DHCP defines the protocols used to allow devices to request the lease of an IP address.
DHCP uses a server that manages all IP's available on different subnets. DHCP clients can send the server a request for an IP. The server offers one and if accepted he notates it as in use. DHCP supplies to clients: IP addresses, gateway address, subnet mask and DNS servers addresses. PING
Internet control message protocol (ICMP), Packet internet groper (PING)
Ping is primary tool to test connectivity.
As we put quality first, we are content to grow slowly. Most of our referrals are word of mouth. This web site exists mainly to offer our customers a fast way to tools and utilities. You can click here to arrange a free initial consultation at your location.
* $ 36.25/Hr.based on 8 Hrs. labor job billed using our MoreforLess innovative pricing structure. Service contract of $ 19.95/mo. based on our NoHeadaches regular maintenance and customer education program.
We offer on-site Web and Information Technology Solutions in Austin, Bee Caves, Bertram, Briarcliff, Burnet, Cedar Park, Driftwood, Dripping Springs, Georgetown, Horseshoe Bay, Lake Travis, Lakeway, Leander, Marble Falls, Oak Hill, Round Rock, Spicewood and Wimberley.
CCNA Cisco study guide of the fundamentals of IP addressing and routing
The OSI layer 3 protocols defines how packets can be delivered from the computer that created them to the computer that needs to receive them. To achieve this goal, the OSI layer 3 or Network layer defines the following:
1. Routing
2. Logical Addressing
3. Routing Protocol
4. Utilities: ARP, DNS, DHCP, PING
The OSI layer 3 defines routing and logical addressing and is considered to be a network layer. OSI defines CLNS (Connectionless Network Services). Today, the only widely used layer 3 protocol is IP out of TCP/IP. The main job of IP is to route data from source host to destination host. Because the network needs to route a large number of packets, the IP routing process is simple. IP does not require any overhead agreements or messages before sending a packet, making it a connectionless protocol. IP tries to deliver a packet but if it fails, it is discarded with no error recovery. TCP provides error recovery, resending lost data.
Network layer interaction with the Data Link layer.
When the Network layer protocol sends the packet it passes it over to the Data link layer which adds the frame header and trailer to the packet creating a frame. Each router along the path strips the header and trailer and re encapsulates the packet.
IP packets and the IP header
|
IPv4 Header, standard 20 bytes |
||||
|
0-7 |
8-15 |
16-23 |
24-31 |
|
|
Version (4) |
Header Lenght (4) |
DS Field (8) |
Packet Lenght (16) |
|
|
Identification(16) |
Flags (3) |
Fragment Offset (13) |
||
|
Time to Live(8) |
Protocol (8) |
Header Checksum (16) |
||
|
Source IP Address (32) |
||||
|
Destination IP Address (32) |
||||
|
Options (1-variable) |
||||
|
Data, not part of header (0-65535-header lenght) |
||||
|
IPv4 Header fields meaning |
|||||||
|
Field |
Meaning |
||||||
|
Version |
Version of the IP protocol, 4 for IPv4, 6 for IPv6 |
||||||
|
IHL |
IP header lenght, number of 32 bit words, 160 to 480 bits |
||||||
|
DS |
Differentiated services, bits 0–2: Precedence (111 - Network Control, 110 - Internetwork Control, 101 - CRITIC/ECP, 100 - Flash Override, 011 - Flash, 010 - Immediate, 001 - Priority, 000 - Routine), bit 3: 0 = Normal Delay, 1 = Low Delay, bit 4: 0 = Normal Throughput, 1 = High Throughput, bit 5: 0 = Normal Reliability, 1 = High Reliability, bit 6: 0 = Normal Cost, 1 = Minimize Monetary Cost (defined by RFC 1349), bit 7: never defined |
||||||
|
Packet lenght |
This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 — the maximum value of a 16-bit word. The minimum size datagram that any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or packet switch in IPv4 |
||||||
|
Identification |
This field is an identification field and is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet-tracing information to datagrams in order to help trace back datagrams with spoofed source addresses. |
||||||
|
Flags |
A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order): Reserved; must be zero. As an April Fools joke, proposed for use in RFC 3514 as the "Evil bit". Don't Fragment (DF), More Fragments (MF). If the DF flag is set and fragmentation is required to route the packet then the packet will be dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation. When a packet is fragmented all fragments have the MF flag set except the last fragment, which does not have the MF flag set. The MF flag is also not set on packets that are not fragmented — an unfragmented packet is its own last fragment. |
||||||
|
Fragment offset |
The fragment offset field, measured in units of eight-byte blocks, is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 – 1) × 8 = 65,528 which would exceed the maximum IP packet length of 65,535 with the header length included. |
||||||
|
TTL |
Time to live. An eight-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1. In latencies typical in practice, it has come to be a hop count field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded. Typically, an ICMP message (specifically the time exceeded) is sent back to the sender that it has been discarded. The reception of these ICMP messages is at the heart of how traceroute works. |
||||||
|
Protocol |
This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of Protocol numbers which was originally defined in RFC 790. 1: Internet Control Message Protocol (ICMP). 2: Internet Group Management Protocol (IGMP). 6: Transmission Control Protocol (TCP). 17: User Datagram Protocol (UDP). 89: Open Shortest Path First (OSPF). 132: Stream Control Transmission Protocol (SCTP). |
||||||
|
Header Checksum |
The 16-bit checksum field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded. Note that errors in the data field are up to the encapsulated protocol to handle — indeed, both UDP and TCP have checksum fields. Since the TTL field is decremented on each hop and fragmentation is possible at each hop then at each hop the checksum will have to be recomputed. The method used to compute the checksum is defined within RFC 1071: The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented and this final value is inserted as the checksum field. To validate a header's checksum the same algorithm may be used - the checksum of the header with the checksum field filled in should be a word containing all zeros (value 0). |
||||||
|
Source IP address |
An IPv4 address is a group of four octets for a total of 32 bits. The value for this field is determined by taking the binary value of each octet and concatenating them together to make a single 32-bit value. For example, the address 10.9.8.7 would be 00001010000010010000100000000111. This address is the address of the sender of the packet. Note that this address may not be the "true" sender of the packet due to network address translation. Instead, the source address will be translated by the NATing machine to its own address. Thus, reply packets sent by the receiver are routed to the NATing machine, which translates the destination address to the original sender's address. |
||||||
|
Destination IP address |
Identical to the source address field but indicates the receiver of the packet. |
||||||
|
Options |
Additional header fields may follow the destination address field, but these are not often used. Note that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integral number of 32-bit words). The list of options may be terminated with an EOL (End of Options List, 0x00) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header. The possible options that can be put in the header are as follows: Copied, 1 bit, Set to 1 if the options need to be copied into all fragments of a fragmented packet. Option class, 2 bits, A general options category. 0 is for "control" options, and 2 is for "debugging and measurement". 1, and 3 are reserved. Option number, 5 bits, Specifies an option. Option lenght, 8 bits, Indicates the size of the entire option (including this field). This field may not exist for simple options. Option data, variable, Option-specific data. This field may not exist for simple options. If the Header Length is greater than 5, i.e. it is between 6-15, it means that the Options field is present and must be considered. The Copied, Option Class, and Option Number are sometimes referred to as a single eight-bit field - the Option Type. The use of the LSRR and SSRR options (Loose and Strict Source and Record Route) is discouraged because they create security concerns; many routers block packets containing these options. |
||||||
|
Data |
The last field is not a part of the header and, consequently, not included in the checksum field. The contents of the data field are specified in the protocol header field and can be any one of the transport layer protocols. |
||||||
Logical Addressing
Classes of networks
|
Public network classes |
|||||||
|
Class |
Leading bits |
First octet range |
Number of networks |
Addresses per network |
Start address |
End address |
Last valid network number |
|
A |
0 |
1 to 126 |
126 (2^7-2) |
16,777,214 (2^24-2) |
1.0.0.0 |
126.255.255.255 |
126.0.0.0 |
|
B |
10 |
128 to 191 |
16,384 (2^14) |
65,534 (2^16-2) |
128.0.0.0 |
191.255.255.255 |
191.255.0.0 |
|
C |
110 |
192 to 223 |
2,097,150 (2^21-2) |
256 (2^8) |
192.0.0.0 |
223.255.255.255 |
223.255.255.0 |
|
Multicast (Formerly class D) |
1110 |
224 to 239 |
not defined |
not defined |
224.0.0.0 |
239.255.255.255 |
not defined |
|
Reserved (Formerly class E) |
1111 |
240 to 255 |
not defined |
not defined |
240.0.0.0 |
255.255.255.255 |
not defined |
|
Private network classes |
|||
|
Class |
Start IP |
Finish IP |
Number of addresses |
|
A |
10.0.0.0 |
10.255.255.255 |
16,777,216 |
|
B |
172.16.0.0 |
172.31.255.255 |
1,048,576 |
|
C |
192.168.0.0 |
192.168.255.255 |
65,536 |
|
Reserved addresses blocks |
|||
|
CIDR |
Start IP |
End IP |
Description |
|
0.0.0.0/8 |
0.0.0.0 |
0.255.255.255 |
Current network |
|
10.0.0.0/8 |
10.0.0.0 |
10.255.255.255 |
Private network class A |
|
127.0.0.0/8 |
127.0.0.0 |
127.255.255.255 |
Loopback |
|
169.254.0.0/16 |
169.254.0.0 |
169.254.255.255 |
Link-Local |
|
172.16.0.0/12 |
172.16.0.0 |
172.31.255.255 |
Private network class B |
|
192.0.0.0/24 |
192.0.0.0 |
192.0.0.255 |
Reserved IANA |
|
192.0.2.0/24 |
192.0.2.0 |
192.0.2.255 |
TEST-NET-1 |
|
192.88.99.0/24 |
192.88.99.0 |
192.88.99.255 |
IPv6 to IPv4 relay |
|
192.168.0.0/16 |
192.168.0.0 |
192.168.255.255 |
Private network class C |
|
198.18.0.0/15 |
198.18.0.0 |
198.19.255.255 |
Network benchmark tests |
|
198.51.100.0/24 |
198.51.100.0 |
198.51.100.255 |
TEST-NET-2 |
|
203.0.113.0/24 |
203.0.113.0 |
203.0.113.255 |
TEST-NET-3 |
|
224.0.0.0/4 |
224.0.0.0 |
239.255.255.255 |
Multicast (Former class D) |
|
240.0.0.0/4 |
240.0.0.0 |
255.255.255.255 |
Reserved (Former class E) |
|
255.255.255.255 |
255.255.255.255 |
255.255.255.255 |
Broadcast |
IP subnetting
Subnet = Subdivided Network
|
Class A subnetting |
||
|
8 |
24-x |
x |
|
Network |
Subnet |
Host |
|
Class B subnetting |
||
|
16 |
16-x |
x |
|
Network |
Subnet |
Host |
|
Class C subnetting |
||
|
24 |
8-x |
x |
|
Network |
Subnet |
Host |
|
Classless subnetting |
|
|
32-x |
x |
|
Subnet or Prefix |
Host |
Routing
IP Routing
Host routing. A host sends a packet. If destination IP is on the same subnet, the packet is sent directly to the destination host. If destination IP is not on the same subnet, it sends the packet to the default gateway.
Router routing process:
1. Check frames FCS for errors. If errors discard.
2. Discard frame header and trailer.
3. Compare destination IP to the routing table and find route that reaches destination. This route will identify outgoing router interface and possibly, the next hop router.
4. Encapsulate IP packet inside a new frame header and trailer appropriate for the outgoing interface and forward the frame.
Routing Protocol
IP Routing Protocols
Goals of a routing protocol:
1. Dynamically learn and fill the routing table with a route to all subnets in the network.
2. When more than one route available to a subnet, place the best route in the routing table.
3. To notice when routes in table are no longer valid and remove them from the table.
4. If a route is removed and another route through a neighboring router is available add it to the routing table.
5. Add new routes and/or replace lost routes with the best available route as quickly as possible. The time between loosing a route and finding a replacement is called convergence time.
6. Prevent routing loops.
Routing protocols:
1. Each router adds a route to its routing table for each subnet connected directly to the router.
2. Each router tells its neighbours about all routes in its routing table, both directly connected routes as routes learned from its neighbours.
3. After learning a new route from a neighbour, the router adds the route to its routing table, with the next hop router being typically the neighbour from which the route was learned.
Utilities
Network layer utilities
ARP
Address Resolution protocol
It correlates MAC addresses with IP addresses. Translates layer 3 addresses into layer 2 addresses.
Inverse ARP or InARP is used to obtain layer 3 addresses from layer 2. Needed for Frame Relay (DLCI) or ATM.
Reverse ARP or RARP, was replaced with BOOTP and then DHCP.
DNS
Domain name system
It correlates URL's with IP's. Translates domain names into IP addresses.
DHCP
Dynamic host configuration protocol
DHCP defines the protocols used to allow devices to request the lease of an IP address.
DHCP uses a server that manages all IP's available on different subnets. DHCP clients can send the server a request for an IP. The server offers one and if accepted he notates it as in use. DHCP supplies to clients: IP addresses, gateway address, subnet mask and DNS servers addresses. PING
Internet control message protocol (ICMP), Packet internet groper (PING)
Ping is primary tool to test connectivity.
As we put quality first, we are content to grow slowly. Most of our referrals are word of mouth. This web site exists mainly to offer our customers a fast way to tools and utilities. You can click here to arrange a free initial consultation at your location.
* $ 36.25/Hr.based on 8 Hrs. labor job billed using our MoreforLess innovative pricing structure. Service contract of $ 19.95/mo. based on our NoHeadaches regular maintenance and customer education program.
We offer on-site Web and Information Technology Solutions in Austin, Bee Caves, Bertram, Briarcliff, Burnet, Cedar Park, Driftwood, Dripping Springs, Georgetown, Horseshoe Bay, Lake Travis, Lakeway, Leander, Marble Falls, Oak Hill, Round Rock, Spicewood and Wimberley.
CCNA Cisco study guide of the fundamentals of IP addressing and routing
The OSI layer 3 protocols defines how packets can be delivered from the computer that created them to the computer that needs to receive them. To achieve this goal, the OSI layer 3 or Network layer defines the following:
1. Routing
2. Logical Addressing
3. Routing Protocol
4. Utilities: ARP, DNS, DHCP, PING
The OSI layer 3 defines routing and logical addressing and is considered to be a network layer. OSI defines CLNS (Connectionless Network Services). Today, the only widely used layer 3 protocol is IP out of TCP/IP. The main job of IP is to route data from source host to destination host. Because the network needs to route a large number of packets, the IP routing process is simple. IP does not require any overhead agreements or messages before sending a packet, making it a connectionless protocol. IP tries to deliver a packet but if it fails, it is discarded with no error recovery. TCP provides error recovery, resending lost data.
Network layer interaction with the Data Link layer.
When the Network layer protocol sends the packet it passes it over to the Data link layer which adds the frame header and trailer to the packet creating a frame. Each router along the path strips the header and trailer and re encapsulates the packet.
IP packets and the IP header
|
IPv4 Header, standard 20 bytes |
||||
|
0-7 |
8-15 |
16-23 |
24-31 |
|
|
Version (4) |
Header Lenght (4) |
DS Field (8) |
Packet Lenght (16) |
|
|
Identification(16) |
Flags (3) |
Fragment Offset (13) |
||
|
Time to Live(8) |
Protocol (8) |
Header Checksum (16) |
||
|
Source IP Address (32) |
||||
|
Destination IP Address (32) |
||||
|
Options (1-variable) |
||||
|
Data, not part of header (0-65535-header lenght) |
||||
|
IPv4 Header fields meaning |
|||||||
|
Field |
Meaning |
||||||
|
Version |
Version of the IP protocol, 4 for IPv4, 6 for IPv6 |
||||||
|
IHL |
IP header lenght, number of 32 bit words, 160 to 480 bits |
||||||
|
DS |
Differentiated services, bits 0–2: Precedence (111 - Network Control, 110 - Internetwork Control, 101 - CRITIC/ECP, 100 - Flash Override, 011 - Flash, 010 - Immediate, 001 - Priority, 000 - Routine), bit 3: 0 = Normal Delay, 1 = Low Delay, bit 4: 0 = Normal Throughput, 1 = High Throughput, bit 5: 0 = Normal Reliability, 1 = High Reliability, bit 6: 0 = Normal Cost, 1 = Minimize Monetary Cost (defined by RFC 1349), bit 7: never defined |
||||||
|
Packet lenght |
This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 — the maximum value of a 16-bit word. The minimum size datagram that any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or packet switch in IPv4 |
||||||
|
Identification |
This field is an identification field and is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet-tracing information to datagrams in order to help trace back datagrams with spoofed source addresses. |
||||||
|
Flags |
A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order): Reserved; must be zero. As an April Fools joke, proposed for use in RFC 3514 as the "Evil bit". Don't Fragment (DF), More Fragments (MF). If the DF flag is set and fragmentation is required to route the packet then the packet will be dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation. When a packet is fragmented all fragments have the MF flag set except the last fragment, which does not have the MF flag set. The MF flag is also not set on packets that are not fragmented — an unfragmented packet is its own last fragment. |
||||||
|
Fragment offset |
The fragment offset field, measured in units of eight-byte blocks, is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 – 1) × 8 = 65,528 which would exceed the maximum IP packet length of 65,535 with the header length included. |
||||||
|
TTL |
Time to live. An eight-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1. In latencies typical in practice, it has come to be a hop count field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded. Typically, an ICMP message (specifically the time exceeded) is sent back to the sender that it has been discarded. The reception of these ICMP messages is at the heart of how traceroute works. |
||||||
|
Protocol |
This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of Protocol numbers which was originally defined in RFC 790. 1: Internet Control Message Protocol (ICMP). 2: Internet Group Management Protocol (IGMP). 6: Transmission Control Protocol (TCP). 17: User Datagram Protocol (UDP). 89: Open Shortest Path First (OSPF). 132: Stream Control Transmission Protocol (SCTP). |
||||||
|
Header Checksum |
The 16-bit checksum field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded. Note that errors in the data field are up to the encapsulated protocol to handle — indeed, both UDP and TCP have checksum fields. Since the TTL field is decremented on each hop and fragmentation is possible at each hop then at each hop the checksum will have to be recomputed. The method used to compute the checksum is defined within RFC 1071: The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented and this final value is inserted as the checksum field. To validate a header's checksum the same algorithm may be used - the checksum of the header with the checksum field filled in should be a word containing all zeros (value 0). |
||||||
|
Source IP address |
An IPv4 address is a group of four octets for a total of 32 bits. The value for this field is determined by taking the binary value of each octet and concatenating them together to make a single 32-bit value. For example, the address 10.9.8.7 would be 00001010000010010000100000000111. This address is the address of the sender of the packet. Note that this address may not be the "true" sender of the packet due to network address translation. Instead, the source address will be translated by the NATing machine to its own address. Thus, reply packets sent by the receiver are routed to the NATing machine, which translates the destination address to the original sender's address. |
||||||
|
Destination IP address |
Identical to the source address field but indicates the receiver of the packet. |
||||||
|
Options |
Additional header fields may follow the destination address field, but these are not often used. Note that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integral number of 32-bit words). The list of options may be terminated with an EOL (End of Options List, 0x00) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header. The possible options that can be put in the header are as follows: Copied, 1 bit, Set to 1 if the options need to be copied into all fragments of a fragmented packet. Option class, 2 bits, A general options category. 0 is for "control" options, and 2 is for "debugging and measurement". 1, and 3 are reserved. Option number, 5 bits, Specifies an option. Option lenght, 8 bits, Indicates the size of the entire option (including this field). This field may not exist for simple options. Option data, variable, Option-specific data. This field may not exist for simple options. If the Header Length is greater than 5, i.e. it is between 6-15, it means that the Options field is present and must be considered. The Copied, Option Class, and Option Number are sometimes referred to as a single eight-bit field - the Option Type. The use of the LSRR and SSRR options (Loose and Strict Source and Record Route) is discouraged because they create security concerns; many routers block packets containing these options. |
||||||
|
Data |
The last field is not a part of the header and, consequently, not included in the checksum field. The contents of the data field are specified in the protocol header field and can be any one of the transport layer protocols. |
||||||
Logical Addressing
Classes of networks
|
Public network classes |
|||||||
|
Class |
Leading bits |
First octet range |
Number of networks |
Addresses per network |
Start address |
End address |
Last valid network number |
|
A |
0 |
1 to 126 |
126 (2^7-2) |
16,777,214 (2^24-2) |
1.0.0.0 |
126.255.255.255 |
126.0.0.0 |
|
B |
10 |
128 to 191 |
16,384 (2^14) |
65,534 (2^16-2) |
128.0.0.0 |
191.255.255.255 |
191.255.0.0 |
|
C |
110 |
192 to 223 |
2,097,150 (2^21-2) |
256 (2^8) |
192.0.0.0 |
223.255.255.255 |
223.255.255.0 |
|
Multicast (Formerly class D) |
1110 |
224 to 239 |
not defined |
not defined |
224.0.0.0 |
239.255.255.255 |
not defined |
|
Reserved (Formerly class E) |
1111 |
240 to 255 |
not defined |
not defined |
240.0.0.0 |
255.255.255.255 |
not defined |
|
Private network classes |
|||
|
Class |
Start IP |
Finish IP |
Number of addresses |
|
A |
10.0.0.0 |
10.255.255.255 |
16,777,216 |
|
B |
172.16.0.0 |
172.31.255.255 |
1,048,576 |
|
C |
192.168.0.0 |
192.168.255.255 |
65,536 |
|
Reserved addresses blocks |
|||||
|
CIDR |
Start IP |
End IP |
Description |
||
|
0.0.0.0/8 |
0.0.0.0 |
0.255.255.255 |
Current network |
||
|
10.0.0.0/8 |
10.0.0.0 |
10.255.255.255 |
Private network class A |
||
|
127.0.0.0/8 |
127.0.0.0 |
127.255.255.255 |
Loopback |
||
|
169.254.0.0/16 |
169.254.0.0 |
|
169.254.255.255 |
Link-Local |
|
|
172.16.0.0/12 |
172.16.0.0 |
|
172.31.255.255 |
Private network class B |
|
|
192.0.0.0/24 |
192.0.0.0 |
|
192.0.0.255 |
Reserved IANA |
|
|
192.0.2.0/24 |
192.0.2.0 |
|
192.0.2.255 |
TEST-NET-1 |
|
|
192.88.99.0/24 |
192.88.99.0 |
|
192.88.99.255 |
IPv6 to IPv4 relay |
|
|
192.168.0.0/16 |
192.168.0.0 |
|
192.168.255.255 |
Private network class C |
|
|
198.18.0.0/15 |
198.18.0.0 |
|
198.19.255.255 |
Network benchmark tests |
|
|
198.51.100.0/24 |
198.51.100.0 |
|
198.51.100.255 |
TEST-NET-2 |
|
|
203.0.113.0/24 |
203.0.113.0 |
|
203.0.113.255 |
TEST-NET-3 |
|
|
224.0.0.0/4 |
224.0.0.0 |
|
239.255.255.255 |
Multicast (Former class D) |
|
|
240.0.0.0/4 |
240.0.0.0 |
|
255.255.255.255 |
Reserved (Former class E) |
|
|
255.255.255.255 |
255.255.255.255 |
|
255.255.255.255 |
Broadcast |
|
IP subnetting
Subnet = Subdivided Network
|
Class A subnetting |
||
|
8 |
24-x |
x |
|
Network |
Subnet |
Host |
|
Class B subnetting |
||
|
16 |
16-x |
x |
|
Network |
Subnet |
Host |
|
Class C subnetting |
||
|
24 |
8-x |
x |
|
Network |
Subnet |
Host |
|
Classless subnetting |
|
|
32-x |
x |
|
Subnet or Prefix |
Host |
Routing
IP Routing
Host routing. A host sends a packet. If destination IP is on the same subnet, the packet is sent directly to the destination host. If destination IP is not on the same subnet, it sends the packet to the default gateway.
Router routing process:
1. Check frames FCS for errors. If errors discard.
2. Discard frame header and trailer.
3. Compare destination IP to the routing table and find route that reaches destination. This route will identify outgoing router interface and possibly, the next hop router.
4. Encapsulate IP packet inside a new frame header and trailer appropriate for the outgoing interface and forward the frame.
Routing Protocol
IP Routing Protocols
Goals of a routing protocol:
1. Dynamically learn and fill the routing table with a route to all subnets in the network.
2. When more than one route available to a subnet, place the best route in the routing table.
3. To notice when routes in table are no longer valid and remove them from the table.
4. If a route is removed and another route through a neighboring router is available add it to the routing table.
5. Add new routes and/or replace lost routes with the best available route as quickly as possible. The time between loosing a route and finding a replacement is called convergence time.
6. Prevent routing loops.
Routing protocols:
1. Each router adds a route to its routing table for each subnet connected directly to the router.
2. Each router tells its neighbours about all routes in its routing table, both directly connected routes as routes learned from its neighbours.
3. After learning a new route from a neighbour, the router adds the route to its routing table, with the next hop router being typically the neighbour from which the route was learned.
Utilities
Network layer utilities
ARP
Address Resolution protocol
It correlates MAC addresses with IP addresses. Translates layer 3 addresses into layer 2 addresses.
Inverse ARP or InARP is used to obtain layer 3 addresses from layer 2. Needed for Frame Relay (DLCI) or ATM.
Reverse ARP or RARP, was replaced with BOOTP and then DHCP.
DNS
Domain name system
It correlates URL's with IP's. Translates domain names into IP addresses.
DHCP
Dynamic host configuration protocol
DHCP defines the protocols used to allow devices to request the lease of an IP address.
DHCP uses a server that manages all IP's available on different subnets. DHCP clients can send the server a request for an IP. The server offers one and if accepted he notates it as in use. DHCP supplies to clients: IP addresses, gateway address, subnet mask and DNS servers addresses. PING
Internet control message protocol (ICMP), Packet internet groper (PING)
Ping is primary tool to test connectivity.
As we put quality first, we are content to grow slowly. Most of our referrals are word of mouth. This web site exists mainly to offer our customers a fast way to tools and utilities. You can click here to arrange a free initial consultation at your location.
* $ 36.25/Hr.based on 8 Hrs. labor job billed using our MoreforLess innovative pricing structure. Service contract of $ 19.95/mo. based on our NoHeadaches regular maintenance and customer education program.
We offer on-site Web and Information Technology Solutions in Austin, Bee Caves, Bertram, Briarc
Last Updated (Saturday, 23 April 2011 15:11)
