Creating ACLs

Creating ACLs
11.1.3 This page will explain how ACLs are created in global configuration mode. There are many types of ACLs. This lesson explains standard ACLs, extended ACLs, and named ACLs. When ACLs are configured on a router, each ACL must have a unique identification number assigned to it. This number identifies the type of access list created and must fall within the specific range of numbers that is valid for that type of list. 

After the proper command mode is entered and the list type number is decided upon, the user enters the access list statements using the keyword access-list, followed by the proper parameters. After the proper command mode is entered and the list type number is set, the user enters the access list statements with the access-list command followed by the proper parameters. This is the first of the two-step process. The second step of the process is assigning the ACL to the proper interface. 

In TCP/IP, ACLs are assigned to one or more interfaces and can filter inbound traffic or outbound traffic by using the ip access-group command in interface configuration mode. The access-group command is issued in the interface configuration mode. When an ACL is assigned to an interface, inbound or outbound placement should be specified. The filter direction can be set to check packets that travel into or out of an interface. To determine if an ACL controls inbound or outbound traffic, the network administrator must view the interfaces as if looking at them from inside the router. This is a very important concept. Traffic that travels into an interface is filtered by the inbound access list. Traffic going out of an interface is filtered by the outbound access list. After a numbered ACL is created, it must be assigned to an interface. An ACL containing numbered ACL statements cannot be altered. It must be deleted by using the no access-list list-number command and then recreated. 

Use the following rules to create and apply access lists:

• There should be one access list per protocol per direction.
• Standard access lists should be applied closest to the destination.
• Extended access lists should be applied closest to the source.
• The inbound or outbound interface should be referenced as if looking at the port from inside the router.
• Statements are processed sequentially from the top of the list to the bottom until a match is found. If no match is found then the packet is denied, and discarded.
• There is an implicit deny any at the end of all access lists. This will not appear in the configuration listing.
• Access list entries should filter in the order from specific to general. Specific hosts should be denied first, and groups or general filters should come last.
• The match condition is examined first. The permit or deny is examined only if the match is true.
• Never work with an access list that is actively applied.
• A text editor should be used to create comments that outline the logic. Then fill in the statements that perform the logic.
• New lines are always added to the end of the access list. A no access-list x command will remove the whole list. It is not possible to selectively add and remove lines with numbered ACLs
• An IP access list will send an ICMP host unreachable message to the sender of the rejected packet and will discard the packet in the bit bucket.
• An access list should be removed carefully. If an access list that is applied to a production interface is removed, some versions of IOS will apply a default deny any to the interface and all traffic will be halted.
• Outbound filters do not affect traffic that originates from the local router.

The Lab Activity will help students become more familiar with the syntax that is used to create an ACL.

The next page will discuss wildcard masks.

How ACLs work

How ACLs work 
11.1.2 An ACL is made up of statements that define whether packets are accepted or rejected at inbound and outbound interfaces. This page will explain how these statements are edited and added to an ACL. These decisions are made by matching a condition statement in an access list and then performing the accept or reject action defined in the statement.

The order in which ACL statements are placed is important. The Cisco IOS software tests the packet against each condition statement in order from the top of the list to the bottom. Once a match is found in the list, the accept or reject action is performed and no other ACL statements are checked. If a condition statement that permits all traffic is located at the top of the list, no statements added below that will ever be checked.

If additional condition statements are needed in an access list, the entire ACL must be deleted and recreated with the new condition statements. To make the process of revising an ACL simpler it is a good idea to use a text editor such as Notepad and paste the ACL into the router configuration.

The beginning of the router process is the same, whether ACLs are used or not. As a frame enters an interface, the router checks to see whether the Layer 2 address matches or if it is a broadcast frame. If the frame address is accepted, the frame information is stripped off and the router checks for an ACL on the inbound interface. If an ACL exists, the packet is now tested against the statements in the list. If the packet matches a statement, the packet is either accepted or rejected. If the packet is accepted in the interface, it will then be checked against routing table entries to determine the destination interface and switched to that interface. Next, the router checks whether the destination interface has an ACL. If an ACL exists, the packet is tested against the statements in the list. If the packet matches a statement, it is either accepted or rejected. If there is no ACL or the packet is accepted, the packet is encapsulated in the new Layer 2 protocol and forwarded out the interface to the next device.

As a review, ACL statements operate in sequential, logical order. If a condition match is true, the packet is permitted or denied and the rest of the ACL statements are not checked. If all the ACL statements are unmatched, an implicit deny any statement is placed at the end of the list by default. The invisible deny any statement at the end of the ACL will not allow unmatched packets to be accepted. When first learning how to create ACLs, it is a good idea to add the deny any at the end of ACLs to reinforce the dynamic presence of the implicit deny.

The next page will describe how ACLs are created

Access Control List Fundamentals / Introduction to ACLs

Access Control List Fundamentals 
Introduction to ACLs
11.1.1 This page will explain what ACLs are and how they are used.

ACLs are lists of conditions used to test network traffic that tries to travel across a router interface. These lists tell the router what types of packets to accept or deny. Acceptance and denial can be based on specified conditions. ACLs enable management of traffic and secure access to and from a network.

ACLs can be created for all routed network protocols such as IP and Internetwork Packet Exchange (IPX). ACLs can be configured at the router to control access to a network or subnet.

To filter network traffic, ACLs determine if routed packets are forwarded or blocked at the router interfaces. The router examines each packet and will forward or discard it based on the conditions specified in the ACL. An ACL makes routing decisions based on source address, destination address, protocols, and upper-layer port numbers.

ACLs must be defined on a per protocol, per direction, or per port basis. To control traffic flow on an interface, an ACL must be defined for each protocol enabled on the interface. ACLs control traffic in one direction at a time on an interface. Two separate ACLs must be created to control inbound and outbound traffic. Every interface can have multiple protocols and directions defined. If the router has two interfaces configured for IP, AppleTalk, and IPX, 12 separate ACLs would be needed. There would be one ACL for each protocol, times two for each direction, times two for the number of ports.

ACLs can be used to perform the following tasks:

• Limit network traffic and increase network performance. For example, ACLs that restrict video traffic could greatly reduce the network load and increase network performance.
• Provide traffic flow control. ACLs can restrict the delivery of routing updates. If updates are not required because of network conditions, bandwidth is preserved.
• Provide a basic level of security for network access. ACLs can allow one host to access a part of the network and prevent another host from accessing the same area. For example, Host A is allowed to access the Human Resources network and Host B is prevented from accessing it.
• Decide which types of traffic are forwarded or blocked at the router interfaces. ACLs can permit e-mail traffic to be routed, but block all Telnet traffic.
• Control which areas a client can access on a network.
• Screen hosts to permit or deny access to a network segment. ACLs can be used to permit or deny a user to access file types such as FTP or HTTP.

If ACLs are not configured on the router, all packets that pass through the router will be permitted to access the entire network.
The next page will describe how ACLs work.

Module 11: Access Control Lists (ACLs) / Overview

Overview

Network administrators must be able to deny unwanted access to a network and allow authorized users to access necessary services. Security tools such as passwords, callback equipment, and physical security devices are helpful. However, they often lack the flexibility of basic traffic filters and the specific controls that most administrators prefer. For example, a network administrator may want to allow users access to the Internet, but not permit external users Telnet access into the LAN.

Routers provide the capability to filter traffic, such as blocking Internet traffic, with access control lists (ACLs). An ACL is a sequential list of permit or deny statements that apply to addresses or upper-layer protocols. This module will introduce standard and extended ACLs as a way to control network traffic and explain how they are used as part of a security solution.

This module includes tips, considerations, recommendations, and general guidelines on how to use ACLs. It also includes the commands and configurations needed to create ACLs. Finally, this module provides examples of standard and extended ACLs and describes ACL placement on router interfaces.

An ACL can be as simple as a single line that permits packets from a specific host or it can be a complex set of rules and conditions that defines network traffic and determines the router processes. While many of the advanced uses of ACLs are beyond the scope of this course, this module provides details about standard and extended ACLs, the proper placement of ACLs, and some special applications of ACLs.

This module covers some of the objectives for the CCNA 640-801 and ICND 640-811 exams. 
Students who complete this module should be able to perform the following tasks: 

• Describe the differences between standard and extended ACLs
• Explain the rules for placement of ACLs
• Create and apply named ACLs
• Describe the function of firewalls

Use ACLs to restrict virtual terminal access 

Summary of Module 10

Summary

This page summarizes the topics discussed in this module. The transport layer of the OSI model is responsible for the reliable transport and regulation of data flow from a source to a destination. TCP makes sure that each host on the network is ready and willing to communicate. A three-way handshake is a process that ensures that each side is ready for data transmission and allows each device to determine the initial sequence number. A three-way handshake starts with a host initiating a connection. The other host receives a packet, records a sequence number and then replies with an ACK. The initiating host then responds back and finalizes the connection. DoS attacks are designed to deny services to legitimate hosts that attempt to establish connections. It is used by hackers to halt system response. SYN flooding is one type of DoS attack. It exploits the normal three-way handshake and causes targeted devices to ACK to source addresses that will not complete the handshake. Spoofing occurs when a receiving device replies to a non-existent, unreachable IP address and is placed in a wait state until it receives the final ACK from the initiator. In addition to software specifically created as a defense against these kinds of attacks, an administrator can decrease the connection timeout period and increase the connection queue size. Breaking data into smaller pieces is called segmenting and is done with TCP. Once the data is segmented, it must be transmitted to the destination device. TCP applies sequence numbers to the data segments so that the receiver can reassemble the bytes properly and the sender knows when all the segments have been received. Windowing is the process of flow control that regulates how much data is sent during a given transmission period. TCP uses a sliding window when determining transmission size. A sliding window allows for devices to negotiate a window size to allow for more than one byte to be sent during a single transmission. Many protocols use PAR to provide reliability. With PAR, the source sends a packet, starts a timer, and waits for an ACK before it sends the next packet. If the timer expires before the source receives an ACK, the source retransmits the packet and resets the timer. TCP uses expectational ACKs in which the Acknowledgment Number refers to the next octet that is expected. UDP provides connectionless, non-guaranteed transmission of packets at Layer 4 of the OSI model. Since UDP does not use windowing or acknowledgments, application layer protocols must provide error detection. A port number must be associated with the conversation between hosts to ensure that the packet reaches the appropriate service on the server. Port numbers have the following assigned ranges: The Well Known Ports are those from 0 through 1023 The Registered Ports are those from 1024 through 49151 The Dynamic and/or Private Ports are those from 49152 through 65535 The three methods of addressing include port numbers, which are located at the transport layer and serviced by the network layer. The network layer assigns the logical or IP address and the data link layer assigns the physical or MAC address.

Comparison of MAC addresses, IP addresses, and port numbers

Comparison of MAC addresses, IP addresses, and port numbers 
10.2.6 This page will describe the three types of addresses in reference to the OSI model. Port numbers are located at the transport layer and are serviced by the network layer. The network layer assigns the logical address, or IP address, and is then serviced by the data link layer, which assigns the physical address, or MAC address.
A good analogy can be made with a normal letter. The address on a letter consists of a name, street, city, and state. These can be compared to the port, MAC, and IP address used for network data. The name on the envelope would be equivalent to a port number, the street address is the MAC, and the city and state is the IP address. Multiple letters can be mailed to the same street address, city and state, but contain different names on the letters. For instance, two letters could be mailed to the same house with one addressed to “John Doe” and the other to “Jane Doe”. This is analogous to multiple sessions with different port numbers. 
This page concludes this lesson. The next page will summarize the main points from this module. 

Port numbering and well-known port numbers / Example of multiple sessions between hosts

Port numbering and well-known port numbers

10.2.4 This page will discuss the three categories of port numbers.

Port numbers are represented by 2 bytes in the header of a TCP or UDP segment. This 16-bit value can result in port numbers ranging from 0 to 65535. The three categories of port numbers are well-known ports, registered ports, and dynamic or private ports. The first 1023 ports are well-known ports. These ports are used for well-known network services such as FTP, Telnet, or DNS. 

Registered ports range from 1024 to 49151. Ports between 49152 and 65535 are defined as dynamic or private ports.

The Interactive Media Activity will help students become more familiar with port numbers.

The next page will give an example of multiple sessions.

Example of multiple sessions between hosts 

