LAN Failover

[Jeff Wolfe_1]

Does anyone have any first hand experience with LAN failover? In reading the documentation, this will create a new network device, llA0 for example. I know I'll have to change the IP binding to point to this device. Will that also be necessary with Decnet? Do the physical devices cease to exist from the point of the OS? Any information would be appreciated.

[Antoniov.]

Mhm, strange question.
For full answer you could read document about TCP/IP http://h71000.www7.hp.com/doc/tcpip54.html
about DecNet phase IV
http://h71000.www7.hp.com/doc/decnet.html
about decnet plus
http://h71000.www7.hp.com/doc/decnetplus73.html

You posted insufficient information for help you so I can only give general hints:
a) For TCP/IP you must plain host mapping then you need execute installation & configuration command:
$ @SYS$MANAGER:UCX$CONFIG !If you have V4.xx
$ @SYS$MANAGER:TCPIP$CONFIG !V5.XX
b) For Decnet IV you must plain address node then you can execute:
$ @SYS$MANAGER:NET$CONFIG
c) I don't know decnet-plus so I can't post any word about this.

@Antoniov

[Ian Miller.]

are you referring to the new in V7.3-2 lan failover features?
http://h71000.www7.hp.com/doc/732FINAL/aa-pv5nh-tk/aa-pv5nh-tk.HTMl

[Jeff Wolfe_1]

Ian, yes I am referring to the new 7.3-2 feature. I was planning on setting it up this weekend and wanted to know if anyone else has tried it yet. Using LANCP you create a logial device that point to 1 to n physical nic's.

From there the documentation is vague. It never really goes into any detail. I'm trying to find out what happens to the original physical interfaces. Are they hidden? Are they still there and being used by some applications. For instance, cluster traffic will usally flow over all network interfaces it finds.

I also assume I'll have to change DECNET from using the physcal EW device to this new LL device. But it's never stated anywhere.

I guess what I was looking for was someone to say "yea, it works great, go for it". It seems that's not happening.

[Ian Miller.]

I've not had the chance to try this new feature out yet so report back with what you find and it will be educational for us all.

[Jeff Wolfe_1]

We enabled LAN Failover this weekend with reasonably good success. There were some issues that we are still working through but I'm confident they will be solved.

This biggest issue now it that Decnet Phase IV is not recognizing the LLA device. In a conversation with HP they state that I should reboot and make sure Decnet is the first network application to start. They assured me that Decnet Phase IV is aware of the LLA device.

To get around this Decnet issue we left one of our 3 NIC's out of the failover set. Decnet is now bound to this EIA device.

We use Multinet from Process software as our IP stack and it worked perfectly, no issues.

We did have to change the LAT startup to make sure it bound to the LLA device. By default it bound to the EIA device, which was the first device it saw. I guess once the EIA device joins the Failover set, this won't be necessary.

The only other issue we were having was with the NIC priority. When I had all 3 NIC's in the failover set, the EIA card was always being selected as active. This occured no matter what the priority of each NIC was. This was a problem because the EIA card is a 10/100 card and the other 2 are 10/100/1000. We have Gigabit running in the sever room, and I need one of the gigabit cards to be the preferred card.

Once the Decnet issue is cleared up, I can contact HP and address this issue. In the meantime, I can use the /switch option in LANCP to manually select the preferred card.

[Uwe Zessin]

Jeff,
can't you just run NETCONFIG.COM and let it figure out the correct commands to set up the line and circuit for LLA in NCP? I have no experience with LAN failover, but I doubt that DECnet will automatically figure out that it should now use a new device - did they really say that?

Then you just write them down and quit NETCONFIG before it messes up your current DECnet setup. Now you can delete the line+circuit for EIA and create new ones for LLA. I assume you will first list and save away the old setup...

[Jeff Wolfe_1]

Uwe,

We did exactly that. Added line and circuit statement for LLA-0. But, Decnet failed when it tried to bring them up. It got an invalid physical address. Now, what HP is saying, it that I need to make sure this happens before any other network bindings occur. They said it has something to do with the AA-00-00-04-XX-XX MAC address they create for the adapter based on the node name/number. That must occur first. Then other layers can bind to the network.

So I have to bring up the system clean, have the LLA-0 lines and circuits in the config and remove the other line and circuit configs. Everything should be fine after that.

[Uwe Zessin]

I see. Then I misunderstood you, sorry. I am sure it is just TCP/IP that is locking the physical address. If I remember correctly, VMScluster and LAT can deal with it when the physical address is later changed by DECnet, but I agree that a reboot is safer and will be a nice test to make sure everything is set up properly.

[Bob Kortlandt]

Hi, I'm new to this forum.
Anyway, I am trying to get it working on IP (FailSAFE IP) on OpenVMS 7.3-1, TCPIP 5.4 ECO 155 (the VMS 7.3-2 TCPIP version), but when activated, the devices are activated and fail immediate in an endless loop. FailSAFE works in that way, that when a device fails, the other is activated, but fails immediately, etc etc.

[Zahid Ghani]

Bob,
I configured failSAFE IP on 7.3-1 with two cards. I must say I had very little problem.
Perhaps you could post the command you used.
What are your NICs. Don,t use autonegotiate.

[Bob Kortlandt]

When I enable TCPIP service FAILSAVE following happens:


14-Apr-2004 15:31:34 INFO: Reading configuration file: SYS$SYSDEVICE:[TCPIP$FSAFE]TCPIP$FAILSAFE.CONF
14-Apr-2004 15:31:34 EVENT: started on node KLPV02:
Logfile : SYS$SYSDEVICE:[TCPIP$FSAFE]TCPIP$FAILSAFE_KLPV02.LOG
Monitoring: IE0,IE1
Info Poll : 3s
Warn Poll : 2s (1 retry)
Error Poll: 30s
14-Apr-2004 15:31:39 INFO: IE0 - retry limit reached
14-Apr-2004 15:31:39 EVENT: IE0 - ifconfig IE0 fail
14-Apr-2004 15:31:42 INFO: IE1 - retry limit reached
14-Apr-2004 15:31:42 EVENT: IE1 - ifconfig IE1 fail
14-Apr-2004 15:32:09 EVENT: IE0 - ifconfig IE0 -fail
14-Apr-2004 15:32:09 EVENT: IE0 - interface has become functional
14-Apr-2004 15:32:12 EVENT: IE1 - ifconfig IE1 -fail
14-Apr-2004 15:32:12 EVENT: IE1 - interface has become functional
14-Apr-2004 15:32:14 INFO: IE0 - retry limit reached
14-Apr-2004 15:32:14 EVENT: IE0 - ifconfig IE0 fail
14-Apr-2004 15:32:23 INFO: IE1 - retry limit reached
14-Apr-2004 15:32:23 EVENT: IE1 - ifconfig IE1 fail
14-Apr-2004 15:32:44 ERROR: 10.30.214.10 (10.30.214.10) -- not local protocol address
14-Apr-2004 15:32:44 EVENT: IE0 - ifconfig IE0 -fail
14-Apr-2004 15:32:44 EVENT: IE0 - interface has become functional
14-Apr-2004 15:32:49 INFO: IE0 - retry limit reached
14-Apr-2004 15:32:49 EVENT: IE0 - ifconfig IE0 fail
14-Apr-2004 15:32:53 EVENT: IE1 - ifconfig IE1 -fail
14-Apr-2004 15:32:53 EVENT: IE1 - interface has become functional
14-Apr-2004 15:32:58 INFO: IE1 - retry limit reached
14-Apr-2004 15:32:58 EVENT: IE1 - ifconfig IE1 fail
14-Apr-2004 15:33:19 EVENT: IE0 - ifconfig IE0 -fail
14-Apr-2004 15:33:19 EVENT: IE0 - interface has become functional
14-Apr-2004 15:33:28 EVENT: IE1 - ifconfig IE1 -fail
14-Apr-2004 15:33:28 EVENT: IE1 - interface has become functional

On a unix node with NetRain it works fine.

Ethernet devices are set to fastFD.

This is the config:
IE0: flags=c43
*inet 10.30.214.10 netmask fffffe00 broadcast 10.30.215.255 ipmtu 1500

IE1: flags=c03
failSAFE IP Addresses:
*inet 10.30.214.10 netmask fffffe00 broadcast 10.30.215.255 (on KLPV02 IE0)

(sorry for crappy layout)