DECNET network switch over in event of network failure

[eran_6]

We are looking for a capability for swiftly cutting over our DECNET from one network to another in the event of a network failure, along with the DMQ (BEA-MessageQueue) messaging that runs over the DECNET.

Here is a description of our overall configuration and requirements:

We are running a number of systems running OpenVMS (version 7.3-2), some in a OpenVMS cluster together and some stand-alone, where we use BEA-MessageQueue (version 4.0) over DECNET (some nodes on phase IV and some nodes on phase V) to communicate between processes running on each of the many systems.

We are now planning a new redundant network configuration. In this configuration each OpenVMS machine will have separate network interface cards to each of two LAN segments, say LAN segment-A and LAN segment-B.

In our standard configuration, we will have all the BEA-MessageQueue over DECNET traffic run default over LAN segment-A.

But, in the event that LAN segment-A fails, we would like DECNET to re-route as automatically as possible to LAN segment-B. We would like to have the BEA-MessageQueue over DECNET re-route as well in the same way.

If there is any procedure, method, or product that could provide us this capability, we would be interested in investigating its applicability to our systems.

Thanks for any assistance here.

[Robert Gezelter]

visa,

DECnet out of the box will chose cheapest, fastest link (by definition, a link that is down has infinite cost). This presumes that you configure the multiple interfaces directly.

In DECnet addresses are Node Numbers, not Interface Numbers as they are in IP (which is why there is no need for the alternate address trick that is used so frequently with IP). So long as the timeout thresholds are not a problem, the traffic should re-route automatically.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

FWIW : when you have 2 interfaces and 1 goes down, the thruput of your node will be cut in 2 also.

Wim

[Andy Bustamante · Accepted solution]

You may also want to consider LAN fail over. See the System Manager's Manual vol 2 chapter 10. See http://h71000.www7.hp.com/doc/732FINAL/aa-pv5nh-tk/aa-pv5nh-tk.HTMl for more information. This supports DECnet phase IV and V as well as TCPIP. There is a restriction on which network cards are supported (and a recent ECO adds support for the DE-500 cards).

Andy

[Robert_Boyd]

Visa,

If the affected nodes are Phase V capable they will continue working without any problems as mentioned by Robert and Wim.

You may however have problems with Phase IV nodes if the failing segment/interfaces were carrying the Phase IV traffic. In this case things get more interesting depending on the interconnects and routers you're using.

In order to fully appreciate your situation it would be necessary to create a network topology diagram with the proper information regarding Phase IV and Phase V circuits and routers.

Robert

[Robert Gezelter]

visa,

I should have been clearer in my earlier posting.

I presumed that if the nodes were Phase IV, they were routing nodes, not end nodes.

- Bob Gezelter, http://www.rlgsc.com

[Thomas Ritter]

Visa, we use decnet phase 4 and bea messageq version 5.0, VMS 7.3-2 and a Disaster Tolerant system. One of our intersite link channels failed, halting IP but allowed DECnet to continue.
DECnet is configured on two seperate backend networks, each node is a router and each host has two backend connections and each circ has the appropriate costs configured.
When we built the systems many vested interests tried to prevent us from having two backend networks. Our recent network problems took 3 days to resolve. Were it not for the redundant network configurations we would have lost MessageQ communcations from two our four node cluster members. MessageQ uses DECNET exclusively in our configuration.
Network hardware is cheap compare to other IT costs.

Very good to see you are using BEA MessageQ. MessageQ is a model archecture by which many other systems could do well to mimic. And it was developed in the 80s ! Version 4.0 of MessageQ is outdated. Version 5.0 RP 28 is the current release.

If you feel this advise is worthwhile please assign points.

[Jan van den Ende]

Visa,

from your Forum Profile:


I have assigned points to 3 of 19 responses to my questions.

One of those dates back to 2003!

Maybe you can find some time to do some assigning?

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption "My Question(s)" you will find "questions or topics with unassigned points " Clicking that will give all, and only, your questions that still have unassigned postings.

Thanks on behalf of your Forum colleagues.

PS. â nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before â please do not take offence â none is intended!

Proost.

Have one on me.

jpe

[Colin Butcher]

You should find this to be a useful reference (I hope): http://www.downloads.xdelta.co.uk/vmstjv5%20feb2005/decnet%20article%20vms%20tj%20v5%20feb2005.pdf

In summary: Phase IV will give you end-node failover for a non-routing node and will give you load balancing and failover for 2 (or more) equal cost paths for a routing node. Phase V will give you load balancing and failover for 2 (or more) equal cost paths for an end system.

What I usually do is set up the dual (or triple) rail network with all nodes connected to all rails, then have DECnet routers (not layer 2 bridges) between the rails. You may well need to fiddle around with some of the DECnet parameters to get the kind of rapid failover behaviour you want. It's usually a trade-off between overhead (not a big issue really) and speed of detection of path failure. Circuit level Hello Timer is one of the key parameters, as is Retransmit Factor (and their Phase V equivalents).

The short version is - DECnet will do exactly what you want it to do automatically without any intervention, once you've set it up and tested it.

On the IP side - I now tend to use "failsafe IP", or add a layer to the application and handle the alternate path retry abopve the available physical paths. Another way is to use IP routing and OSPF in a big way, but that's quite complex to design and configure. The problem is that IP addressing is historically "per interface", not "per node", so the underlying design is different to that of DECnet. Might well be worth experimenting with IPv6 and seeing what that can do for you in a multiple LAN environment.

Good luck!
Cheers, Colin.

[Thomas Ritter]

Lots of free experts advice provide here and no feedback. Some high paid suits would to well to provide the advice these authors provided.
Disappointing.

[Robert_Boyd]

Colin,

What if some of the nodes involved in the network are still running on VMS V5.x(or earlier) with DECnet extensions? Will those systems also continue to work properly on the remaining interfaces?

I can believe that with DECnet-Plus systems in the V7.x and later range that your description is accurate, but I am pretty sure that earlier versions may not handle it all so gracefully.

Robert

[eran_6]

Thanks everybody for the assistance.

We understood that, for DECNET Phase V, one can provide fail over out of the box. However, because in DECNET Phase IV, an Alpha DECNET node can not be a router and can not be an owner of more than one line/circuit, failover is not as simple.

As Colin mentioned, for IP there's a procedure known as "failsafe IP". We didn't check it out yet.

In any case, we've decided (for now) to try to use the Lan fail over method as mentioned by Andy (System Manager's Manual vol 2 chapter 10).

[Volker Halle]

Visa,

LAN failover (according to the manual):

'is a mechanism for protecting your system from a LAN device failure'

Both (all) LAN devices in a LAN failover set must be connected to the SAME EXTENDED LAN.

LAN failover protects you from a failure in a LAN device, cable or switch. Nothing more. LLDRIVER just acts on the Link up/Link down transitions.

Volker.

[Robert_Boyd]

visa,

What are the versions of VMS and DECnet that you're running?

NCP SHOW EXEC CHAR and
NCL SHOW IMPLEMENTATION

are the commands to get the relevant info.

It might be helpful to some of us to see the various versions that you have to contend with.

Probably best to remove/obfuscate the node names as that is not essential to the discussion.

Robert

[Colin Butcher]

Robert,

Actually DECnet/OSI V6.3 (back in VAX VMS V5.5-2 days) would do this stuff - once a lot of the implementation details and some of the design assumptions were fixed (things like probe rate). You might remember a load of ECOs coming out in quick succession. Those fixed a lot of the dual-LAN failover and load balancing issues I found during testing. Biggest problem I had back then was working out how to implement DECdns failover. Got it sorted in the end.

Ah well.

Cheers, Colin.