Category: CCNA Study Guide Chapter 04

Tutorials from Chapter 4 of Dan’s Free CCNA Study Guide

CCNA Study Guide Chapter 4 Summary

This chapter began with a look at the TCP/IP protocol suite. This included a look at the protocols that make up TCP/IP and the way in which they relate to the ISO OSI model.
A look at Network layer protocols provided an overview of IP packets and addressing, the way in which ARP is used to map IP addresses to MAC addresses, as well as how ICMP provides error reporting and diagnostic information.

Examination of protocols at the Transport layer provided an overview of both TCP and UDP, including their header structures. A closer look at TCP provided insight into port numbers, how connections are defined, how they are terminated. An introduction to UDP provided perspective on how it differs from TCP as a connectionless protocol with lower overhead.

Examples of common port numbers that act as interfaces to upper-layer protocols were also examined.

A look at the TCP/IP Application layer provided an overview of some common protocols and services found at this layer.

An examination of the NetWare protocol suite began with a look at the four Ethernet encapsulation types supported by Cisco and the terms used to refer to them on Cisco routers. A look at the Network layer provided an overview of IPX addressing and packet structure. At the upper layers, a variety of protocols were covered including the connection-oriented SPX. Other protocols discussed included NCP, NetWare Shell, NetBIOS and SAP, the Service Advertising Protocol.

NetWare Upper Layer Protocols

The IPX/SPX protocol suite isn’t nearly as orderly as others when it comes to mapping upper layer protocols to the OSI model. Many of the protocols found above the network layer span multiple OSI layers between Transport and Application. The mapping of the suite to the OSI model at the beginning of this section helps to illustrate this. While the actual mappings may not be so clear-cut, the purpose of these protocols is what is most important. We’ll take a look at a number of these here including SAP, NCP, NetWare Shell, and NetBIOS.

Service Advertising Protocol (SAP)

In older version of NetWare (those prior to version 4.0), servers made other systems aware of the services that they offered through the use of Service Advertising Protocol (SAP) broadcasts. For example, a NetWare server might be functioning as a both a file and print server. In this case, the server would broadcast SAP advertisements onto the network, making clients aware that these services are offered at its network address. SAP advertisements are also used by clients to find their nearest server at startup, in the form of a Get Nearest Server (GNS) request. SAP identifiers are hexadecimal numbers that represent the services. Common examples of SAP identifiers are listed below.

File Server 0x4
Gateway 0x6
Print Server 0x7

Servers send out SAP broadcasts every 60 seconds by default. Since these advertisements are broadcasts, they are limited in scope to the local broadcast domain. For this reason, clients in other broadcast domains will not hear these advertisements. To account for this, Cisco routers can be configured with access lists that can selectively propagate or ignore SAP advertisements from different systems. Similarly, when a local NetWare router is not available, a Cisco router can be configured to respond to GNS requests. Access lists and their configuration will be looked at in detail in Chapter 9.

Newer versions of NetWare that use eDirectory or NetWare Directory Services (NDS) rely on SAP broadcasts to a lesser degree, since the location of servers can be found via a query to an NDS/eDirectory server.

NetWare Core Protocol (NCP)

The NetWare Core Protocol (NCP) is a set of procedures followed in IPX-based communication. When a client using the NetWare Shell attempts to access file, print, or directory resources on a NetWare server, NCP processes the request.

NetWare Shell

In a Windows environment, the line between client and server roles is blurred. NetWare clients, on the other hand, are those running another operating system such as Windows 2000. The NetWare Shell is additional redirector software installed on a client to allow it to make requests to NCP on a NetWare server. For example, when a client wishes to access a network drive, the request is passed to the NetWare shell, which creates an NCP request. It then passes the NCP data to IPX to be forwarded over the network. In this way, a client application is unaware that the request is actually for a remote resource.

NetBIOS

NetWare also provides an emulated environment in which NetBIOS applications can be run. NetBIOS is a broadcast-based Session layer protocol developed by Microsoft and IBM that uses names instead of numerical addresses to represent clients. NetBIOS traffic can be encapsulated in IPX packets to allow NetBIOS-based communication across an internetwork.

Transport Layer – Sequenced Packet Exchange (SPX)

Sequenced Packet Exchange (SPX) is the reliable transport protocol used by IPX when connection-oriented communication is required. Much like TCP, SPX uses sequence numbers and acknowledgments to be sure that data is reliably passed between hosts. Beginning with NetWare 4.0, a new (and backwards-compatible) version of SPX called SPX II was released, providing a sliding window flow-control mechanism. You should be aware that not all IPX network communication requires the use of SPX. IPX is also capable of interacting with some of the other upper-layer protocols directly.

Network Layer – Internetwork Packet Exchange (IPX)

IPX is the routable Network layer protocol of the Novell IPX/SPX protocol suite. Similar to IP, IPX is also connectionless, meaning that it leaves reliability to upper-layer protocols such as SPX. IPX addresses are used to uniquely identify hosts on an IPX network. While an IP address is comprised of 32 bits and is usually represented in dotted-decimal notation, an IPX address is an 80-bit address, represented in hexadecimal.

An IPX address is also made up of two parts – a network address and a host address. The network address is represented by the first 32-bits, while the unique host address is comprised of the final 48 bits. The example below outlines an IPX address.

0000000A.0101AE560163AC

An administrator defines the network portion of an IPX address. Leading 0’s can be left off the network portion. Because of this, the network above can be more simply referred to as network A. Like IP networks, every IPX network requires a unique network address.

Tip: Remember that the network portion of an IPX address is represented in hexadecimal. Since each hex digit represents 4 bits, it can be comprised of 8 hex digits maximum. Don’t forget that only the characters 0-9 and A-F are valid in hexadecimal.

The host address portion of an IPX address is actually incredibly simple – it’s the MAC address of a given host. Since all MAC addresses are different, the combination of a network number and a MAC address uniquely identifies a host on a given IPX network. Note that this also eliminates the need for a protocol such as TCP/IP’s ARP, since a host’s MAC address is already contained within the full IPX address.

The figure below outlines the fields with an IPX header. Note that this particular diagram, field sizes are displayed in bytes rather than bits.

Figure: IPX Header.

The IPX header fields are described below:

  • Checksum. A computed value that verifies the integrity of the IPX header, similar to a CRC. This was not used in versions of NetWare prior to 4.0, where it was set to all 1’s.
  • Packet Length. This field specifies the complete length of the IPX packet, including data.
  • Transport Control. Similar to a TTL (Time-To-Live), when a router processes a packet, it must increment this TTL by 1. At 16, a packet is removed from the network.
  • Packet Type. This field specifies the upper-layer protocol that data is to be passed to. Common hexadecimal values include 4 (SAP), 5 (SPX), 17 (NCP), 20 (NetBIOS)
  • Destination Network. The 32-bit destination network address.
  • Destination Node. The 48-bit destination node address.
  • Destination Socket. This field specifies the software process address on the destination system, similar to a TCP port number.
  • Source Network. The 32-bit source network address
  • Source Node. The 48-bit source node address.
  • Source Socket. Specifies the software process address on the sending system.
  • Data. The encapsulated data passed down from upper-layer protocols and applications.

Routing protocols such as RIP and NLSP also exist at the Network layer of the NetWare protocol suite. These will be covered in detail in Chapter 8.

Physical and Data Link Layers – Frame Encapsulation

NetWare protocols can run over a variety of different network technologies, similar to TCP/IP. For the purpose of keeping things simple, in this section we’ll concentrate on Ethernet. However, IPX can also be run over Token Ring, FDDI, ATM and a variety of WAN technologies. If you recall, Novell originally defined the 802.3 frame type to be used over Ethernet networks. These frames lacked a Type field, since all 802.3 frames were assumed to be destined for IPX at the Network layer. The 802.3 frame type is commonly referred to as Novell Ethernet 802.3 or Ethernet Raw. Different versions of NetWare use different Ethernet frame types as their default for encapsulating IPX packets. In NetWare 3.11 and earlier versions, the default frame type was 802.3. Beginning with Netware 3.12, the default frame type was changed to 802.2.

This presents a technical challenge, since different frame types are not interoperable. As such, a system configured to use only 802.3 frames cannot communicate with a system in the same broadcast domain that uses only 802.2 frames.

To help overcome these limitations, a Cisco router can be configured to use more than one Ethernet encapsulation type for IPX on a single interface. This allows a router to communicate with systems using different frame types. We’ll look at the actual configuration of IPX on a router in Chapter 8. For now, it is sufficient to know the different frame types support by Cisco, and the terms used to describe them.

  • novell-ether. Refers to 802.3 frames that lack an LLC header.
  • sap. Refers to the IEEE standard Ethernet frame with an 802.2 LLC header.
  • arpa. Refers to the Ethernet II frame type.
  • snap. Refers to the Ethernet SNAP frame type.

NetWare Protocol Suite

Similar to TCP/IP, the Netware or IPX/SPX protocol suite is actually made up of a number of protocols that serve different purposes in the network communication process. While the IPX/SPX suite has become less popular based on the widespread adoption of TCP/IP, it is still in use in many (especially larger) network environments.

The IPX/SPX suite comes from the world of NetWare, Novell’s popular network operating system (NOS). Up until NetWare 4.x versions, Novell servers primarily relied on IPX/SPX as their native networking protocol suite. However, versions as early as 3.1x are capable of IP-based communication via a loadable module called NetWare/IP that encapsulates IPX/SPX traffic in UDP datagrams. Beginning with version 5.0, NetWare began using TCP/IP as its primary network protocol, although support for IPX/SPX continues into current versions. In order to reduce the complexity of networks, most companies now deploying NetWare are choosing to use TCP/IP only. However, the use of older IPX-based servers continues to make IPX/SPX a requirement on many networks. For the purpose of both the CCNA and CCDA exams, you are expected to be familiar with IPX/SPX, although you will definitely find a much larger emphasis placed on TCP/IP.

NetWare and the OSI Model

The NetWare protocol suite also follows a layered design that can be roughly mapped to the OSI model. The figure below outlines some of the more common protocols that make up the suite. We’ll look at these in more detail in this section.

Figure: NetWare Protocol Suite and the OSI Model.

TCP/IP and the OSI Model – The Application (Process) Layer

The Application/Process Layer is where TCP/IP applications and services reside. You’re more than likely familiar with many of these, since you probably interact with many TCP/IP applications on a daily basis – a web browser using HTTP, or your email client connecting to a POP3 server are but two simple examples.

The list below outlines some of the more common Application layer protocols that you should be familiar with.

  • Telnet. Telnet is used to create a terminal session with a remote host, providing command-line access to the target system running a telnet server (daemon).
  • FTP. The File Transfer Protocol is used to reliably transfer files between an FTP client and server using TCP.
  • SMTP. The Simple Mail Transfer Protocol is used for the exchange of email between systems.
  • DNS. The Domain Name Service is a distributed database that is queried to resolve (or translate) names such as www.2000trainers.com to an IP address.
  • SNMP. The Simple Network Management Protocol is a lightweight network protocol that allows information to be gathered about network devices. Examples include information about utilization, hardware configuration, and so forth.
  • TFTP. The Trivial File Transfer Protocol is used to transfer files between a client and a TFTP server over UDP. You’ll learn more about TFTP later, since it’s the protocol used to transfer files to and from a Cisco router.

User Datagram Protocol (UDP)

In comparison to TCP, UDP is a very simple protocol. Recall that UDP is connectionless, and as such doesn’t have any reliability mechanisms built in. Because of this, UDP relies on upper layer applications and services for reliability – UDP itself does nothing to attempt to make the communication process reliable. You should also remember that this isn’t UDP’s fault – as a protocol it was designed with speed in mind. If a reliable connection is required, applications should be programmed to use TCP.

Much like TCP, UDP also makes use of 65,536 port numbers to define communication endpoints. Similar to TCP, port numbers below 1024 are considered to be well defined and apply to servers, while client port numbers are usually dynamically assigned in the same way as with TCP. If you were to take a look at the list of port numbers on the IANA website, you would notice that both TCP and UDP port numbers are assigned to most services. For the most part, a service will regularly use one of TCP or UDP to communicate, and seldom both. Certain exceptions apply, such as with DNS. For regular DNS queries, UDP port 53 is used. However, for large queries and zone transfers, DNS uses TCP port 53.

The list below outlines some common UDP port numbers:

DNS 53
DHCP 68
TFTP 69
SNMP 161

The figure below outlines the fields found in a UDP header. While a TCP header is comprised of 192 bits of information, a UDP header is considerably smaller at only 64 bits (not including data, of course).

Figure: UDP Header.

Tip: For more information on User Datagram Protocol, see RFC 768

Transmission Control Protocol (TCP)

TCP is the connection-oriented transport protocol in the TCP/IP protocol suite. TCP attempts to make connections reliable through the use of positive acknowledgement with retransmission – a system where acknowledgements are required for all data sent. If the sending host does not receive these acknowledgements, retransmission eventually occurs. Sequence numbers are assigned to segments to be sure that they are assembled in the correct order at the receiving system. Flow control is handled through buffering techniques such as the use of sliding windows.

When two systems wish to communicate via TCP, they first establish a session (remember the 3-way handshake?), also known as a connection or virtual circuit. Once data has been transmitted and the session is complete, it is closed via a modified 3-way handshake – the difference is that the connection needs to be closed (and acknowledged) independently by both systems. The figure below outlines the 4 steps required to close a TCP session. Closing a session involves sending FIN (no more data to send) and ACK messages. Notice that the extra step involved – the system that originated the end of the connection acknowledges that the other system is now closing the connection as well.

Figure: Ending a TCP session.

There can be a delay between the time when one system attempts to close a connection and the time that the entire connection is actually closed. This occurs because one end may close the connection, while the application on the other end might still be running. A good example is when a user accesses a website – the user may keep their browser running long after the web server has finished sending the requested data as has attempted to close the connection.

TCP communicates with upper-layer applications and protocols through the use of port numbers. When combined with an IP address, a port number defines a unique endpoint for communication. There are 65,536 port numbers available to TCP. How they are chosen requires a bit of discussion.

For the most part, server-side applications are defined by what are considered to be well-known port numbers. These port numbers are defined in RFC 1700 and fall into the 0-1023 range. For example, when a client opens a web browser and types in https://www.2000trainers.com, that name will be translated into an IP address using DNS, and then a connection will be made to port 80 on that IP address. TCP port 80 is the default port on which a web server waits for a connection. But what about the client side of the connection? Well, the client needs to specify a port on which it will send and receive data as well. These port numbers are usually in the range above 1024, and are dynamically assigned by the source host.

Pages: Page 1, Page 2, Page 3