10.2.5 This page will explain how port numbers are used to track multiple sessions that can occur between hosts. The source and destination port numbers combine with the network address to form a socket. A pair of sockets, one on each host, forms a unique connection. For instance, a host might have a Telnet connection through port 23 and an Internet connection through port 80. The IP and the MAC addresses would be the same because the packets are received from the same host. Therefore, each conversation on the source side needs its own port number, and each service requested needs its own port number.

In the Lab Activity, students will enable HTTP on a router and observe well-known ports.
The next page will discuss the three types of addresses.

Ports for clients

Ports for clients

10.2.3 This page will discuss source ports, which are set by clients.

Whenever a client connects to a service on a server, a source and destination port must be specified. TCP and UDP segments contain fields for source and destination ports. Destination ports, or ports for services, are normally defined using the well-known ports. Source ports set by the client are determined dynamically.

In general, a client determines the source port by randomly assigning a number above 1023. For example, a client that attempts to communicate with a Web server will use TCP and assign the destination port as 80 and the source port as 1045. When the packet arrives at the server, it moves up to the transport layer and eventually to the HTTP service, which operates at port 80. The HTTP server responds to the clients request with a segment that uses port 80 as the source and 1045 as the destination. Clients and servers use ports to distinguish which process each segment is associated with.

The next page will teach students about the three categories of port numbers.

Ports for services

Ports for services
10.2.2 Services running on hosts must have a port number assigned to them so communication can occur. A remote host attempting to connect to a service expects that service to use specific transport layer protocols and ports. Some ports, which are defined in RFC 1700, are known as the well-known ports. These ports are reserved in both TCP and UDP. 

These well-known ports define applications that run above the transport layer protocols. For example, a server that runs FTP will use ports 20 and 21 to forward TCP connections from clients to its FTP application. This allows the server to determine which service a client requests. TCP and UDP use port numbers to determine the correct service to which requests are forwarded.

The next page will discuss ports in greater detail.

Multiple conversations between hosts

Multiple conversations between hosts
10.2.1 At any given moment, thousands of packets that provide hundreds of different services travel through a modern network. Many servers use a multitude of services and this causes unique problems for the addressing of packets. If a server is running both SMTP and HTTP, it uses the destination port field to determine what service the source is requesting. The source cannot construct a packet destined for just the server IP address because the destination would not know what service was being requested. A port number must be associated with the conversation between hosts to ensure that the packet reaches the appropriate service on the server. If a server could not distinguish between different conversations, a client could not send an e-mail and browse a Web page at the same time. A method for transport layer conversations to be separated must be used.

Hosts running TCP/IP associate ports at the transport layer with certain applications. Port numbers are used to keep track of different conversations that cross the network at the same time. Port numbers are needed for a host to communicate with a server that uses multiple services. Both TCP and UDP use port or socket numbers to pass information to the upper layers.

Application software developers have agreed to use the well-known port numbers that are defined in RFC1700. Any conversation bound for the FTP application uses the standard port number 21. Conversations that do not involve applications with well-known port numbers are assigned port numbers that have been randomly selected from within a specific range. These port numbers are used as source and destination addresses in the TCP segment. 

Port numbers have the following assigned ranges:

• The Well Known Ports are those from 0 through 1023
• The Registered Ports are those from 1024 through 49151
• The Dynamic and/or Private Ports are those from 49152 through 65535

Systems initiating communication requests use port numbers to select proper applications. Source port numbers for these requests are dynamically assigned by the originating host, and are usually a number larger than 1023. Port numbers in the range of 0-1023 are considered public port numbers and are controlled by the Internet Assigned Numbers Authority (IANA).

Post office box numbers are a good analogy for port numbers. A piece of mail may be sent to a zip code, city, and P.O. box. The zip code and city direct mail to the correct general mail facility while the P.O. box ensures the item is delivered to the one individual to whom the mail is addressed. Similarly, the IP address gets the packet to the correct server, but the TCP or UDP port number guarantees the packet is passed to the correct application.

The next page will discuss well-known ports.

UDP operation

UDP operation
10.1.7 This page will explain the similarities and differences between TCP and UDP.

The TCP/IP protocol stack contains many different protocols, each designed to perform a certain task. IP provides Layer 3 connectionless transport through an internetwork. TCP enables connection-oriented, reliable transmission of packets at Layer 4 of the OSI model. UDP provides connectionless, unreliable transmission of packets at Layer 4 of the OSI model.

Both TCP and UDP use IP as their Layer 3 protocol. In addition, TCP and UDP are used by various application layer protocols. TCP provides services for applications such as FTP, HTTP, SMTP, and DNS. UDP is the transport layer protocol used by DNS, TFTP, SNMP, and DHCP. 

TCP must be used when applications need to guarantee that a packet arrives intact, in sequence, and unduplicated. The overhead necessary to ensure delivery of a packet is sometimes a problem with TCP. Not all applications need to guarantee delivery of the data packet, so they use the faster, connectionless delivery mechanism afforded by UDP. The UDP protocol standard is described in RFC 768.

UDP does not use windowing or ACKs so application layer protocols must provide error detection. 

The Source Port field is an optional field used only if information needs to return to the sending host. When a destination router receives a routing update, the source router is not requesting anything so nothing needs to return to the source. There is no exchange of information or data. The Destination Port field specifies the application to which UDP needs to pass the protocol. A DNS request from a host to a DNS server would have a Destination Port field of 53, the UDP port number for DNS. The Length field identifies the number of octets in the UDP segment. The UDP checksum is optional but should be used to ensure that the data has not been damaged during transmission. For transport across the network, UDP is encapsulated within the IP packet.

Once a UDP segment arrives at the destination IP address, a mechanism must exist which allows the receiving host to determine the exact destination application. Destination ports are used for this purpose. If a host is running both TFTP and DNS services, it must be able to determine what service the arriving UDP segments need. The Destination Port field in the UDP header determines the application to which a UDP segment will be delivered.

This page concludes this lesson. The next lesson will provide an overview of transport layer ports. The first page describes multiple conversations between hosts

Positive acknowledgments

Positive acknowledgments

10.1.6 Acknowledgment is a common step in the synchronization process, which includes sliding windows and data sequencing. In a TCP segment, the sequence number field is followed by the Acknowledgment Number field. This field is where tracking of transmitted and received bytes are indicated.

One problem with the IP protocol is that there is no verification method to determine if data segments reach their destination. So data segments may be constantly forwarded with no knowledge as to whether or not they were actually received. TCP uses positive acknowledgment and retransmission (PAR) to control data flow and confirm data delivery.

Many protocols use PAR to provide reliability. With PAR, the source sends a packet, starts a timer, and waits for an acknowledgment before it sends the next packet in the session. If the timer expires before the source receives an acknowledgment, the source retransmits the packet and resets the timer. The acknowledgment is provided by the value of Acknowledgment Number and the ACK flag set in the TCP header. TCP uses expectational acknowledgment in which the Acknowledgment Number value refers to the next octet that is expected as part of the TCP session.

Windowing is a flow control mechanism that requires the source device to receive an acknowledgment from the destination after a specific amount of data bytes has been transmitted. With a window size of three, the source device can send three octets to the destination. It must then wait for an acknowledgment of these bytes. If the destination receives the three octets, it sends an acknowledgment to the source device, which can then transmit three more octets. If the destination does not receive the three octets, it does not send an acknowledgment. This may be caused by overflowing buffers or packets lost in transit. Since the source does not receive an acknowledgment, it knows that the octets should be retransmitted and that the window size should be reduced. This window size reduction provides the receiving host less bytes to process from its buffers before more data arrives. This effectively slows the communication between hosts to provide more reliability between the hosts.

The Lab Activity will teach students how to enable and monitor multiple host sessions. The Interactive Media Activity will help students become more familiar with windows.

The next page will explain how UDP works. 

Sequencing numbers

Sequencing numbers 

10.1.5 TCP breaks data into segments. After the synchronization process occurs and the window size has been established, the data segments are transported from the sender to the receiver. The data segments must be reassembled after all the data is received. There is no guarantee that the data will arrive in the order it was transmitted. TCP applies sequence numbers to the data segments that are transmitted so that the receiver can reassemble the bytes in their original order. This way, if TCP segments arrive out of order, the segments will still be assembled correctly.

These sequencing numbers also act as reference numbers so that the receiver will know if it has received all of the data. They also identify the missing data pieces to the sender so it can retransmit the missing data. This offers increased efficiency since the sender only needs to resend the missing segments instead of the entire set of data.

