Solved: Re: Intervlan Multicast on a 4510r - Page 2

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?

Don Maker · ‎02-04-2014

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.

Jon Marshall · ‎02-04-2014

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

Don Maker · ‎02-04-2014

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

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

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.

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.

paul driver · ‎02-04-2014

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

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-04-2014

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.

Jon Marshall · ‎02-04-2014

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

Don Maker · ‎02-04-2014

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?

Jon Marshall · ‎02-04-2014

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

Don Maker · ‎02-04-2014

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:

Hello. A service sends a Hello message by using UDP multicast when it joins a network.
Bye. A service sends a Bye message when it prepares to leave the network.
Probe. A client sends a Probe message by using UDP multicast looking for services it is interested in. Matching services respond with ProbeMatch messages.
Resolve. A client sends a Resolve message by using UDP multicast to find out transport addresses for services. Matching services respond with ResolveMatch 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.

Jon Marshall · ‎02-04-2014

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

Don Maker · ‎02-04-2014

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#

Don Maker · ‎02-04-2014

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?

Jon Marshall · ‎02-04-2014

Don

Is there anyway to check the TTL of the packets. What do the captures show ?

Jon

Don Maker · ‎02-04-2014

Seems it is 1?

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