Excesso de Tráfego ao usar NLB

Por: Yuri Diógenes

1. Introdução

O tema acerca do componente de balanceamento de carga do Windows não é algo novo, porém as dúvidas quanto ao funcionamento e as capacidades deste recurso é algo que ainda origina muitas chamadas para o suporte Microsoft. Uma destas chamadas que recebi foi justamente para tratar da análise de um tráfego que o cliente estava considerando excessivo para o ambiente dele.

2. O Cenário

O cenário do cliente era semelhante ao mostrado abaixo:

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.

3. 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.

Através desta explicação podemos então dizer que o efeito de “Flooding” pode ser causado pelo fato do endereço de destino não se encontrar na tabela MAC da Switch. Quando isso acontece a Switch vai encaminhar este frame para todas as portas da VLAN com excessã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.

4. 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 https://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:

Source Destination Protocol Info

192.168.0.220 Broadcast ARP Who has 192.168.0.145? Tell 192.168.0.220

Ethernet II, Src: 192.168.0.220 (00:03:ff:3b:2b:29), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Destination: Broadcast (ff:ff:ff:ff:ff:ff)

Source: 192.168.0.220 (00:03:ff:3b:2b:29)

Type: ARP (0x0806)

Address Resolution Protocol (request)

Hardware type: Ethernet (0x0001)

Protocol type: IP (0x0800)

Hardware size: 6

Protocol size: 4

Opcode: request (0x0001)

Sender MAC address: 192.168.0.220 (00:03:ff:3b:2b:29)

Sender IP address: 192.168.0.220 (192.168.0.220)

Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)

Target IP address: 192.168.0.145 (192.168.0.145)

1. 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);

Source Destination Protocol Info

MS-NLB-PhysServer-02_c0:a8:00:91 192.168.0.220 ARP 192.168.0.145 is at 02:bf:c0:a8:00:91

Ethernet II, Src: MS-NLB-PhysServer-02_c0:a8:00:91 (02:02:c0:a8:00:91), Dst: 192.168.0.220 (00:03:ff:3b:2b:29)

Destination: 192.168.0.220 (00:03:ff:3b:2b:29)

Source: MS-NLB-PhysServer-02_c0:a8:00:91 (02:02:c0:a8:00:91)

Type: ARP (0x0806)

Trailer: 000000000000000000000000000000000000

Address Resolution Protocol (reply)

Hardware type: Ethernet (0x0001)

Protocol type: IP (0x0800)

Hardware size: 6

Protocol size: 4

Opcode: reply (0x0002)

Sender MAC address: 192.168.0.145 (02:bf:c0:a8:00:91)

Sender IP address: 192.168.0.145 (192.168.0.145)

Target MAC address: 192.168.0.220 (00:03:ff:3b:2b:29)

Target IP address: 192.168.0.220 (192.168.0.220)

2. 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:

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.

5. 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).

6. 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