Upgrading the software on Juniper EX switch.

(First post on english) This may be something similar on other platforms (such as SRX firewalls and other JunOS-based devices). First, we need the new firmware available on Juniper site on an USB stick. After the new software is copied on the USB, insert the stick on USB port on the EX switch, mount and install the new software. After the software loading is complete, reboot and verify the newer version installed and running. Below:

Mounting the USB stick and verify the content inside:

root@:LC:0% mount_msdosfs /dev/da1s1 /mnt

root@:LC:0% ls /mnt/

$RECYCLE.BIN

jinstall-ex-2200-12.3R10.2-domestic-signed.tgz

root@:LC:0%

Now jump to cli and run:

>request system software add /mnt/jinstall-ex-2200-12.3R10.2-domestic-signed.tgz 

Wait while it is working...  It will show the following after the proccessing:

NOTICE: Validating configuration against incoming-package.tgz.

NOTICE: Use the 'no-validate' option to skip this if desired.

WARNING: A reboot is required to install the software

WARNING:     Use the 'request system reboot' command immediately

 Then...

root> request system reboot

Reboot the system ? [yes,no] (no) yes

Shutdown NOW!

[pid 1464]

root>

*** FINAL System shutdown message from root@ ***

System going down IMMEDIATELY

And bla bla bla... Wait until get device back to life again and check if the newer firmware is installed. The expected version should be 12.3R10.2:

root> show version

fpc0: 

--------------------------------------------------------------------------

Model: ex2200-c-12t-2g

JUNOS Base OS boot [12.3R10.2]

JUNOS Base OS Software Suite [12.3R10.2]

JUNOS Kernel Software Suite [12.3R10.2]

JUNOS Crypto Software Suite [12.3R10.2]

JUNOS Online Documentation [12.3R10.2]

JUNOS Enterprise Software Suite [12.3R10.2]

JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R10.2]

JUNOS Routing Software Suite [12.3R10.2]

JUNOS Web Management [12.3R10.2]

JUNOS FIPS mode utilities [12.3R10.2]

{master:0}

root>

That's it. You have the new software version on your device :)

Fazendo a merda de VMWare Player 3.1.6 funcionar no Ubuntu 12.04

Depois de tanto tempo sem sucesso, finalmente consegui funcionar o VMWare Player (versão 3.1.6) no meu paredão (Lenovo T60 - Se para celular é um tijolo, este laptop é uma parede, grande e pesado comparado com os laptops de hoje em dia - daí o nome). É só seguir os passos abaixo.

Instale o bundle VMware-Player-3.1.6-744570.i386.bundle que com algum esforço pode ser achado no site da própria VMWare (NÃO RODE o VMWare ainda, tenha paciência e siga os passos abaixo);
Baixe o seguinte patch, disponivel em http://weltall.heliohost.org/wordpress/wp-content/uploads/2012/04/vmware716fixlinux340.tar.bz2
Descompacte o .tar (tar -xf vmware716fixlinux340.tar.bz2) e rode o patch dentro da pasta extraída, desta forma: sudo ./patch-modules_3.4.0.sh
Depois disso, vá até o diretório /usr/lib/vmware/modules/source e descompacte o arquivo vmblock.tar (sudo tar -xf vmblock.tar)
Lá dentro, você terá que editar o arquivo fylesystem.c, que fica dentro do diretório extraído (sudo vi vmblock-only/linux/filesystem.c)

E de lá, comente a seguinte linha,

rootDentry = d_make_root(rootInode);

de modo que fique assim:

/* rootDentry = d_make_root(rootInode); */

E adicione logo abaixo isso:

#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 4, 0)
rootDentry = d_alloc_root(rootInode);
#else
rootDentry = d_make_root(rootInode);
#endif

Depois só salvar o arquivo, e executar o seguinte comando, para enfiar o arquivo filesystem.c de novo no vmblock.tar:

sudo tar --append --file=vmblock.tar vmblock-only/linux/filesystem.c

Agora teste rodando o VMWare e enjoy!! Aqui funcionou pelo menos!

Dica retirada do site: http://blog.errorok.com/2012/07/07/262/, na seção de comments!

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

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

Os modelos OSI e TCP/IP

Usamos camadas em redes para a divisão do problema. Com essa divisão, podemos analizar cada aspecto de uma rede, tanto na hora de planejar quanto na hora de isolar um problema até a sua solução. Cada camada descreve uma tecnologia e conceitos que serão apresentados durante uma carreira em redes.

