PIMD only worknig in one direction - wrong input vif for remote source #243

Snafu · 2023-11-17T20:30:51Z

Hello troglobit,
I'm using pimd in order to forward the multicast data from two LANs of different routers (pfSense, FreeBSD14.0) to each other, connected via WireGuard tunnel. On router A it is the LAN 192.168.11.0/24 and on router B it is the LAN 192.168.22.0/24, see image below. In LAN 192.168.11.0/24 there are two KNX/IP routers (192.168.11.30 and 192.168.11.35) and in LAN 192.168.22.0/24 there is one KNX/IP router (192.168.22.20) that all broadcast packets to multicast group 224.0.23.12. Within the LAN 192.168.11.0/24 everything works great, now I want to get the KNX/IP router from the other LAN to join the party.

                    ┌────────────┐                                          ┌────────────┐
                    │            │                                          │            │
             igb1.1 │   Router   │ tun_wg1                          tun_wg0 │   Router   │ re2.1
                ────┤            ├──────────────────────────────────────────┤            ├────
    192.168.11.1/24 │     A      │ 10.1.22.1/24                10.1.22.2/24 │     B      │ 192.168.22.1/24
                    │            │                                          │            │
                    └────────────┘                                          └────────────┘

Issue

I currently have it half way working, meaning I can see all multicast data in the LAN of router B. In the LAN of router A, howerver, I can only see the local multicast data. From what I can see it seems as if on router A the wrong Vif is used as input for the remote source. Instead of Vif 4 it shows the Vif 17 register_vif0 as input.
On router B it correctly shows Vif 2 (tun_wg0) as input for the remote source.
Is my assumption correct or is the pimd -r output OK in your mind and I have some other issue? (Hints appreciated)
I've got static routes configured on both routers, multicast is enabled on all involved interfaces and firewall rules are configured correctly as well. I can see PIM messages from 192.168.22.1 to 192.168.11.1 on the tunnel network.

Edit: I just swapped the DR role and made 192.168.22.1 the RP on both routers and now I have the same issue just the other way round. The router which is acting as RP somehow can't handle the broadcasts properly.

Router A

admin@RouterA: netstat -arn4 | egrep "Destination|10.1.22."
Destination        Gateway            Flags     Netif Expire
10.1.22.0/24       link#15            U       tun_wg1
10.1.22.1          link#10            UHS         lo0
192.168.22.0/24    10.1.22.2          UGS     tun_wg1

admin@RouterA: cat /var/etc/pimd/pimd.conf
##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
phyint igb1.1 enable
phyint tun_wg1 enable
rp-address 192.168.11.1 224.0.0.0/16

admin@RouterA: pimd -r
Virtual Interface Table ======================================================
Vif  Local Address    Subnet              Thresh  Flags      Neighbors
---  ---------------  ------------------  ------  ---------  -----------------
  0   --REDACTED--   --REDACTED--              1  DISABLED
  1   --REDACTED--   --REDACTED--              1  DISABLED
  2   --REDACTED--   --REDACTED--              1  DISABLED
  3  192.168.11.1     192.168.11               1  DR NO-NBR
  4   --REDACTED--   --REDACTED--              1  DISABLED
  5   --REDACTED--   --REDACTED--              1  DISABLED
  6   --REDACTED--   --REDACTED--              1  DISABLED
  7   --REDACTED--   --REDACTED--              1  DISABLED
  8   --REDACTED--   --REDACTED--              1  DISABLED
  9   --REDACTED--   --REDACTED--              1  DISABLED
 10   --REDACTED--   --REDACTED--              1  DISABLED
 11   --REDACTED--   --REDACTED--              1  DISABLED
 12   --REDACTED--   --REDACTED--              1  DISABLED
 13  10.1.22.1        10.1.22/24               1  PIM        10.1.22.2    
 14   --REDACTED--   --REDACTED--              1  DISABLED
 15   --REDACTED--   --REDACTED--              1  DISABLED
 16   --REDACTED--   --REDACTED--              1  DISABLED
 17  192.168.11.1     register_vif0            1

 Vif  SSM Group        Sources

Multicast Routing Table ======================================================
----------------------------------- (*,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
INADDR_ANY       224.0.23.12      192.168.11.1     WC RP
Joined   oifs: .............j....  
Pruned   oifs: ..................  
Leaves   oifs: ...l..............  
Asserted oifs: ..................  
Outgoing oifs: ...o.........o....  
Incoming     : .................I  

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17
           205    55     0       0        0  0  0  0  0  0  0  0  0  0  0  0  0 205  0  0  0  0
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.11.30    224.0.23.12      192.168.11.1     SPT CACHE SG
Joined   oifs: .............j...j  
Pruned   oifs: ..................  
Leaves   oifs: ...l..............  
Asserted oifs: ..................  
Outgoing oifs: ...o.........o...o  
Incoming     : ...I..............  

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17
           170    15     0       0        0  0  0  0  0  0  0  0  0  0  0  0  0 170  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.11.35    224.0.23.12      192.168.11.1     SPT CACHE SG
Joined   oifs: .............j...j  
Pruned   oifs: ..................  
Leaves   oifs: ...l..............  
Asserted oifs: ..................  
Outgoing oifs: ...o.........o...o  
Incoming     : ...I..............  

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17
           170    15     0       0        0  0  0  0  0  0  0  0  0  0  0  0  0 170  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.22.20    224.0.23.12      192.168.11.1     RP SG
Joined   oifs: ..................  
Pruned   oifs: .............p....  
Leaves   oifs: ...l..............  
Asserted oifs: ..................  
Outgoing oifs: ...o..............  
Incoming     : .................I  

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17
           205     5     0       0        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
--------------------------------- (*,*,G) ------------------------------------
Number of Groups: 1
Number of Cache MIRRORs: 2
------------------------------------------------------------------------------

admin@RouterA: tcpdump -n -i igb1.1 host 224.0.23.12 and udp port 3671
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb1.1, link-type EN10MB (Ethernet), capture size 262144 bytes
20:01:38.346263 IP 192.168.11.30.3671 > 224.0.23.12.3671: UDP, length 19
20:01:40.355148 IP 192.168.11.30.3671 > 224.0.23.12.3671: UDP, length 19
20:01:48.346161 IP 192.168.11.30.3671 > 224.0.23.12.3671: UDP, length 19
20:01:58.343534 IP 192.168.11.30.3671 > 224.0.23.12.3671: UDP, length 19
... (nothing from 192.168.22.20)

Router B

admin@RouterB: netstat -arn4 | egrep "Destination|10.1.22."
Destination        Gateway            Flags     Netif Expire
10.1.22.0/24       link#9             U       tun_wg0
10.1.22.2          link#5             UHS         lo0
192.168.11.0/24    10.1.22.1          UGS     tun_wg0

admin@RouterB: cat /var/etc/pimd/pimd.conf
##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
phyint re2.1 enable dr-priority 1
phyint tun_wg0 enable dr-priority 100
rp-address 192.168.11.1 224.0.0.0/16

admin@RouterB: pimd -r
Virtual Interface Table ======================================================
Vif  Local Address    Subnet              Thresh  Flags      Neighbors
---  ---------------  ------------------  ------  ---------  -----------------
  0   --REDACTED--   --REDACTED--              1  DISABLED
  1   --REDACTED--   --REDACTED--              1  DISABLED
  2  192.168.22.1     192.168.22               1  DR NO-NBR
  3   --REDACTED--   --REDACTED--              1  DISABLED
  4  10.1.22.2        10.1.22/24               1  DR PIM     10.1.22.1
  5   --REDACTED--   --REDACTED--              1  DISABLED
  6  192.168.22.1     register_vif0            1

 Vif  SSM Group        Sources

Multicast Routing Table ======================================================
----------------------------------- (*,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
INADDR_ANY       224.0.23.12      192.168.11.1     WC RP CACHE
Joined   oifs: .......
Pruned   oifs: .......
Leaves   oifs: ..l....
Asserted oifs: .......
Outgoing oifs: ..o....
Incoming     : ....I..

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6
             0    15     0       0        0  0  0  0  0  0  0
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.11.30    224.0.23.12      192.168.11.1     SG
Joined   oifs: .......
Pruned   oifs: .......
Leaves   oifs: ..l....
Asserted oifs: .......
Outgoing oifs: ..o....
Incoming     : ....I..

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6
           175    30     0       0        0  0  0  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.11.35    224.0.23.12      192.168.11.1     SG
Joined   oifs: .......
Pruned   oifs: .......
Leaves   oifs: ..l....
Asserted oifs: .......
Outgoing oifs: ..o....
Incoming     : ....I..

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6
            75    50     0       0        0  0  0  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.22.20    224.0.23.12      192.168.11.1     CACHE SG
Joined   oifs: ......j
Pruned   oifs: .......
Leaves   oifs: ..l....
Asserted oifs: .......
Outgoing oifs: ..o...o
Incoming     : ..I....

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6
           200    30     0       0        0  0  0  0  0  0  0
--------------------------------- (*,*,G) ------------------------------------
Number of Groups: 1
Number of Cache MIRRORs: 2
------------------------------------------------------------------------------

admin@RouterB: tcpdump -n -i re2.1 host 224.0.23.12 and udp port 3671
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re2.1, link-type EN10MB (Ethernet), capture size 262144 bytes
20:01:56.362781 IP 192.168.22.20.3671 > 224.0.23.12.3671: UDP, length 19
20:01:56.398748 IP 192.168.22.20.3671 > 224.0.23.12.3671: UDP, length 19
20:01:58.351551 IP 192.168.11.30.3671 > 224.0.23.12.3671: UDP, length 19
20:02:06.363115 IP 192.168.22.20.3671 > 224.0.23.12.3671: UDP, length 19
20:02:06.399144 IP 192.168.22.20.3671 > 224.0.23.12.3671: UDP, length 19
20:02:08.351342 IP 192.168.11.30.3671 > 224.0.23.12.3671: UDP, length 19
...

The text was updated successfully, but these errors were encountered:

roelbroersma · 2023-11-21T20:26:39Z

I have exactly the same problem! Also using KNX/IP Router here. I even use the same multicast group: 224.0.23.12 and port: 3671.

The multicast traffic from site A is seen at site B.
However, the multicast traffic from site B is not seen at site A. It isn't even seen at the tunnel interface at site B!

But, when setting the RP -and- the BSR to Site A, it works. Havinf only the RP or the BSR at site B, it doesn't work anymore and we see the same problem (multicast traffic from site B is seen at the eth0 interface, but not at the tap0 interface).

I am using OpenVPN v2.6.3 in TAP mode.
I am using a much more simplified setup (just 2 Raspberry Pi's) with 1x eth0 and 1x tap0 interface.
Using pimd v2.3.2, and also tested with latest v3.0-beta1 (downloaded Head at 2023-11-21).
Since it's a test environment, I've made some crazy settings, just to be sure..:
Checked rp_filters (for all interfaces, it is off)
Checked mc_forwarding (for all interfaces, it is on)
Promisc mode for all interfaces is enabled (e.g. ip link set dev eth0 promisc on)
IP forwarding (and even bc_forwarding) is enabled for all interfaces.
Tested with spt-thresshold packets 0 interval 100 at both sides and also tested with spt-thresshold infinity interval 100 (just to rule out the SPT stuff).

          Site A                                                    Site B
(running PIMD with BSR and RP)                                 (running PIMD)

 ┌──────────────────────┐                                  ┌────────────────────────┐
 |                      |                                  |                        |
 |    172.16.199.1/24   | tap0                        tap0 | 172.16.199.2/24        |
 |   OpenVPN (server)   |----------------------------------|      OpenVPN (client)  |
 |   192.168.4.56/24    |                                  |     192.168.11.128/24  |
 |                      |                                  |                        |
 └──────────────────────┘                                  └────────────────────────┘
                | eth0                                          eth0 |
                |                                                    |
                |                                                    |
                |                                                    |
 ┌────────────────────────┐                                 ┌────────────────────────────┐
 | Client-A 192.168.4.1/24|                                 | Client-B 192.168.11.196/24 |
 └────────────────────────┘                                 └────────────────────────────┘

Snafu · 2023-11-22T18:55:13Z

Thanks a lot for your response @roelbroersma! In pfSense I can only configure the "interfaces on which to enable Bootstrap Router (BSR) candidate election participation".
I'm not very familiar with PIMD yet. It's my first time poking around. Is it sufficient to set the tunnel interface on router A as the BSR candidate?
Could you please post your (redacted) pimd.conf that works in your described setup?

I cannot test at the moment because the tunnel to router B is down for a few days.
My config (here router A) would now look like this:

##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
phyint igb1.1 enable
phyint tun_wg1 enable
bsr-candidate tun_wg1
rp-address 192.168.11.1 224.0.0.0/16

roelbroersma · 2023-11-23T08:44:04Z

@Snafu I think we should ask @troglobit about this one.

It seems to look like a bug. Probably has something todo with wrong in/out interface.

roelbroersma · 2023-12-08T10:55:30Z

Hi @troglobit Can you shine your light on this? Do you have any idea what could be wrong here? If there is something in the code.. but you are unsure.. let me know. I can do a Fork.. commit, PR. Or we can look together at the source..

~Roel

Snafu · 2024-02-16T08:52:03Z

Hi,
sadly this is still an issue for me. @troglobit have you had any time to look into it already?
@roelbroersma if you know what the issue could be and are willing to look into it, it would be much appreciated.

troglobit · 2024-02-17T15:34:43Z

I'm sorry, this is unfortunately not a prioritised project for me anymore. The company I worked for decided to go in another direction and I've since moved on. FYI, I have three other multicast router projects that work, are well tested, and have active coordinators. There are also other PIM-SM projects out there that you can try.

Now, this is not the first report of this problem. So a constructive way forward is if someone could help debug their issue to help narrow things down. I've put a lot of effort into the still-to-be-released 3.0 version, so I can help steward things along, but I really need help debugging and fixing this particular case.

roelbroersma · 2024-02-17T18:30:38Z

Hi troglobit, I can help you work on this issue. Let’s do the following; I build a test environment and set it up so we can see the problem. From then on, we can work together on the issue; I can start tcpdump etc., running and also switch the environment to a working situation and do tcpdump again. We can do Teams or another sharing tool. I can make time for it to help troubleshoot it, however since you have most knowledge of this and the 3.0 you want to release; if I spend time in it, can you do it also? Kind regards, Roel Broersma

troglobit · 2024-02-17T19:03:17Z

@roelbroersma thank you, but like I said, this is not a prioritised project for me. That means I don't have the time (or energy) to troubleshoot and fix issues on it during my spare time. I am however open to reviewing pull-requests to fixes concerning this problem.

To everyone else in this thread, or lurking around pimd, the project has been without activity for quite some time, and this is mainly because of funding and lack of user involvement/PRs. I would love to see pimd succeed since it still has a lot to offer compared to offering from, e.g., Frr. This does, however, require a lot more code contributions from other people since I only have time for reviews and release work.

roelbroersma · 2024-02-17T22:25:54Z

I understand. I personally switched to Udp broadcast relay for the project for which I needed it, but sooner or later I still need a pimd (sort of) daemon.
If I find something and have time for it, I will test, study the code and do a Pull Request.
Thanks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PIMD only worknig in one direction - wrong input vif for remote source #243

PIMD only worknig in one direction - wrong input vif for remote source #243

Snafu commented Nov 17, 2023 •

edited

Loading

roelbroersma commented Nov 21, 2023 •

edited

Loading

Snafu commented Nov 22, 2023

roelbroersma commented Nov 23, 2023

roelbroersma commented Dec 8, 2023

Snafu commented Feb 16, 2024

troglobit commented Feb 17, 2024

roelbroersma commented Feb 17, 2024 via email •

edited

Loading

troglobit commented Feb 17, 2024

roelbroersma commented Feb 17, 2024

PIMD only worknig in one direction - wrong input vif for remote source #243

PIMD only worknig in one direction - wrong input vif for remote source #243

Comments

Snafu commented Nov 17, 2023 • edited Loading

Issue

Router A

Router B

roelbroersma commented Nov 21, 2023 • edited Loading

Snafu commented Nov 22, 2023

roelbroersma commented Nov 23, 2023

roelbroersma commented Dec 8, 2023

Snafu commented Feb 16, 2024

troglobit commented Feb 17, 2024

roelbroersma commented Feb 17, 2024 via email • edited Loading

troglobit commented Feb 17, 2024

roelbroersma commented Feb 17, 2024

Snafu commented Nov 17, 2023 •

edited

Loading

roelbroersma commented Nov 21, 2023 •

edited

Loading

roelbroersma commented Feb 17, 2024 via email •

edited

Loading