- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Retreiving IP Address
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2007 05:43 AM
тАО07-19-2007 05:43 AM
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 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2007 06:05 AM
тАО07-19-2007 06:05 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2007 07:06 AM
тАО07-19-2007 07:06 AM
Re: Retreiving IP Address
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,
Password:
prompt, an answer,
(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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2007 12:16 PM
тАО07-19-2007 12:16 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-20-2007 04:33 PM
тАО07-20-2007 04:33 PM
Re: Retreiving IP Address
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-23-2007 09:52 AM
тАО07-23-2007 09:52 AM
Re: Retreiving IP Address
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-24-2007 03:56 PM
тАО07-24-2007 03:56 PM
Re: Retreiving IP Address
Is there a case number to reference if someone else with a support contract wants to request the TCPIP$TN_SHOW program?
Jon
- « Previous
-
- 1
- 2
- Next »