From: Andre Tomt <hidden> Date: 2003-06-16 19:50:48
[PS, I'm not subscribed to netdev, CC would be nice - is there any way
to get subscribed?]
Hi
I mailed you guys a little while ago on the "unable to use
SOMENETWORK::0000 as a nexthop gateway" bug in 2.4.21-pre/rc a while
ago. It is still present in 2.4.21, rendering the "first" /128 of a
arbitrary prefixlen unusable - :0000. This is especially bad with /127
tunnels, rendering :0000 and :0001 unusable). But! There is one more
oddity in 2.4.21, not present in 2.4.20..
The lower part of a /127 network is somehow, strangely routed to lo -
observe..
* ed-gw1 configuration
running 2.4.21-s2 (internal vendor tree with megaraid, md and some
netdrv updates, but pristine behaves the same)
* relevant routing info
2001:730:3::1:2a/127 via :: dev aorta proto kernel metric 256 mtu 1480 advmss 1420
2a is Aorta's end of the /127, 2b is our end.
from a host behind some routers:
root@kvass ~ # traceroute6 2001:730:3::1:2a
traceroute to 2001:730:3::1:2a (2001:730:3::1:2a) from 2001:730:f:3::2, 30 hops max, 16 byte packets
1 slask-fe-1.ws.pasop.tomt.net (2001:730:f:3::1) 2.46 ms 0.543 ms 0.455 ms
2 casablanca-fe-1.co.pasop.tomt.net (2001:730:f:7::1) 0.941 ms 0.622 ms 0.567 ms
3 ed-gw1-si0-0.sand-osl.skjellin.net (2001:730:f:ffff::) 6.56 ms 5.177 ms 5.087 ms
^-- hmmm. this was supposed to end at Aorta, not here.
root@kvass ~ # traceroute6 2001:730:3::1:2b
traceroute to 2001:730:3::1:2b (2001:730:3::1:2b) from 2001:730:f:3::2, 30 hops max, 16 byte packets
1 slask-fe-1.ws.pasop.tomt.net (2001:730:f:3::1) 0.797 ms 0.533 ms 0.455 ms
2 casablanca-fe-1.co.pasop.tomt.net (2001:730:f:7::1) 1.077 ms 0.623 ms 0.558 ms
3 skjellin-gw1.no.ipv6.aorta.net (2001:730:3::1:2b) 5.068 ms 18.271 ms 5.182 ms
^-- alright!
from ed-gw1:
root@ed-gw1 ~ # traceroute6 2001:730:3::1:2a
traceroute to 2001:730:3::1:2a (2001:730:3::1:2a) from ::1, 30 hops max, 16 byte packets
1 ip6-localhost (::1) 0.108 ms 0.099 ms 0.033 ms
^-- ehem.. this isn't Aorta, is it?
root@ed-gw1 ~ # traceroute6 2001:730:3::1:2b
traceroute to 2001:730:3::1:2b (2001:730:3::1:2b) from ::1, 30 hops max, 16 byte packets
1 skjellin-gw1.no.ipv6.aorta.net (2001:730:3::1:2b) 0.101 ms 0.089 ms 0.103 ms
^-- alright!
--
Mvh,
André Tomt
andre@skjellin.no
From: Andre Tomt <hidden> Date: 2003-06-18 12:54:24
On man, 2003-06-16 at 21:50, Andre Tomt wrote:
<snip>
The lower part of a /127 network is somehow, strangely routed to lo -
observe..
Replying to myself, with a finding.
I found a temporarily workaround for this problem. Adding the address
with a /128 prefixlen, and then adding a static route entry for the
other end - like this:
ip -6 addr add 2001:730:3::1:2b/128 dev aorta
ip -6 route add 2001:730:3::1:2a/128 dev aorta
.."fixes" the issue.
There is also one more impact of this bug, traffic that travels directly
between the two peers gets discarded, BGP and such breaks this way.
Added CC to usagi-users, and I'm now subscribed to netdev (and
usagi-users), no need for CC'ing me directly. :-)
--
Mvh,
André Tomt
In article [off-list ref] (at 16 Jun 2003 21:50:48 +0200), Andre Tomt [off-list ref] says:
I mailed you guys a little while ago on the "unable to use
SOMENETWORK::0000 as a nexthop gateway" bug in 2.4.21-pre/rc a while
ago. It is still present in 2.4.21, rendering the "first" /128 of a
arbitrary prefixlen unusable - :0000. This is especially bad with /127
tunnels, rendering :0000 and :0001 unusable). But! There is one more
:
This is NOT the bug but by the spec.
prefix:: is an anycast address, not a unicast;
you cannot use it like an unicast address.
Well...
Do you really need to assign global address on the point-to-point device?
If yes, you should not use /127 prefix; please use /64 instead.
Thank you.
--
Hideaki YOSHIFUJI @ USAGI Project [off-list ref]
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
From: Andre Tomt <hidden> Date: 2003-06-18 14:10:54
On ons, 2003-06-18 at 15:42, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [off-list ref] (at 16 Jun 2003 21:50:48 +0200), Andre Tomt [off-list ref] says:
quoted
I mailed you guys a little while ago on the "unable to use
SOMENETWORK::0000 as a nexthop gateway" bug in 2.4.21-pre/rc a while
ago. It is still present in 2.4.21, rendering the "first" /128 of a
arbitrary prefixlen unusable - :0000. This is especially bad with /127
tunnels, rendering :0000 and :0001 unusable). But! There is one more
:
This is NOT the bug but by the spec.
prefix:: is an anycast address, not a unicast;
you cannot use it like an unicast address.
Ok, that probably is correct. It works in 2.4.20, that does not mean
it's correct behavior though ;-)
Well...
Do you really need to assign global address on the point-to-point device?
Yes.
If yes, you should not use /127 prefix; please use /64 instead.
No one in their right mind assigns /64's for a linknetwork with two
peers. It's a pointopoint-link. All people I know use either /128
pointopoint or pointomultipoint semantics (BSD, KAME), or /127's as
Linux refuses to use the traditional pointopoint or peer parameter in
ifconfig and iproute for ipv6.
The /127 matches both 2a and 2b, why does it end up at localhost?
On ons, 2003-06-18 at 15:42, YOSHIFUJI Hideaki / 吉藤英明 wrote:
quoted
In article
[off-list ref] (at 16
Jun 2003 21:50:48 +0200), Andre Tomt [off-list ref] says:
quoted
quoted
I mailed you guys a little while ago on the "unable to use
SOMENETWORK::0000 as a nexthop gateway" bug in
2.4.21-pre/rc a while
quoted
quoted
ago. It is still present in 2.4.21, rendering the "first"
/128 of a
quoted
quoted
arbitrary prefixlen unusable - :0000. This is especially
bad with /127
quoted
quoted
tunnels, rendering :0000 and :0001 unusable). But! There
is one more
quoted
:
This is NOT the bug but by the spec.
prefix:: is an anycast address, not a unicast;
you cannot use it like an unicast address.
This kind of explains it, though I don't really like the way it was
forced upon us
without any big notification, then again I didn't read the changelog
so
it could be there ;)
Is there a toggle for turning this behaviour off ?
Notez bien that many people use :: and ::1 and ::2 etc as a unicast
address.
This will force them to stop using those ofcourse unless one simply
removes
those routes to the lo device, like I did :)
<SNIP>
quoted
If yes, you should not use /127 prefix; please use /64 instead.
No one in their right mind assigns /64's for a linknetwork with two
peers. It's a pointopoint-link. All people I know use either /128
pointopoint or pointomultipoint semantics (BSD, KAME), or /127's as
Linux refuses to use the traditional pointopoint or peer parameter
in
ifconfig and iproute for ipv6.
For SixXS we only use /127's on the IPng POP because of the age of the
POP.
The other POP's all use /64's for 'transitnetworks', the point to
point
tunnels.
Those are a lot of users. The endpoints currently on the IPng POP will
not be
migrated to use /64's all of a sudden though.
The /127 matches both 2a and 2b, why does it end up at localhost?
Routing, remove the route which goes over lo.
Greets,
Jeroen
From: Andre Tomt <hidden> Date: 2003-06-18 17:34:30
On ons, 2003-06-18 at 17:20, Jeroen Massar wrote:
Notez bien that many people use :: and ::1 and ::2 etc as a unicast
address.
I'm getting majorly confused now, things I've taken for granted with
IPv6, and used in IOS, *BSD, Windows and Linux for ages, suddenly stops
working with Linux, and is wrong (it seems).
Is there anything wrong about using $network::1/64 ? Other than not
being EUI64..
2001:730:f:1:: is invalid as a unicast address? (note it still works on
ptp-interfaces as long as you set nexthop to the dev, not the ip address
- but I expected that.)
/127's does not match two addresses (:2a :2b in this case)?
<snip>
quoted
The /127 matches both 2a and 2b, why does it end up at localhost?
Routing, remove the route which goes over lo.
There is no route that goes over lo, other than one for a different
prefix, wich is set to avoid loops on unmatched prefixes.
unreachable 2001:730:f::/48 dev lo metric 2048 error -101 mtu 16436 advmss 16376.
Because of routing? I don't understand. the /127 route matches both 2a
and 2b, and has no conflicting routes. It _should_ end up on the
aorta-dev as far as I can see.
2001:730:3::1:2a/127 via :: dev aorta proto kernel metric 256 mtu 1480 advmss 1420
(kernel autogenerated)
I tried removing it, and add a route without the via ::, still does not
work like before. non-routed traffic still goes to the bitbucket, but
routed traffic works as well as ever.
--
Mvh,
André Tomt
Notez bien that many people use :: and ::1 and ::2 etc as a unicast
address.
I'm getting majorly confused now, things I've taken for granted with
IPv6, and used in IOS, *BSD, Windows and Linux for ages,
suddenly stops working with Linux, and is wrong (it seems).
You have quite some short ages. IPv4 isn't even around for halve
an age yet... though it's coming close :)
Is there anything wrong about using $network::1/64 ? Other than not
being EUI64..
Absolutely not. Actually one can fill in the last 64 bits by himself.
Though there are some bits that should be untouched because of DAD and
some rules.
2001:730:f:1:: is invalid as a unicast address? (note it
still works on ptp-interfaces as long as you set nexthop to the dev,
not the
ip address - but I expected that.)
/127's does not match two addresses (:2a :2b in this case)?
<snip>
quoted
quoted
The /127 matches both 2a and 2b, why does it end up at localhost?
Routing, remove the route which goes over lo.
There is no route that goes over lo, other than one for a different
prefix, wich is set to avoid loops on unmatched prefixes.
unreachable 2001:730:f::/48 dev lo metric 2048 error -101
mtu 16436 advmss 16376.
Setting an unreachable for a prefix routed to your destination
is very good practice indeed.
Because of routing? I don't understand. the /127 route matches both 2a
and 2b, and has no conflicting routes. It _should_ end up on the
aorta-dev as far as I can see.
2001:730:3::1:2a/127 via :: dev aorta proto kernel metric
256 mtu 1480 advmss 1420
(kernel autogenerated)
Via :: on device aorta.. which explains it quite well.
Both IP's go to the device and over the wire to the other side.
But packets coming back get dropped as they have no destination on your
box.
Use tcpdump and you'll see :)
I tried removing it, and add a route without the via ::,
still does not
work like before. non-routed traffic still goes to the bitbucket, but
routed traffic works as well as ever.
As said we still use /127, and will keep on using /127's, at the IPng
POP.
My routing table entries for the tunnel currently look like:
3ffe:8114:1000::26 dev sixxs metric 1024 mtu 1280 advmss 1220
3ffe:8114:1000::26/127 via :: dev sixxs proto kernel metric 256 mtu
1280 advmss 1220
As you can see I've added a seperate route to the 'remote' side
(3ffe:8114:1000::26).
This way the packets go along quite cleanly.
Btw this is on 2.4.21-rc1 and on that system I had to remove the routes
to lo too.
Unicast my <peep> :)
Greets,
Jeroen
From: Pekka Savola <hidden> Date: 2003-06-19 05:37:23
On Thu, 19 Jun 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
In article [off-list ref] (at Wed, 18 Jun 2003 17:20:10 +0200), "Jeroen Massar" [off-list ref] says:
quoted
Is there a toggle for turning this behaviour off ?
Switch forwarding off.
Routers are REQUIRED to be enabled.
Does the same happen with any other prefix length (e.g. the prefix::/126)?
Otherwise, it's just a (un)fortunate bug.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings