cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Veritas.com
Support

Broadcast issue on MultiNICBAgent on VCS 5.0MP1

supermario
Level 3

‎01-14-2010 01:07 AM


We had two servers (sun sparc) detected broadcasting at 0.0.0.0.  On doing a diagnostic we found the following:
2009 Aug 17 11:26:03 MultiNICBAgent[3322]
 MAC dst=ff:ff:ff:ff:ff:ff src=0:15:17:75:51:56 proto=0800

The diagnostics for the dTrace output from sun is:
2009 Aug 17 11:26:03 MultiNICBAgent[3322] <-- process name and pid.
 MAC dst=ff:ff:ff:ff:ff:ff src=0:15:17:75:51:56 proto=0800 <-- src mac is e1000g0's
 IP dst=6.0.65.181 src=246.176.0.0 proto=00 <-- it seems failing to trace IP part due to wrong offset..

They claim that it may be some issue with symantec.

The snoop output is like follows:
  1 11:25:33.08104 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 912 Sequence number: 0)
  2 11:25:43.14157 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 3594 Sequence number: 0)
  3 11:25:53.29017 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 20195 Sequence number: 0)
  4 11:26:3.36074 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 13046 Sequence number: 0) <----
  5 11:26:13.47030 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 4771 Sequence number: 0)
  6 11:26:23.51042 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 24175 Sequence number: 0)
  7 11:26:33.71048 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 56096 Sequence number: 0)



Setting for multiNICBAgent is like follows:
    MultiNICB MultiNICB_erp (
        MpathdCommand = "/usr/lib/inet/in.mpathd -a"
        ConfigCheck = 0
        Device = { e1000g0 = 0, nxge0 = 1 }
        IgnoreLinkStatus = 0
        NetworkTimeout = 300
        DefaultRouter = "172.21.150.22"
        Failback = 1
        )


My VCS version is: Veritas-5.0MP1-11/29/06-17:15:00

System info is:
SunOS CSPM5ERP 5.10 Generic_127127-11 sun4u sparc SUNW,SPARC-Enterprise

any idea what can be causing this? Kindly update.

Regards,

0 Kudos
2 REPLIES 2

supermario
Level 3

‎01-14-2010 01:11 AM

Oops. seems that the stupid thing carried over the style information. The same fixed:
We had two servers (sun sparc) detected broadcasting at 0.0.0.0.  On doing a diagnostic we found the following:

2009 Aug 17 11:26:03 MultiNICBAgent[3322]
 MAC dst=ff:ff:ff:ff:ff:ff src=0:15:17:75:51:56 proto=0800
2009 Aug 17 11:26:03 MultiNICBAgent[3322]
 MAC dst=ff:ff:ff:ff:ff:ff src=0:21:28:5:84:ee proto=0800
2009 Aug 17 11:26:13 MultiNICBAgent[3322]
 MAC dst=ff:ff:ff:ff:ff:ff src=0:15:17:75:51:56 proto=0800
2009 Aug 17 11:26:13 MultiNICBAgent[3322]
 MAC dst=ff:ff:ff:ff:ff:ff src=0:21:28:5:84:ee proto=0800
2009 Aug 17 11:26:23 MultiNICBAgent[3322]
 MAC dst=ff:ff:ff:ff:ff:ff src=0:15:17:75:51:56 proto=0800

The diagnostics for the dTrace output from sun is:

CPU     ID                    FUNCTION:NAME
 16  37046              dld_tx_single:entry
2009 Aug 17 11:26:03 MultiNICBAgent[3322] <-- process name and pid.
 MAC dst=ff:ff:ff:ff:ff:ff src=0:15:17:75:51:56 proto=0800 <-- src mac is e1000g0's
 IP dst=6.0.65.181 src=246.176.0.0 proto=00 <-- it seems failing to trace IP part due to wrong offset..


2009 Aug 17 11:26:03 MultiNICBAgent[3322] <-- process name and pid.
 MAC dst=ff:ff:ff:ff:ff:ff src=0:15:17:75:51:56 proto=0800 <-- src mac is e1000g0's
 IP dst=6.0.65.181 src=246.176.0.0 proto=00 <-- it seems failing to trace IP part due to wrong offset..

They claim that it may be some issue with symantec.

The snoop output is like follows:
  1 11:25:33.08104 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 912 Sequence number: 0)
  2 11:25:43.14157 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 3594 Sequence number: 0)
  3 11:25:53.29017 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 20195 Sequence number: 0)
  4 11:26:3.36074 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 13046 Sequence number: 0) <----
  5 11:26:13.47030 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 4771 Sequence number: 0)
  6 11:26:23.51042 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 24175 Sequence number: 0)
  7 11:26:33.71048 172.21.33.41 -> OLD-BROADCAST ICMP Echo request (ID: 56096 Sequence number: 0)

Setting for multiNICBAgent is like follows:

    MultiNICB MultiNICB_erp (
        MpathdCommand = "/usr/lib/inet/in.mpathd -a"
        ConfigCheck = 0
        Device = { e1000g0 = 0, nxge0 = 1 }
        IgnoreLinkStatus = 0
        NetworkTimeout = 300
        DefaultRouter = "172.21.150.22"
        Failback = 1
        )

My VCS version is: Veritas-5.0MP1-11/29/06-17:15:00

System info is:
SunOS CSPM5ERP 5.10 Generic_127127-11 sun4u sparc SUNW,SPARC-Enterprise

any idea what can be causing this? Kindly update.

Regards,
0 Kudos

Gaurav_S
Moderator
Moderator
   VIP    Certified

‎01-14-2010 06:42 PM

Hello,

couple of initial suggestions:

a) I can see you are not using IPMP for failover however mpathd command is set, in case you have setup IPMP or you intend to use IPMP for failover, please insert a line in config "UseMpathd = 1",  for e.g below

MultiNICB MultiNICB_erp (
        MpathdCommand = "/usr/lib/inet/in.mpathd -a"
        ConfigCheck = 0
        Device = { e1000g0 = 0, nxge0 = 1 }
        IgnoreLinkStatus = 0
        UseMpathd = 1
        NetworkTimeout = 300
        DefaultRouter = "172.21.150.22"
        Failback = 1
        )

b) Thinking on why multinic agent would braodcast ? I get an answer that it needs to ping some IP address to understand whether the resource is alive or not, however this purpose should be solved by "DefaultRouter" attribute, but somehow I guess putting one more attribute "NetworkHosts" & putting a IP in NetworkHosts atribute which is always alive would be good point to start...


Gaurav
0 Kudos