cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1190
Views
0
Helpful
8
Replies

Multicast on a Single Switch/Multiple SVIs

plaethos75
Level 1
Level 1

Hey all.  I don't post much as I generally figure things out with reading, GNS3, and labs.  I however got to a point that I can't seem to figure an engineering task out due to my lack of experience.

Below is a rough diagram of a network I am using to test multicast over wireless on.  I can't seem to get this piece to work, let alone multicast through a wired connection.

I am running a 3650, running 12.2.55 code. 

If I wire in (bypassing the wireless), and use the same vlan/subnet the source of the multicast is on, I can't seem to stream anything. Doing a packet capture, I see the traffic.  As far as I can tell, I am configured correctly on my streaming server. I thought from a multicast prospective, I am configured correctly as well.

I am looking for any help on this and welcome any thoughts.  I've included my multicast config in text doc that is already pasted as well.  I sincerely appreciate any/all help.

L3 Switch Config:


ip multicast-routing distributed
ip igmp querier
no ip igmp filter
!
!
interface Loopback0
ip address 10.0.0.5 255.255.255.255
!
!
interface Port-channel5
description to WLAN-Inside-po5
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,30,54
switchport mode trunk
load-interval 60
spanning-tree bpdufilter enable
!
!
Gi0/2:
description “to streaming server”
switchport access vlan 30
!
!
interface Vlan30
ip address 10.20.30.1 255.255.255.0
ip helper-address 10.20.30.10
ip pim query-interval 1
ip pim sparse-mode
ip igmp join-group 239.239.1.1


interface Vlan54
ip address 172.16.54.1 255.255.255.0
ip helper-address 10.20.30.10
ip pim query-interval 1
ip pim sparse-mode
ip igmp join-group 239.239.1.1

!
ip pim accept-rp 10.0.0.5 mcast-source override
ip pim accept-register list mcast-source
!
ip access-list standard mcast-subnet
permit 239.0.0.0 0.255.255.255
!
ip access-list extended mcast-source
permit ip 10.0.0.0 0.255.255.255 any
permit ip 172.16.0.0 0.0.255.255 any
!

8 Replies 8

Jaime Valencia
Cisco Employee
Cisco Employee

You posted this in the Video Over IP community, might want to search for similar threads on CSC, and move to that same area.

HTH

java

if this helps, please rate

Jon Marshall
Hall of Fame
Hall of Fame

Firstly why are you using the "ip igmp join-group ..." command under the SVIs, do you  not have any clients that send IGMP requests ?

Secondly have you checked the TTL for the multicast stream ?

When the server is streaming can you provide the outputs of -

sh ip igmp groups
sh ip mroute

Jon

Hey Jon.  I appreciate the assist on this.  the end goal is to ensure this is working as I have a non-Cisco wireless controller connected via port channel.  One of the issues I've run into with this, is the fact that if I am wired I still can't stream, regardless if I am within the same broadcast domain or not.  It's been a long standing thought its the program doing the stream, but I won't know until I've successfully ensured the rest of my configs are setup.

With that said:

1.  Since I had posted this, I have actually removed the ip igmp join-group from the SVIs.

At first I wasn't sure when to use them so while trying to t-shoot, I added them thinking maybe that could help.

2.  I have checked the ttl's for the mc streams.  from what I can tell, the output of ttl is set to 128.  A tad bit overkill but -- whatever.

3.  

Dist_sw1#sh ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.239.1.1 Vlan30 2d19h 00:02:59 10.20.30.10
239.255.255.254 Vlan30 2d19h 00:02:58 10.20.30.10
239.255.255.250 Vlan54 00:18:41 00:02:30 172.16.54.18
239.255.255.250 Vlan30 2d19h 00:02:59 10.20.30.7
239.255.255.246 Vlan54 00:18:41 00:02:37 172.16.54.18
224.0.1.39 Vlan54 2d19h 00:02:38 172.16.54.1
224.0.1.39 Vlan30 2d19h 00:02:59 10.20.30.1
224.0.1.39 Vlan10 2d19h 00:02:45 10.10.1.1
224.0.1.40 Vlan10 1d00h 00:02:50 10.10.1.1
224.0.1.40 Vlan30 2d19h 00:02:01 10.20.30.4

