Search

All of Symantec All of Symantec Support Viruses & Risks Home & Home Office Small Business Enterprise Partners VERITAS

Question/Issue:
This document discusses how Ghost performs client and server discovery.


Solution:

---

Before you begin:
This document is provided for the Information Technologies professional. It requires knowledge of advanced networking concepts. Symantec Technical Support does not provide assistance with this document. If you need assistance with information contained in this document, please consult your networking documentation or your Information Technologies department.

---

1. Console & Client

1.1. High Level Protocol
1.2. Console discovery
1.2.1. Method 1: Multicast

1.2.2. Method 2: WINS
2. GhostCast Server

2.1. Multicasting
2.2. Directed Broadcasting
2.3. Unicasting

3. Multicast file transfer and AI deploy tasks

3.1 Overview

3.2 Addresses and ports

4. Internet Group Management Protocol (IGMP)

4.1. Overview
4.2. General information
4.3. RFC2236 - IGMP Version 2
4.4. Cisco Group Management Protocol
4.5. Joining a Multicast Group
4.6. Leaving a Multicast Group

1. Console & Client

The high level protocol used by Console & Client (DOS & Win32)

1.1. High Level Protocol: (CHART)




Sent By	Source Port	Destination Address	Destination Port	Type	Volume
Stage 1 (Server Discovery)
Client	1345,1347	229.55.150.208*	1345,1347	UDP	Low
Client	1347	WINS server	137	UDP	Low
Server	1345, 1346, 1347	Client IP	Varies**	UDP	Low
Stage 2 (Status Update)
Client	1346, 1347	Server IP	1346, 1347	UDP	Low
Server	1345, 1346, 1347	Client IP	Varies**	UDP	Low
Stage 3 (Executing Task)
Client	1346, 1347	Server IP	1346, 1347	TCP	Low
Server	1345, 1346, 1347	Client IP	Varies**	TCP	Med
File transfer steps using Multicast
Client	7777	Server IP	Varies**	UDP	Med
Server	varies	224.77.xxx.xxx	7777	UDP	High


* If Multicasting is not available on the network, then this discovery step will fail and the client will attempt to issue a WINS query after 2 failures to locate the server via multicast (see Console Discovery below).

** "Varies" indicates that an ephemeral port will be allocated for the connection. In Windows, this port range is 1024-4999, though there are registry keys that can adjust this range (this adjustment is a Windows property, not a Ghost property).

1.2. Console discovery

Ghost Clients find the Console using two methods. First, Method 1 is tried, and if that fails, Method 2 is attempted.

1.2.1. Method 1: Multicast
The client sends a Multicast packet to an address and port number that the Console is expecting. All Consoles register their interest in this traffic by sending IGMP (Internet Group Management Protocol) messages. Properly configured routers and switches pass this traffic to the Console. Ensuring that the routers will pass Multicast traffic is usually all that is necessary to get this method working.

1.2.2. Method 2: WINS
Details of this method are shown below for your interest. However, this method relies on a WINS infrastructure existing and working between the networks in question. Usually, if you can browse a computer in the remote site using My Network Places in Windows Explorer, then this method COULD work.

The Console and GhostCast server running on Windows use native API's to register:
1. Group names under which all Consoles (ConfigServer) and GhostCast servers can be found.
2. Individual Consoles (ConfigServers) and GhostCast Sessions.

The following shows the output from NBTStat, which is a standard Windows "NetBIOS over TCPIP" utility. The example used displays the names on a computer with the address 192.168.1.100 and computer name "TESTCLIENT." The command was executed from a computer with the address 192.168.1.89.

C:\>nbtstat -A 192.168.1.100

Local Area Connection:
Node IpAddress: [192.168.1.89] Scope Id: []
NetBIOS Remote Computer Name Table

Name Type Status
------------------------------------------------
TESTCLIENT <00> UNIQUE Registered
DEVTESTDOMAIN <00> GROUP Registered
TESTCLIENT <20> UNIQUE Registered
DEVTESTDOMAIN <1E> GROUP Registered
TESTCLIENT <03> UNIQUE Registered
ConfigServer <1C> GROUP Registered
testclient <2D> UNIQUE Registered
GhostCast <1C> GROUP Registered
testsession <2C> UNIQUE Registered
testsession2 <2C> UNIQUE Registered

