Figura 1 – Cenário de Configuração

Neste cenário temos três servidores ISA Server 2004 com NLB onde cada um tem duas placas, uma placa está sendo usada de forma isolada para comunicação Intra-Array, ajuda a isolar este tipo de tráfego de forma que esta interface seja responsável apenas para a troca de informações relacionadas ao array do ISA. Neste caso a principal reclamação do cliente era que havia “Flood” na switch VLAN1_A.

O que é um Switch Flood?

As switches de nível 2 tomam decisões acerca de onde os frames devem ser enviados a partir de uma tabela de endereços MAC. Nesta tabela temos então um mapeamento do endereço MAC do host e a porta a qual este host está conectado. Um exemplo claro de “flooding” acontece quando ligamos uma switch, neste momento o equipamento vai ter uma tabela de endereços vazia, pois não houve tráfego de rede ainda e com isso não houve oportunidade para a switch aprender os endereços e fazer o devido mapeamento das portas. Quando isso acontece a Switch vai encaminhar os pacotes para todas as portas com exceção da porta a qual o frame foi recebido.

Figura 2 – Flooding

No exemplo acima, todas portas receberam o frame com exceção da porta 4, que foi a porta que originou a transmissão.

Uma outra premissa que se deve ter em mente é que uma switch não permite que um determinado endereço MAC esteja associado a mais de uma porta.

Como o NLB funciona?

A partir do Windows Server 2003 o serviço de NLB pode trabalhar de três formas: Unicast, Multicast e IGMP. A forma com que ele trabalha define justamente como será feito o uso do endereço MAC real e do endereço MAC virtual.

O método padrão e mais utilizado é o “Unicast”, neste método o endereço MAC real de cada nó do cluster NLB é substituído por um MAC virtual. Quando temos os servidores NLB conectados em uma mesma switch então temos um problema, pois como foi dito anteriormente não é permitido a associação do mesmo MAC em mais de uma porta. Para resolver este problema o NLB vai mascarar o endereço MAC Virtual. Sabendo que a switch aprende os endereços MAC associados em cada porta através da leitura do cabeçalho Ethernet o NLB então vai criar um MAC baseado na prioridade do nó NLB e atribuir este MAC a cada adaptador do array NLB. Então será este o endereço que aparecerá no cabeçalho frame Ethernet, por exemplo: se o endereço MAC virtual for 02-BF-1-2-3-4 então ele será trocado por 02-p-1-2-3-4, onde P é a prioridade do nó do NLB.

Vejamos o exemplo de uma conversação entre um cliente e dois servidores NLB, neste exemplo um cliente está tentando acessar o site http://nlb.ctest.com/, que por sua vez redireciona para o IP virtual do NLB, que é 192.168.0.145. É importante salientar que neste caso está sendo utilizado um hub e não uma switch:

Primeiramente temos a resolução ARP acontecendo, onde o host de origem (192.168.0.220) pergunta quem é o host 192.168.0.145. Nos cabeçalhos ARP e Ethernet é possível verificar que o destino é broadcast um endereço de broadcast (Ethernet) e um endereço desconhecido (cabeçalho ARP);

A resposta vem em seguida, e neste caso vem de um dos dois servidores NLB. Note que este MAC que aparece no cabeçalho Ethernet é o MAC virtual (02:bf:c0:a8:00:91). Veja na figura abaixo que este é o MAC que aparece na interface gráfica do NLB:

Figura 3 – Endereço MAC Virtual

Os padrões de MAC irão variar de acordo com o tipo de tráfego que o NLB está usando, na tabela abaixo é mostrado o esquema dos endereços usados:

Modo NLB

Endereço MAC

Descrição

Unicast

02-BF-W-X-Y-Z

W-X-Y-Z = Endereço IP

Endereço MAC Onboard desabilitado

Multicast

03-BF-W-X-Y-Z

W-X-Y-Z = Endereço IP

Endereço MAC Onboard desabilitado

No modo Unicast o driver NLB desabilita o endereço MAC que está onboard na placa a qual o serviço está habilitado. Já no modo Multicast o NLB suporta tanto o uso do onboard quanto o endereço MAC Multicast.

Como o NLB pode causar Flooding?

Bem, agora que já sabemos o que é o Flooding e como o NLB funciona então vejamos o que pode causar este problema em um cenário de NLB. Na realidade, se você leu e entendeu bem os dois conceitos já da para tirar uma conclusão de tudo isso, correto?

O fato é que quando os dois nós NLB estão na mesma Switch, ao responder a um pacote o endereço MAC que será usado é o endereço que foi criado com base na prioridade do nó. Muito bem, até aí tudo bem, porém, quando um cliente tenta comunicar-se com o NLB ele tentará acessar o recurso usando o IP Virtual ou também chamado de VIP (Virtual IP), este IP por sua vez será mapeado para o MAC Virtual, que por sua vez não está vinculado com nenhuma porta da Switch, tendo em vista que cada porta da Switch que vai para o NLB está vinculada com o MAC que contém a prioridade do nó. O resultado disso é que a Switch vai enviar o frame para todas as portas (conforme vimos no item 3 deste artigo).O modo multicast também pode acarretar “flooding” e em alguns cenários pode não ser usado devido a possíveis incompatibilidades na infra-estrutura de rede (switches e roteadores).

Conclusão

Este é um comportamento esperado da tecnologia NLB e de fato isso não traz um impacto grande na rede, tendo em vista que o “Flooding” ocorre para dentro, ou seja, as portas que iram ouvir este flooding serão as portas da switch a qual os nós NLB estão conectados.

Para entender o porque desta afirmação, voltemos para o nosso cenário e digamos que um cliente que está conectado na switch VLAN1_B tente se comunicar com o endereço IP virtual do NLB. O que vai acontecer é que no momento em que este IP for convertido em MAC e este MAC chegar na switch de destino (VLAN1_A) as portas que iram receber o flooding serão todas menos a porta de origem, ou seja, a porta de uplink com a switch VLAN1_B. Com isso as estações conectadas nesta switch (VLAN1_B) não serão afetadas com este “flooding”.

Aí você pergunta: mas e a Switch Core_A, ela também vai receber o flooding, correto? A resposta é sim, ela vai receber. Mas note que nesta topologia, esta switch só tem uma porta configurada para a VLAN1, com isso o flooding não ultrapassará para as outras VLANs. Caso a Switch Core_A tivesse um uplink com outra Switch que pertencesse a VLAN1, aí sim, esta outra Switch receberia o flooding.

A conclusão deste caso foi apenas mostrar ao cliente como a tecnologia funcionava e no caso dele o impacto realmente não ocorria. Porém existem cenários cujo desenho topológico da  rede pode contribuir com que este comportamento impacte o ambiente. Basta por exemplo que ao invés de usar uma switch dedicada para o serviço de NLB, se use uma switch compartilhada entre os servidores NLB e outros servidores de rede ou entre clientes. Neste caso, a mudança da topologia seria a solução mais recomendada.

Devido a estes detalhes é importante que antes de implementar uma solução que use NLB você tenha conhecimento de como funciona e tenha um planejamento para evitar possíveis efeitos colaterais no ambiente de produção.

Segue abaixo três ótimas referências acerca deste assunto:

Microsoft KB: How Network Load Balancing Technology Works

Microsoft KB: Network Load Balancing in ISA Server 2004 Enterprise Edition

Cisco: Unicast Flooding in Switched Campus Networks

Apresentações que fiz sobre NLB: http://blogs.technet.com/b/yuridiogenes/archive/2010/07/28/nlb-slides-portuguese.aspx