Home > Articles > Networking > Routing & Switching

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

Routing Policy Framework

All routing protocols store their routing information in routing tables. From these tables, the routing protocols calculate the best route to each destination and place these routes in a forwarding table. These routes are then used to forward routing protocol traffic toward a destination, and they can be advertised to neighbors using one or more routing protocols. In general, the routing protocols place all their routes in the routing table and advertise a limited set of routes from the routing table. The general rules for handling the routing information between the routing protocols and the routing table are known as the routing policy framework.

Instead of referring to the multiple routing tables that the JUNOS software maintains, this discussion assumes the inet.0 routing table unless explicitly stated otherwise. By default, the JUNOS software stores unicast Internet Protocol Version 4 (IPv4) routes in the inet.0 routing table.

A routing policy is a mechanism in the JUNOS software that allows you to modify the routing policy framework to suit your needs.

The routing policy framework is composed of default rules for each routing protocol that determine which routes the protocol places in the routing table and advertises from the routing table. The default rules for each routing protocol are known as default routing policies. You can create routing policies to preempt the default policies, which are always present. A routing policy is a mechanism in the JUNOS software that allows you to modify the routing policy framework to suit your needs. You can create and implement your own routing policies to control which routes a routing protocol places in the routing table, control which active routes a routing protocol advertises from the routing table, or manipulate the route characteristics as a routing protocol places it in the routing table or advertises it from the routing table.

You might want to preempt the default routing policies in the routing policy framework by creating your own routing policies in the following circumstances:

  • To not have a protocol to import all routes into the routing table. If the routing table does not learn about certain routes, they can never be used to forward packets, and they can never be redistributed into other routing protocols.

  • To not have a routing protocol export all the active routes learned by that protocol.

  • To have a routing protocol announce active routes learned from another routing protocol, which is sometimes called route redistribution.

  • To manipulate route characteristics, such as the preference value, AS path, or the community. You can manipulate the route characteristics to control which route is selected as the active route to reach a destination. In general, the active route is also advertised to a router's neighbors.

  • To change the default BGP route flap-damping parameters.

  • To perform per-packet load balancing.

  • To enable class of service (CoS).

You can manipulate the route characteristics to control which route is selected as the active route to reach a destination. The active route is placed in the forwarding table and used to forward traffic toward the route's destination. In general, the active route is also advertised to a router's neighbors. To create a routing policy, you must define the policy and apply it. You define the policy by specifying the criteria that a route must match and the actions to perform if a match occurs. You then apply the policy to a routing protocol or to the forwarding table.

To better understand the routing policy framework, it is necessary to define two terms that explain how routes move between the routing protocols and the routing table (see Figure 8.5):

  • When the Routing Engine places the routes of a routing protocol into the routing table, it is importing routes into the routing table.

  • When the Routing Engine uses active routes from the routing table to send a protocol advertisement, it is exporting routes from the routing table.

The process of moving routes between a routing protocol and the routing table always is described from the point of view of the routing table. That is, routes are imported into a routing table from a routing protocol, and they are exported from a routing table to a routing protocol. Remember this distinction when working with routing policies.

Figure 8.5Figure 8.5 Importing and Exporting Routes

When evaluating routes for export, the Routing Engine uses only active routes from the routing table. In other words, an export policy does not evaluate all routes; it evaluates only those routes that a routing protocol is allowed to advertise to a neighbor.

Table 8.2 lists the routing protocols from which the routing table can import routes and to which routing protocols the routing table can export routes. This table also lists direct and explicitly configured routes, which for the purposes of this table are considered a pseudoprotocol. An explicitly configured route is a route that you have configured. Direct routes are not explicitly configured; they are created as a result of IP addresses being configured on an interface. Explicitly configured routes include aggregate, generated, local, and static routes. An aggregate route is a route that distills groups of routes with common addresses into one route. A generated route is a route used when the routing table has no information about how to reach a particular destination. A local route is an IP address assigned to a router interface. A static route is a nonchanging route to a destination.

The policy framework software treats direct and explicitly configured routes as if they are learned through routing protocols; therefore, they can be imported into the routing table. Routes cannot be exported from the routing table to the pseudoprotocol because this protocol is not a real routing protocol. However, aggregate, direct, generated, and static routes can be exported from the routing table to routing protocols, whereas local routes cannot.

For information about the default routing policies for each routing protocol, see Table 8.4. For information about the import and export routing policies supported for each routing protocol and the level at which you can apply these policies, see Table 8.6 on page 320.

Table 8.2 Protocols the Routing Table Can Import from and Export to

Protocol

Import

Export

Border Gateway Protocol (BGP)

Yes

Yes

Distance Vector Multicast Routing Protocol (DVMRP)

Yes

Yes

Intermediate System to Intermediate System (IS-IS)

Yes

Yes

Label Distribution Protocol (LDP)

Yes

Yes

Multiprotocol Label Switching (MPLS)

Yes

No

Open Shortest Path First (OSPF)

Yes

Yes

Protocol-Independent Multicast (PIM) dense mode

Yes

Yes

PIM sparse mode

Yes

Yes

Pseudo protocols:

  • Direct routes

  • Explicitly configured routes

    • Aggregate routes

    • Generated routes

    • Local routes

    • Static routes

Yes

No

Routing Information Protocol (RIP) and Routing Information Protocol Next-Generation (RIPng)

Yes

Yes


Table 8.3 lists the routing tables affected by default and user-defined routing policies and the types of routes that each routing table stores.

Table 8.3 Routing Tables Affected by Routing Policies

Routing Table

Type of Routes Stored

inet.0

Unicast IPv4 routes

instance-name.inet.0

Unicast IPv4 routes for a particular routing instance

inet.1

Multicast IPv4 routes

inet.2

Unicast IPv4 routes for multicast reverse-path forwarding (RPF) lookup

inet.3

MPLS routes

mpls.0

MPLS routes for label-switched path (LSP) next hops

inet6.0

Unicast IPv6 routes


Table 8.4 summarizes the default routing policies for each routing protocol that imports and exports routes. The actions in the default routing policies are taken if you have not explicitly configured a routing policy.

Table 8.4 Default Routing Policies

Importing or Exporting Protocol

Default Import Policy

Default Export Policy

BGP

Import all BGP IPv4 routes learned from configured neighbors into the inet.0 routing table. Import all BGP IPv6 routes learned from configured neighbors into the inet6.0 routing table.

Export active BGP routes.

DVMRP

Import all DVMRP routes into the inet.1 routing table.

Export active DVMRP routes.

IS-IS

Import all IS-IS routes into the inet.0 and inet6.0 routing tables. (You cannot override or change this default policy.)

Export active IS-IS routes.

Export direct (interface) routes for the interfaces on which IS-IS is explicitly configured.

LDP

Import all LDP routes into the inet.3 routing table.

Export active LDP routes.

MPLS

Import all MPLS routes into the inet.3 routing table.

Export active MPLS routes.

OSPF

Import all OSPF routes into the inet.0 routing table. (You cannot override or change this default policy.)

Export active OSPF routes.

Export direct (interface) routes for the interfaces on which OSPF is explicitly configured.

PIM dense mode

Import all PIM dense mode routes into the inet.1 routing table.

Export active PIM dense mode routes.

PIM sparse mode

Import all PIM sparse mode routes into the inet.1 routing table.

Export active PIM sparse mode routes.

Pseudoprotocol:

  • Direct routes

  • Explicitly configured routes:

    • Aggregate routes

    • Generated routes

    • Static routes

Import all direct and explicitly configured routes into the inet.0 routing table.

Does not export any routes. The pseudoprotocol cannot export any routes from the routing table because it is not a routing protocol.

Routing protocols can export these or any routes from the routing table.

RIP

Import all RIP routes learned from configured neighbors into the inet.0 routing table.

Does not export any routes. To export RIP routes, you must configure an export policy for RIP.

RIPng

Import all RIPng routes learned from configured neighbors into the inet6.0 routing table.

Does not export any routes. To export RIPng routes, you must configure an export policy for RIPng.


When multiple routes for a destination exist in the routing table, the protocol selects an active route, and that route is placed in the appropriate routing table. For equal-cost routes, the JUNOS software places multiple next hops in the appropriate routing table. When a protocol is exporting routes from the routing table, it exports active routes only (applies to actions specified by both default and user-defined export policies).

You cannot change the default import policy for the link-state protocols IS-IS and OSPF. As link-state protocols, IS-IS and OSPF exchange routes between systems within an autonomous system (AS). All routers and systems within an AS must share the same link-state database, which includes routes to reachable prefixes and the metrics associated with the prefixes. If an import policy were configured and applied to IS-IS or OSPF, some routes might not be learned or advertised, or the metrics for learned routes might be altered, which would make a consistent link-state database impossible.

