[MidnightStar]

Netzwerkconfig ist exakt wie von OVH bei der Installation voreingestellt. Autoconfig ist definitiv aus (bestätigt durch die sysctl-Ausgabe und weil Autoconfig-verursachte Probleme erfahrungsgemäß anders aussehen).

Gibt es hier irgendwen mit mehr als einem Server am gleichen Gateway, der dieses Problem entweder bestätigen oder widerlegen kann?

@Stefan: irgendein Hinweis zur tcpdump-Ausgabe?

[pbm]

hab ipv6 noch nich so ganz durchgeblickt , aber
hast du mal das system durchgekuckt , ob noch irgenwo was mit ipv6 autoconf aktiviert is ?

* ff00::/8 dev eth0 metric 256 (ff02::66.2029)<- kommt doch von autoconfig oder, da könnt der fehler liegen (router cache nicht aktuell, kein traffic -> route deaktiviert)

entweder route direkt setzen , oder autoconf ausmachen müsste dann
gehen

/etc/sysctl.conf

# Disable IPv6 autoconf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0


*http://de.wikipedia.org/wiki/Neighbo...overy_Protocol

[MidnightStar]

Können sich auch gegenseitig anpingen per IPv6, wobei ich glaube das es nicht im gleichen Rack ist.

Verwenden die Server das gleiche Gateway oder ist das unterschiedlich?

[stefanos]

Dann wäre es nett, wenn OVH die Server auch entsprechend ausliefern würde.

Hab 2x 2G Server und dort wurde Debian Linux 7.1 mit /128 vorkonfiguriert. Dagegen der 16G ist mit /64 vorkonfiguriert. Wobei im OVH Manager immer noch Debian 7.0 steht als Option. Können sich auch gegenseitig anpingen per IPv6, wobei ich glaube das es nicht im gleichen Rack ist. Traceroute6 zeigt beim ersten Punkt allerdings ebenfalls Sterne an.

[MidnightStar]

root@ks3357658:~# ip -6 route
2001:41d0:a:16d0::1 dev eth0 proto kernel metric 256
2001:41d0:a:16ff:ff:ff:ff:ff dev eth0 metric 1024
fe80::/64 dev eth0 proto kernel metric 256
ff00::/8 dev eth0 metric 256
default via 2001:41d0:a:16ff:ff:ff:ff:ff dev eth0 metric 1024

[pbm]

mach doch mal bitte nen
ip -6 route

wenns bei slackware sowas gibt
vieleicht erkennt man dort etwas

[MidnightStar]

Kann es sein, dass eine IPv6-Verbindung zwischen zwei Servern nicht möglich ist, wenn diese das gleiche Gateway verwenden? Wenn ich IP-Adressen "rate", dann finde ich sehr wohl erreichbare Hosts - allerdings nur, wenn die Adresse eine andere ist als 2001:41d0:a:16xxx. Ist das ein Fehler in meinem Netzwerk-Setup oder stimmt da bei OVH irgendwas mit dem Routing nicht?

[tester]

ich würd mal schätzen es sind die switches im rack wo deine 2Gs angeschlossen sind...
verwende ipv6 derzeit noch nicht produktiv... obwohls funktioniert...

[MidnightStar]

Ein traceroute6 zw. den beiden GRA-Servern liefert nur Sternchen, traceroute6 zu www.ovh.de geht:

traceroute to 2001:41d0:1:1b00:87:98:247:34 (2001:41d0:1:1b00:87:98:247:34) from 2001:41d0:a:16d0::1, 30 hops max, 24 byte packets
1 2001:41d0:a:16ff:ff:ff:ff:fe (2001:41d0:a:16ff:ff:ff:ff:fe) 0.461 ms * *
2 2001:41d0::1e7 (2001:41d0::1e7) 1.113 ms 1.176 ms 1.192 ms
3 gsw-g1-a9.fr.eu (2001:41d0::f02) 5.075 ms 5.013 ms 5.022 ms
4 p19-7-6k.fr.eu (2001:41d0::5c2) 4.921 ms 4.832 ms *
5 www.ovh.de (2001:41d0:1:1b00:87:98:247:34) 4.649 ms * 4.631 ms

[tester]

Interessehalber
tracert via ipv6 ?
zwischen den servern und evtl. auch zu ovh.de [2001:41d0:1:1b00:87:98:247:34]

[MidnightStar]

Bitte nur wie angegeben /128 verwenden.

Dann wäre es nett, wenn OVH die Server auch entsprechend ausliefern würde. Ich habe das jetzt angepasst, am beschriebenen Problem hat sich dadurch aber erst mal nichts geändert.

Ausgabe von "tcpdump -v -s0 -i eth0 ip6" auf dem pingenden System:

22:32:02.764174 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 80) fe80::12bd:18ff:fee5:ff80.2029 > ff02::66.2029: [udp sum ok] UDP, length 72
22:32:05.021110 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 1
22:32:05.116350 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 14) fe80::1ee6:c7ff:fe52:740.2029 > ff02::66.2029: [udp sum ok] UDP, length 6
22:32:06.021016 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 2
22:32:07.020975 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 3
22:32:08.020962 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 4
22:32:09.020957 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 5
22:32:10.020961 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 6
22:32:10.030948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::222:4dff:fe7c:be95 > 2001:41d0:a:16ff:ff:ff:ff:ff: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:41d0:a:16ff:ff:ff:ff:ff
          source link-address option (1), length 8 (1): 00:22:4d:7c:be:95
22:32:10.031921 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 24) 2001:41d0:a:16ff:ff:ff:ff:ff > fe80::222:4dff:fe7c:be95: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is 2001:41d0:a:16ff:ff:ff:ff:ff, Flags [router, solicited]
22:32:11.020975 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 7
22:32:11.804408 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 80) fe80::1ee6:c7ff:fe52:740.2029 > ff02::66.2029: [udp sum ok] UDP, length 72
22:32:12.020960 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 8
22:32:13.020960 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 9
22:32:14.020955 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:41d0:a:169e::1 > 2001:41d0:a:16d0::1: [icmp6 sum ok] ICMP6, echo request, seq 10

...und auf dem Zielsystem:

22:31:57.120244 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 80) fe80::1ee6:c7ff:fe52:740.2029 > ff02::66.2029: [udp sum ok] UDP, length 72
22:32:02.763684 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 80) fe80::12bd:18ff:fee5:ff80.2029 > ff02::66.2029: [udp sum ok] UDP, length 72
22:32:05.116024 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 14) fe80::1ee6:c7ff:fe52:740.2029 > ff02::66.2029: [udp sum ok] UDP, length 6
22:32:11.804097 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 80) fe80::1ee6:c7ff:fe52:740.2029 > ff02::66.2029: [udp sum ok] UDP, length 72
22:32:17.799801 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 80) fe80::12bd:18ff:fee5:ff80.2029 > ff02::66.2029: [udp sum ok] UDP, length 72

Gesamtresultat:

--- 2001:41d0:a:16d0::1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss

Firewallregeln waren zum Testzeitpunkt keine aktiv.

Ich habe noch einen "alten" KS2G mit identischer Installation in RBX, und IPv6-Verbindungen von und nach dort mit o.g. Servern funktionieren problemlos.

[Stefan]

Bitte nur wie angegeben /128 verwenden. Wie genau sieht denn der tcpdump-output auf IPv6 aus, wenn du dabei den Server anpingst ?

[MidnightStar]

Ich habe 3x KS2G in GRA mit Slackware 14 und unveränderter Netzwerk-Config aus der OVH-Installation (obwohl im Manager mit /128 angegeben, wurden alle drei Server von OVH mit /64 konfiguriert).

IPv6-Verbindungen von und nach außen (RBX, Rest der Welt) funktionieren wunderbar. Was nicht funktioniert sind IPv6-Verbindungen zwischen diesen drei Servern. "tcpdump" hat mir keine Hinweise geliefert. IPv4 funktioniert. Was mache ich falsch?