Solved: Re: Intervlan Multicast on a 4510r

Don Maker · ‎02-03-2014

We have a 4510r as our distribution switch. Recently we have been asked to enable ip multicast so that some network projectors can be discovered by laptops in different vlans. At this moment the requirement does not grow beyond that. We have 3560s in the access layer and the afroementioned 4510 in the distribution. So I'm not touching my core layer at all The 3 vlans in question are all defined on the 4510.

On the 4510 I did a:

ip multicast-routing in global config, and then on the three vlan interfaces in question I did a:

ip pim dense-mode.

Is there anything else that I should need to do? I can ping the multicast group addr ( 239.255.255.250) and I get a bunch of responses but I don't see anything from the device I am trying to discover.

I can see a last reporter from that group in that vlan ( 241). There are two projectors, 192.168.241.10, and .11

sh ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.255.253 Vlan216 01:39:23 00:02:24 0.0.0.0

239.255.255.250 Vlan212 03:22:14 00:02:25 192.168.212.128

239.255.255.250 Vlan216 03:22:33 00:02:17 192.168.216.10

239.255.255.250 Vlan241 03:22:54 00:02:17 192.168.241.10

239.255.255.246 Vlan216 01:39:24 00:02:17 192.168.216.10

234.5.6.8 Vlan216 00:00:59 00:02:17 192.168.216.10

226.178.217.5 Vlan212 01:42:00 00:02:27 192.168.212.15

232.44.44.233 Vlan212 03:22:13 00:02:25 192.168.212.10

232.44.44.233 Vlan216 03:22:33 00:02:17 192.168.216.10

239.77.124.213 Vlan216 03:22:33 00:02:17 192.168.216.10

224.0.1.60 Vlan216 00:02:16 00:02:17 192.168.216.10

224.0.1.40 Vlan241 03:22:18 00:02:20 192.168.241.1

Here is my sh ip mroute:

sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.253), 00:07:46/00:01:15, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan216, Forward/Dense, 00:07:46/00:00:00

(*, 239.255.255.250), 00:09:54/00:02:16, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 00:09:54/00:00:00

Vlan216, Forward/Dense, 00:09:54/00:00:00

Vlan241, Forward/Dense, 00:09:54/00:00:00

(*, 239.255.255.246), 00:09:49/00:02:10, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan216, Forward/Dense, 00:09:49/00:00:00

(*, 234.5.6.8), 00:10:17/stopped, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan216, Forward/Dense, 00:02:09/00:00:00

(192.168.217.18, 234.5.6.8), 00:00:17/00:02:42, flags: PT

Incoming interface: Vlan216, RPF nbr 0.0.0.0

Outgoing interface list: Null

(*, 226.178.217.5), 00:10:13/stopped, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 00:10:13/00:00:00

(192.168.212.15, 226.178.217.5), 00:00:13/00:02:46, flags: PT

Incoming interface: Vlan212, RPF nbr 0.0.0.0

Outgoing interface list: Null

(*, 232.44.44.233), 00:09:49/00:02:16, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 00:09:49/00:00:00

Vlan216, Forward/Dense, 00:09:49/00:00:00

(*, 239.77.124.213), 00:09:49/00:02:10, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan216, Forward/Dense, 00:09:49/00:00:00

(*, 224.0.1.60), 00:10:07/00:02:56, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan216, Forward/Dense, 00:03:26/00:00:00

(*, 224.0.1.40), 00:10:29/00:02:09, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan241, Forward/Dense, 00:10:29/00:00:00

AND pim interface:

sh ip pim inter

Address Interface Ver/ Nbr Query DR DR

Mode Count Intvl Prior

192.168.241.1 Vlan241 v2/D 0 30 1 192.168.241.1

192.168.216.1 Vlan216 v2/D 0 30 1 192.168.216.1

192.168.212.1 Vlan212 v2/D 0 30 1 192.168.212.1

This is pretty new to me, so not sure if I am missing something obvious.

Any suggestions?

