cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
16267
Views
9
Helpful
17
Replies

Help!!! Multicasting Issue

Hi there,

I got a multicasting problem while I was testing a stimulated solution. Below is the digram I'm working on. Two layer 3 switches, both are running EIGRP and PIM-SM, and the multicasting server plays a video through VLC Player, then the multicasting client can watch that video after it joins in that group. So far, all of configurations have been done according Cisco's document, however the client couldn't receive any multicasting packets. I'm assuming the multicasting packet haven't been forwarded the C3560 from C3650. Please give me any suggestions and comments you have. I really appreciate that. 

Thanks,

Bob

Configuration: (All of the configuration I have. Rest of configuration is default like FACTORY SETTINGS. )

C3650:

ip routing
!
ip multicast-routing
!
!
!
!
!
!
interface Loopback0
ip address 30.30.30.30 255.255.255.255
ip pim sparse-mode
!
!
interface GigabitEthernet1/0/1
switchport access vlan 500
switchport mode access
!
!
!
interface Vlan1
no ip address
shutdown
!
interface Vlan100
ip address 172.16.10.3 255.255.255.0
ip pim sparse-mode
!
interface Vlan500
ip address 192.168.50.1 255.255.255.0
ip pim sparse-mode
!
!
router eigrp 100
network 0.0.0.0
eigrp stub connected summary
!
ip forward-protocol nd
ip pim rp-address 30.30.30.30
ip pim send-rp-discovery Loopback0 scope 10

=============================================

C3560:

ip routing
!
!
ip multicast-routing distributed
!
!
!
!
!
vlan configuration 300
vlan internal allocation policy ascending
!
!
!
interface Loopback0
ip address 10.10.10.10 255.255.255.255
!
interface GigabitEthernet1/0/1
switchport access vlan 300
switchport mode access
!
!
interface TenGigabitEthernet1/0/3
switchport access vlan 100
switchport mode access
!
!
interface Vlan1
no ip address
shutdown
!
interface Vlan100
ip address 172.16.10.1 255.255.255.0
ip pim sparse-mode
!
interface Vlan300
ip address 192.168.10.1 255.255.255.0
ip pim sparse-mode
!
!
router eigrp 100
network 0.0.0.0
eigrp stub connected summary
!
ip forward-protocol nd
ip http server
ip http secure-server
!
ip pim rp-address 30.30.30.30
!

Verification:  

C3650:

C3650#  show ip mrouter 
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, E - Extranet,
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,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 01:55:29/00:02:36, RP 30.30.30.30, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan500, Forward/Sparse, 01:55:28/00:02:36

(*, 239.0.0.1), 01:55:29/00:02:37, RP 30.30.30.30, flags: SJC
 Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan500, Forward/Sparse, 01:52:25/00:02:37

(*, 224.0.1.39), 00:41:13/00:02:51, RP 30.30.30.30, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:41:13/00:02:51
Vlan500, Forward/Sparse, 00:41:13/00:02:36
Vlan100, Forward/Sparse, 00:41:13/00:02:29

(*, 224.0.1.40), 02:11:31/00:02:52, RP 30.30.30.30, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan100, Forward/Sparse, 00:41:10/00:02:27
Loopback0, Forward/Sparse, 00:41:13/00:02:52


C3650#show ip pim interface

Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
172.16.10.3 Vlan100 v2/S 1 30 1 172.16.10.3
192.168.50.1 Vlan500 v2/S 0 30 1 192.168.50.1
30.30.30.30 Loopback0 v2/S 0 30 1 30.30.30.30
C3650#show nei     ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.16.10.1 Vlan100 02:08:05/00:01:36 v2 1 / S P G

C3650#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.255.255.250 Vlan500 01:56:11 00:02:55 192.168.50.3
239.0.0.1 Vlan500 01:53:07 00:02:51 192.168.50.3
224.0.1.39 Loopback0 00:41:55 00:02:09 30.30.30.30
224.0.1.39 Vlan500 00:41:55 00:02:53 192.168.50.1
224.0.1.39 Vlan100 00:41:55 00:02:46 172.16.10.3
224.0.1.40 Vlan100 00:41:52 00:02:41 172.16.10.1
224.0.1.40 Loopback0 00:41:55 00:02:10 30.30.30.30

================================================================

C3650-CX:

C3560#show ip mrouter  e
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, E - Extranet,
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,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:01:04/00:01:55, RP 30.30.30.30, flags: SP
Incoming interface: Vlan100, RPF nbr 172.16.10.3
Outgoing interface list: Null

(*, 224.0.1.39), 00:43:05/00:02:31, RP 30.30.30.30, flags: SP
Incoming interface: Vlan100, RPF nbr 172.16.10.3
--More--   Outgoing interface list: Null

(*, 224.0.1.40), 02:07:32/00:02:31, RP 30.30.30.30, flags: SJPL
Incoming interface: Vlan100, RPF nbr 172.16.10.3
Outgoing interface list: Null


C3560#show ip pim interface

Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
172.16.10.1 Vlan100 v2/S 1 30 1 172.16.10.3
192.168.10.1 Vlan300 v2/S 0 30 1 192.168.10.1

C3560#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
224.0.1.39 Vlan100 00:45:23 00:02:17 172.16.10.3
224.0.1.40 Vlan100 02:11:48 00:02:20 172.16.10.1

1 Accepted Solution

Accepted Solutions

Hello

So that confirms your network configuration and the MC is working, the igmp join-group simulates a  MC source and it is responding.

res

Paul


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

View solution in original post

17 Replies 17

johnd2310
Level 8
Level 8

HI,

IS the client sending any joins? Have you check any firewall issues on the client.  On the 3560 vlan 300 add ip igmp join-group 239.0.0.1 and see if traffic flows. Don't forget to remove the command when you finish troubleshooting

interface Vlan300
ip address 192.168.10.1 255.255.255.0
ip pim sparse-mode

ip igmp join-group 239.0.0.1

Thanks

John

**Please rate posts you find helpful**

Hi John,

Thanks for your response. I actually added VLAN 300 to the IGMP group of 239.0.0.1, as well as the client could receive the multicasting packets when it was located same VLAN with the server aka it was at same broadcasting domain with server, which means the firewall issues could not be existed I'm assuming. But both are good suggestions, I appreciate that.

Thanks,

Bob 

Hi,

On the 3560c switch can you ping 239.0.0.1? What is the ttl of the multicast stream?

thanks

John

**Please rate posts you find helpful**

Ping on the server's L3 switch is attached. Could you please let me know how can I check the TTL of the multicast stream? Thanks, John!

PS: 224.20.20.20 is a new group address I created. 

C3650#ping 224.20.20.20 repeat 5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 224.20.20.20, timeout is 2 seconds:

Reply to request 0 from 172.16.10.1, 1 ms

Reply to request 1 from 172.16.10.1, 1 ms

Reply to request 2 from 172.16.10.1, 1 ms

Reply to request 3 from 172.16.10.1, 1 ms

Reply to request 4 from 172.16.10.1, 1 ms

Good news here. I found out the problem I had, which was TTL issue. Actually, TLC player TTL 's default value is 1, also it can not be changed based on the GUI. That would be a problem when the player is using a pim scenario. The solution is to create a .bat file if you are using Windows for customizing what TTL you need. Below is the .bat file I'm using,

echo off

"c:\program files(x86)\videolan\vlc\vlc.exe" -vvv test.mp4 :sout=#transcode{vcode=h264,vb=800,scale=1,acodec=mp4a,ab=128,channels=2,samplerate=44100}:std{access=udp,mux=ts,dst=239.0.0.1:1234} --ttl=12
Hopefully, that's helpful for the people who will face or are facing the same issue. 
Thanks for your help, guys. Your suggestions and recommendations are so important for me to find out the problem.
Thanks,
Bob

Oh, BTW, I checked out the document of Cisco. As it mentioned, " If the application sends packets with a TTL value less than 1, you should see the traffic dropped at the first upstream router. To verify, use the show ip traffic command and look for an increase in the value of the "bad hop count" counter." I actually found the " bad hop count" is increasing on C3560-CX. Is that caused by TTL?  

Thanks,

Bob

http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13726-57.html

