DHCP Emulation

8/22/2019 DHCP Emulation

1/24

DHCP Emulation Testing

with Agilent N2XApplication Note

Agilent N2X


2/24

2

DHCP Emulation Testing with N2X

IntroductionAgilent Technologies N2X platform provides the most scalable and easy-to-use

solution for assessing the performance of broadband access devices such as

BRASs, DSLAMs, and EARs (Ethernet Aggregation Routers). These devices can

be tested for session scalability, session set-up rate, and traffic forwarding/QoS performance. By emulating DHCP, PPPoX and L2TP client sessions and

running traffic over those sessions, testing these edge aggregation devices

is substantially simplified by eliminating the need to configure thousands of

individual clients.

How to Read this Application Note

This document describes the procedures for testing with the DHCP Emulation

feature in three specific scenarios (back-to-back, client to L2 switch to server,

and client to relay agent to server), and describes how to configure traffic

meshes in each. Only DHCP client pools and server pools will be discussed as

the DHCP client relay agent setup is essentially identical to that of client pools

except that the relay agent and server IP addresses must also be configured.

To configure a specific scenario, skip to the Testing Specific DHCP Scenarios

section. That section will refer back to the Common Steps Device Setup and

Common Steps Starting the Emulation sections that were skipped, as many

steps are common among the scenarios.

In addition to the steps listed in this document, the N2X Online Help section for

DHCP emulation also provides much useful information related to this feature.


3/24

3


Technology BackgroundDynamic Host Configuration Protocol (DHCP)

The Dynamic Host Configuration Protocol (DHCP) version 4 and version 6 are

used to dynamically assign IPv4 and IPv6 addresses, respectively, and otherconfiguration information to clients on a TCP/IP network.

There are two primary topologies that are seen between DHCP clients and

DHCP servers. The Server and Client can be directly connected or they can be

separated by a DHCP relay agent (see figure 1).

Figure 1: DHCP Relay Agent Topology

A DHCP relay agent is any host that forwards DHCP packets between DHCP

clients and servers. A relay agent enables DHCP clients and servers to be on

different networks. For example, a service providers DHCP Server is likely on adifferent network than that of the client.

Forwarding through a DHCP relay agent differs from forwarding via a typical

router. A router generally forwards packets transparently, by switching them

between networks without special processing. Relay implies that messages are

processed to a greater extent, which may include changes to the original packet.

For example, a relay agent can examine a DHCP clients broadcast message, add

relay agent information to it, and then relay the packet to a DHCP server unicast

address.

In addition to relay agents, one might also find L2 switches between the clients

and server. This scenario will be also discussed later in this document.


4/24

4


DHCPv4 Messages

DHCPv4 servers and clients communicate with one another through a series of

DHCP messages. There are nine different DHCPv4 messages as seen in Table 1.

DHCPv4 Message Name Originated By Unicast or Broadcast

Discover Client Broadcast

Offer Server Broadcast

Request Client Broadcast(Unicast if used to renew aprevious lease)

Ack Server Broadcast

Nak Server Broadcast

Decline Client Broadcast

Release Client Unicast

Inform Client Unicast

ForceRenew Server Unicast

Table 1: DHCPv4 Messages

When a DHCP client wishes to acquire an IPv4 address, it will send out a DHCP

Discover message (broadcast). The server then responds with an Offer message

that includes an unleased IP address, lease time and any other additional

information that the client may have requested. Since multiple Servers could

have received the clients original Discover message, multiple Offer messages

could be sent to the client. Thus the client sends out a Request message

specifying the IP address details of a particular server, which also implicitly

declines the Offers from other servers. Finally, the DHCP server sends an Ack

message to confirm that the IP address now belongs to the client, or sends a

Nak if the address is no longer available. See Figure 2 for an illustration showing

the order in which DHCP messages are sent.

Figure 2: DHCPv4 client requesting an address


5/24

5


Once a client has been assigned an IP address, the client and server should learn

the MAC addresses of their next hop neighbors (using ARP). For full details

regarding the other DHCP messages, please see the DHCP messages section

in the N2X Online Help.

Finally, note that when a DHCP relay agent forwards messages to and from the

client and server, the message sent between the relay agent and the serverare all unicast, while the messages sent between the client and relay agent are

broadcast or unicast as listed in Table 1, above.

