Agilent N2X

DHCP Emulation Testing with Agilent N2X Application Note

DHCP Emulation Testing with N2X

Introduction Agilent 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.

2

DHCP Emulation Testing with N2X

Technology Background Dynamic 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 other configuration 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 provider’s DHCP Server is likely on a different 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 client’s 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.

3

DHCP Emulation Testing with N2X

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 a previous 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 client’s 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

4

DHCP Emulation Testing with N2X

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 server are 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

Multicast

Relay-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 with a 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.

5

DHCP Emulation Testing with N2X

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.

6

DHCP Emulation Testing with N2X

The Emulation Window The 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.

1. 2.

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 SUT Interfaces). 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.

7

DHCP Emulation Testing with N2X

Device Setup For 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 1.

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

2.

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

3.

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.

4.

8

DHCP Emulation Testing with N2X

5.

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.

6.

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) to close the window. 8. 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. 9. Select DHCP Server. 10. Verify the defaults that a single Pool with a single Server is to be created. 11. Click OK. 7.

9

DHCP Emulation Testing with N2X

12. 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.

13. 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.

14. Click OK to close the window and to save any configuration changes that were made. 15. 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.

10

DHCP Emulation Testing with N2X

Starting the Emulation

1.

2.

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.

3.

Right-click the DHCP Client pool and click “Start Emulation”. At this point, DHCP Discover messages are sent out by the clients as discussed in the Technology Background section.

4.

As the clients send and receive various DHCP messages, their intermediate states can be seen in the Emulation window.

11

DHCP Emulation Testing with N2X

Testing Specific DHCP Scenarios In 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. 1. 2. 3.

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.

12

DHCP Emulation Testing with N2X

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. 1.

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

Modified step 13: Configure the DHCP Server’s 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). 2. 3.

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.

13

DHCP Emulation Testing with N2X

Traffic Setup with the Device Mesh In general, when configuring regular traffic streams or IP meshes, MAC and SUT addresses from the Link Layer Setup are used. When Device meshes are being created 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 1.

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

2.

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.

3. 4.

Select the Sources and Destinations tab. Set the Available Sources Type and the Available Destinations Type both to ‘Device’.

14

DHCP Emulation Testing with N2X

5. 6. 7. 8. 9.

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).

10. 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.

15

DHCP Emulation Testing with N2X

Port to Device 1.

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

2. 3. 4. 5. 6. 7. 8. 9.

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.

16

DHCP Emulation Testing with N2X

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.

1. 2. 3. 4.

5. 6. 7. 8. 9. 10.

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.

17

DHCP Emulation Testing with N2X

Device to Device 1.

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

2.

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.

3.

Now refer back to section Scenario 1 and 2: Back to Back or L2 Switch, subsection Device to Device. Complete steps 3 – 10.

18

DHCP Emulation Testing with N2X

Port to Device 1. 2.

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 Port’s 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.

19

DHCP Emulation Testing with N2X

Viewing DHCP Emulation Statistics The 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 Client pool, the steps and descriptions are the same for DHCP Servers and DHCP Client Relay Agents. 1. 2.

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.

20

DHCP Emulation Testing with N2X

DHCPv6 Emulation Scenario 1 and 2: Back to Back or L2 Switch These two scenarios are identical to the DHCPv4 setup except that DHCPv6 devices 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. 1.

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 the Server. 2. Enabling ‘Address Assignment’ causes the client to request and accept an IPv6 address. 3. 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 bound with 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

21

DHCP Emulation Testing with N2X

Troubleshooting 1.

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. 2.

I see the error message “Duplicate IP address detected = :: unable to add MAC address for device pool n” when I try to create a DHCPv6 Device 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. 3.

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.

22

DHCP Emulation Testing with N2X

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. 4.

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 the client 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.

5.

Why can’t 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.

6.

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.

23

www.agilent.com/find/n2x

Agilent N2X

Sales, Service and Support

Agilent’s N2X multi-service tester combines leading-

United States: Agilent Technologies Test and Measurement Call Center P.O. Box 4026 Englewood, CO 80155-4026 1-800-452-4844

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 Support Hardware 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 Updates With the purchase of any new system controller Agilent will provide 1 year of complimentary software updates. At the end of the first year you can enroll into the Software and Suport Agreement (SSA) contract for continuing software product enhancements.

Support Technical 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 Information To order and configure the test system consult your

Canada: Agilent Technologies Canada Inc. 2660 Matheson Blvd. E Mississauga, Ontario L4W 5M2 1-877-894-4414 Europe: Agilent Technologies European Marketing Organisation P.O. Box 999 1180 AZ Amstelveen The Netherlands (31 20) 547-2323 United Kingdom 07004 666666 Japan: Agilent Technologies Japan Ltd. Measurement Assistance Center 9-1, Takakura-Cho, Hachioji-Shi, Tokyo 192-8510, Japan Tel: (81) 426-56-7832 Fax: (81) 426-56-7840 Latin America: Agilent Technologies Latin American Region Headquarters 5200 Blue Lagoon Drive, Suite #950 Miami, Florida 33126 U.S.A. Tel: (305) 269-7500 Fax: (305) 267-4286 Asia Pacific: Agilent Technologies 19/F, Cityplaza One, 1111 King’s Road, Taikoo Shing, Hong Kong, SAR Tel: (852) 3197-7777 Fax: (852) 2506-9233 Australia/New Zealand: Agilent Technologies Australia Pty Ltd 347 Burwood Highway Forest Hill, Victoria 3131 Tel: 1-800-629-485 (Australia) Fax: (61-3) 9272-0749 Tel: 0-800-738-378 (New Zealand) Fax: (64-4) 802-6881

local Agilent field engineer. This information is subject to change without notice. Printed on recycled paper © Agilent Technologies, Inc. 2007 Printed in USA March, 2007 5989-5662EN