Префикс Вы пытаетесь использовать (:: ffff:0:0/96), для отображенных адресов IPv4. Это - механизм API, который позволяет программному обеспечению открыть единственный сокет и принять запросы IPv6 и IPv4. На моих поддерживающих IPv6 адресах узлов в OpenSSH vsftp и lighttpd зарегистрированы тот формат, например.
auth.log.0:Aug 20 07:01:18 my_host sshd[19411]: refused connect from ::ffff:60.190.31.214 (::ffff:60.190.31.214)
Вы не должны видеть этот префикс ни в каком живом трафике; это обнаружится на проводе как IPv4. Существует подобный префикс (:: ffff:0:0:0/96, отметьте дополнительное "0"), который был предложен для формы 6to4 перевод. Я не знаю, используется ли это. Я не видел никого ":: ffff" обращается в любом трафике действующей сети.
Как несколько других людей указали, IPv6 не является обратно совместимым надмножеством IPv4. Это - один из крупнейших людей жалоб, имеют об этом. Вы или выполненный это независимо двойным стеком или туннелирование, или Вы переводите его.
Я начал экспериментировать с IPv6 путем создания туннеля. После того как я был удобен я сложенный двойным образом мои общедоступные серверы. К счастью мой поставщик услуг хостинга использует собственный IPv6.
У меня была эта проблема в прошлом, и я исправил ее, изменив параметры запуска (notsc divider = 10) и настройки ntp:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-164.6.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=/dev/VolGroup00/LogVol00 hda=noprobe hdb=noprobe notsc divider=10
initrd /initrd-2.6.18-164.6.1.el5.img
title CentOS (2.6.18-164.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-164.el5.img
Пример ntp.conf:
tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org
driftfile /var/lib/ntp/drift
Источник:
Исправление дрейфа часов Linux на Hyper-V на Server 2008 R2
http://hardanswers.net/correct-clock-drift-in-centos-hyper-v
Во-первых, проверьте, обнаруживает ли Hyper-v службы интеграции. Единственный способ, которым я знаю, как использовать диспетчер виртуальных машин системного центра, но я предполагаю, что должен быть способ использовать mmc Hyper-v.
Кроме того, я видел, как это происходит, когда синхронизация часов отключена в конфигурации виртуальной машины. Почему часы идут быстрее, мне непонятно. Я приложил для справки снимок экрана с конфигурацией виртуальной машины.
Дрейф гостевых часов Hyper-V Linux под нагрузкой, к сожалению, довольно распространен (дрейф часов в несинхронизированных виртуальных машинах отчасти неизбежен). См. Часы Linux теряют 10 минут каждую неделю и Машина Hyper-V смещает время повсюду, даже с NTP для других сообщений, рассказывающих об этом. Приведенные мной неофициальные данные говорят следующее:
current_clocksource
равно hyperv_clocksource
- ваши часы будут дрейфовать после загрузки, и не будут исправлены , если вы не запустите одну из программ синхронизации ниже. Существует много сложной Windows-ориентированной и противоречивой информации, окружающей эту тему, и часто повторяющихся терминов, таких как «подключаемый источник времени», для понимания. ntpd
не может исправить дрейф суммы, который может произойти в гостевой системе Linux Hyper-V , и вам придется либо использовать обычную синхронизацию грубой силы ntpdate (плохо), либо службу ntp, такую как chrony
(лучше), чтобы исправить большие часы дрейфуют.