Jon Marshall · ‎02-04-2014

Don

It needs to be greater than 1 to account for the L3 hop between vlans.

So it needs to be 2 or more for it to work across vlans.

Jon

View solution in original post

Jon Marshall · ‎02-03-2014

Don

There is nothing missing from your configuration (assuming IGMP snooping is enabled but it is usually on by default).

Do the network projectors generate a multicast stream ?

If you look at your "sh ip mroute" output for the multicast group you are interested there is only a (*, 239.255.255.250) entry. What you should be seeing with pim dense mode is a (, 239.255.255.250) entry where source IP is one of the projectors.

That stream is then flooded to any vlans that have registered an interest in the stream with IGMP requests ie. laptops in vlans 212 and 216.

It doesn't look from your outputs as though the projectors are actually generating a multicast stream.

Jon

Don Maker · ‎02-03-2014

Thanks. That is sort of what I was thinking. I am told that the projectors use WSD ( Web Services on Devices) which uses multicast for discovery. But I've been banging my head on the wall today trying to figure out why this won't work. It works locally, as I mentioned, if both devices are in the same vlan.

The projectors are an appliance being built and designed here and the inside is a Windows 8 I believe. So it's the windows network projector discovery service that I'm trying to get working. I believe that uses WSD for discovery...

Jon Marshall · ‎02-03-2014

Don

It works locally, as I mentioned, if both devices are in the same vlan.

That is strange as it should work across vlans. Can you check that the TTL in the multicast packets are > 1 ie. the TTL needs to account for the L3 hop to the laptop vlans.

The TTL setting would be within the application settings on the projectors ie. nothing to do with the switch(es).

Jon

Don Maker · ‎02-03-2014

Thanks again for the response, I will need to have someone get that information from the dev team that is building that product.

paul driver · ‎02-03-2014

Hello

can you post the following from the switches active in MC

sh ip pim neighbors

sh ip pim interface count

sh ip pim rp-mapping

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Don Maker · ‎02-03-2014

There is really only one switch active in MC. All access layer switches are 3560's that are only doing L2. The routing is done on the 4510 between the vlan interfaces. I did run the commands on one of the 3560s but there was no output at all.

Here is the output from the 4510:

sh ip pim nei

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

S - State Refresh Capable

Neighbor Interface Uptime/Expires Ver DR

Address Prio/Mode

ktsw-B-distribution#sh ip pim interface count

State: * - Fast Switched, D - Distributed Fast Switched

H - Hardware Switching Enabled

Address Interface FS Mpackets In/Out

192.168.241.1 Vlan241 * H 3006/83

192.168.216.1 Vlan216 * H 239307/49

192.168.212.1 Vlan212 * H 1111925/16

ktsw-B-distribution#

ktsw-B-distribution#show ip pim rp mapping

PIM Group-to-RP Mappings

This is PIM-DM, though, so would there be RP mappings?

paul driver · ‎02-04-2014

Hello

Sorry to ask this - Do you have ip routing enabled on the core and any of the access switches?

I have labbed this up the best i could- please see the results:

core switch:

snooping enabled by default

ip multicast-routing distributed

pim dense mode enabled on SV'sI

sh ip pim interface | in Vlan

192.168.212.1 Vlan212 v2/D 0 30 1 192.168.212.1

192.168.216.1 Vlan216 v2/D 0 30 1 192.168.216.1

192.168.241.1 Vlan241 v2/D 0 30 1 192.168.241.1

Core#sh ip mroute | b In

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:00:37/00:02:32, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 00:00:37/00:00:00

(*, 239.255.255.246), 00:00:37/00:02:33, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan216, Forward/Dense, 00:00:37/00:00:00

(*, 234.5.6.8), 00:00:37/00:02:34, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan241, Forward/Dense, 00:00:38/00:00:00

Host (192.168.212.10 - vlan 212 - attached to access switch)

Host#ping 234.5.6.8 repeat 5

Reply to request 0 from 192.168.212.1, 4 ms