MAC Address = 00-02-55-21-71-20

You can see from the output that there are two groups; "ConfigServer" and "GhostCast". In addition, there is one actual Console called "testclient" and two GhostCast sessions called "testsession" and "testsession2." Type <2D> is for unique Consoles and type <2C> is for unique GhostCast sessions. These types are otherwise unused codes which differentiate Ghost in the NetBIOS namespace. The entries shown in uppercase are created by Windows itself using well-defined types (domains, workstations etc). The type of <1C> is actually the same as that registered by Domain Controller machines in Windows Networking. However, all names used by Microsoft NetBIOS networking are uppercase, so the GhostConfig name will not conflict with names registered by Domain Controller machines. The reason that we use <1C> for our ConfigServer and GhostCast groups is because it is treated specially by Microsoft implementations of WINS; it is one of a handful of type codes for which the WINS server obeys the protocol spec and returns a list of the nodes which registered the name (if other name types are used, the WINS server just returns a single result which is an IP broadcast address).

So, discovery of this information is obviously the question. We use two methods, "broadcast" and "WINS". The WINS method requires that we actually know the IP address of your WINS server. This happens if the client is using DHCP and you have registered the WINS address with the DHCP server. This information is therefore delivered to our IP stack during initialization.

The other method, used either because we aren't using DHCP or the WINS server list is empty, is done via a broadcast NetBIOS query. This requires a WINS server ON THE SAME SUBNET to hear the query and respond.

If this does not work, it could be because:
1. The client is using DHCP, but no WINS servers are registered with the DHCP server, AND there are no WINS servers on the subnet.
2. The client is using static IP, and there are no WINS servers on the subnet.
3. The NetBIOS (over TCPIP) ports are blocked at the router. There are four in total. Ports 137-139 are for the netbiosnameservice, Netbios datagram service and Netbios session service.



---

Note: When the WINS server address is supplied by DHCP, the WINS server can be anywhere. It does not have to be on the same subnet as the client.


---

2. GhostCast Server

High Level Protocol used by GhostCast Server & Ghost

2.1. Multicasting: (CHART)



Sent By	Source Port	Destination Address	Destination Port	Type	Volume
Stage 1 (Server Discovery)
Client	Varies**	224.77.0.0/Client IP*	6666	UDP	Low
Server	6666	Client IP	Varies**	UDP	Low
Stage 2 (Status Update)
Client	Varies**	Server IP	Varies**	TCP	Low-Med
Server	Varies**	Client IP	Varies**	TCP	Low-Med
Stage 3 (Executing Task)
Client	7777	Server IP	Varies**	UDP	High
Server	Varies**	224.77.1.0	7777	UDP	Low
Server	Varies**	224.77.xxx.xxx	7777	UDP	High


In Ghost 6.0 (and later versions) the address marked 224.77.xxx.xxx can be set at the Multicast server to be any desired Multicast address. By default (and in earlier versions) it is a random address between 224.77.2.0 and 224.77.255.255.

2.2. Directed Broadcasting: (CHART)




Sent By	Source Port	Destination Address	Destination Port	Type	Volume
Stage 1 (Server Discovery)
Client	Varies**	224.77.0.0/Client IP*	6666	UDP	Low
Server	6666	Client IP	Varies**	UDP	Low
Stage 2 (Status Update)
Client	Varies**	Server IP	Varies**	TCP	Low-Med
Server	Varies	Client IP	Varies**	TCP	Low-Med
Stage 3 (Executing Task)
Client	7777	Server IP	Varies**	UDP	High
Server	Varies**	Client's Subnet Broadcast Address	7777	UDP	High


Directed Broadcasting is only available in Ghost 7.5 and later.

2.3. Unicasting: (CHART)



Sent By	Source Port	Destination Address	Destination Port	Type	Volume
Stage 1 (Server Discovery)
Client	Varies**	224.77.0.0/Client IP*	6666	UDP	Low
Server	6666	Client IP	Varies**	UDP	Low
Stage 2 (Status Update)
Client	Varies**	Server IP	Varies**	TCP	Low-Med
Server	Varies**	Client IP	Varies**	TCP	Low-Med
Stage 3 (Executing Task)
Client	7777	Server IP	Varies**	UDP	High
Server	Varies**	Client IP	7777	UDP	High