DHCPv6 Messages

DHCPv6 servers and clients communicate using a series of messages very

similar to DHCPv4. There are fourteen different DHCPv6 messages as seen in

Table 2.

DHCPv6 Message Name Originated By Unicast or Multicast

Solicit Client Multicast

Advertise Server Unicast

Request Client Multicast

Reply Server Unicast

Confirm Client Multicast

Renew Client Multicast

Rebind Client Multicast

Release Client Multicast

Decline Client Multicast

Reconfigure Server Unicast

Information-Request Client MulticastRelay-Forward Relay Agent Multicast

Relay-Reply Server Unicast

Table 2: DHCPv6 Messages

To request and assign IPv6 addresses, the sequence of DHCPv6 messages is

essentially the same as with DHCPv4. The primary difference is that the version

4 messages Discover, Offer and Ack, have been renamed to Solicit, Advertise

and Reply, respectively. See Figure 3, below, for an illustration of the message

sequence.

There are two primary DHCPv6 options that N2X supports. One is the Rapid

Commit option, which allows servers to assign IPv6 addresses to clients witha single message in each direction. Figure 4, below, shows the abbreviated

message sequence. The other option is Prefix Delegation. This allows the

delegating router (server) to assign a single pool of addresses to a requesting

router, and then that requesting router can assign specific IPv6 addresses, from

the given pool, to the clients behind it.


6/24

6


Figure 3: DHCPv6 client requesting an address

Figure 4: Rapid Commit Message Sequence

For more information regarding DHCPv6 messages, please refer to the DHCPv6

Messages help document in the Technology Reference section of the N2X

Online help.


7/24

7


The Emulation WindowThe emulation window uses the Generic Protocol Framework (GPF), a powerful

environment for rapidly delivering new features and productivity enhancements

to the N2X. For example using the GPF, N2X routing will become much more

dynamic and can be started and stopped on the fly.

Emulation Window vs. Link Layer Setup

With the introduction of the Emulation Window, there are some key differences

between the Link Layer Setup dialogue and the Port Properties SUT Interfaces

dialogue, found in the Emulation window, that are worth noting.

To access the SUT Interfaces tab from the Port Properties window, click

the Emulation button on the left, in the Setup menu.

Double-click the port that you wish to configure (alternatively, select the

port with a left click and click the properties icon).

A Port Properties dialogue will appear and has two tabs: SUT Interfaces and

MAC Table. The MAC Table is a new feature that does not exist in the Link Layer

Setup and contains all of the MAC addresses that the port has associated with

IP addresses. If no MAC address has been associated to an IP address, the MAC

address will appear as 00:00:00:00:00:00.

Some things to note:

The MAC Table also includes the MAC addresses that are learned via the

Link Layer Setup.

When ARP is sent from the Port Properties window, ARP messages will be

sent to all addresses including those configured in the Link Layer Setup

Sending ARP from the Link Layer Setup will not send messages to the

addresses configured in the Emulation window (from DHCP devices or SUTInterfaces).

IMPORTANT: Disabling ARP (or NDP) in the Link Layer will also disable ARP

in the Port Properties window. In the SUT Interfaces tab, users will add SUT

IP addresses as is done in the Link Layer Setup. Doing this allows the N2X to

resolve ARP and learn the MAC address of its next hop. The specific procedures

regarding SUT Interfaces will be discussed in later sections.

1.

2.


8/24

8


Device SetupFor all DHCP test scenarios, you will need to create DHCP device pools (of

clients, servers, etc.) and then configure each pool.

Adding and Configuring DHCP Devices

To add a DHCP device, double-click the area below the desired port (101/1).

On the new window that appears, select DHCP Client from the DHCP

folder.

Ensure that A group of emulations is selected by default and fill in the

Count field with the value 1000. This will create one pool/group of 1000

DHCP Clients.

Click OK.

Note: Selecting Individual emulations would create 1000 pools/

groups of one DHCP Client per pool.

1.

2.

3.

4.


9/24

9


5. As the option to Edit properties after emulations added was selected

(see New Emulations window, above), a new DHCP Client Properties

dialogue will appear.

Note the options here to configure the Client MAC addresses and

VLANs.

From the DHCP Client Tab, note the various options that can be

configured for the Client pool.

Click OK at the bottom of the Client Properties dialogue (not shown) toclose the window.

Now a DHCP Server will be created. As in step 1, double-click the

area below port 101/2 (not shown). The New Emulations window will

appear.

Select DHCP Server.

Verify the defaults that a single Pool with a single Server is to be

created.

Click OK.

5.

6.

7.

8.

9.

10.

11.


10/24

10


The DHCP Server Properties window will appear. Verify that the Tester

Address of the Server is 100.2.2.2. If not, configure it to have that

address.

Options can be configured from the DHCP Server tab. These options

include the range of IP addresses that the Server will assign, whether to

ignore or NAK certain clients, and also the configureable DHCP options.

Click OK to close the window and to save any configuration changes

that were made.

Finally, verify that the DHCP Client and Server pools were created and

appear in the Emulation Window.

Note: In the above steps, the Device Properties windows appeared

automatically after creating each device pool. To edit the devices

later, simply double-click on the device of interest.

12.

13.

14.

15.


11/24

11


Starting the Emulation

To Enable the DHCP Server, click the checkbox next to the device. Now

the Server is fully enabled and will respond to DHCP Discover and

Request messages.

Enable the DHCP Clients by clicking the checkbox next to the pool.

Right-click the DHCP Client pool and click Start Emulation. At this

point, DHCP Discover messages are sent out by the clients as discussedin the Technology Background section.

As the clients send and receive various DHCP messages, their

intermediate states can be seen in the Emulation window.

1.

2.

3.

4.


12/24

12


Testing Specific DHCPScenariosIn this section you will find instructions to configure three specific scenarios:

back-to-back, client to L2 switch to server, and client to relay agent to server.

Scenario 1 or 2 Back-to-Back or with a L2 Switch

Scenario 1: Back-to-Back

Scenario 2: Client to L2 Switch to Server

Depending on which scenario you wish to configure, connect your N2X ports as

shown in the figures above, and complete the following steps.

Complete the steps presented in section Common Steps Device

Setup.

Complete the steps presented in section Common Steps Starting the

Emulation.

At this point the DHCP Clients should all be in the Bound state. New

to Release 6.7 is the auto-ARP/auto-NDP function which allows N2X

to resolve ARP/NDP before sending out unicast DHCP messages.

Therefore, a SUT Interface does not need to be configured in these

scenarios unless traffic is created. Please refer to the next section,

Traffic Setup with the Device Mesh, for full details.

1.

2.

3.


13/24

13


Scenario 3: Client to relay agent to Server

Scenario 3: Client to Relay Agent to Server

In this scenario, the N2X ports are connected to two ports of a relay agent (a

properly configured Layer 3 switch that should know the IP address of the DHCP

Server). Configure the two ports on the relay agent with IP addresses 100.3.0.1

/16 and 100.2.2.1 /16, as shown above. Then complete the following steps.

Complete the steps presented in section Device Setup, on page 9;with one exception:

Complete the steps presented in section Common Steps Starting theEmulation.

At this point the DHCP Clients should all be in the Bound state. New

to Release 6.7 is the auto-ARP/auto-NDP function which allows N2X

to resolve ARP/NDP before sending out unicast DHCP messages.

Therefore, a SUT Interface does not need to be configured in these

scenarios unless traffic is created. Please refer to the next section,

Traffic Setup with the Device Mesh, for full details.

1.

2.

3.

Modified step 13:

Configure the DHCP Servers IP Address Pool to start with address 100.3.0.10,

and the default Count of 65536. (The Count should actually be configured to

65525, but this will not be an issue with only 1000 Clients.)

This is necessary so that the IP addresses that the Server assigns to the

simulated clients will fall within the same network as the interface of the Relay

Agent (100.3.0.1 /16).


14/24

14


Traffic Setup with theDevice MeshIn general, when configuring regular traffic streams or IP meshes, MAC and SUT

addresses from the Link Layer Setup are used. When Device meshes are beingcreated that involve an emulation device and a L3 SUT, SUT Interfaces must be

configured in the Port Properties diaglogue. This is needed for the N2X to know

which IP address in its MAC Table is the interface address of the SUT.

For scenario-specific details, please see the following subsections.

Scenario 1 and 2: Back to Back or L2 Switch

Device to Device

From the Traffic view, click the mesh drop down menu and click Device

Mesh.

A New Device Traffic Mesh dialogue will appear. In the General tab(opened by default), select Layer 2 as the Type of device under test, and

configure the other settings (Distribution and Orientation) as desired.

Select the Sources and Destinations tab.

Set the Available Sources Type and the Available Destinations Type both

to Device.

1.

2.

3.

4.


15/24

15


Click to select the DHCP Server.

Click Add Source.

Click to select the DHCP Client pool.

Click Add Destination.

Click OK

NOTE: If creating bidirectional traffic then the order of Source and

Destination will not matter. Order will, of course, matter if only

configuring unidirectional traffic. To create unidirectional traffic from

DHCP Clients to DHCP Server, add the Clients as the Source and the

Server as the Destination (reverse of image above).

At this point the Traffic Engine may be started and Tx/Rx statistics

should appear in the Realtime statistics window. Furthermore, if you

double click a mesh traffic stream and view the Stream Properties, you

will see that a list of Client IP addresses has been inserted into the

appropriate Source or Destination address field.

5.

6.

7.

8.

9.

10.


16/24

16


Port to Device

Complete steps 1 and 2 from the previous subsection, Device to Device.

Select the Sources and Destinations tab.

Set the Available Sources Type to Port.

Set the Available Destinations Type to Device.Click to select Port 101/2.

Click Add Source.

Click to select the DHCP Client pool.

Click Add Destination.

Click OK.

NOTE: If creating bidirectional traffic then the order of Source and

Destination will not matter. Order will, of course, matter if only

configuring unidirectional traffic. To create unidirectional traffic from

a DHCP device to a port, change the Available Sources/Destinations

Types to Device and Port, respectively. Then add the DHCP Device as

the Source and the Port as the Destination (reverse of image above).

Now the traffic mesh has been created and the Traffic Engine may be started.

See step 10 in the previous subsection, Device to Device, for more details.

1.

2.

3.

4.5.

6.

7.

8.

9.


17/24

17


Scenario 3: Relay Agent

As this scenario involves configuring Layer 3 Device Meshes, SUT Interfaces

must be configured for each port involved in order for N2X to know which MAC

addresses to insert into the traffic streams.

Double-click Port 101/1 in the Emulation window.

In the Port Properties dialogue that opens, the SUT Interfaces tab

should be selected by default. Click Add.

Enter 100.3.0.1 as the IPv4 SUT Address.

Click Apply.

Select the MAC Table tab.

Click Send All ARP.

Click Refresh.

Verify that the IPv4 Address, 100.3.0.1, has a MAC Address resolved.

Click OK.

Now repeat steps 1 9 except for port 101/2 instead of port 101/1.

Therefore, in step 3, enter 100.2.2.1 as the IPv4 SUT Address.

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.


18/24

18


Device to Device

From the Traffic view, click the mesh drop down menu and click Device

Mesh.

A New Device Traffic Mesh dialogue will appear. In the General tab

(opened by default), select Layer 3 as the Type of device under test, and

configure the other settings (Distribution and Orientation) as desired.

Now refer back to section Scenario 1 and 2: Back to Back or L2 Switch,

subsection Device to Device. Complete steps 3 10.

1.

2.

3.


19/24

19


Port to Device

Complete steps 1 and 2 from the previous section Scenario 3: Relay

Agent, subsection Device to Device.

Now refer back to section Scenario 1 and 2: Back to Back or L2 Switch,

subsection Port to Device. Complete steps 2 10.

IMPORTANT: If the source port does not have an emulated device on

it, you must still configure the Ports SUT Interface as the interface IP

address that the port is connected to.

Also, when the ARP message is sent out, it will use the address

configured in the Link Layer Setup. Therefore, you may have to

configure the IP address in the Link Layer Setup to be on the same

network as the SUT Interface.

For example, if Port 101/2 did not have a DHCP Server on it and you

wanted to create a traffic mesh from Port 101/2 to the DHCP Clients

on Port 101/1 (as described in this section), then you would have to

re-configure the Link Layer IP Address of Port 101/2 to something from

the 100.2.0.0 /16 subnet. If you did not, then the ARP message would

be sent from the default address, 192.2.1.2 /24, and the relay agent

(100.2.2.1 /16) would not respond to the ARP message coming from a

different network.

1.

2.


20/24

20


Viewing DHCP EmulationStatisticsThe DHCP device statistics of all DHCP devices (Client, Server and Relay Agent)

are very similar. Although the steps below are shown only for a DHCP Clientpool, the steps and descriptions are the same for DHCP Servers and DHCP Client

Relay Agents.

Select the DHCP Client pool.

2. Click the Results button.

The Results window contains three tabs with various data related to the

emulation. Measurements is the primary tab that shows all of the packet,

session state, and time delay statistics.

1.

2.


21/24

21


DHCPv6 EmulationScenario 1 and 2: Back to Back or L2 Switch

These two scenarios are identical to the DHCPv4 setup except that DHCPv6devices should be used instead of DHCP(v4) devices. Otherwise, please refer to

section Testing Specific DHCP Scenarios, subsection Scenario 1 and 2: Back to

Back or L2 Switch for the related DHCPv4 setup.

Scenario 3: Relay Agent for DHCPv6 will not be discussed in this document.

DHCPv6 Client Options

This section introduces some of the new DHCPv6 options and describes what

they do.

Enabling Scalable Mode allows more clients to be created per N2X

module, but in this mode N2X Clients will not be able to respond to

certain unicast messages, such as Reconfigure messages from theServer.

Enabling Address Assignment causes the client to request and accept

an IPv6 address.

Enabling the Rapid Commit option inserts that option into the

N2X Clients Solicit message. See section Technology Background,

subsection DHCPv6 Messages for details.

Enabling Prefix Delegation inserts the corresponding option into the N2X

Clients Solicit message. See section Technology Background, subsection

DHCPv6 Messages for details.

IMPORTANT: When using the prefix delegation option, you will not be able

to create a device mesh. The reason for this is that the clients are not boundwith a specific IPv6 address (as you will see in the Tester IPv6 field) and

therefore no addresses exist to be inserted into the device mesh

1.

2.

3.


22/24

22


Troubleshooting

I see the error message IPv4 address is not activated for port xxx/n

(port n.)

or No SUT Gateway specified for port xxx/n (port n) on which device

pool x resides. The SUT list in empty. when I try to create a DHCPv4

device mesh.

These are the error messages that will appear when ARP has not been

resolved on a Source Port (when creating a Device Mesh for L3 traffic).

The first message will appear when creating a Port to Device mesh and

ARP has not been resolved for the source port. The second is seen

when creating a Device to Device mesh and ARP has not be resolved

for the source device. Please see section Traffic Setup with the Device

Mesh, subsection Scenario 3: Relay Agent for full details to create

Device Meshes.

I see the error message Duplicate IP address detected = :: unable to

add MAC address for device pool n when I try to create a DHCPv6Device Mesh.

You will see this message if you are trying to create a Device Mesh and

have used the Prefix Delegation option when assigning addresses to

N2X DHCPv6 Clients. If Prefix Delegation is used, you will not be able to

create a device mesh as the clients do not have specific IPv6 addresses

assigned to them. Therefore, the addresses are unavailable to create a

traffic mesh.

I have created a DHCP device but cannot resolve ARP with its neighbor

via the SUT Interface.

or I have created a DHCP device but find that the N2X is only sending

out ARP packets using the Tester address from the Link Layer setup

(and not from DHCP device) when trying to resolve ARP via the Port

Properties window.

1.

2.

3.


23/24

23


You must ensure that the DHCP devices have been enabled when

trying to resolve ARP. If they are disabled, their IP address are not

available for use in ARP resolution. Also note that when you click the

Action button to Send All ARP, you are sending ARP messages for

all addresses configured in the Link Layer Setup and for all enabled

devices. If N2X DHCP Clients have not yet been assigned IP addresses,

ARP cannot be sent on behalf of those clients until they have addresses.

The N2X is sending ARP messages to its neighbor via the Port

Properties window, but is not receiving any acknowledgements in

response.

The Address Resolution Protocol (ARP) was designed for LANs and

as a result, ports will only respond to ARP messages that come from

others that are on the same network. Therefore you should ensure that

the device/port that you are sending ARP from is on the same network

as its neighbor. For example, if through a relay agent you assign the

addresses from network 192.10.x.x /16 to a pool of N2X Clients and

the relay agent interface connected to the N2X Client pool has address

100.3.0.1 /16, then you will not be able to resolve ARP between theclient pool and the relay agent. In real world scenarios, clients are

usually assigned IP addresses of the same network to which they are

attached.

One caveat, however, regards the N2X DHCP Server. Since the Server IP

address is not configured with a specific subnet, it will respond to any

ARP requests that it receives. For example, in this document the Server

IP address is configured as 100.2.2.2 and in Scenarios 1 and 2, the Client

pool is assigned addresses from 192.133.x.x /16. Since the server is not

configured with a specific prefix you will find that the Server responds

to all of the ARP messages from the clients 192.133.x.x. On the other

hand, from the Link Layer Setup the N2X tester addresses will only

respond to ARP messages from interfaces on their specified network.

Why cant I configure multiple VLANs on an emulated DHCP Server?

Currently, each N2X DHCP Server device only supports a single VLAN.

Therefore, you must create multiple DHCP Server instances together in

a single pool or many pools each with a single instance, and have one

server for each VLAN.

Why is my DHCP Server (DUT) sending NAK messages after receiving

Request messages from an N2X Client.

It is possible that the DUT has certain options configured by default.Enable capture on the N2X to view the DHCP messages from the DUT to

verify if certain options are enabled or required. For example, the DUT

may be expecting the Client ID option to be set. See step 6 in section

Common steps - Device Setup, subsection Adding and Configuring

DHCP Devices which points to the area for configuring DHCP Client

options.

4.

5.

6.


24/24

Sales, Service and SupportUnited States:

Agilent TechnologiesTest and Measurement Call CenterP.O. Box 4026Englewood, CO 80155-40261-800-452-4844

Canada:

Agilent Technologies Canada Inc.2660 Matheson Blvd. EMississauga, OntarioL4W 5M21-877-894-4414

Europe:

Agilent TechnologiesEuropean Marketing Organisation

P.O. Box 9991180 AZ AmstelveenThe Netherlands(31 20) 547-2323

United Kingdom

07004 666666

Japan:

Agilent Technologies Japan Ltd.Measurement Assistance Center9-1, Takakura-Cho, Hachioji-Shi,Tokyo 192-8510, JapanTel: (81) 426-56-7832Fax: (81) 426-56-7840

Latin America:

Agilent TechnologiesLatin American Region Headquarters

5200 Blue Lagoon Drive, Suite #950Miami, Florida 33126U.S.A.Tel: (305) 269-7500Fax: (305) 267-4286

Asia Pacific:

Agilent Technologies19/F, Cityplaza One, 1111 Kings Road,Taikoo Shing, Hong Kong, SARTel: (852) 3197-7777Fax: (852) 2506-9233

Australia/New Zealand:

Agilent Technologies Australia Pty Ltd347 Burwood HighwayForest Hill, Victoria 3131Tel: 1-800-629-485 (Australia)Fax: (61-3) 9272-0749

Tel: 0-800-738-378 (New Zealand)Fax: (64-4) 802-6881

Agilent N2XAgilents N2X multi-service tester combines leading-

edge services with carrier grade infrastructure testing

and emulation. The N2X solution set allows network

equipment manufacturers and service providers to

more comprehensively test new services end-to-end,

resulting in higher quality of service and lower network

operating costs.

Warranty and SupportHardware Warranty

All N2X hardware is warranted against defects in

materials and workmanship for a period of 1 year from

the date of shipment.

Software Warranty

All N2X software is warranted for a period of 90 days.

The applications are warranted to execute and install

properly from the media provided.

This warranty only covers physical defects in the

media, whereby the media is replaced at no charge

during the warranty period.

Software UpdatesWith the purchase of any new system controller

Agilent will provide 1 year of complimentary softwareupdates. At the end of the first year you can enroll into

the Software and Suport Agreement (SSA) contract for

continuing software product enhancements.

SupportTechnical support is available throughout the support

life of the product. Support is available to verify

that the equipment works properly, to help with

product operation, and to provide basic measurement

assistance for the use of the specified capabilities, at

no extra cost, upon request.

Ordering InformationTo order and configure the test system consult your

local Agilent field engineer.

www.agilent.com/find/n2x

This information is subject to change without notice.

Printed on recycled paper

Agilent Technologies, Inc. 2007

Printed in USA March, 2007

5989-5662EN

Documents

DHCP Emulation