Máscaras de tamanho variável, o (variable-length subnet masks), permitem que as subnets recortadas de um mesmo bloco pai tenham prefixos de comprimentos diferentes, cada uma dimensionada para os hosts que precisa abrigar. A (RFC) dos requisitos para roteadores IPv4 descreve o arranjo: "an address block associated with a given network prefix could be subdivided into subblocks of different sizes, so that the network prefixes associated with the subblocks would have different length", um bloco dividido em sub-blocos de tamanhos diferentes, cada um com seu prefix length (comprimento do prefixo) (RFC 1812, seção 4.2.3.4). Você encontra isso onde um segmento de cem hosts fica ao lado de um link entre dois roteadores, porque nenhuma máscara única atende aos dois sem desperdício. A aritmética da máscara fica por conta de Fundamentos de subnetting, e a notação com barra do Classless Inter-domain Routing (), de Notação CIDR explicada. Depois da leitura, você consegue dimensionar cada subnet, alocar os blocos sem abrir buracos, dizer quais protocolos carregam o plano, explicar por que o longest match torna as máscaras mistas seguras e conferir o resultado na calculadora do site.
Uma máscara por rede, depois mais de uma
A RFC 950, o padrão de subnetting de agosto de 1985, criou a máscara de endereço, mas a divisão era decidida uma vez por rede: "the width of the <subnet-number> field is constant for a given network", largura constante numa mesma rede (RFC 950, seção 2.1), e uma só máscara, a "my_ip_mask" (seção 2.2), servia a todos os endereços da rede. A largura constante durou dois anos. Os requisitos para gateways de junho de 1987 disseram "we allow a particular subnetted network to use more than one subnet mask", mais de uma máscara por rede (RFC 1009, seção 1.1.4), e concluíram, para a tabela de roteamento: "for full generality the mask needs to be given explicitly for each entry", máscara explícita em cada entrada (seção 4.2). A RFC 1009 hoje é Historic, mas a permissão começa ali.
Em junho de 1995 a permissão virou obrigação: "Routers MUST support variable length network prefixes in both their interface configurations and their routing databases", prefixos de comprimento variável nas interfaces e nas bases de roteamento (RFC 1812, seção 4.2.3.4). A RFC 1878, hoje Historic, tabulou cada comprimento de prefixo com máscara e quantidade de endereços (RFC 1878, Table); a RFC 4632 absorveu a tabela na regra de que "prefixes may be defined to describe any power of two-sized block of between one and 2^32 end system addresses", qualquer bloco de tamanho potência de dois (RFC 4632, seção 3.1). Nenhum desses documentos usa a sigla: a RFC 1812 escreve "variable length subnet masks (variable length network prefixes)" (Apêndice E) e a especificação do diz "variable length subnetting" (RFC 2328, seção 1.1). VLSM é o nome que o mercado deu ao que eles descrevem.
Com o que a máscara precisa viajar
Um plano com várias máscaras só roda em roteadores que aprendem a máscara com cada rota. "Network masks or prefix lengths must be explicitly carried in routing protocols", máscaras ou comprimentos de prefixo carregados explicitamente pelos protocolos (RFC 4632, seção 5): OSPF, Intermediate System to Intermediate System (), a versão 2 do Routing Information Protocol (), o Enhanced Interior Gateway Routing Protocol () e o carregam; o RIP versão 1, o HELLO e o antigo Interior Gateway Routing Protocol (IGRP) não (seção 5). As famílias estão comparadas em Roteamento dinâmico em comparação.
O RIP mostra a diferença no formato do pacote. Uma entrada de rota da versão 1 traz um "IP address (4)" seguido de dois campos marcados "must be zero (4)" (RFC 1058, seção 3.1). A versão 2 colocou "Subnet Mask (4)" num desses campos (RFC 2453, seção 4), porque a ausência era "a particularly serious problem for routers since they need a subnet mask to know how to determine a route", problema sério para roteadores, que precisam da máscara para a rota (seção 2). O OSPF versão 2 leva a máscara em cada Hello e em cada rota: "Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (i.e., different masks)", cada rota com destino e máscara, subnets da mesma rede com tamanhos diferentes (RFC 2328, seção 1.1), como mostra OSPF: o mapa, a matemática e a área 0. Uma rota estática também declara o destino como prefixo (RFC 1812, seção 7.4).
Quando as máscaras diferem, um destino pode coincidir com várias rotas, e a regra de encaminhamento torna isso seguro: "Routers must use the most specific matching route (the longest matching network prefix) when forwarding traffic", a rota mais específica, de prefixo mais longo (RFC 1812, seção 2.2.5.2). O OSPF faz disso dever de quem planeja: "Subnet masks must be assigned so that the best match for any IP destination is unambiguous", o best match de qualquer destino tem de ser inequívoco (RFC 2328, seção 3.5). A consulta em si está em Rotas estáticas, longest prefix match e distância administrativa.
Como dimensionar cada subnet
Toda subnet comum perde os hosts todos zeros e todos uns; por isso, como nota a RFC 1812, "each of these fields will be at least two bits long", cada um desses campos terá pelo menos dois bits (RFC 1812, seção 4.2.2.11); o bloco para h hosts é a menor potência de dois não menor que h mais 2. A tabela lista os tamanhos do plano e as bordas em que um host a mais muda a resposta:
| Hosts necessários | Hosts mais 2 | Bloco (endereços) | Prefixo | Hosts utilizáveis | Máscara |
|---|---|---|---|---|---|
| 2 | 4 | 4 | /30 | 2 | 255.255.255.252 |
| 10 | 12 | 16 | /28 | 14 | 255.255.255.240 |
| 25 | 27 | 32 | /27 | 30 | 255.255.255.224 |
| 50 | 52 | 64 | /26 | 62 | 255.255.255.192 |
| 62 | 64 | 64 | /26 | 62 | 255.255.255.192 |
| 63 | 65 | 128 | /25 | 126 | 255.255.255.128 |
| 100 | 102 | 128 | /25 | 126 | 255.255.255.128 |
| 127 | 129 | 256 | /24 | 254 | 255.255.255.0 |
Um segmento de 60 hosts cabe num /26 com 2 de sobra, e o 63º host força um /25: dimensionar pela contagem de hoje é como um plano acaba renumerado depois. Um link entre dois roteadores pode usar um /31, já que "In a point-to-point link with a 31-bit subnet mask, the two addresses above MUST be interpreted as host addresses", os dois endereços de um link /31 são de host (RFC 3021, seção 2.1), mas um link "in which only one end supports the use of 31-bit prefixes may not operate correctly", só uma ponta aceitando /31, pode não funcionar (seção 5). Os casos /31 e /32 estão em Fundamentos de subnetting; o plano abaixo fica com o /30.
Alinhamento, e por que o maior vem primeiro
Um bloco de 2^k endereços só pode começar onde os k bits baixos são zero, e por isso a RFC 4632 diz que as alocações são "made in contiguous bit-aligned blocks", blocos contíguos alinhados ao bit (RFC 4632, seção 3.1). No último octeto, .0 é 00000000, .128 é 10000000, .192 é 11000000, .224 é 11100000 e .240 é 11110000: cada deslocamento é múltiplo do bloco que inicia (128, 64, 32, 16 e 4).
Tome 192.0.2.0/24, que o registro da Internet Assigned Numbers Authority () lista como "Documentation (TEST--1)" (IANA, IPv4 Special-Purpose Address Space), e cinco requisitos: 100, 50, 25 e 10 hosts, mais um link entre dois roteadores. Do maior para o menor, um atrás do outro:
| Requisito | Subnet | Máscara | Faixa utilizável | Broadcast | Hosts utilizáveis |
|---|---|---|---|---|---|
| 100 hosts | 192.0.2.0/25 | 255.255.255.128 | 192.0.2.1 a 192.0.2.126 | 192.0.2.127 | 126 |
| 50 hosts | 192.0.2.128/26 | 255.255.255.192 | 192.0.2.129 a 192.0.2.190 | 192.0.2.191 | 62 |
| 25 hosts | 192.0.2.192/27 | 255.255.255.224 | 192.0.2.193 a 192.0.2.222 | 192.0.2.223 | 30 |
| 10 hosts | 192.0.2.224/28 | 255.255.255.240 | 192.0.2.225 a 192.0.2.238 | 192.0.2.239 | 14 |
| Link | 192.0.2.240/30 | 255.255.255.252 | 192.0.2.241 a 192.0.2.242 | 192.0.2.243 | 2 |
Usados 244 de 256 endereços, 12 livres, 95,3%. Cada bloco começa onde o anterior terminou, por aritmética: todo bloco já colocado é uma potência de dois pelo menos tão grande quanto o próximo, e a soma dos tamanhos é múltiplo do seguinte (128 é múltiplo de 64, 192 de 32, 224 de 16, 240 de 4), e nenhum bloco precisa pular para a frente. Uma alocação num /22, com a rota de descarte do resumo, está recortada em Uma alocação VLSM resolvida de ponta a ponta.
Como um plano dá errado
A ordem errada deixa buracos. Coloque os mesmos cinco blocos do menor para o maior, cada um no próximo endereço alinhado. O link fica com 192.0.2.0/30; um /28 não pode começar em .4, pois 4 não é múltiplo de 16, e pula para 192.0.2.16/28; seguem 192.0.2.32/27, 192.0.2.64/26 e 192.0.2.128/25. Tudo cabe, 244 usados e 12 livres, mas o espaço livre agora é 192.0.2.4/30 e 192.0.2.8/29, dois bolsões no meio do plano em vez de uma cauda. Buraco é espaço não alocado, não conflito: blocos alinhados ficam disjuntos em qualquer ordem; sobreposição vem de um bloco fora do limite ou de um endereço usado duas vezes (Sobreposições e lacunas entre subnets).
Num pai exatamente cheio, a ordem errada perde uma subnet. Requisitos de 62, 126 e 62 hosts pedem um /26, um /25 e um /26: 64 mais 128 mais 64 dá 256, o /24 inteiro. Do maior para o menor saem 192.0.2.0/25, 192.0.2.128/26 e 192.0.2.192/26, 100% usados. Do menor para o maior sai 192.0.2.0/26, o /25 pula para 192.0.2.128/25 e o último /26 não tem lugar: os 64 endereços livres, 192.0.2.64 a 192.0.2.127, ficaram atrás do cursor. Usados 192, livres 64, 75,0%, um requisito sem lugar embora a soma feche.
A RFC 4632 mostra o efeito na escala de um provedor: seis sites entram num 10.24.0.0/13 "in the following order (significant because it demonstrates how temporary 'holes' may form in the service provider's address space)", ordem que mostra como buracos temporários se formam (RFC 4632, seção 6.1). C1 fica com 10.24.0.0/21; precisa de um /20 e, como 2048 não é múltiplo de 4096, vai para 10.24.16.0/20, deixando 10.24.8.0 a 10.24.15.255 como buraco que os /22 de C3 e C4 preenchem depois (seção 6.1). A errata verificada 2955 corrige o diagrama da seção, que imprime C4 como /20.
Misturar versões do RIP toma a liberdade de volta. Onde roteadores da versão 1 escutam, "a single subnet mask should be used throughout the network", uma só máscara na rede inteira (RFC 2453, seção 6), ou podem surgir rotas blackhole.
Máscara divergente num segmento compartilhado para o OSPF antes do roteamento. A Network Mask do Hello recebido é conferida contra a da interface, e "Any mismatch causes processing to stop and the packet to be dropped", qualquer divergência descarta o pacote (RFC 2328, seção 10.5): dois roteadores no mesmo segmento com /25 e /24 nunca viram vizinhos, e o sintoma é uma adjacência que não aparece, não uma rota errada.
Espalhar um site pelo plano joga fora o seu resumo. As rotas de um site só viram um prefixo "by allocating a contiguous power-of-two block address space to the site", um bloco contíguo de tamanho potência de dois para o site (RFC 4632, seção 4.1); veja Sumarização de rotas e Supernetting e agregação de rotas.
Como deixar espaço para crescer
A cauda do plano acima, 192.0.2.244 a 192.0.2.255, tem 12 endereços, mas em blocos alinhados é um /30 em 192.0.2.244 e um /29 em 192.0.2.248: nenhuma subnet com mais de 6 hosts cabe ali. Conte o espaço livre em blocos alinhados, não em endereços, e reserve o /27 do ano que vem enquanto há um /27 alinhado livre. O provedor da RFC 4632 fez o mesmo, já que "the number of IPv4 addresses 'required' by each site is assumed to allow for significant growth", cada site dimensionado já prevendo crescimento (RFC 4632, seção 6.1).
A contagem em espelho da RFC 1219 permite trocar a máscara sem renumerar: "host bits (mask = 0) are assigned from the least significant bit working towards the most, and subnet bits (mask = 1) are assigned from the most significant bit working towards the least", bits de host do menos significativo para o mais, bits de subnet do mais para o menos (RFC 1219, Overview), e assim, quando uma subnet cresce, "no host ever need change addresses", nenhum host precisa mudar de endereço (Overview).
Como ver
Num roteador Linux o plano aparece como vários comprimentos de prefixo sob um pai. Como "root PREFIX selects routes with prefixes not shorter than PREFIX", rotas com prefixo não mais curto que o informado (ip-route(8), ip route show), ip route show root 192.0.2.0/24 lista as subnets recortadas do pai, enquanto ip route get 192.0.2.130 imprime a única rota que o kernel usaria, o longest match tornado visível. As máscaras das interfaces se veem com ip address show e se definem com ip address add 192.0.2.129/26 dev eth0, em que "The ADDRESS may be followed by a slash and a decimal number which encodes the network prefix length", barra e comprimento do prefixo depois do endereço (ip-address(8), ip address add). A tabela em si está em Tabelas de roteamento e o default gateway.
O módulo ipaddress do Python confere o plano em poucas linhas, que o Python playground roda no navegador:
>>> from ipaddress import ip_network, collapse_addresses
>>> plan = [ip_network(p) for p in ('192.0.2.0/25', '192.0.2.128/26',
... '192.0.2.192/27', '192.0.2.224/28', '192.0.2.240/30')]
>>> free = [ip_network('192.0.2.244/30'), ip_network('192.0.2.248/29')]
>>> list(collapse_addresses(plan + free))
[IPv4Network('192.0.2.0/24')]
>>> list(ip_network('192.0.2.0/24').address_exclude(ip_network('192.0.2.0/25')))
[IPv4Network('192.0.2.128/25')]
>>> ip_network('192.0.2.128/26').supernet_of(ip_network('192.0.2.192/27'))
False
collapse_addresses devolver o pai prova que as cinco subnets e os dois blocos livres cobrem cada endereço exatamente uma vez; address_exclude lista o que sobra de um bloco em pedaços alinhados; supernet_of dá False porque o /26 e o /27 são irmãos, não aninhados (documentação do Python 3.14, ipaddress).
A Calculadora CIDR / Subnet tem um modo VLSM ao lado dos modos Sub-rede, Super-rede e Sobreposição / lacuna. Ele recebe um bloco pai e uma lista de requisitos, cada um com nome e quantidade de hosts, e em Alocar imprime endereços usados e livres, utilização e, por subnet, rede, prefixo, máscara, faixa utilizável, broadcast e hosts utilizáveis; os requisitos que não cabem aparecem em "Não couberam". O motor ordena os requisitos do maior para o menor sozinho, então os cinco acima dão a mesma tabela em qualquer ordem, e a falha do menor-primeiro só se reproduz à mão ou em Python. Ele dimensiona todo requisito como hosts mais dois, então um link de 2 hosts sempre recebe /30, nunca /31; links RFC 3021 se conferem um a um no modo Sub-rede, que conta o /31 como a RFC 3021 manda. E ele mascara em silêncio os bits de host do pai: 192.0.2.77/24 vira 192.0.2.0/24; leia o endereço de rede devolvido. Em 192.0.2.0/25 com requisitos de 200, 50 e 10 hosts, ele coloca os 50 em 192.0.2.0/26 e os 10 em 192.0.2.64/28 e lista os 200 em Não couberam, com 62,5%.
Para lembrar
- VLSM quer dizer subnets de um mesmo pai com prefixos de comprimentos diferentes: a RFC 950 fixou uma largura por rede em 1985, a RFC 1009 permitiu várias máscaras em 1987, a RFC 1812 fez disso um MUST em 1995.
- Dimensione cada subnet como hosts mais 2 arredondado à potência de dois seguinte: 100 hosts pedem /25, 50 um /26, 25 um /27, 10 um /28, um link um /30 (ou /31 se as duas pontas aceitam a RFC 3021).
- Um bloco de 2^k endereços só começa onde seus k bits baixos são zero; do maior para o menor, cada bloco começa onde o anterior terminou.
- A ordem errada deixa buracos, não sobreposições, e num pai exatamente cheio pode deixar um bloco sem lugar embora a soma dos tamanhos feche.
- O plano só roda onde todo roteador aprende a máscara com a rota (RIP versão 2, OSPF, IS-IS, EIGRP, BGP, rotas estáticas); o RIP versão 1 não carrega nenhuma.
- O encaminhamento é longest match, então cada destino precisa de uma só rota mais específica; máscara divergente nos Hellos do OSPF derruba a adjacência.
- Conte o espaço livre em blocos alinhados, reserve o crescimento enquanto há bloco alinhado livre e mantenha cada site num só bloco potência de dois, para que se resuma a uma rota.
Fontes
- RFC 950, Internet Standard Subnetting Procedure, agosto de 1985: seções 2.1 e 2.2 (lida em 2026-10-19)
- RFC 1009, Requirements for Internet Gateways, junho de 1987: seções 1.1.4 e 4.2 (Historic, tornada obsoleta pela RFC 1812) (lida em 2026-10-19)
- RFC 1219, On the Assignment of Subnet Numbers, abril de 1991: Overview (lida em 2026-10-19)
- RFC 1812, Requirements for IP Version 4 Routers, junho de 1995: seções 2.2.5.2, 4.2.2.11, 4.2.3.4, 7.4 e Apêndice E (lida em 2026-10-19)
- RFC 1878, Variable Length Subnet Table For IPv4, dezembro de 1995: a Table (Historic) (lida em 2026-10-19)
- RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, agosto de 2006: seções 3.1, 4.1, 5 e 6.1 (lida em 2026-10-19)
- RFC 2328, OSPF Version 2, abril de 1998: seções 1.1, 3.5 e 10.5 (lida em 2026-10-19)
- RFC 1058, Routing Information Protocol, junho de 1988: seção 3.1 (lida em 2026-10-19)
- RFC 2453, RIP Version 2, novembro de 1998: seções 2, 4 e 6 (lida em 2026-10-19)
- RFC 3021, Using 31-Bit Prefixes on IPv4 Point-to-Point Links, dezembro de 2000: seções 2.1 e 5 (lida em 2026-10-19)
- IANA, registro IPv4 Special-Purpose Address Space, atualizado em 2025-10-09: as linhas de documentação (lido em 2026-10-19)
- ip-route(8), página de manual do iproute2, man7.org: ip route show, ip route get (lida em 2026-10-19)
- ip-address(8), página de manual do iproute2, man7.org: ip address add, ip address show (lida em 2026-10-19)
- Documentação do Python 3.14, ipaddress: IPv4Network, strict, address_exclude, supernet_of, collapse_addresses (lida em 2026-10-19)