Problems with Multicast between VLANS

[Migration User]

I'm currently using Ghost Solution Suite 1.1 and having troubles trying to use pqpcast between vlans. For a switch I am running a Cisco Catalyst 6513 with IOS on a sup720. "IP multicast-routing" has been enabled, "ip pim sparse-dense-mode" has been enabled on the vlan interfaces, and igmp is also enabled. The ghost server is running off a Windows 2003 server with all the latest updates. When ghosting in the same vlan it works wonderfully, but I can't get any clients from another vlan to connect.

Thanks,
Ed

[Migration User]

> igmp is also enabled.

I just spent all my Saturday reading the Catalyst 6500 sup720 12.2sx manuals on-line, and I have to say I'm little the wiser for it in terms of the precise mechanics of the inter-VLAN multicast routing it supports in the absence of a separate inter-VLAN ip router.

Much of that, no doubt, is due to the quite different role VLANs play; some people use them to establish separate security domains, and use sophisticated filtering-proxy-capable routers between them, while others use them with multiple switches to overlay a virtual topology separate from the physical wiring topology. Some people map multiple class C IP networks onto VLANs within a single switch for reasons that are no doubt reasonable but which are opaque to me.

In addition to the general layer confusion that you expect with these layer2/3 switches, there is the confusion about PIM versus IGMP; PIM is primarily an inter-router, not a host-to-router protocol, yet some of the documentation - most notably when you look at the Cisco reference docs for ip igmp snooping querier - muddies, rather than clarifies, the role of IGMP versus PIM at the subnet or VLAN level (more level confusions right there). PIM and IGMP do completely different things, yet they are presented as alternatives which is somewhat confusing.

So... assuming Cisco are no help to you, how can we proceed?

I presume you have no separate IP router (to perform IGMP queries), and are relying completely on the sup720's CEF systen for inter-VLAN IP routing, both unicast and multicast.

Although the Cisco reference documentation is vague about ip igmp snooping querier as to whether it relates at all to inter-VLAN routing, can you try enabling an IGMP querier on the GhostCast server's VLAN and one of the others and see if that helps establish routing between them? See http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a00804356ac.html#wp1069655 for an example.

Is there any diagnostic information such as show ip igmp snooping mrouter, show mac-address-table multicast vlan X or show ip igmp interface vlan X that you can share with us?

[Migration User]

Actually, it occurs to me that the problem might not just be with multicast connectivity.

Something you can try is to manually run Ghost32 on a machine running Windows in one of the secondary VLANs, and try and connect to a manual GhostCast session in the primary one. If that connection succeeds but the DOS-based Ghost does not, then the root issue isn't multicasting but something else.

Something that would be helpful is a network trace at the client end to see exactly which phase of the protocol setup is failing, starting with the DHCP interchange when the DOS Ghost client starts.

[Migration User]

After doing some captures from both the server and client. The TTL for both the server and client multicast packets are set to 1, so once it hits the VLAN interface, they are dropped. On both the server and client, only the maximum TTL value can be set. Is there a way to set the minimum TTL value?

[Migration User]

I did a span on both the server port and client port and found out that the TTL value for both are 1. So, once the packet hits the VLAN interface, it is dropped. In Powercast you can set the maximum TTL value, but is there any other TTL value that can be set?

[Migration User]

With the plain old Ghost client, the multicast packet TTL can be configured with the command-line by -js=N. With the GhostCast server it is configurable with "File", "Options...". With the configuration server and its clients, the numbers aren't configurable at present.

In each case the default TTL is the same as Ghost's, which is 16 (except for the client's discovery packets which are 31 for some odd reason). A TTL value of 1 for multicast packets is the Winsock API default, which suggests that it's not being set at all for some reason.

I just did a quick test with a console imaging operation with GSS1.1 and in my trace I saw the TTLs of the multicast packets our code originates set as I'd expect to 31 (for 229.55.150.208, which is the group used for the console client discovery) or 16 (everything else).

I'm somewhat stumped by what could be causing this if both the clients and servers are affected. Is this affecting both console operation and manual GhostCasting?

Can you show us a some of the headers for the affected packets (both for the client and server)?

[Migration User]

Here are links to both the client and server network capture.


Client

Server

[Migration User]

I just installed the Symantec GhostCast Server 8.3 and that works just fine between VLANS.

[Migration User]

Thanks for that, Ed. Unfortunately I can't see any frames generated by our software in either trace, which I presume is due to switch filtering at work - ideally, I need traces taken on the client or server machines or on a separate machine that is sharing the same switch port (a plain old dumb hub is great for this purpose), so I can check on the TTL question.

That said, the trace still clarifies a lot about your setup - I see the subnet structure looks fine, there are IGMP query frames as expected (frame 434 in the client capture, frame 125 in the server capture), the Configuration Server machine is issuing the IGMPv2 membership report for the discovery multicast address in frame 130 of the server capture to its assigned router.

So, that all looks fine.

[Migration User]

The thing that I'm wondering at this point is why both the clients and servers are using an outbound TTL of one. Since that's the Winsock default, that suggests there is some code path that results in this not being set - the more specific detail in a packet trace may allow me to trace back into the code to the why.

One possibility, for instance, is that there's some kind of timing/startup error. The configuration server and client services are supposed to be able to deal with networks being disabled and enabled and coming and going, but perhaps one of those situations can lead to the TTL setting being bypassed.

If you can get a trace that shows some of the multicast traffic our application sends having a TTL of 1, can you also try stopping/restarting the service on the machine without restarting the entire machine and see if the TTL values change to the expected values?