Service guard Issue with virtual IP

[anoop_10]

Hi,
I have two rp3440 servers with MC/SG 11.16 active-passive cluster configured. These servers were working perfectly with out any trouble; unfortunately one node went down due to some hardware issue. So I tried to bring up the cluster with single node. Cluster formed successfully and application started working. Suddenly we loss the connection with Application Virtual IP.I am able to ping to this IP from the same cluster node were the application is up and running. But not able to connect (telnet/ping) from outside n/w.

So I down the cluster and started again, then its starts work fine but after some time again we face the same issue…In my observation there is no duplication in the IP’s.and there is no error in pakage log file and syslog.

Please help me out to solve this issue……

# cmviewcl


CLUSTER STATUS
INTRANET up

NODE STATUS STATE
sudr2e05 up running

PACKAGE STATUS STATE AUTO_RUN NODE
ORACLE up running enabled sudr2e05

NODE STATUS STATE
supr4d04 down unknown


Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lan1:1 1500 172.28.4.0 172.28.4.80 75247 0 51561 0 0
lan1 1500 172.28.4.0 172.28.4.72 35642158 0 34941831 0 0
lan0* 1500 10.10.10.28 10.10.10.30 6998943 9 6564868 0 0
lo0 4136 127.0.0.0 127.0.0.1 28992584 0 28992584 0 0


Thanks & Regards
Anoop

[Steven E. Protter]

Shalom,

Try changing the network port the surviving server is connected to.

What I'm thinking is there is either a network infrastructure problem or worse yet a network configuration problem on the surviving server.

This behavior can occur due to network issues.

SEP

[anoop_10]

Hi Steven,

Thanks for u r quick reply.....

I am also suspecting the same issue But How can I isolate this issue as there is no logs available...and what are network configuration I need to check. Because Am able to connect to its physical IPâ s


Thanks
Anoop

[melvyn burnard]

hmm, this looks like your routing is getting corrupted or something like that.
I would check your syslog.log, and you may want to see if inetd logging is on, then take a look at that log.
You may also want to take a nettl trace to see if that will help.

As a test, halt the package, and add the package ip manually using ifconfig lan1:1 and see if the same symptom persists. This will at least help to isolate wheter it is an SG issue or not (which I doubt)

[manoj_pu]

Hi Anoop,

Try to bind the virtual IP address 172.28.4.80 manually (without package) on lan1:1 and see the network behavior.

If it behaves similar manner then the network is the culprit otherwise the service guard configuration.


Regards,
Arjun

[Steve Lewis]

Check to see if your passive server happens to be plugged into a different VLAN.

Check the switch port configuration, to see if the switch has port security enabled.

I once had a problem where the switches would disable a port if they discovered that an IP address had 'changed' from one MAC address or port to another. Because the customer refused to change their switch security config, we were forced to work around the problem by using lanadmin -A to spoof the MAC address of the passive server to be the same as the real one, before adding the IP to the lan (also to unset this changed MAC address when the real server came back again). That was quite a few years ago. To test this, when the package switches over, are you ever able to connect to the package IP from a remote client or does it work for a few minutes before stopping?

[Thomas J. Harrold]

Have you checked the nettl logs yet? This may clue you in to a network issue, duplicate IP, etc.

netfmt -t /var/adm/nettl.LOG000 (check log file name, but this is default)

-tjh

[Thomas J. Harrold]

Oops, typo in my last suggestion.

Use:

# netfmt -t 10 /var/adm/nettl.LOG000
(formats and displays last 10 entries in the log)

-tjh