Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

pbx starting on 169.X.X.X address

Created: 14 Nov 2012 | 7 comments
Michael G Andersen's picture

Hello

I have a Windows 2008 R2 Netbackup 7.5.0.4 client where the pbx keeps starting on a 169.X.X.X address

Have tried to change the order of the network interfaces, disable the interface with the 169.X.X.X and created the PREFERRED_NETWORK which should be equivalent to the REQUIRED_INTERFACE all without luck

C:\Program Files\VERITAS\NetBackup\bin>bpclntcmd -self
gethostname() returned: DK01SC0019-2
host DK01SC0019-2: DK01SC0019-2.scdom.net at 172.X.X.X
host DK01SC0019-2: DK01SC0019-2.scdom.net at 169.X.X.X
aliases:     DK01SC0019-2.scdom.net     DK01SC0019-2     172.X.X.X     169.X.X.X

C:\Program Files\VERITAS\NetBackup\bin>

The problematic interface is the cluster heart beat team

Have searched the support site without much luck eventhough I am pretty sure there was a technote which related to a similar problem

Have also created a case at symantec support

Regards

Michael

Comments 7 CommentsJump to latest comment

Yasuhisa Ishikawa's picture

On which point you think the problem? By " bpclntcmd -self"? Any other?

If I remember right, "bpclntcmd -self" just displays all the interfaces up on the host.
And, unlike UNIXs, Windows used to return its node name againt reverse lookup when any other name service like DNS and host file can not resolve it.
So "bpclntcmd -self" shows all the interfaces with same host name.

Authorized Symantec Consultant(ASC) Data Protection in Tokyo, Japan

Michael G Andersen's picture

See the problem in the vnetd log and when trying to set SQL Server connection properties and dbclient log from the attempts.

from vnetd log:

15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.132: pbxRegisterEx successful at 169.X.X.X:5126/vnetd, returns with 7 alt_addrs
15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.144: alt_addr: 172.X.X.X:5126
15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.144: alt_addr: 172.X.X.X:5126
15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.144: alt_addr: 172.X.X.X:5126
15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.144: alt_addr: 172.X.X.X:5126
15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.144: alt_addr: 172.X.X.X:5126
15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.144: alt_addr: 0.0.0.0:1556
15:32:19.769 [3028.6472] <2> vnet_registerPBXServer: ../../libvlibs/vnet_pbx.c.144: alt_addr: 0.0.0.0:1556

Nicolai's picture

Is it a issue ?

PBX as I recall detect all available interfaces in order to resolve all possible connections.

Does the primary interface and heartbeat inteface use the DNS name ?

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

mph999's picture

Nicolai is correct - PBX will detect all interfaces

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
mph999's picture

Nicolai is correct - PBX will detect all interfaces

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
Marianne's picture

It seems you have two interfaces using the same hostname?

host DK01SC0019-2: DK01SC0019-2.scdom.net at 172.X.X.X
host DK01SC0019-2: DK01SC0019-2.scdom.net at 169.X.X.X
 

Each Interface/IP should have its own hostname.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Michael G Andersen's picture

Sorry for the late answer. Yes, but unfortunately microsoft cluster just uses the hostname for it's internal created interface. Turned out the problem with SQL was another issue which has disappeared after the server was rebooted. So it seems that the 169.X.X.X address may not the issue this time