Home > Articles > Cisco Certification > CCNP > CCNP ISCW Exam Guide: GRE Tunneling over Ipsec

CCNP ISCW Exam Guide: GRE Tunneling over Ipsec

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jun 24, 2008.

Chapter Description

The growth of IPsec saw a rebirth in the use of GRE in IP networks. This chapter talks about the use of GRE in an IPsec environment and how that relates to the CCNP ISCW exam.

Foundation Topics

GRE Characteristics

The initial power of GRE was that anything could be encapsulated into it. The primary use of GRE was to carry non-IP packets through an IP network; however, GRE was also used to carry IP packets through an IP cloud. Used this way, the original IP header is buried inside of the GRE header and hidden from prying eyes. The generic characteristics of a GRE tunnel are as follows:

  • A GRE tunnel is similar to an IPsec tunnel because the original packet is wrapped inside of an outer shell.
  • GRE is stateless, and offers no flow control mechanisms.
  • GRE adds at least 24 bytes of overhead, including the new 20-byte IP header.
  • GRE is multiprotocol and can tunnel any OSI Layer 3 protocol.
  • GRE permits routing protocols to travel through the tunnel.
  • GRE was needed to carry IP multicast traffic until Cisco IOS Software Release 12.4(4)T.
  • GRE has relatively weak security features.

The GRE tunnel itself is similar to an IPsec tunnel. The tunnel has two endpoints. Traffic enters one end of the tunnel and exits the other end. While in the tunnel, routers use the new outer header only to forward the packets.

The GRE tunnel is stateless. Unlike an IPsec tunnel, the endpoints do not coordinate any parameters before sending traffic through the tunnel. As long as the tunnel destination is routable, traffic can flow through it. Also, by default, GRE provides no reliability or sequencing. Such features are typically handled by upper-layer protocols.

GRE tunnels offer minimal security, whereas IPsec offers security by means of confidentiality, data authentication, and integrity assurance. GRE has a basic encryption mechanism, but the key is carried along with the packet, which somewhat defeats the purpose.

GRE does add an additional 24-byte header of overhead. This overhead contains a new 20-byte IP header, which indicates the source and destination IP addresses of the GRE tunnel. The remaining 4 bytes are the GRE header itself. Additional GRE options can increase the GRE header by up to another 12 bytes.

It is important to note that the larger packet size caused by the additional headers can have a detrimental effect on network performance. Because the additional headers are dynamically added, most users believe that nothing "bad" can happen as a result. If a packet is larger than the interface maximum transmission unit (MTU) permits, the router must fragment the packet into smaller pieces to fit. This fragmentation effort can add significant CPU overhead to a router, which can affect all packet forwarding.

GRE is a simple yet powerful tunneling tool. It can tunnel any OSI Layer 3 protocol over IP. As such, it is basically a point-to-point private connection. A private connection between two endpoints is the basic definition of a VPN.

Unlike IPsec, GRE permits routing protocols (such as OSPF and EIGRP) across the connection. This is not the case with typical IPsec tunnels. IPsec tunnels can send IP packets, but not routing protocols. Before the IP packets can travel through the IPsec tunnel, however, static routes are necessary on each IPsec endpoint for routing awareness of the opposite end. This additional configuration overhead does not scale well with a large number of IPsec tunnels.

Until Cisco IOS Software Release 12.4(4)T, IP multicast had to be sent over GRE. Prior to this IOS release, IPsec could not carry IP multicast traffic. Even though IOS 12.4(4)T now supports IP multicast traffic, GRE over IPsec still must be used to carry dynamic routing protocols.

GRE does not have any strong security features. The header provides an optional, albeit weak, security key mechanism. As a result, no strong confidentiality, data source authentication, or data integrity mechanisms exist in GRE. However, IPsec provides confidentiality (DES, 3DES, or AES), and source authentication and data integrity with MD5 or SHA-1 HMACs.

Thus, a GRE tunnel, which carries multicast and routing traffic, can be sent through an IPsec tunnel for enhanced security.

GRE Header

The GRE header itself contains 4 bytes, which represent the minimum size of GRE header with no added options. The first pair of bytes (bits 0 through 15) contains the flags that indicate the presence of GRE options. Such options, if active, add additional overhead to the GRE header. The second pair of bytes is the protocol field and indicates the type of data that is carried in the GRE tunnel. Table 14-2 describes the GRE header options.

Table 14-2. GRE Header Options

GRE Header Bit




Checksum Present

Adds a 4-byte checksum field to the GRE header after the protocol field if this bit is set to 1.


Key Present

Adds a 4-byte encryption key to the GRE header after the checksum field if this bit is set to 1.


Sequence Number Present

Adds a 4-byte sequence number to the GRE header after the key field if this bit is set to 1.


GRE Version

0 indicates basic GRE, while 1 is used for PPTP.

The Checksum Present option (bit 0) adds an optional 4-byte checksum field to the GRE header. This checksum appears after the protocol field in the GRE header only if the Checksum Present bit is set. Normally, this option is not needed because other upper-layer protocols provide checksum capabilities to detect packet corruption.

The Key Present option (bit 2) adds an optional 4-byte key field to the GRE header. This clear-text key follows the checksum field. The key is used to provide basic authentication where each GRE endpoint has the key. However, the key itself is exposed in the GRE header. Due to this vulnerability, GRE encryption is not typically used. However, the key value can be used to uniquely identify multiple tunnels between two endpoints. This would be similar to an IPsec SPI.

The Sequence Number option (bit 3) adds an optional 4-byte sequence number field to the GRE header. This sequence value follows the key option. This option is used to properly sequence GRE packets upon arrival. Similar to the checksum option, this is not typically used because upper-layer protocols also offer this functionality.

Bits 13–15 indicate the GRE version number. 0 represents basic GRE, while 1 shows that the Point-to-Point Tunneling Protocol (PPTP) is used. PPTP is not covered in this book.

The second 2 bytes of the GRE header represent the Protocol field. These 16 bits identify the type of packet that is carried inside the GRE tunnel. Ethertype 0x0800 indicates IP. Figure 14-1 shows a GRE packet with all options present added to an IP header and data.

Figure 14-1

Figure 14-1 GRE Packet Format

In Figure 14-1, only the required GRE header and original IP header and packet typically appear in GRE tunnel configurations. The GRE options are normally not used because upper-layer protocols provide similar functionality.

Basic GRE Configuration

A GRE tunnel carries some Layer 3 protocol between two IP endpoints. During the initial use of GRE tunnels, the tunnel contents were typically any protocol except IP. Today, GRE tunnels are used to carry IP data over an IP network. But the GRE tunnel itself can be sent through an IPsec tunnel for security. Figure 14-2 shows a basic GRE tunnel setup.

Figure 14-2

Figure 14-2 GRE Tunnel Configuration

The basic configuration components of a GRE tunnel include

  • A tunnel source (an interface or IP address local to this router)
  • A tunnel destination (an IP address of a remote router)
  • A tunnel mode (GRE/IP is the default)
  • Tunnel traffic (data that travels through the tunnel, and is encapsulated by the GRE header)

In Figure 14-2, two IP endpoints have a GRE tunnel configured between them. The GRE tunnel is actually defined as an interface in each router. The GRE interface is what makes GRE multiprotocol. IPsec crypto maps can match only IP access lists. A router interface can be configured for, and thus transport, any protocol. The available protocols are dependent upon the Cisco IOS feature set installed.

The tunnel source and destination are IP interfaces. Thus, the GRE travels across an IP network. The protocol configured on the GRE interfaces is the data that travels through the GRE tunnel.

The GRE tunnel source on one end must match the destination on the other end, and vice versa. This IP validation is performed as the GRE tunnel is established. For proper routing through the GRE tunnel, a common subnet should be configured within the tunnel.

In Figure 14-2, IP is configured within the GRE tunnel. The two sites, as well as the tunnel itself, use RFC 1918 private addressing. IP routing flows between the sites through the GRE tunnel by means of your favorite routing protocol (not shown). For documentation purposes, the public network also uses private addressing, although this certainly is not a requirement.

Secure GRE Tunnels

"GRE over IPsec" implies that the GRE packet sits higher in the stack than the IPsec portion. Similar to how TCP/IP is represented, TCP is at Layer 4, while IP is at Layer 3. When laid out in a graphical packet, the TCP portion is inside of the IP part. The same is true with GRE over IPsec. The original packet is the innermost layer. Then the GRE wrapper appears. Finally, the IPsec portion is added for security. Figure 14-3 shows the GRE over IPsec packet format.

Figure 14-3

Figure 14-3 GRE over IPsec Packet Format