Antigamente, as redes eram "presas" a padrões definidos por diferentes fabricantes, ou seja, se uma rede rodava tecnologia de um fabricante, logo a interconexão com uma outra rede, de outro fabricante não seria possível. A partir daí surgiu a necessiadde de padronizar as tecnologias para que vários produtos de diferentes fabricantes abrissem a possibilidade de várias redes comunicarem entre si, independente de fabrinate, sistema operacional, etc etc

Os benefícios de criar modelos em camadas são:

• Reduzir a complexidade;
• Definir padrões;
• Facilitar o entendimento;
• Promover um rápido desenvolvimento de produtos;
• Facilitar a engenharia modular;

O modelo OSI

Datando na década de 70, o modelo OSI começou a ser definido. Contudo, mais tarde, o padrão para as comunicações foi mudado para o TCP/IP, ficando o modelo OSI apenas para referência, tanto para estudos quanto para o desenvolvimento de produtos/tecnologias.

Uma dica que eu peguei para decorar as camadas, principalmente do modelo OSI, foi simplesmente decorar as iniciais de cada camada em sequência, ficando uma pronúncia assim: AASTRÉF. Depois fui procurando lembrar o que cada letra significava, junto com a sua função do modelo OSI.

• Aplicação: É a camada mais próxima do usuário. Nela basicamente encontramos os nossos aplicativos de email, web browser, instant messaging, tranferência de arquivos, etc. Também encontramos os protocolos os quais cada tipo de aplicação depende para o seu funcionamento, como o HTTP para web, SMTP/POP/IMAP para o email, 23 para o Telnet, 22 para o SSH...
• Apresentação: É onde são definidos os formatos das informações. Exemplo, um arquivo mp3 deverá ser aberto por um player multimídia, enquanto um arquivo PDF pode ser aberto pelo Adobe Reader, e assim por diante. Esta camada também cuida de aspectos de criptografia.
• Sessão: Estabelece e mantém fluxos em uma comunicação.
• Transporte: Fornece serviços como estabelecimeto/fechamento de conexão, controle de fluxo, recuperação de erros e segmentação de grandes quantidades de dados em partes menores para a transmissão. Essa camada cuida da confiabilidade da mensagem, como podemos ver em cada serviço oferecidao por ela. É onde vemos também os protocolos famosos TCP e UDP.
• Rede: É onde temos o endereçamento lógico, a decisão de roteamento e o encaminhamento dos pacotes. É onde encontramos o protocolo IP e os roteadores.
• Enlace: Temos o enderaçamento lógico (MAC address) também define o acesso ao meio, além de fazer os dados em formato de quadros para a transmissão no meio. Também define meios para reconhecer erros de transmissão.
• Física: É onde encontramos as propriedades físicas de cada meio, como óptico, cabos conectores e a transmissão de bits. 

O modelo TCP/IP

O modelo TCP/IP foi o sucessor do modelo OSI devido a sua popularidade atualmente é utilizado como modelo de protocolo. O modelo TCP/IP têm quatro camadas. Comparando com o modelo OSI, a camada de aplicação do modelo TCP/IP engloba as três últimas camadas, enquanto a camada de acesso á rede do modelo TCP/IP engloba a camada física e de enlace do modelo OSI, deixando somente as camadas de rede e transporte parecidas com o modelo OSI.

Abaixo, segue uma comparação entre as camadas do modelo OSI e do TCP/IP:

Encapsulamento

O processo para o envio e recepção de dados em rede é camado de encapsulamento. Conforme um usuário envia uma mensagem via IM ou email, esses dados (PDUs - Protocol Data Units) irão descer as camadas até chegar na rede, onde serão enviados ao destino. Chegando ao destino, esta mensagem é "remontada" (desencapsulada) até chegar na camada de aplicação, onde temos um outro usuário. Para cada camada, esses dados tem um nome e um tipo de informação específica, como endereço IP de origem, destino, portas TCP/UDP, quadros, etc...

O processo de encapsulamento/desencapsulamento

Cada PDU tem um tipo específico de informação. No caso retratado na figura abaixo, os dados são criados e logo são encapsulados em um segmento para o transporte. Cada segmento contém informações como número de porta TCP/UDP de origem/destino. Este segmento logo é envolvido em um pacote, onde contém as informações de endereçamento IP de origem/destino que será encaminhado pela rede. Após isso, o pacote é encapsulado em um quadro (Camada de enlace), onde será entregue ao meio, em forma de bits!

Quando a mensagem chega no destino, cada camada é responsável por desencapsular a mensagem até a camada de aplicação, fazendo com que os dados sejam legíveis ao nosso olhar.

Até o próximo post!

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!