| 1 |
On Thursday 19 July 2007 17:02, Mike Williams wrote: |
| 2 |
|
| 3 |
> I hadn't configured the "subnet router anycast address", but I can |
| 4 |
> still ping it. Again makes no difference if it's specified or not. |
| 5 |
|
| 6 |
Ok, then probably the linux implementation recognizes it anyway. But it |
| 7 |
seems this is not the issue here. |
| 8 |
|
| 9 |
> interface bond2 |
| 10 |
> { |
| 11 |
> AdvSendAdvert on; |
| 12 |
> prefix dead:beef:2:136::/64 |
| 13 |
> { |
| 14 |
> AdvOnLink on; |
| 15 |
> AdvAutonomous on; |
| 16 |
> }; |
| 17 |
> }; |
| 18 |
|
| 19 |
Looks OK. |
| 20 |
|
| 21 |
> As above, no difference. I've even tried using the link-local address |
| 22 |
> of the upstream router for the default route out of the firewall. |
| 23 |
|
| 24 |
> # ip -6 route show |
| 25 |
> dead:beef:2::/64 dev bond0 metric 1 expires 21253232sec mtu 1500 |
| 26 |
> advmss 1440 hoplimit 4294967295 |
| 27 |
|
| 28 |
> dead:beef:2::/64 dev bond0 metric 256 expires 21254724sec mtu 1500 |
| 29 |
> advmss 1440 hoplimit 4294967295 |
| 30 |
|
| 31 |
> dead:beef:2:131::/64 dev bond1 metric 256 expires 21256488sec mtu |
| 32 |
> 1500 advmss 1440 hoplimit 4294967295 |
| 33 |
|
| 34 |
> dead:beef:2:136::/64 dev bond2 metric 256 expires 21252676sec mtu |
| 35 |
> 1500 advmss 1440 hoplimit 4294967295 |
| 36 |
|
| 37 |
> dead:beef:2:137::/64 dev bond4 metric 256 expires 21255086sec mtu |
| 38 |
> 1500 advmss 1440 hoplimit 4294967295 |
| 39 |
|
| 40 |
> default via fe80::214:f600:b67e:b4db dev bond0 metric 1 expires |
| 41 |
> 21334235sec mtu 1500 advmss 1440 hoplimit 4294967295 |
| 42 |
|
| 43 |
Ok, so fe80::214:f600:b67e:b4db *is* your provider's router interface. |
| 44 |
|
| 45 |
You should also have, for each interface, a route to fe80::/64 and one to |
| 46 |
ff00::/8, eg something like |
| 47 |
|
| 48 |
fe80::/64 dev bond1 ... |
| 49 |
ff00::/8 dev bond1 ... |
| 50 |
|
| 51 |
for each interface. |
| 52 |
|
| 53 |
And at each internal host you should have a route to |
| 54 |
dead:beef:2:xxx::/64, one to fe80::/64, one to ff00::/8, and a default |
| 55 |
route pointing to the link-local address of the router interface on that |
| 56 |
link. |
| 57 |
|
| 58 |
> firewall # ip -6 neigh |
| 59 |
> fe80::214:f600:b67e:b4db dev bond0 lladdr 00:14:f6:7e:b4:db router |
| 60 |
> STALE |
| 61 |
> dead:beef:2:136:204:23ff:fed7:e86a dev bond2 lladdr 00:04:23:d7:e8:6a |
| 62 |
> REACHABLE |
| 63 |
> fe80::204:23ff:fed7:e86a dev bond2 lladdr 00:04:23:d7:e8:6a STALE |
| 64 |
> |
| 65 |
> host # ip -6 neigh |
| 66 |
> dead:beef:2:136::11 dev bond0 lladdr 00:04:23:d7:f3:32 router |
| 67 |
> REACHABLE |
| 68 |
> fe80::204:23ff:fed7:f332 dev bond0 lladdr 00:04:23:d7:f3:32 |
| 69 |
> router REACHABLE |
| 70 |
|
| 71 |
I assume you took this immediately after pinging the global firewall |
| 72 |
address (manually assigned, I supposed), otherwise the entry |
| 73 |
dead:beef:2:136::11 would have no reason to be there. |
| 74 |
|
| 75 |
Everything seems ok so far. |
| 76 |
The thing left to understand is why your provider's router, when it |
| 77 |
receives a packet coming from an internal host of yours, tries to do a |
| 78 |
neighbor discovery (similar to ARP) on that address. |
| 79 |
|
| 80 |
I'd make sure that everything is configured correctly at the far side of |
| 81 |
the link. If you don't do dynamic routing with them (and if you are |
| 82 |
single-homed you probably don't), they should have a static route |
| 83 |
pointing to dead:beef:2::/48 via your firewall's bond0 link-local |
| 84 |
address. |
| 85 |
|
| 86 |
Their end of the link should definitely have a /64 (or longer) address, |
| 87 |
as should your end; the behaviour we are seeing /could/ mean that they |
| 88 |
have configured their end with a /48 address from the same pool, thus |
| 89 |
erroneously thinking that all the addresses belonging to your /48 block |
| 90 |
(ie, everything starting with dead:beef:2) belong to the link between |
| 91 |
you and them. |
| 92 |
|
| 93 |
If neither of you needs said link to be pingable or otherwise reachable, |
| 94 |
you can also (like I do) avoid assigning global addresses to the link |
| 95 |
altogether and only use link-local addresses, thereby saving global |
| 96 |
addresses (not a concern with ipv6, but anyway...). |
| 97 |
-- |
| 98 |
gentoo-user@g.o mailing list |
Archives