network interface names are inconsistent

[Scott Conrad]

Hi,

(2nd attempt to post--apologies if this is a repeat.)

I have a long-winded question on configuring the network interface under HP-UX 11.11. The OS reports different (but overlapping) interface names for the network interfaces and I'm hoping that someone can point me to the solution. To illustrate the problem, I'm including the output of some system calls as well as the output of a proprietary utility called "hpuxget" which (with the arguments provided) prints out the number of output packets sent on the interface (o1=) and a percentage of the packets that failed because of collisions. If an error occurs, the percentage is reported as -1.

To access the number of output packets, hpuxget calls get_logical_stat(), which is part of the NM API. I can't reference documentation for the NM API because I can't find any. However, the relevant portion of the sys/mib.h is:

/*
* Structure Defintion for the get_logical_stat() NM api call
*/
typedef struct {
char nm_device[MAX_PHYSADDR_LEN]; /* interface name, e.g. "lo0", */
/* "lan0", "lan0:1", etc. */
u_int ifindex; /* ifIndex assigned to this interface */
ip_addr netaddr; /* IP Address */
u_int in_packets; /* Number of IP inbound packets */
u_int out_packets; /* Number of IP outbound packets */
} nmapi_logstat;

get_logical_stat() returns an array of nmapi_logstat structs, which are then matched by interface name (nm_device) to find the counters for the specified interface.

# hpuxget "UX Networking" %Collision lan0
o1=228935820 0.000000

# hpuxget "UX Networking" %Collision lan1
net interface 'lan1' not found in following list:
0: 'lan0'
1: 'lan2'
-1.000000

['lan0' and 'lan2' are the content of the two nmapi_logstat struct's nm_device fields.]

o1=52003 0.000000

# netstat -i
Name Mtu Network Address Ipkts Opkts
lan1 1500 10.86.200.0 datasfa 110226187 228938672
lan0 1500 (omitted) (omitted) 53114 52003
lo0 4136 127.0.0.0 localhost 5549367 5549367

[Note that the output packets reported for lan1 here match the lan0 output above, while the lan0 output reported by netstat match lan2 above. lan2 isn't even listed.]

# grep lan rbootd.log
Mon Sep 29 06:24:48 2003 : lan0: type: Ether NMID = 0
Mon Sep 29 06:24:48 2003 : lan2: type: Ether NMID = 2
Mon Sep 29 06:24:48 2003 : lan1: type: Ether NMID = 1
Mon Sep 29 06:24:48 2003 : matched lan0 : ppa 0
Mon Sep 29 06:24:48 2003 : matched lan2 : ppa 2
Mon Sep 29 06:24:48 2003 : matched lan1 : ppa 1
Mon Sep 29 06:24:48 2003 : got 3 lan device(s)

[Note PPA and NMID match.]

# ioscan -fnkC lan
Class I H/W Path Driver S/W State H/W Type Description
===================================================================
lan 0 0/0/0/0 btlan3 CLAIMED INTERFACE HP PCI 10/100Base-TX
Core /dev/diag/lan0 /dev/ether0
lan 1 1/10/0/0 gelan CLAIMED INTERFACE HP A4926A PCI
1000Base-SX Adapter
/dev/gelan1
lan 2 1/12/0/0 gelan CLAIMED INTERFACE HP A4926A PCI
1000Base-SX Adapter
/dev/gelan2

From /etc/rc.config.d/netconf:
INTERFACE_NAME[0]=lan0
IP_ADDRESS[0]=(omitted)
SUBNET_MASK[0]=255.255.255.0
BROADCAST_ADDRESS[0]=(omitted)
DHCP_ENABLE[0]=0
INTERFACE_STATE[0]=up

IP_ADDRESS[1]=10.86.200.110
SUBNET_MASK[1]=255.255.255.0
INTERFACE_NAME[1]=lan1
BROADCAST_ADDRESS[1]=10.86.200.255
INTERFACE_STATE[1]=up
DHCP_ENABLE[1]=0

# lanscan
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/0/0/0 0x00306E273C4D 0 UP lan0 snap0 1 ETHER Yes 119
1/12/0/0 0x00306E219F4F 2 UP lan2 snap2 2 ETHER Yes 119
1/10/0/0 0x00306E219F56 1 UP lan1 snap1 3 ETHER Yes 119

[Note: The PPA and the NMID do not match and NMID's are in a different range.]

# ifconfig lan2
ifconfig: no such interface

Only 2 of the three interfaces are connected to networks.

Now for the questions:
1. Has anyone seen this before?
2. Are there configuration files that can be checked/fixed?
3. Where does netstat get its info?
4. Where does the nm library get its info?
5. Where does lanscan get its info?

Thanks just for reading this far.

scott

[Romaric Guilloud · Accepted solution]

Hi Scott,
I went thru all you explanations:
To troubleshoot your pb of "overlapping" lanics names, you must fist match the output of a ioscan -fnClan with what a lanscan produces.

From your ioscan, you get the driver that should be then retrieved from /usr/newconfig/etc/rc.config.d (ex: for a gelan lanic, you copy /usr/newconfig/etc/rc.config.d/hpgelanconf into /etc/rc.config.d/hpgelanconf.new and populate this .new file)

Once done, you bring the lanic up (/sbin/init.d/hpgelan start) and verify with lanadmin -x its setup.
Fianlly, populate your /etc/rc.config.d/netconf accordingly and mount the associated IP on it (/sbin/init.d/net start).

At this point, you can pass the netstat -i command to make sure the ifconfig was done and that the number of packets sent/received on it gets incremented over the time.

Hope this helps.
Regards,

Romaric.

[Dietmar Konermann]

Please compile the attached source and run it on your machine.

(e.g. cc -o nmtest -lnm nmtest.c)

It should print you the results for all your interfaces including lan1. If it does not then the revision of you libnm may be responsible. For 11.11 it's patched with the ARPA cumulative patch. You should have at least PHNE_25642 installed.

Best regards...
Dietmar.

[Scott Conrad]

Thank you, Dietmar and Romaric, for your rapid and helpful responses.

It turned out that most of the wound was self-inflicted. An assumption built into the hpuxget program was that the arrays of structs returned by the NM lib calls get_physical_stat() and get_logical_stat() would have the same number of entries and be sorted in the same order.

This bug explains the output packets for lan0 being reported as lan1 and it appears that the NM library is behaving well based on Dietmar's utility.

I have no explanation for the NMID's not matching in the lanscan output and the rbootd.log entries. I'm hoping this won't matter to us.

The sys admin of the remote host in question is reluctant to change the LAN configuration of his production host when it appears to be working just fine, but I'm hoping the new hpuxget utility will provide coherent results. (I won't know the results until tomorrow at the earliest.) If the results are not what I expect, I know what to try next.

scott

[Karen Fontechia_1]

Hi Scott,

I am experiencing the same exact problem. Lan1 interface was brought live after lan3 due to networking drops not being installed. Lan1 is the interface which acts as our primary LAN for that host and lan3 is simply the backup. When the superdome was installed, they were brought live lan3 first; then lan1.

Lan1's incorrect configuration is: NM ID = 8, and CRD # = 1, and lan3's NM ID = 3 and the CRD ID = 3 (as it should).

The result is causing me a slight problem and it has to do with traceroute. It traces off of lan3 and therefore conflicts with our ISEE installation.

What / if anything did you to to reconcile the lan NM ID's?

Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/0/0/1/0 0x00306E4A249F 0 UP lan0 snap0 1 ETHER Yes 119
1/0/0/1/0 0x00306E4A04A0 2 UP lan2 snap2 2 ETHER Yes 119
1/0/10/0/0 0x00306E495892 3 UP lan3 snap3 3 ETHER Yes 119

2/0/10/0/0 0x00306E495893 4 UP lan4 snap4 4 ETHER Yes 119

2/0/11/0/0 0x00306E373A8A 5 UP lan5 snap5 5 ETHER Yes 119

3/0/10/0/0 0x00306E497801 6 UP lan6 snap6 6 ETHER Yes 119

3/0/11/0/0 0x00306E373A7B 7 UP lan7 snap7 7 ETHER Yes 119

0/0/10/0/0 0x00306E49588B 1 UP lan1 snap1 8 ETHER


This is not production yet, and I would like to fix it before it becomes production.
- Karen Fontechia

[Scott Conrad]

Hi Karen,

I'm sorry to report the NMID configuration issue was never addressed. The only remaining known problem besides the ID mismatch is that lan1 reports incorrect collision data 80% of the time. This wasn't considered important enough to take a production system down for more fiddling.

I'm ignorant about networking issues in general, but especially about HPUX configuration issues. Is it possible to remove all the interfaces, then add them back in the "correct" order since you feel this caused the problem?

scott