Bridge not forwarding multicast traffic to the tap interface

Discussion:

Terry T

2016-05-13 16:06:51 UTC

I have a Debian 8 64-bit machine set up as a server and apt-got the tinc
package. I configured tinc as a bridge and everything seems normal except
that the tunnel does not forward multicast traffic.

I used tcpdump to examine the br0, eth0 and tap interfaces. I could see
multicast packets on both br0 and eth0, but there is no such packet present
on the tap interface. I don't quite know why that is.

br0 Link encap:Ethernet HWaddr 7a:22:d7:1b:04:2e
inet addr:10.10.189.254 Bcast:10.10.189.255 Mask:255.255.255.0
inet6 addr: fe80::d227:88ff:fee5:2078/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3569 errors:0 dropped:0 overruns:0 frame:0
TX packets:2773 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1125028 (1.0 MiB) TX bytes:429677 (419.6 KiB)

eth0 Link encap:Ethernet HWaddr d0:27:88:e5:20:78
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:56890 errors:0 dropped:0 overruns:0 frame:0
TX packets:2869 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:26184692 (24.9 MiB) TX bytes:444021 (433.6 KiB)

tap0 Link encap:Ethernet HWaddr ae:a2:e1:cd:aa:68
inet6 addr: fe80::aca2:e1ff:fecd:aa68/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2336 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:1015186 (991.3 KiB)

bridge name bridge id STP enabled interfaces
br0 8000.7a22d71b042e no eth0
tap0

Samples of the tcpdump on the bridge.

***@lionrock:/home/terry# tcpdump -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:03:04.185117 IP 10.10.189.254.30022 > 116.19.81.143.53880: Flags [P.],
seq 3950669668:3950669856, ack 1682193163, win 317, options [nop,nop,TS val
425064 ecr 4674355], length 188
00:03:04.242176 IP 116.19.81.143.53880 > 10.10.189.254.30022: Flags [.],
ack 188, win 1066, options [nop,nop,TS val 4674385 ecr 425064], length 0
00:03:04.269393 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 211
00:03:04.292112 IP 10.93.112.115.47978 > 224.10.86.1.2013: UDP, length 11
00:03:04.385814 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.406215 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.420350 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.422856 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.424661 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011

***@lionrock:/home/terry# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:03:48.657143 IP 10.10.189.254.30022 > 116.19.81.143.53880: Flags [P.],
seq 3950676648:3950676836, ack 1682193487, win 317, options [nop,nop,TS val
436182 ecr 4685479], length 188
00:03:48.715103 IP 116.19.81.143.53880 > 10.10.189.254.30022: Flags [.],
ack 188, win 1313, options [nop,nop,TS val 4685503 ecr 436182], length 0
00:03:48.754522 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:48.769103 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:48.872717 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 361
00:03:48.941631 IP 10.68.150.37.54718 > 224.10.86.7.2014: UDP, length 11
00:03:48.993608 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 461
00:03:49.012100 IP 10.93.112.115.45907 > 224.10.86.3.2014: UDP, length 11
00:03:49.105880 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 161
00:03:49.115551 IP 10.68.150.38.59286 > 224.10.86.7.2003: UDP, length 11
00:03:49.155296 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011

***@lionrock:/home/terry# tcpdump -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:04:41.417898 IP 10.10.189.1 > all-systems.mcast.net: igmp query v2
00:04:41.494373 IP 10.10.189.254.ntp > 10.10.189.255.ntp: NTPv4, Broadcast,
length 48
00:04:44.529568 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, Hello,
length 38
00:04:47.132901 IP 10.10.189.101 > 239.255.255.250: igmp v2 report
239.255.255.250
00:04:57.828645 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:04:57.828689 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:04:57.828847 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:04:57.828906 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:05:13.927163 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, Hello,
length 38
00:05:16.146586 IP 10.10.189.101.netbios-dgm > 10.10.189.255.netbios-dgm:
NBT UDP PACKET(138)

This really got me stumped. I've searched high and low for a clue but
haven't really come across with anything that helps.

Terry T

2016-05-13 17:27:10 UTC

Permalink

yes, ip_forward was turned on.

iptables is defaulted to ACCEPT policy on all the 3 chains.

Post by Terry T
I have a Debian 8 64-bit machine set up as a server and apt-got the tinc
package. I configured tinc as a bridge and everything seems normal except
that the tunnel does not forward multicast traffic.

Did you enable forwarding (echo 1 >/proc/sys/net/ipv4/ip_forward) and
allow forwarding in your iptables rules?
--
Met vriendelijke groet / with kind regards,
_______________________________________________
tinc mailing list
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Terry T

2016-05-13 17:47:40 UTC

Permalink

no. the multicast packets were generated by a remote server that has a TTL
of 3.

There was a blog which talks about multicast on tap. I made those changes
that he suggested, but it was in vain.

http://blog.michael.kuron-germany.de/2015/07/arp-and-multicast-packets-lost-with-openvpn-in-tap-mode/

Post by Terry T
yes, ip_forward was turned on.
iptables is defaulted to ACCEPT policy on all the 3 chains.

Hm. What is generating the multicast traffic? Could it be that the TTL
on the pacets is set to 1, so it will not be forwarded?
--
Met vriendelijke groet / with kind regards,
_______________________________________________
tinc mailing list
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Liang Guo

2016-05-14 06:54:27 UTC

Permalink

Post by Terry T
tap0 Link encap:Ethernet HWaddr ae:a2:e1:cd:aa:68
inet6 addr: fe80::aca2:e1ff:fecd:aa68/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2336 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:1015186 (991.3 KiB)
bridge name bridge id STP enabled interfaces
br0 8000.7a22d71b042e no eth0
tap0

tap0 RX packets is 0, can you double check your tinc config is correct?

You'd better remove tap0 from br0, configure sufficient ip address on
tap0, then check the connection with other tinc nodes.

--
Liang Guo
http://guoliang.me/

Terry T

2016-05-22 07:10:43 UTC

Permalink

As it turns out, it's a bug in the igmp snooping code in the kernel that's
the problem with multicast traffic not being forwarded.

This seems to affect recent versions. To check if it's turned on, run
cat /sys/devices/virtual/net/<bridgename>/bridge/multicast_snooping

If it's 1, it's highly this is the culprit causing the non-propagation of
the multicast traffic. The solution is to turn it off by setting it 0.

echo 0 > /sys/devices/virtual/net/<bridge name>/bridge/multicast_snooping

Post by Liang Guo

tap0 RX packets is 0, can you double check your tinc config is correct?
You'd better remove tap0 from br0, configure sufficient ip address on
tap0, then check the connection with other tinc nodes.
--
Liang Guo
http://guoliang.me/
_______________________________________________
tinc mailing list
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc