Multicast flow over DMVPN with Cisco Hub and Spoke FRR: multicast flow is not bidirectional

[Alt0S04]

Description

Hello, I am currently testing multicast video streaming through a DMVPN using a Cisco Hub and two Spoke FRR. I'm stuck in my tests because only the Hub to Spoke direction works, whereas I'd be more interested in the Spoke to Hub direction. Unfortunately, this direction doesn't work with my current configuration and I've searched and searched, but I can't find a solution. I am using OSPF as a routing protocol, and it is working very well through the DMVPN.

Here's a diagram of my topology:

To make things easier to understand, I'll only be talking about the Hub and a single Spoke (FRR-Spoke-1). To generate multicast streams, I use VLC on Windows machines on both sides of the topology. In the Hub --> Spoke direction, I ask Multicast 1 to broadcast and Multicast 2 to receive. This works very well and I can see the stream reaching Multicast 2:

I've done the opposite operation for the Spoke --> Hub direction (Multicast 2 --> Multicast 1), and I have two possible scenarios:

1: If I run the test quickly (about 5 minutes) after first diffuse in the Hub --> Spoke direction, the broadcast works and I see the stream passing through, but I also see the registration request to the RP (HUB) passing through at the same time:

2: If I run the test without having broadcast in the Hub --> Spoke direction beforehand or too long afterwards, the broadcast doesn't work and I get Register-Stops from the RP:

I would like to clarify that I have tried the NHRP authentication recently added to my topology, so the issue is not related to this command. Below, you will find the configuration of my Cisco HUB and my FRR Spoke. I am using tagged sub-interfaces on both sides of my topology for the clients behind my Hub and Spoke. I also tried without the sub-interfaces, but I encountered the same issue. Thank you in advance for the help provided 👍

HUB Cisco :

ip multicast-routing
!
interface Tunnel1000
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip pim nbma-mode
 ip pim sparse-mode
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp holdtime 30
 ip nhrp registration no-unique
 ip ospf network point-to-multipoint
 ip ospf hello-interval 10
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 42
!
interface FastEthernet0/0
 ip address 192.168.0.1 255.255.255.0
 duplex half
!
interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet1/0.10
 encapsulation dot1Q 10
 ip address 172.16.100.254 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 network 10.0.0.0 0.0.0.255 area 0
 network 172.16.100.0 0.0.0.255 area 0
!
ip pim rp-address 10.0.0.1
!

Spoke FRR (frr.conf)

frr version 10.2-dev-MyOwnFRRVersion
frr defaults traditional
hostname Debian12
log syslog informational
no ipv6 forwarding
ip pim rp 10.0.0.1 224.0.0.0/4
nhrp multicast-nflog-group 2
service integrated-vtysh-config
!
interface enp0s3
 ip address 192.168.0.2/24
 ip pim
exit
!
interface tunnel1
 ip address 10.0.0.2/32
 ip nhrp map 10.0.0.1 192.168.0.1
 ip nhrp map multicast 192.168.0.1
 ip nhrp network-id 1
 ip nhrp nhs dynamic nbma 192.168.0.1
 ip nhrp registration no-unique
 ip ospf network point-to-point dmvpn
 ip pim
exit
!
interface enp0s8.10
 ip igmp
 ip pim
exit
!
router ospf
 network 10.0.0.0/24 area 0
 network 172.16.10.0/24 area 0
exit
!

Spoke FRR (interfaces.conf)

auto enp0s8.10
iface enp0s8.10 inet static
    address 172.16.10.254
    netmask 255.255.255.0
    vlan-raw-device enp0s8
    vlan-id 10

auto tunnel1
iface tunnel1 inet static
    address 10.0.0.2
    netmask 255.255.255.255
    pre-up ip tunnel add tunnel1 mode gre key 42 ttl 64 dev enp0s3
    pre-up ip link set dev tunnel1 mtu 1400
    up ip link set dev tunnel1 up

Spoke FRR (nftables.conf)

table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority filter; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
                oifname "tunnel1" ip daddr 224.0.0.0/24 log group 2
                oifname "tunnel1" ip daddr 224.0.0.0/24 drop
        }

}

Version

FRRouting 10.2-dev-MyOwnFRRVersion-g54134b479 (Debian12) on Linux(6.1.0-13-amd64).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
This is a git build of frr-10.2-dev-128-g54134b479
Associated branch(es):
    local:master
    github/frrouting/frr.git/master

configured with:
    '--prefix=/usr' '--includedir=${prefix}/include' '--bindir=${prefix}/bin' '--sbindir=${prefix}/lib/frr' '--libdir=${prefix}/lib/frr' '--libexecdir=${prefix}/lib/frr' '--localstatedir=/var/run/frr' '--sysconfdir=/etc/frr' '--with-moduledir=${prefix}/lib/frr/modules' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-snmp=agentx' '--enable-multipath=64' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--with-pkg-git-version' '--with-pkg-extra-version=-MyOwnFRRVersion' '--enable-scripting' '--with-scriptdir'

How to reproduce

1: Reproduce the explained topology 2: Broadcast first from HUB --> SPK, then from SPK --> HUB to achieve scenario 1 3: Broadcast only from SPK --> HUB to achieve scenario 2

Expected behavior

Broadcast working as expected (SPK --> HUB)

Actual behavior

Broadcast not working as expected (SPK --> HUB)

Additional context

No response

Checklist

• [X] I have searched the open issues for this bug.
• [X] I have not included sensitive information in this report.

[aapostoliuk]

Try to add 224.1.1.1 or all multicast range to a forward chain and direct it to the nflog group 2. I am testing multicast streaming through FRR DMVPN now. If I do not forward the stream to the nflog group, GRE header has dst address - multicast address. If I forward the stream to nflog, it has the correct GRE header. Something like this:

table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                oifname "tunnel1" ip daddr 224.1.1.1/32 log group 2
                oifname "tunnel1" ip daddr 224.1.1.1/32 drop
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
                oifname "tunnel1" ip daddr 224.0.0.0/24 log group 2
                oifname "tunnel1" ip daddr 224.0.0.0/24 drop
        }

}

[Alt0S04]

Hello Apostoliuk,

I tried your solution, which involved adding a configuration in nftables.conf, but it didn’t solve the issue on my end.

My main problem is that I can only get multicast traffic to flow in one direction in my DMVPN. Multicast 1 can send a video to Multicast 2, but not the other way around. I’m not sure if this issue is due to the type of PIM I used or because I’m using a DMVPN.