gif interface not passing IPv6 packets
Matt Smith
matt at xtaz.co.uk
Mon Sep 26 15:04:38 UTC 2011
On 26 September 2011 15:21, Gary Palmer <gpalmer at freebsd.org> wrote:
> Smells like a routing table problem or similar configuration problem.
> On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings
> to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external
> interface (gif0). I believe that is true for all IPv4 or IPv6 traffic.
Interesting. You could be right then. But I still don't understand
what could have changed as the rc.conf configuration for this is
identical to what it was before the power cut. The deprecated part
just makes the outgoing source address algorithm favour the vr0
address, but the same happens no matter if I include that or not.
ipv6_enable="YES"
ipv6_ifconfig_vr0="2a01:348:294::1 prefixlen 64"
gif_interfaces="gif0"
gifconfig_gif0="192.168.1.2 77.75.104.126"
ipv6_ifconfig_gif0="2a01:348:6:45c::2 2a01:348:6:45c::1 prefixlen 128
deprecated"
ipv6_defaultrouter="2a01:348:6:45c::1"
ipv6_gateway_enable="YES"
rtadvd_enable="YES"
rtadvd_interfaces="vr0"
Which produces:
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
ether 00:40:63:e8:79:3e
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::240:63ff:fee8:793e%vr0 prefixlen 64 scopeid 0x1
inet6 2a01:348:294::1 prefixlen 64
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
tunnel inet 192.168.1.2 --> 77.75.104.126
inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5
inet6 2a01:348:6:45c::2 --> 2a01:348:6:45c::1 prefixlen 128 deprecated
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
options=1<ACCEPT_REV_ETHIP_VER>
Destination Gateway Flags
Netif Expire
::/96 ::1 UGRS
lo0 =>
default 2a01:348:6:45c::1 UGS gif0
::1 ::1 UH lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
2a01:348:6:45c::1 2a01:348:6:45c::2 UH gif0
2a01:348:294::/64 link#1 U vr0
2a01:348:294::1 link#1 UHS lo0
The interesting thing is I've just got the routing table from my
friends working server with similar configuration except his is just a
tunnel without any subnet and his has this:
Destination Gateway Flags
Netif Expire
::/96 ::1 UGRS
lo0 =>
default 2a01:348:6:45d::1 UGS gif0
::1 ::1 UHL lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
2a01:348:6:45d::1 link#3 UHL gif0
2a01:348:6:45d::2 link#3 UHL lo0
I'm wondering why there are clearly significant differences here. If
my configuration didn't work before then I can accept that I've
screwed up in some way but it's worked for months so I don't
understand what's changed now. Unfortunately I don't know what my
routing table looked like originally when it worked but I'm thinking
for some reason when the box boots it's building the routing table
differently to how it was before now?
More information about the freebsd-net
mailing list