Arquivo

Archive for the ‘NLB’ Category

TMG – NLB – Bi Directional Affinity ( BDA ) – Afinidade Bi Direcional

Considere o Ambiente abaixo com um Array com 2 Servidores TMG e com NLB configurado somente para a rede interna.

Ambiente
—————————————-

Nesse caso, o cliente estava utilizando os 2 nós do array para publicar um único servidor SMTP na rede interna.

O Servidor SMTP estava publicado na internet com os IPs 200.200.200.1 no TMG01 e 200.200.200.2 no TMG02.

O balanceamento havia sido feito no DNS, configurando o MX para os IPs 200.200.200.1 e 200.200.200.2 conforme descrito no link abaixo:

http://www.zytrax.com/books/dns/ch9/rr.html#mail

Problema:
———————————–

– Foi publicado o servidor SMTP com uma regra recebendo os dois IPs válidos, um em cada servidor TMG, quando tentávamos o aceso por um ip funcionava corretamente, quando tentávamos refazer o mesmo teste usando o outro ip publicado ele não aceitava, ficava aguardando e depois apresentava o com o erro abaixo no log do servidor TMG:

Failed Connection Attempt
Log type: Firewall servisse
Status: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

– Não era possível se conectar no servidor SMTP utilizando-se os 2 IPs externos. Ou funcionava um ou outro.

Resolução:
—————————————-

– Olhando a regra de publicação, na aba “TO” a opção “Requests appear to come from the original client” estava selecionada.

– Alteramos essa opção para “Requests appear to come from the ISA Server computer”.

– Após essa alteração, conseguimos nos conectar com sucesso em ambos os IPs externos.

– Com isso, aparentemente o caso havia sido resolvido.
– Estavamos conseguindo conectar no servidor SMTP utilizando os dois IPs, passando pelos 2 TMGs. Mas o servidor que estava sendo publicado era um SMTP Server. Os servidores SMTP precisam saber o IP de origem da conexão para fazer consulta do DNS Reverso .
– Por esse motivo, não seria possível manter a opção “Requests appear to come from the ISA Server computer”.

– Quando a opção “Requests appear to come from the ISA Server computer” está marcada, o TMG envia a requisição para o servidor SMTP com o IP dele. Com isso, quando o servidor SMTP responde para o VIP, o mecanismo do NLB sabe identificar de qual nó o trafego veio e envia a resposta para o nó correto.

– A opção “Requests appear to come from the original client” não funciona quando temos NLB em uma única interface do TMG. Abaixo segue a explicação:

– Quando uma requisição é realizada por um cliente externo, um dos nós do TMG irá se encarregar de encaminhar essa requisição para o servidor SMTP na rede interna. Essa requisição chega ao servidor SMTP com o IP do cliente que fez a requisição.
– Quando o Servidor SMTP responde essa requisição, ele envia para o gateway cadastrado na placa de rede (nesse caso é o VIP do NLB).
– O problema ocorre quando a requisição externa é feita para o TMG01 e na resposta do SMTP Server, o NLB (que não sabe de qual nó a conexão foi iniciada pois o endereço de destino é externo) encaminha esse pacote para o TMG02. Isso faz com que a conexão seja quebrada.

– Para resolver esse problema, precisamos que as conexões em ambas as direções passem pelo mesmo TMG. A única maneira de fazer isso, é configurar as placas externas do TMG em NLB.

– Com o NLB configurado na placa Interna e externa, temos a afinidade Bi-Direcional.

– Essa afinidade bi-direcional, garante que a requisição e a resposta passem pelo mesmo nó do array fazendo que seja possível se conectar por ambos os IPs externos.

———————————————————————–

Nos artigos abaixo, é muito bem descrito o funcionamento do NLB BDA.

http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx

http://www.isaserver.org/articles/2004nlbbdarevisted.html

———————————————————————————————-

Renato Marson Pagan

 

NLB – Virtual IP não responde quando acessado de uma subnet diferente

Considere o ambiente abaixo com 2 Servidores Windows Server 2008 R2 configurados em Multicast NLB.

O problema relatado nesse caso é que não era possível se conectar ao NLB utilizando o VIP (Virtual IP) quando o acesso era realizado por um cliente em uma diferente subnet.

Tentamos realizar o acesso a partir da mesma subnet com sucesso.

Na máquina cliente em uma subnet diferente realizamos os seguintes teste:

——–

Pingar o IP dedicado do Server1 || OK

Pingar o IP dedicado do Server2 || OK

Pingar o VIP do NLB || Falha

Pingar o Gateway (192.168.0.1) a partir de qualquer um dos nós do NLB || Sucesso

——–

Ao rodar o comando ARP –A na máquina cliente foi possível visualizar o MAC address correto vinculado ao IP do roteador (192.168.0.1).

A tabela ARP dos 2 servidores tinham o MAC correto do gateway (172.29.42.1)

Ao rodar o comando show arp no roteador Cisco verificamos que o MAC address para o VIP 172.29.42.227 estava marcado como Incomplete. Com isso o roteador não conseguia enviar os pacotes para o VIP.

Esse é um comportamento padrão em dispositivos CISCO e outros dispositivos de rede. Eles não aceitam uma resposta ARP de uma endereço IP Unicast que tenha um Multicast MAC address.

No link abaixo essa situação é bem detalhada:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml#mm

————————————————————–
“In Multicast Mode, the system admin clicks the IGMP Multicast button in the MS NLB configuration GUI. This choice instructs the cluster members to respond to ARPs for their virtual address using a multicast MAC address for example 0300.5e11.1111 and to send IGMP Membership Report packets. If IGMP snooping is enabled on the local switch, it snoops the IGMP packets that pass through it. In this way, when a client ARPs for the cluster’s virtual IP address, the cluster responds with multicast MAC for example 0300.5e11.1111. When the client sends the packet to 0300.5e11.1111, the local switch forwards the packet out each of the ports connected to the cluster members. In this case, there is no chance of flooding the ARP packet out of all the ports. The issue with the multicast mode is virtual IP address becomes unreachable when accessed from outside the local subnet because Cisco devices do not accept an arp reply for a unicast IP address that contains a multicast MAC address. So the MAC portion of the ARP entry shows as incomplete. (Issue the command show arp to view the output.) As there is no MAC portion in the arp reply, the ARP entry never appeared in the ARP table. It eventually quit ARPing and returned an ICMP Host unreachable to the clients. In order to override this, use static ARP entry to populate the ARP table as given below. In theory, this allows the Cisco device to populate its mac-address-table. For example, if the virtual ip address is 172.16.63.241 and multicast mac address is 0300.5e11.1111, use this command in order to populate the ARP table statically:

arp 172.16.63.241 0300.5e11.1111

However, since the incoming packets have a unicast destination IP address and multicast destination MAC the Cisco device ignores this entry and process-switches each cluster-bound packets. In order to avoid this process switching, insert a static mac-address-table entry as given below in order to switch cluster-bound packets in hardware.

mac-address-table static 0300.5e11.1111 vlan 200 interface  fa2/3 fa2/4

Note: For Cisco Catalyst 6000/6500 series switches, you must add the disable-snopping parameter. For example:

mac-address-table static 0300.5e11.1111 vlan 200 interface fa2/3 fa2/4 disable-snooping

————————————————————–

Após efetuarmos as alterações no roteador conforme o exemplo acima, foi possivel acessar o endereço VIP a partir de qualquer subnet.

Abaixo, algumas perguntas relacionadas a esse caso:

Como são gerados os MACs Virtuais do NLB?

Por padrão é gerado um endereço virtual com o endereço 03-BF-XX-XX-XX-XX. Conforme pode ser visto no link abaixo:

http://technet.microsoft.com/en-us/library/bb742455.aspx

“Network Load Balancing provides a second mode for distributing incoming network traffic to all cluster hosts. Called multicast mode, this mode assigns a layer two multicast address to the cluster adapter instead of changing the adapter’s station address. The multicast MAC address is set to 03-BF-1-2-3-4 for a cluster’s primary IP address of 1.2.3.4. Since each cluster host retains a unique station address, this mode alleviates the need for a second network adapter for communication between cluster hosts, and it also removes any performance penalty from the use of dedicated IP addresses.”

O que garante que não vai existir outro MAC igual em nossa rede causando conflitos com esse MAC virtual?

O Multicast MAC Address é gerado com o endereço 03-BF-XX-YY-ZZ-WW. Onde XX-YY-ZZ-WW é igual o endereço IP VIP do NLB em Hexadecimal.
http://technet.microsoft.com/en-us/library/cc756878(WS.10).aspx

Por exemplo: Nesse caso o VIP é 172.29.42.227.

Esse endereço em Hexadecimal é 03-bf-ac-1d-2a-e3   que é o Multicast MAC do seu NLB. 

AC=172
1D=29
2A=42
E3=227 

Com isso só teremos esse MAC duplicado se existir outro NLB Multicast na rede com o mesmo VIP.

Ótimo guia para troubleshooting em problemas de NLB.
http://download.microsoft.com/download/3/2/3/32386822-8fc5-4cf1-b81d-4ee136cca2c5/NLB_Troubleshooting_Guide.htm

———————————————————————————————-

Renato Marson Pagan

Categorias:Networking, NLB Tags:, , , ,