Как предотвратить задержки, связанные с записями IPv6 AAAA?
В установке не-iSCSI нет ничего для остановки каждого хоста, имеющего только что единственный vSwitch и единственную группу портов - это несло бы оба не-iSCSI vmkernel трафик, а также гостевой трафик (включая VC, конечно), но это - просто вопросы проектирования не реализация один.
Я на самом деле подозреваю, что это, более вероятно, будет проблемой DNS, HA очень чувствителен к наличию 100%, надежных вперед И обратные записи DNS для примерно всего, особенно хосты и VC - я проверил бы, что они сначала, поскольку это - быстрая проверка, кроме этого могут Вы экранировать захватить Вашу установку для нас.
редактирование - чертовски, не видел Ваш собственный ответ - хорошее задание :)
The IPv6 transition technology called 6to4 is infamous for causing problems like this one. There are several factors at work. Individually they are harmless, but the combined effect is that end users can experience connection delays.
A list of enabling factors and thoughts on their mitigation is presented below.
Windows enables 6to4 by default
If your hosts are running a recent version of Windows (Vista or later), Windows will opportunistically enable 6to4 tunnelling when a publicly routable IPv4 address is available. Critically, this applies to both servers and clients.
To find out whether a system is using 6to4, run ipconfig and look for an IPv6 address that starts with the 6to4 prefix 2002:. It would look something like this.
C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222
- If your endpoints are connected to Active Directory, you can use Group Policy to disable transition protocols like 6to4 and Teredo. This is well-documented in KB929852. (Applying this to either your clients or servers would be sufficient, but if you're taking this step it probably makes sense to disable it everywhere, on both clients and servers.)
- If you only manage a few hosts, you can disable 6to4 on a case by case basis. This is much better than disabling IPv6 entirely.
netsh int ipv6 6to4 set state disabled - Use a different client operating system. For example, Mac OS X does not have 6to4 enabled by default.
Publicly routable IPv4 addresses are being used
6to4 only works on hosts that have publicly routable IPv4 addresses so this problem never affects hosts behind a NAT firewall.
- You can move clients and/or servers behind a NAT firewall and start using RFC1918 addressing. But in some cases, publicly routable addresses are actually preferred. Changing the addressing of an entire network might also be an unrealistic choice.
6to4 is not functioning correctly on the network
It is infamously difficult to troubleshoot 6to4 in anycast mode. It is so troublesome that there was a formal request to the IETF that 6to4 should be reclassified as historic. In the opinion of this author, 6to4 has been deprecated.
In brief, 6to4 works by encapsulating IPv6 packets into IPv4 packets using a protocol called 6in4 (IP protocol=41). The IPv4 packets are addressed to anycast address 192.88.99.1 in hopes that it will arrive at a working 6to4 relay somewhere on the internet. It might even be geographically nearby, if you're lucky.
In practice, some 6to4 relays are set up incorrectly, and a lot of networks don't even allow 6in4 traffic to cross the firewall. Typically this happens when a firewall allows all outbound traffic, but doesn’t explicitly allow IP protocol 41 packets to return through the firewall. (TODO note the relevant RFC for troubleshooting.) This failure ("inbound black hole") and many others are described in RFC 6343.
- Set up your firewall to loudly reject IP protocol 41 (with TCP resets) when sent from hosts internal to your network. This should result in a "fail fast" behaviour that makes more sense than non-deterministic connection delays. This has been demonstrated to work in limited test environments.
- Ask your ISP or first-hop transit provider to set up a working 6to4 relay. If this is done right, it will result in the best experience for end users. Any end user with a publicly routable IPv4 address would be able to participate in the IPv6 internet.
Dynamic DNS registration
In a typical Active Directory environment, every computer is permitted to register its own addresses with the DNS server. When a host is multihomed, it will register all of its addresses, even from a 6to4 tunnel.
Most internet services don't use dynamic DNS, so this problem is typically restricted to enterprise sites where the clients and servers are all "internal" to the same network.
- You may choose to disable dynamic DNS updates. Then if you don't put any AAAA resource records into the zone file, they will never be served. However, dynamic DNS is often desirable for internal DNS servers. (If you do this, make sure to also delete any AAAA records that might already be present.)
- Set up the DNS server to not provide answers for AAAA resource records. But don't do this, because it will really give you trouble when you want to start implementing IPv6. (Does anybody know of a free/open source DNS firewall?)
Client application does not fail gracefully
Microsoft's RDP client is one example of a client application that does not gracefully deal with IPv6 routing problems. Most web browsers are better at dealing with IPv6 edge cases like this one, so they don’t tend to show this behaviour.
- Try using a different client. Maybe you'll get lucky.
Я понимаю, что это не очень помогает в данной ситуации, но для разработчиков, которые сталкиваются с подобной дилеммой, есть метод реализации, известный как "Happy Eyeballs" (RFC 6555), который определяет метод одновременного подключения к ipv4 и ipv6 и выбирает тот, который подключается первым.
Это довольно интересный вопрос, и я должен признать, что никогда не видел такого поведения. Поработав немного, чтобы попытаться понять это лучше, я взял фрагмент запроса nslookup для одного из моих серверов RDS W2K8R2 с другого сервера W2K8R2, а также захватил фрагмент сеанса RDP на тот же сервер RDS с того же тестового сервера. . Nslookup не показал задержки при возврате записи IPv6, а nslookup показал, что мой тестовый сервер запрашивает запись IPv4 перед запросом записи IPv6. Разница во времени в захвате не показывает заметной задержки (которую я могу установить) ни в одном запросе.
EDIT
Теперь вы кое-что знаете.
Убедитесь, что вы захватываете трафик для адаптера Microsoft 6To4. , иначе вы не увидите IPv6:
Вот результат nslookup для моего сервера RDS. Обратите внимание на адреса IPv6:
Вот фрагмент моего захвата:
И, наконец, вот фрагмент из netstat, показывающий соединение:
Итак, ясно, как вы подтвердили, разрешение DNS не эта проблема. Проблема в том, что соединение RDP предпочитает IPv6 вместо IPv4 (что является значением по умолчанию для Windows - Windows предпочитает IPv6, а не IPv4), и поскольку IPv6 не работает должным образом, это вызывает задержку (как вы заявили) при откате с IPv6 на IPv4. Вы можете исправить это, настроив клиентов так, чтобы они предпочитали IPv4 IPv6, но я думаю, что это просто маскирует проблему. Лучшим решением было бы выяснить, почему IPv6 не работает, и исправить это. Я недостаточно знаю об IPv6, чтобы помочь, но предполагаю, что записи IPv6, возвращаемые DNS, являются «локальными».
Вот мое решение. По умолчанию Windows дает маршрутам IPv6 более высокий приоритет, чем маршрутам IPv4. Если вы измените политику префикса IPv6, вы можете изменить это поведение, чтобы использовать IPv4 вместо IPv6.
Чтобы убедиться, что все системы в моей сети настроены одинаково, я поместил следующие команды в файл. Сценарий bat запускается во время установки программного обеспечения после сборки или ремонта машины.
netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable
netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32
netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5
Чтобы объяснить, что это делает:
Первые 3 строки отключают встроенные туннельные интерфейсы,поскольку они избыточны для большинства сетей. Возможно, вы захотите не использовать эти 3 строки, если вы не предоставляете своим машинам собственные IPv6-адреса, в моем случае у меня есть сервер DHCPv6 и соответствующая инфраструктура, назначающая IPv6 для туннельного подключения
Второй блок команд удаляет все существующие IPv6 политики префиксов маршрутизации.
Третий блок затем воссоздает политику префикса IPv6, но использует другой набор приоритетов. Таким образом, префиксу, соответствующему IPv4, отдается предпочтение перед IPv6, и тогда машина захочет использовать IPv4, если приложение не указывает использование IPv6.
Это решение сохраняет функциональную возможность двойного стека, но предпочтение использовать IPv4 означает, что сайты с неполным, ненадежным или плохо работающим IPv6 будут избегать его использования, если это не будет указано программой в системе.
Я считаю, что использование в операционных системах IPv6 вместо IPv4 на самом деле препятствует их принятию. В переходный период будут моменты, когда хост думает, что у него есть возможность подключения по IPv6, но на самом деле у него нет полностью функционального соединения, что приводит к сбоям в работе программного обеспечения и большим задержкам. Многие люди, которых я знаю, полностью отключили IPv6 на своем маршрутизаторе в качестве обходного пути для интернет-провайдеров, развертывающих IPv6 неработоспособным образом до установления полного подключения, и эти люди просто забудут снова включить его, оставив их без IPv6, пока они снова не перенастроят свой маршрутизатор.