Multicast Image Deployment failing

[chris.macleod]

Hi,

I am having some problems when deploying images via Multicast using Windows Deployment Server. All imaging sessions are failing after a few minutes. While troubleshooting this issue we tried different images and they fail also - unicast works fine. We have also moved the server to the same switch as the clients and the imaging completes successfully.

Hardware:

Core: Cisco 4507re Sup 6E (All line cards are classic)

Access: Mix of 2950G, 3550, 3560

Switch stacks consist of mix of up to three 2950g and 3550/60 each stack connects to our single 4507re.

Setup:

Clients and Deployment Server are in the same VLAN

All access Switches have default IGMP settings (enabled, v2)

Core 4507 has IP Multicast Routing

Int VLAN x

ip pim sparse-dense mode

Any ideas what I am doing wrong?

Thanks

Chris

[chris.macleod]

I have found that when the source is in the same stack as the receiving devices the deployment is slower but works.

[Giuseppe Larosa]

Hello Chris,

I've seen the traffic graphs and the traffic stays up for 6 minutes so this is not related to the usual timers.

The debug log files showed clearly that 4507 is acting correctly as the IGMP querier for the Vlan.

So we can say the issue shouldn't be related to IGMP snooping activity.

Now, you have added an interesting note that says that you see multicast delivery working when source and receivers are on the same stack.

This would point to a stack issue when dealing with multicast traffic originated / destinated outside the stack itself.

This is strange but possible.

Hope to help

Giuseppe

[chris.macleod]

Hi,

Thought I would update this thread with some new info.

After some playing around I found that only certain images would fail.  The images that Multicast okay could be taken anywhere in the Campus and deployed successfully.  Images that failed at the exact same percentage each time – transfer rate would immediately drop to zero and never recover.

I found that disabling DHCP Snooping on our Core Switch solved the problem.  I can actually disable DHCP Snooping on our core switch after a Multicast session has failed (transfer rate dropped to zero) and the session recovers.

DHCP Snooping is enabled on all our access switches so I am happy to leave DHCP snooping off on the core, maybe it is advised?  Can anyone shed any light on why DHCP Snooping would cause this issue?

Thanks

Chris

[Giuseppe Larosa]

Hello Chris,

you have been very kind to provide a feedback on this open issue.

The relationship between multicast and DHCP snooping is not immediate.

Generally speaking DHCP snooping should be enabled only at access layer if core switches have no end users connected on them.

In other cases other colleagues have reported high cpu usage also on C6500 switches after having enabled DHCP snooping, probably caused by a bug.

Hope to help

Giuseppe

[chris.macleod]

Hi Giuseppe,

The CPU usage was always low.  All the access switches have DHCP Snooping enabled so I will leave it off on the core.

Thanks for taking time to help with this issue!

Thanks

Chris