Multicast (bonus: real world scenario)

I'm posting this here since it seems to be the most applicable place.

The techs at my new job do a LOT of imaging PCs. There's a ghost server, but they normally just mount the c$ and install from the mount point (net use K: \\server\c$). For a lot of images they'll copy the directory to one of their PCs and share that for a second stream of unicasts. I brought up getting multicast working and was told it's been tried before, but nobody has ever gotten it working. Here's my opportunity to get some cred, but I've been trying to make it work for a week off and on with no luck. I thought I'd understood how it works, and I still do (in theory I guess), but it's just. not. working.

The topology is pretty simple. The network is completely flat. There are multiple vlans, but vtp is running and the same L3 switch (a 4500 series) is the DG for all devices, so is the only one doing any routing.

I have 2 test PCs set up right now, and the path between the source and clients is as follows:

[server] ---vlan 20--- [3560] ---(t)--- U]4500[/U ---(t)--- [4500] ---(t)--- [4500] ---(t)--- [3560] ---vlan 201--- [pcs]

I originally thought igmp would be able to be used on everything except the underlined 4500 (the DG for everything), but I've messed with almost every combination I could think of, from enabling pim on all the 4500s (the 3560's don't seem to support anything except pim passive), to trying different vlan paths (vlan 1 is native on all trunks, but I wouldn't think that would matter), etc.

Anyone have any input that might help me get this working? I don't have internet at work (yet), so can't provide any debugs or shows at the moment, although I haven't had much luck with any of the debug or show commands I've found and tried.

Find more posts tagged with

Comments

jamesp1983

Have you tried debug ip mpacket?

networker050184

Multicast routing enabled?

What's the mroute table look like?

IGMP interface show command?

bermovick

I ran debug ip mpacket on the first 3560 near the end of today, when I found it in the debug options, but didn't see any packets when I specified the destination group address I was able to get via show ip igmp snooping groups (I think that was the command, or something similar) near the destination. Running debug ip mpacket alone was very spammy with other info.

multicasting routing is enabled. I tried originally with it off most of the way (since only one switch needs to move the packets between vlans), but noticed it does need to be on. Having L3 switches makes it confusing since all the documentation specifies igmp for switches, pim between routers (mostly).

mroute table is ugly - lots of unknown things in there. I've been able to see the mroute (sometimes) when I check it.

I think I'm just confused, with them all being L3 switches, on where igmp is in play and where pim needs to be. It gets confusing since an RPF check would make me think you'd need to put (and keep) the mcast packets on vlan 1 since the default-gateway of the switches themselves is on vlan 1. But .... it's really confusing, for such a simple network.

jamesp1983

Look into no ip mroute-cache... be careful with the debug.

Zartanasaurus

Where are the default-gateways for the PCs and servers located? I'm guessing just that 3560 that is attached to VLAN 20 in your picture?
Looking at your diagram, I'd say just enable IGMP snooping on all devices, and PIM on the vlan 20, 201 interfaces on that 3560 to the far left.

Then type sh ip igmp snooping mrouter on the access switch to the far right.
You should see some output like this:
Vlan ports
201 (upstream trunk interface)

If that far left 3560 only supports PIM passive, you need to upgrade the IOS to IP services.

If you don't get that, it means the switch is not seeing the PIM messages being generated by the 3560. The access level, IGMP snooping devices listen for PIM messages so it knows which interface to consider a member of all IGMP groups.

I've never done multicast under ghost, but I'm guessing it's similar to WDS/SCCM where you specify a range of multicast IPs as well as enabling multicast for image distribution.

Note: The mroute table is going to be ugly, because there's a lot of devices like printers out there that have mDNS or some proprietary multicast group enabled by default.

networker050184

If only one device is routing then that is the only one that needs multicast routing enabled. You shouldn't need PIM at all in this situation as there shouldn't be any multicast groups that need to be shared.

Zartanasaurus

networker050184 wrote: »

If only one device is routing then that is the only one that needs multicast routing enabled. You shouldn't need PIM at all in this situation as there shouldn't be any multicast groups that need to be shared.

No, but switches that are running IGMP snooping listen for the PIM messages to discover its port connected to the mrouter in the topology. The switch then proxies the IGMP Membership Reports and Leave messages and forwards them to the mrouter only when neccessary. An example of this would be receiving a Leave for a group that still has other members. There's no need for the mrouter to hear the Leave, so the switch drops it until the last host sends a Leave.

If you do a show ip igmp snooping groups on an access switch, you'll notice that the port under show ip igmp snooping mrouter is a member of every group that is joined. What I think is happening in his scenario is the access switch to the far right is getting IGMP joins, but he isn't sending the joins upstream towards the mrouter. Which means the intervening switches don't have the downstream (or upstream) port as a member of the group, so multicast packets won't go downstream.

bermovick

Zartanasaurus wrote: »

If you do a show ip igmp snooping groups on an access switch, you'll notice that the port under show ip igmp snooping mrouter is a member of every group that is joined.

I think this may be the case, as that command only lists both up- and down- stream ports on the end 3560's. All the 4500's list only the downstream ports, if memory serves. I'm home for the holidays now sadly, so won't be able to check if it was the up- or the down- that was listed, but each of them only listed one or the other.

Zartanasaurus

The suspense is killing me.

bermovick

Sorry; I haven't been trying to get it working any this (short) week. I don't have any new information.

bermovick

If anyone is still following this, I have a computer now with internet access at work. Some information.

[server] ---vlan 20--- [3560] ---(t)--- U]4500[/U ---(t)--- [4500] ---(t)--- [4500] ---(t)--- [3560] ---vlan 201--- [pcs]

On the underscored 4500 from my original image (copied above), debugs show information coming in on the port-channel going towards the PCs.

IGMPSN: group: Received V2 report for group 224.77.255.10 received on vlan 201, port Po64
IGMPSN: group: Added port Po64 to gropu 224.77.255.10
IGMPSN: group: Forwarding 224.77.255.10 report to router ports

Checking the mroute looks ok too (... maybe):

(*, 224.77.255.10), 00:47:05/stopped, RP 10.255.255.1, flags: SJC
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
   Vlan201, Forward/Spare-Dense, 00:42:53/00:02:37, H

(192.168.128.116, 224.77.255.10), 00:00:02/00:02:57, flags: T
 Incoming interface: vlan22, RPF nbr 0.0.0.0, Udlr
 Outgoing interface list:
  Vlan201, Forward/Sparse-Dense, 00:00:02/00:02:57, H

One big point of confusion is that the source is NOT on vlan 22

Routing entry for 192.168.128.0/22, supernet
 Known via "connected", distance 0, metric 0 (connected, via interface)
...
 * directly connected, via Vlan20
   Route metric is 0, traffic share count is 1

This network is a bit of a mess though. There's no routing except at that core 4500, yet every switch has an SVI for every vlan (I've been working on removing those, but I wouldn't think it would have any impact here)

bermovick

As a note, I got it working today. ip pim passive was/is configured on a bunch of the vlan interfaces of the other switches in the network. I removed it from all the vlan 22's after reading on a cisco whitepaper how bad that was. The mroute changed to vlan 20 and we were good to go. Still not entirely sure how that made the RPF fail or make the incoming interface vlan 22 when the sender is directly connected on 20, but I knew that was what the issue was.

Tomorrow comes the real test. 140 computers need re-imaged as there was an issue with the image we put on a few weeks back (needs SP1 and possibly IE9)

pert

I'm a little confused on the problem..

Does the imaging program use IGMPv2 or v3?
If it's v2, is the Core router the RP?
Why are there SVIs built on the L2 switches?

All you should need to do is enable mrouting at the core, enable pim and igmp vX on the SVIs you want multicast, and remove the SVIs off the l2 switches.

bermovick

Pretty much yes - but it still wasn't working because every other switch (with all those stupid SVIs) also had pim passive configured so counted itself as a DR, screwing up the RPF (somehow).

I've been gradually removing the unneeded SVIs from all switches except the core - but my senior guy keeps adding new ones. (he says it helps the switches route to the destination.......)