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!

Mudando configurações do teclado no CentOS

Como faço para mudar a configuração de teclado do CentOS?

No arquivo /etc/sysconfig/keyboard tem as configurações do layout do teclado. A linha KEYTABLE define o layout do teclado, como BR-ABNT2 ou US, enquanto a linha KEYBOARDTYPE define o tipo de teclado, se é um teclado normal (PC) ou SUN. No caso abaixo, o padrão do teclado está configurado para US e o tipo é PC (o mais comum...):

[root@wikidb ~]# cat /etc/sysconfig/keyboard
KEYBOARDTYPE="pc"
KEYTABLE="us"
[root@wikidb ~]#

Para mais informações, procure o arquivo /usr/share/doc/initscripts-/sysconfig.txt

Por enquanto é só!

Rodando VRRP no CentOS

Este post fala de como rodar o VRRP (RFC 2338) em Linux. Aqui é especialmente no CentOS, mas isso pode ser feito em qualquer outra distribuição Linux. É somente um ".tar.gz" e um make e já era. Para saber o propósito disso, imagine uma situação onde você quer redundância, tanto na parte de redes quanto em aplicações onde é necessário alta disponibilidade (Nas distros RHEL/CentOS, o VRRP é presente no Cluster Suite e para o LVS, para manter disponibilidade em ambientes de aplicativos em cluster...Corrija-me se precisar...). Com isso, podemos fazer com que um servidor web "tome conta" dos pedidos dos clientes enquanto um outro servidor está down ou para manter redundância de first-hop (Default Gateway) em uma rede. Segue uma topologia abaixo:

• O que acontece?

    Nesta topologia, um dos servidores ou gateways têm uma prioridade definida. O que tiver maior valor, será o master. Sendo o master, logo ele irá responder pelo endereço virtual (192.168.100.23), até que por algum motivo, ele fique "offline" e um backup assuma o posto. Isso é feito através de multicast com pacotes UDP no endereço 224.0.0.18. Depois que o master "cai", o backup percebe que não há mais mensagens do master e o backup acaba tornando-se o master.

• Instalando

    A instalação é bem simples. Em uma instalação mínima, vamos precisar dos pacotes make, gcc e do libpcap0-devel. Só instalar com o comando make e depois copiar o arquivo vrrpd em /usr/sbin (rodar como root) e o arquivo vrrpd.8 em /usr/share/man/man8/ do seu CentOS, para consultar no man pages ;). O mesmo pode ser feito na outra máquina, pois estamos falando de redundância aqui.

   [root@scooby ~]# tar  xvfz vrrpd-1.0.tar.gz 
   [root@scooby ~]# cd vrrpd-1.0
   [root@scooby ~]# make
   [root@scooby ~]# cp vrrpd /usr/sbin/
   [root@scooby ~]# cp vrrpd.8 /usr/share/man/man8/

• Pondo para funcionar

    A configuração dele é bem simples. Para que ele funcione depois do boot, podemos pôr a linha de comando no arquivo /etc/rc.local onde -i especifica a interface , -p a prioridade (O valor maior será o master), -v para o grupo, pode ser usado quando tiver redes diferentes e o endereço IP a seguir é o endereço IP virtual que irá ser usado para os requests ou como default gateway de uma rede. Para mais informações podemos ver pelo man pages do vrrpd. Você pode ver os logs gerados pelo daemon vrrpd em /var/log/messages. Podemos ver quando um nó se tornou master e quando ele se tornou backup, devido alguma mudança de prioridade.


Note que o host que tiver maior prioridade (opção -p) , será eleito como master:

[root@shaggy ~]# vrrpd -i eth0 -p 46 -v 1 192.168.100.23
Remove a stale pid file /var/run/vrrpd_eth0_1.pid
[root@shaggy ~]#
[root@shaggy ~]# tail -f /var/log/messages
[...]
May 25 23:32:04 shaggy vrrpd: vrrpd version 0.4 starting...
May 25 23:32:05 shaggy vrrpd: VRRP ID 1 on eth0: we are now a backup router.
May 25 23:32:12 shaggy kernel: eth0: Using EEPROM-set media 100baseTx-FDX.
May 25 23:32:12 shaggy vrrpd: VRRP ID 1 on eth0: 192.168.100.21 is down, we are now the master router.

E o com menor prioridade... O backup:

[root@scooby ~]# vrrpd -i eth0 -p 45 -v 1 192.168.100.23
Remove a stale pid file /var/run/vrrpd_eth0_1.pid
[root@scooby ~]#
[root@scooby ~]# tail -f /var/log/messages
[...]
May 25 23:23:34 scooby vrrpd: vrrpd version 0.4 starting...
May 25 23:23:34 scooby vrrpd: VRRP ID 1 on eth0: we are now a backup router.
May 25 23:23:48 scooby kernel: eth0: Using EEPROM-set media 100baseTx-FDX.
May 25 23:23:49 scooby vrrpd: VRRP ID 1 on eth0: we are now the master router.
May 25 23:24:58 scooby kernel: eth0: Using EEPROM-set media 100baseTx-FDX.
May 25 23:24:58 scooby vrrpd: VRRP ID 1 on eth0: 192.168.100.22 is up, we are now a backup router.

Por hoje é só...

Abraços!

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!

Como criar "plano de fundo" para os telefones IP 7940 da Cisco

Segue um pequeno "how-to" para criar algumas figuras que serão disponibilizadas para os telefones IP da Cisco. Note que aqui estou usando o modelo 7940, portanto, não será algo muito bonito de se ver e não será algo dinâmico via web/XML/etc, pois sou incompetente com linguagens de programação :)

Para isso, devemos baixar e instalar o SDK em http://developer.cisco.com/web/ipps e usar um aplicativo no DOS disponilizado no SDK, chamado gif2cip.exe, onde irá tranformar uma umagem GIF para um arquivo XML, com a extensão .cip, Note que a imagem GIF deverá ter a resolução de 133x65.

Para ser mais prático, salvaremos a figura em C:\CiscoIPServices\Tools, onde fica a ferramento onde iremos usar daqui a pouco. A figua original eu montei uma Kombi no site BussSelecta.com (http://www.busselecta.com/bus/) - Enjoy!

Essa será a kombi que irá aparecer no telefone...

Usando a ferramenta gif2cip, vamos converter a imagem kombi.gif para o arquivo kombi.cip:

    C:\CiscoIPServices\Tools Gif2Cip.exe kombi.gif kombi.cip


    Converting GIF kombi.gif to Cisco Image File kombi.cip
    Image is 116 by 65 pixels
    Image has a global color map with 256 colors. Mapping with nearest color match.
    Done!


    C:\CiscoIPServices\Tools

Quase pronto, podemos ver como ficou a imagem em uma outra ferramenta, no mesmo diretório, chamada ImageViewer.

Após isso, podemos pegar o arquivo .cip, renomear para .xml e disponilizar em um servidor web (Apache httpd, MS IIS, whatever...) e configurar no CallManager ou CallManager express uma URL (Aqui eu uso como idle URL em um CCME no dynamips...). Aqui segue o código XML (O blogger não está aceitando o código XML como deveria ser mostrado, daí esse link...)

 E agora, segue o trabalho final:

O telefone, sem a "tela de descanso..."

E agora, com a tela...

Por enquanto é só...Para saber mais sobre serviços XML para os telefones Cisco, aconselho dar uma olhada no site da Cisco, principalmente no primeiro link deste post... Tem bastante coisa lá... Abraços!