Windows NLB-кластер и коммутатор Cisco.

Почему специалисты по сетям, особенно те что предпочитают оборудование Cisco так не любят решения от Microsoft?
Одну из причин опишу ниже.

У нас есть MS Forefront TMG, работающий на массиве из двух серверов. Еще есть коммутатор Cisco для подключения к каналу провайдера. Кроме указанного выше массива в коммутатор был подключен банкомат, расположенный у нас на территории.

Поскольку главный элемент информационной безопасности во всем мире до сих пор это умолчание и засекречивание всего и вся, банкомат пришлось подключить во внешний коммутатор, так как коллеги из банка сослались на внутренние инструкции и заявили что не могут предоставить нам ни какой информации для подключения банкомата через внутреннюю сеть предприятия.

А дальше начало твориться странное. Банкомат регулярно терял связь, выходил в аварийный режим и всячески отказывался работать, особенно в дни зарплаты. Анализ данных с коммутатора показал, что порт на который подключен банкомат забит трафиком, средняя скорость на порту 35 mbps. Трафик входящий.

В принципе – не страшно, наверное. Порт работает на скорости 1 gbps, значит внутри банкомата стоит сетевая карта поддерживающая эту скорость, ей эти 35 mbps мелочь, откуда проблемы?

Смотрю порты коммутатора, которые подключены к массиву TMG. Там трафик и входящий и исходящий.
На всякий случай мучаю поддержку провайдера и получаю от них данные по трафику. По их данным флуд идет от нас и прибивается на их оборудовании.

Подключаюсь к коммутатору напрямую, перехватываю пакеты и вижу на порту пакеты предназначенные для серверов массива TMG.

Что происходит?

На лицо “некорректная работа” коммутатора Cisco, который вместо адресной передачи пакетов по портам работает в режиме повторителя и рассылает пакеты по всем портам сразу. Это не нормально. Подобный режим работы у коммутатора возможен после включения, пока не создана таблица MAC-адресов и коммутатор не знает что за каким портом находится. Что мешает созданию таблицы? Как именно работает технология NLB на Windows Server, нет ли тут проблемы? Надо проверить гипотезу.

И так, NLB или балансировка сетевой нагрузки (Network Load Balance) предлагается к применению начиная с Windows Server 2000. Кстати, NLB не совместима с технологией отказоустойчивой кластеризации (fault tolerance cluster) от Microsoft, что влечет ограничения на использование этой технологии, например в DAG Microsoft Exchange 2013, но это не является темой данной статьи.
И так, NLB кластер Windows может работать в двух режимах:

  • Одноадресный режим (Unicast)
  • Режим многоадресной рассылки (Multicast)

В режиме Unicast, MAC-адреса сетевого интерфейса каждого сервера кластера заменяются на общий MAC-адрес кластера. Все сервера nlb-кластера имеют один и тот же MAC-адрес, все пакеты отправленные на этот адрес пересылаются всем членам nlb-кластера.

Так же каждому серверу nlb-кластера назначается еще один свой фиктивный MAC-адрес, на основании идентификатора хоста и этот адрес указывается в заголовке ethernet-кадра.
Минусом режима unicast является то, что если кластер подключен к сетевому коммутатору, пакеты отправляются по всем портам коммутатора, что может вызвать флуд (flood, большое количество не нужных пакетов на портах коммутатора). Логично, так как коммутатор получает непонятную для него ахинею в виде одного и того же MAC-адреса в пакетах с нескольких интерфейсов и не может создать таблицу mac-адресов.

В режиме Multicast, каждый сетевой интерфейс каждого узла nlb-кластера сохраняет свой аппаратный MAC-адрес. Так же на каждый узел nlb-кластера назначается дополнительный MAC-адрес, являющийся производным от IP-адреса nlb-кластера.

И если верить документации Microsoft, то всё хорошо и можно использовать это решение.

А вот в документации по коммутаторам Cisco указывается совсем иное. Поскольку входящие пакеты имеют один IP адрес nlb-кластера и MAC-адрес многоадресной рассылки (не совпадает пара IP – MAC), то коммутатор отбрасывает этот заголовок и рассылает пакет по всем портам коммутатора, что опять вызывает флуд.

Проверяем режим работы nlb-кластера на Forefront TMG:

cisco-tmg-1cisco-tmg-2cisco-tmg-3Режим работы unicast.

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

Что делать?

Нет особой разницы, какой режим NLB использовать в данном случае.

Нужно статически указать коммутатору на какие порты отправлять пакеты с MAC-адресом nlb-кластера.

Еще не плохо убрать порты к которым подключен nlb-кластер в отдельный vlan и настроить маршрутизацию до этого vlan-а, дабы не крутить петли патч-кордами в пределах одного коммутатора.

Подключаемся к консоли коммутатора Cisco.
Указываем статическую привязку виртуального MAC-адреса к портам коммутатора (порты ge1/0/1 и ge1/0/2 – это порты куда включены сервера Forefront TMG):

mac-address-table static 0300.5e11.1111 vlan 22 interface GigabitEthernet1/0/2 GigabitEthernet1/0/3

IP адрес 172.16.63.241 – это виртуальный IP адрес nlb кластера:

arp 172.16.63.241 0300.5e11.11
interface vlan 122
ip address 172.17.63.240 255.255.255.192
Клиентская vlan:
interface vlan120
ip address  10.1.1.250 255.255.255.0
ip classless

172.16.63.193 – это шлюз (default gateway):

ip route 0.0.0.0 0.0.0.0 172.16.63.193
end

Чтобы не светить своими реальными адресами, я заменил их на те, что были даны в примере.

Подробнее:

technet.microsoft.com

cisco.com

Comments

comments