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 06:43 AM
Thanks for the reply Jon. I guess I may have to start capturing some packets to get to the bottom of this. I am curious about the TCP directed discovery mentioned by MS. If the devices are using that method, then it is not crossing a router either since no discovery is happening across vlans right now.
02-04-2014 06:48 AM
Don
If the devices are using that method, then it is not crossing a router either since no discovery is happening across vlans right now.
Good point.
I would try, as you say, capturing packets coming from the projectors.
Jon
02-04-2014 07:34 AM
What I find interesting is that I just put my laptop switchport into the projector vlan, 241. Assigned myself a static addr there and confirmed that I can ping the projectors, 241.10 and 241.11, however I get no response from a ping to the multicast address that they are supposed to be using? I should see a response, no?
C:\>ping 192.168.241.10
Pinging 192.168.241.10 with 32 bytes of data:
Reply from 192.168.241.10: bytes=32 time<1ms TTL=128
Reply from 192.168.241.10: bytes=32 time<1ms TTL=128
Reply from 192.168.241.10: bytes=32 time<1ms TTL=128
Reply from 192.168.241.10: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.241.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping 192.168.241.11
Pinging 192.168.241.11 with 32 bytes of data:
Reply from 192.168.241.11: bytes=32 time<1ms TTL=128
Reply from 192.168.241.11: bytes=32 time<1ms TTL=128
Reply from 192.168.241.11: bytes=32 time<1ms TTL=128
Reply from 192.168.241.11: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.241.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping 239.255.255.250
Pinging 239.255.255.250 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 239.255.255.250:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
At least now I can easily do a wireshark of the successful discovery process.
02-04-2014 09:52 AM
Hello
Yes you should be able too.
These mc groups are attached in specific interfaces. And are these interfaces directly attached to the core switch or on an access switch.
Do they have pim specifically assigned?
Res
Paul
Sent from Cisco Technical Support iPad App
02-04-2014 09:56 AM
Yes, the topology is pretty simple actually. A network projector device ( runs a version of windows 8 I believe in a 1U rack mount chassis) is connected to a 3560 with no routing enabled. The 3560 is connected to a 4510r that is our distribution switch. Routing is enabled here. Ip multicast is enabled here. The vlan interfaces that I want to participate in multicast have ip pim dense-mode command applied.
I just did a wireshark of a workstation trying to discover and used a port span on the 3560 with a sniffer attached locally to capture the packets of the projector device. I do not see any 239.255.255.250/udp 3702 at all being received by the projector device. If I run the same thing but with a workstation in the same vlan as the projector, I do see the multicast discovery packets occurring. So it seems something is preventing the multicast from crossing vlans.
02-04-2014 10:05 AM
Don
I maybe misunderstanding here but it sounds like you are expecting the client packets to be routed between vlans and i don't think that is how it is meant to work.
Apologies if i have got what you are saying wrong but if you look back at my previous post where i copied that information from the Microsoft site it says that it is the device ie. the projector that sends the multicast as a service availability message.
So it's not that the projector receives this multicast group from the clients. It is the projector that is meant to generate that message. The clients simply register their interest in the message with the switch using IGMP and then the switch, when it receives the multicast message sends it to any vlans where clients have registered their interest.
Jon
02-04-2014 10:12 AM
Maybe I am not understanding it properly. The device development team came to us and said we need this device to be discoverable on the network and it uses multicast for that...we think. So I looked up that it uses WSD for the discovery process which uses multicast 239.255.255.250/udp 3702 When I do a discovery on the same segment I do see that udp traffic with a destination of 239.255.255.250 during the discovery process. When I attempt that same process from a different vlan, I see the source attempting to send to that destination, 239.255.255.250 but I never see anything arrive on the projector end.
Am I incorrect in thinking that I should?
I could share the .cap files but that might be out of the scope of this forum?
02-04-2014 10:27 AM
Don
It may well be me that is misuderstanding. It sounds like it is actually the laptop that generates the multicast stream and the projector simply registers to receive it.
But that isn't what the Microsoft paper i read is saying ie. it suggests it is the projector that should be sending traffic to this multicast addess which would make sense to me because then any client that was interested could simply register. If it was for the client to discover the projector then what use would multicast be ie. you simply use the TCP based discovery mechanism.
The idea behind using the multicast solution is so each client does not send their own TCP messages independantly of each other. The projector simply sends out a multicast message and all clients can receive this.
I will do some more hunting around.
Have you looked at the projector configuration settings to see if there is anything obvious that can be set/changed ?
Jon
02-04-2014 10:31 AM
Hi Jon, thanks again for you interest and time in this thread.
According to this article (
http://msdn.microsoft.com/en-us/library/dd352335.aspx), :
The WS-Discovery protocol uses SOAP and UDP (User Datagram Protocol) multicast to enable services to be discovered by a client. In the RFID world, services discovered are RFID devices and the client is a provider. WS-Discovery has four types of messages:
The multicast address used is 239.255.255.250 on IPV4 networks and [FF02::C] on IPV6 networks. In both cases, multicast messages are sent to port 3702. Several components in Windows Vista such as "People Near Me" and "Computers Near Me" use the WS-Discovery protocol. The detailed specification for the WS-Discovery protocol can be found athttp://go.microsoft.com/fwlink/?LinkId=107376.
02-04-2014 10:29 AM
Don
Can you try from a client in a different vlan from the projectors and then post the output of "sh ip mroute" together with the client IP address.
Jon
02-04-2014 10:33 AM
Sure, I did that earlier and captured the packets as well. I will run it again now:
Client ip addr 192.168.212.144
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), 22:14:47/00:02:55, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan216, Forward/Dense, 02:29:41/00:00:00
Vlan212, Forward/Dense, 22:14:47/00:00:00
Vlan241, Forward/Dense, 22:14:47/00:00:00
(*, 226.178.217.5), 22:15:06/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan241, Forward/Dense, 03:03:08/00:00:00
(192.168.241.120, 226.178.217.5), 00:00:10/00:02:49, flags: PT
Incoming interface: Vlan241, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 232.44.44.233), 22:14:41/00:02:55, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan212, Forward/Dense, 22:14:41/00:00:00
(*, 224.0.1.40), 22:15:20/00:02:30, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan241, Forward/Dense, 22:15:20/00:00:00
ktsw-B-distribution#
02-04-2014 10:37 AM
In your note above I see that MS mentions two methods: multicast discovery ( for local segments); and TCP directed. I assume that correlates to the two options one sees when one opens the Connect to a Network Projector wizard in Windows. One is to search for projectors and the other option is to put in an ip addr.
Our product team do not wish to have to put in an ip address when they demo this device on our premises. That is why they are pushing for us to make it searchable over the network. It seems to me that it should be doable, if not preferrable?
02-04-2014 10:46 AM
Don
Is there anyway to check the TTL of the packets. What do the captures show ?
Jon
02-04-2014 10:53 AM
Seems it is 1?
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide