Troubleshooting Port-Channels and Trunks Between HP-UX Servers and Nexus Switches

Carole Warner Reece

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.


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.


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#” orlanVPPA#” in this output.



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!


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:

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.