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.
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.
I'm able to configure the two VMS systems' hardware address to reflect their DECnet-computed addresses, so that's not an issue.
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.)
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.
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.
--Marc
Windows have a very weird and appearantely unreliable
interface for programs that want to talk raw ethernet.
And for virtual machines, you do want to talk raw ethernet.
But these are all just potential problems. To really diagnose all of this, you'd have to be physically by the machine to test various things.
Depending on system, as well as virtual machine, these problems can be solved, but I wouldn't bet money on anything here. :-)
Johnny
Ok, I've stayed out long enough. :-)
Marc Chametzky wrote:
Marc you might also double check your cabling (in fact even change them).
There is no cabling between the two systems. Both LULU and DUSTY are virtual systems running on the same ESXi hardware.
You have two (well, three) potential problems here.
First of all, since both virtual machines are running on the same hardware, you can get into a probem where one machine don't neccesarily hear traffic from another machine, since they are eventually talking on the same hardware.
Second, DECnet, unlike TCP/IP actually requires that the ethernet interface have a specific MAC address, and if you have two virtual machine running, they will require that same interface to have different MAC addresses.
Third - is the actual machine running windows, or did I misunderstand something? Windows have a very weird and appearantely unreliable interface for programs that want to talk raw ethernet.
And for virtual machines, you do want to talk raw ethernet.
But these are all just potential problems. To really diagnose all of this, you'd have to be physically by the machine to test various things.
Depending on system, as well as virtual machine, these problems can be solved, but I wouldn't bet money on anything here. :-)
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
"Marc" == Marc Chametzky <marc at bluevine.net> writes:
Marc you might also double check your cabling (in fact even change
them).
Marc> There is no cabling between the two systems. Both LULU and
Marc> DUSTY are virtual systems running on the same ESXi hardware.
Marc> At least that's one issue I don't have to worry about. :-)
Marc> I'm still thinking it has something to do with Personal Alpha's
Marc> network handling. I know that they play funny games between
Marc> promiscuous mode and regular, and since I did set the Windows
Marc> network adapter to have the right hardware address for DECnet,
Marc> it's not using promiscuous mode, and perhaps it's not
Marc> recognizing some of the multicast packets. That's a silly thing
Marc> to consider, but I imagine it's possible.
With virtual hardware you might have virtually any problem...
Clearly if you have multiple DECnet nodes, each of them will need to
set its own DECnet-style MAC address. You should verify that your
virtualization setup is capable of supporting that.
Marc> I suppose it's also possible that DUSTY isn't able to send out
Marc> the hello packets. That I could find by snooping quite
Marc> easily. I wonder whether Wireshark on the virtual Windows
Marc> system would give me a decent idea of what DUSTY is sending
Marc> out... or at least what LULU /could/ be seeing.
It should. Certainly it should see the multicast packets. That will
let you confirm that they are there, and that they have the correct
MAC address. Any reasonable wireshark or Ethereal (same thing,
different name) should be able to parse DECnet frames well enough to
help you walk through them. The protocol specs are also available
on-line.
paul
Marc you might also double check your cabling (in fact even change them).
There is no cabling between the two systems. Both LULU and DUSTY are virtual systems running on the same ESXi hardware.
At least that's one issue I don't have to worry about. :-)
I'm still thinking it has something to do with Personal Alpha's network handling. I know that they play funny games between promiscuous mode and regular, and since I did set the Windows network adapter to have the right hardware address for DECnet, it's not using promiscuous mode, and perhaps it's not recognizing some of the multicast packets. That's a silly thing to consider, but I imagine it's possible.
I suppose it's also possible that DUSTY isn't able to send out the hello packets. That I could find by snooping quite easily. I wonder whether Wireshark on the virtual Windows system would give me a decent idea of what DUSTY is sending out... or at least what LULU /could/ be seeing.
--Marc
"Brett" == Brett Bump <bbump at rsts.org> writes:
Brett> Marc you might also double check your cabling (in fact even
Brett> change them). As I recall, DECnet (like IPX) is not an error
Brett> correcting protocol. I've worked on networks where TCP will
Brett> error correct for poor cabling while the Novell connections
Brett> fell flat on their faces. This could explain why your IP
Brett> connection seems to work fine, but you have no DECnet
Brett> connectivity.
That seems strange.
DECnet (NSP) is just like TCP in that it handles lost packets. Bad
cables will produce lost packets but they will not produce corrupted
packets. Corrupted packets are caused by defective switches or
routers. Bad cables only cause CRC errors. (Well, except for the
EXTREMELY low probability of a random error getting past the Ethernet
CRC.)
You're right that TCP detects corrupted packets (some of them, anyway
-- TCP checksum is pretty weak) while NSP does not. But if you see
TCP checksum errors, the way to fix them is not to change the cabling,
but the defective switches/routers.
paul
On Mon, 6 Apr 2009, Marc Chametzky wrote:
I think I'm going to set up MultiNet on the Alpha and try using a TCP
circuit between LULU and DUSTY. This will tell me whether it's a DECnet
routing issue or an Ethernet packet one.
Well, with a DECnet-over-IP circuit instead, it's working just fine with
both nodes seeing each other's adjacency, and from LULU I can connect to
LEGATO.
So, some sort of Personal Alpha networking glitch. That's surprising
since I do have the two nodes clustered, so that's working. I wonder
what's not working right with DECnet routing multicasts.
Well, this may be suboptimal, but it works well enough and that's all
that matters.
--Marc
Marc you might also double check your cabling (in fact even change them).
As I recall, DECnet (like IPX) is not an error correcting protocol. I've
worked on networks where TCP will error correct for poor cabling while the
Novell connections fell flat on their faces. This could explain why your
IP connection seems to work fine, but you have no DECnet connectivity.
Brett
Hi All,
Virgin have been mucking me about a bit. I will be upgraded to a new
cable modem next week which will mean I'll get a new IP address for ZAPHOD.
However, in the mean time they've mistakenly disconnected me and
reconnected me to a different IP!
Zaphod's current IP address is 82.8.17.191, but that WILL change next
Wednesday afternoon (GMT) so it's up to you if you change the multinet
connection in the meantime ... I won't be offended if I'm off HECnet for
a week, I'm far too busy doing other things anyway :S
I'll post the new IP address next week,
Sorry for the outage ... but it's not my fault :-(
Chrissie
I think I'm going to set up MultiNet on the Alpha and try using a TCP circuit between LULU and DUSTY. This will tell me whether it's a DECnet routing issue or an Ethernet packet one.
Well, with a DECnet-over-IP circuit instead, it's working just fine with both nodes seeing each other's adjacency, and from LULU I can connect to LEGATO.
So, some sort of Personal Alpha networking glitch. That's surprising since I do have the two nodes clustered, so that's working. I wonder what's not working right with DECnet routing multicasts.
Well, this may be suboptimal, but it works well enough and that's all that matters.
--Marc
