Hi!
Am Mittwoch 18 Juni 2025 um 8:43:25 +1000, schrieb David Gwynne 3,1K:
> the net.inet.gre.allow=1 enables gre processing for both ipv4 and
> ipv6.
O.K. - thank you for clarifying!
> dlg@bgp0 ~$ ifconfig gre6
> gre6: flags=248051<UP,POINTOPOINT,RUNNING,MULTICAST,AUTOCONF6TEMP,AUTOCONF6>
> mtu 1476
> index 7 priority 0 llprio 6
> encap: vnetid none txprio payload rxprio packet
> groups: gre
> tunnel: inet6 2001:db8:602:307:c153:217c:4841:6ec4 -->
> 2001:db8:602:307:2387:f6e:62ac:a02 ttl 64 nodf ecn
> inet6 fe80::250:56ff:fea1:5dc3%gre6 --> prefixlen 64 scopeid 0x7
>
> dlg@bgp1 ~$ ifconfig gre6
> gre6: flags=248051<UP,POINTOPOINT,RUNNING,MULTICAST,AUTOCONF6TEMP,AUTOCONF6>
> mtu 1476
> index 8 priority 0 llprio 6
> encap: vnetid none txprio payload rxprio packet
> groups: gre
> tunnel: inet6 2001:db8:602:307:2387:f6e:62ac:a02 -->
> 2001:db8:602:307:c153:217c:4841:6ec4 ttl 64 nodf ecn
> inet6 fe80::250:56ff:fea1:aebe%gre6 --> prefixlen 64 scopeid 0x8
This works from Host A (OpenBSD) to Host B (OpenBSD), but not from Host
A to Host C (Linux) :-(
Tassilo from the Freetransit support (the gre(4) tunnel is for BGP)
replied to following:
"And the other thing I notice is that our linux box sends ipv6
destination options (so it's ipv6 hdr | destination opts | gre header),
while your end sends (ipv6 hdr | gre header). Maybe the ipv6 extension
header gets filtered at your end?"
This is confusing for me ATM... He's ticking off checkboxes with
possible causes of the problem; I'd be happy, if you could explain this
open question / draw on your experience - thank you again for your time!
(I don't know how to debug this with tcpdump from my machine, since I
don't have access to the Linux box)
--
Mit besten Wünschen /
With best wishes,
Manuel Kuklinski
