Configuring Emulated Ethernet for Charon-AXP

Monday, 25 June 2012 13:33

In the last month or so I have been involved in configuring an Alpha virtualisation solution for a client.  They have an AlphaServer DS15A which they would like to move to an emulated CHARON-AXP DS10L.  Until it came to configuring the network the whole process had been very simple and easy.  However, once I started setting up the network interfaces I ran into plenty of trouble.  After spending much time searching around the 'net and experimenting with the configuration I finally got something that worked.  Unfortunately, finding all this information was not very straight forward (at least not to me) and hopefully everything I have documented here will save someone else stuck in the same situation.



Charon-AXP needs its own adapter to support an emulated device.  The best way to load the drivers and take control of the card is to use the Network Control Center utility that comes with the emulationg software.  I used version 1.26.  If you don't have it you can download it here.  Use this utility to allocate a network adapter for exclusive use by Charon-AXP and remove all other extensions and protocols.  I used a Broadcom NetXtreme II as well as another Broadcom card for the storage and network adapters for host system.  Something worth noting is that the host network configuration was using LACP teaming.  These drivers will show up as being active on all the network adapters on the host system.  You can safely ignore this, it does not appear to affect the Charon-AXP emulation.

The last thing that Network Control Center will do is to spit out a sample configuration snippet for the network adapter (similar to the one below).  Use this only as a very rough guide.  Trusting this output is partly what got me into trouble in the first place.  You'll also notice the string "connection:EWA0" in there too.  I renamed my network adapters to reflect their use by the Charon-AXP product.

1. NIC connection name (preferred).
load DE500BA/dec21x4x EWA interface=EWA0
load ndis5_chpack_port/chnetwrk EWA0 interface="connection:EWA0"

2. NIC device name. WARNING: NIC device name may be duplicated!
load DE500BA/dec21x4x EWA interface=EWA0
load ndis5_chpack_port/chnetwrk EWA0 interface="Broadcom BCM5709C NetXtre...#53"

If you are using a system that has built in ethernet, like a DS10L then you can ignore the line 'load DE500BA/dec21x4x EWA interface=EWA0'.  The device EWA is already available as part of the default configuration. The next part, 'load ndis5_chpack_port/chnetwrk', is the tricky bit.  There are a set of rules that determine the different driver names to be used.  After reading through everything I could find I believe the following set of rules to be accurate, at least at the time of writing, and I request comments from anyone who finds different.

If your host system is...

  • Windows 2003(R2) or Windows XP, then use "ndis5_chpack_port/chnetwrk" for Charon-AXP Build 118-05 and higher.
  • Windows 2008(R2) or Windows 7, then use "ndis6_chpack_port/chnetwrk" for Charon-AXP Build 118-05 and higher.
  • Windows 2008(R2) of Windows 7 and Charon-AXP Build 129-04 is running as a virtual appliance then it is necessary to download a patch and follow these directions.
  • any version of Windows and using Charon-AXP Build 129-04 and higher then use "packet_port/chnetwrk".
  • any other system then check the documentation referenced at the bottom of this page.

So, here is a copy of the network adapter configuration for the system I was working on, an AlphaServer DS10L with two builtin DE500 network adapters.

# EWA0:
load ndis6_chpack_port/chnetwrk EWA0 interface="connection:EWA0"
set EWA interface=EWA0 adapter_mode="100BaseT-FD"
# EWB0:
load ndis6_chpack_port/chnetwrk EWB0 interface="connection:EWB0"
set EWB interface=EWB0 adapter_mode="100BaseT-FD"

You'll also notice in my snippet that I set the adapter_mode.  According to the documentation I could find this has to be configured manually, as you see above.  My experience has been that everything needs to be exactly the same.  I configured the network adapter in Windows to be 100BaseT-FD as well as the switch port the system was plugged in to, not just in the configuration file.  This is the only way I seemed to be able to get everything working reliably.  Do not use autosense at all, it just doesn't seem to work.


In my quest to get the network configuration working correctly I discovered a few problems and have included the symptoms and solutions below in the hope that I might give a pointer to someone already well down this path.

When I first started out and was using ndis5_chpack_port (when I should have been using ndis6_chpack_port) I found that the LANCP utility within OpenVMS would report the following information:

LEELA Device Counters EWA0 (29-MAR-2012 13:04:14.35):
                  Value  Counter
                  -----  -------
                     99 Seconds since last zeroed
                      0 Bytes received
                     70 Bytes sent
                      0 Packets received
                      2 Packets sent
                      0 Multicast bytes received
                     70 Multicast bytes sent
                      0 Multicast packets received
                      2 Multicast packets sent
                      0 Unrecognized unicast destination packets
                      0 Unrecognized multicast destination packets
                      0 Unavailable station buffers
                      0 Unavailable user buffers
                      0 Transmit underrun errors
                      0 Transmit failures
                     27 Carrier check failures
                      0 Station failures
                      0 Initially deferred packets sent
                      0 Single collision packets sent
                      0 Multiple collision packets sent
                      0 Excessive collisions
                      0 Late collisions
                      0 Collision detect check failures
                      0 Link up transitions
                      0 Link down transitions
   29-MAR-2012 13:04:08 Time of last generic transmit error
                   None Time of last generic receive error

I also discovered that although I could not get any traffic to move over the physical interface Charon-AXP was successfully changing the MAC address of the network card after DECnet started.  So, ipconfig/all would report the new MAC address.  The Cisco 2950 switch would also detect a change which would show up in the output of show mac-address-table briefly.  The 'Bytes sent' counter would very slowly increase, but the 'Carrier check failures' would increment with astronomical speed.

Without the adapter_mode attribute configured I would also notice that the Cisco switch port would auto-negotiate the link speed to be 100BaseT-FD, but that LANCP would report the connection as being 10BaseT-HD.  This would cause multitudes of carrier and frame check errors to be reported to the console by DECnet.


The content of this blog is based on my own personal experience and the following resources I managed to scour from around the 'net.

Lastly, here is the Advanced Networking Guide.  I did not find this until I was checking all my links and references before publishing this article.  It would have been a big help at the time.