1748066 Members
5231 Online
108758 Solutions
New Discussion юеВ

Retreiving IP Address

 
SOLVED
Go to solution
Jon Pinkley
Honored Contributor

Re: Retreiving IP Address

Re: Hoff's comment "packets arriving via one of the alias addresses of a NIC will be sent with the primary address of the NIC."

We aren't using the multi-IP address per NIC feature, but if it works as Hoff says, I cannot see how it would possibly work. How would a TCP connection ever be established to one of the secondary addresses?

I would expect it to work in a similar way to a secondary address on a Cisco router. Packets sent in response to connections established by other nodes would use the IP address that was connected to.

I am not sure what Jack's intentions are, but I wanted to do the same thing a long time ago, before it was possible to have multiple IP addresses on a single NIC.

Here's the scenario we wanted to address. We had an Executive Information System on the cluster. We wanted people to be able to connect to "EIS" and have sys$sylogin detect that they wanted to enter the executive friendly menu. With LAT we were able to do this with multiple service names. sys$sylogin had a program that could detect the LAT service that was connected to, and if it was EIS, they never see a DCL prompt. When we migrated off LAT, there was nothing that corresponded to that functionality. We thought of two possible workarounds, but were not able to get either to work (this was 15 years ago at another job). First thought was to somehow allow for telnet connections to multiple TCP ports in addition to the standard port 23, with the idea that we would determine the port, and therefore the "service" they were connecting to. The second was to allow multiple IP addresses, one for each service on each node, and to use DNS to forward to one of the proper addresses for that service. We would have then needed to be able to determine the IP address connected to, and determine the "service" by reverse DNS lookup.

In the end we just let login.com do different things for different users.
it depends
Hoff
Honored Contributor

Re: Retreiving IP Address


>>>We aren't using the multi-IP address per NIC feature, but if it works as Hoff says, I cannot see how it would possibly work. How would a TCP connection ever be established to one of the secondary addresses?<<<

I'd expect this is a feature of TCP connections and routing; numbers of IP hosts and addresses can be involved in a TCP connection, after all. Intermediate nodes don't care where a packet goes.

BTW, the IP address behavior with alias IP addresses is directly out of the TCP docs.
Jan van den Ende
Honored Contributor

Re: Retreiving IP Address

Jack,

I am not sure if our solution is possible in your situation, but anyway, here it is:

For one application (further details graciously left out, but is implemented as a VERY simple screen-scraper) we absolutely NEED a strict sequence of a
Uername:
prompt, an answer, and a
Password:
prompt, an answer, , and then the application announcement text.
(all system output also at fixed positions).

Fancy that with thousends of incomimg sessions, only a tiny fraction for this app.

We implemented it by directing this app at a specific service in the firewall, and NATing this service back at the VMS cluster, but "spoofing" the source address to be something specific.
Now in SYS$SYLOGIN if the source node was this special dummy source, AND the user held he appropiate identifier, then we would directly jump to the app.
We DID have to educate the users of this app, that if it did not work, they first enter any other VMS app; and change their password, or read all their new mail, or resolve ANY issue that would interfere with the "EXPECTed" sequence....

Hoping to have been of some use,

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Doug Phillips
Trusted Contributor

Re: Retreiving IP Address


In the end we just let login.com do different things for different users.


In the past I've used the UIC group to segregate user groups, and had something like this in sylogin.com:

$ GRP = F$GETJPI ("","GRP")
$ GROUP_LOGIN = "LOGINGRP" + F$STRING(GRP) + ".COM"
$ if f$search(GROUP_LOGIN) .NES. "" THEN @'GROUP_LOGIN'

to define various special logicals and symbols. An individual user could have even more specific def's in his/her login. Also had an option in the menu system that would allow users with higher priv's to get to the $ but keep everyone else captive.

I've used rights ID's in a similar way; usually presenting a default UI if the user doesn't hold a right, and some special UI if s/he does.

If the problem is to identify which network a user is on to segregate the users, then maybe using a similar method would work better than hard-coding IP's and having to worry about changing the code if a NIC gets replaced.

Another benefit to making things more "user" rather than "site" specific, is if a person goes to the other site and logs in he'll get a familiar UI. Of course, there could be a security down side to this, too.

Not knowing the goals, YMMV
Jon Pinkley
Honored Contributor

Re: Retreiving IP Address

After unsuccessfully trying to find the documentation about behavior of alias addresses, I did configure a several alias ip address on one of our nodes, and they appear to me to work like a secondary address on a Cisco router.

The following examples are from my testing.

Configuration tested on.

$ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4
on a AlphaServer 2000 4/233 running OpenVMS V7.3-2

$ tcpip sho interface
Packets
Interface IP_Addr Network mask Receive Send MTU

LO0 127.0.0.1 255.0.0.0 1179 1179 4096
WE0 206.157.122.24 255.255.255.0 5152457 34676 1500
$ netstat -n "-I" we0
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
WE0 1500 aa:0:4:0:17:4 5152522 0 34685 0 0
WE0 1500 206.157.122/24 206.157.122.24 5152522 0 34685 0 0
WE0 1500 172.30.200/21 172.30.200.24 5152522 0 34685 0 0
WE0 1500 172.30.200/21 172.30.207.24 5152522 0 34685 0 0
WE0 1500 172.30.200/21 172.30.207.23 5152522 0 34685 0 0
WE0 1500 206.157.122/24 206.157.122.23 5152522 0 34685 0 0
$

Specifically, output packets in response to a connection to an alias use the alias address as the source. This is true even if the alias is in the same network as the the primary.

Specific examples using telnet from ohter hosts to connect to system with telnet.(packets sent in response by local system)

Dst Address Src Address used.
206.157.123.74 172.30.207.23 (response to telnet client at 206.157.123.74 connecting to 172.30.207.23)
206.157.123.74 172.30.207.24 (response to telnet client at 206.157.123.74 connecting to 172.30.207.24)
206.157.123.74 172.30.200.24 (response to telnet client at 206.157.123.74 connecting to 172.30.200.24)
206.157.123.74 206.157.122.24 (response to telnet client at 206.157.123.74 connecting to 206.157.122.24)
206.157.123.74 206.157.122.23 (response to telnet client at 206.157.123.74 connecting to 206.157.122.23)

Note in every case the NIC uses the IP address that was connected to. This is a requirement for a tcp connection establishment three-way-handshake to work. Otherwise the node attempting the connection will receive a response from a different ip address than was connected to, and it will be ignored. NAT in between systems can make the addresses different, but from the perspective of the node establishing the connection, the IP address that sends the SYN,ACK must he identical to the IP address that the SYN packet was sent to.

Google "tcp connection handshake" and you will find plenty of info about how this all works.

The following is an example showing what the local system displays when a telnet connection from 206.157.123.74 was made to the alias address 172.30.207.23.

The following is output extracted from SDA> tcpip show dev tna31/full

Terminal TNA31: service type None, protocol Telnet
Network Device: (not connected)
Accessportname: Host: B24RTR1L Locn:
Remote address: 206.157.123.74 port 24082
Local address: 172.30.207.23 port 23



For outbound connections, the source address used appears to be the one of the following:

1. To a connected network (one for which the NIC has at least one address in) the ip address will be the IP address from that network that was the first one configured on the interface. Note that this can be an alias address.

Specific examples

Dst Address Src Address used.

206.157.122.1 206.157.122.24 (Connected network, network 206.157.122.0/24, primary IP used)
172.30.200.1 172.30.200.24 (Connected network. network 172.30.200.0/21, first configured in network used)

2. To an address that is not on a connected network, the primary address will be used as the source.

Specific examples follow, using telnet from system.


Dst Address Src Address used.

172.30.24.1 206.157.122.24 (non-connected network, primary IP used)

I am attaching a logfile with the traces captured using ethereal showing the three-way-handshake with the primary address and one of the alias addresses.
it depends
Jack Trachtman
Super Advisor

Re: Retreiving IP Address

Thanks for all the input.

I contacted HP and found out two things:

1) The reason that Location is returned instead of Port# sometimes is that VMS requests it from clients and if that info is returned it is displayed to help locate the client for security issues

2) Other people besides myself have requested this info, so someone at HP has written a pgm just to get the info. Below is an example of usage in case anyone else would find it useful:

$ getipinfo:==$home:TCPIP$TN_SHOW.EXE_AXP;1
$ getipinfo tna1185:
Local address: 172.20.66.43, port: 23
Remote address: 172.20.69.184, port: 1821
$ sho sym tcpip$tn*
TCPIP$TN_LOCAL_ADDRESS = "172.20.66.43"
TCPIP$TN_LOCAL_PORT = "23"
TCPIP$TN_REMOTE_ADDRESS = "172.20.69.184"
TCPIP$TN_REMOTE_PORT = "1821"
Jon Pinkley
Honored Contributor

Re: Retreiving IP Address

Jack,

Is there a case number to reference if someone else with a support contract wants to request the TCPIP$TN_SHOW program?

Jon
it depends