Home > Articles > Certification > Cisco Certification > CCNP

This chapter is from the book

Modeling WAN Networks in Integrated IS-IS

This section discusses how to configure Integrated IS-IS over a WAN.

Categories of WANs for Integrated IS-IS

WANs typically are implemented as either point-to-point or point-to-multipoint, and most support multiple connections. These WANs typically do not support broadcasting, though, and thus are classified as NBMA.

Integrated IS-IS considers three categories of WANs, as follows:

  • Point-to-point leased circuits—There are few issues for configuring Integrated IS-IS on these circuits.

  • Dialup connections—Configuring IS-IS over dialup should be avoided if possible, except to use as a backup.

  • Switched WANs—Various design options exist for NBMA networks.

These three categories are discussed in further detail in the following sections.

Point-to-Point

Point-to-point WANs are typically leased circuits between two routers. A point-to-point WAN has two devices attached, one at each end of the circuit. Usually such links will run Cisco HDLC or Point-to-Point Protocol (PPP). This corresponds exactly to the Integrated IS-IS classification of a point-to-point network.

NOTE

A point-to-point circuit still is regarded as an NBMA network, just as a back-to-back Ethernet connection is still a LAN. Both are examples of multiple-access networks that have only two devices attached.

On a point-to-point link a single IIH PDU is sent. This specifies whether the adjacency is at Level 1, Level 2 or both.

When the adjacency is established, each neighbor sends a CSNP describing the contents of its link-state database. Each router then requests any missing LSPs from the neighbor using PSNPs and acknowledges the receipt of the LSPs with PSNPs.

This activity reduces the amount of routing traffic across the point-to-point link—each router exchanges only the information missing from its link-state database rather than the entire link-state database of its neighbor router.

Dialup

Dialup networks using dial-on-demand routing (DDR) can be configured as either point-to-point or point-to-multipoint WAN implementations, as follows:

  • Legacy DDR dialup connections (that is, using dialer map commands) are NBMA (even though they might use PPP as their line protocol) because a single interface can support multiple destinations.

  • Dialer profiles and dialer virtual profiles are point-to-point connections (because one dialer profile represents one remote profile), but these can suffer from loss-of-neighbor delays similar to those for NBMA networks.

  • Dialer virtual profiles are point-to-point connections in which the interface drops immediately if the remote end disconnects. This leads to faster neighbor-loss detection and faster convergence.

NOTE

Dialup interfaces are not dealt with further in this book. As a general rule, you should avoid using IS-IS over dialup, except to provide dial-backup functionality.

For further information on dialup networks and configuring them, see the Cisco Press Book Building Cisco Remote Access Networks.

Switched WANs

IS-IS can work over an NBMA multipoint network only if the network is configured with a full mesh. Anything less than a full mesh could cause serious connectivity and routing issues. However, even if a full mesh is configured, this is no guarantee that a full mesh will exist at all times. A failure in the underlying switched WAN network or a misconfiguration on one or more routers could break the full mesh either temporarily or permanently. Therefore, you should avoid NBMA multipoint configurations for IS-IS networks. Use point-to-point subinterfaces instead.

Point-to-point subinterfaces usually should be configured with their own IP subnet (typically with a 30-bit, or /30, subnet mask). In modern IP networks using private addressing or variable-length subnetting, usually plenty of spare IP addresses can be applied to point-to-point subinterfaces.

Alternatively, because Integrated IS-IS uses CLNS packets for its route propagation, the ip unnumbered interface configuration command can be used on point-to-point interfaces. However, this works only on more recent Cisco IOS Software releases (Version 12.0 and later); earlier releases fail to establish an IS-IS adjacency because the IP subnets do not match at either end of the link.

Configuring Integrated IS-IS in an NBMA WAN

This section describes how to configure Integrated IS-IS in an NBMA environment and shows some example configurations.

Configuration Steps

To enable Integrated IS-IS over switched WAN media, do the following:

Step 1

Start the Integrated IS-IS process and assign NETs as usual.

Step 2

On each NBMA, interface do the following:

 

Design a mesh between the NBMA peers (full or partial).

 

Configure point-to-point subinterfaces for each NBMA virtual circuit (VC), and assign IP addresses.

 

Define the mapping of Level 3 protocols/addresses to the VC. If manual mappings are used (for example, x25 map or frame-relay map commands), the CLNS mapping must specify the keyword broadcast to support routing packets. However, the IP mapping does not require this (it is used only for next-hop resolution, not for routing packets).

 

Start IS-IS processing on the subinterface using the ip router isis command. This command must not be used on the main interface of the router, or that (multipoint) interface will generate a pseudonode LSP for itself.


Further tuning can be done to control the flooding of link-state information using timer and blocking commands.

NOTE

You can reduce LSP flooding in two ways:

Blocking flooding on specific interfaces—The advantage of full blocking over mesh groups is that it is easier to configure and understand, and fewer LSPs are flooded. Blocking flooding on all links permits the best scaling performance but results in a less robust network structure. Permitting flooding on all links results in poor scaling performance.

Configuring mesh groups—The advantage of mesh groups over full blocking is that mesh groups allow LSPs to be flooded over one hop to all routers on the mesh, while full blocking allows some routers to receive LSPs over multiple hops. This relatively small delay in flooding can have an impact on convergence times, but the delay is negligible compared to overall convergence times.

Running IS-IS in NBMA using Point-to-Point Subinterfaces

Figure 5-22 is an example of a router network connected over Frame Relay and using point-to-point subinterfaces. In this network, Frame Relay is modeled as a collection of subnets, with each Frame Relay permanent virtual circuit (PVC) treated as its own point-to-point network with its own subnet.

Figure 5-22Figure 5-22 Frame Relay Network Using Point-to-Point Subinterfaces

The network in Figure 5-22 is an example of a star network topology. It is important to note that the routers at the points of the star (R1, R2, and R3) are also configured with point-to-point subinterfaces, even though (unlike the central router, R4) they connect to only one VC. This is the best practice for all routing protocols (because it allows further VCs to be added without affecting the existing VC), but it is imperative to IS-IS. A main interface (for example, interface Serial 0) is a multipoint interface, even if it happens to have only one VC configured. If the single VC were configured under a main interface, IS-IS would treat this as a broadcast network and attempt to elect a DIS. Also, the adjacency would not establish because the multipoint end would send broadcast, network-style hellos, but the central router would send point-to-point hello PDUs.

Example 5-22 shows the configuration of the central router, router R4, in Figure 5-22.

Example 5-22 Configuration of Router R4 in Figure 5-22

interface Serial0/0
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
ip address 10.1.1.1 255.255.255.252
ip router isis
frame-relay interface-dlci 100
!
interface Serial0/0.2 point-to-point
ip address 10.1.1.5 255.255.255.252
ip router isis
frame-relay interface-dlci 200
!
interface Serial0/0.3 point-to-point
ip address 10.1.1.9 255.255.255.252
ip router isis
frame-relay interface-dlci 300

Example 5-22 shows the following:

  • The encapsulation type (frame-relay) is set under the main interface (Serial0/0). No IP or IS-IS configuration is included under the main interface.

  • Three subinterfaces are defined, one for each VC. Each subinterface specifies the following:

    • The IP address for that point-to-point link. There is a different subnet for each subinterface.

    • Integrated IS-IS as the routing protocol over that subinterface (this is done using the ip router isis command).

    • The VC to use for that point-to-point subinterface, using the frame-relay interface-dlci command. This is the only command needed to enable both IP and CLNS across this VC. The router automatically enables across this VC all the protocols that are enabled on the point-to-point subinterface, and it specifies broadcast for all those protocols.

Example 5-23 shows the output of the show frame-relay map EXEC command for router R4 in the example network shown in Figure 5-22.

Example 5-23 show frame-relay map Command Output from Router R4 in Figure 5-22

R4#show frame-relay map
Serial0/0.1 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast
status defined, active
Serial0/0.2 (up): point-to-point dlci, dlci 200(0xC8,0x3080), broadcast
status defined, active
Serial0/0.3 (up): point-to-point dlci, dlci 300(0xA4,0x4580), broadcast
status defined, active

As shown in Example 5-23, the show frame-relay map command displays the status of each Frame Relay VC, providing information as follows:

  • Its assigned subinterface—for example, Serial0/0.1.

  • Its type—in this case, point-to-point, meaning that it has been assigned to a point-to-point subinterface.

  • The VC identification—for example, dlci 100.

  • Whether it supports broadcast (for example, routing) packets.

  • Its status. A status of defined means it has been configured on the Frame-Relay switch, and a status of active indicates that this VC is operational. A status of inactive means that the router on the other end is not available. A status of deleted means that the DLCI was not advertised in the last LMI full status update.

Example 5-24 shows the output of the debug isis adj-packets EXEC command on router R4 in the example network shown in Figure 5-22.

Example 5-24 debug isis adj-packets Command Output from Router R4 in Figure 5-22

R4#debug isis adj-packets
ISIS-Adj: Sending serial IIH on Serial0/0.1, length 1499
ISIS-Adj: Rec serial IIH from DLCI 100 (Serial0/0.1), cir type L1L2,
cir id 00, length 1499
ISIS-Adj: rcvd state UP, old state UP, new state UP
ISIS-Adj: Action = ACCEPT
<output omitted>
ISIS-Adj: Sending serial IIH on Serial0/0.2, length 1499
ISIS-Adj: Rec serial IIH from DLCI 200 (Serial0/0.2), cir type L1L2, 
        cir id 01,
length 1499
ISIS-Adj: Sending serial IIH on Serial0/0.3, length 1499
ISIS-Adj: Rec serial IIH from DLCI 300 (Serial0/0.3), cir type L1L2, 
        cir id 02,
length 1499

Example 5-24 shows the neighborship establishment across the Serial0/0.1 subinterface, sending and receiving serial (that is, point-to-point) IIH PDUs and declaring the adjacency to be up. Ongoing hello conversations for the other subinterfaces also are shown.

Running IS-IS in NBMA Using Multipoint Interfaces

Figure 5-23 shows an alternative NBMA version of the network shown in Figure 5-22. In this case, all the Frame Relay ports are configured as multipoint interfaces, either as a multipoint subinterface (on the central router, router R4) or possibly as the main interfaces on the other routers. All interfaces share the same IP subnet.

Figure 5-23Figure 5-23 Frame Relay Network Using Multipoint Interfaces

In Figure 5-23, the network is still a star topology, as in the previous example. In a multipoint environment it is important that a full mesh be implemented; therefore, all routers in this network must have VCs interconnecting them, although these are not shown in the figure.

If this were a true hub-and-spoke environment and the spoke sites had no need to communicate with each other, this topology could work with only the indicated DLCIs rather than having a full mesh. In this case, the central router (R4) must become the DIS for the NBMA network (because it is the only router visible to all others), so a suitable IS-IS priority should be set on the Frame Relay interface. Routes would be installed in each spoke router toward the other spoke routers through their local IP addresses. However, packets to these destinations would be dropped because there are no direct VCs between the spokes.

Example 5-25 shows the configuration of the multipoint interface on the central router, R4.

Example 5-25 Configuration of Router R4 in Figure 5-23

interface Serial0/0
encapsulation frame-relay
!
interface Serial0/0.2 multipoint
ip address 10.0.0.4 255.0.0.0
ip router isis
frame-relay map clns 100 broadcast
frame-relay map clns 200 broadcast
frame-relay map clns 300 broadcast
frame-relay interface-dlci 100
frame-relay interface-dlci 200
frame-relay interface-dlci 300
!
router isis
net 00.0001.0000.0000.0004.00

As can be seen in Example 5-25, IP and CLNS maps must be configured separately in a multipoint environment:

  • The frame-relay interface-dlci command is used to enable IP across the Frame Relay PVCs. Inverse ARP resolves the remote end IP addresses. On a point-to-point subinterface, this command enables all traffic, but in a multipoint environment, this enables only IP.

  • Alternatively, the IP maps could be entered explicitly using the frame-relay map ip ip address dlci command. In this case, the broadcast keyword might not be necessary for IP because only directed IP packets will use this VC. (Remember that the Integrated IS-IS routing protocol is not sending IP packets.)

  • To enable CLNS, which must be done separately from IP in a multipoint environment, the frame-relay map clns command is used. CLNS is used for the IS-IS routing packets, so the broadcast keyword must be specified.

Examples 5-26 and 5-27 show how the same monitoring commands as used in the previous example produce a slightly different output for the multipoint environment.

Example 5-26 is the show frame-relay map command output from router R4 in Figure 5-23.

Example 5-26 show frame-relay map Command Output from Router R4 in Figure 5-23

R4#show frame-relay map

Serial0/0.4 (up): CLNS dlci 400(0x190,0x6400), static,
broadcast,
CISCO, status defined, active
Serial0/0.4 (up): ip 10.1.4.3 dlci 400(0x190,0x6400), dynamic,
broadcast,, status defined, active 

In Example 5-26, the show frame-relay map command again displays the status of each Frame Relay VC. This time however, separate entries are created for the IP and CLNS mappings (even though they use the same VC). The CLNS map shows that it is created as a static map and that broadcast was specified. The IP map is dynamic because the IP address was resolved by Inverse ARP.

Example 5-27 is the debug isis adj-packets command output from router R4 in Figure 5-23.

Example 5-27 debug isis adj-packets Command Output from Router R4 in Figure 5-23

