Marc Chametzky wrote: You have two (well, three) potential problems here. Of the problems you list, most of them aren't actually the kinds of problems you'd expect. ESXi is very good about presenting multiple virtual interfaces to its guest operating systems over a single physical interface. ESXi creates a virtual bridge to handle this. It's even possible using VLANs to set up different LAN segments to isolate traffic between guests. There are more things to it than might appear to the eye here. The problem is that TCP/IP, by its design, don't care about them, but DECnet do. And so, virtual machines can work fine with OSes that talk TCP/IP, and most likely the implementors of the virtual machine have only tried TCP/IP, and possibly something like IPX, but most likely not DECnet. I'll expand a little more below. In this case, the Windows and the Linux system can see each other on the same LAN segment just fine. ESXi takes care of that very well. Hmm. I have a problem understanding the topology and hardware, so you really should be more explicit. Is either of the Windows or Linux system here on a virtual host? Or both? When you say LAN segment, are we talking about a physical cable or just a virtual LAN within a host? I'm able to configure the two VMS systems' hardware address to reflect their DECnet-computed addresses, so that's not an issue. Don't be too sure... What I failed to mention in my previous post (I realized it after I sent it), is that DECnet is very picky about *both* source and destination MAC address of ethernet packet. TCP/IP couldn't care less about the source address (heck, it don't even care about the destination address, as long as the packet enters the bottom of the IP stack, TCP/IP is happy). If you have a virtual bridge in your host, it becomes very interesting to verify that the source MAC address really is set correct when a packet comes out from the machine. A bridge should be totally transparent, and so source MAC addresses should be different depending on which virtual machine actually sent the packet. I know for a fact that there are ethernet controllers that don't allow you to set the source address of the ethernet packet at all, and instead the controller inserts its own address when the packet is being sent out. Admittendly, the controllers I know do this are the DEC controllers for Unibus and Q-bus, but there could very well be others that do this as well. These cannot be used to bridge DECnet no matter what you do. However, they work perfectly fine to bridge TCP/IP. If you have the wrong source address for ethernet packets I seem to remember that you will get a situation where on one side the adjacency is up, while the other side thinks not. Or if it were that adjacency look as if it was up, but if you tried establishing a connection, you'd get a timeout and failure. Third - is the actual machine running windows, or did I misunderstand something? The guest OS that's running the Alpha is Windows XP. I don't know what games Personal Alpha plays to make its networking work, but it's conceivable that there's some sort of issue there. I've dedicated the Windows network adapter to Personal Alpha's protocol interface, so Personal Alpha gets exclusive access to it. (This Windows system doesn't need TCP/IP connectivity anywhere... that makes it more secure anyway.) I remember from when playing with CHARON that you needed to set the MAC address of the adapter first, and then you'd get some long identifier that was used to connect the virtual machine with the adapter. And this had to be done outside of the virtual machine, since the virtual machine itself could not actually change the MAC address of the adapter, even though VMS thinks it's doing that. There are two potential failure points that I can imagine. One is ESXi. I don't think that this is the problem since DUSTY (on the Linux guest) is able to see LULU's packets and establish adjacency. ESXi is at least passing those packets in one direction, so it should be able to do it in both. I wouldn't make that assumption. First of all see all my comments above. Second, adjacency just means that packets have come in one direction. It don't mean that both sides see each other. Basically it's just a case of seeing the broadcast hello packets (if we talk ethernet). The other potential point is in Windows, and perhaps Personal Alpha's network interface. It may be dropping packets it doesn't recognize, so DECnet routing packets don't make it. Maybe. When I get a chance to use Wireshark, I'll at least see what's going on from Windows' perspective. One possibly additional thing here is that adjacency is based on broadcast packets. This is a rather loose requirement. Broadcast packets have a much higher chance of getting through here. Once you actually try a connection, then unicasts are used, and at that point we start getting into the issue of actually having correct MAC addresses on packets and interfaces. Adjacency can very well work when these things are wrong. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol