255.255.255.0: A matemática das máscaras de rede

Autor: Elgio Schlemer <elgio.schlemer at gmail.com>

Introdução

Mesmo aqueles que não são familiarizados com redes, número IP, já se depararam com este item de configuração: máscara de rede.

Sem dúvida que a mais usada, mais conhecida, é a máscara 255.255.255.0,
tanto que muitos nem se quer sabem que ela pode ser outro valor e não
apenas este. Poucos também sabem o que este número "mágico" significa,
o que ele representa e quão importante ele é para uma rede. E mais, o
quão desastroso pode ser se ele estiver errado, não em conformidade com
a real configuração de uma rede local.

Neste artigo procuro descrever tecnicamente o princípio
existente na composição da máscara de rede, o que ele representa e para
que serve. Faço um comparativo com o antigo roteamento baseado em
Classes de IP e porque isto ele abandonado.

Se você é do tipo que sente arrepios quando ouve falar de
operações bit a bit, como AND, OR ou XOR, prepare-se: as máscaras de
rede tem tudo a ver com escovação de bits. Leitura não recomendada para
alérgicos binários.

Tudo é uma questão de roteamento

Você sabia que um número IP não serve para realizar a comunicação entre uma máquina e outra?

Esta frase soa estranha, mas vou explicar o seu contexto:
sempre uma máquina conversa com outra ela usa o endereço de enlace
dela. Sim, enlace (referência ao modelo TCP/IP de quatro camadas, não o
OSI)!

Considerando a rede Ethernet, com a atual Fast Ethernet
(100Mbps) como sua maior representante, os endereços de hardware das
placas de rede são constituídos de 48 bits (sendo que os primeiros 24
dizem qual o fabricante da placa de rede). É o número em HEXA que você
vê quando executa um ifconfig, algo como 00:50:56:C0:00:06. Claro que
todo mundo que já configurou um servidor DHCP sabe bem o que é este
número.

Pois bem, a comunicação é realizada colocando-se o endereço de
hardware do destino no pacote, determinando que este pacote deve ser
entregue a máquina cujo endereço de placa de rede é o
00:50:56:C0:00:06. O problema é que isto só funciona em rede local,
pois a origem precisa antecipadamente conhecer o MAC ADDRESS do destino
e para isto que serve o protocolo ARP (que não irei descrever aqui).

Mas e quando o meu destino não está na mesma rede que eu e não
posso colocar o MAC de destino no pacote? É aí que entra o que se chama
de roteamento IP.

Analisando o número IP do destino minha máquina verifica que precisa
repassá-lo ao gateway, pois o destino não é local. O gateway, por sua
vez, compara o Ip de destino com sua tabela de rotas para determinar
para onde o pacote vai agora, e assim sucessivamente até que o pacote
chegue na rede local do destino, onde finalmente o último gateway irá
enviar o pacote para o "MAC ADDRESS do destino". Cada etapa do
roteamento envolve o MAC address do gateway de saída (este artigo é uma
introdução e procura descrever apenas as máscaras e não as tarefas de
um roteador).

Costumo aplicar em aula a seguinte analogia: como o CEP dos
correios. Ele não serve para determinar a entrega, pois a carta será
entregue para a Rua e número de uma determinada cidade. Serve apenas
para roteamento, pois analisando o número sabe-se o que fazer com ele.
Se estou no RS e o CEP não começa com o dígito 9, então o destino não é
RS, pois "9" no início do CEP determina que é algum lugar no RS.

Logo, entendam o contexto quando digo que o número IP não
serve para que uma máquina se comunique com outra. Quero dizer que a
comunicação é sempre de endereço MAC para endereço MAC e que o número
IP serve para determinar o próximo passo de roteamento (esta descrição
está incompleta e focada ao objetivo deste artigo. Entender bem a
participação dos números IP em uma comunicação envolve compreender a
tarefa de cada uma das quatro camadas do modelo TCP/IP. Quem sabe em um
próximo artigo?).

Resumindo: IP serve para rotear.

Aí surge, evidentemente, a necessidade de que os números IPS
sejam organizados através de uma técnica determinística, que permita a
qualquer um saber onde está o destino ou pelo menos, para que lado
está. Como na analogia que fiz, o CEP tem esta função, pois se o CEP
começa com 9 é Rio Grande do Sul e os demais dígitos dão uma maior
precisão sobre a cidade, bairro e até a rua.

Com os números IPs da versão 4 (IPv4) é mais ou menos assim e a primeira organização de IPs foi a organização por classes.

Seu IP é Classe A, Classe B ou Classe C?

Na verdade isto já não importa mais para efeitos de roteamento, mas até 1993 era a forma usada para realizar roteamento IP.

Nesta técnica os ips foram catalogados em Classes, para
determinar o roteamento. O objetivo do roteamento por classes era
disponibilizar uma forma muito rápida (matematicamente) dos roteadores
calcularem o destino. Basicamente determinou-se que dos 32 bits de um
número IP, parte dele (alguns bits iniciais) diriam qual a rede de
destino e outra parte dele (bits finais) diriam qual o número do host
dentro desta rede. Se apenas 8 bits iniciais disserem qual rede é, um
roteador só precisa analisar estes 8 bits para determinar o destino e
não todos os 32. Sempre visando o menor custo, ainda mais em uma época
onde o hardware não é o que temos hoje!

A pergunta importante é: quantos bits dizem qual rede é e quantos bits dizem qual host? Nesta decisão é que entraram as classes:

Classe A: sempre que um número IP começar com 0, é classe A. Genericamente pode-se dizer que um classe A possui o formato:


0XXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Observe o quanto isto facilitava (não se usa mais ISTO,
lembre-se!) as operações de roteamento: se eu sou um roteador classe A
e o primeiro bit do IP que devo rotear NÃO FOR ZERO, pronto, pra que
olhar os demais bits se já sei que o destino não é aqui? (novamente o
CEP: pra que olhar os demais dígitos do CEP se o 9 me diz que é RS e eu
sou uma agência de correios de SP?)

Como o primeiro bit será sempre ZERO, isto obriga o primeiro
octeto do IP a ser 0XXXX XXXX, o que restringe as possibilidades deste
octeto a ser de 0 a 127. Por isto que popularmente se diz que um IP
Classe A é o que vai de 0.0.0.0 até 127.255.255.255. Mas isto no
popular, pois os roteadores não fazem if (if octeto UM maior que zero e
menor que 127, então é classe A), eles fazem operações bit a bit! Se
primeiro bit for ZERO, é um classe A.

Sendo um Classe A (primeiro bit em ZERO), os próximos SETE bits dizem qual é a rede e os demais qual o HOST dentro desta rede:


0RRRRRRR HHHHHHHH HHHHHHHH HHHHHHHH

Veja, a definição da classe determina a quantidade de bits para
rede. No caso de um classe A, tem-se sete bits para rede e 24 para
host. Quem adquiria uma faixa Classe A para si (grandes empresas) podia
suprir até 2^24 hosts, algo próximo de 16 milhões de máquinas. Coisa
para poucos, pois existiam apenas 127 redes deste tipo no mundo
(novamente, estou simplificando para não fugir do foco, embora os
números não sejam exatamente estes por conta de reservas de ips,
números de rede e broadcast).

Classe B: sempre que um número IP começar com 10,
é classe B e sendo desta classe, os próximos 14 bits é que dizem que
rede é, sobrando os últimos 16 para determinar qual a host:


10RRRRRR RRRRRRRR HHHHHHHH HHHHHHHH

Com 16 bits para host, cada rede poderia ter até 65536 hosts
(simplificando!!) e um total de 16384 redes classe B existem (2 elevado
na 14).

Classe C: sempre que um número IP começar com 110,
é classe C e sendo desta classe, os próximos 21 bits é que dizem que
rede é, sobrando os últimos 8 para determinar qual a host:


110RRRRR RRRRRRRR RRRRRRR HHHHHHHH

Com isto cada rede pode ter até 256 ips e muitas redes deste tipo existiram (em torno de 2 milhões).

Ainda existe o Classe D (começa com 1110) reservado para
tráfego multicast (ainda usado) e o Classe E (1111) reservado para uso
futuro. Como para uso normal, unicast, tem-se apenas o classe A, B e C,
o último ip válido ainda hoje é o que começa com 223 (224 já é classe
D).

Roteamento baseado em Classes de IP

OK, certo. Mas para que servia esta divisão por classes, que REPITO, não se usa mais?

Como o número de bits, que determinam o que é rede, variava, a
Classe determinava quantos bits o roteador deve avaliar. Observe que o
roteador precisa saber a rede de destino para determinar a quem ele
envia, assim como uma agência de correio precisa saber a cidade de
destino.

Assim, o roteador testava o primeiro bit, se for zero, Classe
A, isola os próximos sete bits e joga em sua tabela de rotas. Mas se os
primeiros bits fossem 10, então são os próximos 14 bits que devem ser
isolados e comparados com a tabela de rotas. Operações binárias
agilizam esta operação em muito.

Sem dúvida uma forma de roteamento muito otimizada, tanto que
foi ressuscitada no Ipv6 (a idéia, não o modelo de classes). Só que
esta técnica amenizou o trabalho dos roteadores que sem muito esforço
determinavam o que fazer com o pacote, mas trouxe um gravíssimo
problema: a falta de números IPs.

O fato é que uma faixa Classe C possibilita apenas 256 ips, o
que é pouco para a maioria das instituições que desejam entrar na
Internet. Já um classe A com seus 16 milhões de ips é muito. Logo a
preferida da torcida foi a classe B, que rapidamente esgotou-se.

Aliado a este fato, imagine uma instituição que tinha 300
máquinas para por na Internet. Um Classe C não lhe serve. Logo, ele
adquire um classe B (se ainda houver). Só que com suas míseras 300
máquinas e um classe B que pode ter 65536 máquinas, ele estaria
desperdiçando pouco mais de 65 mil endereços ips!!! Imagine uma empresa
que adquiriu um Classe A que permite 16 milhões de ips!

Não precisa ser muito esperto para perceber que isto
rapidamente gerou um caos, pois rapidamente esgotou-se os números de
ips disponíveis ao passo que se tinha um imenso e lastimável
desperdício dos mesmos, mas era o efeito colateral da classificação por
classes.

Algo precisou ser feito e a classificação CIDR reorganizou os ips e é nela que existem as tais máscaras de rede.

Classe CIDR

CIDR: Classless Inter-Domain Routing

Como o nome sugere, roteamento livre de classe. Adeus, bye bye
classes. Foi uma furada, um tiro no pé. Em 1993 este padrão substitui
as classes.

Lembre-se que o número IP versão 4 é dividido em duas partes:

  • alguns bits iniciais dizem qual rede é;
  • outros bits finais dizem qual a máquina dentro desta rede.

Antes a própria definição de Classe dizia quantos bits
era rede e quantos eram host. O que o CIDR fez foi libertar-se desta
restrição: não importa de qual classe o IP é, o número de bits de rede
não é fixo. Posso ter agora um IP "CLASSE A", mas usando não sete, mas
24 bits para rede e os demais 8 para host, como seria um classe C.

Uma sutil mudança, mas com impactos profundos: o roteador já
não sabe, através da análise do IP, quantos bits deve analisar para
determinar a rede de destino. Adeus otimização dos cálculos. Roteador
vai sofrer um pouco mais com cálculos mais onerosos. Ganha-se em um
lado, perde-se em outro.

A pergunta é: se agora o número de bits que determinam qual
rede sou não é fixo, como era no modelo por classes, como sei quantos
bits devo usar?

Resposta: não sei, preciso sempre ter esta informação. Neste
modelo cada máquina precisa saber que ip eu sou e deste meu IP quantos
bits são usados para rede e quantos para host.

Cada roteador igualmente tem em sua nova tabela de rotas a
informação de rede de destino, quantos bits devem ser usados para rede,
e para onde vai. Mais oneroso, como disse (e, claro, suscetível a
falhas).

No modelo CIDR a informação de quantos bits são usados para
rede é simplesmente representada colocando-se este número ao lado do
IP:

Meu IP: 10.1.0.5/24

O /24 determina que são usados os primeiros 24 bits para rede,
e que os últimos 8 (o que sobrou) são para host. Cada definição de uma
rede IP possui ainda dois números especiais, que não podem ser usados:

  • a definição do número da rede;
  • e a definição do número de broadcast.

Isto já era assim mesmo no modelo de classes, mas naquela época estes
números eram fixos, pois o número de bits para rede era amarrado a qual
classe ele pertencia. Agora não, agora estes dois números precisam ser
calculados!

Cálculo do número de rede e de broadcast

Define-se como número de rede o primeiro endereço da faixa e como
número de broadcast o último. Se tivermos, por exemplo, o IP
10.1.0.5/24 (24 bits para rede):

   (10)       (1)        (0)        (5)
0000 1010 0000 0001 0000 0000 0000 0101
<------ 24 bits para rede -----> <- HOST->

O número de rede seria 00001010 00000001 00000000 00000000, ou 10.1.0.0, primeiro IP que seria para host da seqüência.

O número de broadcast seria 0001010 00000001 00000000 11111111, ou 10.1.0.255, último número de host permitido.

Mas como uma máquina calcula este número?

Usando operações binárias, pois elas são rápidas e eficientes.
Para calcular o número da rede, faz-se um AND bit a bit do número IP
com os números destinados a rede em 1. Se um IP é /24, quer dizer que
devem ser usados 24 bits para rede, restando oito para host. Para
calcular a rede faz-se um AND com os primeiros 24 bits em 1 e os demais
em zero:

   (10)       (1)        (0)        (5)
0000 1010 0000 0001 0000 0000 0000 0101
1111 1111 1111 1111 1111 1111 0000 0000 (24 bits em 1)
0000 1010 0000 0001 0000 0000 0000 0000 (resposta do AND)

Ao realizar este AND bit a bit, chega-se ao número 10.1.0.0 (número da rede).

Agora observe esta fato: se eu fosse ler de forma decimal estes bits que usei para o AND, que número eu tenho?

1111 1111   1111 1111   1111 1111   0000 0000
(255) (255) (255) (0)

255.255.255.0 lhe soa mais familiar? Por isto o nome “máscara de
bits” pois é uma máscara que será usada em uma operação AND para
determinar qual a rede.

Para determinar qual é o meu endereço de broadcast, se faz um
OR bit a bit com a máscara complementada (invertida, números destinados
a rede em ZERO):

   (10)       (1)        (0)        (5)
0000 1010 0000 0001 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 1111 1111 (24 bits em 0)
0000 1010 0000 0001 0000 0000 1111 1111 (resposta do OR)

Sendo agora um OR, o resultado matemático disto será 10.1.0.255.

É isto que acontece nos bastidores, envolvendo a máscara para
determinar que rede sou e qual o meu endereço de broadcast. Uma máscara
equívoca pode significar o isolamento de uma máquina do resto do mundo,
pois ela pode não rotear pacotes corretamente, não usando o gateway
quando deveria, por exemplo.

Roteamento baseado em máscara de rede

Cada máquina sabe seu IP, sua máscara e o IP do gateway. A máquina
não sabe as máscaras e os ips de outras máquinas, apenas a sua. Logo,
ao necessitar comunicar-se com uma máquina cujo o IP é X.Y.K.Z a
máquina não tem como saber qual rede este IP é, mas tem como saber se é
a mesma rede sua. Isto é suficiente para ela saber se pode enviar
diretamente (mesma rede) ou se precisa acionar o gateway para jogar
para fora (eu, estando no RS, posso não saber onde é um CEP que começa
com "4", mas sei que não é RS, pois estou no RS e aqui ele começa com
"9". Basta para eu enviar para outra agência de correio).

Alguns exemplos:

Caso A: origem e destino estão na mesma rede. Maquina A com IP
10.1.0.5/25 deseja conversar com 10.1.0.120 (ela não sabe a máscara do
destino!!!).

Máquina A primeiro determina a sua rede aplicando um AND do
seu IP com sua máscara, sendo que ela agora é 255.255.255.128, pois um
/25 significa 25 bits em 1:

1111 1111   1111 1111   1111 1111   1000 0000
(255) (255) (255) (128)

Ela chega a conclusão que pertence a rede 10.1.0.0. Ela faz o mesmo com
o IP de destino, aplicando um AND do IP de destino COM A SUA MÁSCARA
(única que ela tem):

   (10)        (1)         (0)         (120)
0000 1010 0000 0001 0000 0000 0111 1000
1111 1111 1111 1111 1111 1111 1000 0000 (25 bits em 1)

Como resultado deste AND, chega-se ao cálculo de 10.1.0.0. Como o
número calculado para rede é o mesmo, a conclusão é que o destino está
aqui, local, basta realizar um ARP e endereçar diretamente o MAC do
destino. Nada de gateway.

Caso B: origem e destino não estão na mesma rede. Maquina A com
IP 10.1.0.5/25 deseja conversar com 10.1.0.129. Já sabemos que a rede
que a máquina A pertence é 10.1.0.0 (veja, pode não ser se a máquina A
estiver com a máscara errada!!!)

Ela faz o mesmo com o IP de destino, aplicando um AND do IP de destino COM A SUA MÁSCARA (única que ela tem):

   (10)        (1)         (0)         (129)
0000 1010 0000 0001 0000 0000 1000 0001
1111 1111 1111 1111 1111 1111 1000 0000 (25 bits em 1)
0000 1010 0000 0001 0000 0000 1000 0000 (RESULTADO AND)

Como resultado deste AND, chega-se ao cálculo de 10.1.0.128, que
não é mesma rede da máquina A. A conclusão é que o destino não está
aqui e preciso repassar o pacote para o gateway (o que o gateway faz
deixamos para um próximo artigo).

Se a máquina A estiver com a máscara errada (um /24 quando
deveria ser um /25) ela pode ficar isolada de parte da rede, por achar
que o destino é rede local quando não é (deveria ter usado o gateway).
Da mesma forma se ela é um /25 quando deveria ser um /24 poderá usar o
gateway quando não era necessário. A correta configuração de máscara é
extremamente importante.

Conclusão

Por envolver operações binárias e conceitos de redes, este artigo
pode não ter sido do interesse de muitos leitores. Mas tenho observado
nos fóruns que muita gente não sabe o que são máscaras de rede e se
perdem quando este conceito é empregado, por exemplo, em configurações
de firewall.

O que significa dizer que estou executando um DROP no IP 10.1.0.0/28?

# iptables -A FORWARD -s 10.1.0.0/28 -j DROP

Quem está realmente sendo bloqueado? A resposta agora tem explicação:
estão sendo bloqueados todos os ips que ao se realizar AND bit a bit
com /28 resulte em 10.1.0.0. Na prática todos entre 10.1.0.0 e
10.1.0.15, pois este será o IP da rede e de broadcast que um /28
determina.

Ainda resta dizer que o uso de máscaras de forma apropriada é
usado para subdividir uma faixa de ips públicos que determinada
instituição recebeu em várias redes. Se eu tenho um /24, sei que posso
montar uma rede com até 254 máquinas (sim, 254, pois tem o endereço de
rede e de broadcast que não posso usar em máquina). Uma rede! Mas se eu
quero DUAS, cada uma com 100 máquinas, posso quebrar este /24 em dois
/25. Ou em quatro /26… Ou ainda em três redes, uma /25 e duas outras
/26.

Claro que para isto ai tem que ir mais a fundo no conceito de máscaras,
pois pode não parecer, mas este artigo procurou fornecer apenas uma
introdução ao assunto.

Referências

Este conceito de máscaras é bastante técnico e na
Internet geralmente se encontram simplificações populares, como
receitas de bolo. Nada como bons livros, principalmente os que
descrevem o protocolo TCP/IP ou direto na veia, lendo as RFCs. Não
seria ético da minha parte tornar público aqui minha preferência por
este ou aquele livro, em detrimento de outro, mas se alguém se
interessar pelo assunto, envie-me um email que terei maior prazer em
responder.

Possuo em minha página pessoal um script em PHP para realizar o cálculo
de máscara de redes, com um diferencial que ele mostra o números em seu
formato binário, dentro do conceito que descrevi aqui. O mesmo pode ser
encontrado em:


http://www.vivaolinux.com.br/artigo/255.255.255.0-A-matematica-das-mascaras-de-rede

Um comentário sobre “255.255.255.0: A matemática das máscaras de rede

  1. Gostei da publicaçao maiS gostaria que detalhace mais como calcular o numero d hostes e d sub redes. Muinto obrigado

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s