R4#debug isis adj-packets
ISIS-Adj: Sending L2 LAN IIH on Serial0/0.2, length 1500
ISIS-Adj: Rec L2 IIH from DLCI 400 (Serial0/0.2), cir type L1L2,
cir id 0000.0000.0004.03, length 1500 
ISIS-Adj: Sending L1 LAN IIH on Serial0/0.2, length 1500
ISIS-Adj: Rec L1 IIH from DLCI 400 (Serial0/0.2), cir type L1L2,
cir id 0000.0000.0004.03, length 1500

In Example 5-27, the debug isis adj-packets command again shows the neighborship establishment. This time, the adjacency uses LAN IIH PDUs because this is a multipoint environment.

Detecting Mismatched Interfaces

When interfaces are misconfigured in an NBMA environment, the network will not function as desired.

An example of a misconfiguration is when one end of a link is specified as a point-to-point subinterface but the other end is using a point-to-multipoint interface. Issuing the show clns neighbors command on each router indicates the mismatch. An example is shown in Example 5-28. Here router R2 is specified as a point-to-point subinterface, while router R4 is using a point-to-multipoint interface configuration.

Example 5-28 show clns neighbors Command Output from Misconfigured Routers

R2#show clns neighbors

System Id Interface SNPA State Holdtime Type Protocol
0000.0000.0004 Se0/0.2 DLCI 300 Up 8 L1 IS-IS
R5 Et0/0 0050.3ef1.5960 Up 8 L2 IS-IS
R1 Se0/0.1 DLCI 100 Up 23 L1 IS-IS

R4#show clns neighbors

System Id Interface SNPA State Holdtime Type Protocol
R6 Et0/0 0010.117e.74a8 Up 26 L2 IS-IS
R3 Se0/0.3 DLCI 400 Up 28 L2 IS-IS
0000.0000.0002 Se0/0.2 DLCI 300 Init 29 L1 IS-S

0000.0000.0001 Se0/0.1 DLCI 200 Up 290 IS ES-IS

The shaded lines in Example 5-28 indicate the routers' view of each other. Router R2 (the point-to-point end) shows the adjacency as up. However, the adjacency is stuck in the init state on router R4 (the multipoint end).

The misconfiguration results from the fact that the two ends of the VC are set to different types, which is an illegal configuration. The point-to-point end sends serial IIH PDUs. The multipoint end sends LAN IIH PDUs.

The ISO standard (ISO 10589) defines a three-way handshake for initiating LAN adjacencies, as follows:

  • The adjacency starts in the down state. The IS sends out LAN IIH PDUs, identifying itself.

  • If a LAN IIH PDU is received, the adjacency is installed in the init state. This router then sends out an IIH PDU to the neighbor, including the neighbor's SNPA in the hello packet. The neighbor does the same thing with this router's SNPA.

  • The IS receives a second IIH from the neighbor router with its own SNPA identified in the packet. On receipt of this, the IS understands that the new neighbor knows of its presence and, therefore, declares the adjacency up.

According to the ISO standard, this process is omitted for a point-to-point adjacency. However, Cisco IOS Software implements the same three-way handshake by adding a Point-to-Point adjacency state TLV (TLV 240) in the serial hello PDUs. In a similar manner to the LAN adjacency, the router checks for its own SNPA in the neighbor's hello PDU before declaring the adjacency up.

The result of the mismatch configuration described in this example depends on the Cisco IOS Software release level. If using a release earlier than Release 12.1(1)T, the following happens (this is the case shown in Example 5-28):

  • Router R4 (configured for multipoint) receives the point-to-point hello from router R2 but treats it as a LAN hello and puts the adjacency in the init state. It looks for its own SNPA in the received hello PDUs (in a LAN hello PDU, this would be identified in TLV 6, IS Neighbors, but this TLV is not present in a serial hello) but never finds them. Therefore, the adjacency remains in the init state.

  • Router R2 (configured for point-to-point) receives a LAN hello PDU and treats it as a point-to-point hello. It checks the hello for a TLV 240 (point-to-point adjacency state) and fails to find one. For backward compatibility, or perhaps to allow the link to be made to a non-Cisco IS-IS device, the router assumes that this is an ISO-specified point-to-point link, ignores the Cisco three-way handshake, and allows the adjacency to establish, setting it to up.

If using a release of Cisco IOS Software since Release 12.1(1)T, the following happens:

  • Router R4 (configured for multipoint) receives the point-to-point hello, realizes that it is the wrong hello type, and installs the neighbor as an ES. Router R2 would show up in the show clns neighbors command output on router R4 with a protocol of ES-IS.

  • Router R2 (configured for point-to-point) receives the LAN hello, recognizes the mismatch, and ignores the neighbor. Router R4 would not appear at all in router R2's show clns neighbors command output. Using the debug isis adj-packets command would show the incoming LAN IIH PDU and router R2 declaring the mismatch.

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