Replacement of decnet router

[Wim Van den Wyngaert]

We are using VMS 7.3 with decnet 7.3 eco 3 (28-oct-2002). We are using decnet+ in transport NSP only. No DNS, only .LOCAL.

Now the very old router is going to be replaced by redundant routers.

Anyone experience with such a replacement ? Side effects ?

Wim

[Hoff]

Within the scope of what I now know of your configuration here (ie: not much), what you are proposing (planning) should work just fine.

I'd probably set the router priority for the fastest (or preferred) router, if there are differences among the replacements. (Otherwise, IIRC, the priority is based on the lowest host address. In one case I'm aware of, a VAXstation 2000 with a low address erroneously got enabled as a router, and ended up routing the whole of a large group of hosts.)

I'd probably add DNS/BIND after .Local, and start using DECnet-Plus over IP.

[Wim Van den Wyngaert]

Hoff,

Had the same over here. A VAX was doing the routing (by accident) and the real router didn't do his job. Worked fine until the VAX was unplugged ...
The current router is a Cisco 7200. No data yet on the new one.

Wim

[Colin Butcher]

Hi Wim,

Depends on the level of redundancy you need and how the network infrastructure is configured and so on. A diagram would be most helpful.

If you stay with routing DECnet in the Ciscos it tends to get expensive these days because the DECnet routing is an "extra". It also means carry multiple protocols over the intervening WAN link - which is fine unless it's an IP only VPN or something.

DECnet routing with pairs of routers and multiple paths "just works". IP routing with multiple paths and multiple interfaces is a lot more "interesting" to configure.

DECnet over IP is an alternative solution, but you start to lose the multiple path fatures of DECnet and have to get into IP routing and how to handle multiple paths and multiple interfaces. With DECnet over IP the end to end communication between the nodes (now IP interfaces) is entirely IP, so you can end up having to resesign the network configuration if you're doing multiple paths for load balancing and high availability.

If you have muliple paths and your own WAN links then it may well be worth looking at picking up some of the older DEC networking kit such as the Routeabout Central DEChub900 form factor type devices. ALternatively a DS10 / DS10L with dual LAN and dual WAN running VMS can make a nice multiprotocol router.

Lots of possible ways to solve the problem. Also depends what other protocols you need to pass over the links and whether any of them need bridging at layer 2 rather than routing at layer 3.

This might help with some of the background, but you've probably read it already: http://www.downloads.xdelta.co.uk/vmstjv5%20feb2005/decnet%20article%20vms%20tj%20v5%20feb2005.pdf

Cheers, Colin (http://www.xdelta.co.uk).

[Wim Van den Wyngaert]

Colin : changing something is out of the question. VMS will live charter than the time to implement the change (so they say).

The routing was changed as follows : down old router, up new routerS (about 100 seconds between the 2).

All went fine except that 1 node could not see another node in the same area. Test done 5 minutes after the change via set host.

After 5 minutes the problem went away (could be less but we tried set host with an interval of 5 minutes) without changing anything.

Wim

[JohnDite]

Before being able to comment it would be interesting to find out what kind of DECnet configuration you've got at present LAN / WAN, multicircuit, # of Areas, routing protocol IV or IS-IS etc.

Your results as far as the time it took for another node to see a partner node in the sane area does surprise me. Are they also running DECnet+ or are these still IV systems?

John

[Wim Van den Wyngaert]

All nodes are running the same decnet software. The difference between these 2 problem nodes and all the others is that they are rarely used in decnet.

No plans available of the network infrastructure (other teams, hard to get). But we have multiple areas.

Wim

[Colin Butcher · Accepted solution]

Hello Wim,

5 mins = 600 secs = default value for hello timer on Phase V.

That's one of the important differences in defaults between Phase IV and Phase V.

Try changing hello timer to 30 secs and see if things improve (use NET$CONFIGURE in ADVANCED mode). What type of routers have you got and what can you change?

It's really difficult to guess what happens without a diagram and without a better understanding of your network topology.

[Wim Van den Wyngaert]

Colin,

Further info is hard to get. Changes are out of the question.

My routing default eshello is at 15 on all nodes. Except on the 2 nodes where it is on 600 (quorum nodes not configured in the same way).

I guess you found the problem but I don't understand how it exactly works. How is routing exactly working ? I thought the router was going to broadcast it's presence and that all nodes would update their caches.

Wim

[Ian Miller.]

The routers advertise their presence using hello messages.

If you don't change anything then its not going to get any better.

Documenting your network topology would benefit yourselves whenever you have a problem in the future and also for IT asset management.

[Tony_289]

Wim, This would be a side-effect or fact of life response Re: DECNET. I am unable to elaborate with my sites specifics, but I was involved with moving a host system off of fiddi to something more... current :-). That system had ~80 clients machines wondering where its host went to once it booted up on the newer network. Colin's reply hit home.

Once my host system's network cable was switched (which involved the new routers), I had to simply wait for a spell until they timed out with the old router, then discover the new router's "hello message". I am assuming that is why you couldn't see that other node in the same area. Like you, I was performing the proverbial up-arrow/hit return "Set host command" to determine when those clients finally timed out and saw the new routers.

I guess it all depends on the default "hello timer"?

Cheers from Vancouver WA.

Tony

[Colin Butcher]

Hi,

There's a brief description of routing in the article I referred to earlier: http://www.downloads.xdelta.co.uk/vmstjv5%20feb2005/decnet%20article%20vms%20tj%20v5%20feb2005.pdf

Let's stick with Phase IV based routing for the moment: Basically the end nodes advertise their presence every "end node hello timer" to a multicast address that the routers listen to. The routers then build a map of who's where. The routers advertise their presence every "router hello timer" and the end nodes thus know who their nearest router is - and sort out the preferred router based on the "router priority". After a period of time all the nodes know who's where.

Nodes fall out of being reachable after you've not heard from them for 3x end node hello timer. It's made more tricky by things like retransmit factor.

In a multi-path network with multiple routers things get a bit tricky if you have inconsistent values for the various timers - as you've discovered.

Personally I keep the end node hello timers on the LAN side down to around 10-15 seconds, maybe 30 at worst, sometimes much less if I want rapid failover on a multi-rail LAN with very few nodes and not much traffic. It's not too much overhead. Where it gets fun is with extended LANs bridged over low bandwidth connections.

There's a lot to it "under the hood", but in general DECnet works very well indeed with the default values, but there are a few things worth setting to non-default values, such as the "end node hello timer".

Read the Phase IV functional specifications if you have the time. They're on the web somewhere. You can (or used to be able to) order the Phase V functional specifications too.

Cheers, Colin (http://www.xdelta.co.uk).