One of my customers asked for helping troubleshooting a port-channel between a HP-UX server and a Cisco Nexus 7000. I did not know much about HP-UX server configuration, but I agreed to take a look at it.
Key take-away: Server terminology does not always match networking terminology.
Background
My customer told me that they wanted to configure network redundancy from the HP RX2800i4 server running HP-UX to one of their core switches (Nexus7Ks). They were told that the HP-UX system runs software to provide port aggregation (APA) that is supposed to be compatible with “most” switch vendors. However, they were not able to successfully configure the port-channel between the server and their 7K.
Note: This is not a vPC configuration.
I believe that both Cisco and HP support folks were trying to resolve the problem previously, but the issue was still lingering when I got the call.
I suggested that my customer check that the LACP mode on both sides was set to active — on the HP-UX Link Aggregate this is LACP_AUTO, on the Nexus switch it is channel-group channel-number mode active for the interfaces in the port-channel.
She let me know that on one of the last tests, the port-channel came up, and it was set to active. So the problem had evolved, she believed the port-channel was working.
I think she said that the server guy had configured an IP address on the trunk. This was a bit confusing to me – I asked if it was a Layer 3 port channel. She said no, but was not sure how or where the IP address was configured.
She did know that when the port-channel was up there was no IP accessibility across the port-channel to other network resources. The HP server could only ping itself.
Troubleshooting
I then got to review the Nexus configuration over a webex session. It looked fine to me – two VLANs were allowed across the port-channel, and it was configured as a Layer 2 trunk. The port-channel was down with suspended interfaces, but the HP server ports had been removed from the port-channel during a previous troubleshooting session.
We did not have access to the server initially, so I reviewed the HP documents for HP-UX Port aggregation (APA) and for configuring VLANs on HP-UX. What I found interesting:
“HP Auto Port Aggregation (APA) is a software product that creates link aggregates, often called trunks, which provide a logical grouping of two or more physical ports into a single fat pipe.”
This seemed to be one of the keys to me. In the Cisco world, I think of trunks as links that support multiple Layer 2 VLANs. We configure IP address on SVIs. But in the HP server world, a group of interfaces running LACP can be called a trunk. And you can add a VLAN to an interface, and you can modify a VLAN to associate an IP address with it (to create the equivalent of an SVI.)
With this new terminology in mind, my guess was that the IP connectivity issue was possibly a syntax issue – by default there is NO VLAN trunking on a APA trunk from the HP Server perspective. So when the server guy initially configured an IP address for the trunk, it was NOT associated with an allowed VLANs from the Cisco switch perspective. The non-working IP address was probably in the default VLAN, and did not match the SVIs on the switch.
While looking at the HP docs, I learned that the HP-UX link aggregate uses a PPA (Physical Point of Attachement) to identify the port channels. The PPA numbers start at 900. These correspond to the port-channel number used in Cisco switches.
I also learned that HP-UX ties a VPPA (Virtual Physical Point of Attachement) to each VLAN. The VPPA numbers range from 5000 – 8999 and are used to send and receive 802.1Q tagged frames.
From the command line on the HP-UX, you can see the IP addresses associated with the PPA or the VPPA with the netstat -in command:
Note: The HP-UX shows the PPA and VPPA as “lanPPA#” or “lanVPPA#” in this output.
Resolution
We had another webex when the HP server guy was available. We could not actually confirm the old configuration because it had been removed.
However, after reactivating the link aggregate interface, we added the appropriate VLANs to it. Since we were working with 3 digit VLAN numbers, we defined the VPPA for each VLAN to correspond to the VLAN number – so VPPA 5100 was used for VLAN 100. We then associated IP addresses in the correct subnets with the VLANs.
We tried a ping test from the HP side – success! Woo hoo!
Summary
It seems quite likely the IP address was previously assigned only to the PPA on the HP server (Cisco world – logical port-channel interface), not to any VPPAs (Cisco world – SVI). I learned that sometimes you need translate terms between the server world and the networking world so everyone is configuring the same items, and then connectivity happens.
— cwr
_________________________________________________________________________
If you would like some additional details on troubleshooting Nexus port-channels, the following references may be helpful: