CPQTeamMP Event ID 434 and Event ID 11197

[Bob Martin_3]

Hi,
I am getting the above event ID's on 2 DL380's (Windows 2003 servers) with teamed NC7781 adapters.

HP Network Team #1: PROBLEM: A non-Primary Network Link is not receiving. Receive-path validation has been enabled for this Team by selecting the Enable receive-path validation Heartbeat Setting. ACTION: Please check your cabling to the link partner. Check the switch port status, including verifying that the switch port is not configured as a Switch-assist Channel. Generate Broadcast traffic on the network to test whether these are being received. Also make sure all teamed NICs are on the same broadcast domain. Run diagnostics to test card. Drop the NIC from the team, determine whether it is receiving broadcast traffic in that configuration.

I also get dnsapi Event ID 11197 when the server starts. If I get this error then the server didn't make it onto the network. If I do an IPCONFIG it doesn't have and IP address.

The system failed to update and remove host (A) resource records (RRs) for network adapter
with settings:

Adapter Name : {1D33D9DF-9C74-49C5-9586-C427F10EC80F}
Host Name : sehbac002w23
Primary Domain Suffix : aegonuk.com
DNS server list :
1.34.12.10, 1.34.54.23
Sent update to server :
IP Address(es) :
1.34.30.13

The reason the update request failed was because of a system problem. For specific error code, see the record data displayed below.

I have tried reconfiguring the network adapters and creating the team again from scratch no no avail. The thing is that it doesn't happen every reboot, sometimes it
will come up OK. Also, after an unsuccessful reboot, if I disable the team then enable, it connects OK.

I would be grateful for any assistance.
Bob

[Iain Proudfoot]

Bob,
I have had a similar 434 error on one of our teams. The problem was happening because the Primary NIC in the team was transmitting a heartbeat frame that the non-primary was not receiving.

This made sense in our configuration so we switched off 'receive path validation' this stopped the 434 error. If there is a path back to the non-primary NIC then I would check your connections or your switch config.
Hope this helps
IP

[Andrew Schmadel]

Hi,

I'm having the same exact problem, but on Windows 2000.

I do not believe that teaming was ever even set up on this server, nor do I know where to go to resolve this problem which has arisen over the past few weeks.

Does anyone know where I even start looking to resolve this problem?

[Paul Phuong]

Hi Bob, I too am running into the same issue. I am looking into the problem right now and will let you know when I find the solution. But if you find the solution before I do, please notify me.

Thanks, PP

[Twan van Beers]

Hi ya,

I also have a couple of 380s with this problem. It has happened after upgrading to 8.20 of the Teaming Software. At this stage I only have two out of the twelve intially upgraded servers with this problem. I've found a difference in the configuration since the switch ports for the two failing servers is not set to PortFast, whereas all of the others are. I've had the ports reconfigured and will monitor progress on these

I can resolve the problem temporarily by using ILO to get onto the server, disable the team and enable the team again. It is just like the problem with 8.10 of the software eventhough we've upgraded to 8.20 which is supposed to have fixed this very problem...

Cheers
Twan

[Tech Engineers]

We were able to resolve this issue, with the 8.20 team drivers. We had to update the individual NIC drivers to 8.48, then set the team type to Automatic, transmit load balancing to Automatic.

Then on our Cisco switch...
!
interface Port-channel20
switchport
switchport access vlan 100
switchport mode access
!
!
interface GigabitEthernet6/10
description NIC1
switchport access vlan 100
switchport mode access
channel-group 20 mode active
!
interface GigabitEthernet6/11
description NIC2
switchport access vlan 100
switchport mode access
channel-group 20 mode active
!

This combination corrected the issue. If you look at the Team Properties, Statistics tab, you see that the mode negotiates to 802.3ad Dynamic with Fault Tolerance. This is what we were trying to accomplish. On previous software versions, we would set the team type to 802.3ad Dynamic with Fault Tolerance. After the driver update, this no longer worked. So half of our servers are one way, half are the other, the switch configuration for both are exactly the same as above. Hope this helps.

[Pete Long]

Heres how I fixed mine

http://www.petenetlive.com/KB/Article/0000350.htm


Pete