route issue, (unable to login) (916 Views)
Reply
Super Advisor
Posts: 565
Registered: ‎12-10-2003
Message 1 of 13 (916 Views)
Accepted Solution

route issue, (unable to login)

Hi All!

 

Please I wonder if you can help me:

 

I have C7000 chassis with 5 blades on it, four of the blades I can access them from my pc/laptop, but one is not allowing me to do so. The only way I can login to this particular one is by connecting to any of the other 4 blades, and from there telnet it to the strange one.

I have done the following:

 

1. check /etc/inetd.conf for line:

ftp          stream tcp6 nowait root /usr/lbin/ftpd     ftpd -l

 in all servers are the same

2. check /etc/services for the following line:

ftp           21/tcp                 # File Transfer Protocol (Control)

 which is also the same for all the blades

 

3. the routing table in all of them including the one which is inaccessible is the same in all blades, so the default gateway is the same for all the blades

 

4. I have run the following command:

netstat -an | grep 21 | grep -i listen
tcp        0      0  *.2121                 *.*                     LISTEN
tcp        0      0  *.21                   *.*                     LISTEN

 

 

5. I am also able to ping the blade

 

So I am almos run out of options, please can you help?

 

 

NDO

 

Honored Contributor
Posts: 6,271
Registered: ‎12-02-2001
Message 2 of 13 (889 Views)

Re: route issue, (unable to login)

First: what protocol are you using for logins? SSH, telnet, remsh, rlogin, other?


FTP is for file transfers only. Command line logins are done with other protocols. You can be allowed to use FTP but not have a login shell access, or vice versa.

 

SSH uses port 22, telnet uses port 23, rlogin uses 513 and remsh uses 514.

 

Is there a network firewall between your PC and the blade? If there is a firewall, ask the firewall administrator if the access for the appropriate login protocol has been allowed for all 5 blades, or just 4 of them.

MK
Super Advisor
Posts: 565
Registered: ‎12-10-2003
Message 3 of 13 (883 Views)

Re: route issue, (unable to login)

Hi

 

I am using putty (ssh) to connect. 

 

The blade was accessible until a reboot was performed a day , and ever since we no longer able to connect. there is no firewall between my pc and the server... and I am able to connect to the other 4 blades on the same network.

does it have to do with the fact when adding a route you have to specify what type of network is? like

 

route add net "network host ip" netmask "255.255.255.0 "gateway" 1

Advisor
Posts: 21
Registered: ‎09-01-2013
Message 4 of 13 (879 Views)

Re: route issue, (unable to login)

Hi NDO,

 

Please add the default route with route add

 

check your /etc/rc.config.d/netconf file.

 

-madhu

Super Advisor
Posts: 565
Registered: ‎12-10-2003
Message 5 of 13 (871 Views)

Re: route issue, (unable to login)

the default route is already there in the file netconf:

 

 #netstat -nr
Routing tables
Destination           Gateway            Flags Refs Interface  Pmtu
127.0.0.1             127.0.0.1          UH    0    lo0       32808
10.1.20.32            10.1.20.32         UH    0    lan1      32808
10.100.0.0            10.1.20.100        UGH   0    lan1       1500
10.1.20.0             10.1.20.32         U     2    lan1       1500
10.0.0.0              10.1.20.32         U     0    lan1       1500
127.0.0.0             127.0.0.1          U     0    lo0       32808
default               10.1.20.1          UG    0    lan1       1500

 

ROUTE_DESTINATION[0]=default
ROUTE_MASK[0]=""
ROUTE_GATEWAY[0]="10.1.20.1"
ROUTE_COUNT[0]=""
ROUTE_ARGS[0]=""
ROUTE_SOURCE[0]=""
ROUTE_SKIP[0]=""


ROUTE_DESTINATION[1]="10.100.0.0"
ROUTE_MASK[1]=""
ROUTE_GATEWAY[1]="10.1.20.100"
ROUTE_COUNT[1]=""
ROUTE_ARGS[1]=""
ROUTE_SOURCE[1]=""
ROUTE_SKIP[1]=""

ROUTE_DESTINATION[2]="10.1.20.0"
ROUTE_MASK[2]=""
ROUTE_GATEWAY[2]="10.1.20.32"
ROUTE_COUNT[2]=""
ROUTE_ARGS[2]=""
ROUTE_SOURCE[2]=""
ROUTE_SKIP[2]=""
mcelVMhost4[296]/ #

 

Advisor
Posts: 21
Registered: ‎09-01-2013
Message 6 of 13 (868 Views)

Re: route issue, (unable to login)

Hi,

 

Do you have old nickel output to compare the difference in network configuration ?

 

-madhu

Super Advisor
Posts: 565
Registered: ‎12-10-2003
Message 7 of 13 (860 Views)

Re: route issue, (unable to login)

Hi

 

No. I dont have it, but these systems are relatively new, they were recently installed (O.S.) in fact this no DB or APP is installed on that one (inaccessible)

Advisor
Posts: 21
Registered: ‎09-01-2013
Message 8 of 13 (853 Views)

Re: route issue, (unable to login)

after making telnet session,check sshd is running properly or not ?

 

hope so you are trying to login by using ssh.

 

-madhu

Honored Contributor
Posts: 6,271
Registered: ‎12-02-2001
Message 9 of 13 (847 Views)

Re: route issue, (unable to login)

Your lan1 network interface might be configured with an incorrect netmask.

 

This line of "netstat -nr" output indicates that lan1 might be currently operating with a default A-class netmask of 255.0.0.0:

10.0.0.0              10.1.20.32         U     0    lan1       1500

 Since you currently have other routes with a ROUTE_DESTINATION of 10.100.0.0 and 10.1.20.0, a netmask of 255.0.0.0 would seem to be incorrect: it would effectively mean "this system can access all 10.*.*.* IP addresses without using a gateway, unless there is a specific route telling otherwise."

 

If the traffic between the blade and your laptop must go through the gateway, and your laptop also has a 10.*.*.* IP address, this would definitely be the problem.

 

Your default route definition looks OK; however, the two other route definitions are missing the appropriate ROUTE_MASK, and the ROUTE_DESTINATION value should be prefixed with either "net" or "host" keyword.

 

Please run "netstat -nrv" on the blade with the problem, and also on one of the good blades, and compare the outputs.

Also run "ifconfig lan1" on the blade with the problem, and on one of the good blades, and compare the netmask values.

 

The -v option is important with the netstat command, since the route netmask field will not be displayed without it - and with modern networks, the netmasks are usually very important.

MK
Super Advisor
Posts: 565
Registered: ‎12-10-2003
Message 10 of 13 (837 Views)

Re: route issue, (unable to login)

Hi Matti

 

Thank you very much, you were spot on, I run your commad on the blade with the issue:

mcelVMhost4[296]/ #netstat -nrv
Routing tables
Dest/Netmask                    Gateway            Flags Refs Interface  Pmtu
127.0.0.1/255.255.255.255       127.0.0.1          UH    0    lo0       32808
10.1.20.32/255.255.255.255      10.1.20.32         UH    0    lan1      32808
10.100.0.0/255.255.255.255      10.1.20.100        UGH   0    lan1       1500
10.1.20.0/255.255.255.0         10.1.20.32         U     2    lan1       1500
10.0.0.0/255.255.255.0          10.1.20.32         U     0    lan1       1500
127.0.0.0/255.0.0.0             127.0.0.1          U     0    lo0       32808
default/0.0.0.0                 10.1.20.1          UG    0    lan1       1500

 then I run the same command on another blade with no issue:

mcelVMhost3[322]/ #netstat -nrv
Routing tables
Dest/Netmask                    Gateway            Flags Refs Interface  Pmtu
127.0.0.1/255.255.255.255       127.0.0.1          UH    0    lo0       32808
10.1.20.31/255.255.255.255      10.1.20.31         UH    0    lan1      32808
10.1.20.0/255.255.255.0         10.1.20.31         U     2    lan1       1500
10.100.0.0/255.255.0.0          10.1.20.100        UG    0    lan1       1500
127.0.0.0/255.0.0.0             127.0.0.1          U     0    lo0       32808
192.168.0.0/255.255.254.0       10.1.20.100        UG    0    lan1       1500
default/0.0.0.0                 10.1.20.1          UG    0    lan1       1500
mcelVMhost3[323]/ #

 

So I found out the route to 10.100.0.0 had a wrong netmask, so I deleted that route insert the same route but with correct netmask, and no its fine.

Thank you very much

Honored Contributor
Posts: 6,271
Registered: ‎12-02-2001
Message 11 of 13 (830 Views)

Re: route issue, (unable to login)

Did you also fix the route specification in /etc/rc.config.d/netconf?

 

Any settings you make with the "route" command won't be persistent over a system reboot: if you don't fix your netconf file, the configuration error will come back at next reboot.

 

Based on the "netstat -rnv" output from the good blade, this is how the netconf route specification should be:

ROUTE_DESTINATION[1]="net 10.100.0.0"   # note: "net" keyword added
ROUTE_MASK[1]="255.255.0.0"                  # note: netmask added
ROUTE_GATEWAY[1]="10.1.20.100"
ROUTE_COUNT[1]="1"                               # note: the count value is needed for routes to remote networks
ROUTE_ARGS[1]=""
ROUTE_SOURCE[1]=""
ROUTE_SKIP[1]=""

 

This route specification looks bad too:

ROUTE_DESTINATION[2]="10.1.20.0"
ROUTE_MASK[2]=""
ROUTE_GATEWAY[2]="10.1.20.32"
ROUTE_COUNT[2]=""
ROUTE_ARGS[2]=""
ROUTE_SOURCE[2]=""
ROUTE_SKIP[2]=""

 If is missing the net/host keyword and the ROUTE_COUNT value, and if it is supposed to be a network route, the ROUTE_MASK is missing too.

Also, the ROUTE_GATEWAY IP address seems to be the blade's own IP address: this route should be automatically generated if the SUBNET_MASK parameter in the ifconfig settings is correct.

So I don't see why this route entry should be configured at all!

 

Another thing I'm wondering about: your "bad" blade has this route entry, and the "good" blade does not have anything equivalent:

10.0.0.0/255.255.255.0          10.1.20.32         U     0    lan1       1500

If this is the auto-generated route for the network segment your lan1 is plugged into, then I think there may be a missing or incorrect SUBNET_MASK setting in your /etc/rc.config.d/netconf file.

 

Based on the configurations you've posted so far, I think the interface settings for lan1 in the netconf file should be like this:

INTERFACE_NAME[0]=lan1
IP_ADDRESS[0]=10.1.20.32
SUBNET_MASK[0]=255.255.255.0   # <-- Please check this one carefully.
BROADCAST_ADDRESS[0]=10.1.20.255  # <-- if SUBNET_MASK was wrong, this may be wrong too.
INTERFACE_STATE[0]=up
DHCP_ENABLE[0]=0

 

MK
Super Advisor
Posts: 565
Registered: ‎12-10-2003
Message 12 of 13 (825 Views)

Re: route issue, (unable to login)

Hi !

 

 

yes I did update on /etc/rc.config.d/netconf file, and I have also deleted the 10.0.0.0 entry in the routing table, what I am not sure now is if the current netmask on the ip address (10.1.20.32) is indeed:

 

#netstat -nrv
Routing tables
Dest/Netmask                    Gateway            Flags Refs Interface  Pmtu
127.0.0.1/255.255.255.255       127.0.0.1          UH    0    lo0       32808
10.1.20.32/255.255.255.255      10.1.20.32         UH    0    lan1      32808

 

 

or:

 

INTERFACE_NAME[2]="lan1"
IP_ADDRESS[2]="10.1.20.32"
SUBNET_MASK[2]="255.255.255.0"
BROADCAST_ADDRESS[2]=""
INTERFACE_STATE[2]="up"
DHCP_ENABLE[2]="0"
INTERFACE_MODULES[2]=""

 

So I have used an IPcalculator/IP subnetting tool found in the internet that is telling me that its the latter one. So I dont know if I should delete that entry in the routing table and reboot the server, just to check if comes up with all entries ok.

 

Honored Contributor
Posts: 6,271
Registered: ‎12-02-2001
Message 13 of 13 (811 Views)

Re: route issue, (unable to login)

For each network interface (including loopback and IP aliases), there should be a minimum of 2 lines in HP-UX routing table:

  • a line with the interface's own IP address in both the destination & gateway fields, netmask 255.255.255.255 and a high MTU value. This indicates the server can "talk to itself" without MTU restrictions, as the traffic is simply looped back in the protocol stack without using the physical network interface at all. This line should have "UH" in the Flags field.
  • a line with a network address and netmask matching the IP segment the interface is connected to, with the interface's own IP in the gateway field. This indicates a network segment that is directly accessible, with the proper MTU value. This line should have "U" in the Flags field.

These two are automatically generated standard entries and they should not normally be deleted.

 

Additionally, there should usually be only one default gateway entry, even if the server has multiple network interfaces.

If the server has no Internet access and the network is very simple, there might be no default gateway entry at all.

 

Two or more default gateway entries may be required in some special situations, but it is much more probably a mistake.

 

Any other lines in the routing table are custom and completely depend on the network the server is in.

MK
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.