07-18-2019 01:55 AM
Hi,
I have just deployed a very small multicast network. One site we have a VLAN with IPTV Equipment (Multicast Source) and across a few Layer 3 routers we have another site with IPTV Receivers.
I have opted for very simple configuration of PIM Sparse mode on all Layer 3 links and statically assigned the RP which is at the IPTC Equipment site. This is locked down to the 239.192.0.0/15 range on the receiver site and routers in between, except the source site, he is allow to be RP for everything.
Multicast is making its way from Source to receiver, until someone mentioned the channel list isn't working. I looked into it and it looks like the IPTV system uses SAP (Session Announcement Protocol) to announce the channels. This is using IP 239.255.255.255 which is the default and can't be changed.
So, I thought ok, cool I will just update my ACL to allow 239.255.255.255. When I do that I see that all equipment on both sides of the multicast network start to become S,G entries and the RP now comes up with a message saying -
Received Register from (IPTV receiver VLAN IP) for (IPTV Receiver IP, 239.255.255.255), not willing to be RP
So both source and receiver of the Video traffic also use SAP to communicate. They all all configured to find the channels at sap://239.255.255.255
I cannot find if this is supported configuration and can't find a reason why the RP would not be RP for this group?
Can multiple sites/hosts in a PIM domain send to an RP on the same group?
This works fine at the IPTV Equipment site inside a single VLAN, now that we are trying to make it work over a few PIM routers, it's a no go.
Am i using the wrong type of multicast deployment? Is a Many to Many protocol needed instead? Is the PIM-SM unidirectional nature causing the issue?
Thanks for your time.
Brad
08-09-2019 05:45 AM
Hello Brad,
the bug description mentions that applies only to a stack of C3850 acting at OSI Layer 2 only
>> Seen only on member switches in a 3850 stack
Is your switch member of a stack or is it a standalone switch ?
Also your device is a Layer3 device performing routing both unicast and multicast from your description, so I am not sure that this bug applies to your network.
Hope to help
Giuseppe
08-09-2019 02:28 PM
Hi,
We have a stack of 3850 SFP switches as the core and then two stacks of 3850 as access layer in Layer 2 mode.
The receivers are attached to the layer 2 switches. We didn’t have any Copper SFPs to test being connected to core directly to test either.
Brad
08-10-2019 06:48 AM
Hello Brad,
with this more detailed description I agree the bug may apply to your issue.
Hope to help
Giuseppe
09-08-2019 04:43 PM
Hi,
Just to get some closure, Cisco TAC came back after some investigations and found this bug -
CSCvn31653.
They recommend a upgrade to Fuji Code - 16.9.3a
Thanks again for your help.
Brad
09-09-2019 12:56 AM
Hello Brad,
you have been kind to provide feedback on this strange issue with multicast.
I have given a read to the bug description
Fed is showing incorrect or is missing IGMP Snooping groups entries on Cat9300/Cat3850/Cat3650 switch.
Example:
Problematic group 225.x.x.x, receiver behind the gig 2/0/3 is present in "show ip igmp group" but not in the "fed" outputs
None of the suggested workarounds is a sure way to solve the issue so an IOS XE upgrade is necessary.
>> Workaround:
- shut/no shut of port that is missing may help to recover
- disabling igmp snooping and enabling it back may help to recover
- clear ip igmp snooping group may help to recover
- reload
The bug is classified as severity 1
Hope to help
Giuseppe
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