Home > Articles > Networking

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Other Design and Deployment Issues

Beyond deciding whether or not to divide an IS-IS network into multiple domains, and where the domain borders should be if you decide to separate the domain, what other issues should you look for when designing and deploying an IS-IS network? There are a few things that you should look at regardless of what routing protocol you are using, such as summarizing IP prefixes or dialer interfaces, while there are others, which are more specific to IS-IS, such as tuning the various IS-IS timers.

Summarizing IP Prefixes

One of the most important issues to address when designing or deploying an IP network is prefix summarization. Summarization is a very simple concept—the basic premise is to reduce the amount of information that intermediate systems must handle while computing the best paths through the network by hiding information about reachable destinations. For instance, in the network illustrated in Figure 4-4, each time intermediate systems B and C need to run SPF,

Figure 4-4Figure 4 – 4 A highly summarizable address space

Since all of these networks are reachable through a single point, why not describe them with a single prefix (or advertisement), rather than 16? That is exactly what summarization does—rather than advertise a large number of destinations, they are summarized into a single prefix at intermediate system A, which then advertises it towards B and C. In this case, 10.1.0.0/21 would include all of the destinations from 10.1.0.0 through 10.1.15.255.

Calculating IP Summaries

IP summarization, although simple in principle, is a confusing topic to many people. The general idea is to shorten the prefix length (the number of bits set in the subnet mask) so a single advertisement covers, or represents, more address space. For instance, in the network illustrated in Figure 4-4, we begin with 16 different destinations, each with a 24-bit mask.

Figure 4-5Figure 4 – 5 IP address summarization

What we want to do is to find a single destination we can advertise from intermediate system A that will represent all of the destinations covered by these 16 advertisements. The most straightforward way of finding the single prefix is to figure out the lowest and highest addresses represented by the range of addresses we would like to replace, and then try to find one prefix that will represent all of those addresses by itself. In this example, we would begin with the address 10.1.0.0, since that is the lowest address in the range, and end with the highest address of

10.1.15.255. Is there any prefix we can use to represent this entire address range? If we were to lay all of these addresses out in binary, we would find that the top 20 bits of every address remain the same throughout the entire address range.

So, we can use a single prefix with 20 bits set in its subnet mask to represent all of the addresses covered by the 16 individual prefixes, each with 24 bits set in their subnet masks. This 20-bit prefix is called a summary.

Summarization in IS-IS can only be configured at the intermediate system that is injecting the IP destinations or at a domain border. For instance, in Figure 4-4, the specific routes are static routes in intermediate system A, so it is the only node that could summarize the routes into a single advertisement. To configure a summary on a Cisco router in IS-IS, use the summary-address command within the router isis submode.

!
router isis 		
 summary-address 10.1.0.0 255.255.240.0
 redistribute static metric 10 level-2
 net 49.0001.1111.1111.1111.00
!

Once these commands are configured on A, its routing table will show the 16 individual 24-bit prefixes plus the single 21-bit summary prefix.

router-a#show ip route
....
   10.0.0.0/8 is variably subnetted, 16 subnets, 2 masks
S    10.1.11.0/24 [115/10] via 10.1.11.1, Serial11
S    10.1.10.0/24 [115/10] via 10.1.10.1, Serial10
S    10.1.9.0/24 [115/10] via 10.1.9.1, Serial9
S    10.1.8.0/24 [115/10] via 10.1.8.1, Serial8
S    10.1.14.0/24 [115/10] via 10.1.14.1, Serial14
S    10.1.13.0/24 [115/10] via 10.1.13.1, Serial13
S    10.1.12.0/24 [115/10] via 10.1.12.1, Serial12
S    10.1.3.0/24 [115/10] via 10.1.3.1, Serial3
S    10.1.2.0/24 [115/10] via 10.1.2.1, Serial2
S    10.1.1.0/24 [115/10] via 10.1.1.1, Serial1
i su  10.1.0.0/20 [115/0] via 0.0.0.0, Null0
S    10.1.0.0/24 [115/10] via 10.1.10.1, Serial0
S    10.1.7.0/24 [115/10] via 10.1.7.1, Serial7
S    10.1.6.0/24 [115/10] via 10.1.6.1, Serial6
S    10.1.5.0/24 [115/10] via 10.1.5.1, Serial5
S    10.1.4.0/24 [115/10] via 10.1.4.1, Serial4

Note the summary route indicated in bold type in the output above; IS-IS automatically injects the route into the routing table when the summary is configured on A. On intermediate system B, issuing the show ip route command shows only the summary route; none of the components are shown.

router-b#show ip route
....  10.0.0.0/20 is subnetted, 1 subnets
i L2  10.1.0.0 [115/20] via 208.0.2.5, Serial0/3

The summary route A is advertising to intermediate system B looks like any other L2 route B is receiving.

IP Summaries and Routing Black Holes

One issue to be careful of when summarizing destinations in a network with redundant level 1 and level 2 connections is routing black holes. Figure 4-6

Figure 4-6Figure 4 – 6 A routing black hole in the making

This network design appears to be perfectly reasonable when it's initially deployed, with redundancy provided for destinations within the 192.168.50.0/24 network. However, when the link between B and D fails, the network administrators suddenly discover that 192.168.50.0/24 is no longer reachable. Why? Since both intermediate systems B and C are advertising the same route to A, A must choose between the two routes when calculating the best paths through the network. In this case, we will assume A chooses the path through the level 1/level 2 border B for all traffic destined to 192.168.48.0/20, which includes all the destinations on the 192.168.50.0/24 network. When the link between intermediate systems B and D fails, there is no reason for B to stop advertising the 192.169.48.0/20 IP summary, since it still has at least one component in the summary, 192.168.49.0/24, which is directly attached. In fact, neither B nor C will advertise any changes in this summary at all.

Router A will continue routing all traffic for any destination within 192.168.48.0/20 through intermediate system B, and B will drop the traffic destined to 192.168.50.0/24, since it no longer has a route to that destination network. This result is a very common problem in network designs with redundant connections between L1 and L2 domains.

How can you resolve this problem? One option is to simply not have redundant paths between L1 and L2 domains. This is not a very good solution, because it results in single points of failure. Another option is to simply not summarize between L1 and L2. Again, this is not a very good option either, since it will likely limit the scaling of your network over the long haul.

Yet another option is to provide an alternate link between the redundant connecting intermediate systems between the domains, as illustrated in Figure 4-7.

Figure 4-7Figure 4 – 7 Resolving the routing black hole

This solution provides intermediate system B with an alternate link to reach the 192.168.50.0/24 network should the link between B and D fail. Links of this type must be used with some caution, however, and their capacity must be carefully planned. Assuming that the link between B and C will only carry one remote site's worth of traffic probably is not a good idea. If there are, say, 200 remote sites dual-homed between Routers B and C, a single massive failure could redirect all of the traffic to and from these sites across this single link. Careful network traffic flow and capacity planning are required to make this solution work well.

Some IS-IS implementations offer still another solution: automatic deaggregation. The details of the operation might be rather involved in some cases. Both intermediate systems B and C are part of the same level 1 and level 2 domains. Before any failure, intermediate system B might notice that another node (C in this example) is advertising the same summary through the level 2 domain. At the same time, intermediate system B can verify that C is reachable through the level 1 domain when it runs SPF for the domain and C's LSP is part of the resulting tree. If the second condition changes (C is not reachable anymore through the level 1 domain), but the first one is maintained, then B can deaggregate the summary and advertise the more specific routes. Of course, C would follow a similar process and it would also advertise the specific routes it can reach. The result is that intermediate system A (and all the other nodes in the level 2 domain) now have specific knowledge of which prefixes are reachable through which entry into the level 1 domain. Once the partition is resolved, both intermediate systems will continue advertising just the summary.

Timer Tuning

Within the IS-IS protocol, there are many timers which may be configured or set to defaults, including the flooding timers, the hello interval, the hold interval (or multiplier), shortest path first interval, and the link state packet generation interval. When you are designing a network with a particular goal in mind, such as minimum control traffic or very fast convergence times, it is sometimes advantageous to change these timers to better fit the network.

Routing protocols are deployed in many different situations that can be radically different from the circumstances their designers anticipated. Because of that, many of the default timers decided on when routing protocols were first designed can (and should) be reviewed against what the goals of any given intermediate system are for possible changes that might improve network performance.

IS-IS Flooding Timers

By default, IS-IS intermediate systems reflood the LSPs they created (self-originated LSPs) on a regular basis—about every 20 minutes. What is the purpose of this flooding? To guard against corrupted LSPs.

But isn't reflooding about every 20 minutes a little excessive? What are the odds that a mistake in the database, through packet corruption or other means, is going to surface in an IS-IS network? At one time, the odds were believed to be reasonably high, which is why the timers are set for such a relatively short interval.

With network infrastructure improving all the time, however, the chances of a packet being corrupted as it transits the network, or bad information getting into and staying in the LSP database on any one intermediate system for a long period of time, seems unlikely. This reliability, together with recent efforts at optimizing the use of network bandwidth (which typically means reducing the ratio of control to user traffic passed across a network), has resulted in some investigation into how the flooding of information through an IS-IS domain can be reduced.

Thus, one timer that can be considered for adjustment is the IS-IS reflooding interval. To configure the flooding interval in the Cisco IOS Software, use the router isis submode command lsp-refresh-interval:

router(config-router)#lsp-refresh-interval ?
 <1-65535> LSP refresh time in seconds

When configuring the LSP refresh interval, you should remember to set the max-lsp-lifetime value, also within the router isis submode, to something a bit longer than the lsp-refresh-interval value.

router(config-router)#max-lsp-lifetime ? 
 <1-65535> Maximum LSP lifetime in seconds 

A higher max-lsp-lifetime setting causes the intermediate system to generate LSP's that have a longer lifetime, which means that the LSPs will be considered valid longer by other intermediate systems in the network. Setting lsp-refresh-interval to a high value without changing the max-lsp-lifetime setting might cause other intermediate systems to time out the LSPs received before they have received a replacement (refreshed) LSP.

Many large-scale IS-IS networks are using the maximum time possible as their refresh rate—about 18.7 hours. Using this large a timer for the refresh max-lsp-lifetime value can significantly cut the amount of traffic that IS-IS generates on a very large network.

These two timers do not need to be set the same on all the intermediate systems in the network; each intermediate system can have different lsp-refresh-interval and max-lsp-lifetime values. If you decide to change the value in your network, make sure that max-lsp-lifetime is set to a number larger than the lsp-refresh-interval.

Hello and Hold Intervals

In the early days of the Internet, when IS-IS and the other routing protocols were first designed and deployed, many of the links in the Internet (and other networks) were slow links that frequently had high error rates on them. Furthermore, much of the traffic carried across networks was not anywhere close to real time in nature—that is, it didn't matter much if there was a delay of nine or ten seconds in delivering a given packet, or if it had to be retransmitted several times before it was finally delivered.

In this environment, when deciding how often intermediate systems would send hellos to each other (and how long they would wait since receiving a hello from a neighbor before timing out and assuming the neighbor had failed), slightly longer intervals of time seemed more appropriate than shorter intervals of time. Who cared if it took nine seconds for an IS-IS intermediate system to discover that its peers were down, and it needed to reroute traffic?

Today's networks are generally designed assuming much higher speeds and more reliable links, and today's traffic is much less tolerant of a nine-second delay in rerouting traffic. Therefore, it seems that these timers should be reconsidered, and possibly shortened. In fact, on most links over T1 speed (1.544Mb/s), there doesn't seem to be much of a reason not to set these timers to a much lower number than their default values, which are three seconds for the hello interval, and nine seconds for the hold interval.

In the Cisco IOS Software, to set the hello interval, use the isis hello-interval command in the interface submode.

router(config-if)#isis hello-interval ?
 <1-65535> Hello interval value
 minimal  Holdtime 1 second, interval depends on multiplier

As the help string states for isis hello-interval, the hold interval depends on the hello multiplier, which is set using the isis hello-multiplier command under the interface submode.

router(config-if)#isis hello-multiplier ?
 <3-1000> Hello multiplier value

The hello interval is multiplied by the hello multiplier to determine the hold interval. Therefore, if the hello interval is two seconds, and the hello multiplier is four, the hold interval will be eight seconds. The Hello and Hold intervals do not need to match on all interfaces or with the settings of the neighbors, as each Hello packet carries its own timer.

Very Fast Hellos

While running very fast hellos with low hold intervals may seem like a very good solution for producing quick convergence times on first examination, further scrutiny indicates that this approach is not necessarily practical or scalable. First, fast hellos will most likely not improve the detection of neighbors which are no longer responding on point-to-point links, since the operating system running on most intermediate systems will notify IS-IS immediately of the loss of line protocol on point-to-point links.

For broadcast networks, the problem of scalability can come into play very quickly. For instance, if you have 101 intermediate systems attached to a single broadcast network, and each of them is expecting to receive a hello from every other intermediate system on the network every second, each intermediate system must be able to receive and process a hello every ten milliseconds. The same problem exists on the transmit side—an intermediate system attached to 100 networks, each with a hello timer of 330 milliseconds, must be able to transmit a hello packet every

three milliseconds or so. Due to limitations within the timers and other architectural issues beyond the scope of this book, these numbers are unrealistic.

An alternate mechanism, which uses protocol independent signaling at layer 2, has been developed and is supported in some implementations. This new mechanism allows for the subsecond detection of link failures in shared multi-access media while avoiding the scalability concerns mentioned above.

Shortest Path First Interval

It does not make a lot of sense, on first consideration, that a routing protocol would want to hold information for some time before processing it—and, in fact, no distance vector protocol, such as the routing information protocol (RIP) or the Enhanced Interior Gateway Routing Protocol (EIGRP), ever holds routing information for any length of time before processing it. Why would IS-IS hold routing information before processing it, then? There are two reasons, one dealing with the flooding process, and the other dealing with the shortest path first algorithm.

First, let's deal with why holding onto SPF computations after receiving a link state packet is desirable for flooding. Link state protocols, generally, would prefer to flood information to all the intermediate systems in the network, and then let all of them compute their shortest paths through the network at the same time. This approach is not as reasonable as it sounds, since it would require some sort of synchronized timer running through the network, so IS-IS does the next best thing—it tries to make the SPF computation always run after any new information is flooded to the other neighbors of this intermediate system.

Why? Most implementations of routing protocols run on single processor devices; thus, the IS can only do one thing at a time. If the processor is busy running the shortest path first computation on some new data, it cannot also be flooding that new information to its neighbors. If an intermediate system always ran SPF across new information before flooding it, the propagation of information through the network would slow down dramatically; each IS would hold the information until it had finished running SPF. Thus, it is more efficient (in network terms) for an intermediate system to flood any link state information before it begins running SPF over the data. In this way, its neighbors can flood the same information and then begin running SPF in parallel.

The second reason most intermediate systems wait for some time after receiving a link state packet before running shortest path first is to reduce the overall load on the processor and memory. For instance, if a single link flaps, two intermediate systems will flood new network topology information—the two intermediate systems attached to either side of the link. So, assume an intermediate system runs SPF immediately upon receiving the changed information generated by the IS attached to one end of a link. While it is running SPF, it receives the second link state packet. It cannot stop running the SPF to take the second piece of information into account, nor can it insert the new information into the database SPF is currently being run over. Instead, it must wait until the current shortest path first computation is finished, flood the new information, and run SPF again. Intermediate systems batch information (or SPF runs) by delaying the SPF run for a period of time after receiving new link state packets.

There are actually three shortest path first interval timers in some implementations, rather than just one. In the Cisco IOS Software, the spf-interval command is used in the router submode.

router(config-router)#spf-interval ?
 <1-120> Minimum interval between consecutive SPFs in seconds

router(config-router)#spf-interval 1 ?

 <1-10000> Initial wait before first SPF in milliseconds
router(config-router)#spf-interval 1 40 ?
<1-10000> Minimum wait between first and second SPF
 in milliseconds
 <cr>

The first interval is the minimum time that should elapse between consecutive shortest path first computations. It is generally set in seconds, with the shortest interval being one second. Even though we call this time the minimum, it really represents the maximum time between SPF runs; this concept will be clearer a little later.

The second timer is the number of milliseconds between the receipt of new link state information and running SPF. While it can be set as low as one millisecond, really low settings may cause the intermediate system to run SPF before flooding new information. It's better to set it to a larger number that allows for the flooding to occur; you might want to start with something as high as 200 milliseconds and reduce it incrementally until you find the network converging slower. Generally, it should be set no lower than 40 or 50 milliseconds.

Finally, there is the minimum wait time between the first and subsequent SPF calculations, which is set in milliseconds. This timer addresses, in another way, the issue raised above— receiving new data while still running SPF. Generally, it is best to set this timer to the average (or maximum) length of a shortest path first computation in the network. In an intermediate system using Cisco IOS Software, this information can be obtained from the show isis spf-log command.

NOTE

In the Cisco IOS Software implementation of IS-IS, the timers shown for the spf-interval command (and other commands in this section) interact to create a backoff algorithm, such that the interval between any two successive operations will increase until a maximum is reached. After some time, the interval will be reset to the minimum configured. To make this concept clearer, let's use the following configuration command: spf-interval 2 40 100.

As explained above, the intermediate system will wait 40 milliseconds after an LSP is received before running SPF. If a second SPF run is needed, then the wait will be 100 ms (the third timer). If a third SPF run is needed, then the wait will be 200 ms (or two times the third timer). For subsequent SPF runs, the wait will keep increasing (twice the last wait) to 400 ms, 800 ms, 1,600 ms, and so on, until the limit set by the first option (or argument) included with the command: 2,000 ms. The wait timer will be reset to the original minimum value (40 ms, in this case) when no more triggers are present for two times the maximum value (four seconds, in this case).

It is easily observed that the effect of this algorithm is to react quickly to a change, but to slow down if the network is showing instability (changing too fast).

The partial route calculation (PRC) timers are similar in purpose, and should be set using the same sorts of parameters as the SPF timers above. The only difference might be in the setting of the maximum wait between the first and subsequent PRC runs. In this case, the timer can be set to a smaller number because the PRC involves only the calculation of the leaf routes of a particular LSP, so it takes a lot less time to execute. In the Cisco IOS Software, the prc-interval command is used in the IS-IS router configuration submode.

router(config-router)#prc-interval ?
 <1-120> Minimum PRC interval in seconds

router(config-router)#prc-interval 1 ?
 <1-10000> Initial wait for PRC in milliseconds

<cr>
router(config-router)#prc-interval 1 40 ?
<1-10000> Minimum wait between first and second PRC
 in milliseconds
<cr>

Link State Packet Generation

Most implementations of IS-IS allow you to determine how long after a network topology change occurs the intermediate system should wait before building and flooding a link state packet. This wait is to prevent a constantly flapping link (or some other network situation which would normally generate constant updates) from causing an intermediate system to send a massive number of link state packets through the network. In Cisco IOS Software, the lsp-gen-interval command is used in the IS-IS router configuration submode.

router(config-router)#lsp-gen-interval ?
 <1-120> Minimum interval in seconds

router(config-router)#lsp-gen-interval 1 ?
 <1-10000> Initial wait in milliseconds
 <cr>

router(config-router)#lsp-gen-interval 1 1 ?
<1-10000> Wait between first and second lsp generation 
in milliseconds
 <cr>

There are, as with the SPF timers above, three timers: one for the minimum interval between generated link state packets, one for the minimum time between the first event and the first link state packet being generated, and one for the minimum interval between the first link state packet flooded in a series and subsequent LSPs. You would generally set these timers so the first change will immediately cause a link state packet to be generated and flooded, while link state packets generated for an immediate event are delayed a short time. The reason for these settings is that LSPs are generated, most often, when a change in the state of a link (up to down or down to up) occurs. By setting the first and third timers to the same value and the initial wait to a low number, no penalty is given to "good" or "bad" news in the network; both are treated equally.

Link State Packet Interval

Beyond the speed at which an intermediate system will generate link state packets in response to topology change events, IS-IS also limits the number of packets per second an intermediate system can transmit. The default value is one packet every 33 milliseconds, which allows about 360K of data to be flooded in any second (given the intermediate system is flooding maximum-sized packets on 1,500 byte links). With higher speed links, this is a rather conservative amount of information flow; in fact, pacing packets at this rate can slow down network convergence.

To configure the interval between packets (packet pacing) on an intermediate system running Cisco IOS Software, use the interface submode command isis lsp-interval.

Multiple Net Statements

Given the network illustrated in Figure 4-8, what would be the result of configuring multiple net commands in the router isis submode of router B with the Cisco IOS Software?

Figure 4-8Figure 4 – 8 Multiple net statements in the Cisco IOS Software

The problem here is that intermediate systems A and C are in different domains. How will intermediate system B treat these two different domains if we enter two net statements in the router isis submode? On B, we would have:

!
router isis 
 net 49.2222.1111.1111.1112.00
 net 47.1111.1111.1111.1112.00
!

Would intermediate system C learn about the 10.1.1.0/24 network? Let's look at C's routing table to find out.

router-c#show ip route
....
   10.0.0.0/20 is subnetted, 1 subnets
i L2  10.1.0.0 [115/30] via 208.0.2.9, Serial0/3

It looks like it does. Intermediate system B shows both intermediate systems A and C as neighbors.

router-b#sho clns neighbor

System Id Interface SNPA   State Holdtime Type Protocol
router-a  Se0/2   *HDLC*  Up   29    L2  IS-IS
router-c  Se0/3   *HDLC*  Up   21    L1L2 IS-IS

In fact, the only odd thing we see is in the show isis database detail command.

router-c#show isis database detail 

IS-IS Level-1 Link State Database:
LSPID      LSP Seq Num LSP Checksum LSP Holdtime   
router-c.00-00 0x000000B2  0x210B    710 
 Area Address: 47.1111
 Hostname: router-c
 Metric: 10     IS router-b.00
router-b.00-00 0x000000B6  0xC573    824
 Area Address: 49.2222
 Area Address: 47.1111
 Hostname: router-b
 Metric: 10     IS router-c.00
....

Intermediate system C's database appears normal—it shows a single connection to intermediate system B in domain 47.1111. However, B's LSP has two domains in it, since B has two domains configured. Intermediate system B essentially merges the two databases into one database, and treats the domain border as a level 1/level 2 domain border.

This mechanism is primarily defined for use while switching from one domain address to another; it's not designed to provide any advantages or a more conventional configuration, nor for long- term use in a large-scale network. There is no advantage to dividing a network into multiple domains and using multiple net statements on the connecting intermediate system to merge them.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

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

Overview


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

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

Collection and Use of Information


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

Questions and Inquiries

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

Online Store

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

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

Service Announcements

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

Customer Service

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

Other Collection and Use of Information


Application and System Logs

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

Web Analytics

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

Cookies and Related Technologies

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

Do Not Track

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

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 InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


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

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

Supplemental Privacy Statement for California Residents


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

Sharing and Disclosure


Pearson may disclose personal information, as follows:

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

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