npi Device ???

[John Harper (Barbour)]

We are running VMS 8.3 on Alpha 4100. TCP/IP version 5.6

Users connect using Poweterm or Kea via telnet.

Normally SHOW USER/FULL shows a terminal device on TNAnnnn plus a transation similar to
(Host: ukws0015.barbours.local Port: 3292)

However one user is showing a transation of
(Host: npi1b2e68.barbours Port: 3291)

Can anyone tell me what the "npi" reference means.

The only reference to npi I can find is from a webpage about HP Procurve switches (which we use) but this would be too weird.

Many thanks,

John

[Oswald Knoppers_1]

It must be a name in your hosts file or your local DNS.

Try:

$ tcpip show host npi1b2e68.barbours

This should give you the IP adres.

Oswald

[Hoff]

Though you likely already know this, the translation here is the reverse DNS (rDNS) entry for the originating host. OpenVMS takes the arriving IP address and asks its own assigned DNS server about the IP host name associated with the arriving IP address.

This could well be the ProCurve, too. That would make sense, if you have a ProCurve that is configured to provides DHCP and such, and it's not particularly integrated into the local DNS.

If you want to investigate further, you can

@sys$startup:tcpip$define_commands

Then

dig -x w.x.y.z

and

dig host.name

for a reverse (rDNS) translation and a forward DNS translation, respectively.

Seeing the .local TLD assigned makes some sense for a no-DNS or a very small network environment, but I'd tend to expect a DNS server and a real domain name in a moderate to large environment. (The .local TLD is usually assigned as part of mDNS networks (Bonjour / zeroconf, Microsoft, et al.)

Your question here is likely better asked of your own (no-dot) local network folks, and of your Windows client managers. We can help you poke around in your network, but your own networking folks are best resources.

[John Harper (Barbour)]

Many thanks for your replies.

Oswald, nice try, but all I get is

%TCPIP-W-NORECORD, information not found

Perhaps I should have made it clear that the two host translations come from two sessions from the same PC at the same time.

Hoff, this sounds feasable. We've recently had some procurves installed and I'm not convinced they are properly configured.

As far as talking to the windows networking people, I'm afraid we're one and the same and all were equally perplexed.

[Oswald Knoppers_1]

Could it be that these switches dynamicly register these addresses in DNS

(I don't know ProCurve)

Oswald

[Hoff]

The usual trigger here is how the DHCP box (ProCurve or otherwise) is configured to coordinate with the (I presume) Microsoft Active Directory (AD) that is at the core of your network.

If you use AD, start reading the KBs. Such as:

http://technet.microsoft.com/en-us/library/cc781697(WS.10).aspx

And read the ProCurve manual for whichever box this is.

I'd offer to look at this (from your New England outpost) but (presuming AD) this case looks to fall squarely in the realm of a Microsoft AD configuration question. And I prefer to use other boxes in place of the Microsoft AD and the Microsoft DNS implementations.

[Hoff]

>Perhaps I should have made it clear that the two host translations come from two sessions from the same PC at the same time.

That implies some issues of skewing within the local DNS configuration.

Start tossing dig commands at your DNS servers, and trace this back. (I still don't know enough about your configuration to be sure. This whether AD or DNS or otherwise. I'm most definitely guessing here.)

It might pay dividends to look toward how you want this DNS and AD and related pieces to work together, rather than troubleshooting how you want this case to work, too. (Sometimes, working the whole network toward a goal can be easier and more budget-efficient than is chasing the individual malfunctioning pieces in a more ad-hoc network configuration.) Make sure what you currently have configured here works the way you want for your budget and your configuration. I've certainly been involved in more than a few networks that have, um, grown sans sufficient design oversight. And then spent more than a few weekends shifting to more capable or more appropriate or more cost-effective configurations.

[John Harper (Barbour)]

Thanks again.

It's now looking like a problem with DNS right enough. I tried a ping -a of the npi device from windows and I got an ip address od a HP printer returned. Sure enough, npi1b2e68 is the host name of a laser printer in our warehouse.

Given my limited knowledge of windows, I think a good reboot of the DC might be in order.

Hoff, I'm mighty impressed you know of our New England outpost ...

[John Harper (Barbour)]

"grown sans sufficient design oversight." sounds like a perfect description of our network.

[Hoff · Accepted solution]

Ensure that the DHCP pool of IP addresses being served here doesn't overlap the pools of any existing (other) DHCP servers, or of any existing static IP allocations. That alone can play havoc with IP network routing.

[Colin Butcher]

It sounds like a DHCP server address range overlap, which has ended up incorrectly updating some records in a dynamic DNS server.

It's worth ensuring that all the DHCP servers hand out unique non-overlapping address ranges with consistent DNS / gateway etc. information. It's also worth ensuring that your internal dynamic DNS servers (which may well be the same machines) are consistent across the internal network (along with your HOSTS files if they get used too).

I generally ensure that all non-client devices have fixed IP addresses - so that's your printers, network hardware, Windows servers, VMS servers, etc. You can either set those devices up manually, or arrange for your DHCP servers to statically tie specific MAC addresses to specific IP addresses, but still provide the information for the default gateway, DNS servers and so on. That latter method can make it easier to view the entire addressing scheme and to make changes that then get propagated to all DHCP clients when a machine boots or renews its DHCP lease.

For devices that don't need to talk to the 'net, or which don't need to refer to DNS names for devices other than themselves (printers, network equipment etc.), then it simplest to set them up manually. However, do remember to record the allocated addresses somewhere - and make sure they're not in the address range for DHCP assigned addresses.

A good general principle is to start the DHCP allocated addresses at the bottom of the address space and go up (eg: 10.51.42.1 to 10.51.42.149) and to start other devices at the top and come down (eg: 10.51.42.254 as the default gateway, 10.51.42.249 to 10.51.42.230 as network devices, 10.51.42.229 to 10.51.42.200 as printers, 10.51.42.199 to 10.51.42.150 as servers and other devices in need of static IP addresses).

Of course, most networks grow over time (or merge every so often) - which is why a structure to allocate names and addresses is the first thing you should design - and it should allow sufficient space and flexibility to expand without having to go back and change it.

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

[John Harper (Barbour)]

Many thanks for all your help.

DHCP was getting confused because a consultant installed a printer for testing with an address right in the middle of the DHCP range.

We install printers with fixed addresses of xxx.xxx.xxx.201 and upwards. The consultant assigned an address of xxx.xxx.xxx.113 which really confused things. We moved the printer so a "proper" address and everything seems fine.

If only he had asked first ...

[John Harper (Barbour)]

All fixed so once again, thanks.

John