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!

Analogia - Como os dados fluem em uma rede - Carta vs. Email

O último post chegou a abordar sobre encapsulamento/desencapsulamento e um pouco sobre os modelos TCP/IP e OSI.

Hoje postarei uma analogia de como as coisas funcionam. Irei aprofundar um pouco mais e "viajar" para tentar explicar melhor e fixar o conhecimento com isso.

Os modelos OSI e TCP/IP podem ser usados para descrever como o tráfego flui em uma rede, como o processo de encapsulamento/desencapsulamento. Uma analogia que pode ser aplicada a isso seria compararmos o nosso email com uma carta escrita a mão, usando os correios como "roteadores". Os correios poderão ser usados em outros assuntos, como o processo de roteamento e como funciona o endereçamento da camada de rede e enlace, porém irei postar somente sobre o tráfego de ponta-a-ponta usando os modelos OSI e TCP/IP.

Como foi visto antes, cada camada possui uma PDU específica, cada qual tem um tipo de informação/dados e isso faz com que exista a comunicação host com hosts. Para relembrar, vamos á elas.

Comparando uma carta á mão com o email, temos menos passos para descrever esta comunicação, porém nos ajuda a "abstrair" o modelo em camadas com a analogia em questão.

Analogia - A carta

Simplesmente, quando escrevemos uma carta, estamos gerando dados de forma legível ao nosso olhar, onde logo colocaremos em um envelope com um número, seguido com endereço de origem/destino e logo depois iremos levar a carta para um correio ou depositar em uma urna ou coisa do tipo para que os correios encaminhem a carta até o destino. Quando a carta chega nos correios, eles irão analizar o endereço de quem enviou a carta e também para onde ela será enviada. Isso, em termos técnicos, significa que a carta foi escrita, usando dados, colocados em um envelope para o transporte e logo em seguida, colocamos nossos endereços de origem/destino para a carta sair para os correios até a antrega ao destino. Note que isso foi feito em passos diferentes, como seriam nas camadas do modelo OSI e TCP/IP. O processo quando chgar no destino é o inverso, onde a carta chega dos correios na caixa postal, o endereço da carta é checado, o envelope é aberto e logo em seguida, a carta é lida!

Resumindo, a nossa história ficará assim:

A camada de transporte do TCP/IP
 
Indo mais á frente, não recebemos apenas cartas. Imagine que ao invés de uma carta, estamos esperando uma encomenda muito grande. Supomos que esta encomenda foi "repartida" em peças para a entrega. Logo ao chegar no endereço de destino, a encomenda poderá ser "montada" aos poucos, ao invés de receber tudo de uma vez e depois não sobrar espaço para futuras cartas ou encomendas. Com isso, podemos usar um meio para vários tipos de tráfego, o que se chama multiplexação. Neste caso, cada envelope é numerado, indicando um número que será útil na hora da da montagem da encomenda. Caso um envelope faltar, a perda deste envelope será comunicado e logo um envelope com o mesmo conteúdo será enviado novamente ao destino!

Isso é apenas uma descrição grosseira da camada de transporte do modelo TCP/IP. A camada de transporte também oferece os seguintes serviços:

*Início/Término de conexões;
*Controle de fluxo (windowing);
*Mutiplexação usando portas;
*Recuperação de falhas;
*Segmentar e por os dados em ordem;   

Protocolos da camada de transporte - O TCP (Transport Control Protocol) e UDP (User Datagram Protocol)

O TCP é o protocolo mais popular da camada de transporte. É um protocolo onde garante a entrega dos dados, oferecendo as mesmas funcionalidades da camada de transporte, como segmentação, confiabilidade, multiplexação e início/término de conexões, daí o TCP ser um protocolo "orientado a conexões". A diferença entre o TCP e o UDP (User Datagram Protocol), um outro protocolo da camada de transporte, é que o UDP é mais leve, porém não oferece os campos que fornecem os mecanismos de confiabilidade presentes no protocolo TCP, fazendo com que o UDP dependa das camadas superiores para a retransmissão dos dados. Abaixo, podemos comparar através do datagrama de cada um as suas capacidades:

 O próximo post será sobre como o TCP comporta para garantir a entrega dos dados entre duas máquinas. Até lá!

Cabos cruzados (crossover) vs. cabos diretos (straight-through)

Para cabos UTP, usamos dois esquemas diferentes para conectar os equipamentos dentro de uma LAN. Isso também depende de que tipo de equipamentos serão conectados nas extremidades do cabo.

Quando e qual cabo usar?

Em redes locais, usamos bastante cabos UTP para conectar computadores, switches, roteadores e outros dispositivos que suportam o padrão Ethernet. Usamos dois padrões para cabeamento UTP, chamados EIA/TIA T568A e T568B. O que difere entre eles é como os pares de cobre são organizados. Este padrão foi criado para facilitar a identificação do cabo e manter uma documentação consistente em um ambiente de rede. Para cabos straight-through, podemos usar nas duas pontas o T568A ou o T568B. Enquanto para os cabos crossover, usamos o padrão T568A em uma ponta e o padrão T568B em outra. Abaixo seguem os padrões T568A e T568B.

Os pinos são vistos no conector RJ-45 com a "orelha" virada para trás.

Usamos o cabo direto quando conectamos dispostivos diferentes nas pontas, como um computador, um roteador ou uma impressora em um switch ou hub. Isso só não é válido quando connectarmos computadores em roteadores (lembrem-se que um roteador é também um computador, mas projetado para a função de roteamento de pacotes!). Isso acontece pelo fato dos pinos 1 e 2 serem usados para transmitir (Tx) e os pinos 3 e 6, para receberem (Rx) os dados. Quando dispositivos diferentes são conectados, no caso de um computador em um switch, encontramos os pinos 1 e 2 (Tx) do computador diretamente conectados nos pinos 3 e 6 (Rx) do switch e vice-versa no outro sentido. Daí, não precisamos nos preocupar em usar cabos cruzados, pois temos comunicação direta entre Tx e Rx em ambas as pontas.

Usamos straight through quando for equipamentos diferentes...

Quando queremos conectar dispositivos iguais (switches, computadores, roteadores...), usamos o cabo crossover. Isso de deve ao fato dos pares Rx e Tx estarem na mesma posição nas portas de cada equipamento. Imagine você em uma ligação de telefone em que a pessoa do outro lado está falando onde era para escutar. Tanto em uma redes como na vida real, a comunicação não será das melhores ou simplesmente não irá funcionar de jeito nenhum! Com o cabo crossover, os pares 1 e 2 (Transmit - Tx, não esqueça disso!) em uma ponta são trocados com os pares 3 e 6 (Receive - Rx) respectivamente, criando assim o link entre os dois equipamentos. Agora, comparando na vida real, poderiamos entender o que a outra pessoa está falando no telefone e em redes, podemos ver que um link está ativo entre dois switches, roteadores e até em computadores!

... E quando os equipamentois conectados forem iguais entre si, usamos cabos crossover para interconectá-los:

Resumidamente, se for para fazer o cabo, seguindo os padrões T568A e T568B, ficaremos com o seguinte esquema de cores:

Por enquanto é só. Até o próximo post!

Topologia para brincar com Frame Relay! - Ponto-a-ponto

Segue uma topologia para brincar com Frame Relay!

Aqui usei dois PVCs ponto-a-ponto, emulando 3 roteadores 3745. O Roteador Campinas interliga Ubatuba e Trindade em circuitos diferentes (1:110 -> 2:101; 1:220 -> 3:202), sendo que cada um deles têm uma subrede diferente (192.168.XXX.0 /30, onde XXX reflete o número do DLCI de cada PVC na ponta do roteador Campinas).

Segue abaixo as configurações das interfaces:

• Campinas:

Campinas#show run interface serial1/0
Building configuration...

Current configuration : 93 bytes
!
interface Serial1/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
end

Campinas#
Campinas#show run interface serial1/0.110
Building configuration...

Current configuration : 156 bytes
!
interface Serial1/0.110 point-to-point
 ip address 192.168.110.1 255.255.255.252
 frame-relay interface-dlci 110
end

Campinas#
Campinas#show run interface serial1/0.220
Building configuration...

Current configuration : 162 bytes
!
interface Serial1/0.220 point-to-point
 ip address 192.168.220.1 255.255.255.252
 frame-relay interface-dlci 220 CISCO
end

Campinas#
Campinas#show frame-relay pvc

PVC Statistics for interface Serial1/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 110, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0.110

  input pkts 18            output pkts 46           in bytes 1960
  out bytes 12104          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 31        out bcast bytes 10544
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:30:00, last time pvc status changed 00:29:00

DLCI = 220, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0.220

  input pkts 11            output pkts 38           in bytes 1074
  out bytes 10588          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 28        out bcast bytes 9548
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:30:02, last time pvc status changed 00:29:01
Campinas#

• Ubatuba:

Ubatuba#sh run interface serial 1/0
Building configuration...

Current configuration : 245 bytes
!
interface Serial1/0
 ip address 192.168.110.2 255.255.255.252
 encapsulation frame-relay
 no snmp trap link-status
 serial restart-delay 0
 frame-relay interface-dlci 101
end

Ubatuba#
Ubatuba#
Ubatuba#show frame-relay pvc

PVC Statistics for interface Serial1/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

  input pkts 37            output pkts 17           in bytes 8448
  out bytes 1628           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 2         out bcast bytes 68
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:19:27, last time pvc status changed 00:18:23
Ubatuba#

•  Trindade: 

Trindade#sh run interface serial 1/0
Building configuration...

Current configuration : 146 bytes
!
interface Serial1/0
 ip address 192.168.220.2 255.255.255.252
 encapsulation frame-relay
 no snmp trap link-status
 serial restart-delay 0
end

Trindade#
Trindade#show frame-relay pvc

PVC Statistics for interface Serial1/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 202, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

  input pkts 22            output pkts 11           in bytes 4825
  out bytes 1074           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 1         out bcast bytes 34
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:10:37, last time pvc status changed 00:09:37
Trindade#

 Para quem estiver interessado em fazer algumas modificações ou correr riscos, o arquivo .net do GNS3 está aqui.

Abraços!