Each TCP segment is numbered before transmission. 

The sequence number portion comes after the destination port in the segment format. At the receiving station, TCP uses the sequence numbers to reassemble the segments into a complete message. If a sequence number is missing in the series, that segment is retransmitted.

The next page discusses positive acknowledgments.

Windowing and window size

Windowing and window size 
10.1.4 The amount of data that needs to be transmitted is often too large to be sent in a single data segment. In this case, the data must be broken into smaller pieces to allow for proper data transmission. TCP is responsible for breaking data into segments. This can be compared to the way that small children are fed. Their food is cut into smaller pieces that their mouths can accommodate. Additionally, a device may not be able to receive data as quickly as the source can send it. The device may be busy with other tasks or the sender may be a more robust device.

Once the data is segmented, it must be transmitted to the destination device. One of the services provided by TCP is flow control, which regulates how much data is sent during a given transmission period. The process of flow control is known as windowing.

Window size determines the amount of data that can be transmitted at one time before the destination responds with an acknowledgment. After a host transmits the window-sized number of bytes, the host must receive an acknowledgment that the data has been received before it can send any more data. For example, if the window size is 1, each byte must be acknowledged before the next byte is sent. 

TCP utilizes windowing to dynamically determine transmission size. Devices negotiate a window size to allow a specific number of bytes to be transmitted before an acknowledgment. 

This process of dynamically varying the window size increases reliability. The window size can be varied based upon acknowledgments.

The Interactive Media Activity will help students understand the concept of windowing.

The next page describes TCP sequence numbers.

Denial of service attacks

Denial of service attacks 
10.1.3 his page will teach students about denial of service (DoS) attacks. DoS attacks are designed to deny services to legitimate hosts that try to establish connections. DoS attacks are commonly used by hackers to halt system responses. One type of DoS is known as SYN flooding. SYN flooding exploits the normal three-way handshake and causes targeted devices to acknowledge to source addresses that will not complete the handshake.

The three-way handshake begins when the initiating host sends a SYN packet. The SYN packet includes the source IP address and the destination IP address. This source and destination address information is used by the recipient to send the acknowledgment packet back to the initiating device. 

In a DoS attack, the hacker initiates a SYN but spoofs the source IP address. Spoofing is a term used when the receiving device replies to a non-existent, unreachable IP address and then is placed in a wait state until it receives the final acknowledgment from the initiator. The waiting request is placed in a connection queue or a holding area in memory. This wait state requires the attacked device to use system resources, such as memory, until the connection timer times out. Hackers will flood the attacked host with false SYN requests to utilize all of its connection resources and prevent it from responding to legitimate connection requests.

To defend against these attacks, system administrators may decrease the connection timeout period and increase the connection queue size. Software also exists that can detect these types of attacks and initiate defensive measures.

The next page will discuss the concept of windowing.

Synchronization or three-way handshake

Synchronization or three-way handshake 
10.1.2 This page will explain the synchronization process that TCP uses. The process is also called a three-way handshake.

TCP is a connection-oriented protocol. Prior to data transmission, the two communicating hosts go through a synchronization process to establish a virtual connection for each session between hosts. This synchronization process ensures that both sides are ready for data transmission and allows the devices to determine the initial sequence numbers for that session. This process is known as a three-way handshake. This is a three-step process that establishes the virtual connection between the two devices. It is also important to note that the three-way handshake is initiated by a client host. To establish a TCP session, the client host will use the well-known port number of the service it wishes to contact on a server host.

In step one, the initiating host (client) sends a synchronization (SYN flag set) packet to initiate a connection. This indicates that a packet has a valid initial Sequence Number value in this segment for this session of x. The SYN bit set in the header indicates a connection request. The SYN bit is single bit in the code field of the TCP segment header. The Sequence Number is a 32 bit field TCP segment header.

In step two, the other host receives the packet, records the Sequence Number of x from the client, and replies with an acknowledgment (ACK flag set). The ACK control bit set indicates that the Acknowledgment Number field contains a valid acknowledgment value. The ACK flag is a single bit in the code field of the TCP segment header and the Acknowledgment Number is a 32 bit field TCP segment header. Once a connection is established, the ACK flag is set for all segments during the session. The Acknowledgment Number field contains the next sequence number that this host is expecting to receive (x + 1). The Acknowledgment Number of x + 1 means the host has received all bytes up to and including x, and expects to next receive byte x + 1. The host also initiates a return session. This includes a TCP segment with its own initial Sequence Number value of y and with the SYN flag set.

In step three, the initiating host responds with a simple Acknowledgment Number value of y + 1, which is the Sequence Number value of Host B + 1. This indicates that it received the previous acknowledgment and finalizes the connection process for this session.

It is important to understand that initial sequence numbers are used to initiate communication between two devices. They act as reference starting numbers between the two devices. The sequence numbers give each host a way to acknowledge so that the receiver knows the sender is responding to the proper connection request.

The Interactive Media Activity will help students understand synchronization.

The next page will discuss denial of service attacks

TCP Operation

TCP Operation 
10.1.1This page will explain how the transport layer provides reliability and flow control.
IP addresses allow for the routing of packets between networks. However, IP makes no guarantees about delivery. The transport layer is responsible for the reliable transport of and regulation of data flow from source to destination. This is accomplished through the use of sliding windows and sequencing numbers along with a synchronization process. This process ensures that each host is ready and willing to communicate. 
To understand reliability and flow control, think of a student who studies a foreign language for one year. Now imagine the student visits a country where the language is used. The student must ask people to repeat their words for reliability and to speak slowly for comprehension, which relates to the concept of flow control. The transport layer, which is Layer 4 of the OSI model, uses TCP to provide these services to Layer 5.
The next page will describe the concept of synchronization.

Module 10: Intermediate TCP/IP / Overview

Module 10: Intermediate TCP/IP

Overview

Routers use the IP address information in an IP packet header to determine the interface to which a packet should be switched based on its destination. Since IP does not ensure that the packet reaches the destination, it is described as an unreliable, connectionless protocol, that uses best-effort delivery. If packets are dropped in route, arrive in the wrong order, or are transmitted faster than the receiver can accept them, IP alone cannot correct the problem. To address these problems, IP relies on TCP. This module describes TCP and its functions and introduces UDP, another important Layer 4 protocol.
Each layer within the OSI reference model has various functions. These functions are independent of the other layers. Each layer expects to receive services from the layer beneath it, and each layer provides certain services to the layer above it. The application, presentation, and session layers of the OSI model, which are all considered to be part of the application layer in the TCP/IP model, access the services of the transport layer through logical entities called ports. This module will introduce the concept of ports and will explain the critical importance of ports and port numbers in data networking.
This module covers some of the objectives for the CCNA 640-801, INTRO 640-821, and ICND 640-811 exams. - 
Students who complete this module should be able to perform the following tasks: 

• Describe TCP and its functions
• Describe TCP synchronization and flow control
• Describe UDP operation and processes
• Identify common port numbers
• Describe multiple conversations between hosts
• Identify ports used for services and clients
• Describe port numbering and well known ports

Understand the differences and the relationship between MAC addresses, IP addresses, and port numbers 

Module 9: Summary

