02-03-2014 12:29 PM - edited 03-07-2019 05:58 PM
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?
Solved! Go to Solution.
02-04-2014 10:55 AM
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
02-03-2014 12:47 PM
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 (
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
02-03-2014 12:56 PM
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...
02-03-2014 01:00 PM
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
02-03-2014 01:03 PM
Thanks again for the response, I will need to have someone get that information from the dev team that is building that product.
02-03-2014 02:29 PM
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.
02-03-2014 05:04 PM
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?
02-04-2014 01:51 AM
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.
02-04-2014 01:59 AM
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
02-04-2014 02:29 AM
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.
02-04-2014 02:47 AM
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
02-04-2014 05:51 AM
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.
02-04-2014 06:02 AM
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#
02-04-2014 06:08 AM
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.
02-04-2014 06:34 AM
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.
So from the above when using multicast mode i would expect the projector (the device host) to multicast out a message and this would then be multicast routed by your switch onto those vlans that the switch received IGMP queries.from.
Perhaps within the same vlan they were using the other method where they sent a TCP packet to discover the projector ?
Either way i don't think it is the switch configuration, it is to with the projectors and whether or not they generate a multicast stream for your switch to forward.
Jon
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: