der Mouse
2008-09-26 20:05:10 UTC
This is something like a followup to my recent messages about v6
troubles, but I've changd the test setup enough that I thought it
deserved a new subject header.
I decided that (a) I wanted my house v6 up again and (b) I wanted a
test setup that wasn't crossed with a production environment. So I
resurrected the former (1.4T) machine as my house v6 gateway and am
trying to get the 3.1 machine to work as a vanilla v6 host.
And even that much doesn't work right.
The scenario: palantir is the 1.4T machine (which, here, is nothing but
a convenient place to ping6 from). Draupadi is the 3.1 machine.
Palantir le0 and draupadi sk0 are in the same broadcast domain.
Palantir le0 is configured with 2610:98:8001:2::/112; draupadi sk0,
2610:98:8001:2::1/112. My test is to "ping6 -n 2610:98:8001:2::1" on
palantir. This returns nothing after a fresh reboot of draupadi
(tcpdump on draupadi shows neighbour sol and neighbour adv, then echo
requests with no echo responses) but can be "fixed".
Palantir is configured by hand after boot; draupadi is configured from
rc.conf.
Two things need to be done to "fix" this. One is to delete the inet6
default route; the other is to delete and re-add 2610:98:8001:2::1/112
on draupadi's sk0. Neither one, alone, makes palantir's ping6 start
working, but doing both of them - in either order - does. If I comment
out the defaultroute6 setting in draupadi's rc.conf, then deleting and
re-adding the address on sk0, by itself, is enough to "fix" things.
Notably absent is the "cannot forward" log messages that were so
visibly present when things were broken in the more complex case. But
the similarity of this misbehaviour and the absence of thsoe messages
here lead me to suspect they are a red herring.
I captured output from ifconfig -au, ndp -na, and netstat -rLnf inet6
in three states: (1) immediately after boot (no defaultroute6), (2)
during a ping6 when "broken", and (3) during a ping6 when "fixed".
Then I diffed those.
2 relative to 1, I see:
- One new line from ndp, showing 2610:98:8001:2::1 with draupadi's MAC:
2610:98:8001:2::1 00:0f:ea:f3:08:7e sk0 permanent R
- The Refs value changes from 0 to 1 on the 2610:98:8001:2::/112 line
in netstat output.
3 relative to 2:
- One new line from ndp, giving 2610:98:8001:2:: with palantir's MAC:
2610:98:8001:2:: 08:00:20:0d:88:a9 sk0 20s R R
There is clearly something I don't understand going on here, but I'm at
a loss to even guess what. If nobody has any ideas, I can just
approach this as a classic debugging problem, adding printfs and such
to trace processing until I figure out the relevant difference between
the two cases, but I find it hard to believe v6 is this badly broken
for everyone, leading me suspect it's me doing something stupid....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
troubles, but I've changd the test setup enough that I thought it
deserved a new subject header.
I decided that (a) I wanted my house v6 up again and (b) I wanted a
test setup that wasn't crossed with a production environment. So I
resurrected the former (1.4T) machine as my house v6 gateway and am
trying to get the 3.1 machine to work as a vanilla v6 host.
And even that much doesn't work right.
The scenario: palantir is the 1.4T machine (which, here, is nothing but
a convenient place to ping6 from). Draupadi is the 3.1 machine.
Palantir le0 and draupadi sk0 are in the same broadcast domain.
Palantir le0 is configured with 2610:98:8001:2::/112; draupadi sk0,
2610:98:8001:2::1/112. My test is to "ping6 -n 2610:98:8001:2::1" on
palantir. This returns nothing after a fresh reboot of draupadi
(tcpdump on draupadi shows neighbour sol and neighbour adv, then echo
requests with no echo responses) but can be "fixed".
Palantir is configured by hand after boot; draupadi is configured from
rc.conf.
Two things need to be done to "fix" this. One is to delete the inet6
default route; the other is to delete and re-add 2610:98:8001:2::1/112
on draupadi's sk0. Neither one, alone, makes palantir's ping6 start
working, but doing both of them - in either order - does. If I comment
out the defaultroute6 setting in draupadi's rc.conf, then deleting and
re-adding the address on sk0, by itself, is enough to "fix" things.
Notably absent is the "cannot forward" log messages that were so
visibly present when things were broken in the more complex case. But
the similarity of this misbehaviour and the absence of thsoe messages
here lead me to suspect they are a red herring.
I captured output from ifconfig -au, ndp -na, and netstat -rLnf inet6
in three states: (1) immediately after boot (no defaultroute6), (2)
during a ping6 when "broken", and (3) during a ping6 when "fixed".
Then I diffed those.
2 relative to 1, I see:
- One new line from ndp, showing 2610:98:8001:2::1 with draupadi's MAC:
2610:98:8001:2::1 00:0f:ea:f3:08:7e sk0 permanent R
- The Refs value changes from 0 to 1 on the 2610:98:8001:2::/112 line
in netstat output.
3 relative to 2:
- One new line from ndp, giving 2610:98:8001:2:: with palantir's MAC:
2610:98:8001:2:: 08:00:20:0d:88:a9 sk0 20s R R
There is clearly something I don't understand going on here, but I'm at
a loss to even guess what. If nobody has any ideas, I can just
approach this as a classic debugging problem, adding printfs and such
to trace processing until I figure out the relevant difference between
the two cases, but I find it hard to believe v6 is this badly broken
for everyone, leading me suspect it's me doing something stupid....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de