root@blog:/# chmod o+r *

Leia as partes anteriores desse curso antes de prosseguir

Galera, serei breve! Primeiro desculpa ai pela demora!!! Mas realmente esse aqui além de ter dado trabalho tá ficando maior do que eu imaginei!!! E as coisas no meu trabalho tão feias então quase não tive tempo de escrever! E essas imagens então.... Mas vamos ao que interessa!!!

Camada 2 - Enlace de Dados (Parte 2)

Um pequeno review

No último post falamos do quadro (Frame) e seus campos, endereçamento MAC e controle de acesso ao meio (CSMA/CD). Agora nos vamos ver a utilidade desses conceitos.

Primeiramente vamos fazer uma abstração para compreender melhor o que seria um quadro, pra que precisamos desses campos e porque ter um controle de acesso ao meio.

Vamos imaginar que os computadores são pessoas e a rede é uma sala. Nessa sala todas as pessoas podem se comunicar apenas falando. Mas cada fala tem uma forma, uma língua (protocolo). Essa língua é definida por palavras (padrões). Dessa forma, se colocarmos um japonês nessa sala, só com brasileiros (considerando que nenhum assiste anime ou fez intercâmbio no Japão) o japonês não conseguirá se comunicar com ninguém, pois ele não “fala o mesmo protocolo”. Inclusive esse “fala” é um jargão muito comum em redes: “esse roteador fala OSPF??”. Voltando ao escopo. Todos nessa sala podem se comunicar através da fala, e como sabemos que a fala são ondas sonoras que se propagam pelo ar. Se comparado a redes, o ar é o meio de transmissão (cabo ethernet) e as ondas sonoras são os pulsos eletro-magnéticos gerados pelas interfaces ethernet. As ondas sonoras chegam até nossos ouvidos (interface) que, através da pressão sofrida pelas ondas gera uma oscilação dos tímpanos, “decodifica” essas ondas. Nossos ouvidos funcionam como interfaces ethernet que decodificam os impulsos eletromagnéticos do meio em sinais binários (uns e zeros).

Agora, o que acontece se todos falarem ao mesmo tempo? Ninguém se entende certo?! Por isso temos o controle de acesso ao meio. Quando alguém fala, todos os outros se calam. Como isso é feito? Antes de falar você tem que ouvir pra saber se alguém está falando (conforme definido pelo algoritmo CSMA/CD) e em caso positivo espera a pessoa terminar. Vamos considerar que a pessoa que quer falar é o Irado (para quem não conhece aqui tá o perfil dele: Irado). Ele primeiro ouve o meio e se estiver em silêncio, ele poderá falar. Mas ao mesmo tempo em que ele fala, ele ouve, pois alguém pode começar a falar ao mesmo tempo que ele, ocorrendo assim uma colisão. O que acontece se alguém fala ao mesmo tempo que o Irado? Ele age como um cavalheiro e avisa seus companheiros com um sonoro: “Eu to falando p***a!!!”. Esse sinal de aviso seria o sinal de JAM que tem como objetivo evitar que as pessoas continuem a falar. Enquanto isso, a pessoa que falou ao mesmo tempo que o Irado estará se recuperando do susto (tempo aleatório na ponta A) enquanto o Irado conta até 10 (tempo aleatório na ponta B) pra se acalmar e não partir a cara desse usuário que teima em não usar o google. Depois de contar até 10 o Irado tenta falar novamente, dessa vez (com razão) ninguém tenta falar ao mesmo tempo que ele!

Obs: Irado isso é só uma brincadeira OK?!

Outro padrão na nossa fala é sempre se dirigir a pessoa com quem estamos falando: “Fulano, você já atualizou seu kernel hoje?”. Dessa forma endereçamos à pessoa (fulano=Endereço MAC) a mensagem desejada. Geralmente, depois de falar o nome da pessoa esperamos alguns segundos antes de falar o restante da frase. Isso é para dar tempo da pessoa direcionar sua atenção à nossa pergunta. Se não esperarmos, muito provavelmente ouviremos um “hum?!” ou “oq?!”. Isso é porque não esperamos a pessoa se “sincronizar” à nossa conversa, função dos campos Preâmbulo e SFD do quadro. Por sorte quando conversamos com alguém não precisamos informar o tamanho da frase que falamos e nem que somos nós que estamos falando. Mas essas funções são substituídas pela visão da pessoa, reconhecendo a origem e vendo que não estamos mais falando, indicando que terminamos de transmitir (o campo comprimento tem o objetivo de prever o fim do quadro). Os dados são nossa pergunta, “você já atualizou seu kernel hoje”. O FCS tem como objetivo garantir que o que a pessoa ouviu foi o que enviamos. Esse função é exercida por aquela perguntinha chata que muitas vezes ouvimos como resposta de nossas perguntas: “você me perguntou se eu já atualizei meu kernel hoje?”. Como em redes podemos conversar com uma única pessoa, com todas as pessoas em um segmento de rede ou com um grupo definido. “Segmento de rede?“ calma, veremos isso hoje!

Ao falar com uma única pessoa, temos uma comunicação unicast: “fulano, você já atualizou seu kernel hoje?”. Quando falamos com um grupo de pessoas temos um multicast: “fulano e sicrano, vocês já atualizaram o kernel hoje?”. Quando falamos com todos ao mesmo tempo temos um broadcast: “Galera, vocês já atualizaram o kernel hoje”. Sempre que falamos “galera” todo mundo sabe que todos devem ouvir. Esse é o endereços de broadcast.

Outra abstração muito utilziada para ensinar é umaginar as redes como os correios. Você antes de mandar uma carta, escreve o conteúdo em um papel põe no envelope e envia a carta. O envelope seria o cabeçalho/trailer.

Com isso revisamos tudo o que vimos anteriormente, só que de uma forma subjetiva. Agora vamos para conceitos novos!


Segmentos de Rede

Segmentos de rede são trechos de uma rede. Podemos ter Segmentos em camada 2 ou segmentos em camada 3. Isso vai depender de com que equipamento é feita a segmentação.
Vamos ver a seguinte imagem:

http://under-linux.org/members/magnu...egmentacao.gif

Essa imagem tem 3 partes. Primeiro temos duas redes totalmentes segmentadas, costumamos dizer que são redes segregadas. Chamamos a rede da esquerda de Segmento A e a de direita de Segmento B. Como podemos ligar esses dois segmentos de rede? De diversas formas. Nas imagens apresentei 2 formas: com um HUB ou Repetidor e com uma Bridge ou Switche.

Com um HUB: Ao utilziar o HUB nós estendemos os segmentos de rede tornando ambos os segmentos (A e B) em um mesmo segmento. Isso é devido ao fato que um HUB é BURRO! Não, eu não to brincando não! Costumamos dizer que um hub é burro porque ele não tem "inteligência", ou seja, ele não toma decisões. Por isso ele une os dois segmentos. Um HUB funciona como um barramento, qualquer dado que você enviar nele todos (que esteja conectados nele) podem "ouvir" o tráfego e também ele permite a ocorrência de colisões.

Com um Switch: Ao utilizar o switch nós não unimos a rede, nos a interligamos. Teremos dois segmentos de reme na camada 2. Isso será melhor compreendido quando vermos o funcionamento de uma bridge/switch. O que interessa é que, em condições ótimas, os hosts do segmento A não escutarão as conversas do segmento B e não haverá colisões entre os segmentos. Muita atenção aqui. A rede não está livre de colisões no geral porque temos os HUS em cada segmento, mas ENTRE os segmentos pode-se dizer que não haverá colisões.

Sempre que expandimos uma rede podemos aumentar, manter ou diminuir o tamanho do segmento, tudo depende de que ativos utilizamos. Conforme vão sendo adicionados nós a um segmento físico Ethernet, vai aumentando a competição pelos meios. E quantos mais nós adicionamos mais perdemos em termos de throughput. Throughput é a velocidade real de uma rede. Pode-se dizer que uma rede de 100Mbps com 4 hosts tem um throughput pouco inferior a 25Mbps, considerando que todos falem ao mesmo tempo. Isso é porque os 100Mbps serão divididos para os 4 hosts. “E porque um pouco inferior?!”. Porque, como vimos, quando enviamos dados de um host para outro não enviamos apenas os dados enviamos cabeçalhos e dados de controle, isso se chama overhead. O overhead varia de acordo com a pilha de protocolos utilizados. Agora vamos às bridges...


Bridge

A Ethernet compartilhada funciona extremamente bem sob condições ideais. Quando o número de dispositivos que tentam acessar a rede é baixo, o número de colisões permanece bem dentro dos limites aceitáveis. No entanto, quando aumenta o número de usuários na rede, o aumento do número de colisões pode causar um desempenho inaceitavelmente baixo. O uso de bridges foi elaborado para ajudar a amenizar os problemas de desempenho que surgiram devido ao aumento das colisões. Uma das funções da bridge é a segmentação do domínio de colisão. Pode-se dizer que o domínio de colisão é a mesma coisa que segmento de camada 2.

A bridge é um dispositivo de camada dois que possui duas interfaces suas principais funções são a segmentação de tráfego em camada 2, isto é, a bridge encaminha ou descarta os quadros baseados nas entradas da tabela MAC.

O que é segmentar. Segmentar é separar. Então ao segmentar uma rede, nos a separamos. Separamos com base no que?! Como disse segmentação de camada 2. Logo separamos com base na camada 2. Ou seja, com base no endereço MAC. Mas se você se recorda eu havia dito que o endereço MAC é único para todas as interfaces e ela possui um início baseado no fabricante. Com o endereçamento MAC não conseguimos criar grupos, sub-grupos ou redes, por isso dizemos que o MAC é um endereçamento linear. Então o único jeito é criar uma tabela de endereços MAC dinamicamente na memória da bridge. Todas as decisões feitas por uma bridge são baseadas no na tabela MAC e no endereço MAC de destino do pacote e não afetam o endereçamento lógico ou da Camada rede (apenas guarde isso, será útil futuramente). Assim, uma bridge divide um domínio de colisão, mas não tem efeito nenhum no domínio de broadcast. “Opa, domínio de colisão e domínio de broadcast?!?!”. Ok... Definição formal:

Domínio de colisão: É um segmento de rede (cabos e ativos) em que um pacote pode trafegar e colidir.
Domínio de broadcast: É um segmento de rede (cabos e ativos) em que um host pode se comunicar com outro sem a necessidade de um dispositivo de camada 3.


Bridging

Para entendemos melhor esses conceitos de domínios temos que entender como a bridge funciona. Em suma, quando uma bridge recebe um pacote ela consulta a tabela MAC procurando uma ocorrência do MAC de origem. Ao encontrar, ele sabe se deve ou não encaminhar esse pacote para a outra interface. Caso ele não encontra ele permite a passagem. Pode-se dizer que a bridge é um “firewall de camada 2” que cria suas regras dinamicamente. Abaixo uma animação de como a bridge funciona:

http://under-linux.org/members/magnu...-switching.gif

O cenário é simples:

• Dois segmentos de rede interligados por uma bridge;
• Em cada segmento tem um Hub que, como sabemos, funciona como um barramento, repetindo o pacote recebido por todas as suas portas;
• Temos 6 hosts com os endereços MACs escritos acima deles;
• A bridge possui duas interfaces eth1 e eth2: A eth1 se conecta ao segmento da esquerda enquanto a eth2 se conecta ao segmento da direita.

Algumas “legendas”:

• Quando os “cabos de rede” ficam vermelhos eles indicam que o pacote passa por todos esses cabos.
• O envelope que aparece em baixo é o quadro de camada dois com os campos de MAC de origem (SRC) e MAC de destino (DST).

Passo 1
O host de MAC AAA quer se comunicar com o host BBB (não é BigBrother!!!). Ele monta um quadro com os dados de cabeçalho/trailer e envia o quadro pelo meio físico. Como ele está conectado a um HUB, todos os outros hosts conectados a esse HUB "recebem" esse pacote. Porque "recebem" entre aspas? Porque todos os hosts (com excessão do BBB e da Bridge) recebem mas não precessam, a pilha TCP/IP descarta o quadro porque o MAC de destino não é o deles. É aquela analogia da sala com várias pessoas feita anteriormente apesar de todos te ouvirem ninguém dá atenção pra sua conversa porque você não os chamou pelo nome.

Como o quadro é repetido para todos ele chega até o destino (BBB), mas antes vamos ver o que está acontecendo com a Bridge...

Ainda no passo 1, a Bridge recebe o quadro na interface eth1, mas como ela não é um host ela não tem o mesmo comportamente que eles (descartar o quadro). A Bridge faz mais ou menos assim:

Opa, chegou um quadro!! De onde veio? Do AAA pela eth1. Hum... isso pode ser útil, vou anotar! - Ela pega uma prancheta com uma tabela que mais parece uma lista de convidados a adiciona o MAC AAA na primeira coluna e a porta eth1 na segunda coluna - Pra onde esse quadro vai? Hum, é pro BBB... - Ela olha de novo para a tabela e comenta - Hum... Esse cara não tá na minha lsita.. mas como vovó dizia, antes pecar pelo excesso que pela falta! Vou deixar esse quadro passar!

Nisso o pacote passsa o quadro para o segmento da direita e o burro do HUB repassa pra todo mundo. Porém todos nesse segmento descartam o pacote...

-Pausa-

"Porque que a Bridge só anotou o MAC AAA??" Essa é a pergunta mais importante que você pode ser fazer quando estuda switching/bridging! Pelo simples fato dela só ter certeza de onde vem o pacote e não poder afirmar com certeza pra onde ele vai!

-Continuando-

De volta ao BBB: "Chegou um quadro pra mim! Vou responder...". E o quadro de retorno é enviado para o HUB tagarela que repete pra todo mundo, inclusive a bridge. A bridge ao receber o quadro verifica em sua tabela MAC: "Epa, outro quadro. Quam mandou?! BBB?? Esse eu não tenho, vou anotar... Epa mas pera ai!!! esse quadro que entrou pela eth1 é pro host AAA! Mas que p***a, o host AAA ta ai na eth1, quem foi o burro que mandou isso?! Não vai passar...". Assim a bridge impede o envio do quadro para o segmento da esquerda.

Mas mesmo com esse "bloqueio" o quadro chega com sucesso ao AAA, pois ele nunca deveria ter ido pra bridge.

Esse é o processo de aprendizagem da Bridge. Ela se baseia sempre no campo MAC de origem para descartar os próximos quadros. Mas na dúvida ela deixa o pacote passar. Com o passar do tepo ela vai ficando mais eficiente. E é isso que veremos nos próximos passos.
Obs: Acho que deu pra entender ne?! Vou ser mais breve!!

Passo 2
Agora a comunicação é de AAA pra FFF. Ao enviar o quadro o HUB repete e a bridge recebe. A bridge olha a origem e ve que já conhece AAA, então ela analisa o destino e vê que não conhece FFF, então deixa o quadro passar.

Do outro lado o HUB repete o pacote para todos e o FFF recebe o quadro e envia a resposta que é novamente repassada pelo HUB até chegar na Bridge. Ao receber, a bridge já anota o FFF como estando na eth2 e verifica que o destino, AAA, está d outro lado (direito), então ela encaminha o quadro.

Passo 3
Agora, um quadro de DDD pra FFF. O quadro é enviado e repetido até chegar na bridge (e no próprio FFF). A bridge ao receber o quadro anota o MAC DDD vinculado à eth2 e depois descarta o pacote, uma vez que FFF, de a cordo com a tabela está em eth2.

O FFF envia uma resposta, o HUB repete e a Bridge recebe, assim como o DDD. A bridge verifica o destino, DDD, e não permite a passagem para o outro lado pois DDD está na eth2.

Dessa forma, nessa "conversa" do segmento da esquerda não foi "interrompida" por um quadro desnecessário.

Vocês devem estar pensando: "Ah, que besteira, é só um quadro de vez em quando! Não mata ninguém!". Vamos imaginar dois grupos (grupo 1 e grupo 2) de amigos e a conversa rolando solta. Sempre no grupo de amigos tem um chato, logo temos o chato 1 e o chato 2. Então quando alguém quer conversar mandar o chato ir ver se o fulano ta no grupo 2. Pouco depois do chato 1 sair vem o chato 2 perguntar se sicrano ta ai! Atrapalhou a conversa de todo mundo certo?? "Ah, mas nem tanto!!" OK, imagine agora 50 grupos de amigos. Quando alguém do grupo 1 fala, o chato 1 tem que ir nos 50 grupos procurar o fulano. Não só isso, os outros 49 chatos virão incomodar seu grupo de amigos. E ai?! Se preocupou agora?! Pois é...

Esse processo de permitir ou não a passagem de quadros com base no endereço MAC é chamado de switching/bridging ou comutação.


Referências

* Cisco CCNA - Guia de certificação do Exame, 3a Edição
Wendell Odom

* Redes de Computadores, 4a Edição
Andrew S. Tanenbaum,

* Conteúdo Cisco NetAcad, versão 3.1.1

Fechamento

Ok... vamos parar por aqui!!!! Ufa... Na terceira parte vamos ver o switch e suas funções mais importantes como VLANs, trunks, tipos de comutação e talvez spanning tree e configuração de port-security. Porque talvez??? Porque spanning tree é um pouco complexo e vai tornar o post longo!! Fica pra uma parte de configuração avançada de switches! Ainda temos muit chão pela frente!!!

Pessoal, queria um feedback! Como ta indo??? Acham que o texto ta chato, tenho que utilizar menos compadraçoes e ser mais técnico?? O que vocês tão achando?? Ta faltando alguma coisa?? Ta sobrando alguma coisa?? Outra cosia, vocês preferem imagens estáticas ou essas animações?? Eu escolhi usar animação porque senão ia ter muita imagem! Me dá mais trabalho mas pelo menos coprime um pouco o post e vocês conseguem ver a "fato acontecendo"!

Valeu galera..
Até e apróxima e espero comentários, na parte 1 desse post só teve um comentário!
Acho que todo mundo desistiu ou ainda tão de resaca do ano novo!!