Experiências do mundo real: ARP e como realizar o troubleshoot em máquinas virtuais.

Decidi fazer isso pois este blog está empoeirado demais e criei este artigo, agora sobre uma categoria, Experiências do mundo real (EMR), onde posso passar um pouco de experiência do dia-a-dia trabalhando com redes e com outras equipes de suporte em TI. Irei passar exemplos de situações e como resolvê-las ou acabar se livrando delas, deixando para outra equipe responsável pelo seu escopo, ou serviços e ativos relativos.

ATENÇÃO!!! Como TI é uma área estressante, você tem que lidar com perguntas de outras pessoas para afirmar que seu troubleshoot está correto e que da "sua parte" não há nada de errado. É claro que, isso depende muito de como você está preparado para isso, qual o seu nível de conhecimento e de como você sabe demonstrar este conhecimento para as outras equipes. Portanto não use este post como uma referência única. Cada situação é uma situação, dependendo de como o ambiente está montado, quais tecnologias empregadas e fabricantes também.

Este tópico irá mostrar a situação onde um usuário não consegue acessar uma máquina virtual hospedada em um servidor físico, onde, ambos estão na mesma subrede. Abaixo segue a topologia do ambiente e como ele funciona. Isto envolve um pouco sobre o conceito de como funciona o protocolo ARP, útil para obter o MAC address a partir de um endereço IP... Usando o comando show ip arp (que será mostrado mais abaixo). Aqui, tenho uma máquina onde há vários IPs que são de máquinas virtuais e uma, por algum motivo, não responde.

Exemplo de rede com servidor fisico rodando VMs na rede.

 Dependendo de onde você está, principalmante se o host estiver em um local remoto, poderá fazer um traceroute para identificar onde o caminho pára e depois entrar em algum equipamento de rede próximo. Muitos casos em redes grandes, podemos encontrar SVIs (Switched VLAN Interface), cada uma com um IP correspondente da subnet do host e a partir daí executar o troubleshooting.

Durante uma discussão com o usuário, podemos identificar se o host é uma VM, ou um servidor físico. Neste caso, temos tanto o host (físico) quanto a VM (virtual) na mesma rede, facilitando o troubleshooting nos equipamentos de redes.

Um conceito para ser lembrado, ainda mais quem está iniciando ou estudando redes ou até para uma certificação, é sobre o ARP. Com o ARP, podemos obter o MAC address do host e da VM que estamos falando e com isso, identificar o problema.  Quando o ARP não está na tabela, podemos deduzir que algum problema físico (energia, cabo de rede desconectado ou placa de rede com problema) está rolando no servidor, ainda mais se ele for físico, mas estamos falando de um servidor físico, onde tem se o MAC address na tabela, tanto ARP do equipamento layer 3 quanto um MAC address na tabela CAM do switch (assumindo ser layer 2, como na figura acima).

Note que tanto a maquina host (192.168.10.60) e a virtual (192.168.10.10) usam o mesmo MAC address e estão na mesma VLAN. Como tenho apenas um roteador, usei subinterfaces para cada VLAN presente no lab, que no caso, FastEthernet0/0.10 pertence a VLAN 10.

Router#sh ip arp 192.168.10.10
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.10.10           0   001b.772b.c811  ARPA   FastEthernet0/0.10
Router#sh ip arp 192.168.10.60
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.10.60           3   001b.772b.c811  ARPA   FastEthernet0/0.10
Router#

Procurando no switch que conecta o roteador (ou um switch layer 3), podemos ver que há o MAC na tabela dele, na intercafe FastEthernet 0/14 (Onde o host está conectado no switch):

switch0#sh mac address-table  address  001b.772b.c811
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    001b.772b.c811    DYNAMIC     Fa0/14
Total Mac Addresses for this criterion: 1
switch0#

Checando a porta. Ainda está conectada fisicamente:

switch0#sh int Fa0/14 status

Port      Name               Status       Vlan       Duplex  Speed Type
Fa0/14  Labport            connected    trunk      a-full  a-100 10/100BaseTX
switch0#

Podemos considerar que o MAC do host está lá, e que o host "pinga" na rede, mas que acontece quando a VM não pinga mais? A entrada ARP no roteador expira e não há mais resposta, nem como acessar a VM remotamente!

Entrada ARP, com a VM "funcionando":

CCME#sh ip arp 192.168.10.10
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.10.10           9   001b.772b.c811  ARPA   FastEthernet0/0.10
CCME#

E agora, sem resposta, e o ARP table para a VM está marcada como incomplete, o que significa que algo está errado com a VM:

Router#sh ip arp 192.168.10.10  
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.10.10           0   Incomplete      ARPA  
Router#

E o servidor host pinga:

Router#ping 192.168.10.60

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.60, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
CCME#sh ip arp 192.168.10.60
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.10.60          18   001b.772b.c811  ARPA   FastEthernet0/0.10
Router#

Depois dessa, concluímos que apesar de o host e a VM estarem na mesma subrede e na mesma porta do switch, a VM ou o software de virtualização têm que ser verificados, pois há o MAC do host presente, tanto na porta do switch quanto na entrada ARP do roteador/L3 switch. Isso também vale caso a VM e o host tiverem MAC addresses diferentes, pois eles estando em uma mesma subnet/VLAN podemos isolar o problema com a mesma facilidade também descrita neste post.

Por enquanto é só!