Summary
The show ip route command is used to gather detailed information about the routes installed on the router. It displays the contents of the IP routing table. New routes may be added with static routing, which allows an administrator to manually define routes, or with dynamic routing, which uses the rules defined by a routing protocol to exchange information and determine the best path.
Default routes are used when the router is unable to match a destination network with a more specific entry in the routing table. The router uses this default route to reach the gateway of last resort in an effort to forward the packet.
The path determination function occurs at the network layer of the OSI model. It enables a router to evaluate the available paths to a destination and to establish the preferred handling of a packet. This information is configured manually or collected dynamically. The administrative distance of the route is used by the router to decide what the best path is to a particular destination. The administrative distance is a number that measures the trustworthiness of the source of the route information. Lower administrative distances indicate more trustworthy sources.
To determine the best route to a destination, routing protocols use a value that measures the desirability of a route called a metric. The metric is usually determined by factors such as hop count, bandwidth, delay, load, reliability, and cost. Typically, the smaller the metric number, the better the path.
Troubleshooting should be an orderly process based on the networking standards set in place by an administrator. Documentation is an important part of the troubleshooting process. Indicator lights are a useful tool for troubleshooting at Layer 1. At Layer 3, ping is used to test network connectivity. Telnet connections are used to verify the application layer software between a source and a destination.
The show interfaces command shows the status of two important portions of the interfaces. They are the physical or hardware portion and logical or software portion. These can be related to the Layer 1 and the Layer 2 functions. If the interface is up and the line protocol is down, a Layer 2 problem exists. If the physical layer is properly functioning, then all other directly connected Cisco devices should be displayed. If no known device appears, a Layer 1 problem likely exists.
To debug connectivity issues, the show cdp neighbors command is used to display information about directly connected neighbors. Use the traceroute command to trace the routes that packets take to destinations. This command can be used to test the network layer at each hop and provide performance benchmarks.
To verify the routing protocol configuration, use the show ip protocols and show ip route commands. These commands display information about routing protocols and the routing table. To determine the type of cable connected without inspecting the cables, use the show controllers command.
The debug command is used to display dynamic data and events. Since the show commands only display static information, they provide a historical picture of the router operation. The debug command output gives more insight to the current events of the router.

Introduction to debug

Introduction to debug 
9.3.7 This page will explain the functions of the debug command.
The debug commands assist in the isolation of protocol and configuration problems. The debug command is used to display dynamic data and events. Since the show commands only display static information, they provide a historical picture of the router operation. The debug command output gives more insight into the current events of the router. These events could be traffic on an interface, error messages generated by nodes on the network, protocol-specific diagnostic packets, and other useful troubleshooting data. The dynamic output of the debug command creates performance issues. This command produces high processor overhead that may disrupt normal router operation. For this reason, debug should be used conservatively. Use debug commands to examine specific types of traffic or problems after likely problems have been narrowed a few causes. The debug command should be used to isolate problems and not to monitor normal network operation.

WARNING: The debug all command should be used sparingly as this can disrupt router operations.

By default, the router sends the debug output and system messages to the console. If a Telnet session is used to examine the router, then the debug output and system messages can be redirected to the remote terminal. This is done through the Telnet session with the terminal monitor command. Use extra caution when the debug commands are selected from a Telnet session. No command should be selected that will cause the debug output to create additional traffic that creates debug output. If this occurs, the Telnet session will rapidly saturate the link with traffic or the router will exhaust one or more resources. A good rule to follow to prevent this recursion of traffic is to never debug any activity on the port where the session is established.
The output of the different debug commands varies. Some may frequently generate many lines while others produce a line or two of output every few minutes.  
Another IOS software service that will enhance the usefulness of the debug output is the timestamps command. This command will put a timestamp on a debug message. This information provides the time when the debug event occurred and the duration of time between events.
This is often very useful when troubleshooting intermittent problems. By time stamping the output, a pattern of occurrence is often recognized. This helps to isolate the source of the problem. This also prevents the technician from intently watching the debug output for what may seem like hours.
The following command configures a timestamp that will show the hour:minute:second of the output, the amount of time since the router was last powered up, or when a reload command was executed:

GAD(config)#service timestamps debug uptime

The output from this is useful to determine the time between events. To determine how long since the last occurrence of the debug event, the time since the last reload has to be used as a reference. This time can be found with the show version command.
A more practical use of the timestamps is to have it display the time and date that the event occurred. This will simplify the process of determining the last occurrence of the debug event. This is done using the datetime option:

GAD(config)#service timestamps debug datetime localtime

It should be noted that this command is only useful if the clock is set on the router. Otherwise, the timestamp shown in the debug output is not an accurate time. To ensure that the timestamps are correct, the router clock should be set to the correct time from privileged EXEC mode with the following command:

GAD#clock set 15:46:00 3 May 2004

Note: On some Cisco platforms, the router clock is not backed up with a battery source, so the system time will need to be reset after a router reload or power failure.

The no debug all and undebug all commands turn off all diagnostic output. To disable a particular debug command, use the no form of the command. For example, if the debug ip rip command is used to monitor RIP, it can be disabled with no debug ip rip. To view what is currently being examined by a debug command, use show debugging.
The Lab Activity will help students become more familiar with the debug command.
This page concludes this lesson. The next page will summarize the main points from this module