05-21-2016 03:12 PM - edited 03-08-2019 05:52 AM
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
Solved! Go to Solution.
05-25-2016 02:42 PM
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
05-21-2016 06:21 PM
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
05-21-2016 07:36 PM
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
05-22-2016 02:37 AM
Hi,
On the 3560c switch can you ping 239.0.0.1? What is the ttl of the multicast stream?
thanks
John
05-22-2016 09:51 AM
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
05-25-2016 02:13 PM
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
05-22-2016 09:57 AM
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.
05-21-2016 08:19 PM
Here are a few IGMP packets were captured by Wireshark. Those are the packets regarded to multicast I had only.
05-22-2016 06:58 AM
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
05-22-2016 09:26 AM
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
05-23-2016 11:38 PM
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
05-23-2016 11:57 PM
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
05-24-2016 02:20 AM
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
05-24-2016 12:40 PM
05-25-2016 02:42 PM
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
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: