Home > Articles

Hardware and the OSI Model

This chapter is from the book

Terms you'll need to understand

  • Hub

  • Bridge

  • Layer 2 switch

  • Router

  • Layer 3 switch

  • Repeater

  • Star topology

  • Bus topology

  • Coaxial cable

  • Twisted pair

  • Collision domain

  • Segment


Techniques you'll need to master:

  • Ethernet operation

  • Store and forward bridging

  • Network segmentation

  • Strengths and weaknesses of a star topology versus a bus topology

  • Identify hardware typical of Layers 1 through 3 of the OSI model

  • Understand the functions of and differences of bridges and Layer 2 switches

  • Understand the operational differences and functions of Layer 1, 2, and 3 devices

When IBM released its first PC it started a veritable buying frenzy among corporations. What separated the IBM PC from others of the time was not so much technology as it was the IBM logo displayed prominently on the front of each PC. The IBM logos made the PC acceptable for deployment in a corporate environment, and deploy it they did! At the time, businesses were largely dependent upon timesharing vendors to run ad hoc analysis and simulations. The benefit of these real-time applications more than warranted the cost, which in many cases exceeded $40,000 to $50,000 per month. A PC, however, could often run the same application for a one-time cost of $6,000 to $12,000, making deployment a foregone conclusion.

Why Are We Covering History?

You are probably asking yourself, why the history lesson? After all, Exam Crams are supposed to be "the facts, only the facts, and nothing but the facts" right? Well, there are really two reasons for this chapter. The first is that the CCNA exam covers far more material than can be memorized. Many of the questions will require you to determine the best answer based on your knowledge of how and why things work the way they do. Taking some time now to review the reasons behind the technology will not only pay big dividends at test time, but it will also provide a contextual framework for discussing some pretty complex equipment in the chapters to come. The second reason for the history lesson is that it provides a way to remember the low-level properties affecting the design and operation of today's equipment. The alternative is just listing electrical properties, physical design limitations, and the physics behind network operation, which can be drier than Oklahoma dirt. So put your feet up, relax, and let's go back to the time of short sleeve white shirts and pocket protectors.

"Give a man a fish and he will surely want a steak" is a parable that holds true for corporations as well as individuals, and it wasn't long before organizations were demanding even more savings from PC installations. It didn't take a rocket scientist to realize the major cost of PC deployment was in the peripherals, not the PCs. A letter-quality printer could cost as much as a PC and a really big hard drive, say 5MB, could exceed the cost of a PC. With the exception of running back and forth with 5 1/2-inch diskettes (sneaker-net) those peripherals were un-shareable and grossly underutilized. Ahh, if only peripherals could be shared, think of the savings!

Early Bus Networks (10BASE-5 and 10BASE-2)

About this time a consortium of manufacturers working at Xerox's PARC (Pacific Area Research Center) released a really strange device called "Ethernet" that would do exactly what was needed—namely share PC resources. Ethernet used signaling that was well into the radio frequency spectrum and utilized a long coaxial cable (up to 500 meters) as a medium to connect PCs and peripherals. A coaxial cable consists of a single copper center conductor, covered by a dielectric material (insulator), which in turn is covered by a braid of copper wire, all of which is covered by a polyvinyl chloride (PVC) or Teflon jacket. (See Figure 3.1.)

Figure 3.1Figure 3.1 Coaxial Cable.

It is easy to see why installers preferred 10BASE-2 cable (right) over 10BASE-5 cable (left).

This type of cable is relatively immune to radio frequency interference from the outside, and also does a good job of containing radio frequency signals on the inside. Without these two properties, the cable would actually become a huge antenna, with all kinds of nasty consequences.

However, there is a downside to this type of cable, and all other cables, including fiber optics. The downside is that an impedance mismatch will reflect a signal. An impedance mismatch occurs where the properties of the cable change. Joining a cable to another with different properties will create an impedance mismatch. Nicking a cable will also create a mismatch, or we can go for the biggest mismatch of all and just whack the thing in half. Of course, all cables must end one way or another, so to avoid the resulting impedance mismatch, both ends of the coaxial cable were terminated with resistors (terminators). These terminators would dissipate the electrical energy rather than reflect it (see Figure 3.2). This assembly in its entirety is called a backbone or bus topology.

Figure 3.2Figure 3.2 Bus topology.

A bus topology provides a single transmission cable called a bus. Network nodes connecting to the bus share its transmission capacity. When coaxial cable is used for the bus, a terminator (resistor) must be installed at each end to eliminate reflections. Notice how the Ethernet symbol in the lower right resembles the bus design.

The resulting reflections from a cut or nicked coaxial cable or fiber-optic cable can bring an entire Ethernet system down. In fact, the nick or cut is located by launching a signal down the cable and then timing the reflection. The device used for this is called a Time Domain Reflectometer (TDR) for copper cable and an Optical Time Domain Reflectometer for fiber optics. Both will provide the distance from where the device is connected to the cut or nick by timing the reflected signal.

The backbone cable was a really good idea but without a way to attach stations or nodes it was useless, and this is where things got messy. Originally, nodes or stations were attached to the bus by way of a tap, which physically pierced the cable (see Figure 3.3).

These taps were quickly nicknamed vampire taps for obvious reasons, and the name has stayed with them ever since.

The tap included a transceiver (transmitter/receiver) for signaling, and was attached to the PC by an attachment unit interface (AUI) cable. The AUI cable was often called a drop cable and closely resembled today's serial cable. The PC itself was provided an interface card for attaching the drop cable and a piece of software called a redirector that routed resource requests either to the transceiver for transmission on the bus or to a locally attached resource, such as a printer or hard disk.

Figure 3.3Figure 3.3 10BASE-5 taps.


We bet you are thinking that if a nick in the cable causes an impedance mismatch and reflections, the pins of the vampire tap piercing the cable would also cause reflections. Absolutely! That is why cable manufacturers marked Ethernet cable with a ring every 2.5 meters. The natural resistance of the cable could dampen the reflections from the pins, but it took 2.5 meters of cable to provide adequate resistance. So each tap had to be at least 2.5 meters for neighboring taps. That is why the cable was marked every 2.5 meters. If you always placed your taps on the marks, reflection problems would be eliminated.

The layout of a single transmission medium, like a coaxial cable, providing connectivity to a number of stations or nodes is referred to as a bus topology (actually, the proper name for the backbone is bus but in practice the terms are used interchangeably). Although multiple stations (Multiple Access) were connected to the bus, only one signal could traverse the bus at any one time (Baseband).

Multiple signals were eliminated because each of the network interfaces had a circuit that sensed voltage on the bus (Carrier Sense). If a voltage or carrier was present, the interface would delay transmission until the voltage again dropped to zero. So, a situation where two or more signals ended up on the bus at the same time would be highly unlikely.


In actual operation, having multiple signals on the bus can and does occur. Two or more interfaces, sensing zero voltage, could, in fact, transmit at the same time causing a collision on the bus. In fact, the stations did not necessarily have to transmit at exactly the same time.

A signal takes time to move from one end of the bus to the other, so it is quite possible a station on one end would transmit, not knowing there was already a signal on the other end of the bus. Two or more signals on the bus would create an over-voltage condition, which (you guessed it) would be sensed (Collision Detection) by the same circuit that was monitoring the voltage in the first place. When this occurred, the network interface would send a jam signal to busy out the entire bus, wait for a random time period of no carrier or voltage on the bus, and then retransmit the original signal. The random period of time was to prevent a second collision when the two or more network interfaces that originally caused the collision retransmit. Now you know why all Ethernets are categorized as Carrier Sense, Multiple Access, Collision Detection (CSMA/CD) networks.

Pushing Distance Limitations (Repeaters)

The network we described previously was standardized as a 10BASE-5 (10Mbps, baseband, 500 meters) network and theoretically, if you stayed within the standards, everything would work fine. However, it was a lot cheaper to extend the bus a little over the 500 meter limit than to install a whole new bus, and that is what many people did. The problem was that as a signal travels down a medium, it loses a bit of its strength (attenuates) for every meter it travels. All standards tend to be conservative so in most cases this did not create a major problem. As people pushed the distance more and more, or used lower quality materials, attenuation began to cause problems. So it was not long before a nifty device called a repeater was developed to address signal attenuation.

A repeater is a Layer 1 (Physical layer) device installed between two segments of a bus (the bus is actually cut and then reconnected through the repeater). A repeater does not care about addresses, frames, packets, or any of the upper-layer protocols we have discussed. A repeater simply senses a voltage or signal on one side, rebuilds and retimes the signal, and then sends it out the other side (repeats). Do not make the assumption, however, that repeaters eliminate distance restrictions. Like railroads, all networks operate on a foundation of timing. It takes time for a signal to move down a cable and it takes even more time for a repeater to rebuild, retime, and retransmit a signal. So long as we stay within the established timing standards for our type of network, everything is fine. If we exceed those standards, things get ugly fast (see Figure 3.4).


More than one question will require knowing the difference between segment and network. Segments are part of the same network and are formed as the result of using a Layer 1 device such as a repeater or a Layer 2 device such as a bridge. A network is a single entity that can include several segments, but as a whole can be identified by a single Layer 3 address (see Figure 3.4).

Pushing Station Limitations (Bridges)

So now we have a flexible network that can be easily expanded and provides sharing of expensive resources. The requirements have been met and everybody is happy. Well, not quite. The economies generated by shared resources provided a very real and tangible incentive for adding more stations to the network, and that is exactly what companies did. After all, an Ethernet segment could have as many as 1,024 nodes, which should be far more than anybody would ever need. The problem was that very few organizations made it to 1,024 nodes. Degradation in response time and throughput became a problem long before the magic number 1,024 was ever reached. Even more disturbing were traffic studies that revealed an incredibly high number of collisions with very little data transiting the network.

So what was happening? Well, it turns out that every node or station added to an Ethernet network increases the probability of a collision. When a collision occurs, the node interface sends out a jam signal that stops all transmission on the network. The interface then waits for a random period of silence before retransmitting the original frame of data. All of this takes time, and although the network is busy, very little data is moving across the network. At some point the network reaches its capacity of 10Mbps with the majority of that capacity used for collision recovery. Depending on the type of traffic, that ceiling is usually reached when approximately 4Mbps of data are moving across the network. Furthermore, if we attempt to push even more data through a saturated Ethernet, the total capacity available to data will decrease as the number of collisions increase. In short, Ethernet has the remarkable characteristic of providing excess capacity when you don't need it and reduced capacity when you do.

Well, no engineer can tolerate this kind of situation so it was not long before another nifty device called a bridge was developed. A bridge allows you to cut the Ethernet cable and then reattach it using the bridge. The bridge, like a repeater, has two network interfaces, with each attached to a segment of the cable. When a frame is launched on one segment (let's call it "A"), the bridge copies the entire frame into a buffer, reads the source address and destination address, and performs a Cyclical Redundancy Check (CRC) to ensure the frame is complete and accurate.


A repeater segments an Ethernet network but does not create separate collision domains. A bridge both segments a network and creates separate collision domains (see Figure 3.4).

A Cyclical Redundancy Check is a number attached to the end of a frame that was derived by running the digits of the frame through a specific computation. The bridge performs the same computation and if the resulting number is equal to the one stored in the CRC field, then the frame is considered accurate and complete.

Because the bridge reads the entire frame, it is considered a Store and Forward device. The bridge then writes the source address of the frame to a reference table for segment "A" and checks to see if the destination address has also been logged as a source address on segment "A". If the destination address is in fact listed in the table, the bridge then knows that both the source and destination addresses are on segment "A" and the frame is discarded. However, if the destination address is not already listed in the table, the bridge assumes the address must be located on segment "B" and the frame is passed on through the second interface to segment "B". Of course the same thing is happening at the interface for segment "B". Within a few seconds the bridge will have compiled tables for the stations on both segments of the network and frames will either be checked and passed or stopped and discarded based on destination address and completeness of the frame. The ability of bridges to automatically build and update network tables led many to call them learning bridges.

So, what did all of this really accomplish? First, traffic that is moving between stations on the same segment stayed on that segment and did not tie up the resources of the other segment. It was like gaining the capacity of two networks with all of the benefits of a single network. Secondly, because a CRC was performed on each frame needing transit across segments, only good frames were actually passed. This effectively limits collisions to a single segment which also frees the other segment to carry traffic. When a network is segmented with a bridge, each of the segments is considered a separate collision domain (see Figure 3.4). Prior to segmentation, the entire network was one collision domain. We can also add multiple bridges, and create multiple collision domains, which would greatly expand our capacity for additional stations.


The collision domain is another one of those concepts that may not be questioned directly, but will be at the core of several questions. Remember that a collision domain is a group of nodes or stations that is connected in such a way that if any two transmit at the same time, the resulting collision will affect the entire group. A repeater is a Layer 1 device that will rebuild, retime, and retransmit any voltage pattern down the wire. Although a repeater does break a network into segments, it does not create separate collision domains. A bridge is a Layer 2 device that also segments a network, but because it stops collisions from passing from one segment to the other, it does create separate collision domains. If you understand collision domains to the point where you can easily identify the problems of cut through switches discussed later in this chapter, then you are ready.

Figure 3.4Figure 3.4 A segment is always a subset of a network (1). Both a repeater and a bridge will divide a network into segments (2 & 3). However, only a device with bridging functionality will create separate collision domains as well as segments (3).

So, with all of these benefits, was there a downside to using bridges? Of course, it took time for a bridge to read and analyze each frame. Multiple bridges could easily exceed the timing restrictions of a network. When this happened, stations or entire segments at one end of the network would be completely unaware that stations at the other end of the network had begun transmitting. The resulting collisions storms could and did shut down entire networks. It was also possible to accidentally create a loop with multiple bridges that would cause frames to endlessly race around the loop until the network got so clogged it could no longer function. The Spanning Tree Protocol (STP) was eventually developed so that bridges could communicate with each other to determine which bridges would be active and which would be held in reserve. This not only eliminated loops but also allowed for redundancy in the network. Even with these drawbacks, the bridge solved many more problems than it created and greatly advanced the capabilities of networking.

Layer 3 Expansion (Routers)

However (you knew this was coming didn't you?), there was one limitation to bridges that could not be overcome. That limitation had to do with scalability or size. I am sure you noticed how many times the term "frame" was used in the previous paragraphs.

You already know from Chapter 2 that in the OSI model, "frame" is the PDU for Layer 2, and Layer 2 is where MAC addresses are defined. So it would not be unreasonable to assume that bridge functions were based on the MAC address of the network interface attached to stations in the network. If you made that assumption you are absolutely correct!


You will likely get at least one "recall type" question relating directly to Protocol Data Units (PDUs). However, many questions will use a PDU name without calling attention to it, much like the way we used "frame" in the previous paragraphs. This may be your only clue as to how to answer a specific question. So be sure you can recognize PDU names, the layer of the OSI model where they operate, and the functions of that layer. If you have been a bit sloppy with the way you have applied PDU names in the past (all of us have), start disciplining yourself right now to only use the name of a PDU in exact context of its definition. That will go a long way toward making some of the test questions intuitively obvious.

Bridges are Layer 2 devices and the foundation of their operation is the MAC address. You will probably also recall from Chapter 2 that MAC addresses have a problem with scalability. Maintaining a unique address across many networks required going to a higher level (Layer 3) where a logical network address was defined.

The MAC address is physical because it is burned into a chip on the network interface. There is nothing virtual about it. What is on the chip is what you get and only what you get, period. The network address is "logical" in that it is derived from a routing protocol and assigned to a network. The network address is not burned into a chip or physically attached to a device in any way. It is a part of the software in use and can be readily changed. The concept is identical to logical drives on a PC. You may have only one physical drive, but that drive could, and usually is, configured as several logical drives.

The need for a different address scheme was not the only problem encountered when data was passed across or between different networks. There was almost always a change in media type, signaling requirements, and interface hardware. The whole issue of network overhead also became a major problem. Network stations needed a way to identify the addresses of other stations on the network. One popular network software package accomplished this by having each station broadcast its MAC address every three seconds. Now imagine you bridged the networks of two remote corporate divisions over a 56Kb leased line that costs $100,000 a month. With every station broadcasting its address across that link every three seconds, how much real data could get through? Some other device was clearly needed and that device was called a router.

Routers and bridges differ in that bridges use the MAC address (Layer 2) to perform their functions while routers use the network address (Layer 3). That, folks, "is the difference, the whole difference, and nothing but the difference"! Routers rely on a routing protocol for the definition and establishment of network addresses, and there is more than one protocol.

You are already familiar with at least one routing protocol named IP, which is a part of TCP/IP and stands for Internet Protocol. Others include Novell's IPX and Apple's AppleTalk. However, regardless of protocol, all routers fall into one of two types: static or dynamic. Most smaller, single site applications use static routers.

A static router, or fixed configuration router, is initially configured by the user and then it stays that way until the user goes back and manually changes the configuration. Configuring a router is done using a command-line interface or a Web-based interface developed by the manufacturer. Most static routers today have a Web-based interface with very limited options so it will be easier for the end user to configure. Simplicity is good in a static router because most of those end users have little if any computer training. The good news is that once a static router is configured it will merrily chug away forever, which is great for single location with a stable network environment. The bad news is that every time the environment changes, somebody has to physically change the operating parameters of the router. The really bad news is that if the environment changes and the organization has multiple sites, somebody, hopefully not you, has to reconfigure each router individually. This reconfiguration can usually be done through a utility such as telnet, but in many cases requires a personal visit. So if you get into a situation which uses static routers in multiple locations, keep your bags packed and be prepared to make house calls.

The limitations of static routers were a major problem for big decentralized companies with "big bucks" budgets, so it did not take long for a new type of router to arrive on the scene. A router that could automatically adjust to changes in the network environment, be configured and managed remotely, and provide even more filtering capability would be perfect, and that folks is exactly what a dynamic router or flexible configuration router does.

A major hurtle to development of dynamic routers was finding a way to make the router aware of changes in the network and then provide it with a method for determining the best route to a given address. Therefore, it should not be surprising that the advent of dynamic routers coincided with advent of routing protocols. A routing protocol provides a way for routers to exchange information from their routing tables and then determine the best route to a network given that information. Each protocol handles this function slightly differently, and each has its own set of benefits and drawbacks. RIP (Routing Information Protocol) and IGRP (Interior Gateway Routing Protocol) are examples of protocols that use a distance vector algorithm for determining the best route. A distance vector routing protocol requires each router to exchange information with its direct neighbors. In this way, information travels from router by router throughout the network. Some refer to this approach as "routing by rumor." OSPF (Open Shortest Path First) and IS-IS (Intermediate System to Intermediate System) are examples of protocols that use link state routing. Link state routing requires each router to exchange information with every other router in the network. We will be going into each of these approaches in Chapter 7. However, for now it is enough to know that:

  • Routable protocols provide a framework for addressing networks and a structure (Packet) to carry user data across networks.

  • Routing protocols provide a way for routers to exchange routing table data and a method for determining the best rout to a given address.

Configuring a static router or fixed configuration router can be intimidating, and they are designed for simplicity. Configuration of a dynamic router or flexible configuration router can be downright otherworldly. Initial configuration of a dynamic router is usually done through a command-line interface. However, instead of having a dozen or so parameters like a static router, a dynamic router can easily have thousands. The scary part is that not only do you have to find where a parameter is set in a complex command-line interface, but you also have to know the ramifications that setting will have on all of the other parameters that interact with it. We are not trying to scare you here (well maybe a little). The real thing we want to get across is that setting up large dynamic routers is not a task to be taken lightly. Becoming a Cisco Certified Network Associate (CCNA) is your first step to joining the elite few who can really handle these complex systems.

We have arrived at a point where we have large bridged coaxial cable-based networks connected by dynamic routers that are talking to each other and keeping the whole system running like a top. In fact, the new coaxial cable standard called 10BASE-2 (see Figure 3.1) largely replaced the bulky 10BASE-5 systems. 10BASE-2 installations use a much thinner coaxial cable and replaced the dreaded vampire tap with a simple "T" connector (see Figure 3.5). So now everybody should be ecstatic, right? The problems of installation were greatly reduced, networks could be segmented with bridges to allow more users, and routers provided long distance connectivity. What more could possibly be needed? The answer is something other than coax.

Figure 3.5Figure 3.5 10BASE-2 Networking.

Figure 3.5 shows the "T" connector used to attach the bus to the station. The leg of the "T" (facing forward) attaches to the interface card in the station, while the top of the "T" provides a straight through connection for the cable.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020