Subject: gre(4) and multicast
To: None <tech-net@netbsd.org>
From: Miles Nordin <carton@Ivy.NET>
List: tech-net
Date: 05/12/2005 14:40:20
--pgp-sign-Multipart_Thu_May_12_14:40:20_2005-1
Content-Type: text/plain; charset=US-ASCII

I'm trying to run OSPF (IPv4 and IPv6) over NetBSD's gre(4), and it's
not working.

On the following machine, ezln, Quagga's ospf6d is listening on both
tlp4 and gre0.  tlp4 is an Ethernet with another OSPFv3 router on it,
and gre0 is a tunnel to lucette.  When I ping the OSPFv3 multicast
address on tlp4, both routers answer, but over gre0 I get no answers.

It could be a quagga bug, but since the NetBSD gre(4) v6 support is so
new and I know others are using Quagga/gre successfully, I thought a
lingering gre multicast bug was pretty likely, and I'd ask here if
someone recognizes this as a quick-fix.

-----8<-----
ezln:~$ ifconfig gre0
gre0: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> mtu 1476
        tunnel inet 216.158.24.218 --> 216.158.24.217
        inet 216.158.24.215 -> 216.158.24.214 netmask 0xffffffff
        inet6 fe80::200:f8ff:fe77:8168%gre0 ->  prefixlen 64 scopeid 0x10
ezln:~$ sudo ping6 ff02::5%tlp4
PING6(56=40+8+8 bytes) fe80::200:d1ff:fe1a:3919%tlp4 --> ff02::5%tlp4
16 bytes from fe80::200:d1ff:fe1a:3919%tlp4, icmp_seq=0 hlim=64 time=0.792 ms
16 bytes from fe80::260:97ff:fe89:9edb%tlp4, icmp_seq=0 hlim=64 time=2.712 ms(DUP!)
16 bytes from fe80::260:97ff:fe89:9edb%tlp4, icmp_seq=1 hlim=64 time=1.535 ms
16 bytes from fe80::200:d1ff:fe1a:3919%tlp4, icmp_seq=1 hlim=64 time=4.985 ms(DUP!)
^C
--- ff02::5%tlp4 ping6 statistics ---
2 packets transmitted, 2 packets received, +2 duplicates, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.792/2.506/4.985/1.587 ms

ezln:~$ sudo ping6 ff02::5%gre0
PING6(56=40+8+8 bytes) fe80::200:f8ff:fe77:8168%gre0 --> ff02::5%gre0
^C
--- ff02::5%gre0 ping6 statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
-----8<-----

There is working gre connectivity to lucette:

-----8<-----
ezln:~$ ping6 fe80::203:baff:fe0f:aa45%gre0
PING6(56=40+8+8 bytes) fe80::200:f8ff:fe77:8168%gre0 --> fe80::203:baff:fe0f:aa45%gre0
16 bytes from fe80::203:baff:fe0f:aa45%gre0, icmp_seq=0 hlim=64 time=0.757 ms
16 bytes from fe80::203:baff:fe0f:aa45%gre0, icmp_seq=1 hlim=64 time=0.99 ms
16 bytes from fe80::203:baff:fe0f:aa45%gre0, icmp_seq=2 hlim=64 time=0.798 ms
^C
-----8<-----

What's more, the multicast pings do reach lucette:

-----8<-----
lucette:~# ifconfig gre0
gre0: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> mtu 1476
        tunnel inet 216.158.24.217 --> 216.158.24.218
        inet 216.158.24.214 -> 216.158.24.215 netmask 0xffffffff
        inet6 fe80::203:baff:fe0f:aa45%gre0 ->  prefixlen 64 scopeid 0xa
lucette:~# tcpdump -n -p -i gre0
tcpdump: listening on gre0
18:21:41.062395 fe80::200:f8ff:fe77:8168 > ff02::5: icmp6: echo request (len 16, hlim 64)
18:21:41.357008 fe80::203:baff:fe0f:aa45 > ff02::5: OSPFv3-hello 36: rtrid 192.168.168.4 backbone V6/E/R ifid 0.0.0.10 pri 1 int 10 dead 40 nbrs [hlim 1] (len 36)
18:21:42.061330 fe80::200:f8ff:fe77:8168 > ff02::5: icmp6: echo request (len 16, hlim 64)
18:21:42.757772 fe80::200:f8ff:fe77:8168 > ff02::5: OSPFv3-hello 36: rtrid 192.168.168.1 backbone V6/E/R ifid 0.0.0.16 pri 1 int 10 dead 40 nbrs [hlim 1] (len 36)
18:21:43.061314 fe80::200:f8ff:fe77:8168 > ff02::5: icmp6: echo request (len 16, hlim 64)
-----8<-----

it's just that lucette doesn't feel inclined to answer them.  I
noticed another odd thing, but I think it's unrelated.  If I use
pkgsrc tcpdump on the unicast ping, the ping that lucette _does_
answer just fine, I get:

(on lucette)
-----8<-----
18:23:08.231209 IP6 , wrong link-layer encapsulationbad-hlen 0
18:23:08.231253 fe80::203:baff:fe0f:aa45 > fe80::200:f8ff:fe77:8168: [icmp6 sum ok] icmp6: echo reply seq 5 (len 16, hlim 64)
18:23:09.231265 IP6 , wrong link-layer encapsulationbad-hlen 0
18:23:09.231308 fe80::203:baff:fe0f:aa45 > fe80::200:f8ff:fe77:8168: [icmp6 sum ok] icmp6: echo reply seq 6 (len 16, hlim 64)
-----8<-----

so, you can see tcpdump is printing an error in place of the received
echo-request packet, but the echo-reply sent out in response to this
supposedly corrupt received packet is decoded by tcpdump okay.  On
ezln, the pinger, it's just the opposite---the echo replies are
replaced with errors:

-----8<-----
18:30:12.758019 fe80::200:f8ff:fe77:8168 > fe80::203:baff:fe0f:aa45: [icmp6 sum ok] icmp6: echo request seq 2 (len 16, hlim 64)
18:30:12.758365 IP6 , wrong link-layer encapsulationbad-hlen 0
16 bytes from fe80::203:baff:fe0f:aa45%gre0, icmp_seq=3 hlim=64 time=1.083 ms
18:30:13.757712 fe80::200:f8ff:fe77:8168 > fe80::203:baff:fe0f:aa45: [icmp6 sum ok] icmp6: echo request seq 3 (len 16, hlim 64)
18:30:13.758206 IP6 , wrong link-layer encapsulationbad-hlen 0
-----8<-----

so, there is this odd tcpdump problem, and then there is the multicast
group-membership problem.

pinging the all-multicast address does work---i get replies from the
far end only with IPv4, and from both ends with IPv6:

-----8<-----
ezln:~$ ping -I 216.158.24.215 224.0.0.1
PING ALL-SYSTEMS.MCAST.NET (224.0.0.1): 56 data bytes
64 bytes from 216.158.24.214: icmp_seq=0 ttl=255 time=1.591 ms
64 bytes from 216.158.24.214: icmp_seq=1 ttl=255 time=2.801 ms
64 bytes from 216.158.24.214: icmp_seq=2 ttl=255 time=1.121 ms
^C
----ALL-SYSTEMS.MCAST.NET PING Statistics----
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.121/1.838/2.801/0.867 ms
ezln:~$ ping6 ff02::1%gre0
PING6(56=40+8+8 bytes) fe80::200:f8ff:fe77:8168%gre0 --> ff02::1%gre0
16 bytes from fe80::200:f8ff:fe77:8168%gre0, icmp_seq=0 hlim=64 time=0.889 ms
16 bytes from fe80::203:baff:fe0f:aa45%gre0, icmp_seq=0 hlim=64 time=2.208 ms(DUP!)
16 bytes from fe80::200:f8ff:fe77:8168%gre0, icmp_seq=1 hlim=64 time=1.293 ms
16 bytes from fe80::203:baff:fe0f:aa45%gre0, icmp_seq=1 hlim=64 time=2.919 ms(DUP!)
^C
--- ff02::1%gre0 ping6 statistics ---
2 packets transmitted, 2 packets received, +2 duplicates, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.889/1.827/2.919/0.791 ms
-----8<-----


--pgp-sign-Multipart_Thu_May_12_14:40:20_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQoOjFInCBbTaW/4dAQJx3AP/TWnoUUIIJbLt001vWItUu/uf8wjDgvTW
uEOFzBzKVEIU11UG8wP1X0Zt+dAp2E2sWR1HBj1K+gW1PxbC7v0ctATVsHEYkTxX
yQOg2ALPEuUAV9+GGZPHyBgnT+xF3EJ2rdPkpOI6TN6a5tAiC2MZaPP6wnmwH07L
4zwDR2xQ1/A=
=F4MW
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_May_12_14:40:20_2005-1--