Home > Articles > Cisco Network Technology > General Networking > Designing Cisco Enterprise Campus Architecture Models

Designing Cisco Enterprise Campus Architecture Models

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Apr 17, 2009.

Contents

  1. Designing High Availability in the Enterprise Campus
  2. Designing an Optimum Design for Layer 2
  3. Developing an Optimum Design for Layer 3
  4. Supporting Infrastructure Services
  5. Summary
  6. References
  7. Review Questions

Chapter Description

This chapter examines design models for high availability and fast convergence for the hierarchical layers of the Cisco Enterprise Campus Architecture.

From the Book

Designing Cisco Network Service Architectures (ARCH) (Authorized Self-Study Guide)

Designing Cisco Network Service Architectures (ARCH) (Authorized Self-Study Guide), 2nd Edition

$72.00

Designing an Optimum Design for Layer 2

Layer 2 architectures rely on the following technologies to create a highly available, deterministic topology: Spanning Tree Protocol (STP), trunking (ISL/802.1q), Unidirectional Link Detection (UDLD), and EtherChannel.

The following section reviews design models and recommended practices for Layer 2 high availability and optimum convergence of the Cisco Enterprise Campus Infrastructure.

Recommended Practices for Spanning-Tree Configuration

For the most deterministic and highly available network topology, the requirement to support STP convergence should be avoided by design. You may need to implement STP for several reasons:

  • When a VLAN spans access layer switches to support business applications.
  • To protect against user-side loops. Even if the recommended design does not depend on STP to resolve link or node failure events, STP is required to protect against user-side loops. There are many ways that a loop can be introduced on the user-facing access layer ports. Wiring mistakes, misconfigured end stations, or malicious users can create a loop. STP is required to ensure a loop-free topology and to protect the rest of the network from problems created in the access layer.
  • To support data center applications on a server farm.

NOTE

Some security personnel have recommended disabling STP at the network edge. This practice is not recommended because the risk of lost connectivity without STP is far greater than any STP information that might be revealed.

If you need to implement STP, use Rapid Per-VLAN Spanning-Tree Plus (RPVST+). You should also take advantage of the Cisco enhancements to STP known as the Cisco STP toolkit.

Cisco STP Toolkit

The Cisco enhancements to STP include the following. (Note that the enhancements marked with an* are also supported with Rapid Per-VLAN Spanning-Tree Plus [RPVST+].)

  • PortFast*: Causes a Layer 2 LAN interface configured as an access port to enter the forwarding state immediately, bypassing the listening and learning states. Use PortFast only when connecting a single end station to a Layer 2 access port.
  • UplinkFast: Provides from three to five seconds convergence after a direct link failure and achieves load balancing between redundant Layer 2 links using uplink groups.
  • BackboneFast: Cuts convergence time by max_age for indirect failure. BackboneFast is initiated when a root port or blocked port on a network device receives inferior bridge protocol data units (BPDU) from its designated bridge.
  • Loop guard*: Prevents an alternate or root port from becoming designated in the absence of BPDUs. Loop guard helps prevent bridging loops that could occur because of a unidirectional link failure on a point-to-point link.
  • Root guard*: Secures the root on a specific switch by preventing external switches from becoming roots.
  • BPDU guard*: When configured on a PortFast-enabled port, BPDU guard shuts down the port that receives a BPDU.
  • Unidirectional Link Detection (UDLD): UDLD monitors the physical configuration of fiber-optic and copper connections and detects when a one-way connection exists. When a unidirectional link is detected, the interface is shut down and the system alerted.

NOTE

The STP toolkit also supports the BPDU filter option, which prevents PortFast-enabled ports from sending or receiving BPDUs. This feature effectively disables STP at the edge and can lead to STP loops. It is not recommended.

STP Standards and Features

STP enables the network to deterministically block interfaces and provide a loop-free topology in a network with redundant links. There are several varieties of STP:

  • STP is the original IEEE 802.1D version (802.1D-1998) that provides a loop-free topology in a network with redundant links.
  • Common Spanning Tree (CST) assumes one spanning-tree instance for the entire bridged network, regardless of the number of VLANs.
  • Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning tree instance for each VLAN configured in the network. The separate instance supports PortFast, UplinkFast, BackboneFast, BPDU guard, BPDU filter, root guard, and loop guard.
  • The 802.1D-2004 version is an updated version of the STP standard.
  • Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. MST maps multiple VLANs into the same spanning-tree instance. The Cisco implementation of MSTP is MST, which provides up to 16 instances of Rapid Spanning Tree Protocol (RSTP, 802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, UplinkFast, BackboneFast, BPDU guard, BPDU filter, root guard, and loop guard.
  • RSTP, or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP.
  • Rapid PVST+ (RPVST+) is a Cisco enhancement of RSTP that uses PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, UplinkFast, BackboneFast, BPDU guard, BPDU filter, root guard, and loop guard.

NOTE

When Cisco documentation and this course refer to implementing RSTP, they are referring to the Cisco RSTP implementation, or PVRST+.

STP Standards and Features

To configure a VLAN instance to become the root bridge, enter the spanning-tree vlan vlan_ID root primary command to modify the bridge priority from the default value (32768) to a significantly lower value. The bridge priority for the specified VLAN is set to 8192 if this value will cause the switch to become the root for the VLAN. If any bridge for the VLAN has a priority lower than 8192, the switch sets the priority to one less than the lowest bridge priority Manually placing the primary and secondary bridges along with enabling STP toolkit options enables you to support a deterministic configuration where you know which ports should be forwarding and which ports should be blocking.

NOTE

Defining the root bridge under MST is done using the spanning-tree mst instance_id root primary. When you use this command, the switch will review all bridge ID values it receives from other root bridges. If any root bridge has a bridge ID equal to or less than 24576, it will set its own bridge priority to 4096 less then the lowest bridge priority. To ensure that it will retain its position as the root bridge, you must also enable root guard.

Figure 2-9 illustrates recommended placements for STP toolkit features:

  • Loop guard is implemented on the Layer 2 ports between distribution switches, and on the uplink ports from the access switches to the distribution switches.
  • Root guard is configured on the distribution switch ports facing the access switches.
  • UplinkFast is implemented on the uplink ports from the access switches to the distribution switches.
    Figure 2-9

    Figure 2-9 Layer 2 Hardening

    NOTE

    When you are configuring MST, UplinkFast is not required as a feature on dual-homed switches. Rapid root port failover occurs as part of the default MST protocol implementation.

  • BPDU guard or root guard is configured on ports from the access switches to the end devices, as is PortFast.
  • The UDLD protocol allows devices to monitor the physical configuration of the cables and detect when a unidirectional link exists. When a unidirectional link is detected, UDLD shuts down the affected LAN port. UDLD is often configured on ports linking switches.
  • Depending on the security requirements of an organization, the port security feature can be used to restrict a port's ingress traffic by limiting the MAC addresses allowed to send traffic into the port.

Recommended Practices for Trunk Configuration

A trunk is a point-to-point link between two networking devices that carry the traffic of multiple VLANs. Trunks are typically deployed on the interconnection between the access and distribution layers.

The current recommended practice is to use IEEE 802.1Q trunks. Cisco extensions to 802.1Q avoid security concerns related to the 802.1Q nontagged, native VLAN. The native VLAN is assigned to an unused ID, or the tagged, native VLAN option is used to avoid VLAN hopping.

NOTE

VLAN hopping is an attack using a double 802.1Q-encapsulated packet. If the attacker has specific knowledge of the 802.1Q native VLAN, a packet could be crafted that when processed, the first or outermost tag is removed when the packet is switched onto the untagged, native VLAN. When the packet reaches the target switch, the inner or second tag is then processed, and the potentially malicious packet is switched to the target VLAN. The traffic in this attack scenario is in a single direction, and no return traffic can be switched by this mechanism. In addition, this attack cannot work unless the attacker knows the native VLAN identity.

VLAN Trunking Protocol (VTP) is a protocol that enables network managers to centrally manage the VLAN database. VTP transparent mode is now a recommended practice because it decreases the potential for operational error.

By default, Cisco switches are configured as a VTP server with no VTP domain name specified.

Therefore, it is also recommended when configuring switches along with setting the mode to Transparent, to set the VTP domain name. This is important if you are connecting your switch to other domains, such as a service provider switch. Misconfiguration of the switch as a server or client with no VTP domain name will cause it to accept the domain name of an adjacent VTP server and overwrite the local VLAN database.

As a recommended practice, when configuring switch-to-switch interconnections to carry multiple VLANs, set Dynamic Trunking Protocol (DTP) to Desirable and Desirable with Encapsulation Negotiate to support DTP negotiation.

NOTE

Turning DTP to On and On with Nonnegotiate could save seconds of outage when restoring a failed link or node. However, with this configuration, DTP is not actively monitoring the state of the trunk, and a misconfigured trunk is not easily identified. One instance where you would use On with Nonnegotiate is if you are trunking between two different VTP domains. DTP includes the VTP domain name in its messages; and if the names do not match, the trunk will not come up if set to Desirable.

Another recommended practice is to manually prune unused VLANs from trunked interfaces to avoid broadcast propagation. You should avoid automatic VLAN pruning.

The final recommendation for trunk configuration is to disable trunks on host ports, because host devices will not need to negotiate trunk status. This practice speeds up PortFast and is also a VLAN-hopping security measure.

VLAN Trunking Protocol

VTP version 3 supports centralized VLAN administration in a switched network. VTP runs only on trunks and provides the following four modes:

  • Server: Updates clients and servers. The VTP server switch propagates the VTP database to VTP client switches.
  • Client: Receives updates but cannot make changes.
  • Transparent: Does not participate in the VTP domain. Lets updates pass through.
  • Off: Ignores VTP updates.

With VTP, when you configure a new VLAN on a switch in VTP server mode, the VLAN is distributed through all switches in the VTP domain. This redistribution reduces the need to configure the same VLAN everywhere.

With hierarchical networks that do not span VLANs across the distribution layer, there is little need for a shared common VLAN database. In the recommended campus design, the same VLAN should not appear in two access layer switches. Adding and removing VLANs is generally not a frequent network management practice. In most cases, VLANs are defined once during switch setup with few, if any, additional modifications to the VLAN database in an access layer switch. The benefits of dynamic propagation of VLAN information across the network are not worth the potential for unexpected behavior due to operational error. For these reasons, VTP transparent mode is the recommended configuration option.

Dynamic Trunking Protocol

DTP provides switch ports to negotiate the trunking method with another device and to automatically allow a link to become a trunk.

With Cisco devices, there are five Layer 2 port modes:

  • Trunk: Puts the port into permanent trunking mode and negotiates to convert the link into a trunk link. The port becomes a trunk port even if the neighboring port does not agree to the change.
  • Desirable: Actively attempts to form a trunk, subject to neighbor agreement. The port becomes a trunk port if the neighboring port is set to On, Desirable, or Auto mode.
  • Auto: Makes the port willing to convert the link to a trunk link. The port becomes a trunk port if the neighboring port is set to on or desirable mode.
  • Access: This is the access mode in Cisco IOS Software that specifies that the port never become a trunk, even if the neighbor tries. This mode puts the LAN port into permanent nontrunking mode and negotiates to convert the link into a nontrunking link.
  • Nonnegotiate: Prevents the port from generating DTP frames. You must configure the neighboring port manually as a trunk port to establish a trunk link.

With Cisco devices, there are three Ethernet trunk encapsulation types:

  • ISL: Uses Inter-Switch Link (ISL) encapsulation on the trunk link
  • Dot1q: Uses 802.1Q encapsulation on the trunk link
  • Negotiate: Specifies that the LAN port negotiate with the neighboring LAN port to become an ISL (preferred) or 802.1Q trunk, depending on the configuration and capabilities of the neighboring LAN port

The trunking mode, the trunk encapsulation type, and the hardware capabilities of the two connected LAN ports determine whether a link becomes an ISL or 802.1Q trunk. A common practice is to configure both ends of the trunk to desirable. This has the operational benefit of providing a clear indication of a functional trunking connection with show commands, and is the general recommendation for DTP trunking.

An alternative practice is to set one side of the link (typically the access layer) to Auto and the other end (typically the distribution layer) to Desirable. This setting allows for automatic trunk formation, with DTP running on the interconnection to protect against some rare hardware failure scenarios and software misconfigurations.

For fastest convergence, a third configuration turns DTP to On and On with Nonnegotiate to save a few seconds of outage when restoring a failed link or node. However, DTP is not actively monitoring the state of the trunk with this configuration, and a misconfigured trunk is not easily identified. The Nonnegotiate setting can also cause loss of connectivity if the process is not performed in the correct order and there is no out-of-band connectivity to the farthest switch from where the in-band modifications are being made.

Recommended Practices for UDLD Configuration

UDLD enables devices to monitor the physical configuration of the cables and detect when a unidirectional link exists where bidirectional communication has not been established.

UDLD is typically deployed on fiber topologies where physical misconnections can occur that enable a link to appear to be up/up when there is a mismatched set of transmit/receive pairs. UDLD supports both fiber-optic and copper Ethernet cables connected to LAN ports.

Each switch port configured for UDLD will send UDLD protocol hello packets at Layer 2 containing the device and port identifications of the port, and the device and port identifications of the neighbor as seen by UDLD on that port. Neighboring ports should see their own device and port identifications in the packets received from the other side. If the port does not see its own device and port identifications in the incoming UDLD packets for a specific duration of time, the link is considered unidirectional and is shut down. The default 15-second hello timers are the same for normal and aggressive UDLD. In normal mode, UDLD will error-disable only the end where the UDLD is detected; aggressive mode will error-disable both ends of a connection after aging on a previously bidirectional link in eight seconds.

A recommended practice is to enable UDLD aggressive mode in all environments where fiber-optic interconnections are used. UDLD is enabled globally on all fiber-optic LAN ports with the Cisco IOS software udld {enable | aggressive} command. UDLD is enabled on individual LAN ports with the udld port [aggressive] interface command.

NOTE

You should enable UDLD in global mode so that you do not have to enable it on every individual fiber-optic interface.

Recommended Practices for EtherChannel

An EtherChannel bundles individual Ethernet links into a single logical link that provides the aggregate bandwidth of up to eight physical links.

EtherChannels are typically deployed between the distribution-to-core and core-to-core interconnections where increased availability and scaled bandwidth are required. EtherChannel link aggregation is used to provide link redundancy and prevent a single point of failure, and to reduce peering complexity because the single logical entity reduces the number of Layer 3 neighbor relationships as compared to multiple parallel links.

NOTE

EtherChannel also provides an optimization to STP by enabling all member ports to be placed in the forwarding mode. STP views the EtherChannel as a single logical link.

EtherChannels create channels containing up to eight parallel links between switches. If the channels are on interfaces that are on different physical line cards, there is increased availability because the failure of a single line card does not cause a complete loss of connectivity.

There are two variants for the control mechanism for EtherChannel: the prestandard Cisco implementation that uses Port Aggregation Protocol (PAgP), and the IEEE 802.3ad standards-based implementation that uses Link Aggregation Control Protocol (LACP). PAgP and LACP do not interoperate. You can manually configure a switch with PAgP on one side and LACP on the other side in the on/on mode. When this is done, ports configured in the on mode do not negotiate, and therefore there is no negotiation traffic between the ports. This configuration results in the EtherChannel being hard-coded.

When connecting a Cisco IOS Software device to a Catalyst operating system device, make sure that the PAgP settings used for establishing EtherChannels are coordinated. The defaults are different for a Cisco IOS Software device and a Catalyst operating system device. As a recommended practice, Catalyst operating system devices should have PAgP set to Off when connecting to a Cisco IOS Software device if EtherChannels are not configured. If EtherChannel PAgP is used, set both sides of the interconnection to Desirable.

Port aggregation should be disabled when not needed. Port aggregation can most effectively be controlled by disabling it on interfaces facing end users with the set port host macro on the Catalyst operating system or the switchport host macro on Cisco ISO Software. These macros disable both trunking and EtherChannel while enabling STP PortFast.

Port Aggregation Protocol

PAgP is one of the control mechanisms for EtherChannel. PAgP has four modes related to the automatic formation of bundled, redundant switch-to-switch interconnections (see Figure 2-12):

  • On: Mode that forces the LAN port to channel unconditionally. In the on mode, a usable EtherChannel exists only when a LAN port group in the on mode is connected to another LAN port group in the on mode. Because ports configured in the on mode do not negotiate, no negotiation occurs traffic between the ports. You cannot configure the on mode with an EtherChannel protocol. If one end uses the on mode, the other end must also.
  • Desirable: Places a port into an active negotiating state, in which the port starts negotiations with other ports by sending PAgP packets. This mode is not supported when the EtherChannel members are from different switches in the switch stack (cross-stack EtherChannel).
  • Auto: Places a port into a passive negotiating state, in which the port responds to PAgP packets it receives but does not start PAgP packet negotiation. This setting minimizes the transmission of PAgP packets. This mode is not supported when the EtherChannel members are from different switches in the switch stack (cross-stack EtherChannel).
  • Off: Do not become a member.

As with DTP, the long-standing practice for EtherChannel/PAgP has been to set one side of the interconnection (typically the access switch) to Auto and the other side (typically the distribution switch) to Desirable, or both sides to Desirable. In these configurations, an EtherChannel is established when configuration is complete, and connectivity to the remote switch is always available, even when the EtherChannel is not completely established.

NOTE

For Layer 2 EtherChannels, a desirable/desirable PAgP configuration is recommended so that PAgP is running across all members of the bundle, ensuring that an individual link failure will not result in a STP failure.

Link Aggregation Control Protocol

LACP is another control mechanism for EtherChannel. LACP has four modes related to the automatic formation of bundled, redundant switch-to-switch interconnections:

  • On: Mode that forces the LAN port to channel unconditionally. In the on mode, a usable EtherChannel exists only when a LAN port group in the on mode is connected to another LAN port group in the on mode. Because ports configured in the on mode do not negotiate, no negotiation traffic occurs between the ports. You cannot configure the on mode with an EtherChannel protocol. If one end uses the on mode, the other end must also.
  • Active: LACP mode that places a port into an active negotiating state, in which the port initiates negotiations with other ports by sending LACP packets.
  • Passive: LACP mode that places a port into a passive negotiating state, in which the port responds to LACP packets it receives but does not initiate LACP negotiation.
  • Off: Do not become a member.

NOTE

The recommended practice for EtherChannel LACP is to set one side of the interconnection (typically the access switch) to Active and the other side (typically the distribution switch) to Passive, or both sides to Active. In these configurations, a channel is established when configuration is complete, and connectivity to the remote switch is always available, even when the channel is not completely established.

3. Developing an Optimum Design for Layer 3 | 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