В начале июля я начал миграцию электронной почты – за полмесяца почта должна была переехать с MS Exchange 2007 на 2010. В первых числах августа миграция была закончена, но затем возник неприятный нюанс – Outlook начал периодически просить пароль. Отключение Outlook Anywhere большинству пользователей помогло, что делать с остальными мы не знали. В журналах событий даже после включения супер-подробных журналов диагностики было тихо.
Все было настолько печально, что я обратился в техподдержку Microsoft…
Инфраструктура выглядит следующим образом:
- все серверы находятся в отдельном VLAN;
- есть три контроллера домена, обслуживающие этот сайт AD: один железный и два виртуальных;
- виртуальная инфраструктура – VMware vSphere;
- шлюзом по умолчанию для серверной сети и клиентов является Cisco;
- почта состоит из четырех серверов: два – Mailbox (DAG), еще два – HT/CAS. CAS-сервера объединены в CAS-Array и NLB-кластер. В паре серверов один – физический, другой – виртуальный;
- доступ в интернет осуществляется через MS TMG (работающий в качестве прокси), находящийся в серверном VLAN.
Настроенный мониторинг портов показал очень странную вещь: соединения на отдельные ноды NLB-кластера проходили на ура, а вот NLB-адрес (HTTP, SMTP, POP3) несколько раз в час выдавал таймаут >2 секунд. Оставил в NLB только один узел – та же картина.
Для начала я решил разобраться, как же работает этот странный NLB. Тут же на помощь мне пришло видео с ExchangeRus. Очень рекомендую для ознакомления. Кстати, там же объясняется почему на ряде маршрутизаторов необходимо вручную создавать ARP-запись под Multicast NLB-кластер.
К этому времени тут мы уже обсудили, что в средах VMware лучше использовать Multicast.
С момента возникновения проблемы прошел почти месяц, гугл не помогал, проблема казалась нерешимой. И тут Mr.Nobody посоветовал посмотреть внутрь TCP-сессий с помощью сниффера.
В качестве тестовой станции был взят физический сервер, не являющийся членом домена. На этом сервере установлено ПО мониторинга Dude. Я скачал и установил на него Microsoft Network Monitor 3.4.
В качестве теста я создавал соединения на 25 порт (SMTP-сессию). После этого в MS Network Monitor сравнивал нормальную сессию и зависшую.
Ясности мне это не дало – в зависшей сессии после “TCP-рукопожатия” NLB-сервер отправлял пакет с флагом Reset. Почему/зачем – не ясно.
Посоветовавшись с Diz, установил вместо него Wireshark 1.6.1 и тут такое увидел:
Слева – тестовый сервер, справа – активный узел NLB.
Выделенный курсором пакет идет от NLB-узла (IP=47/MAC=00:50:16:8B:00:25) до тестового сервера (IP=151/MAC=00:16:35:C4:25:96).
А слева мы видим, что сервер получает этот пакет, но MAC-адрес источника какой-то “левый”. Точнее, сервер получает два пакета от узла NLB (№№29193 и 29195). В строке №29193 – нормальный пакет с нормальными MAC’ами. Та же ерунда с пакетами от IP=151 до IP=47. IP=47 – виртуальный адрес NLB.
“Левый” MAC принадлежит TMG-серверу, который не является шлюзом ни для кого.
Для осмысления мы нарисовали картинку:
MAC1 – сервер, MAC2 – NLB, MAC3 – узел NLB, MAC4 – TMG-сервер.
В начале августа для работы почтовых клиентов Apple мы сделали на TMG правило Internal<->Internal.
Видимо, с тех пор, трафик до NLB “дублировался” через TMG-сервер, несмотря на то, что:
- TMG не является шлюзом;
- при обмене трафиком между IP=151 и IP=47 (NLB-IP) шлюз вообще не должен использоваться, так как это адреса одного логического сегмента.
А теперь интерес 🙂
Первый человек, с линками объяснивший, почему TMG пытался “маршрутизировать” пакеты, находящиеся в рамках одной сети, получит от меня электронную книгу Михаила Михеева про VMware vSphere (отсюда).
странности вы какие-то рассказываете
исходящий трафик с узла NLB идет по нативным MAC адресам и к NLB вообще никаким боком – обычное сетевое взаимодействие
TMG у вас одиноко стоящая или в array с NLB?
статические MAC’и на кошке какие и куда прописаны?
на виртуальном свиче всякой экзотики вроде VLAN 4096 не наконфигурено ли?
и нельзя ли картинку внятную сделать. по этой ничего понять невозможно
1) Исходящий трафик с NLB идет по нативным адресам в случае мультикаста. В случае уникаста будет синтетический MAC для каждого узла.
Кстати, я про это и написал – для NLB-узла один пакет ушел с его MAC-а, а сервер получил два пакета (от NLB-узла и от TMG).
На NLB-узлах по два сетевых адаптера, оба смотрят в серверный VLAN.
2) TMG – одинокая виртуалка без NLB.
3) Статический мак прописан для NLB-адреса Exchange, прописан как раз на роутере.
4) Виртуальный свитч распределенный, держит несколько VLAN’ов. Других извратов не замечено.
5) Картинку нарисую завтра.
Судя по дампам и описанию – у вас мультикаст. Почему мы говорим о юникасте?
Решил уточнить…
понимания для нужен еще дамп с TMG и значения Seq\Ack всех пакетов
Вот чего нет, того нет.
Если это поможет, то в журнале TMG часто светились две ошибки:
– A non-SYN packet was dropped because it was sent by a source that does not have an established connection with the Forefront TMG computer
– A TCP packet was rejected because it has an invalid sequence number or an invalid acknowledgement number
Ошибка правило “InternalInternal”, я честно говоря с трудом могу представить ситуацию где нужно именно такое правило, у меня клиенты с iOS подключаются к OWA через TMG без подобных ухищрений.
Т.к. TMG внутренним интерфейсом смотрит в ту же сеть где и NLB кластер распространяет multicast пакеты, то ничего удивительного что получая такой трафик TMG, при наличии выше озвученного правила, дублирует его, что просили то и получили 🙂
как я понимаю, приз уходит Сергею =)
multicast пакеты с точки зрения NLB – это пакеты идущие на MAC-адрес, у которого в старшем октете младший бит в 1 выставлен
TMG на такой трафик плевать хотел – у него на интерфейсах такого адреса нет, ничего “дублировать” он не будет
по крайней мере в нормальных условиях
какой-нибудь нюанс возможен с arp-proxy, используемым клиентским vpn – если включен
но вообще, без дампов, по предоставленной фотографии гадать не возьмусь
Выложил примерную схему сети.
а у нас другая грабля с NLB multicast
http://forum.dlink.ru/viewtopic.php?f=2&t=144890&hilit=NLB
с цисками вроде как таких проблем нет. Терзаем D-Link.
К слову об Outlook Anywhere. Как то бы научиться отключать его для конкретных людей (чтобы автоконфигурация не трогала оутлуки ненужных людей)
сам и отвечу на свой каммент
Отключение Outlook Anywhere для одного пользователя:
Get-Mailbox –Identity | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True
Отключение для всех пользователей:
Get-Mailbox –ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True
Мог бы спросить 🙂
Такой прикольный D-Link…
на нашу проблему с NLB он ответил следующее
Ответ от разработчика:
Поскольку мы используем ACL для перенаправления NLB пакетов с приходящего на исходящий порт, входящий порт не должен перекрывать исходящий порт. Это наше ограничение.
Ввиду сложности дальнейших изысканий ответ BSV считаю ближе к моему мнению.
Книга уходит ему.
Оставайтесь с нами, новый конкурс будет на следующей неделе. Приз – еще одна электронная книга Михаила.
2Alexander: У меня какой-то другой русский используется :))
Они что этим хотели сказать?
Андрей, я так и не понял – выключение странного правила помогло?
Именно так.
to Андрей.
Видимо то, что это фича, а не баг )
sh access_profile действительно показывает первое правило с названием “NLB!”, которое создается автоматом после добавления статической ARP с мультикаст MAC. ни заглянуть в правило, ни удалить его низя (
Вообще говоря от NLB нужно держаться подальше и использовать или Hardware Load Balancer или виртуальных на базе линукса полно.
Микрософт сам об этом говорит.