Dist_sw1#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
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.239.1.1), 2d19h/stopped, RP 10.0.0.5, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.20.30.10, 239.239.1.1), 2d06h/00:02:59, flags: PJT
Incoming interface: Vlan30, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 239.255.255.254), 2d19h/00:02:39, RP 10.0.0.5, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 239.255.255.250), 2d19h/00:02:39, RP 10.0.0.5, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan54, Forward/Sparse, 00:13:11/00:02:29

(*, 239.255.255.246), 00:16:10/00:02:26, RP 10.0.0.5, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan54, Forward/Sparse, 00:13:11/00:02:26

(*, 224.0.1.39), 2d19h/00:02:42, RP 10.0.0.5, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan54, Forward/Sparse, 2d19h/00:02:25
Vlan10, Forward/Sparse, 2d19h/00:02:32

(*, 224.0.1.40), 2d19h/00:02:41, RP 10.0.0.5, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan10, Forward/Sparse, 23:58:13/00:02:33

this is my client:

Interface: 172.16.54.11 --- 0xc
Internet Address Physical Address Type
10.20.30.10 00-19-06-6e-8c-47 dynamic
172.16.54.1 00-19-06-6e-8c-47 dynamic
172.16.54.18 24-4b-03-e1-9b-8c dynamic
172.16.54.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
239.239.1.1 01-00-5e-6f-01-01 static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

Is 10.20.30.10 the multicast server and the group address 239.239.1.1 ?

If so then you can see from the "sh ip igmp groups"  that no IGMP request has come from any client on vlan 54 so the switch is simply not forwarding the stream onto that vlan.

What software are you running on the client to receive the multicast stream ?

Jon

-->  chrihussey:  You are correct.  it doesn't appear to work. I've tried so many options too, I can't remember if I even saw join requests coming from a receiver off the same subnet from a packet capture.  as for adding sparse-mode to the lo, I had tried that as well and saw no difference.


Jon: You are correct about the server and group address.  For a while I was thinking the issue was because of the WLAN controller and how it was configured.  The one piece that stuck out to me the most, was what chrihussey pointed out - receiver on the same subnet is not able to participate in the stream.  Which now brings me back to the ttl and or the software...

Software I am using for the server and receiver is  VLC.  Do you maybe have any suggestions of some other software to try?

Thank you both for your help on this.

I have always used VLC and it worked for me. I did deal with a problem on here a while back where the person was using a version of VLC with a bug where the TTL was ignored unless they specified it on the command line.

But if the receiver in the same subnet cannot receive the stream the TTL is not the problem.

From the output of the mroute table it looks like the server is sending the stream so the issue must be with the client.

Can you try a quick test. Put the receiver in the same subnet and see if it can see the stream. Assuming it can't can you disable IGMP snooping on the switch and then see if it can see the stream.

Note disabling IGMP snooping will mean the multicast is treated as a broadcast so if this is in production be careful.

Jon

My two cents. I think you have to get it working on a single subnet first and then worry about multicast routing later. I agree with Jon's approach and would also suggest removing all multicast and IGMP configurations. You could start with removing the default of IGMP enabled, and then add it back once things are working and take it from there.

My understanding of multicast between source and client is that the client needs to join the group, so you would need to see that in a packet sniff. The source just needs to transmit and not join or do anything else. With that in mind you may be able to figure out what is going on.

There was an issue I read of on a different post where the problem was the version of JAVA on the client. Not something I know much about, but just putting it out there if it is a possibility.

 

Sorry for jumping in late, but if I understand things correctly it doesn't appear to be working when the server and receiver are on the same switch and VLAN. If this is the case, it should work without any multicast configuration at all. Out of the box the Cisco also has IGMP enabled.

So just to keep it simple, I'd suggest getting it working on the single subnet and once operational then expand to the other networks/VLANs where multicasting comes into play.

One other thing, just shooting from the hip. Try adding "ip pim sparse-mode" to the loopback interface.

Getting Started

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: