Can't run Symantec Ghost over Cisco 3524 switch

jfraasch · ‎03-04-2003

We were upgrading an older HP switch to a newer Cisco 3524 switch and once we made the move we were not able to Ghost any of the PCs that were located on the switch. All the effected PCs were connected to the same switch and all were in the same VLAN. There wasn't anything funny about our setup.

I opened a case with Cisco TAC and all they said was there was not a workaround for this issue, but they never really told me what the issue was.

Has anyone else run into this problem before? If so, what did you do?

efrahim · ‎03-04-2003

Ghost uses multicast to communicate with the machines and multicast means that they have to be flooded all over the ports, if the switch is not running the multicast.. You can try add static multicast entries or configure cgmp so that unnecessary ports won't able to see it if this causing the ports to unable to run ghost. or make sure you don;t have any kind of filtering confugured to control broadcast strom etc.

Do you run the ghost on all the machines at the same time.

Here is the link on the multicast

http://www.cisco.com/warp/customer/473/22.html

makkers · ‎03-04-2003

We have had this problem which is resolved by enabling portfast on each port of the switch that your cleint machine is connected to.

If you are trying to ghost an image to a pc from boot, basically, if the client doesnt see the multicast server or establish ip add within 15 secs or so it assumes its not there. Spanning tree takes approx 50secs to establish and verify a connection hence the client machine timeout.

Same applies to Winterms and some pedantic DHCP scenarios, and portfast always provides the fix. Be aware of the portfast risks though!!

Hope this helps.

milan.kulik · ‎03-04-2003

Could you provide some details of your problem?

The clients are not seen on the Ghost server console at all?

Or the switch is flooded by multicasts at the Ghost session time?

I've spent a long time playing with Ghost in our network (multicast flooding problem) and finally (after some IGMP and CGMP settings) it works fine.

Regards,

Milan

jfraasch · ‎03-05-2003

Basically what happens is that the server IS able to see all the clients but when you try to actually send the images out, the clients dont receive the data.

The post before your solved the problem. Enabling PortFast on all the client ports fixed the problem. Don't know exactly how it fixes it but I will take the win anyday!

Report Inappropriate Content · ‎04-24-2003

Hi Milan

Maybe I can draw on your experience? We are having multicast flooding issues on our network. Currently we have the following basic switching interconnections throughout:

[Ghost Server]--cat5--[Catalyst 6509]--fibre--[Catalyst 3524]--cat5--[Nortel 350T]--cat5--[Client]

or

[Ghost Server]--cat5--[Catalyst 6509]--fibre--[Nortel 350T]--cat5--[Client]

Could you please offer some suggestions on how to control flooding given these interconnections?

Sincerely,

R

rjackson · ‎04-24-2003

The portfast solution is the answer. we had the same problem. this is how our 3524s are configured and we ghost all the time

!

interface FastEthernet0/1

switchport access vlan 325

spanning-tree portfast

!

interface FastEthernet0/2

switchport access vlan 325

spanning-tree portfast

!

interface FastEthernet0/3

switchport access vlan 325

spanning-tree portfast

!

interface FastEthernet0/4

switchport access vlan 325

spanning-tree portfast

Report Inappropriate Content · ‎04-24-2003

I see how this would work with respect to fixing client connection timeouts; however, I will not be enabling portfast on aggregate switches (STP does serve a purpose afterall). As per my posted interconnection information, and I apologize if it is unclear, the actual edge switching is non-cisco gear... So far what I've been able to deduce is that Cat 3524s don't support IGMP but do use CGMP to manage multicast groups. Our current edge switches (Nortel 350Ts) obviously don't support CGMP but do support IGMP... Another issue that I'm concerned about is that of HSRP and CGMP compatablity issues and how this my affect me at our core (where we rely on HSRP). I guess I'm hoping that others have already dealt with similar issues and can offer some guidance.

Regards,

R.

milan.kulik · ‎04-24-2003

Hi,

my solution is following:

1) set a mutlicast storm control on the port the Ghost server (multicast source) is connected to the network. I'm using 2000 rising and 1500

falling thresholds. This decreases the absolute number of multicasts flooded to the network. So even if all other features fail your network will not be flooded by multicasts.

I'm not sure if Catalyst 6509 supports this feature. If not, move the Ghost server to Cat3524 which does.

The commands on Cat3524 are

interface FastEthernet.....

description Ghost

port storm-control broadcast action filter

port storm-control broadcast threshold rising 2500 falling 1500

port storm-control multicast action filter

port storm-control multicast threshold rising 3000 falling 2000

Tune the treshold values regarding your Ghost traffic (I'm using the above ones).

2) enable IGMP snooping on switches which are IGMP-snooping enable (Cat6500, 2950) and set CGMP enable on switches which are not

(Cat4000). On Cat3500 and 2900 CGMP is enabled by default.

3) configure

ip pim sparse-mode

ip cgmp

on your router LAN port.

You need a router to "translate" from IGMP to CGMP.

If the Ghost server and the client PC are in different VLANs you need to configure multicast routing on your router which is more complicated.

My solution is not describing it, I'm just fixing multicats flooding in one VLAN.

Don't use CGMP fast-leave if you're using HSRP in your network (address conflict).

The way this scenario works:

At the moment wokstation joins a multicast group it sends a IGMP join message. IGMP-enable switches detects it and they send multicast

traffic to appropriate ports only then. IGMP-not-enabled switches receive this info through CGMP - a router "translating" from IGMP to CGMP

is necessary.

There are some minor problems remaining (if the workstation joins several multicast groups rapidly it takes some time to detect it and

aproximately 30 sec multicast storm apears, e.g.) but generally this scenario works.

The above description is very rough, for detailed info see:

http://www.cisco.com/warp/public/473/38.html

http://www.cisco.com/warp/public/473/22.html

http://service4.symantec.com/SUPPORT/ghost.nsf/docid/1999033015222425

A good news in the end: There is a new Ghost version available which should be much more flexible and user friendly regarding unicats/multicasts options. It should enable using unicasts to send image to one PC and leave multicast as on option for image distribution to a PC group.

Hope to help,

Milan

Report Inappropriate Content · ‎05-08-2003

Thank You Milan

I will use your advice as a general framework in preproduction and will let you know what happens.

Sincerely,

R.