The machine refuses the connection when called as virtual IP

[Enrico Venturi]

Hi all,
one node of my HP MC/SG cluster doesn't work properly anymore!
When I telnet on it by using the physical IP, it's OK!
When I ping it by using the physical IP, it's OK!
When I ping it by using the virtual IP it's OK!
When I telnet on it by using the virtual IP the answer is: telnet: Unable to connect to remote host: Connection refused.

What is the reason???

Thanks a lot!
Enrico

[Claude Fortin]

Is your virtual IP is on the same network?

[Enrico Venturi]

Yes,
the really strange topic is that this cluster properly worked since a long time (1 year) ....

the physical address is 139.54.19.17; the virtual IP is 139.54.19.34

I kindly remind that *the ping works fine*

[Sanjay_6]

Hi,

Your virtual ip may be sitting behind a firewall. If there is a firewall it may allow ping but will block telnet is not allowed.

Hope this helps.

Regds

[Enrico Venturi]

Unfortunately there isn't any firewall .......

[Christopher Caldwell · Accepted solution]

-Try to telnet to the virtual on host A from host A - see what you get.

-Try removing the virtual IP (cmmodnet or ifconfig) and re-adding it.

-Look at the arp table on hosts on the same network (routers and servers) to verify that an arp entry maps to the virtual IP

router (cisco) > show arp

server (hp) > arp -a

Let us know your results.

[Steven Gillard_2]

You will get the connection refused message if you try to telnet to a machine that does not run the telnet server, for example an NT system or if inetd was down. Given that the "real" ip responds to telnet its very strange that the "virtual" ip doesn't. So I have to ask - are you sure that the virtual IP definitely refers to the same system you are able to telnet to?

What do the following report (you'll need to run these on a machine on the same subnet):

# arp
# arp

Are the physical addresses returned the same?

Regards,
Steve

[Mark van Hassel]

Hi,

Did you create/change /var/adm/inetd.sec ?

Are you sure that inetd is running ?

[George_Dodds]

Where are you telneting from is it a pc?
If it is from an terminal emulation s/w, the problem could be that it has not closed an old telnet connection properly from the emulation s/w itself.

I've had this once or twice, just restart the t/e software usually does the trick.

Regs

George

[Enrico Venturi]

On a node being able to telnet on the physical IP but not on the virtual IP:

#arp phy_IP --> OK (a result is provided)
#arp virt_IP --> -- no entry

concerning another MC/SG node on the same network:

#arp phy_IP_1 --> OK (a result is provided)
#arp virt_IP_1 --> -- no entry

but in this second case the telnet on the virt_IP_1 works fine!!

It seems to NOT be any relations between the arp and the capability to telnet on a virtual IP

[Christopher Caldwell]

1) For virt IPs on host A (virt or primary), host B (on the same IP network) should produce an arp entry for each IP on host A mapped to the same ethernet address on host A

A.you.com (1.2.3.4) at 0:10:83:ee:bb:f8 ether
virtB.you.com (1.2.3.5) at 0:10:83:ee:bb:f8 ether

2) arp entries expire, so before running an arp command, ping physical IP and/or virt IP to make sure the arp entry gets into the arp table.

If you're missing an arp entry after 1) and 2), IP should be somewhat broken.

You can get SeviceGuard or the kernel to re-arp by using cmmodnet or ifconfig down/up respectively.

[Sanjay_6]

Hi,

Are you able to trace route to the virtual ip.

do this from one of the nodes,

/usr/contrib/bin/traceroute virtual_ip_add

If you are using a winnt workstation i think the nt command "tracert" might help.

Hope this helps.

Regds

[Enrico Venturi]

Some little step to the solution, I hope!

Now,
#arp phys_IP
0:8:c7:69:3d:45 ether

#arp virt_IP
0:10:83:ff:7b:a1 ether

the MAC addresses are NOT the same!

if i check on another (properly working) MC/SG node I get the same values.

What's now?

[Christopher Caldwell]

Your diagnostic tells me that the IPs aren't bound to the same ethernet interface.

If the arp entries aren't the same AND the IPs are supposed to be bound to the same LAN interface, then someone has usurped/misconfigured/stolen your virt IP and added it against a different ethernet card.

If that card is on the same host, things should work fine. If the card is on a different host, perhaps the configuration (inetd.conf or inetd.sec) doesn't allow telnet.

Either way, it sounds like something is amiss in the configuration.

Figure out which host/NIC card maps to the ethernet address of your virt IP.

BTW, it could that your virt IP moved with the SG package, so you may be looking at correct behavior in IP, but the primary host and the failover host may be configured differently as far as telnet is concerned.

[John Waller]

I personally suspect the old favorite is at fault here. Somebody has decided to use 139.54.19.34 on another device so you have a duplicate IP situation. 0:10:83:ff:7b:a1 does not sound like a MAC address from an HP machine. To confirm, try cmhaltpkg then try to ping your virtual IP address. If it responds then you know its a duplicate

[Christopher Caldwell]

Actually
0:10:83:ff:7b:a1
is in the neighborhood of L class boxen we've been buying lately.

[Enrico Venturi]

For sure it's a duplicated IP address: I can ping the node even if the package is down!!

But I did a little mistake on a previous message: the MAC address on which the virtual IP is mapped is:
00:08:C7:69:3D:45

We have to look for the device hosting this MAC address ... PC? HP? SUN?

[Christopher Caldwell]

0008C7 Compaq

[Eugen Cocalea]

Hi,

Seems like somebody uses your IP.

Anyway, to detect who's using, don't go from workstation to workstation to look for it, just cut all the trafic for that machine in the firewall and the user will show up.

My first thought was that telnet was bound only on the physical IP, some servers will only answer on the IP you said them to and will not answer to requests on any other IP, even if they are coming on the same physical interface.

E.

[Enrico Venturi]

The problem is going to be solved: I need just to find which is the intruder :-) (it's not so simple because I try to solve from Rome a problem happening in Paris).

My best thanksgiving to Christoper Caldwell who gave me the proper suggestions to find the solution.

Season's Greetings and Happy New Year.

Enrico

[John Waller]

Just a bit advice to help you track down this rogue device. You need to remember the device in question is not running a telnetd so it is unlikely (though not impossible) that it is a server, router or managed switch, but more likely to be a Windows PC or other basic networked device which cannot be accessed remotely.