Reply to request 1 from 192.168.212.1, 1 ms

Host#ping 239.255.255.246 repeat 2

Reply to request 0 from 192.168.212.1, 1 ms

Reply to request 1 from 192.168.212.1, 1 ms

core

Corew#sh ip mroute | in 192.168.212.10

(192.168.212.10, 239.255.255.246), 00:02:20/00:00:48, flags: LT

(192.168.212.10, 234.5.6.8), 00:02:48/00:00:29, flags: LT

The only time I produced the similar output to yourself was when I disabled ip routing on the core and ping the MC address residing on the same vlan.

Host#ping 239.255.255.250 repeat 2

Reply to request 0 from 192.168.212.1, 4 ms

Reply to request 1 from 192.168.212.1, 1 ms

core

sh ip mroute | b In

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:04:06/00:02:18, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 00:04:06/00:00:00

I doubt you would have ip routing disabled on a core switch but is it enabled on any of the access switches also, if not than I agree with Jon that the problem looks like its originating from the source of the MC flow.

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Jon Marshall · ‎02-04-2014

Paul

I may be misunderstading but IP routing does not need to be enabled on the access switches, only on the core.

The issue is that there is no source specific multicast group entry for the stream.

I suspect this may be an issue with how the projectors actually use multicast. It works on the same LAN but not across L3 hops which suggets a TTL issue but i am not entirely sure how it is meant to work.

Jon

paul driver · ‎02-04-2014

Hello Jon

Yes you are correct - Just to verify - I didn't mean to suggest ip routing is required on the access switches maybe it was the way I posted my reply -

what I was trying to say is that if IP routing was enabled by mistake on the access switches or it wasn't enabled on the core, Then lab test I performed produced a similar output to the OP in that, the mroute table of the core switch regards showing no actual MC source being reported.

Apologies to all if my post was a bit misleading

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Jon Marshall · ‎02-04-2014

Hi Paul

what I was trying to say is that if IP routing was enabled by mistake on the access switches or it wasn't enabled on the core

my mistake not yours. I should have read your post more carefully.

Hadn't had my first cup of coffee of the day

Jon

Don Maker · ‎02-04-2014

Hi.

Routing is not enabled on the access switches. Routing is enabled on the 4510r. I can ping the multicast addr in question ( 239.255.255.250) from the 4510 and I get many responses ( mostly printers and such), but nothing from the projectors. I can see the projectors in the igmp groups command output, but cannot ping them. Multicast is only used by the projectors for discovery purposes, so I'm told. So if you use the Windows "Connect to a Network Projector" it will use that multicast addr and udp/3702 to discover any Windows Network Projectors on the network. This works on the same segment, but does not seem to want to cross vlans right now.

One small note, I only did a ip multicast-routing on the 4510r, not a ip mulitcast-routing distributed command.

Don Maker · ‎02-04-2014

Here is the output, just now, of an show ip mroute, sh ip igmp groups, and a MC ping to 239.255.255.250. I can see one of the projectors ( 192.168.241.11) in the igmp groups, but it does not show up in a MC ping, nor can I discover it across vlans.

ktsw-B-distribution#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 17:41:15/00:02:30, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 17:41:15/00:00:00

Vlan241, Forward/Dense, 17:41:15/00:00:00

(*, 226.178.217.5), 17:41:34/stopped, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 17:41:34/00:00:00

(192.168.212.15, 226.178.217.5), 00:01:37/00:01:22, flags: PT

Incoming interface: Vlan212, RPF nbr 0.0.0.0

Outgoing interface list: Null

(*, 232.44.44.233), 17:41:09/00:02:30, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 17:41:09/00:00:00

(*, 224.0.1.40), 17:41:48/00:02:09, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan241, Forward/Dense, 17:41:48/00:00:00

ktsw-B-distribution#sh ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.255.250 Vlan212 20:54:52 00:02:22 192.168.212.150

239.255.255.250 Vlan241 20:55:33 00:02:53 192.168.241.11

226.178.217.5 Vlan212 19:14:38 00:02:23 192.168.212.15

232.44.44.233 Vlan212 20:54:52 00:02:21 192.168.212.138

224.0.1.40 Vlan241 20:54:56 00:02:55 192.168.241.1

ktsw-B-distribution#ping 239.255.255.250

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 239.255.255.250, timeout is 2 seconds:

Reply to request 0 from 131.194.168.192.in-addr.arpa.fqdn.unknown.com (192.168.194.131), 8 ms

Reply to request 0 from sales-mfp.cds,int (192.168.228.106), 8 ms

Reply to request 0 from 192.168.194.19, 8 ms

Reply to request 0 from exec-mp201.cds.int (192.168.197.106), 8 ms

Reply to request 0 from 192.168.194.124, 8 ms

Reply to request 0 from 192.168.194.199, 8 ms

Reply to request 0 from 192.168.194.145, 8 ms

Reply to request 0 from 192.168.194.191, 8 ms

Reply to request 0 from 192.168.194.135, 8 ms

Reply to request 0 from 192.168.194.177, 8 ms

Reply to request 0 from 192.168.194.129, 8 ms

Reply to request 0 from 192.168.194.148, 8 ms

Reply to request 0 from 192.168.194.171, 8 ms

Reply to request 0 from 192.168.194.202, 8 ms

Reply to request 0 from 192.168.194.120, 8 ms

Reply to request 0 from 192.168.194.136, 8 ms

Reply to request 0 from 192.168.194.146, 8 ms

Reply to request 0 from 192.168.194.20, 8 ms

Reply to request 0 from 192.168.194.188, 8 ms

Reply to request 0 from ve4-mfp.cds.int (192.168.194.112), 8 ms

Reply to request 0 from ve-exec-mfp.cds.int (192.168.194.115), 8 ms

Reply to request 0 from cmh-mfp.cds.int (192.168.194.114), 8 ms

Reply to request 0 from ve3-mfp.cds.int (192.168.194.113), 8 ms

Reply to request 0 from 192.168.194.176, 8 ms

Reply to request 0 from 192.168.194.139, 8 ms

Reply to request 0 from 192.168.194.128, 8 ms

ktsw-B-distribution#

Don Maker · ‎02-04-2014

I can confirm that MC is working across vlans in general as the vlan that had most of the devices in it, printers and such, did not have a pim command on it as I did not want it participating in MC. But for test purposes I just put a ip pim dense-mode on that SVI and was then able to do a successful MC ping from my workstation that resides in another pim enabled vlan. So at least I know that MC routing in general should work with my setup.

Jon Marshall · ‎02-04-2014

Don

With pim dense mode the important entry in your mroute is the one with a source IP as well as the group ie. not this one -

(*, 239.255.255.250), 17:41:15/00:02:30, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan212, Forward/Dense, 17:41:15/00:00:00

Vlan241, Forward/Dense, 17:41:15/00:00:00

as you can see there is no source IP ie. just a * entry. For multicast routing to work there must be a stream to route ie. IGMP queries are not routed, only the actual stream. But from your outputs there is no stream.

I did a bit of hunting on Miscrosoft's site on Web Services on Devices and i found this where it suggests there are two ways for clients to discover devices -

The Web Services on Devices stack and API (WSDAPI) implementation provides the following discovery mechanisms, each of which can allow a client application to find and access a device host.

Service availability multicast

The device host uses UDP to multicast a service availability message. This message cannot make use of a secure channel, so this type of service discovery does not support authentication. The WSDAPI implementation does not offer authentication, however, the WS-Discovery specification provides an avenue for authentication. Typically, the multicast message does not traverse IP routers, so only the client applications on the same subnet as the device host can receive the service availability multicast.


Directed discovery

The client application uses TCP to send a directed discovery message. This message can make use of a secure channel, so this mechanism supports authentication. Also, these messages can traverse an IP router, so this mechanism allows client applications to discover a device hosts that is located on a remote subnet.