Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not forwarding multicast (Linux kernel (config) issue?) #14

Closed
T-X opened this issue May 15, 2019 · 3 comments
Closed

Not forwarding multicast (Linux kernel (config) issue?) #14

T-X opened this issue May 15, 2019 · 3 comments

Comments

@T-X
Copy link
Contributor

T-X commented May 15, 2019

Setup:

Same as in #13.

Issue:

router2 receives PIM Join/Prune from router1 and receives ICMPv6 multicast messages from client2 but does not forward these to router1.

Details:

Ignoring the issues discovered for router0 in #13 for now, router2 should still forward to router1 as at least router1 sends correct pim-join-prune messages to router2 due to the listener on client2. However:

Packets are received on lan0 of router2 from client2 fine:

router2$ timeout 15 tcpdump -c3 -i lan0 -n -v -l icmp6
tcpdump: listening on lan0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:44:28.336339 IP6 (flowlabel 0x65e89, hlim 1, next-header ICMPv6 (58) payload length: 64) fd5c:725:2841:103::2 > ff13:23:42:ffff::123: [icmp6 sum ok] ICMP6, echo request, seq 245
18:44:29.360333 IP6 (flowlabel 0x65e89, hlim 1, next-header ICMPv6 (58) payload length: 64) fd5c:725:2841:103::2 > ff13:23:42:ffff::123: [icmp6 sum ok] ICMP6, echo request, seq 246
18:44:30.388044 IP6 (flowlabel 0x65e89, hlim 1, next-header ICMPv6 (58) payload length: 64) fd5c:725:2841:103::2 > ff13:23:42:ffff::123: [icmp6 sum ok] ICMP6, echo request, seq 247
3 packets captured
3 packets received by filter
0 packets dropped by kernel

However they are not forwarded to router1 on wan0:

router2$ timeout 15 tcpdump -c3 -i wan0 -n -v -l icmp6
tcpdump: listening on wan0, link-type EN10MB (Ethernet), capture size 262144 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel

The pim6sd internal routing table on router2 looks like this:

Multicast Routing Table
 Source          Group           RP-addr         Flags
---------------------------(*,G)----------------------------
 IN6ADDR_ANY     ff13:23:42:ffff::123 fd5c:725:2841:1::3 WC RP
Joined   oifs: j..                 
Pruned   oifs: ...                 
Leaves   oifs: ...                 
Asserted oifs: ...                 
Outgoing oifs: o..                 
Incoming     : ..I                 
Upstream nbr: NONE

TIMERS: Entry=185 JP=40 RS=0 Assert=0
  MIF   0   1   2   3   4   5   6   7   8   9
    0 185   0   0
---------------------------(S,G)----------------------------
 fd5c:725:2841:103::2 ff13:23:42:ffff::123 fd5c:725:2841:1::3 SPT CACHE SG
Joined   oifs: ...                 
Pruned   oifs: ...                 
Leaves   oifs: ...                 
Asserted oifs: ...                 
Outgoing oifs: o..                 
Incoming     : .I.                 
Upstream nbr: NONE

TIMERS: Entry=195 JP=40 RS=0 Assert=0
  MIF   0   1   2   3   4   5   6   7   8   9
    0   0   0   0

And there is an entry in "ip -6 mroute show":

router2$ ip -6 mroute show
(fd5c:725:2841:103::2,ff13:23:42:ffff::123) Iif: lan0       Oifs: wan0  State: resolved

Also, multicast forwarding seems to be correctly enabled in the kernel:

router2$ cat /proc/sys/net/ipv6/conf/wan0/mc_forwarding 
1
router2$ cat /proc/sys/net/ipv6/conf/lan0/mc_forwarding 
1
router2$ cat /proc/sys/net/ipv6/conf/all/mc_forwarding 
1

So I'm a bit confused why the ICMPv6 multicast packets are not forwarded from router2 to router1. The Linux kernel in use is a 4.19.28 kernel as provided by Debian Sid. (I'm probably missing something obvious?)

@troglobit
Copy link
Owner

Weird, everything seems to look OK, from what my tired eyes can see atm.

You've checked the TTL?

@T-X
Copy link
Contributor Author

T-X commented May 15, 2019

Urgh! That was it :D.

Sorry, had read your excellent blog posts on multicast several times and you did mention to watch the TTL... but I forgot :-).

Now the ping6 from client2 arrives on client1 via router2->router1 fine and this echo request is then replied to via unicast and arrives back on client2 again.

@T-X T-X closed this as completed May 15, 2019
@troglobit
Copy link
Owner

Ha ha ha, awesome! ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants