Ghost Solution Suite

Quite frequently when running a multicast session which either spans mulitple subnets or are contained within a single subnet 1 or more clients fail to connect. On investigating this, tests such as Ping fail to reply from both server and client, from the client it is still possible to contact get a reply from all other machines on the network just not the ghost server. The only thing that resolves the issue is to reboot the server, at which point subsequent connections from the failed ip address are made succesfully. This is not isolated to one subnet in particular but is common across all the subnets served by the multihomed server. All our switches and network infrastructure is fully capable of running multicasts which does not go to explain why only random IP's fail until rebooting the server. Once failed the IP address in question will not connect to ghost until the server is rebooted even if it is forced manualy onto a different client.

This behaviour is only ever seen when running a console session or running a ghost server session. If we join a session via our installed 3com Pxe boot services we always get 100% success on joining sessions.

We have many other mulithomed servers in our establishment and none of them are displaying this behaviour, has anyone else experienced this with GSS 2.0 built on 2003Svr Standard, if so would realy appreciate a fix. This is stopping any fully automated procedures due to the sureity that some are going to fail.

Hi,

Do you see this issue when Clients are in Dos or Windows? (assuming you are running a Console task)

If it is in DOS, does the client work if it boot to Windows?

Krish

Thx for the reply Krish,

This only shows up in Windows not in DOS, PXE services work 100% everytime. If we manually set the IP address on the problematic client to a different address it will work ok with the console. If we use the problem IP address on a different client the problem follows the IP from machine to machine.

To me this suggests some form of cache on the server side as opposed to any issue on the client(s).

Hi,

If you delete the arp cache in the server with 'arp -d', instead of restarting the server, does it make any difference?

Krish

We have previously checked the cache for obvious errors when this has happened but not actualy deleted it, we will try this next time we get the problem. Will edit this again once the problem re-surfaces.

Just checked the arp cache again just now as the problem has come back.

All the IP addresses that are non contactable have static entries. These have not been created manually so not sure why and what is creating static entries as opposed to dynamic as expected. Once these static entries have been deleted the clients report in to the server, have dynamic entries created and are visible through the console.

We could run a scheduled arp -d command but would prefer to find a solution rather than a work around if possible.

Thanks again
Dave

Hi,

Do you run the PXE server in the same machine as the Console?

There is a related discussion with lot more explanations in

https://forums.symantec.com/syment/board/message?board.id=109&message.id=6212

Apart from what is discussed there, I have only seen this behavior when the DHCP server has very small amount of free addresses. DHCP seems to optimize the address allocation leading to allocate different IPs to same machine when requested at different times. Could this be the status of your address pool?

Krish

Krish

OUr DHCP is running at 60% adress usage max so no probs there, lease set to 16 days. But we are running the 3Com PXE service on the same machine so that is where the cause must be coming from.

Thanks for the help, we will schedule a arp -d to run and see how get on.

Cheers
Dave