IGMP Proxying, no traffic coming in

Question

After posting this question to Network Engineering, I was told the site is about enterprise environments, whereas my setup is a residential network. Hence, I'll try my luck here.

I managed to connect my Cisco 886VA to my local provider over a VDSL interface. The provider's TV solution is based on AppleTV, and multicast.

Vlan1 is my internal LAN. Ethernet0 is the link to the ISP, whereas Dialer1 is being used as the IP interface.

Here's my configuration so far - reduced to what I believe should be sufficient (notice there's NAT, in case this is important):

ip multicast-routing
!
interface Ethernet0
 description PPPoE
 no ip address
 ip nat outside
 no ip virtual-reassembly in
 no ip route-cache
 pppoe enable group global
 pppoe-client dial-pool-number 1
!

interface Vlan1
 ip address 192.168.0.1 255.255.255.0
 ip pim sparse-dense-mode
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1452
 ip igmp proxy-service
!
interface Dialer1
 ip address negotiated
 no ip redirects
 ip flow ingress
 ip pim sparse-dense-mode
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 ip igmp mroute-proxy Vlan1
 dialer pool 1
 ppp authentication chap callin
 ppp chap hostname SOMEHOSTNAME
 ppp chap password 7 SOMEPASSWORD
 ppp ipcp dns accept
 ppp ipcp route default
 no cdp enable
!
ip nat source static tcp 192.168.0.30 80 interface Dialer1 80
ip nat inside source list LAN_ACL interface Dialer1 overload
!
ip access-list extended LAN_ACL
 permit ip 192.168.0.0 0.0.0.255 any
!

After a long troubleshooting session and a lot of googling, here's what I found so far. Furthermore, there are two Cisco SG300 (Small Business) switches in between my endpoint and the router. Both of them have IGMP Snooping enabled.

Visiting one of the channels, e.g. udp://@239.77.0.77:5000 on my PC clearly results in the IGMP joins and leaves to be displayed on the router. The debug ip igmp shows:

*Dec 31 15:04:12.490: IGMP(0): Send v2 general Query on Vlan1
*Dec 31 15:04:12.490: IGMP(0): Set report delay time to 7.9 seconds for 224.0.1.40 on Vlan1
*Dec 31 15:04:12.490: IGMP(0): Sending Proxy Report for 239.255.255.250 to Vlan1
*Dec 31 15:04:12.490: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.1 for 239.255.255.250
*Dec 31 15:04:12.490: IGMP(0): Received Group record for group 239.255.255.250, mode 2 from 192.168.0.1 for 0 sources
*Dec 31 15:04:12.490: IGMP(0): Updating EXCLUDE group timer for 239.255.255.250
*Dec 31 15:04:12.490: IGMP(0): MRT Add/Update Vlan1 for (*,239.255.255.250) by 0
*Dec 31 15:03:20.894: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.33 for 224.0.0.252
*Dec 31 15:03:20.894: IGMP(0): Report has illegal group address 224.0.0.252
*Dec 31 15:03:21.010: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.30 for 224.0.0.251
*Dec 31 15:03:21.010: IGMP(0): Report has illegal group address 224.0.0.251
*Dec 31 15:03:21.010: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.30 for 224.0.0.251
*Dec 31 15:03:21.010: IGMP(0): Report has illegal group address 224.0.0.251
*Dec 31 15:03:55.470: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.33 for 239.77.0.77
*Dec 31 15:03:55.470: IGMP(0): Received Group record for group 239.77.0.77, mode 2 from 192.168.0.33 for 0 sources
*Dec 31 15:03:55.470: IGMP(0): Updating EXCLUDE group timer for 239.77.0.77
*Dec 31 15:03:55.470: IGMP(0): MRT Add/Update Vlan1 for (*,239.77.0.77) by 0

I just figured that no packets seem to be coming back from the ISP:

Router#show ip multicast interface dial1
Dialer1 is up, line protocol is up
  Internet address is 82.xxx.xxx.xxx/32
  Multicast routing: enabled
  Multicast switching: fast
  Multicast packets in/out: 0/252
  Multicast TTL threshold: 0
  Multicast Tagswitching: disabled
Router#show ip multicast interface vl1
Vlan1 is up, line protocol is up
  Internet address is 192.168.0.1/24
  Multicast routing: enabled
  Multicast switching: fast
  Multicast packets in/out: 121482/0
  Multicast TTL threshold: 0
  Multicast Tagswitching: disabled
Router#

I'm on a CCNA level, but to be honest I never really touched multicast (and mrouting). Not sure where to continue my troubleshooting from now on.

The provider provides configuration samples for other router manufacturers (check section "TV7", but they couldn't help me with Cisco. I looked into the MikroTik configs (instructions are in german, but the screenshots on page 4 should suffice), where it seems as easy as setting one interface as upstream and the other as downstream.

Edit

After implementing the changes suggested by Marc, here's the new output. 192.168.0.14 is the client asking for the stream. I tried different versions of IGMP on both subnets - without any more luck. Also, I've tried creating a loopback interface with the IP being used in the RP, didn't change anything. I also threw in debug ip pim and I believe, the RP is working... but to me it looks like no traffic is coming back from the ISP. Any more input what I can do to troubleshoot it?

*Jan  3 05:04:00.590: IGMP(0): Send v3 general Query on Vlan1
*Jan  3 05:04:01.194: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.77.0.224
*Jan  3 05:04:01.310: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.20 for 224.0.0.251
*Jan  3 05:04:01.310: IGMP(0): Report has illegal group address 224.0.0.251
*Jan  3 05:04:01.310: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.20 for 224.0.0.251
*Jan  3 05:04:01.310: IGMP(0): Report has illegal group address 224.0.0.251
*Jan  3 05:04:01.502: IGMP(0): Received v3 Report for 1 group on Vlan1 from 192.168.0.11
*Jan  3 05:04:01.502: IGMP(0): Report has illegal group address 224.0.0.251
*Jan  3 05:04:01.510: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.20 for 239.255.255.250
*Jan  3 05:04:01.510: IGMP(0): Received Group record for group 239.255.255.250, mode 2 from 192.168.0.20 for 0 sources
*Jan  3 05:04:01.510: IGMP(0): Setting v2 old host timer for 239.255.255.250 on Vlan1
*Jan  3 05:04:01.510: IGMP(0): Updating EXCLUDE group timer for 239.255.255.250
*Jan  3 05:04:01.510: IGMP(0): MRT Add/Update Vlan1 for (*,239.255.255.250) by 0
*Jan  3 05:04:01.510: IGMP(0): Helper Report for group 239.255.255.250 out Dialer1
*Jan  3 05:04:01.594: IGMP(0): Received v3 Report for 1 group on Vlan1 from 192.168.0.14
*Jan  3 05:04:01.594: IGMP(0): Report has illegal group address 224.0.0.251
*Jan  3 05:04:01.606: IGMP(0): Received v3 Report for 2 groups on Vlan1 from 192.168.0.30
*Jan  3 05:04:01.606: IGMP(0): Report has illegal group address 224.0.0.251
*Jan  3 05:04:01.610: IGMP(0): Received Group record for group 239.255.255.250, mode 2 from 192.168.0.30 for 0 sources
*Jan  3 05:04:01.610: IGMP(0): Updating EXCLUDE group timer for 239.255.255.250
*Jan  3 05:04:01.610: IGMP(0): MRT Add/Update Vlan1 for (*,239.255.255.250) by 0
*Jan  3 05:04:01.610: IGMP_ET(0): host 192.168.0.30 report for 239.255.255.250 (0 srcs) on Vlan1
*Jan  3 05:04:01.610: IGMP(0): Helpered report with fewer groups 1 than original 2
*Jan  3 05:04:01.610: IGMP(0): Helper v3 Report out Dialer1
*Jan  3 05:04:02.822: IGMP(0): Received v3 Report for 1 group on Vlan1 from 192.168.0.14
*Jan  3 05:04:02.822: IGMP(0): Received Group record for group 239.77.0.77, mode 4 from 192.168.0.14 for 0 sources
*Jan  3 05:04:02.822: IGMP(0): WAVL Insert group: 239.77.0.77 interface: Vlan1Successful
*Jan  3 05:04:02.822: IGMP(0): Switching to EXCLUDE mode for 239.77.0.77 on Vlan1
*Jan  3 05:04:02.822: IGMP(0): Updating EXCLUDE group timer for 239.77.0.77
*Jan  3 05:04:02.822: IGMP_ET(0): Adding Host 192.168.0.14 for 239.77.0.77 on Vlan1
*Jan  3 05:04:02.822: IGMP_ET(0): host 192.168.0.14 report for 239.77.0.77 (0 srcs) on Vlan1
*Jan  3 05:04:02.822: IGMP_ET(0): host 192.168.0.14 switch to exclude for 239.77.0.77 on Vlan1
*Jan  3 05:04:02.822: IGMP(0): MRT Add/Update Vlan1 for (*,239.77.0.77) by 1
*Jan  3 05:04:02.822: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.77.0.77
*Jan  3 05:04:02.822: PIM(0): Insert (*,239.77.0.77) join in nbr 0.0.0.0's queue
*Jan  3 05:04:02.822: IGMP(0): Helper v3 Report out Dialer1
*Jan  3 05:04:02.822: PIM(0): Building Join/Prune packet for nbr 0.0.0.0
*Jan  3 05:04:02.822: PIM(0):  Adding v2 (1.1.1.1/32, 239.77.0.77), WC-bit, RPT-bit, S-bit Join
*Jan  3 05:04:02.822: PIM(0): PIM passive interface Dialer1 suppress v2 JP
*Jan  3 05:04:04.810: IGMP(0): Received v3 Report for 1 group on Vlan1 from 192.168.0.14
*Jan  3 05:04:04.810: IGMP(0): Received Group record for group 239.77.0.77, mode 4 from 192.168.0.14 for 0 sources
*Jan  3 05:04:04.810: IGMP(0): Updating EXCLUDE group timer for 239.77.0.77
*Jan  3 05:04:04.810: IGMP_ET(0): host 192.168.0.14 report for 239.77.0.77 (0 srcs) on Vlan1
*Jan  3 05:04:04.810: IGMP(0): MRT Add/Update Vlan1 for (*,239.77.0.77) by 1
*Jan  3 05:04:04.810: IGMP(0): Helper v3 Report out Dialer1

Marc 'netztier' Luethi · Answer 1 · 2020-01-01T22:04:53.103

I saw your question over at Network Engineering, and it struck a chord.

I successfully run (Swisscom) IPTV with my C891-24X. Over the years, I had been using CISCO891, C891, C892SFP, too. I don't think that your ISP's (init7, I assume?) service is that different. They might even be running off the same platform as a reselling customer of swisscom' wholesale division.

Here's the config bits that made it work in my cases:

Outside Interface (in your case with PPPoE, that'll be Dialer0):

interface <myOutsideInterface>
 ip pim passive
 ip nat outside
 ip igmp query-interval 30

You have ip pim sparse-dense mode; that makes your CPE look for an upstream PIM neighboring router on that interface. There is one - but it most certainly won't accept your router as a PIM neighbor. Your CPE is supposed to be an IGMP speaking system, with IGMP being the protocol that multicast receivers (end systems) use to signal their interest in receiving traffic. Still, we need to activate multicast on the outside interface to have any multicast forwarding at all, hence ip pim passive is good enough.

The inside interface (in your case, that'll be VLAN 1)

interface <myInsideInterface>
 ...
 ip igmp helper-address 1.1.1.1    
 ip igmp query-max-response-time 2
 ip igmp v3-query-max-response-time 2
 ip igmp version 3
 ip igmp explicit-tracking
 ip igmp query-interval 12
 ip igmp querier-timeout 60
 ip igmp proxy-service
 ip pim passive
 ...
 ip nat inside
 ...

The key elements here are ip igmp proxy-service and the ip igmp helper-address .... After all, your IGMP proxy needs to know where to forward the IGMP joins of your end systems to. The rest is just tuning of IGMP behaviour towards the end systems.

Also, you need to enable PIM on that interface to have form of multicast forwarding at all. But if you don't expect any downstream multicast routers, there's no need for sparse nor dense mode, and passive is good enough.

Then you still need to map the group addresses of interest to that somewhat pseudo-ish RendezVous-Point, and turn pim's auto-rp off (which probably won't run anyway if all your interfaces are pim passive).

ip pim rp-address 1.1.1.1 ACLv4-IPTV-MCAST-RP
no ip pim autorp
...
ip access-list standard ACLv4-IPTV-MCAST-RP
 permit 239.186.0.0 0.0.255.255
 permit 233.0.0.0 0.255.255.255

The 1.1.1.1 seems to be some kind of dummy address. I just swapped it against 2.2.2.2 in my config and I can still the multicast streams keep coming in. I assume it just needs to be a unicast address beyond your outside interface, so that the proxified IGMP Join does go towards your ISP (by virtue of the default route).

You'll have to find out which multicast address range your ISP is using for their IPTV streams [1]. Of course, you might just as well map all of 239.0.0.0/8 [2] to that RP, and it will probably work. I had to map selectively because at the time, I used to experiment with multicast in my internal network.

The debug output you've shown does not show how the proxyfied IGMP leaves your CPE out of Dialer 0 towards whatever is up there. I think that must happen; else, your ISP's upstream router won't know that you have a system at your site interested in receiving that stream.

On a sideline:

Do yourself a favour and add the following, if you don't have it already. Your outside interface's MTU is reduced by 8 bytes for PPP (is now 1492). Adjusting MSS really helps TCP, and makes your end systems less dependent on PMTUd (Path MTU Discovery) and saves your router some ICMP workload or computationally expensive fragmentation.

interface <myInsideInterface>
 ...
 ip tcp adjust-mss 1452
 ...

[1] I believe the .186. in the second octet is somewhat of a swisscom thing. Much of their services for end customers run in their public range of 195.186.0.0/16. I assume that's why they assigned group addresses that way, too.

[2] Wild guess: The 239.**77**.0.77 from your debug makes me believe that your ISP's stream's adresses are all within 239.77.0.0/16

Thanks for the detailed response. I implemented your suggested changes but unfortunately, it didn't work out. As per your comment, I added the entire multicast range into the accesslist (they offer a playlist and you're right about your wild guess). — Atmocreations, Jan 03 '20 at 08:19
I've now modified the question to reflect the changes you suggested. Have you got any more idea? — Atmocreations, Jan 03 '20 at 08:40

IGMP Proxying, no traffic coming in

Edit

1 Answers1