RELATED TO -- Subject: Help with Auto Port Aggregation

[Carlos Zoller]

Hello, I have a similar question to the case that I am quoting on the subject field, however I couldn't find any response on that case or in any other one.

I am having this error on rc.log, and the same when I issue a lancheckconf command:

Reading ASCII file /etc/lanmon/lanconfig.ascii
ERROR: Ports 1 and 5 not connected
Exiting: Error verifying input file /etc/lanmon/lanconfig.ascii

My very punctual question is:

What does "Ports 1 and 5 not connected" means?

1. Hardware error.
2. Config error.
3. Others???

Your answers are kindly appreciated.

[Ivan Krastev]

Check the connection between LAN1 (port 1) and LAN5 (port5) with linkloop.
Check also speed and duplex settings for both ports.


regards,
ivan

[Carlos Zoller]

Ivan, thanks for your answer.

I am pretty sure you mean check connection physically on the equipment. The thing is that I give remote support, and this equipment is installed on a different city. I apologize, I should have mentioned that before.

Is there any command that would reveal a connection issue between those 2 LANs.?

Thanks again.

[Stefan Mirevski · Accepted solution]

Carlos, you can test the card connectivity with the linkloop(1M) command:


# lanscan
...
1/0/4/0/6 0x00306E5EB7F8 1 UP lan1 snap1 1 ETHER Yes 119
1/0/2/0/0 0x00306EF4011D 5 UP lan2 snap2 5 ETHER Yes 119


In the preceding sample output, there is lan1 with MAC address 0x00306E5EB7F8 and lan5 with 0x00306EF4011D .

Use the linkloop command to send a packet out lan1 to the MAC address of lan5 and vice-versa:


# linkloop -i 1 0x00306EF4011D
Link connectivity to LAN station: 0x00306EF4011D
-- OK
# linkloop -i 5 0x00306E5EB7F8
Link connectivity to LAN station: 0x00306E5EB7F8
-- OK

[Carlos Zoller]

Now, it was clear how to test. I just did it, see the output:


#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 0x00306E4846C7 0 UP lan0 snap0 1 ETHER Yes 119
0/10/0/0/4/0 0x00306E5EDE74 1 UP lan1 snap1 2 ETHER Yes 119
0/10/0/0/5/0 0x00306E5EDE75 2 UP lan2 snap2 3 ETHER Yes 119
0/10/0/0/6/0 0x00306E5EDE76 3 UP lan3 snap3 4 ETHER Yes 119
0/10/0/0/7/0 0x00306E5EDE77 4 UP lan4 snap4 5 ETHER Yes 119
0/12/0/0/4/0 0x00306E5EDE78 5 UP lan5 snap5 6 ETHER Yes 119
0/12/0/0/5/0 0x00306E5EDE79 6 UP lan6 snap6 7 ETHER Yes 119
0/12/0/0/6/0 0x00306E5EDE7A 7 UP lan7 snap7 8 ETHER Yes 119
0/12/0/0/7/0 0x00306E5EDE7B 8 UP lan8 snap8 9 ETHER Yes 119
LinkAgg0 0x000000000000 900 DOWN lan900 snap900 11 ETHER Yes 119 -- This is the lan that supposedly is formed by 1 and 5
LinkAgg1 0x000000000000 901 DOWN lan901 snap901 12 ETHER Yes 119
LinkAgg2 0x000000000000 902 DOWN lan902 snap902 13 ETHER Yes 119
LinkAgg3 0x000000000000 903 DOWN lan903 snap903 14 ETHER Yes 119
LinkAgg4 0x000000000000 904 DOWN lan904 snap904 15 ETHER Yes 119
#

#linkloop -i 1 0x00306E5EDE78
Link connectivity to LAN station: 0x00306E5EDE78
error: expected primitive 0x30, got DL_ERROR_ACK
dl_error_primitive = 0x2d
dl_errno = 0x04
dl_unix_errno = 57
error - did not receive data part of message
#

#linkloop -i 5 0x00306E5EDE74
Link connectivity to LAN station: 0x00306E5EDE74
error: get_msg2 getmsg failed, errno = 4
-- FAILED
frames sent : 1
frames received correctly : 0
reads that timed out : 1
#

I believe:
1. either there's physical damage.
2. or some cables were disconnected on site.

Am I right?

[Stefan Mirevski]

Carlos,
Yes, possibly you are facing one of the two problems you mentioned.

In addition, you might further want to check for the following issues:

To check the speed and duplex settings for both server ports:
lanadmin -x 1
lanadmin -x 5

You might also want to check the server port statistics for any peculiarities (e.g. Administrative status UP/Operation status DOWN, excessive errors, etc):

lanadmin -g 1
lanadmin -g 5

and the nettl log for any recent entries:

netfmt -f /var/adm/nettl.LOG000

And finally, there might possibly be some misconfiguration on the switch or some speed/duplex settings mismatch between the server and switch ports.
You could try linkloop to the MAC address of the corresponding switch ports and check the switch configuration itself (channeling, VLAN settings, etc.)

[Fabien GUTIERREZ]

this error that is confirmed by invalid linkloop means u have 2 differents vlan configured on both NIC.

[Carlos Zoller]

Now, things are getting clearer to me, however still some doubts. I have two HP boxes with exactly the same config (of course with different IP addresses), one box is failing and is the one that I have been talking about. Now have executed all those commands on both boxes to compare and this is what I see.

1. Only on "node1" and lan1 lanadmin -g shows that Operation Status is down and also a no traffic and some "Outbound discards"

2. Both nodes show alarms about "bad cable connection" or "Port X did not receive any poll packets" so not sure if that shows actually a problem.

I just saw a comment about a possible VLAN misconfig, my friend would you kindly be a more specific please.

Thanks a lot to everyone.

P.S. Attached you'll find outputs from both nodes.

[Steven E. Protter]

Shalom,

<7002> 10/100BASE-T driver detected bad cable connection between
the adapter in slot(Crd In#) 0 and the hub or switch.
btlan[ 0] [HP PCI 10/100Base-TX Core]
going Offline @ [0/0/0/0] [Cable Disconnected]


Perhaps a meaningful error message.

Try replacing the cable, checking the switch port configuration. If that fails, consider having the NIC card checked and replaced.

SEP

[Carlos Zoller]

Hello all,

I do apologize for taking too long to give acknowgement about this issue.

Finally we realize the problem was that both HP boxes are connected to two different balancer switches (BigIPs) and it turned out that one of them was disconnected. So, when the HP box was rebooted it couldn't reassemble the Port Aggregation feature that was using lan1 and lan5 as lan900 because one of them didn't have connection.

I was working with another guy that has a lot of experience in HP boxes and he told me this was the first we realized that HP APA had this behaviour, the logical thing (at least from my point of view) is that at the moment that the APA is going to be assemble, if one of its interfaces fails to connect, it should use the remaining one that has connection, however what it does is simply deactivate both interfaces leaving the box without connection, perhaps it's a HP bug.

When we realized this, what we did is to disable the lan900 interfaces from lanconfig.ascii and use only the one that has connection, that solved the problem for the moment, until we put into production the failed bigip again, and now everything is back to normal.

I have assigned points for all helpful answers, and I will leave this case open for a few days in case there are comments to be shared.

Thanks everyone for your valuable help.

RGs,

Carlos.

[Stefan Mirevski]

Hello Carlos,

Thanks for your update on this issue!

The behaviour you experienced (APA LAN Monitor failover group not forming when member interfaces not being able to linkloop each other) is not a bug.

One of the prerequisites when configuring APA LAN Monitor failover groups is that the member interfaces be able to linkloop each other. This is actually the first step to verify. Consult e.g.:

===========================================
HP Auto Port Aggregation (APA) Support Guide
HP-UX 11.0, 11i v1, 11i v2
HP Part Number: J4240-90035
Edition: September 2006, E0906
Subsection (on p.60)
"Configuring LAN Monitor Failover Groups":
===========================================
If this is the first time you have configured a LAN Monitor failover group, or if you have changed the
LAN Monitor configuration, [My comment: This also includes a reboot] do the following:
1. Connect the physical devices that are to be in the failover group to the same switch, or to different
switches or hubs on the same subnet to achieve switch/hub redundancy.
NOTE: Be sure that trunking is not enabled on the switch ports.
[!!!]2. Check that a linkloop between the devices succeeds. If it fails, resolve the physical connection
between the devices.
===========================================

Does this answer your concern?

Best regards,
Stefan

[Stefan Mirevski]

PS: Further informal explanation to the above stated:

The interfaces in the APA LAN Monitor failover group should - or rather must - be able to linkloop each other when forming the failover group in order for the group to be successfully formed.

After the failover group has been formed successfully, should afterwards one of the interfaces in the group fail, then the one with the next highest priority will take over the connection/traffic.

[Carlos Zoller]

Thanks Stefan for your clarification, I see that the issue is documented (so not a bug), however it would be nice if the APA could be able to handle this type of scenario, that would make things safer for the platform, and will give the administrator time to fix the problem without running into trouble.

Thanks again. Proceeding to close thread now.

[Carlos Zoller]

Issue solved and cleared.