From: Etaoin Shrdlu <shrdlu@unlimitedmail.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] IPv6 troubles
Date: Thu, 19 Jul 2007 18:09:47 +0200 [thread overview]
Message-ID: <200707191809.47936.shrdlu@unlimitedmail.org> (raw)
In-Reply-To: <200707191602.45433.mike@gaima.co.uk>
On Thursday 19 July 2007 17:02, Mike Williams wrote:
> I hadn't configured the "subnet router anycast address", but I can
> still ping it. Again makes no difference if it's specified or not.
Ok, then probably the linux implementation recognizes it anyway. But it
seems this is not the issue here.
> interface bond2
> {
> AdvSendAdvert on;
> prefix dead:beef:2:136::/64
> {
> AdvOnLink on;
> AdvAutonomous on;
> };
> };
Looks OK.
> As above, no difference. I've even tried using the link-local address
> of the upstream router for the default route out of the firewall.
> # ip -6 route show
> dead:beef:2::/64 dev bond0 metric 1 expires 21253232sec mtu 1500
> advmss 1440 hoplimit 4294967295
> dead:beef:2::/64 dev bond0 metric 256 expires 21254724sec mtu 1500
> advmss 1440 hoplimit 4294967295
> dead:beef:2:131::/64 dev bond1 metric 256 expires 21256488sec mtu
> 1500 advmss 1440 hoplimit 4294967295
> dead:beef:2:136::/64 dev bond2 metric 256 expires 21252676sec mtu
> 1500 advmss 1440 hoplimit 4294967295
> dead:beef:2:137::/64 dev bond4 metric 256 expires 21255086sec mtu
> 1500 advmss 1440 hoplimit 4294967295
> default via fe80::214:f600:b67e:b4db dev bond0 metric 1 expires
> 21334235sec mtu 1500 advmss 1440 hoplimit 4294967295
Ok, so fe80::214:f600:b67e:b4db *is* your provider's router interface.
You should also have, for each interface, a route to fe80::/64 and one to
ff00::/8, eg something like
fe80::/64 dev bond1 ...
ff00::/8 dev bond1 ...
for each interface.
And at each internal host you should have a route to
dead:beef:2:xxx::/64, one to fe80::/64, one to ff00::/8, and a default
route pointing to the link-local address of the router interface on that
link.
> firewall # ip -6 neigh
> fe80::214:f600:b67e:b4db dev bond0 lladdr 00:14:f6:7e:b4:db router
> STALE
> dead:beef:2:136:204:23ff:fed7:e86a dev bond2 lladdr 00:04:23:d7:e8:6a
> REACHABLE
> fe80::204:23ff:fed7:e86a dev bond2 lladdr 00:04:23:d7:e8:6a STALE
>
> host # ip -6 neigh
> dead:beef:2:136::11 dev bond0 lladdr 00:04:23:d7:f3:32 router
> REACHABLE
> fe80::204:23ff:fed7:f332 dev bond0 lladdr 00:04:23:d7:f3:32
> router REACHABLE
I assume you took this immediately after pinging the global firewall
address (manually assigned, I supposed), otherwise the entry
dead:beef:2:136::11 would have no reason to be there.
Everything seems ok so far.
The thing left to understand is why your provider's router, when it
receives a packet coming from an internal host of yours, tries to do a
neighbor discovery (similar to ARP) on that address.
I'd make sure that everything is configured correctly at the far side of
the link. If you don't do dynamic routing with them (and if you are
single-homed you probably don't), they should have a static route
pointing to dead:beef:2::/48 via your firewall's bond0 link-local
address.
Their end of the link should definitely have a /64 (or longer) address,
as should your end; the behaviour we are seeing /could/ mean that they
have configured their end with a /48 address from the same pool, thus
erroneously thinking that all the addresses belonging to your /48 block
(ie, everything starting with dead:beef:2) belong to the link between
you and them.
If neither of you needs said link to be pingable or otherwise reachable,
you can also (like I do) avoid assigning global addresses to the link
altogether and only use link-local addresses, thereby saving global
addresses (not a concern with ipv6, but anyway...).
--
gentoo-user@gentoo.org mailing list
next prev parent reply other threads:[~2007-07-19 16:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 11:45 [gentoo-user] IPv6 troubles Mike Williams
2007-07-19 12:56 ` Etaoin Shrdlu
2007-07-19 15:02 ` Mike Williams
2007-07-19 16:09 ` Etaoin Shrdlu [this message]
2007-07-19 15:12 ` Etaoin Shrdlu
2007-07-19 16:00 ` Mike Williams
2007-07-19 16:51 ` Etaoin Shrdlu
2007-07-19 18:17 ` Mike Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200707191809.47936.shrdlu@unlimitedmail.org \
--to=shrdlu@unlimitedmail.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox