Multicast Ghost Application
Support on UNTNET
(Draft Rev. 8/3/01)
UNTNET is now enabled for multicast support in all areas that have the “new” hardware. All department networks with the “new” hardware have multicast capability as long as they do not transit a hub or a “non-multicast” capable switch. The only exception is the dorm network, which is supported on the “old” 7507 router at present.
Symantec Ghost application uses the multicast group address 224.77.X.Y when it sets up a multicast session. Here X.Y is selected at random by the multicast server. Alternatively, the server administrator can also select the multicast group address. To simplify the identification of the multicast group and to guarantee the uniqueness of the multicast group address for each multicast server on campus we need to standardize the multicast group address for all multicast servers on campus. This can be accomplished by selecting X.Y based on the IP address of the multicast server 129.120.X.Y. For example, if the IP address of the multicast server is 188.8.131.52 then its multicast group address would be 184.108.40.206. Here X.Y is derived from the IP address of the multicast server.
In order for us to support multicast traffic and minimize the impact on unicast traffic at the same time we must standardize the proposed multicast addressing scheme. We cannot identify the offending multicast servers (see III. below) on the network if X.Y is selected at random. Therefore, the proposed multicast addressing scheme must be mandatory for all Ghost servers.
Ghost Application and Router Performance
On multicast enabled networks, there should be very little impact on the router CPU utilization with multicast traffic. However, we observed an enormous increase of up to 1000% in the CPU utilization on the core router with multicast traffic. This increase in the CPU utilization can be attributed to a number of factors including switch topology & hardware, client & server hardware and router operation to a varying degree. The most significant impact was the router operation where it inspects each multicast packet after it is dropped because the TTL (IP time to live parameter) is set to 1. The Multicast Ghost server sets TTL=1 when all Clients and server are on the same Layer 2 network (VLAN). The TTL value is dynamically determined by the Ghost server based on the location of the client(s) on the network. To overcome the adverse impact on the router operation at the present time the multicast Ghost server must use TTL >1.
According to Symantec there is no way to manually change the TTL value on the Ghost server. There is no work around from Symantec at this time. According to Cisco the router cannot drop multicast packets with TTL=1 without the impact on the router CPU. There is no work around from Cisco at this time.
We can indirectly change the TTL of the multicast server by deploying at least one client on a non-local network (VLAN). For example, if the server is on Computing Center network and we deploy a client on SCS network. This in effect forces the multicast server to dynamically learn TTL>1. The router will then create a cache entry in the Layer 2 FIB thereby eliminating the need to inspect each multicast packet. We are exploring alternatives to automate this process by providing a non-local (dummy) client to force multicast server(s) to dynamically learn TTL>1.