- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: route issue, (unable to login)
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
тАО10-17-2013 01:07 AM
тАО10-17-2013 01:07 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-17-2013 02:02 AM
тАО10-17-2013 02:02 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-18-2013 08:09 AM
тАО10-18-2013 08:09 AM
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.
- « Previous
-
- 1
- 2
- Next »