Experiências do mundo real + LAB. Resolvendo problemas com trunks - Parte I - VLAN Mismatch.

Imagine que de repente, você depara com estas mensagens no logging ou aparecendo espontaneamente na console do switch, após receber um alerta ou um chamado de usuários reclamando de algum problema com acesso a rede:

SWITCH-A# 
*Mar  1 00:31:21.695: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/14 (30), with SWITCH-B FastEthernet1/15 (1).
SWITCH-A# 

E o mais interessante, não consegue ter tem acesso e nem ter resposta no ping para o SWITCH-B, mesmo recebendo CDP dele na porta Fa1/14 do SWITCH-A (Significa que ele está funcionando). O que fazer? Chamar o Bátima? Apesar da dublagem deste vídeo ser chula, recomendo vê-lo depois que fazer o LAB deste post, para quem nunca viu... Mas, e agora, como resover isto?

É simples Comissário, essa fita mostra tudo.

Já que o Bátima está com outras ocupações, e você é o responsável por manter uma rede ou fazer usuários ficarem felizes, segue abaixo como resolver este problema. Vamos lá, segue a topologia abaixo:

Trunk entre SWITCH-A e SWITCH-B

Em ambos os switches, temos três VLANs, VLAN 10, usada para as máquinas, VLAN 20, usada para os Telefones IP (tráfego de sinalização e voz) e a VLAN 30, que foi escolhida para gerenciamento. Note que esta VLAN foi escolhida pelo cliente ou o projetista da rede (Ou até você mesmo pode ter escolhido, se for o projetista ou administrador da rede) para ser uma VLAN nativa, ou seja, conceitualmente os quadros, uma PDU (Protocol Data Unit) da camada 2 (Enlace) não passarão a ter marcação de nenhuma VLAN, passando entre os switches como se fossem um quadro normal. O problema nesta caso é que um dos switches não está com a mesma VLAN nativa configurada na porta que faz o trunk com o seu switch vizinho. Neste caso, podemos checar que, após conectar pela console (Acesso físico) no switch que não estamos conseguindo acessar, vemos os também seguintes as seguintes mensagens na saída da console ou nos logs:

SWITCH-B#
*Mar  1 00:10:04.307: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/15 (1), with SWITCH-A FastEthernet1/14 (30).
SWITCH-B#
*Mar  1 00:11:04.311: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/15 (1), with SWITCH-A FastEthernet1/14 (30).
SWITCH-B#
*Mar  1 00:12:04.299: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/15 (1), with SWITCH-A FastEthernet1/14 (30).
SWITCH-B#

Já que temos alguma forma de acesso ao SWITCH-B, podemos começar a comparar como estão configuradas as portas entre eles. Podemos ver diretamente a configuração da porta ou somente verificar como o está o trunking delas.

SWITCH-A>sh int fastEthernet  1/14 switchport
Name: Fa1/14
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Disabled
Access Mode VLAN: 0 ((Inactive))
Trunking Native Mode VLAN: 30 (MGMT)
Trunking VLANs Enabled: ALL
Trunking VLANs Active: 1,10,20,30
Protected: false
Priority for untagged frames: 0
Override vlan tag priority: FALSE
Voice VLAN: none
Appliance trust: none
SWITCH-A>

E o log gerado, no SWITCH-A:

 *Mar  1 00:12:24.351: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/14 (30), with SWITCH-B FastEthernet1/15 (1).

Agora vamos para o SWITCH-B:

SWITCH-B#sh int fastEthernet  1/15 switchport
Name: Fa1/15
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Disabled
Access Mode VLAN: 0 ((Inactive))
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Trunking VLANs Active: 1,10,20,30
Protected: false
Priority for untagged frames: 0
Override vlan tag priority: FALSE
Voice VLAN: none
Appliance trust: none
SWITCH-B#

O que podemos ver entre os dois switches é que existe a configuração de trunk entre eles e todas as VLANs estão sendo permitidas entre ambas as portas, porém, a VLAN nativa ainda não está configurada para a VLAN 30 no SWITCH-B. Para isso, temos que fazer com que a VLAN 30 seja a VLAN nativa também para a interface Fa1/15 do SWITCH-B. Até não mudarmos esta configuração na porta, ainda veremos os logs de VLAN mismatch em ambos switches no log e não haverá tráfego IP na vlan 30 para o switch B. Abaixo seguem os logs e o teste de ping para o SWITCH-A:

SWITCH-B#
*Mar  1 00:35:18.551: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/15 (1), with SWITCH-A FastEthernet1/14 (30).
SWITCH-B#
*Mar  1 00:36:18.547: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/15 (1), with SWITCH-A FastEthernet1/14 (30).
SWITCH-B#
*Mar  1 00:37:18.563: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/15 (1), with SWITCH-A FastEthernet1/14 (30).
SWITCH-B#

 SWITCH-B#sh cdp nei fas 1/15 det
-------------------------
Device ID: SWITCH-A
Entry address(es):
  IP address: 182.168.30.20
Platform: Cisco 3725,  Capabilities: Router Switch IGMP
Interface: FastEthernet1/15,  Port ID (outgoing port): FastEthernet1/14
Holdtime : 169 sec

Version :
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T10, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Mon 14-Sep-09 15:53 by prod_rel_team

advertisement version: 2
VTP Management Domain: ''
Native VLAN: 30
Duplex: full

SWITCH-B#ping 182.168.30.20

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 182.168.30.20, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
SWITCH-B#

 Agora, para arrumar isto, basta um simples comando na interface Fa1/15 do SWITCH-B e os logs irão parar de aparecer em ambos os switches e teremos conectividade entre eles pela VLAN30:

SWITCH-B(config)#int fas 1/15
SWITCH-B(config-if)#switchport trunk native vlan 30
SWITCH-B(config-if)#

E agora, podemos verificar a porta novamente :

SWITCH-B#sh interfaces  fas1/15 switchport
Name: Fa1/15
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Disabled
Access Mode VLAN: 0 ((Inactive))
Trunking Native Mode VLAN: 30 (MGMT)
Trunking VLANs Enabled: ALL
Trunking VLANs Active: 1,10,20,30
Protected: false
Priority for untagged frames: 0
Override vlan tag priority: FALSE
Voice VLAN: none
Appliance trust: none
SWITCH-B#

E agora, podemos ver que o SWITCH-B está de volta na rede, pela VLAN30!

SWITCH-B#ping 182.168.30.20               

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 182.168.30.20, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/13/24 ms
SWITCH-B#

Por enquanto é só. E segue aqui a topologia, pronta para rodar no GNS3! Só edite o arquivo .net de acordo para apontar para o IOS e o arquivo de confguração na sua máquina. Have fun!

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ó!