none
TMG 2010 и NLB: странная работа unicast-режима RRS feed

  • Вопрос

  • Доброе время суток!

    Имеется два сервера (Windows Server 2008R2 EE + TMG 2010 with SP1 + rollup'ы 4). В каждом - 3 сетевухи: Internal, External и Intra-Array. Настраиваю на Internal и External Unicast NLB средствами TMG: все вроде хорошо, все поднимается, в логах никаких ошибок.

    Однако работает все это как-то странно: где-то у половины пользователей не работает интернет. Стал разбираться подробнее и обнаружил, что unicast работает весьма оригинальным образом. Пытаемся зайти по ssh на одно из внешних устройств (CISCO 800), получаем connection timeout. Смотрим логи на том узле, через который попадаем в inet (npr, node1) и видим, что connection aborted по причине отсутствия SYN/ASK. Смотрим на другой узел и видим, что на него приходит пакет, предназначенный для предыдущего узла и что он отвергается как NOT_SYN. То, что входящий пакет попадает сразу на два узла - это понятно, ибо unicast. То, что на node2 пакет отвергается, тоже понятно, поскольку мы попадали на хост через node1. Вопрос в том, почему пакет отвергается также и на node1? Самое интересное, что такое явление носит нерегулярный характер, т.е. примерно в половине попыток коннект по ssh успешно устанавливается. Господа, кто сталкивался, подскажите плз, почему может отбрасываться пакет, в какую сторону копать?

    Заранее благодарен.


    • Изменено Mickwel 12 сентября 2011 г. 11:29
    12 сентября 2011 г. 10:47

Все ответы

  • Это говорит, на мой взгляд, о том, что у вас NLB вообще не работает.

    По идее его надо было протестировать до установки TMG, т.к. подводных камней там много.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    14 сентября 2011 г. 6:04
    Модератор
  • Это говорит, на мой взгляд, о том, что у вас NLB вообще не работает.


    Странно, я почему-то подумал точно также и обратился на форум в попытке получить что-нибудь более конкретное :)

    Появились некоторые дополнительные подробности. Путем просмотра трафика в разных точках схемы удалось выяснить следующее: когда пользователь из внутренней сети пытается установить TCP-соединение с каким-либо внешним сервером, исходящий пакет уходит с одного из узлов кластера, например, с SRV2, с внешнего DIP IP_EXT_2. Ответный ASK попадает сразу на оба узла кластера (поскольку идет на специальный кластерный MAC, ибо unicast). А вот дальше узлы начинают интересную игру под названием "поймай пакет первым". Варианты:

    1. Первым этот пакет ловит узел SRV2 c IP_EXT_2, т.е. тот, который послал SYN. В этом случае все работает, соединение устанавливается, однако на SRV1 появляется странный пакет, адресованный на DIP IP_EXT_1, но на совершенно другой порт, причем пакет этот узлом отбрасывается. Пока не понял, откуда он берется. Подозреваю, что это нюансы NLB'шной балансировки.

    2. Первым пакет ловит SRV1, у которого DIP IP_EXT_1. Естественно, он не может принять пакет, адресованный на IP_EXT_2 и отбрасывает его, после чего SRV2 тоже отбрасывает свой ПРАВИЛЬНЫЙ, адресованный именно ему пакет. Почему - тоже не ясно. Видимо, это опять таки нюансы NLB'шной балансировки.

    В то же время, если пакеты входят на VIP кластера IP_EXT_0 (например, на опубликованный почтовик), то все прекрасно работает и они вполне корректно раскидываются по узлам. Собственно, это и опровергает мнение уважаемого Сазонова Ильи, что де "у вас NLB вообще не работает".

    В связи этим вопрос: поведение, описанное в пп. 1 и 2, нормально для unicast NLB или нет? Если нет, то подскажите плз, куда можно копать. Может, есть какие средства для тонкой диагностики?

     

    По идее его надо было протестировать до установки TMG, т.к. подводных камней там много.


    А вот с этого места, если можно, поконкретнее. Что это за камни и где о них можно почитать?

     

    Заранее спасибо!

    14 сентября 2011 г. 10:15
  • Разбирательство продолжается, привлечен провайдер, дошли до ARP broadcast и ответов на них. Ситуация получается весьма интересная. Когда пользователь идет из внутренней сети, c SRV2 пакет уходит с IP_EXT_2, но MAC у него имеет вид 02-03-1-2-3-4, т.е. это - bogus MAC, который зарегистрирован на порту свича, к которому подключен SRV2. Чтобы послать ответный пакет, внешний сервер, отсылает ARP broadcast, который проходит через роутер и в котором просит сказать MAC для IP_EXT_2. Смотрим ответ на этот запрос (ARP_RARP) и видим, что возвращается 02-bf-1-2-3-4, т.е. MAC кластера. Это понятно, поскольку:

    1. Этот MAC жестко прописан на сетевухах узлов (ибо unicast).

    2. Так работают все роутеры, они берут MAC из секции RARP, а не ETHERNET, и это правильно, потому что иначе было бы никак не получить MAC для VIP кластера.

    Отправленный на этот MAC пакет уходит на оба узла кластера, а дальше - см. предыдущие посты. Если бы в данном случае возвращался bogus, проблемы бы не было.

    В связи с этим возникает вопрос: то, что для DIP узла кластера система возвращает кластерный MAC (а не bogus) - это так и должно быть или ошибка в реализации NLB unicast в Windows Server 2008R2?

    Господа маститые, увешанные многими сертификатами от MS, форумчане! Я не прошу ни вникать в проблему, ни подсказывать решение, все уже разложено по полочкам. Я прошу просто блестнуть своим знанием ТЕОРИИ работы NLB и ответить на вопрос, как ДОЛЖНО быть by design. Надеюсь все же получить ответ.

    Заранее благодарен!

    15 сентября 2011 г. 13:51
  • я ничем не увешан, но у вас все правильно работает

    Network traffic for a host's dedicated IP address (on the cluster adapter) is received by all cluster hosts since they all use the same MAC address. Since Network Load Balancing never load balances traffic for the dedicated IP address, Network Load Balancing immediately delivers this traffic to TCP/IP on the intended host. On other cluster hosts, Network Load Balancing treats this traffic as load balanced traffic (since the target IP address does not match another host's dedicated IP address), and it may deliver it to TCP/IP, which will discard it

    то есть обратный пакет в любом случае попадает на все ноды кластера, дальше nlb уже сам определяет был ли этот трафик отправлен на кластер или на конкретную ноду

    15 сентября 2011 г. 16:13
    Отвечающий
  • то есть обратный пакет в любом случае попадает на все ноды кластера, дальше nlb уже сам определяет был ли этот трафик отправлен на кластер или на конкретную ноду


    Вот в моем случае похоже, что NLB дальше ничего не определяет. Трафик просто приходит всем узлам, а дальше - кто первый схватит (см. выше). Если трафик входит на VIP кластера - все работает как надо. Подскажите плз, в каких еще настройках NLB можно покопаться? Честно говоря, не знаю уже, куда и смотреть.

    Слава Богу хоть с провайдером разбираться не придется, он у нас вменяемостью не отличается :)


    • Изменено Mickwel 15 сентября 2011 г. 16:59
    15 сентября 2011 г. 16:33
  • Итак, окончательный вариант работы. Имеется кластер из двух серверов SRV1 и SRV2 (Windows Server 2008R2 EE + TMG 2010 with SP1 + rollup'ы 4). В каждом - 3 сетевухи: Internal, External и Intra-Array. На Internal и External настроен NLB unicast средствами TMG. Также имеются два пользователя USER1 и USER2, которым надо приконнектиться к некоему внешнему интернетовскому хосту по протоколу TCP (конкретика здесь не важна, это и HTTP, и FTP и SSH и т.п.).

    Пусть первым начинает работать USER1, он попадает в интернет через SRV1. Исходящий с SRV1 пакет выходит с внешнего DIP узла и в качестве источника имеет bogus MAC, зарегистрированный на порту свича, к которому подключен SRV1. Входящий ответный пакет в качестве destination имеет DIP SRV1, но вот в качестве destination MAC используется кластерный(!) MAC. Соответственно, пакет попадает на оба узла. Далее NLB сама принимает решение куда его отправить и, совершенно логично, этим узлом оказывается SRV1. Все работает.

    Вторым коннектится USER2, пусть он попадает в инет через SRV2. Входящий обратный пакет имеет DIP SRV2 и кластерный MAC. А вот дальше начинается несуразица: NLB ВСЕ РАВНО маршрутизирует этот пакет на SRV1, где тот совершенно правильно отвергается TMG, даже если первым этот исходный пакет поймал SRV2! В итоге коннект не устанавливается.

    Путем многочисленных проверок, установлена четкая закономерность: любые (в том числе и TCP) пакеты с внешнего хоста NLB по получении ВСЕГДА переправляет на тот узел кластера, с которого первым попали на указанный внешний хост. Вне зависимости от того, с какого узла кластера происходит коннект к хосту. Дальнейшая пересылка таких пакетов между узлами TMG-кластера НЕ производится, пакеты отвергаются TMG. Если же пакет от внешнего хоста адресован на VIP кластера - все работает прекрасно.

    Пытался разрешать маршрутизацию из внешней сети на intra-array и соответствующее правило типа allow all to all. Не помогает. Пытался менять настройки в реестре на узлах кластера сообразно описанному здесь: http://www.isaserver.org/articles/2004bidirnlb.html Не помогает, TMG всегда смывает все настройки на собственные.

    Вывод: на основании вышеизложенного, есть все основания говорить о допущенной MS ОШИБКЕ в реализации связки TMG + unicast NLB. Пакет, адресованный на DIP узла НЕ ДОЛЖЕН никуда пересылаться NLB, а должен обрабатываться только тем узлом, которому он адресован. Самый простой способ добиться этото - возвращать в RARP для DIP bogus,  а не кластерный MAC.

    Подскажите плз, куда обращаться в MS с описанием ошибки? И есть ли вообще смысл это делать?





    • Изменено Mickwel 19 сентября 2011 г. 16:58
    19 сентября 2011 г. 16:53
  • в rarp никода не вернут bogus, так как последний используется только чтобы в исходящих пакетах не было кластерного мака.

    nlb точно корректно работает? ни на какие ошибки не ругается? если уверен что MS виновата то обращайся к ним в техподдержку.

    19 сентября 2011 г. 18:10
    Отвечающий
  • nlb точно корректно работает? ни на какие ошибки не ругается? если уверен что MS виновата то обращайся к ним в техподдержку.


    В том-то что все и дело, что у NLB нет никаких ошибок. В логах настолько все чисто, что даже прицепиться не к чему. Да и входящие на VIP коннекты работают совершенно правильно. Попробую обратиться в MS, хотя что-то мне подсказывает, что никакого результата не будет.
    • Изменено Mickwel 19 сентября 2011 г. 19:48
    19 сентября 2011 г. 19:42
  • а со стороны провайдера тмг куда подключены? может косяк у них на железе? пробовал заменить провайдера своей железкой и проверить?

    20 сентября 2011 г. 15:11
    Отвечающий
  • Конечно, как только ни делал. И напрямую к провайдеру втыкал, и своим switch'ом заменял, и даже отдельный VLAN на нем делал. Результат - один и тот же - входящие на DIP tcp-пакеты все равно перенаправляются NLB (хотя и не должны), heardbeat'ы между узлами ходят отлично, входящий на VIP трафик обрабатывается правильно. Снимаешь NLB с внешней сети - все работает, входящие tcp-пакеты четко попадают на тот же хост, откуда вышли. И настройками самой NLB особо не поиграешь: в TMG их практически нет, а если через консоль NLB - TMG не дает применить и все смывает. Четко ошибка MS.

    Интересно, а есть ли на этом форуме люди, у кого такая конфигурация (NLB unicast на внешнем И внутреннем интефейсах) работает?

    Кстати, связаться с MS Support так и не получилось: я не имею партнерского статуса, Software Assurance у меня тоже нет, а во всех остальных случаях MS за обращение денег хочет. Очень мило: сначала взять с нас деньги за продукт, а затем за то, чтобы сообщить им об их же ошибке.



    • Изменено Mickwel 20 сентября 2011 г. 17:10
    20 сентября 2011 г. 16:51
  • День добрый.

    По настройке NLB Unicast/multicast

     http://www.isaserver.org/articles/basicnlbpart2.html

    21 сентября 2011 г. 12:15
  • Результат - один и тот же - входящие на DIP tcp-пакеты все равно перенаправляются NLB (хотя и не должны)

    выше же писал уже дважды - должны, пакеты на DIP всегда пойдут по общему кластерному маку. NLB драйвер должен сам все разрулить

    tmg ставить не пробовал, у меня две 2006 исы с nlb на обеих интерфейсах, и вроде проблем за год с этим не наблюдал

    21 сентября 2011 г. 16:25
    Отвечающий
  • выше же писал уже дважды - должны, пакеты на DIP всегда пойдут по общему кластерному маку. NLB драйвер должен сам все разрулить


    От того, что Вы даже дважды написали, проблема все равно осталась. NLB-драйвер по-прежнему ничего не разруливает. С установкой SP2 на TMG ничего не изменилось, проблема все равно сохраняется. Это - ошибка в работе связки TMG + NLB.
    21 января 2012 г. 17:27
  • Здравия Пан Зюзя. :)

    Есть вопрос. Какое сетевое оборудование вы используете на сетвых интерфейсах NLB?

    Настроено сетевое оборудования для работый NLB в режиме (в вашем случае unicast)?

    Пример. Catalyst Switches for Microsoft Network Load Balancing Configuration Example

    http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

    Возможно вам требуеться проверить настройки сетевого оборудования.


    MCITP. Знание - не уменьшает нашей глупости.
    23 января 2012 г. 14:37
  • в общем случае настройка свичей для юникаста не требуется
    23 января 2012 г. 15:11
    Отвечающий
  • Здравия Пан Зюзя. :)

    Есть вопрос. Какое сетевое оборудование вы используете на сетвых интерфейсах NLB?

    Настроено сетевое оборудования для работый NLB в режиме (в вашем случае unicast)?

    Пример. Catalyst Switches for Microsoft Network Load Balancing Configuration Example

    http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

    Возможно вам требуеться проверить настройки сетевого оборудования.


    MCITP. Знание - не уменьшает нашей глупости.


    Здравствуйте!

    Спасибо, что откликнулись. Вы имеете в виду то оборудование, куда подключены сетевухи TMG-серверов? Пробовал разное: простой неуправляемый switch, хитрый управляемый switch и даже банальный старый-престарый хаб, найденный совершенно случайно в дальних закромах. Результат для ВСЕХ случаев тот же самый, вышеописанная ситуация носит стабильно устойчивый характер, что и позволяет трактовать ее именно как ошибку MS.

    Насколько я знаю, дополнительные настройки маршрутизаторов нужны только для multicast-режима. Хотя на хитрых управляемых свитчах есть всякие решения типа Safeguard Engine, но и их отключение ни к чему не привело.

    23 января 2012 г. 15:52
  • День добрый, Пан Зюзя.

    Предлагаю ознакомиться со статьей. Возможно вы ее видели и читали, но прочтите ее еще раз. 

    Network Load Balancing Integration Concepts for Microsoft Internet Security and Acceleration (ISA) Server 2006

    Пример настройки NLB

    ISA 2006 Ent

    Enable Intra-Array communication in ISA 2006


    MCITP. Знание - не уменьшает нашей глупости.
    24 января 2012 г. 5:52
  • Спасибо, эти статьи я читал и делал именно так, как там и сказано.

    Как раз дело  в том, что когда пакеты приходят на VIP, NLB срабатывает идеально. А вот когда на DIP - как повезет :)

    • Изменено Mickwel 24 января 2012 г. 14:27
    24 января 2012 г. 14:24
  • Пан Зюзя.

    Еще раз перечитал ваши требования к той конфигурации, которую вы пытаетесь заставить работать.

    Если вам не трудно ознакомиться с такой статьей, как неподдерживаемые конфигурации. 

    1. Unsupported configurations

    2. Если вы включили NLB на интерфейсах TMG/ISA, то все ваши запросы должны направляться на адрес NLB в противном случае, эти запросы буду отбрасиваться.

    http://www.isaserver.org/tutorials/nlbpart3.html 


    MCITP. Знание - не уменьшает нашей глупости.
    24 января 2012 г. 15:23
  • впервые такое слышу, и в статьях что то этого я не нашел, потому как это нереально - как же тогда управлять нодами (по тому же rdp)?
    но в статье есть полезный совет - удостовериться что dip стоит на первом месте в списке адресов интерфейсов.

    формально не поддерживается только балансировка fwc, и то только формально, у меня например как раз fwc работает без проблем по кластерному имени.

    24 января 2012 г. 16:55
    Отвечающий
  • впервые такое слышу, и в статьях что то этого я не нашел, потому как это нереально - как же тогда управлять нодами (по тому же rdp)?

    Коментарий п.2 относился к рисунку в статье. Если запрос отправляеться из локальной сети в интернтет и ответ назад маршрутизиреуться правилами роутера и пересылаеться на интерфейс ноды, а не nlb, то пакет будет отброшен.
    MCITP. Знание - не уменьшает нашей глупости.
    25 января 2012 г. 6:13
  • так картинка то гласит как раз наоборот, что если интерфейс настроен неправильно, и иса послала пакет с VIP адреса, то обратный пакет может отбросится так как он тоже придет на VIP и может попасть не на ту ноду с которой пришел пакет. поэтому исходящие всегда должны быть с dip чтобы на этот dip и вернуться

    25 января 2012 г. 8:30
    Отвечающий
  • формально не поддерживается только балансировка fwc, и то только формально, у меня например как раз fwc работает без проблем по кластерному имени.


    У меня это тоже вполне хорошо работало.
    26 января 2012 г. 15:31
  • По поводу двух последних комментариев.

    Господа, Ваши утверждения входят в противоречие.

    Коваленко Олег. Когда пользователь идет в инет, исходящий пакет покидает TMG с DIP, соответственно провайдерский маршрутизатор ответный пакет отсылает обратно тоже на DIP и никак иначе. Он просто не может больше никуда его послать, поскольку речь идет о TCP-соединении. Получается, что если в Network Rules не сделать VIP адресом NAT'а, то TCP соединения через связку TMG + NLB не будут работать никогда.

    Дмитрий Никитин. Получается как раз наоборот, что нельзя ставить VIP NAT-адресом, поскольку тогда пакеты могут попадать не на ту ноду, с которой ушли, и TCP-сессия работать не будет?

    Где же правда? :)

    Ответ из практики: проблема исчезает, если NAT-адресом поставить VIP. Пакеты все равно попадают на нужные ноды.

    Проблема в том, что там, где я экспериментировал, это решение не годится. Там есть только один VIP, который - и это недвижимое требование - должен работать только на прием, т.е. только на входящие коннекты. Лазать в инет с него никто не должен. Исторические корни этого требования установить не удалось :)

    P.S. DIP стоял на первом месте.

    Все равно спасибо :)

    26 января 2012 г. 15:45
  • Пан Зюзя, у Вас серверы TMG физические?
    27 января 2012 г. 7:57
    Модератор
  • Да. Но как разворачивать на виртуальных, я тоже читал :)

    27 января 2012 г. 18:03