Home > Articles > Cisco Certification > CCIE > CCIE Routing and Switching Exam Certification Guide

CCIE Routing and Switching Exam Certification Guide

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Aug 16, 2002.

Chapter Description

Prepare for the CCIE Routing and Switching Exam with this excellent study resource. Review such topics as MAC address format, VLAN trunking, transparent bridge functions, and much more.

SRB

This section covers SRB explorer frames, SRT, SR/TLB, RSRB, and DLSw Plus (DLSw+).

SRB Operation

IBM developed SRB in the mid-80s as a way to bridge between Token Ring LANs. The IEEE adopted most of IBM's proposal into the IEEE 802.5 standard. As shown in Figure 4-20, in SRB, the source determines the route to the destination node by sending an explorer frame to it. SRB bridges do not keep a MAC table of hosts and do not worry about bridge loops. This is different to Ethernet transparent bridging where the bridges have the smarts of MAC layer destinations and determine the path by creating a spanning-tree. SRB networks are limited to a 7-bridge hop count. (Some implementations can extend to 13 hops.) In SRB, the source node obtains the knowledge of routes to destinations on the network. This is accomplished using explorer frames.

Figure 4-20Figure 4-20 SRB Network

Explorer Frames

When a source node wants to send information to a destination that is not on the local LAN, it sends out an explorer frame. Bridges pick up the explorer frames and forward them out the other interfaces. The bridges add route information to the frames as they travel through the network. The route information includes a Token Ring number and bridge number pair that the explorer frame travels on. As seen in Figure 4-21, when the explorer frame reaches Bridge 6, a route descriptor is added to the frame that includes Ring 7/Bridge 6. At Bridge 4, another route descriptor with Ring 3/Bridge 4 is added. Finally, Ring 2 is added at the destination node with the bridge value set to 0 to indicate that the destination has been reached.

Figure 4-21Figure 4-21 SRB Ring/Bridge Routing Information

When the explorer frames arrive at the destination, the destination frame sets the direction bit (also known as the D-bit) to 1 and sends the frame back to the source node through the same route that was used to arrive to the destination. When multiple frames reach back to the source node, it usually uses the route of the first frame received. Other decision metrics include the minimum number of hops and the path with the largest MTU allowed.

There are two types of explorer frames. The first is the all-routes explorer (ARE) frame. This explorer takes all possible paths to the destination. The second type is the spanning-tree explorer (STE) frame; these explorer frames use a spanning tree to reach a destination to prevent loops.

RIF

The RIF is contained in the 802.5 frame and is composed of a 2-byte RIF header. The RIF can contain one or more route descriptors. Figure 4-22 shows the RIF header and route descriptor format.

Figure 4-22Figure 4-22 RIF

The first two most significant bits indicate the type of frame:

  • 00—Non Broadcast (specific route). Indicates that this is a regular frame that should be routed to the destination following the information in the route descriptors.

  • 10—All-routes broadcast. Indicates this is an All-rings explorer packet that should take all possible routes to the destination.

  • 11—Single-route broadcast. Indicates that this is a limited broadcast that should take one path to the destination.

The next bit is unused.

The 5 least significant bits in the first byte indicate the total length of the RIF field including the 2-byte header. A RIF with only one bridge hop is 6-bytes long.

The most significant bit in the second byte is the D-bit (direction bit). A value of 0 indicates forward direction, which means the source to the destination. The route descriptors are read from left to right when the D-bit equals 0. A value of 1 indicates reverse direction, meaning the destination station has seen it and the frame travels from the destination to the source. The route descriptors are read right to left when the D-bit equals 1.

The next 3 bits indicate the maximum transmission frame size for the 802.5 frame. This is the maximum frame size that this station is willing to accept. A value of 011 indicates 4136 bytes, and a value of 100 indicates 8232 bytes. (Some references might say the values are 4472 and 8144, respectively.) Table 4-9 shows possible maximum frame size values.

Table 4-9 RIF Max Frame Size Values

RIF MTU Bit Value

Max Frame Size (bytes)

000

512

001

1500

010

2052

011

4472

100

8144

101

11407

110

17800


The lower 4 bits are not used.

The route descriptors are 2 bytes long. The first 12 bits indicate the ring number. The 4 least-significant bits indicate the bridge number.

Figure 4-23 shows Token Ring and bridge numbers between Hosts A and B. Some numbers are in decimal and others are in hexadecimal format.

Figure 4-23Figure 4-23 RIF Example

The RIF header from Host A to Host B is constructed as follows:

00001000 00110000 = 0x0830

From the bits, you can determine the following:

  • This is a regular frame (type = 00).

  • It is 8 bytes in length (length = 01000).

  • The maximum frame size is 4472 (MTU = 011).

  • The direction bit is set to 0.

The route descriptors are constructed as follows. The last bridge number is set to 0x0:

Ring 20 (0x014) to Bridge 12 (0xC) to Ring 0x003 to Bridge 10 (0xA) to Ring (0x010) = 014c.003A.0100

The RIF field in hex is 0830.014c.003a.0100.

The CCIE candidate should know how to read and construct the RIF field for regular SRB and in other scenarios, such as RSRB and DLSw. RIF examples are included in each corresponding section.

SRB Configuration with Cisco Routers

SRB is limited in that it is a flat network topology in the data-link layer. Another limitation is the maximum hop limitation of 7 bridges. Routers can be introduced into the network to help limit the number of hops on the network. Remote Token Ring networks can be attached to routers to reduce bridge hops. This is accomplished with the concept of the virtual ring, as seen in Figure 4-24. Consider each router interface a minibridge that connects the external ring to the internal virtual ring. You use the ring number in the RIF field just like any other physical ring.

Figure 4-24Figure 4-24 SRB Configuration

To configure the virtual ring group, use the global command source-bridge ring-group virtual-ring-group-number. Each Token Ring LAN is bridged to the virtual ring by using the interface command source-bridge ring-number bridge-number virtual-ring-group-number. The bridge number can be from 1 to 15. The ring number is from 1 to 4095.

The configuration for the router in Figure 4-24 is displayed in Example 4-7.

Example 4-7 Configuration Example of Source Route Bridging

source-bridge ring-group 5
!
interface tokenring 0
 source-bridge 1 10 5
 source-bridge spanning
!
interface tokenring 1
 source-bridge 2 11 5
 source-bridge spanning
!
interface tokenring 2
 source-bridge 3 12 5
 source-bridge spanning

The frame in this example from Token Ring 1 to Token Ring 2 is source routed as follows: Ring 1 to Bridge 0xA to Ring 5 to Bridge 0xB to Ring 2. The RIF is 0830.001a.005b.0020.

NOTE

The CCIE candidate must master how the RIF is built. At the end of some of the following sections, there is a paragraph on how the RIF looks.

SRT

SRT is specified in the IEEE 802.1d Appendix C standard. SRT bridges can forward traffic from both transparent and source-route end nodes and form a common spanning tree with transparent bridges. SRT bridges combine the implementations of transparent bridges and source-route bridges and can distinguish between source-route and transparently bridged frames. SRT allows transparent or source-route stations to communicate with other stations of the same type.

SRT bridges use a Routing Information Indicator (RII) bit to distinguish between SRB and transparent bridge frames. The RII values are as follows:

  • 0, means a RIF is present; use the SRB algorithm.

  • 1, means a RIF is not present; the frame is transparently bridged.

SR/TLB

SR/TLB bridges provide bridging between Ethernet and Token Ring networks. The difference between SR/TLB and SRT bridges is that SR/TLB bridges can forward frames between source-route and transparently bridged networks. Considering the differences between these two technologies, SR/TLB has many challenges to overcome so that transparent Ethernet networks can communicate with SRB token ring networks and vice versa.

As shown in Figure 4-25, source-route translational bridges overcome the following issues:

  • Bit ordering of MAC addresses—As explained in an earlier section, Ethernet NICs expect to receive the least-significant bit first for each octet; Token Ring considers the first bit to be the most significant bit of each octet. Translational bridges reorder source and destination addresses when translating between Token Ring and Ethernet.

  • MTU size—Ethernet's MTU is 1500 bytes; Token Ring has a MTU of 4472 bytes on 4 Mbps networks and 17,800 on 16 Mbps networks. Translational bridges usually set the MTU on the Token Ring networks to 1500 to facilitate the transfer of frames to Ethernet. They check the MTU of every frame.

  • Frame Status—Ethernet does not use frame status bits that are used in Token Ring. Some bridges set the C (copied) bit to 1 when a frame is transferred from Token Ring to Ethernet.

  • Explorer Frames—Ethernet does not use explorer frames. These frames are dropped when converting from Token Ring to Ethernet segments.

  • RIF—Ethernet does not understand the concept of source-routed frames.

  • Spanning-tree algorithm—Token Ring bridges do not understand Ethernet's STP.

  • Frame Conversion—Ethernet V2 frames are converted to Token Ring SNAP frames, and vice versa.

Figure 4-25Figure 4-25 SR/TLB

SR/TLBRouter Configuration

Configuring SR/TLB involves the configuration of SRB and transparent bridging as described in earlier sections. An additional command ties in the SRB domain with the transparent bridged domain:

source-bridge transparent ring-group pseudo-ring bridge-number tb-group

The arguments are as follows:

  • ring-group—The virtual ring group number created with the source-bridge ring-group command.

  • pseudo-ring:—A virtual ring group number created for the transparent bridge group. The Token Ring side sends frames to this ring number to reach the host in the transparent bridge side.

  • bridge-number:—A bridge number is assigned for the bridge between the virtual ring group and the pseudo ring.

  • tb-group:—The transparent bridge group number configured with the bridge-group command.

To perform SR/TLB the router configuration of the network in Figure 4-25 is displayed in Example 4-8. The virtual ring group number is 10. From the source-bridge transparent 10 2 5 1 command, you can determine that transparent bridge group 1 uses pseudo ring 2, which is bridged to virtual ring 10. Bridge number 5 bridges between pseudo ring 2 and virtual ring 10.

Example 4-8 Example of SR/TLB

source-bridge ring-group 10
source-bridge transparent 10 2 5 1
!
interface tokenring 0
 source-bridge 5 6 10
 source-bridge spanning
!
interface ethernet 0
 bridge-group 1
!
bridge 1 protocol ieee

The RIF of a source route frame from Host A to reach Host B routes from Ring 5, Bridge 6, Ring 10, Bridge 5, to Ring 2. In hex, the RIF is 0830.0056.00a5.0020.

RSRB

RSRB permits the bridging of Token Rings that are located on separate routers across non-Token Ring media. The routers are remotely connected through serial lines, Ethernet, or other methods. RSRB routers create the same virtual ring number that is a logical ring that encompasses both routers. There are four methods of transport:

  • Direct
  • Frame Relay
  • Fast Sequenced Transport (FST)
  • TCP

If you use direct encapsulation over serial lines, they need to have high-level data-link control (HDLC) encapsulation. Direct encapsulation can run over Ethernet, Frame Relay-ATM Interworking, or serial interfaces. If you use TCP encapsulation, RSRB traffic can be prioritized over WAN links.

RSRB Configuration

The configuration of RSRB involves the regular SRB configuration with virtual rings. All routers in RSRB need to have the same virtual ring number configured. The additional configuration command is the configuration of source-route remote-peer statements. The configuration of every RSRB encapsulation is not presented in this subsection. Example configurations follow for direct and TCP RSRB encapsulation. More information on RSRB is at the site www.cisco.com/warp/public/701/2.html.

RSRB with Direct Encapsulation

Looking at Figure 4-26, Router A connects to Router B through a serial line. The RSRB configuration is shown in Example 4-9. The source-bridge remote-peer 10 interface serial 0 command defines the RSRB remote peer as being available through serial 0.

Figure 4-26Figure 4-26 RSRB with Direct Encapsulation@

Example 4-9 RSRB Configuration with Direct Encapsulation

!Router A
source-bridge ring-group 10
source-bridge remote-peer 10 interface serial 0
!
interface tokenring 0
 source-bridge 1 5 10
 source-bridge spanning
!
interface serial 0
 encapsulation hdlc


!Router B
source-bridge ring-group 10
source-bridge remote-peer 10 interface serial 0
!
interface tokenring 0
 source-bridge 2 6 10
 source-bridge spanning
!
interface serial 0
 encapsulation hdlc

The RIF of a source route frame from Host A to reach Host B routes from Ring 1, Bridge 5, Ring 10, Bridge 6, to Ring 2. In hex, the RIF is 0830.0015.00a6.0020.

RSRB with TCP Encapsulation

Looking at Figure 4-27, Router A reaches Router B through an IP network. With TCP, the local peer IP address is configured with one remote-peer statement, and the remote peer IP address is also configured with another remote-peer statement. The router can also be configured to acknowledge sessions destined for the remote peer by using the local-ack argument. The RSRB configuration is shown in Example 4-10. You use the shaded source-bridge remote-peer commands to define the local peer with the local IP address, and the remote peer with the IP address of the remote router.

Figure 4-27Figure 4-27 RSRB with TCP Encapsulation@

Example 4-10 Configuration of RSRB with TCP Encapsulation

!Router A
source-bridge ring-group 10
source-bridge remote-peer 10 tcp 192.168.1.1
source-bridge remote-peer 10 tcp 192.168.2.1 local-ack
!
interface tokenring 0
 ip address 192.168.1.1 255.255.255.0
 source-bridge 1 5 10
 source-bridge spanning


!Router B
source-bridge ring-group 10
source-bridge remote-peer 10 tcp 192.168.2.1
source-bridge remote-peer 10 tcp 192.168.1.1 local-ack
!
interface tokenring 0
 ip address 192.168.2.1 255.255.255.0
 source-bridge 2 6 10
 source-bridge spanning

The RIF of a source route frame from Host A to reach Host B routes from Ring 1, Bridge 5, Ring 10, Bridge 6, to Ring 2. In hex, the RIF is 0830.0015.00a6.0020.

DLSw+

DLSw version 2 is documented in RFC 2166 and DLSw version 1 is documented in RFC 1795. It was originally submitted by IBM to the IETF as RFC 1434 to overcome some of the limitations of SRB networks, especially in WAN networks. DLSw serves as a replacement of SRB and serves SNA data-link connections (DLC) and NetBIOS traffic.

Cisco's implementation of DLSw is called DLSw+. Some of the benefits of implementing DLSw+ are that link-layer acknowledgments and keepalive messages of SNA and NetBIOS traffic do not have to travel through the WAN. Also DLSw+ traffic can reroute around link failures and can be prioritized on WAN links, whereas SRB does not provide this capability. Cisco routers can be configured to communicate with devices running standards-based DLSw.

Figure 4-28 displays a sample DLSw network.

Figure 4-28Figure 4-28 DLSw Network

End systems can attach to the DLSw network from the Token Ring, Ethernet, Fiber Distributed Data Interface (FDDI), Qualified Logical Link Control (QLLC) (X.25), and SDLC networks. Although there are other methods, the preferred method for establishing peer connections is by using TCP. After a connection is established, the peer routers can exchange capabilities. Circuits are established between end-systems (SNA and NetBIOS). NetBIOS names can be configured to prevent NetBIOS Name Queries to traverse the DLSw network; MAC addresses can be configured in the same manner to reduce SRB explorer frames.

DLSw uses the Layer-2 Switch-to-Switch Protocol (SSP) between DLSw peer routers. SSP switches frame at the SNA layer. DLSw also encapsulates frames into TCP/IP for transport over IP networks.

DLSw supports termination of RIFs at the local virtual ring, which is the default mode. DLSw local termination eliminates the requirement for link-layer acknowledgments and keepalive messages to flow across a WAN. With RIF termination, the virtual rings do not have to be the same between the peers, and all remote hosts appear to be connected to the local router's virtual ring. DLSw also supports RIF Passthru, which does not terminate the RIF at the local end. With RIF Passthru, the virtual ring numbers of the DLSw peer routers must match, and the rif-passthru keyword must be in the remote-peer statement.

SNA devices on a LAN find other SNA devices by sending an explorer frame with the MAC address of the target SNA device. When a DLSw router receives an explorer frame, the router sends a canureach frame to each of the DLSw partners. If one of its DLSw partners can reach the specified MAC address, the partner replies with an icanreach frame. The specific sequence includes a canureach ex (explore) to find the resource and a canureach cs (circuit setup) that triggers the peering routers to establish a circuit.

NetBIOS circuit establishment is similar, but instead of forwarding a canureach frame that specifies a MAC address, DLSw routers send a name query (NetBIOS NAME-QUERY) frame that specifies a NetBIOS name. Instead of an icanreach frame, there is a name recognized (NetBIOS NAME-RECOGNIZED) frame.

Most DLSw implementations cache information learned as part of the explorer processing (from the icanreach responses) so that subsequent searches for the same resource do not result in the sending of additional explorer frames. This is also true with DLSw+.

DLSw Configuration

The basic configuration of DLSw is quite simple. Each router with attached networks is configured with a local -peer command. Remote peers are configured to remote routers. It is preferred to use the loopback IP addresses to configure the peers because the DLSw peers stay connected regardless of the state of local or remote LAN interfaces. For designs with multiple branches connecting to a hub site, the promiscuous keyword can be used on the hub router's local-peer command to permit remote peers to connect without having to explicitly configure each remote peer on the hub router. The configurations of the routers in Figure 4-29 are shown in this section.

Figure 4-29Figure 4-29 DLSw Example Network

The configuration for Router A is displayed in Example 4-11.

Example 4-11 DLSw Configuration of Router A

source-bridge ring-group 10
!
dlsw local-peer peer-id 10.1.1.1 promiscuous
dlsw remote-peer 0 tcp 10.2.1.1
!
interface loopback 0
 ip address 10.1.1.1 255.255.255.255
!
interface tokenring 0
 source-bridge 1 5 10

The configuration for Router B is displayed in Example 4-12.

Example 4-12 DLSw Configuration of Router B

source-bridge ring-group 20
!
dlsw local-peer peer-id 10.2.1.1
dlsw remote-peer 0 tcp 10.1.1.1
!
interface loopback 0
 ip address 10.2.1.1 255.255.255.255
!
interface tokenring 0
 source-bridge 2 6 20

The configuration for Router C is displayed in Example 4-13.

Example 4-13 DLSw Configuration of Router C

bridge-group 1 protocol ieee
!
dlsw bridge-group 1
!
dlsw local-peer peer-id 10.3.1.1
dlsw remote-peer 0 tcp 10.1.1.1
!
interface loopback 0
 ip address 10.3.1.1 255.255.255.255
!
interface Ethernet 0
 bridge-group 1

Router A only defines a remote peer for Router B. It does not need to define Router C as a peer because the promiscuous keyword accepts connections from remote peers without having to define them. Router C defines Router A as a remote peer.

The RIF for a host on Router A to reach a host on Router B takes the path from Ring 1 to Bridge 5 to Ring 10. Because the virtual ring numbers are different, the RIF is terminated on virtual ring 10 on Router A. The RIF in hex is 0630.0015.00a0.

If the router configuration on Router B is changed to virtual ring 10 and DLSw is configured for RIF Passthru, the RIF reaches the far end ring. The RIF from the host on Router A to Router B takes the path from Ring 1 to Bridge 5 to Ring 10 to Bridge 6 to Ring 2. The RIF in hex is 0830.0015.00a6.0020.

5. LAN Switching Topics | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

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

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press 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.

Surveys

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.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.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.

Security

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

Children

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

Marketing

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.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. 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.ciscopress.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.

Links

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