Check the TTL value in the application sourcing packets; it should be greater than 1. If the application sends packets with a TTL value less than 1, you should see the traffic dropped at the first upstream router. To verify, use the show ip traffic command and look for an increase in the value of the "bad hop count" counter. Any packet with a TTL value of 1, or less than the TTL threshold set by the interface with the ip multicast ttl-threshold command, is dropped and the "bad hop-count" counter is increased by one. Use the show ip igmp interface interface-namecommand to see the interface TTL threshold value.

Here are a few IGMP packets were captured by Wireshark. Those are the packets regarded to multicast I had only. 

Hello

Your static rp addressing is fine on either L3 switch , So at this time you don't require to apply also auto-rp statements with  send-rp-discovery Loopback0 scope 10 this can be removed.

As long as the RP is reachable from the client you will be fine, and your eigrp config looks okay so I am guessing this is being advertised. 

However I can see your client ip address is NOT in a routable subnet on its attached L3 switch

interface Vlan300 - 192.168.10.3 255.255.255.

Client is = 192.168.20.253

res
Paul


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

Hi Paul,

Thanks for your response. If you mentioned that was the digram I posted, I apologize I made some mistakes on that. Actually, On C3560-CX, VLAN300's IP address should be 192.168.10.1/24, and the client is 192.168.10.231/24. The configuration I posted was correct fortunately :) 

Right now, the server can be pinged by client. The verifications on the client as below:

:\Users\Owner>ipconfig

Windows IP Configuration


Wireless LAN adapter Wireless Network Connection:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::95aa:2a64:f520:b785%10
IPv4 Address. . . . . . . . . . . : 192.168.10.231
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.10.1

C:\Users\Owner>ping 192.168.50.3

Pinging 192.168.50.3 with 32 bytes of data:
Reply from 192.168.50.3: bytes=32 time=112ms TTL=126
Reply from 192.168.50.3: bytes=32 time=29ms TTL=126
Reply from 192.168.50.3: bytes=32 time=60ms TTL=126
Reply from 192.168.50.3: bytes=32 time=81ms TTL=126

Ping statistics for 192.168.50.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 112ms, Average = 70ms

Thanks,

Bob

Hello

So you have IP routing enabled on each switch and reachability to the loopback of switch 1/2 from the client and server?

RPR failure won't be an issue as their only one way to go.

You are running static RP and have both static rp map statements in each switch

Sh ip pim rp mapping  ------- to confirm this

So you sure it isn't the Vic player?

Lastly for a try applying -pim sparse-dense mode, to see if you are able to reach the mc source then?

Res

Paul


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

Hi Paul

Thanks for your response. Yes, the client can reach to the server's loopback and interface. 

I will try " show ip pin rp mapping" tomorrow to see what will be exported. 

You mean could be some problems on VLC Player, right? I'm not sure if it works on multicast scenario but I tried the broadcast scenario it's working. Also, I captured the IGMP packet at client side when the player played. Anyway, that's a good point I definitely need to make sure it's working or not. Do you have any recommendations regarding the multicast player?

And I've tried sparse-dense mode before but it didn't work. 

Thanks,

Bob

Hello

What I can see from your posts and what your are saying , basic static unicast RP  is running and reachability is good.

I does seem to point to the VLC, but I have never used it so cannot comment, But what you can do to test the MC tree is:

Create another loopback on the C3650 an advertised it into eigrp.

int lo100
ip address 100.100.100.100 255.255.255.255
ip igmp join-group 239.255.255.249

then test by pinging that MC address from the client

res

Paul


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

Hi Paul,
Below is what I got on the client's switch according to you suggestions. Any comments ?
Switch#ping 239.255.255.249 source 192.168.30.1 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.255.255.249, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.1
Reply to request 0 from 172.16.10.1, 7 ms
Reply to request 1 from 172.16.10.1, 4 ms
Reply to request 2 from 172.16.10.1, 4 ms
Reply to request 3 from 172.16.10.1, 3 ms
Reply to request 4 from 172.16.10.1, 3 ms
Reply to request 5 from 172.16.10.1, 4 ms
Reply to request 6 from 172.16.10.1, 3 ms
Reply to request 7 from 172.16.10.1, 3 ms
Reply to request 8 from 172.16.10.1, 4 ms
Reply to request 9 from 172.16.10.1, 3 ms
Best,
Bob

Hello

So that confirms your network configuration and the MC is working, the igmp join-group simulates a  MC source and it is responding.

res

Paul


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
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: