Multicast Routing and IPTV Question

[bradleyordner]

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

[Giuseppe Larosa]

Hello Bradley,

can you post the new ACL used to decide what groups should be served by the RP?

>> Can multiple sites/hosts in a PIM domain send to an RP on the same group? 

Yes this is supported

>> Received Register from (IPTV receiver VLAN IP) for (IPTV Receiver IP, 239.255.255.255), not willing to be RP

This makes me think the RP does not see itself as an RP for group 239.255.255.255.

Hope to help

Giuseppe

[bradleyordner]

Hi,

Thanks for your reply, I have no ACL on the RP itself. It has just been
configured as

ip pim rp-address x.x.x.x

When doing the show mapping it just reveals

232.0.0.0/4

Only on the other PIM routers have I locked down the RP.

I locked down as -

Access-list 10
Permit 239.192.0.0 0.1.255.255
Permit 239.255.255.255

I am a little worried about this last address. It’s used by the SAP
protocol and didn’t know if it had any other significance being the last IP
in the range?

[Giuseppe Larosa]

Hello Bradley,

I have found no evidence that address 239.255.255.255 cannot be processed by an RP.

For example in very famous book TCP/IP volume 2 by Doyle and Carroll there is an example for group 239.255.255.254 using an RP.

see below

https://books.google.it/books?id=GdWAapirZ9gC&pg=PA555&lpg=PA555&dq=239.255.255.255+and+RP&source=bl&ots=69O0mPrE28&sig=ACfU3U29LevVnhc6AbV03IgTP5cqVnMHCw&hl=it&sa=X&ved=2ahUKEwin9YSKzr7jAhXHCOwKHZEOCpYQ6AEwBHoECAkQAQ#v=onepage&q=239.255.255.255%20an...

And a reference that confirms address 239.255.255.255 is used by SAP see slide 10 of the following proposal for an alternative protocol

https://www.ietf.org/proceedings/70/slides/mboned-3.pdf

Hope to help

Giuseppe

[bradleyordner]

Hi,

Will check this book as I have it at home. 

I checked the RP and the directly connected VLAN that has the IPTV equipment, it receives the traffic from source and sends it towards receivers. It is also the RP - 

Group: 239.255.255.255, RP: 10.142.0.1, next RP-reachable never
Group: 239.255.255.254, RP: 10.142.0.1, next RP-reachable never
Group: 239.255.255.250, RP: 10.142.0.1, next RP-reachable never

(10.142.5.88, 239.255.255.255), 21:40:55/00:03:23, flags: T
Incoming interface: Vlan41, RPF nbr 0.0.0.0
Outgoing interface list:
TenGigabitEthernet1/5/1, Forward/Sparse, 14:27:50/00:02:37

VLAN41 local IPTV VLAN 

TenGig1/51 = Interface to next PIM router 

You can see this traffic get all the way to the receivers. The problem is the receivers themselves are also marking themselves as source for this multicast group. 

It mentions in that book that when a join request is received for a Multicast Group, it consults Mroute table and if it is there is just adds it and does nothing else. 

The receiver PIM router is showing the following - 

(10.142.5.88, 239.255.255.255), 14:31:23/00:01:59, flags: JT
Incoming interface: TenGigabitEthernet1/0/12, RPF nbr 10.141.255.253
Outgoing interface list:
Vlan41, Forward/Sparse, 14:31:23/00:02:42

(*, 239.255.255.255), 17:02:26/stopped, RP 0.0.0.0, flags: SJCF
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan41, Forward/Sparse, 17:02:26/00:02:35

Need to figure out if its actually working and that RP message is just an error? Although the channels list is not accessible. 

Brad

[chrihussey]

Just out of curiosity, is there a TTL setting associated with the 239.255.255.255 group? If so, and it is set to 0 or 1 then that may be your problem. Set it to something equivalent to the maximum number of hops in your network  and add a couple more just for kicks.

Hope this helps.

[bradleyordner]

Hi, 

I can see the group and source at the other PIM router 3 hops away. so it is making it. My concern is each site is sourcing the traffic and one way the router is ok to be RP but the other way it isn't. See my post above to other user. 

Thanks

[bradleyordner]

Just did this trace and got this response - 

#mtrace 10.141.255.253 10.142.2.88 239.255.255.255
Type escape sequence to abort.
Mtrace from 10.141.255.253 to 10.142.2.88 via group 239.255.255.255
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 10.142.2.88
-1 * * * Timed out receiving responses
Perhaps no local router has a route for source, the receiver is not
a member of the multicast group or the multicast ttl is too low.

Will try and modify the TTL see if it makes a difference. 

[bradleyordner]

Hi, 

Just to add to troubleshooting, I joined my remote interface to group 239.255.255.255 and then tried to ping it from Source Router and get no response. So even though the mroute is populated, no active stream. I tried another stream to join, such as 239.192.x.x and i get a response. 

I checked the config on the IPTV device and it has a SAP TTL of 7.I cant see anywhere to configure TTL on our routers though.

[chrihussey]

You are making sense and some good troubleshooting on your part. Suggest re-ordering your access list so that the 239.255.255.255 is not denied by the first instance:

!

Access-list 10

Permit 239.255.255.255
Permit 239.192.0.0 0.1.255.255
!

[bradleyordner]

Checked and changed the seq numbers, matches on all. 

One thing I will try is locked down the Multicast RP at the source site to these groups, even though it is RP for the group when the source is local, only when the source is remote does it say it does not want to be RP. 

[bradleyordner]

Checked and changed the seq numbers, matches on all. 

One thing I will try is locked down the Multicast RP at the source site to these groups, even though it is RP for the group when the source is local, only when the source is remote does it say it does not want to be RP. 

[bradleyordner]

Ok, I found the reason for the message. This was applied to the RP - 

ip pim accept-register list <acl name>

I have updated it with source IPs and now get no messages. 

So, that is fixed and related back to the RP not willing to be or know it should be RP. 

[Giuseppe Larosa]

Hello Bradley,

there was another ACL involved

>>ip pim accept-register list <acl name>

Thanks for your feedback, now it is working for any source trying to register to the RP?

Hope to help

Giuseppe

[bradleyordner]

Now that the RP is working, I have to see if these 239.255.255.255 announcement messages are getting to site. 

Will do a packet capture and advise :-)