Такой прикольный NLB

В начале июля я начал миграцию электронной почты – за полмесяца почта должна была переехать с MS Exchange 2007 на 2010. В первых числах августа миграция была закончена, но затем возник неприятный нюанс – Outlook начал периодически просить пароль. Отключение Outlook Anywhere большинству пользователей помогло, что делать с остальными мы не знали. В журналах событий даже после включения супер-подробных журналов диагностики было тихо.

Все было настолько печально, что я обратился в техподдержку Microsoft…

Инфраструктура выглядит следующим образом:

  1. все серверы находятся в отдельном VLAN;
  2. есть три контроллера домена, обслуживающие этот сайт AD: один железный и два виртуальных;
  3. виртуальная инфраструктура – VMware vSphere;
  4. шлюзом по умолчанию для серверной сети и клиентов является Cisco;
  5. почта состоит из четырех серверов: два – Mailbox (DAG), еще два – HT/CAS. CAS-сервера объединены в CAS-Array и NLB-кластер. В паре серверов один – физический, другой – виртуальный;
  6. доступ в интернет осуществляется через 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-сервер, несмотря на то, что:

  1. TMG не является шлюзом;
  2. при обмене трафиком между IP=151 и IP=47 (NLB-IP) шлюз вообще не должен использоваться, так как это адреса одного логического сегмента.

А теперь интерес 🙂

Первый человек, с линками объяснивший, почему TMG пытался “маршрутизировать” пакеты, находящиеся в рамках одной сети, получит от меня электронную книгу Михаила Михеева про VMware vSphere (отсюда).

20 thoughts on “Такой прикольный NLB”

  1. странности вы какие-то рассказываете
    исходящий трафик с узла NLB идет по нативным MAC адресам и к NLB вообще никаким боком – обычное сетевое взаимодействие

    TMG у вас одиноко стоящая или в array с NLB?
    статические MAC’и на кошке какие и куда прописаны?
    на виртуальном свиче всякой экзотики вроде VLAN 4096 не наконфигурено ли?

    и нельзя ли картинку внятную сделать. по этой ничего понять невозможно

  2. 1) Исходящий трафик с NLB идет по нативным адресам в случае мультикаста. В случае уникаста будет синтетический MAC для каждого узла.
    Кстати, я про это и написал – для NLB-узла один пакет ушел с его MAC-а, а сервер получил два пакета (от NLB-узла и от TMG).
    На NLB-узлах по два сетевых адаптера, оба смотрят в серверный VLAN.
    2) TMG – одинокая виртуалка без NLB.
    3) Статический мак прописан для NLB-адреса Exchange, прописан как раз на роутере.
    4) Виртуальный свитч распределенный, держит несколько VLAN’ов. Других извратов не замечено.
    5) Картинку нарисую завтра.

  3. Судя по дампам и описанию – у вас мультикаст. Почему мы говорим о юникасте?

  4. Вот чего нет, того нет.
    Если это поможет, то в журнале 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

  5. Ошибка правило “InternalInternal”, я честно говоря с трудом могу представить ситуацию где нужно именно такое правило, у меня клиенты с iOS подключаются к OWA через TMG без подобных ухищрений.

    Т.к. TMG внутренним интерфейсом смотрит в ту же сеть где и NLB кластер распространяет multicast пакеты, то ничего удивительного что получая такой трафик TMG, при наличии выше озвученного правила, дублирует его, что просили то и получили 🙂

  6. multicast пакеты с точки зрения NLB – это пакеты идущие на MAC-адрес, у которого в старшем октете младший бит в 1 выставлен
    TMG на такой трафик плевать хотел – у него на интерфейсах такого адреса нет, ничего “дублировать” он не будет
    по крайней мере в нормальных условиях
    какой-нибудь нюанс возможен с arp-proxy, используемым клиентским vpn – если включен
    но вообще, без дампов, по предоставленной фотографии гадать не возьмусь

  7. а у нас другая грабля с NLB multicast
    http://forum.dlink.ru/viewtopic.php?f=2&t=144890&hilit=NLB
    с цисками вроде как таких проблем нет. Терзаем D-Link.
    К слову об Outlook Anywhere. Как то бы научиться отключать его для конкретных людей (чтобы автоконфигурация не трогала оутлуки ненужных людей)

  8. сам и отвечу на свой каммент
    Отключение Outlook Anywhere для одного пользователя:
    Get-Mailbox –Identity | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True

    Отключение для всех пользователей:
    Get-Mailbox –ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True

  9. Такой прикольный D-Link…
    на нашу проблему с NLB он ответил следующее
    Ответ от разработчика:
    Поскольку мы используем ACL для перенаправления NLB пакетов с приходящего на исходящий порт, входящий порт не должен перекрывать исходящий порт. Это наше ограничение.

  10. Ввиду сложности дальнейших изысканий ответ BSV считаю ближе к моему мнению.
    Книга уходит ему.
    Оставайтесь с нами, новый конкурс будет на следующей неделе. Приз – еще одна электронная книга Михаила.

  11. to Андрей.
    Видимо то, что это фича, а не баг )
    sh access_profile действительно показывает первое правило с названием “NLB!”, которое создается автоматом после добавления статической ARP с мультикаст MAC. ни заглянуть в правило, ни удалить его низя (

  12. Вообще говоря от NLB нужно держаться подальше и использовать или Hardware Load Balancer или виртуальных на базе линукса полно.

    Микрософт сам об этом говорит.

Leave a Reply

Your email address will not be published. Required fields are marked *