cmmodnet can't removed IP

[David Her]

hi,
Lan failed when package was halted. The IP still alive/pingable. Now can't even manully remove ip. Need advice please.


here is syslog.log
Jan 16 10:50:33 g4u1395c cmcld[5386]: Executing '/etc/cmcluster/EGP/dbciEGP.control.script stop' for package dbciEGP, as ser
vice PKG*130561.
Jan 16 10:50:33 g4u1395c cmserviced[5389]: Request to perform run service PKG*130561
Jan 16 10:50:33 g4u1395c su: + tty?? root-egpadm
Jan 16 10:50:36 g4u1395c su: + tty?? root-oraegp
Jan 16 10:50:37 g4u1395c syslog: cmmodnet -r -i 16.234.17.68 16.234.16.0
Jan 16 10:50:37 g4u1395c su: + tty?? root-oraegp
Jan 16 10:50:37 g4u1395c syslog: cmmodnet -r -i 16.234.17.72 16.234.16.0
Jan 16 10:50:40 g4u1395c cmserviced[5389]: Service PKG*130561 terminated due to an exit(0).
Jan 16 10:50:37 g4u1395c su: + tty?? root-egpadm
Jan 16 10:50:40 g4u1395c above message repeats 5 times
Jan 16 10:50:40 g4u1395c cmcld[5386]: Halted package dbciEGP on node g4u1395c.
Jan 16 10:50:58 g4u1395c cmnetd[5409]: 16.234.18.17 recovered.
Jan 16 10:50:58 g4u1395c cmnetd[5409]: Subnet 16.234.16.0 up
Jan 16 10:50:58 g4u1395c cmnetd[5409]: lan6 is up at the IP layer.
Jan 16 10:50:58 g4u1395c cmnetd[5409]: lan6 recovered.
Jan 16 10:51:33 g4u1395c inetd[24433]: registrar/tcp: Connection from g4u1395c (16.234.18.17) at Sun Jan 16 10:51:33 2011

...... ping ip
g4u1395c:adm/syslog $ ping 16.234.17.72
PING 16.234.17.72: 64 byte packets
64 bytes from 16.234.17.72: icmp_seq=0. time=3. ms
64 bytes from 16.234.17.72: icmp_seq=1. time=0. ms

..... manully remove ip
g4u1395c:adm/syslog $ cmmodnet -r -i 16.234.17.72 16.234.17.72
cmmodnet: IP address 16.234.17.72 is not configured on the subnet.
cmmodnet: Use the "netstat -in" command to check the configured IP addresses
for the subnet.

Thanks,
David

[Matti_Kurkela]

The IP might be active on another host.

Ping the IP address again, then run "arp -a" immediately after stopping the ping to see which MAC address is associated with the IP. Does it match any of the MAC addresses of this host? If not, find the host that has that particular MAC address and examine its configuration.

MK

[David Her]

Here is outcome then lanscan. Can you assist how to identify which MAC matched sapnfsegp1 ?

g4u1395c:$ arp -a
16.234.250.1 (16.234.250.1) at 0:0:c:7:ac:3 ether
16.234.248.1 (16.234.248.1) at 0:0:c:7:ac:9 ether
sapnfsegp1.houston.hp.com (16.234.17.72) at 0:b:fc:fe:1b:c ether
16.234.16.1 (16.234.16.1) at 0:0:c:7:ac:4 ether


g4u1395c:$ lanscan
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/2/1/0/4/0 0x001E0B885744 0 UP lan0 snap0 1 ETHER Yes 119
0/2/1/0/4/1 0x001E0B885745 1 UP lan1 snap1 2 ETHER Yes 119
0/2/1/0/6/0 0x001E0B885746 2 UP lan2 snap2 3 ETHER Yes 119
0/2/1/0/6/1 0x001E0B885747 3 UP lan3 snap3 4 ETHER Yes 119
0/4/2/0 0x001A4B083A76 4 UP lan4 snap4 5 ETHER Yes 119
0/6/1/0/4/0 0x001E0B885C20 6 UP lan6 snap6 6 ETHER Yes 119
0/6/1/0/4/1 0x001E0B885C21 7 UP lan7 snap7 7 ETHER Yes 119
0/6/1/0/6/0 0x001E0B885C22 8 UP lan8 snap8 8 ETHER Yes 119
0/6/1/0/6/1 0x001E0B885C23 9 UP lan9 snap9 9 ETHER Yes 119
0/4/2/1 0x001A4B083A77 5 UP lan5 snap5 10 ETHER Yes 119
LinkAgg0 0x000000000000 900 DOWN lan900 snap900 12 ETHER Yes 119
LinkAgg1 0x000000000000 901 DOWN lan901 snap901 13 ETHER Yes 119
LinkAgg2 0x000000000000 902 DOWN lan902 snap902 14 ETHER Yes 119
LinkAgg3 0x000000000000 903 DOWN lan903 snap903 15 ETHER Yes 119
LinkAgg4 0x000000000000 904 DOWN lan904 snap904 16 ETHER Yes 119

Thanks,
David

[Matti_Kurkela · Accepted solution]

Lanscan? Oh, you mean it's HP-UX, not Linux. I see. (You posted to Linux system administration section, so I generally assumed you had some form of Linux. I'll ask the moderators to move this thread to the proper HP-UX system administration section.)

The current MAC address of IP 16.234.17.72 is 0:b:fc:fe:1b:c = 00:0b:fc:fe:1b:0c = 0x000BFCFE1B0C (alternate ways to write the MAC address).

There is no such address listed by lanscan. That means the IP address is most likely currently active on some other host.

According to this search service, the MAC address prefix 00:0b:fc suggests the IP address is currently accessible via (or perhaps even held by) some Cisco device:

http://www.coffer.com/mac_find/?string=00%3A0b%3Afc

Contact your network administrator: s/he might be able to identify the switch port where that MAC address is located. If the MAC address points you to e.g. a firewall or a router, the network administrator should know how to continue the trace using the IP address.

You may have a classic case of duplicate IP address. If your Serviceguard package was generating/receiving a lot of traffic and the other holder of the same IP was mostly quiet, the duplicate IP might not have caused any significant problems and thus managed to stay undetected... until now.

MK

[David Her]

Matti,
Thank you for quick direction. Hope network administrator can trace it.

David