"Sampsa" == Sampsa Laine <sampsa at mac.com> writes:
Sampsa> Guys, I've just received a DEFPA-DB PCI-FDDI adapter from
Sampsa> ebay, my plan is to install it in CHIMPY and then connect
Sampsa> CHIMPY to CHIMP via this for clustering.
Sampsa> Anybody know how I would go about cabling such a beast, there
Sampsa> are four fibre optic ports on these things?
Wow, that takes me back a bunch of years...
There are two basic FDDI cabling approches: dual ring, and tree of
concentrators. The DEFPA can be hooked up either way because it has
the two ports (type A and B ports).
If you have other FDDI devices that also have A or B ports, just plug
A to B in a circular fashion, and you have a dual ring. This is the
topology that FDDI originally started with early in its development.
It has single-fault tolerance, but it doesn't support hierarchical
wiring (wiring closets). The single-fault tolerance means you can
make a chain instead of closing the ring, that's equivalent to the
ring with a single cable busted.
If you have a concentrator (a box with either A/B ports or S port,
plus a number of M ports) plug either A or B into an M port and leave
the other unused.
Finally, if you have another device with an S port (a "single attached
station") you can plug that into either the A or the B port, leaving
the other port available for another S port, or another A/B port. I
don't think you should have S to A and B to M, but I don't remember
for sure. If you have concentrators, the rule is that any single
attached devices plug into M ports, while dual attached devices plug
either into an M port or into the root dual ring.
paul
Guys,
I've just received a DEFPA-DB PCI-FDDI adapter from ebay, my plan is to install it in CHIMPY and then connect CHIMPY to CHIMP via this for clustering.
Anybody know how I would go about cabling such a beast, there are four fibre optic ports on these things?
Also, can I route DECNET traffic over this interface - I assume not as bot machines are Alphas and they don't do routing...
Sampsa
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
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
