Home > Articles > Networking

Effective BGP Policy Control

Micah Bartell and Randy Zhang explore the various aspects of BGP policy control, including Policy control techniques, Conditional advertisement, Aggregation and deaggregation, Local AS, QoS policy propagation, and BGP policy accounting.
This chapter is from the book

This chapter is from the book

Throughout this book, you have learned that BGP is first and foremost a policy tool. This results in BGP's being used to build very complex policy-based architectures. The protocol itself provides a list of attributes through which you can set policies. Additionally, Cisco IOS software further expands and enhances what is available with additional tools and knobs. This chapter examines these tools and how you can use them to build complex and effective BGP policies.

Policy Control Techniques

BGP employs many common policy control techniques. This section starts with regular expressions and then describes various forms of filter lists, route maps, and policy lists.

Regular Expression

A regular expression is a formula for matching strings that follow a certain pattern. It evaluates text data and returns an answer of true or false. In other words, either the expression correctly describes the data, or it does not.

A regular expression is foremost a tool. For example, a regular expression can help extract the needed information from a large IOS output quickly, as shown in Example 4-1.

Example 4-1 Regular Expression to Extract All Neighbors' Maximum Data Segment Sizes

R2#show ip bgp neighbors | include max data segment
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):

As a formula, a regular expression allows pattern matching in BGP AS_PATH and community policy settings. Example 4-2 shows the use of a regular expression to describe an AS_PATH pattern that matches all AS_PATHs that are originated from the neighboring AS 100.

Example 4-2 Regular Expression Matches AS_PATH Patterns

ip as-path access-list permit ^(100_)+$

Components of a Regular Expression

A regular expression consists of two types of characters:

  • Characters to be matched, or regular characters

  • Control characters or metacharacters that have special meanings

To really make good use of regular expressions, it is critical to understand the control characters and how they are used. Control characters can be grouped into three types:

  • Atom characters, or atoms—An atom is an independent control character or placeholder character that defines or expands the regular characters that are before or after it. Some atoms can be standalone, without regular characters.

  • Multiplier characters, or multipliers—A multiplier follows an atom or a regular character and is used to describe repetitions of the character immediately before it. Except for the dot (.) character, all other atom characters must be grouped with regular characters before a multiplier is appended.

  • Range characters—Range characters (brackets) specify a complete range.

Table 4-1 lists the common atom characters.

Table 4-1 Common Atom Characters and Their Usage

Atom Character

Usage

.

Matches any single character, including white space.

^

Matches the beginning character of a string.

$

Matches the ending character of a string.

_

Underscore. Matches a comma (,), left brace ({), right brace (}), the beginning of an input string, the end of an input string, or a space.

|

Pipe. It is an OR, meaning that it matches either of two strings.

\

An escape character to turn a control character that immediately follows into a regular character.


Some simple examples are listed in Table 4-2.

Table 4-2 Examples of Atoms

Regular Expression

Usage

^a.$

Matches a string that begins with character a and ends with any single character, such as ab, ax, a., a!, a0, and so on.

^100_

Matches 100, 100 200, 100 300 400, and so on.

^100$

Matches 100 only.

^100_500_

Matches 100 500, 100 500 500, and so on.

100$|400$

Matches 100, 2100, 100 400, 400, 100 100, 1039 2400, 600 400, and so on.

^\(65000\)$

Matches (65000) only.


Table 4-3 shows the common multiplier characters.

Table 4-3 Multipliers and Their Usage

Multiplier

Usage

*

Any sequence of the preceding character (zero or more occurrences).

+

One or more sequences of the preceding character (one or more occurrences).

?

Matches a preceding character with zero or one occurrences.


A multiplier can be applied to a single-character pattern or a multicharacter pattern. To apply a multiplier to a multicharacter pattern, enclose the pattern in parentheses. Some simple examples are shown in Table 4-4.

Table 4-4 Examples of Multipliers

Regular Expression

Usage

abc*d

Matches abd, abcd, abccd, abcccd, and so on.

abc+d

Matches abcd, abccd, abcccd, and so on.

abc?d

Matches abd, abcd, abcdf, and so on.

a(bc)?d

Matches ad, abcd, cabcd, and so on.

a(b.)*d

Matches ad, ab0d, ab0b0d, abxd, abxbxd, and so on.


The characters [ ] describe a range. Only one of the characters within the range is matched. You can make the matching exclusive by using the caret (^) character at the start of the range to exclude all the characters within the range. You can also specify a range by providing only the beginning and the ending characters separated by a dash (-). Some simple examples are shown in Table 4-5.

Table 4-5 Examples of Ranges

Regular Expression

Usage

[aeiouAEIOU]

Matches a, aa, Aa, eA, x2u, and so on.

[a-c1-2]$

Matches a, a1, 62, 1b, xv2, and so on.

[^act]$

Matches d, efg*, low2, actor, path, and so on, but not pact.


How to Use Regular Expressions in Cisco IOS Software

Regular expressions in IOS are only a subset of what is available from other operating systems. The use of regular expressions within IOS can be generally described in two categories:

  • Filtering the command output

  • Pattern matching to define policies

Regular expressions can be used in filtering outputs of show and more commands. The entire line is treated as one string. Table 4-6 shows the three types of filtering that can be done on an output.

Table 4-6 Regular Expressions Used to Perform Three Types of Output Filtering

Keyword

Usage

begin

Begins output lines with the first line that contains the regular expression.

include

Displays output lines that contain the regular expression.

exclude

Displays output lines that do not contain the regular expression.


To filter the output, send the output with a pipe character (|) followed by the keyword and a regular expression. For example, show run | begin router bgp shows the part of the running configuration that begins with router bgp. To interrupt the filtered output, press Ctrl-^ (press Ctrl, Shift, and 6 at the same time). Example 4-3 shows an example of filtering show ip cef output to show all the prefixes associated with the interface Ethernet0/0.

Example 4-3 Filtering show ip cef Output with a Regular Expression

R1#show ip cef | include Ethernet0/0
172.16.0.0/16    192.168.12.2     Ethernet0/0
192.168.12.0/24   attached       Ethernet0/0
192.168.12.2/32   192.168.12.2     Ethernet0/0
192.168.23.0/24   192.168.12.2     Ethernet0/0
192.168.25.0/24   192.168.12.2     Ethernet0/0
192.168.36.0/24   192.168.12.2     Ethernet0/0

NOTE

To type a question mark in a regular expression on the router, first press Ctrl-V (Escape for CLI), and then you can enter ?.

Regular expressions are used extensively in pattern matching to define BGP policies, such as AS_PATH filtering. The AS_PATH attribute lists, in reverse order, the AS numbers, separated by blank spaces, that the prefix has traversed. You can use the command show ip bgp regexp to verify the result of the configured regular expressions.

Table 4-7 shows some examples of common AS_PATH pattern matching using regular expressions.

Table 4-7 Examples of AS_PATH Pattern Matching Using Regular Expressions

AS_PATH Pattern

Usage

.*

Matches all path information—for example, no filtering.

^$

Matches updates originated from the local AS.

^200$

Matches all paths that start and end with AS 200—that is, only updates originated and sent from AS 200 (no AS prepending and no intermediary). For example, this does not match 200 200.

_200$

Matches all routes originated from AS 200, including those prepended with 200.

^200

Matches any updates received from the neighboring AS 200, such as 200, 200 100, 200 300 100, 2001, and so on.

_200_

AS_PATH contains AS 200 (the prefix passed through AS 200 but not necessarily originated by or received directly from AS 200), such as 200, 200 100, 300 200 100, and so on.

^100(_100)*(_400)*$

Matches paths from AS 100 and its immediate neighbor AS 400, such as 100, 100 100, 100 400, 100 400 400, 100 100 100 400 400, and so on.


Filter Lists for Enforcing BGP Policies

Filter lists are used extensively in BGP to define policies. This section covers prefix lists, AS path lists, and community lists.

Prefix Lists

Prefix lists are used to filter IP prefixes and can match both the prefix number and the prefix length. Compared to regular access lists, use of prefix lists provides higher performance (fewer CPU cycles).

NOTE

Prefix lists cannot be used as packet filters.

A prefix list entry follows the same general format as an IP access control list (ACL). An IP prefix list consists of a name for the list, an action for the list (permit/deny), the prefix number, and the prefix length. Here is the basic format of an IP prefix list:

ip prefix-list name [seq seq] {deny | permit} prefix/length

NOTE

A distribute list is another way to filter BGP routing updates. It uses access lists to define the rules and is mutually exclusive with the prefix list.

Any prefixes entered are automatically converted to match the length value entered. For example, entering 10.1.2.0/8 results in 10.0.0.0/8. Example 4-4 shows a simple example of matching 172.16.1.0/24. As with an access list, a deny-all entry is implied at the end of the list.

Example 4-4 Matching 172.16.1.0/24

ip prefix-list out-1 permit 172.16.1.0/24

Optionally, a sequence number can be supplied for each entry. By default, the sequence numbers are automatically generated in increments of 5. They can be suppressed with the command no ip prefix-list seq. Entries are processed sequentially based on the sequence number. The use of sequence numbers offers flexibility when modifying a portion of a prefix list.

With the basic form of the prefix list, an exact match of both prefix number and prefix length is assumed. In Example 4-4, the prefix list matches only the prefix 172.16.1.0/24. The prefixes 172.16.1.128/25 and 172.16.1.0/25, for example, are not matched.

To match a range of prefixes and lengths, additional optional keywords are needed. When a range ends at /32, the greater-than-or-equal-to (ge) can be specified. The value of ge must be greater than the length value specified by prefix/length and not greater than 32. The range is assumed to be from the ge value to 32 if only the ge attribute is specified. If the range does not end at 32, another keyword, le, must be specified. The use of le is discussed later in this section.

NOTE

A prefix consists of a prefix number and a prefix length. When a range is specified for a prefix list, the prefixes are matched for a range of prefix numbers and prefix lengths. For example, if a prefix list is 172.16.1.0/24 ge 25, the matched range of the prefix numbers is 172.16.1.0 255.255.255.0 (representing a network mask in this case). The range of the matched prefix lengths falls between 25 and 32, inclusive. Thus, prefixes such as 172.16.1.128/25 and 172.16.1.0/30 are included. As another example, if the prefix list is 172.16.1.0/24 ge 27, the matched range of the prefix numbers is still the same—that is, 172.16.1.0 255.255.255.0. The difference between the two is the range of the matched prefix lengths is smaller in the second example.

Example 4-5 shows an example of matching a portion of 172.16.0.0/16. Notice that the range is between /17 and /32, inclusive. Thus, the network 172.16.0.0/16 is excluded from the match. The legacy extended ACL version is also included for comparison.

Example 4-5 atching a Portion of 172.16.0.0 255.255.0.0

ip prefix-list range-1 permit 172.16.0.0/16 ge 17
!
access-list 100 permit ip 172.16.0.0 0.0.255.255 255.255.128.0 0.0.127.255

NOTE

Standard ACLs do not consider prefix lengths. To filter classless routing updates, you can use extended ACLs. The source address, together with wildcard bits, specifies the prefix number. The field of destination address in an extended ACL is used to represent the actual netmask, and the field of destination wildcard bits is used to denote how the netmask should be interpreted. In other words, the fields of destination address and wildcard masks indicate the range's prefix lengths. The following are some examples.

This denies the prefix 172.16.0.0/24 only (not a range):

access-list 100 deny ip host 172.16.0.0 host 255.255.0.0

NOTE

This permits 172.16.0.0 255.255.0.0 (the entire class B range):

access-list 100 permit ip 172.16.0.0 0.0.255.255 255.255.0.0 0.0.255.255

NOTE

This denies any updates with lengths of 25 bits or longer:

access-list 100 deny ip any 255.255.255.128 0.0.0.127

NOTE

Besides numbered ACLs, named extended IP ACLs can also be used for this purpose.

