Stuck VIP

[EJ Stremler]

For some reason when we halt a package by "cmhaltpkg pkg" on one of our servers in the cluster, and start it on the other server, the VIP does not get released from the server where the package was halted.. It seems like it does not drop the TCP connection to the LINUX web tier server. We do have commands that use ssh to stop the web services in the SG control script, needed by the application.. Anyone have any idea why the VIP won't release, is there a workaround for this? I was thinking of adding the "ifconfig lan0:1 0.0.0.0" to release the vip in the SG control script,, otherwise users log in to the web server and access the passive node.. I can log into the VIP from any other system except for the web tier and access the right server where the package is up.

[Geoff Wild]

IS there an error in the syslog or the package log when shutting down?

Is the VIP configured in the package?

Rgds...Geoff

[skt_skt]

if you are loking for a work around use similar commands. This would be recommended way of handling VIPs.


to release the VIP

cmmodnet -r -i 10.10.252.183 10.10.252.0

to add the VIP

cmmodnet -a -i 10.10.252.183 10.10.252.0

[Carsten Krege]

You cannot use cmmodnet to add or remove an Oracle VIP, because SG does not control the VIP.

Instead when CRS shuts down, it should have removed the VIP. Therefore it appears you deal with an Oracle problem and you need to contact them for help.

Please refer to Oracle Metalink note 356903.1.


Carsten

[EJ Stremler]

Checking the package logs an all.. It shows the cmmodnet -r being executed without errors.. Then it proceeds with unmountimg the file systems.. Nothing is indicated in the syslog.log for the cmaltpkg.. I think there might be something quirky between this server and the web tier server. netstat -rn still shows the VIP as up, and you can access the correct system via the VIP from any other system but the web tier system.. We can get around this by ifconfig lan0:1 0.0.0.0.. I was wondering about adding this to the SG controls script as the last command executed in the halt portion of the CUSTOMER DEFINED commands.. Thanks,Ed

Jul 30 17:08:49 - Node "oa4401": Remove IP address 10.130.2.25 from subnet 10.13
0.2.0
Jul 30 17:08:49 - Node "oa4401": Unmounting filesystem on /dev/vg02/lvol4
Jul 30 17:08:51 - Node "oa4401": Unmounting filesystem on /dev/vg02/lvol3

[skt_skt]

Always use netstat -iw to confirm if the Ips are really bound to the same virtual interface. Looking at the below output you can see that netstat -in shows only first 8 chars under name column. FYI.

So when ever VIP fail over happens it may look like IPs bound to the same virtual interface, but actually it may not.

:root [/eb_inf2_q/orabin/10.2.0.2/crs/bin] netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lan901:8 1500 10.10.252.0 10.10.252.197 11004174 0 10042523 0 0
lan900:1 1500 132.226.192.0 132.226.192.154 0 0 0 0 0
lan1 1500 10.10.253.0 10.10.253.35 68161 0 0 0 0
lo0 4136 127.0.0.0 127.0.0.1 857977 0 857977 0 0
lan900:7 1500 132.226.192.0 132.226.192.230 219477 0 131571 0 0
lan902 9000 10.10.225.0 10.10.225.1 39193190 0 37343398 0 0
lan901 1500 10.10.252.0 10.10.252.65 39414252 0 29955631 0 0
lan900 1500 132.226.192.0 132.226.192.65 18149868 0 14845818 0 0

:root [/eb_inf2_q/orabin/10.2.0.2/crs/bin] netstat -iw
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lan901:801 1500 10.10.252.0 aded115nv.ami.alcoa.com 11004267 0 10042599 0 0
lan900:1 1500 132.226.192.0 ebrdw2d.ami.alcoa.com 0 0 0 0 0
lan1 1500 10.10.253.0 10.10.253.35 68161 0 0 0 0
lo0 4136 loopback localhost 857984 0 857984 0 0
lan900:77 1500 132.226.192.0 ebrdw3q.ami.alcoa.com 219477 0 131571 0 0
lan902 9000 10.10.225.0 aded115np.ami.alcoa.com 39194450 0 37344638 0 0
lan901 1500 10.10.252.0 aded115n.ami.alcoa.com 39447692 0 29989082 0 0
lan900 1500 132.226.192.0 aded115nu.ami.alcoa.com 18150036 0 14845924 0 0