As Figure 14-3 shows, there are multiple IP layers in a GRE over IPsec packet. The innermost layer is the original IP packet. This represents data that is traveling between two devices, or two sites. The initial IP packet is wrapped in a GRE header to permit routing protocols to travel between in the GRE tunnel (something that IPsec alone cannot do). And IPsec is added as the outer layer to provide confidentiality and integrity (which is a shortcoming of GRE by itself). The end result is that two sites can securely exchange routing information and IP packets.

Figure 14-3 is also a reminder of the two IPsec modes: tunnel and transport. Transport mode is used if the original IP header can be exposed, while tunnel mode protects the original IP header within a new IPsec IP header. When using GRE over IPsec, transport mode is often sufficient, because the GRE and IPsec endpoints are often the same. Whether tunnel or transport mode is selected, the original IP header and packet are fully protected.

What might get lost in Figure 14-3 is the size of the new packets created due to the additional encapsulations. Each IP header adds 20 bytes to the packet size. This does not include overhead for ESP and GRE headers. For small IP packets, it is possible that the GRE over IPsec headers may be much larger than the original packet itself. Network efficiency can be determined by the ratio of actual data compared to the overhead associated with transporting the data. When there is more overhead (packet headers) than actual data, then the network is inherently less efficient.

Most GRE over IPsec implementations use a hub-and-spoke design. Although not a requirement, such a design minimizes the management overhead seen with managing a large number of IPsec tunnels. For example, if ten sites were fully meshed with GRE over IPsec tunnels, it would take 45 tunnels ([10 * 9]/2). In a hub-and-spoke design, full connectivity (via the hub) is accomplished with only nine tunnels. Figure 14-4 graphically compares a full mesh of tunnels versus a hub-and-spoke design.

Figure 14-4

Figure 14-4 Full Mesh versus Hub-and-Spoke

In a normal IPsec tunnel, static routes are needed to direct IP packets into the IPsec VPN tunnel. Routing protocols can run inside the GRE tunnel, creating a dynamic routing topology. GRE provides the routing connectivity, while IPsec provides the confidentiality and integrity. With GRE, routing protocols can now run inside the IPsec tunnel.

Configure GRE over IPsec Using SDM

This chapter explores how to configure GRE over IPsec using the SDM tool. The previous chapter gave you the opportunity to create an IPsec tunnel in SDM, and get familiar with the SDM interface. This section expands upon previous navigation skills that you have learned.

Launch the GRE over IPsec Wizard

The GRE over IPsec wizard is accessed from the same window that started the Site-to-Site VPN wizard as seen in Chapter 13. Figure 14-5 shows how to access the GRE over IPsec wizard.

Figure 14-5

Figure 14-5 GRE over IPsec Wizard

Similar to how the Site-to-Site VPN Wizard was initiated in Chapter 13, the GRE over IPsec wizard is accessed as follows:

  1. Step 1 Click the Configure button at the top of the window.
  2. Step 2 Click the VPN button in the Tasks bar on the left.
  3. Step 3 Click the Site-to-Site VPN option at the top of the menu.
  4. Step 4 Click the Create Site to Site VPN tab in the window.
  5. Step 5 Click the Create a secure GRE tunnel (GRE over IPSec) radio button.
  6. Step 6 Click the Launch the selected task button at the bottom of the window.

When you successfully accomplish these tasks, the Secure GRE Wizard starts. The Secure GRE Tunnel (GRE over IPsec) window reminds you of the capabilities and purpose of such a tunnel. The basic steps of the Secure GRE Wizard are as follows:

  1. Step 1 Create the GRE tunnel.
  2. Step 2 Create a backup GRE tunnel (optional).
  3. Step 3 Select the IPsec VPN authentication method.
  4. Step 4 Select the IPsec VPN IKE proposals.
  5. Step 5 Select the IPsec VPN transform sets.
  6. Step 6 Select the routing method for the GRE over IPsec tunnel.
  7. Step 7 Validate the GRE over IPsec configuration.

To continue into the wizard, click Next> at the bottom of the window.

Step 1: Create the GRE Tunnel

The first part of the GRE over IPsec tunnel is the GRE tunnel. Figure 14-3 showed the various layers within the GRE over IPsec tunnel. The original IP packet is the innermost portion. Next comes the GRE layer. Figure 14-6 shows the GRE Tunnel Information window.

Figure 14-6

Figure 14-6 GRE Tunnel Information

The GRE Tunnel Information window is the first configuration window of the Secure GRE Wizard. There are two sets of IP addresses that are applied to the GRE tunnel interface—the tunnel source and destination (at the top of the window) represent the GRE IP header (shown in Figure 14-3).

The tunnel source is either selected from a pull-down list of interfaces in this router or entered manually. If an interface is selected from the list, the IP address of the interface is automatically used as the GRE tunnel source. The tunnel destination is the IP address of the remote GRE peer and must be manually entered.

The IP address of the GRE tunnel is the IP subnet used within the tunnel itself. This subnet can be used for management (the other end can be pinged) or, more importantly, for routing protocol neighbors. The remote GRE peer must use a unique IP address on the same inner subnet.

Path MTU is enabled by default. Remember that GRE over IPsec considerably increases the IP packet size. Path MTU discovery uses Internet Control Message Protocol (ICMP) Unreachable messages to determine the maximum packet size possible between the GRE peers. If needed, fragmentation can then be performed by the GRE endpoints, versus en route, where it might not be performed at all.

When you are finished with the GRE Tunnel Information window, click Next> at the bottom of the window.

Step 2: Create a Backup GRE Tunnel

The Secure GRE Wizard offers the option to create a second GRE tunnel for survivability. If the GRE tunnel fails for any reason, then the IPsec tunnel that is carried within it fails also. A backup GRE tunnel provides stateless failover in the event of the loss of the primary GRE tunnel. Figure 14-7 shows the Backup GRE Tunnel Information window.

Figure 14-7

Figure 14-7 Backup GRE Tunnel Information

Because a backup GRE tunnel is an optional feature, you must check the Create a backup secure GRE tunnel for resilience box to activate this window. Once checked, the configuration options are very similar to those used to create the primary GRE tunnel.

The same tunnel source is used for both the primary and backup GRE tunnels, so there is no opportunity to select a tunnel source in the Backup window. Either an interface or a local IP address was entered earlier for the primary GRE tunnel. Simply enter the IP address of the alternate peer for this backup GRE tunnel. This IP address could be a different interface on the same peer router, or an entirely different device at the remote site.

Similar to the primary GRE tunnel, you must create a unique IP address on a new IP subnet within this backup tunnel. The remote peer must use the same subnet with an exclusive IP address of its own. As with the primary GRE tunnel, the inner IP addresses are used to establish routing protocol neighbors.

When you are finished with the Backup GRE Tunnel Information window, click Next> at the bottom of the window.

Steps 3–5: IPsec VPN Information

The outermost layer of the GRE over IPsec tunnel is the IPsec VPN. The various windows used to enter the IPsec information are nearly identical to those used to create a site-to-site IPsec VPN discussed in Chapter 13, "Site-to-Site VPN Operations."

The first IPsec VPN task is to enter the VPN authentication information. Similar to Figure 13-14, either digital certificates or pre-shared keys can be used. If pre-shared keys are selected, the key must be entered twice to ensure accuracy.

The second IPsec VPN task is to select or create IKE proposals. This window is identical to the one shown in Figure 13-15, as are the procedures used to select an appropriate IKE proposal for this IPsec VPN. Remember that the remote IPsec peer must have an identical IKE proposal configured, and that the same IKE proposal can be used for many remote peers.

The third IPsec VPN task is to select or create IPsec transform sets. This window is identical to the one shown in Figure 13-16. From here, new transform sets can be created, and the appropriate transform set can be selected for use with this IPsec VPN. Remember that the remote IPsec peer must have an identical IPSec transform set configured, and that the same IPsec transform set can be used for many remote peers.

Step 6: Routing Information

Once both the GRE tunnel and the IPsec tunnels have been configured, the final step is to select a routing protocol to traverse the GRE tunnel. Remember that with a typical IPsec VPN, the only routing option is to configure static routes on each side. These static routes manually determine which prefixes are reachable through the IPsec VPN. Figure 14-8 shows the Select Routing Protocol window of the Secure GRE Wizard.

Figure 14-8

Figure 14-8 Select Routing Protocol

Static Routing is the default option (radio button) in the routing protocol selection process. There are four routing options supported within the GRE tunnel:

  • OSPF
  • RIP
  • Static routing

Each routing option uses the Routing Information window to configure individual options. Routes that are manually configured (static) or dynamically exchanged (RIP, OSPF, or EIGRP) through the GRE over IPsec tunnel become the "interesting traffic" described that decides which traffic is encrypted through the IPsec tunnel. Once you have selected a routing protocol, click Next> at the bottom of the window to proceed to the Routing Information window for the appropriate routing protocol.

When using the GRE over IPsec wizard, RIP is not an available dynamic routing option from the Select Routing Protocol window if a backup GRE tunnel was configured earlier. Only OSPF or EIGRP can be enabled when two GRE tunnels to the same remote location are used.

Static Routes

Static routing is typically used to support small stub sites that only have a single subnet. No dynamic routing information is exchanged between sites. If a site has multiple subnets that are to use the VPN, or if a site uses backup VPN tunnels, then static routing is inappropriate.

If static routing is selected in the Select Routing Protocol window of the wizard, the first choice presented is whether to do split tunneling or not. Split tunneling allows the router to send some traffic through the IPsec VPN to the remote side, and the remainder of the traffic unprotected into the public network. This is very similar to the definition of interesting traffic with IPsec VPNs. Enter an IP subnet and subnet mask that is to be protected in the VPN tunnel.

The wizard permits only a single static route to be configured within the split tunneling option. If split tunneling is not selected (the Tunnel All Traffic option), then a default route is added to the router that sends all traffic through the GRE over IPsec tunnel.

When you are finished with the static routing options, click Next> at the bottom of the window to advance to the Summary of the Configuration window.


The first RIP configuration option is the version. Select version 1 to use the older classful version of RIP, or version 2 for the more modern classless version that sends the subnet mask with the routing updates. Next, click the Add... button local networks to the RIP routing protocol. Remember that you can add only whole classful network numbers to RIP, and all subnets of that network number are included. You must add the IP subnet of the GRE interface for RIP to use the interface.

Routes that are not added to the RIP configuration are not exchanged through the GRE over IPsec tunnel. Only traffic in the exchanged routes is protected by the VPN. Traffic outside of the RIP routes avoids the VPN. It is important that the remote router also correctly configure RIP so routing neighbors can be formed.

When you are finished with the RIP options, click Next> at the bottom of the window to advance to the Summary of the Configuration window.


The first OSPF task is to select or create an OSPF process ID. If OSPF is already operational in the router, you can select a process ID from the pull-down menu. If not, you must create a new OSPF process in the router. Once the process ID is configured, you must determine the OSPF area ID to be used in the GRE over IPsec tunnel.

Next, you must click the Add... button to add local networks to the OSPF routing protocol. In OSPF, you must enter a subnet number, a wildcard mask, and an area for each network. You must add the IP subnet/mask/area of the GRE interface for OSPF to use the interface.

Routes that are not added to the OSPF configuration are not exchanged through the GRE over IPsec tunnel. Only traffic in the exchanged routes is protected by the VPN. Traffic outside of the OSPF routes avoids the VPN. It is important that the remote router also correctly configure OSPF so routing adjacencies can be formed. For OSPF, this means that both peers use a common subnet and the same OSPF area.

When you are finished with the OSPF options, click Next> at the bottom of the window to advance to the Summary of the Configuration window.


The first EIGRP task is to select or create an EIGRP autonomous system (AS) number. If EIGRP is already operational in the router, you can select an AS number from the pull-down menu. If not, you must create a new EIGRP AS number in the router.

Then, you must click the Add... button to add local networks to the EIGRP routing protocol. In EIGRP, you must enter a subnet number and a wildcard mask for each network. You must add the IP subnet/mask of the GRE interface for EIGRP to use the interface.

Routes that are not added to the EIGRP configuration are not exchanged through the GRE over IPsec tunnel. Only traffic in the exchanged routes is protected by the VPN. Traffic outside of the EIGRP routes avoids the VPN. It is important that the remote router also correctly configure EIGRP so routing neighbors can be formed. For EIGRP, this means that both peers use a common subnet and the same EIGRP AS.

When you are finished with the EIGRP options, click Next> at the bottom of the window to advance to the Summary of the Configuration window.

Step 7: Validate the GRE over IPsec Configuration

Once you advance beyond either of the routing options (the appropriate Routing Information window), you reach the Summary of the Configuration window. You likely need to use the scrollbar to view the entire configuration created by the Secure GRE Wizard. This window is identical to the summary window at the end of the Site-to-Site VPN Wizard. The differences here are the additional configuration options of the GRE tunnel and the routing protocol (if one was configured).

As with the Site-to-Site VPN Wizard, you can either click Finish to end the wizard from this window or click <Back to go back into the wizard to modify any of the configurations shown.

Once the configuration is complete, the procedures to test and monitor the GRE over IPsec tunnel are identical to those for the site-to-site IPsec tunnel described in Chapter 13.

3. Foundation Summary | 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.


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.


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@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.


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 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.


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