Two IP addresses in same subnet on the one machine

[Jeremy Begg]

Hi,

Process Software MultiNet V5.2 Rev A-X, COMPAQ AlphaServer DS20E 666 MHz,
OpenVMS AXP V8.3

For various reasons I'm about to split a VMScluster consisting of two nodes
which boot from the same system disk and MultiNet root directory. Each node
has its own IP address (a.b.c.1 and a.b.c.2) plus they share an IP Cluster
Alias address (a.b.c.15). All addresses are in the same subnet (a range of
31 addresses).

After the split (which will happen in about 48 hours) each machine will be
operating stand-alone with no shared files. However they will be connected
to a shared SCSI bus so that in the event of one machine failing the other
one can take over. (Sort of a "warm" failover ability.) The startup
procedures on both systems are careful not to both mount the same disks
simultaneously!

The purpose of this email is to ask how best to handle the web services which
are currently associated with the IP cluster alias address. The intention
is that the various web sites hosted on these machines will be offered on an
IP address which will be moved from one machine to the other if the
currently active machine fails. (The failover time will be in the realm of
several minutes rather than seconds or hours.)

Each machine has two Ethernet ports. So I have come up with the following
scenarios and I'd like some guidance as to which would be "best".

1. Use one ethernet port as the machines "primary", unchanging ethernet
address i.e. a.b.c.1 or a.b.c.2, depending on the machine. Use the other
ethernet port as the machines "service" address i.e. a.b.c.15. In normal
operation one machine will set this interface /DOWN and other other one
will set it /UP. The failover process will require the newly active
machine to make its second interface /UP, and the failing machine to make
it's /DOWN (although it will probably be down anyway).

2. Similar to the above, but use a pseudo-interface attached to the primary
ethernet port. The pseudo-interface IP address (a.b.c.15) will be marked
/DOWN on one machine and /UP on the other, as before. (The reason for
adopting this approach is to allow the second ethernet interface on each
machine to be used for a "private" network, but I haven't yet decided if
this is necessary for my purposes or even desirable.)

3. Retain the IP cluster alias feature on each machine but take steps to
ensure it's active only on one machine at a time. I suspect the only way
this can be done is to manually ENABLE or DISABLE the CLUSTERALIAS
service and restart the MULTINET_SERVER process. I suppose it might be
done by having a process running on the "inactive" machine which grabs
the relevant VMS lock before MultiNet gets a look-in, but first I'd have
to find out what the lock is.

4. Any other suggestions for achieving this? I'd rather not rely on dynamic
DNS updates because they take too long to propagate and dynamic zones are
a pain anyway.

I can see that an immediate benefit of option 1 will be to offer a BIND
resolver on the .15 IP address, something which isn't possible using IP
Cluster Alias (because BIND only binds to interfaces) and which I've wanted
to be able to do for a long time.

Also isn't there support in MultiNet for transparently failing over from one
Ethernet port to another in the event of device failure? I can't find
mention of this in the MultiNet V5.2 install & admin guide.

Thanks,

Jeremy Begg

+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
| "OpenVMS Systems Management & Programming" |
|---------------------------------------------------------|
| P.O.Box 402, Walkerville, | E-Mail: ***@vsm.com.au |
| South Australia 5081 | Phone: [phone] |
|---------------------------| Mobile: [phone] |
| A.C.N. 068 409 156 | FAX: [phone] |
+---------------------------------------------------------+

[Javier Henderson]

Post by Jeremy Begg
4. Any other suggestions for achieving this? I'd rather not rely on dynamic
DNS updates because they take too long to propagate and dynamic zones are
a pain anyway.

If the VMS systems are plugged into Cisco switches running a version of
IOS that supports SLB's, that is an option. The switch presents an IP
address to the world, and dispatches packets to the real servers in one of
various forms. In your case you'd have one machine as preferred over the
other, so only one gets the connections, but if the preferred goes away,
the packets will then start flowing to the secondary system.

The decision of node up/down is based on the results of a probe that you
configure, in your case you were talking about web servers, so you'd
configure a probe to establish a connection to each node's web server
every so often, and upon failure, the corresponding node would be marked
down.

Other switch vendors might have similar features as well.

-jav

ps: by way of disclaimer, I work at Cisco.

[Jeremy Begg]

Hi Javier,

Post by Javier Henderson

Post by Jeremy Begg
4. Any other suggestions for achieving this? I'd rather not rely on dynamic
DNS updates because they take too long to propagate and dynamic zones are
a pain anyway.

If the VMS systems are plugged into Cisco switches running a version of
IOS that supports SLB's, that is an option. The switch presents an IP
address to the world, and dispatches packets to the real servers in one of
various forms. In your case you'd have one machine as preferred over the
other, so only one gets the connections, but if the preferred goes away,
the packets will then start flowing to the secondary system.

Thanks for the suggestion, and it's an interesting one, but unfortunately I
have no control over the Cisco equipment which connects these machines to
the Internet. But I'll definitely bear it in mind if that situation
changes!

Post by Javier Henderson
The decision of node up/down is based on the results of a probe that you
configure, in your case you were talking about web servers, so you'd
configure a probe to establish a connection to each node's web server
every so often, and upon failure, the corresponding node would be marked
down.
Other switch vendors might have similar features as well.
-jav
ps: by way of disclaimer, I work at Cisco.

Regards,

Jeremy Begg

[Javier Henderson]

Post by Jeremy Begg
Thanks for the suggestion, and it's an interesting one, but unfortunately I
have no control over the Cisco equipment which connects these machines to
the Internet. But I'll definitely bear it in mind if that situation
changes!

Can "they" set up the SLB for you? It's really simple. I can even send you
a sample config.

-jav

[Forster, Michael]

For very simple applications would this eliminate the need for a CSM in a Catalyst 6500 configuration?

-----Original Message-----
From: "Javier Henderson" <***@kjsl.org>
To: "info-***@process.com" <info-***@process.com>
Sent: 01/16/08 9:51 PM
Subject: Re: Two IP addresses in same subnet on the one machine

Post by Jeremy Begg
4. Any other suggestions for achieving this? I'd rather not rely on
dynamic
DNS updates because they take too long to propagate and dynamic zones
are
a pain anyway.

If the VMS systems are plugged into Cisco switches running a version of
IOS that supports SLB's, that is an option. The switch presents an IP
address to the world, and dispatches packets to the real servers in one of
various forms. In your case you'd have one machine as preferred over the
other, so only one gets the connections, but if the preferred goes away,
the packets will then start flowing to the secondary system.

The decision of node up/down is based on the results of a probe that you
configure, in your case you were talking about web servers, so you'd
configure a probe to establish a connection to each node's web server
every so often, and upon failure, the corresponding node would be marked
down.

Other switch vendors might have similar features as well.

-jav

ps: by way of disclaimer, I work at Cisco.

[Javier Henderson]

Post by Forster, Michael
For very simple applications would this eliminate the need for a CSM
in a Catalyst 6500 configuration?

It depends. It would be best to talk to your account SE, there are
several factors to keep in mind.

-jav

[Hunter Goatley]

Post by Jeremy Begg
I can see that an immediate benefit of option 1 will be to offer a BIND
resolver on the .15 IP address, something which isn't possible using IP
Cluster Alias (because BIND only binds to interfaces) and which I've wanted
to be able to do for a long time.

Sounds to me like option 1 should work OK.

Post by Jeremy Begg
Also isn't there support in MultiNet for transparently failing over from one
Ethernet port to another in the event of device failure? I can't find
mention of this in the MultiNet V5.2 install & admin guide.

Yes, both MultiNet and TCPware have this feature. It's the paired
network interface support. See the help for MULTINET
SET/INTERFACE/COMMON_LINK, or got to the MultiNet FAQ page and search
for "paired":

http://www.process.com/techsupport/multinet_faqs_page.html

It's also documented in the MultiNet Administrator's Reference.

http://www.process.com/tcpip/mndocs52/ADMIN_REFERENCE/Ch01.htm#E55E57

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@GOATLEY.COM http://www.goatley.com/hunter/

[Michael Corbett]

Post by Jeremy Begg
Hi,
Process Software MultiNet V5.2 Rev A-X, COMPAQ AlphaServer DS20E 666 MHz,
OpenVMS AXP V8.3
For various reasons I'm about to split a VMScluster consisting of two nodes
which boot from the same system disk and MultiNet root directory. Each node
has its own IP address (a.b.c.1 and a.b.c.2) plus they share an IP Cluster
Alias address (a.b.c.15). All addresses are in the same subnet (a range of
31 addresses).
After the split (which will happen in about 48 hours) each machine will be
operating stand-alone with no shared files. However they will be connected
to a shared SCSI bus so that in the event of one machine failing the other
one can take over. (Sort of a "warm" failover ability.) The startup
procedures on both systems are careful not to both mount the same disks
simultaneously!
The purpose of this email is to ask how best to handle the web services which
are currently associated with the IP cluster alias address. The intention
is that the various web sites hosted on these machines will be offered on an
IP address which will be moved from one machine to the other if the
currently active machine fails. (The failover time will be in the realm of
several minutes rather than seconds or hours.)
Each machine has two Ethernet ports. So I have come up with the following
scenarios and I'd like some guidance as to which would be "best".
1. Use one ethernet port as the machines "primary", unchanging ethernet
address i.e. a.b.c.1 or a.b.c.2, depending on the machine. Use the other
ethernet port as the machines "service" address i.e. a.b.c.15. In normal
operation one machine will set this interface /DOWN and other other one
will set it /UP. The failover process will require the newly active
machine to make its second interface /UP, and the failing machine to make
it's /DOWN (although it will probably be down anyway).
2. Similar to the above, but use a pseudo-interface attached to the primary
ethernet port. The pseudo-interface IP address (a.b.c.15) will be marked
/DOWN on one machine and /UP on the other, as before. (The reason for
adopting this approach is to allow the second ethernet interface on each
machine to be used for a "private" network, but I haven't yet decided if
this is necessary for my purposes or even desirable.)
3. Retain the IP cluster alias feature on each machine but take steps to
ensure it's active only on one machine at a time. I suspect the only way
this can be done is to manually ENABLE or DISABLE the CLUSTERALIAS
service and restart the MULTINET_SERVER process. I suppose it might be
done by having a process running on the "inactive" machine which grabs
the relevant VMS lock before MultiNet gets a look-in, but first I'd have
to find out what the lock is.
4. Any other suggestions for achieving this? I'd rather not rely on dynamic
DNS updates because they take too long to propagate and dynamic zones are
a pain anyway.
I can see that an immediate benefit of option 1 will be to offer a BIND
resolver on the .15 IP address, something which isn't possible using IP
Cluster Alias (because BIND only binds to interfaces) and which I've wanted
to be able to do for a long time.
Also isn't there support in MultiNet for transparently failing over from one
Ethernet port to another in the event of device failure? I can't find
mention of this in the MultiNet V5.2 install & admin guide.

Another option would be to something similar to option 2 but using
a Lan failover set. Have one Multinet interface configured to run on
a LAN failover set that contains the two ethernet devices. Then run the
pseudo device with the a.b.c.15 address and set it /UP and /DOWN as
needed.

regards
Mike

[Jeremy Begg]

Hi Michael,

Post by Michael Corbett
Another option would be to something similar to option 2 but using
a Lan failover set. Have one Multinet interface configured to run on
a LAN failover set that contains the two ethernet devices. Then run the
pseudo device with the a.b.c.15 address and set it /UP and /DOWN as
needed.

By "LAN failover set" do you mean MultiNet's common link feature, the one
set up with $ MU SET/INTERFACE/COMMON_LINK=... ?

Thanks,

Jeremy Begg

[Michael Corbett]

Post by Jeremy Begg

Post by Michael Corbett
Another option would be to something similar to option 2 but using
a Lan failover set. Have one Multinet interface configured to run on
a LAN failover set that contains the two ethernet devices. Then run the
pseudo device with the a.b.c.15 address and set it /UP and /DOWN as
needed.

By "LAN failover set" do you mean MultiNet's common link feature, the one
set up with $ MU SET/INTERFACE/COMMON_LINK=... ?

Hi Jeremy,

No, I'm referring to the OpenVMS Lan Failover where multiple
interfaces are grouped into a virtual device. Here is a link that
describes it -

single virtual interface called a LAN Failover set.

regards
Mike

[Jeremy Begg]

Hi Mike,

Appending your last two messages together...

Post by Michael Corbett

Post by Jeremy Begg

Post by Michael Corbett
Another option would be to something similar to option 2 but using
a Lan failover set. Have one Multinet interface configured to run on
a LAN failover set that contains the two ethernet devices. Then run the
pseudo device with the a.b.c.15 address and set it /UP and /DOWN as
needed.

By "LAN failover set" do you mean MultiNet's common link feature, the one
set up with $ MU SET/INTERFACE/COMMON_LINK=... ?

No, I'm referring to the OpenVMS Lan Failover where multiple
interfaces are grouped into a virtual device. Here is a link that
describes it -
http://h71000.www7.hp.com/doc/732FINAL/aa-pv5nh-tk/00/01/119-con.html#cegejebd
single virtual interface called a LAN Failover set.

Thanks! Might come in handy. No doubt more questions to follow before long.

Regards,

Jeremy Begg

[Jim]

Post by Jeremy Begg
Hi,
Process Software MultiNet V5.2 Rev A-X, COMPAQ AlphaServer DS20E 666 MHz,
OpenVMS AXP V8.3
For various reasons I'm about to split a VMScluster consisting of two nodes
which boot from the same system disk and MultiNet root directory.  Each node
has its own IP address (a.b.c.1 and a.b.c.2) plus they share an IP Cluster
Alias address (a.b.c.15).  All addresses are in the same subnet (a range of
31 addresses).
After the split (which will happen in about 48 hours) each machine will be
operating stand-alone with no shared files.  However they will be connected
to a shared SCSI bus so that in the event of one machine failing the other
one can take over.  (Sort of a "warm" failover ability.)  The startup
procedures on both systems are careful not to both mount the same disks
simultaneously!
The purpose of this email is to ask how best to handle the web services which
are currently associated with the IP cluster alias address.  The intention
is that the various web sites hosted on these machines will be offered on an
IP address which will be moved from one machine to the other if the
currently active machine fails.  (The failover time will be in the realm of
several minutes rather than seconds or hours.)
Each machine has two Ethernet ports.  So I have come up with the following
scenarios and I'd like some guidance as to which would be "best".
1. Use one ethernet port as the machines "primary", unchanging ethernet
   address i.e. a.b.c.1 or a.b.c.2, depending on the machine.  Use the other
   ethernet port as the machines "service" address i.e. a.b.c.15.  In normal
   operation one machine will set this interface /DOWN and other other one
   will set it /UP.  The failover process will require the newly active
   machine to make its second interface /UP, and the failing machine to make
   it's /DOWN (although it will probably be down anyway).
2. Similar to the above, but use a pseudo-interface attached to the primary
   ethernet port.  The pseudo-interface IP address (a.b.c.15) will be marked
   /DOWN on one machine and /UP on the other, as before.  (The reason for
   adopting this approach is to allow the second ethernet interface on each
   machine to be used for a "private" network, but I haven't yet decided if
   this is necessary for my purposes or even desirable.)

The following code example, when placed in the MULTINET directory of
each system will execute automatically during MultiNet startup (there
is a hook that invokes xxx_CONFIGURE.COM for each configured
interface). This interface must exist within the MultiNet
configuration. On your primary node you would then include an
invocation of "$ @MULTINET:PD0_CONFIGURE UP" in your system startup
(SYSTARTUP.COM perhaps) somewhere after MultiNet has been started
(this example uses pd0 though it could easily be se1 or whatever). On
your backup system you would execute "$ @MULTINET:PD0_CONFIGURE UP"
interactively or via some "watchdog" process when you want the address
to be active there. "$ @MULTINET:PD0_CONFIGURE DOWN" may be used at
any time to shut down the interface. PING is used to safeguard against
the address being activated on multiple nodes.


$! MultiNet:PD0_Configure.Com !! 'f$verify(0)'
$!
$! Configure network device "pd0"
$!
$ Set :=
$!
$ address := 192.168.0.2
$ mask := 255.255.255.0
$!
$ Set NoOn
$ P1 = F$Edit(P1,"collapse,upcase")
$ If P1 .Eqs. "UP" Then Goto up
$ If P1 .Eqs. "DOWN" Then Goto down
$!
$! PD0 will be configured during system startup be left in a "down"
state
$!
$system_startup:
$ MultiNet Set/Interface pd0 -
/Address='address' -
/IP_SubNet='mask' -
/Protocol=IP -
/Hardware_Device=se0
$ Multinet Set/Interface pd0 /Down
$ Multinet Set/ARP/Delete='address'
$! the following three commands address an issue where the prior "/
Down"
$! command does not reliably set the pd0 interface "down" - we'll
$! just assign it a bogus IP address that will not be routable on the
LAN
$ Multinet Set/Interface pd0 /Address=1.1.1.1
$ Multinet Set/Interface pd0 /Down
$ Multinet Set/Route/Delete=(dest:1.1.1.0,gate:1.1.1.1,netm:
255.255.255.0,inte)
$ exit 1
$!
$!
$up:
$! this code will not be executed during system startup; it exists to
$! provide a mechanism for activating the interface
$ Define/User Sys$Output NL:
$ Multinet Ping/Number=1 'address'
$ If $STATUS .nes. "%X10002094"
$ Then
$ ! status isn't node-unreachable, exit; can't have two nodes with
same address
$ Write Sys$Output "___PD device not activated; IP address already
in use."
$ Exit %x0134
$ Endif
$ MultiNet Set/Interface pd0 -
/Address='address' -
/IP_SubNet='mask' -
/Protocol=IP -
/Hardware_Device=se0
$ Multinet Set/Interface pd0 /Up
$ Multinet Set/Route/add=(dest:'address',gate:127.0.0.1,interface)
$ Define/System/Nolog CHCS_GIS_IP_ADDRESS "''address'"
$ Define/User Sys$Output NL:
$ Multinet Ping/Number=1 'address'
$ Exit '$status'
$!
$! this code will not be executed during system startup; it exists to
$! provide a mechanism for deactivating the PD0 interface
$down:
$ Multinet Set/Interface pd0 /Down
$ Multinet Set/ARP/Delete='address'
$ Multinet Set/Route/Delete=(dest:'address',gate:127.0.0.1,interface)
$ If F$Trnlnm("CHCS_GIS_IP_ADDRESS","LNM$SYSTEM") .NES. "" Then -
Deassign/System CHCS_GIS_IP_ADDRESS
$! the following three commands address an issue where the prior "/
Down"
$! command does not reliably set the pd0 interface "down" - we'll
$! just assign it a bogus IP address that will not be routable on the
LAN
$ Multinet Set/Interface pd0 /Address=1.1.1.1
$ Multinet Set/Interface pd0 /Down
$ Multinet Set/Route/Delete=(dest:1.1.1.0,gate:1.1.1.1,netm:
255.255.255.0,inte)
$ exit 1