The following default actions are taken if one of the following situations arises during policy evaluation:

  • If a policy does not specify a match condition, all routes evaluated against the policy match.

  • If a match occurs but the policy does not specify an accept, reject, next term, or next policy action, one of the following occurs:

    • The next term, if present, is evaluated.

    • If no other terms are present, the next policy is evaluated.

    • If no other policies are present, the action specified by the default policy is taken.

  • If a match does not occur with a term in a policy and subsequent terms in the same policy exist, the next term is evaluated.

  • If a match does not occur with any terms in a policy and subsequent policies exist, the next policy is evaluated.

  • If a match does not occur by the end of a policy or all policies, the accept or reject action specified by the default policy is taken.

When you configure routing policy, you use import routing policies to control which routes routing protocols place in the routing table and export routing policies to control which routes a routing protocol advertises from the routing table to its neighbors (see Figure 8.6).

Figure 8.6Figure 8.6 Import and Export Routing Policies

To define a routing policy, you create a term that specifies match conditions, which are criteria that a route must match, and actions, which is what to do if a route matches the conditions. The actions can specify whether to accept or reject the route, control how a series of policies is evaluated, and manipulate the characteristics associated with a route. You define match conditions and actions within a term. After defining a routing policy, you then apply it to a routing protocol or to the forwarding table.

Routing policy match conditions fall into two categories: standard and extended (see Table 8.5). In general, the standard match conditions include criteria that are defined within a routing policy and are less complex than the extended match conditions, and the extended match conditions include criteria that are defined separately from the routing policy (AS path regular expressions, communities, and prefix lists) and are more complex than standard match conditions. Some match conditions, including communities, prefix lists, and AS path regular expressions, are defined separately from the routing policy and are given names. You then reference the name of the match condition in the definition of the routing policy itself. Named match conditions allow you to reuse match conditions in other routing policies and read configurations that include complex match conditions with more ease.

Table 8.5 Match Conditions

Match Condition

Category

When to Use

Notes

AS path regular expression—Combination of AS numbers and regular expression operators

Extended

(BGP only) Match a route based on its AS path.

Community—Group of destinations that share a common property (community information is included as a path attribute in BGP update messages)

Extended

Match a group of destinations that share a common property. Use a routing policy to define a community that specifies a group of destinations you want to match and one or more actions that you want taken on this community.

Actions can be performed on the entire group.

You can create multiple communities associated with one particular destination.

You can create match conditions using regular expressions.

Prefix list—Named list of IP addresses

Extended

Match a route based on prefix information. You can specify an exact match of a particular route only.

You can specify a common action only for all prefixes in the list.

Route list—List of destination prefixes

Extended

Match a route based on prefix information. You can specify an exact match of a particular route or a less precise match.

You can specify an action for each prefix in the route list or a common action for all prefixes in the route list.

Standard—Collection of criteria that can match a route

Standard

Match a route based on one of the following criteria: area ID, color, external route, family, instance (routing), interface name, level number, local preference, metric, neighbor address, next-hop address, origin, preference, protocol, routing table name, or tag.

For the protocol criterion, you can specify one of the following: BGP, direct, DVMRP, IS-IS, local, MPLS, OSPF, PIM dense mode, PIM sparse mode, RIP, RIPng, static, and aggregate.

Subroutine—Routing policy that is called repeatedly from another routing policy.

Extended

Use an effective routing policy in other routing policies.

The subroutine action influences but does not necessarily determine the final action.


An action is what the policy framework software performs if a route matches all criteria defined in a match condition. You can configure one or more actions in a term. The policy framework software supports flow control actions, which affect whether to accept or reject the route or whether to evaluate the next term or routing policy, actions that manipulate route characteristics, and trace action, which logs route matches.

A term is a named structure in which match conditions and actions are defined. You can define one or more terms. In general, the policy framework software compares a route against the match conditions in the first term in the first routing policy, then goes on to the next term and the next policy if present, and so on until an explicitly configured or default action of accept or reject is taken. Therefore, the order in which you arrange terms in a policy is relevant. The order of match conditions in a term is not relevant because a route must match all match conditions in a term for an action to be taken.

After defining a routing policy, you can apply it to routing protocols, to a pseudoprotocol (explicitly created routes, which include aggregate and generated routes), and to the forwarding table. Table 8.6 summarizes the import and export policy support for each routing protocol. You can apply an import policy to aggregate and generated routes, but you cannot apply an export policy to these routes. These routes cannot be exported from the routing table to the pseudoprotocol, because this protocol is not a real routing protocol. However, aggregate and generated routes can be exported from the routing table to routing protocols.

Table 8.6 Apply Routing Policies to Protocols

Protocol

Import Policy

Export Policy

Supported Levels

BGP

Yes

Yes

Import: global, group, peer Export: global, group, peer

DVMRP

Yes

Yes

Global

IS-IS

No

Yes

Export: global

LDP

Yes

Yes

Global

MPLS

No

No

OSPF

No

Yes

Export: global

PIM dense mode

Yes

Yes

Global

PIM sparse mode

Yes

Yes

Global

Pseudoprotocol—Explicitly configured routes, including aggregate routes and generated routes

Yes

No

Import: global

RIP and RIPng

Yes

Yes

Import: global, neighbor Export: group


For BGP only, you can also apply import and export policies at group and peer levels as well as at the global level. A peer import or export policy overrides a group import or export policy. A group import or export policy overrides a global import or export policy.

For RIP and RIPng only, you can apply import policies at the global and neighbor levels and export policies at a group level.

You can apply export policies to routes being exported from the routing table into the forwarding table for per-packet load balancing and CoS.

Figure 8.7 shows how a single routing policy is evaluated. This routing policy consists of multiple terms. Each term consists of match conditions and actions to apply to matching routes. Each route is evaluated against the policy as follows:

Figure 8.7Figure 8.7 Routing Policy Evaluation


  1. The route is evaluated against the first term. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues as described in Step 2. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.

  2. The route is evaluated against the second term. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues in a similar manner against the last term. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.

  3. If the route matches no terms in the routing policy or the next policy action is specified, the accept or reject action specified by the default policy is taken.

Figure 8.8 shows how a chain of routing policies is evaluated. These routing policies consist of multiple terms. Each term consists of match conditions and actions to apply to matching routes. Each route is evaluated against the policies as follows:

  1. The route is evaluated against the first term in the first routing policy. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues as described in Step 2. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.

  2. The route is evaluated against the second term in the first routing policy. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues in a similar manner against the last term in the first routing policy. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.

  3. If the route does not match a term or matches a term with a next policy action in the first routing policy, it is evaluated against the first term in the second routing policy.

  4. The evaluation continues until the route matches a term with an accept or reject action defined or until there are no more routing policies to evaluate. If there are no more routing policies, the accept or reject action specified by the default policy is taken.

Figure 8.8Figure 8.8 Routing Policy Chain Evaluation

Figure 8.9 on page 325 shows how a subroutine is evaluated. The subroutine is included in the first term of the first routing policy in a chain. Each route is evaluated against the subroutine as follows:

  1. The route is evaluated against the first term in the first routing policy. If the route does not match all match conditions specified before the subroutine, the subroutine is skipped and the next term in the routing policy is evaluated (see Step 2). If the route matches all match conditions specified before the subroutine, the route is evaluated against the subroutine. If the route matches the match conditions in any of the subroutine terms, two levels of evaluation occur in the following order:

    1. The actions in the subroutine term are evaluated. If one of the actions is accept, evaluation of the subroutine ends and a Boolean value of TRUE is returned to the calling policy. If one of the actions is reject, evaluation of the subroutine ends and FALSE is returned to the calling policy. If one of the actions is meant to manipulate route characteristics, the characteristic is changed regardless of whether accept, reject, or neither action is specified.

      If the subroutine does not specify the accept or reject actions, it uses the accept or reject action specified by the default policy and the values of TRUE or FALSE are returned to the calling policy as described above.

    2. The calling policy's subroutine match condition is evaluated. During this part of the evaluation, TRUE equals a match and FALSE equals no match. If the subroutine returned TRUE to the calling policy, then the evaluation of the calling policy continues. If the subroutine returned FALSE to the calling policy, then the evaluation of the current term ends and the next term is evaluated.

    3. The route is evaluated against the second term in the first routing policy. If a term defines multiple match conditions, including a subroutine, and a route does not match a condition specified before the subroutine, the evaluation of the term ends and the subroutine is not called and evaluated. In this situation, an action specified in the subroutine that manipulates a route's char-acteristics is not implemented. If you specify a policy chain as a subroutine, the entire chain acts as a single subroutine. That is, as with other chains, the action specified by the default policy is taken only when the entire chain does not accept or reject a route.

Figure 8.9Figure 8.9 Routing Policy Subroutine Evaluation

  • + 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