The range can also be specified by the less-than-or-equal-to (le) attribute, which goes from the length value specified by prefix/length to the le value, inclusive. Example 4-6 shows an example of matching the entire range of 172.16.0.0/16—that is, 172.16.0.0 255.255.0.0 using the regular mask or 172.16.0.0 0.0.255.255 using the inverted mask. If you want to specify a range that does not start from the length, you must specify another keyword, ge, as discussed next.

Example 4-6 Matching the Entire Class B Range of 172.16.0.0/16

ip prefix-list range-2 permit 172.16.0.0/16 le 32

Example 4-7 shows another example. Both the prefix list and the ACL versions are shown.

Example 4-7 Matching 172.16.0.0 255.255.224.0

ip prefix-list range-3 permit 172.16.0.0/19 le 32
!
access-list 100 permit ip 172.16.0.0 0.0.31.255 255.255.224.0 0.0.31.255

When both ge and le attributes are specified, the range goes from the ge value to the le value. A specified ge value and/or le value must satisfy the following condition:

length < ge value <= le value <= 32

The expanded prefix list format follows. Note that the ge attribute must be specified before the le value:

ip prefix-list name [seq #] deny | permit prefix/length [ge value] [le value]

Example 4-8 shows an example of using both ge and le attributes to match a portion of 172.16.1.0/24. The ACL version is also included.

Example 4-8 Matching a Portion of 172.16.1.0 255.255.255.0

ip prefix-list range-3 permit 172.16.1.0/24 ge 25 le 31
!
access-list 100 permit ip 172.16.1.0 0.0.0.255 255.255.255.128 0.0.0.126

Note that 172.16.1.0/24 is not in the range, nor are all the /32s. The matched ranges include all the following prefixes:

  • Two /25s—172.16.1.0/25, 172.16.1.128/25

  • Four /26s—172.16.1.0/26, 172.16.1.64/26, ..., 172.16.1.192/26

  • Eight /27s—172.16.1.0/27, 172.16.1.32/27, ..., 172.16.1.224/27

  • 16 /28s—172.16.1.0/28, 172.16.1.16/28, ..., 172.16.1.240/28

  • 32 /29s—172.16.1.0/29, 172.16.1.8/29, ..., 172.16.1.248/29

  • 64 /30s—172.16.1.0/30, 172.16.1.4/30, ..., 172.16.1.252/30

  • 128 /31s—172.16.1.0/31, 172.16.1.2/31, ..., 172.16.1.254/31

Table 4-8 shows more examples of prefix lists.

Table 4-8 Additional Examples of Prefix Lists

Prefix List

What It Matches

0.0.0.0/0

Default network

0.0.0.0/0 le 32

Any address that has a length between 0 and 32 bits, inclusive


AS Path Lists

AS path filters are used to filter the BGP AS_PATH attribute. The attribute pattern is defined by a regular expression string, either permitted or denied per the list's action. With regular expressions and AS path filters, you can build complex BGP policies.

The AS path list is defined by the ip as-path access-list command. The access-list-number is an integer from 1 to 500 that represents the list in the global configuration:

ip as-path access-list access-list-number {permit | deny} as-regular-expression

The filter can be applied in a BGP neighbor command using a filter list or in a route map (discussed in the later section "Route Maps"). Example 4-9 shows the use of an AS path filter to allow incoming routes from peer 192.168.1.1 that are only originated in AS 100.

Example 4-9 Path Filter to Permit Only Routes Originated from AS 100

neighbor 192.168.1.1 filter-list 1 in
!
ip as-path access-list 1 permit _100$

Community Lists

Community lists are used to identify and filter routes by their common community attributes. There are two forms of community lists: numbered and named. Within each category, there are also standard and expanded formats. A standard format allows actual community values or well-known constants, and an expanded format allows communities to be entered as a regular expression string. There is a limit of 100 for either format of the numbered lists (1 to 99 for the standard format and 100 to 199 for the expanded format), but named lists have no limit. The general formats are as follows:

  • Standard numbered list:

  • ip community-list list-number {permit | deny} community-number
  • Expanded numbered list:

  • ip community-list list-number {permit | deny} regular-expression
  • Standard named list:

  • ip community-list standard list-name {permit | deny} community-number
  • Expanded named list:

  • ip community-list expanded list-name {permit | deny} regular-expression

By default, the community-number value is a 32-bit number between 1 and 4294967295. If you enter it in the aa:nn format (the new format), the resulting format is converted to a 32-bit number. If you enable the new format globally using ip bgp-community new-format, the new format is displayed. This change is immediate. Note that the format you choose is important, because the filtering using a regular expression in an expanded list can have different results for different formats.

NOTE

The new community format splits the 32-bit number into two 16-bit numbers, aa:nn. Each number is expressed in decimal format. Typically, aa is used to represent an AS number, and nn is an arbitrary 16-bit number to denote a routing or administrative policy. Methods to design a coherent community-based policy are discussed in more detail in Chapter 9, "Service Provider Architecture."

One or more community numbers (separated by a space) can be entered per entry, or multiple entries can be entered per list number or name. When multiple communities are entered into the same entry, a match is found only when all communities match the condition—that is, an AND comparison. When multiple entries are entered for the same list number or name, a match is found when any entry matches—that is, an OR comparison. Example 4-10 shows two forms of community lists.

Example 4-10 Two Ways of Entering Community Lists

ip community-list 1 permit 100:1 100:2
ip community-list 2 permit 100:1
ip community-list 2 permit 100:2

With list 1, a match is found only when both community values of 100:1 and 100:2 are attached to a prefix. For list 2, a match is found if a prefix has a community with either 100:1 or 100:2 or both. Note that the rules stated here apply only to matching community values. They do not indicate whether a community is permitted or denied. For example, if the community list 2 in Example 4-10 is changed to deny 100:1 and 100:2 and to permit all other community values, a prefix with a community of 100:1 and 100:2 results in a match, and the prefix is denied.

NOTE

To announce community settings to a peer, you must configure the command neighbor send-community for that peer. The result of this command is to send the peer with the communities permitted by the local outbound policies of the best paths.

Besides private communities, there are four well-known communities, as discussed in Chapter 2, "Understanding BGP Building Blocks"—internet, no-export, local-as, and no-advertise.

Community values for a prefix can be set or reset in two ways:

  • Use a set clause within a route map to set a community value, to add a community value (additive), or to remove all community values:

  • set community {community-value [additive]} | none
  • Use a set clause within a route map to selectively remove some community values:

  • set comm-list community-list-number delete

This route map set command removes communities from the community attribute of an inbound or outbound update. Each community that matches the given community list is removed from the community attribute. When used with this command, each entry of a standard community list should list only one community.

NOTE

When both the set community and set comm-list delete commands are configured in the same instance of a route map, the delete operation is performed before the set operation.

Route Maps

A route map is a flexible and powerful way to set BGP policies. It can set and reset both prefixes and BGP attributes based on predefined conditions. A route map is often used to define policies toward a BGP peer or during route generation. A route map can filter updates based on prefix, AS_PATH, communities, metrics, next hop, ORIGIN, LOCAL_PREF, WEIGHT, and so on. A route map often uses policy control lists to define BGP policies.

A route map is a named group of filters consisting of one or more instances. Each instance is identified by a unique sequence number that determines the order of processing. Instances are applied sequentially. If a match is found, the rest of the route map is skipped. If the route map is finished without a match, a deny action is performed. When used in the neighbor command, only one route map per type per direction is allowed for each neighbor.

Within each instance, you can set conditions using the match clause and set actions using the set clause. Example 4-11 shows a simple route map named Set-comm, which resets communities to 200:100 when updates are originated from AS 100.

Example 4-11 Simple Route Map Example

ip as-path access-list 1 permit _100$
!
route-map Set-comm permit 10
 match as-path 1
 set community 200:100
route-map Set-comm permit 20

The second instance (with sequence number 20) is important, because without it, all other updates that don't match the first instance are not accepted. When no match clause is specified under an instance, the result is to permit any. This instance basically means that no action should be taken for prefixes that do not match the conditions in the first instance.

NOTE

The deny keyword in a route map is equivalent to a no keyword for other commands, but it does not necessarily indicate to deny something. The exact meaning depends on the route map's purpose. For example, if a route map is to suppress a route, deny is used to unsuppress that route. The same concept also applies to other forms of filtering of BGP prefixes and attributes.

There are two ways to match more than one condition. You can enter multiple conditions in the same match command or in different match commands. The processing rules are as follows:

  • An OR function is performed between multiple match parameters defined in the same match command, regardless of the type of match commands.

  • An OR function is performed when there are multiple match commands of the same type. Actually, IOS converts this form into the form discussed in the preceding bullet.

  • An AND function is performed if there are multiple match commands of different types in the same route map instance.

Example 4-12 shows how the preceding rules work. The route map foo matches either community 100:1 or 100:2. With the route map foo2, a match is found only when the prefix and both communities are matched.

Example 4-12 Processing Example When Multiple Conditions Are Set with match Commands

ip community-list 1 permit 100:1
ip community-list 2 permit 100:2
ip community-list 3 permit 100:1 100:2
!
ip prefix-list 1 seq 5 permit 13.0.0.0/8
!
route-map foo permit 10
 match community 1 2
!
route-map foo2 permit 10
 match ip address prefix-list 1
 match community 3

You can use a route map in the following BGP commands:

  • neighbor

  • bgp dampening

  • network

  • redistribute

Additionally, you can use route maps in various commands for specific purposes:

  • suppress-map

  • unsuppress-map

  • advertise-map

  • inject-map

  • exist-map

  • non-exist-map

  • table-map

Policy Lists

Complex route maps often have more than one match clause of different types. In a medium to large network, many of the same match clauses are reused repeatedly by different route maps. If the same sets of match clauses can be extracted from a route map, they can be reused by more than one route map or in different instances of the same route map. These independent match clauses are called policy lists.

A policy list is a subset of route maps that contains only match clauses. When a policy list is referenced in another route map, all the match clauses are evaluated and processed as if they were configured directly in the route map. Match clauses are configured in policy lists with permit or deny statements. The route map evaluates and processes each match clause and permits or denies routes based on the configuration in the referenced policy list.

A policy list is configured with the ip policy-list command and is referenced within another route map using the match policy-list command. Two or more policy lists can be referenced within a route map, and each entry can contain one or more policy lists. When multiple policy lists are configured in the same match policy-list command, it is an OR operation; when multiple match policy-list statements are configured, it is an AND operation. The policy lists and all other match and set options within a route map instance can coexist.

Example 4-13 shows a route map configuration using policy lists. Two policy lists are configured: as100 and as200. In as100, a match is found when both the AS path starts with AS 100 and the community is 300:105. In as200, a match is found when the AS path starts with AS 200 and the community is 300:105. With the route map foo, first a match is made to select the prefix to be 10.0.0.0/8, and then an OR operation is made for the two policy lists. The final action is to change the local preference to 105 for the updates that match.

Example 4-13 Example of Policy List Configuration

ip prefix-list 1 permit 10.0.0.0/8
ip as-path access-list 1 permit ^100_
ip as-path access-list 2 permit ^200_
ip community-list 1 permit 300:105
!
ip policy-list as100 permit
 match as-path 1
 match community 1
!
ip policy-list as200 permit
 match as-path 2
 match community 1
!
route-map foo permit 10
 match ip address prefix-list 1
 match policy-list as100 as200
 set local-preference 105
route-map foo permit 20

Filter Processing Order

When multiple filters are configured per neighbor, each filter is processed in a specific order, as shown in Figure 4-1. For inbound updates, the filter list is processed first, followed by the route map. The distribute list or prefix list is processed last. On the outbound side, the distribute list or prefix list is processed first, and then the prefix list received via Outbound Route Filtering (ORF), and then the filter list. The route map is processed last.

Figure 1Figure 4-1 Filter Processing Order

An update has to pass through all the filters. One filter does not take precedence over another. If any filter does not match, the update is not permitted. For example, if an inbound update is permitted by the filter list and the route map but is denied by the prefix list, the update is denied. The same rule applies on the outbound side.

When a policy for a neighbor is configured in the neighbor command but the policy is not defined, the following are the default behaviors:

  • For distribute lists and prefix lists, permit any.

  • For filter lists and route maps, deny any.

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