Unicasting is only available in Ghost 7.5 and later.

In Ghost 7.5, running multiple GhostCast servers on the same machine with Unicasting results in Ghost.exe often being unable to find the GhostCast server it is interested in. This has been fixed in Ghost 8.0 by allowing the GhostCast servers to forward discovery packets to each other on the same machine using the loopback address's broadcast address (127.255.255.255).

* If Multicasting is not available on the network, then this discovery step will fail. In Ghost 7.5 and above, Ghost.exe and the Console Client (DOS & Win32) will use a fallback method utilizing WINS to find the server. In Ghost 8.0 and later, the packet will be sent directly to the client without using Multicasting if the machine has a single NIC or if supported by the underlying OS (NT 4.0 computers with multiple NICs will try to use Multicasting, for example).

** "Varies" indicates that an ephemeral port will be allocated for the connection. In Windows, this port range is 1024-4999, though there are registry keys that can adjust this range (this adjustment is a Windows property, not a Ghost property).

3. Multicast file transfer and AI deploy tasks

3.1 Overview

In Ghost 8.0, changes were made to allow the file transfer task step and the AI deploy task steps to run over the GhostCast protocol. This provides two advantages over the previous TCP based method:

1. A file transfer to multiple machines (especially with large files) will occur much quicker, as there is only one stream going to all the clients.
2. The throttling capabilities of GhostCasting can now apply to File Transfer tasks.
   
The administrator can choose to use Multicasting, Directed Broadcasting and Unicasting in exactly the same way as in GhostCasting.

3.2 Addresses and ports
The addresses and ports are the same as in chapter 2 "GhostCast server."

4. Internet Group Management Protocol (IGMP)

4.1. Overview

Ghost supports IGMP version 2.
IGMP is designed to be used by hosts to inform routers that they wish to receive Multicast traffic on specific addresses. In this way, routers can decide whether to forward Multicast traffic based on whether a host on a given subnet has requested this or not. In addition, some vendors such as Cisco, extend this functionality by having routers share this information with switches so that the switches will only forward the Multicast traffic to ports with hosts that have requested it. Without this feature, the traffic would effectively be broadcast traffic.

When Ghost joins a Multicast session, it sends out an IGMP packet to let any listening routers know that it wants to receive Multicast traffic sent to a particular address. This packet is addressed to the Multicast address that Ghost wants to join. This is called "Joining a Multicast Group". Similarly, when the session has ended, Ghost sends out another IGMP packet to "Leave the Multicast Group".

For more detailed information, see below.

4.2. General information

When configuring your routers, we find that generally the default settings for Group Membership Time, Max Response Time and Query Interval work well. It's probably a trade-off between the volume of IGMP traffic and the volume of Multicast traffic that is sent but with no one any longer interested in listening to it. Since the Ghost Multicast Server ceases sending Multicast packets at the same time that the clients stop listening, the times for Ghost could be made longer to reduce the IGMP traffic volume, but this volume tends to be negligible, so the defaults are probably just as good.

224.0.0.1 is the address of the All-Systems Multicast Group. IGMP-enabled routers send query commands to this address requesting information about all hosts that need to receive Multicast packets. Each host replies with any Multicast addresses it needs to receive.

224.0.0.2, the All-Routers Multicast Group. Hosts send packets to this address when they are no longer interested in receiving Multicast traffic on a certain address.

4.3. RFC2236 - IGMP Version 2

http://www.faqs.org/rfcs/rfc2236.html

4.4. Cisco Group Management Protocol

This is an excerpt from Cisco documentation on their Catalyst Switches.

For more info see:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/c5k3_1/c5kcg3_1/10multi.htm

CGMP (Cisco Group Management Protocol) works with Internet Group Management Protocol (IGMP) messages to dynamically configure Catalyst 5000 series switch ports so that IP Multicast traffic is forwarded only to those ports associated with IP Multicast hosts.



---

Note: For information on IP Multicast including IGMP, refer to RFC 1112.

---



CGMP software components run on both the router and the Catalyst 5000 series switch. A CGMP-capable IP Multicast router sees all IGMP packets and can inform the Catalyst 5000 series switch when specific hosts join or leave IP Multicast groups. When the CGMP-capable router receives an IGMP control packet, it creates a CGMP packet that contains the request type (either join or leave), the Multicast group address, and the actual MAC address of the host. The router then sends the CGMP packet to a well-known address to which all Catalyst 5000 series switches listen. When a switch receives the CGMP packet, the supervisor engine module interprets the packet and modifies the Encoded Address Recognition Logic (EARL) forwarding table automatically, without user intervention.

You can explicitly set up Multicast groups by entering the set cam static command. User-specified Multicast group settings are static, whereas Multicast groups learned through CGMP are dynamic. If you specify group membership for a Multicast group address, your static setting supersedes any automatic manipulation by CGMP. Multicast group membership lists can consist of both user-defined and CGMP-learned settings.

If a spanning-tree VLAN topology changes, the CGMP-learned Multicast groups on the VLAN are purged and the CGMP-capable router generates new Multicast group information.

If a CGMP-learned port link is disabled for any reason, CGMP removes that port from any Multicast group memberships.

4.5. Joining a Multicast Group

When a host wants to join an IP Multicast group, it sends an Internet Group Multicast Protocol (IGMP) join message specifying its Machine Address Code (MAC) address and which IP Multicast group it wants to join. The Cisco Group Management Protocol (CGMP)-capable router then builds a CGMP join message and multicasts the join message to the well-known address to which the Catalyst 5000 series switches listen. Upon receipt of the join message, each Catalyst 5000 series switch searches its Enhanced Address Recognition Logic (EARL) table to determine if it contains the MAC address of the host asking to join the Multicast group. If a switch finds the host's MAC address in its EARL table associating the MAC address with a nontrunking port, the switch creates a Multicast forwarding entry in the EARL forwarding table. The host associated with that port then receives Multicast traffic for that Multicast group. In this way, the EARL automatically learns the MAC addresses and port numbers of the IP Multicast hosts.

4.6. Leaving a Multicast Group
The CGMP-capable router sends periodic multicast-group queries. If a host wants to remain in a Multicast group, it responds to the query from the router. In this case, the router does nothing. If a host does not want to remain in the Multicast group, it does not respond to the router query. If, after a number of queries, the router receives no reports from any host in a Multicast group, the router sends a CGMP command to the Catalyst 5000 series switch, telling it to remove the Multicast group from its forwarding tables.



---

Note: If there are other hosts in the same Multicast group and they do respond to the multicast-group query, the router does not tell the switch to remove the group from its forwarding tables. The router does not remove a Multicast group from the switch's forwarding tables until all the hosts in the group have asked to leave the group.

---



The CGMP fast-leave-processing feature allows the Catalyst 5000 series supervisor engine module to detect IGMP V.2 leave messages sent on the all-routers Multicast address by hosts on any of the supervisor engine module ports. When the supervisor engine module receives a leave message, it starts a query-response timer. If this timer expires before a join message (an IGMP membership report) is received, then the port is pruned from the Multicast tree for the Multicast group specified in the original leave message. Fast-leave processing ensures optimal bandwidth management for all hosts on a switched network, even when multiple Multicast groups are in use simultaneously.

Document ID: 2002101612025325
Last Modified: 09/15/2009
Date Created: 10/16/2002
Operating System(s): DOS, Windows 95, Windows 98, Windows ME, Windows NT, Windows 2000, Windows XP
Product(s): Symantec Ghost 7.5, Symantec Ghost 8.0, Symantec Ghost 8.2, Symantec Ghost Solution Suite 1.0, Symantec Ghost Solution Suite 2.0
Release(s): Ghost 7.5 [All Releases], Ghost 8.0 [All Releases], Symantec Ghost 8.2 [All Releases], Symantec Ghost Solution Suite 1.0 [All Releases], Symantec Ghost Solution Suite 2.0, Symantec Ghost Solution Suite 2.0 [All Releases], Symantec Ghost Solution Suite 2.5

Site Index · Legal Notices · Privacy Policy · · Contact Us · Global Sites · License Agreements