Fundamentos de Roteamento para Provedores

Introdução

Este artigo tem como principal proposta fornecer conhecimentos acerca de fundamentos básicos do roteamento IP no geral e, depois, conectar estes conceitos para as necessidades e realidades dos ISP. Os temas sugeridos para este artigo:

• Revisão do Funcionamento da Comunicação em Rede
• Funcionamento de switches Ethernet
• Funcionamento do roteamento IP
• Funções básicas de um roteador

Revisão do funcionamento da comunicação em rede

Para que se possa compreender bem o funcionamento do roteamento IP, torna-se necessário fazermos uma revisão dos fundamentos da comunicação em redes de computadores. Nada muito extenso, e focando apenas nas questões mais essenciais aqui.

E, para constar, definitivamente, este artigo não será um tutorial ou um curso dedicado a explicar o funcionamento em detalhes do modelo de referência OSI. Tudo o que será citado sobre modelo OSI tem como propósito apenas esclarecer o óbvio para os profissionais de redes que atuam nos provedores. E toda a parte citada não incluirá toda a pilha de protocolos e demais conceitos; focaremos apenas em algumas questões L2 e, principalmente, nos detalhamentos do roteamento IP (L3).

Modelos de referência OSI e TCP/IP

Para ensinarmos fundamentos de redes e até mesmo para dissertarmos sobre determinados temas, uma das ferramentas mais adequadas é o Modelo de Referência Open System Interconnection ou simplesmente Modelo OSI. Este modelo de rede foi formalizado no início dos anos 80 com o principal objetivo organizar e padronizar os múltiplos sistemas e componentes presentes na comunicação entre periféricos de fabricantes distintos, assegurando um modelo funcional que forneça compatibilidades ou interoperabilidades. Note que o modelo OSI não é o padrão em si, e sim, como o próprio nome sugere, um modelo de referência, pois o modelo OSI procura esmiuçar uma rede de computadores fazendo uma divisão em 7 camadas funcionais e com o propósito de obtermos a abstração dos componentes que devem operar em cada camada. Por exemplo, cada protocolo, serviço e componente requerido para uma rede funcionar é mapeado para uma destas 7 camadas funcionais do modelo OSI. Desta forma, fica mais fácil compreendermos como funcionam as redes de computadores, quais protocolos, serviços e componentes residem em qual camada deste modelo de referência, e como cada componente e em sua respectiva camada funciona para o estabelecimento de uma comunicação em rede.

Note que o modelo OSI não é uma arquitetura de redes em si! Não representa os padrões, nem determina exatamente quais protocolos e serviços exatos devem ser usados em cada camada. No entanto, o modelo OSI é bastante útil para ensinarmos como uma rede de computadores funciona.

À exemplo do modelo OSI, outro modelo de referência foi estabelecido para redes TCP/IP. É o chamado Modelo TCP/IP. A proposta é basicamente a mesma do modelo OSI, porém com alguma simplificação das camadas referenciadas e de objetivo orientado às redes TCP/IP. A ilustração a seguir faz um comparativo entre os dois modelos e cita exemplos de componentes que são encontrados (à título de referência mesmo!) em cada camada:

Conforme citado anteriormente, há uma proposição de quais protocolos e serviços operam em quais camadas destes modelos de referência. Mas não dá para tomar isto como uma garantia 100% em todos os casos. Quer um exemplo? O protocolo de roteamento BGP está mais para uma aplicação (o que tecnicamente seria a Camada de Aplicação) do que um componente da Camada Rede/Internet propriamente dito, mesmo que, de forma geral, os profissionais de redes tratem os protocolos de roteamento como pertencentes à Camada de Rede/Internet. Outro exemplo clássico: o protocolo ARP realiza funções que podem ser identificadas em ambas as camadas 2 e 3 do modelo OSI e, portanto, deveria ser considerado um protocolo de Camada "2,5" ?

Outra questão é que a compreensão dos modelos de referência permite o entendimento das especificações de desenvolvimento de componentes e em suas respectivas camadas. Fica mais fácil isolar e compreender, ou até mesmo desenvolver conceitos, por camada, dedicando ou focando no desenvolvimento nas próprias funções da camada e se nos preocuparmos com o que é feito pelas demais camadas.

Portanto, sugestão aqui: procure usar o modelo de referência OSI ou o modelo TCP/IP para questões didáticas ou para explicar certos fundamentos para seus usuários e clientes. Não foque muito no "bit" dos protocolos relacionando-os para as camadas destes modelos de referência, pois as "miudezas" disto tudo certamente não são encontradas nestes modelos de referência.

Para todos os efeitos das explicações a seguir, consideraremos o Modelo TCP/IP.

Modelo de comunicação Host-para-Host

Duas realidades serão apresentadas a seguir:

• Cada camada produz conteúdo que só é útil/consumido para a mesma camada no nó adjacente.
• Considerando a abordagem vertical do Modelo TCP/IP, a camada de "cima" solicita serviços da camada de "baixo". E a camada de "baixo" presta serviços para a camada de "cima".

A ilustração acima é auto-explicativa, mas devemos prestar atenção nos nomes das Unidades de Dados de Pacotes, as quais normalmente citamos como PDUs (Packet Data Units). É muito importante, até mesmo para a pífia necessidade de mostrar conhecimentos para alguém, que o profissional de redes saiba citar os nomes corretos de cada PDU produzidos pelas respectivas camadas.

• A Camada de Aplicação produz os Dados. Estes Dados são consumidos pela camada de Aplicação do computador destinatário (outrora citado como nó adjacente - na perspectiva da comunicação entre dois hosts).
• A Camada de Transporte produz os Segmentos. Estes Segmentos são consumidos pela camada de Transporte do computador destinatário.
• A Camada de Internet produz os Pacotes. Estes Pacotes são consumidos pela camada de Internet do computador destinatário.
• A Camada de Acesso à Rede produz os Quadros e, posteriormente, os Bits. Os Quadros e Bits são consumidos pela camada Acesso à Rede do computador destinatário.
  • OBS: a Camada de Acesso à Rede consolida duas Camadas do Modelo OSI, a Física e a de Enlace de Dados. Na questão lógica envolvendo os Quadros (ex: cabeçalho Ethernet), no modelo OSI isto seria tratado pela camada de Enlace de Dados. A questão mais "física" (modulação, codificação e afins) seria tratada pela camada Física, que lida com estas situações eletromecânicas, codificação, modulação, etc.

E tudo faz muito sentido: a quem mais interessa dados do HTTP, se não o próprio HTTP "rodando" (na verdade, sendo referenciado...) na camada de Aplicação do computador remoto? A quem mais interessa um segmento TCP (funções de sequenciamento, janelamento, retransmissões de segmentos perdidos, multiplexação de várias aplicações sobre o mesmo endereço de rede, etc.) se não o próprio protocolo TCP referenciado na camada de Transporte do nó destinatário? E isto é mostrado tanto na ilustração acima quando na ilustração a seguir:

É notório que uma parte razoável de todo o payload é meramente "encheção de linguiça", ou seja, não são efetivamente os dados finais úteis que serão consumidos/utilizados pelas aplicações (o que realmente importa na perspectiva do usuário), e isto é o que chamamos de overhead. O overhead constitui boa parte do tamanho total do payload, especialmente em transmissões de pacotes de tamanhos menores. Mesmo assim, os cabeçalhos são fundamentais para que todo o conceito de comunicação em uma rede possa funcionar.

Se analisássemos uma comunicação fim-a-fim entre dois computadores devidamente separados por switches e roteadores, isto poderia ser ilustrado da seguinte forma:

1. O cenário apresenta dois computadores com interesse de trocar dados: o computador representado à esquerda da topologia, e o computador vizinho à direita.
   1. Computador 1:
      1. Endereço IP: 10.1.1.1
      2. Endereço MAC: 1111.1111.aaaa
      3. Default Gateway: 10.1.1.254
   2. Computador 2:
      1. Endereço IP: 10.2.2.2
      2. Endereço MAC: 6666.6666.ffff
2. Quanto aos elementos ativos de rede presentes:
   1. Roteador 1:
      1. Interface 1:
         1. Endereço IP: 10.1.1.254
         2. Endereço MAC: 2222.2222.bbbb
      2. Interface 2:
         1. Endereço IP: 10.0.0.1
         2. Endereço MAC: 3333.3333.ccccc
   2. Roteador 2:
      1. Interface 1:
         1. Endereço IP: 10.0.0.2
         2. Endereço MAC: 4444.4444.dddd
      2. Interface 2:
         1. Endereço IP: 10.2.2.254
         2. Endereço MAC: 5555.5555.eeee
3. O Computador 1 produz dados para serem enviados para o Computador 2:
   1. O Computador 1 consulta o endereço IP de destino do Computador 2 (10.2.2.2), num procedimento conhecido por Logical AND.
      1. Usando o seu próprio endereço IP (10.1.1.1) e sua máscara de subrede (255.255.255.0 ou /24) e o endereço IP do Computador (10.2.2.2), determina que o Computador 2 está localizado em outra subrede IP.
      2. O Computador 1 possui um default gateway configurado, que, neste caso, é o endereço IP da interface 1 do Roteador 1.
         1. Neste momento, a composição do cabeçalho IP na pilha de protocolos do Computador 1 é:
            1. IP de Origem: 10.1.1.1
            2. IP de Destino: 10.2.2.2
      3. O Computador 1 compreende que precisa: a) construir um quadro Ethernet, pois é a tecnologia de enlace empregada por seu adaptador de rede, b) encaminhar o quadro para o default gateway.
         1. No entanto, o Computador 1 precisa determinar o endereço físico (MAC) associado ao endereço IP do default gateway/Roteador 1.
            1. O Computador 1 consulta o seu ARP cache para identificar esta informação, se possuir.
            2. Não possuindo uma entrada em sua tabela ARP, o Computador 1 "estaciona" o pacote e aciona o protocolo ARP para prover esta resolução.
      4. O Roteador 1 responde à requisição de ARP feita pelo Computador 1, que por sua vez armazena esta informação em sua tabela ARP.
   2. O Computador 1 escreve um quadro Ethernet apropriado, onde destacamos os principais campos:
      1. Endereço Físico de Origem: 1111.1111.aaaa (o endereço MAC do próprio Computador 1)
      2. Endereço Físico de Destino: 2222.2222.bbbb (o endereço MAC da interface 1 do Roteador 1, seu default gateway).
      3. EtherType: 0x0800 (denotando que o protocolo sendo transportado pelo quadro Ethernet é o IPv4).
   3. O Computador então encaminha o quadro Ethernet destinado para a interface 1 do Roteador 1.

Neste ponto conseguimos esclarecer um fundamento bastante importante que pode ser útil para profissionais que estejam começando as suas carreiras na área de provedores:

"A entrega efetiva de dados numa rede ocorre na Camada de Acesso à Rede do Modelo TCP/IP (que consolida as Camadas Física e Enlace de Dados do Modelo OSI)".

Ou seja, no aspecto mais "físico" do conceito, é um quadro ("frame") sendo encaminhado pela rede e sempre de acordo com a tecnologia de enlace empregada, Numa rede Ethernet, é uma comunicação entre os endereços físicos (MAC) envolvidos.

Se esta informação parece ser muito óbvia para você, ótimo. Mas, acredite, há muitos profissionais que lidam com infraestruturas de telecomunicações que já me confessaram não conhecer estes conceitos tão básicos.

Funcionamento de switches Ethernet

Embora a intenção original do artigo seja tratar as questões de roteamento IP nos provedores, abrirei um espaço aqui para uma breve revisão de fundamentos L2 - especificamente os endereços físicos e funções de encaminhamento de quadros Ethernet - pois, sem dúvidas, isso poderá aprimorar o seu próprio entendimento acerca de como funcionam as funções gerais de encaminhamento de pacotes na infraestrutura do provedor.

O que melhor define um switch Ethernet:

• Um switch Ethernet é essencialmente uma Bridge Multiportas, só que, para as funções de encaminhamento de quadros, emprega silício rápido, os chamados Application-Specific Integrated Circuit (ASIC).
• Um switch filtra tráfego de forma a fazer uma comutação inteligente, porém simples, e que envolva apenas as portas/interfaces desejadas ou necessárias em uma determinada comunicação.
  • Ou seja, toda a comunicação unicast deverá envolver somente as portas necessárias. As demais portas não recebem cópias dos quadros destas comunicações.
• Um switch não consegue filtrar os seguintes tipos de comunicações:
  • Unknown Unicast: qualquer quadro de uma comunicação unicast que o switch não saiba (em que porta está?) onde o endereço físico de destino mencionado no quadro Ethernet recebido.
  • Broadcast: por razões óbvias, já que é uma comunicação que obrigatoriamente deve envolver todas as portas naquela VLAN.
  • Multicast: os endereços MAC de transmissões IPv4 unicast representando os grupos são facilmente identificados pelo início "01-00-53". No entanto este endereço físico navega sempre na porção "Destino" do cabeçalho Ethernet, logo, portanto, o switch não possui condições de filtrá-lo.
    • OBS: exceto via mecanismos adicionais tais como o IGMP Snooping.
• Citando apenas as funções de Camada 2 (L2) de um switch, e desprezando ações complementares e recursos diversos que switches podem implementar, ou seja, as funções de encaminhamento de dados na rede.
  • O switch encaminha tráfego envolvendo apenas as portas necessárias de uma comunicação unicast.
  • Para o procedimento de encaminhamento de dados de uma porta para a outra, o switch implementa uma tabela específica chamada "Tabela MAC". Esta tabela informa ao switch quais endereços MAC são acessíveis e por quais portas.
  • Todo o trabalho de criação e manutenção das entradas correspondentes aos endereços físicos conhecidos na Tabela MAC do switch é realizado diretamente no Plano de Dados, ou seja, diretamente nos ASICs, os quais são programados dinamicamente conforme os endereços MAC são aprendidos pelo switch quando os quadros são recebidos em suas portas. À título de informação e curiosidade de alguns, os switches possuem uma área sistêmica denominada Plano de Controle também, que é a área onde residem os processos de software de protocolos tais como o Spanning Tree, LACP, LLDP, UDLD, e tantos outros. No entanto, para manutenção da tabela MAC, não há protocolos envolvidos, pois tudo ocorre diretamente no Plano de Dados do equipamento.
    • Sim, todo este trabalho ocorre no plano de dados, mediante o recebimento dos quadros. Não há envolvimento de protocolos.
      • Alguns "profissionais" já me confessaram ter entendido que os switches rodavam um protocolo específico para que pudessem trocar as suas tabelas MAC. Isto não procede! Não há quaisquer protocolos envolvidos no procedimento de criação e manutenção de entradas na tabela MAC dos switches!
    • O switch consulta o endereço MAC de origem para criar ou atualizar a entrada na tabela MAC.
    • O switch consulta o endereço MAC de destino para determinar qual deverá ser a porta por onde aquela transmissão deverá ser feita.
      • Não conhecendo o endereço MAC de destino, o switch inunda (flooding) o quadro Ethernet - fazendo cópias deste - para todas as portas daquela VLAN, exceto, obviamente, a porta de origem que recebeu o quadro.
• Um switch implementa o que chamamos de microssegmentação:
  • Permite o estabelecimento de um domínio de colisão por porta. Ou seja, caso uma colisão vá ocorrer o diâmetro desta colisão seria tão grande quanto a própria porta.
  • Permite o estabelecimento de configurações Full Duplex entre a porta do switch e o equipamento conectado nesta porta. E, com isto, elimina-se por completo colisões naquela porta.
  • Permite misturar portas de diferentes capacidades no mesmo equipamento (1/10/25/40/100 Gbps, por exemplo).
• Há switches de diversas classes, tipos e missões. Inclusive em algumas características bem técnicas acerca do tratamento dos quadros, tais como técnicas Store-and-Forward, Cut-Through e Fragment-Free; temas estes completamente fora do escopo deste artigo.

E isto pode ser sumarizado na ilustração a seguir:

Informações adicionais importantes sobre os switches:

"Switches são bridges multiportas transparentes. Ou seja, não modificam os endereços físicos (MAC) dos quadros em trânsito".

Por mais básico ou trivial que esta informação seja para muitos, Isto é realmente muito importante! Vários profissionais de redes já me relataram não sabendo exatamente esta informação! Os switches definitivamente não realizam modificações dos endereços MAC dos quadros em trânsito.

Funcionamento do roteamento IP

Uma vez que fica melhor esclarecido algumas funções básicas dos switches e dos recursos de Camada 2 no geral, ficará mais fácil abordarmos a parte IP, que é justamente a área de maior interesse desse artigo.

O roteamento IP é orientado ao encaminhamento de dados para os endereços de destino citados nos cabeçalhos IP dos pacotes. Desprezando todas as ações adicionais ou periféricas que um roteador pode desempenhar, e focando exclusivamente nas funções de roteamento do protocolo IP, isto significa que o roteador não está interessado nos endereços IP de origem mencionados nos cabeçalhos IP dos pacotes, e sim apenas nos endereços IP de destino. Pouco importa "da onde o pacote veio" - seja a interface de entrada ou a rede IP de origem - e sim para onde o pacote deverá ser encaminhado.

Todo o roteador desempenha duas funções muito básicas, citadas a seguir:

• Determinação de Caminhos
• Encaminhamento de Pacotes

Foquemos inicialmente na determinação de caminhos: como um roteador faz isso?

A determinação de caminhos ou "path determination" é realizada sobre instruções conhecidas previamente pelo roteador em sua tabela de roteamento. Ou seja, para escolher um caminho, o melhor caminho, para o encaminhamento de um determinado pacote, o roteador deverá selecionar a melhor rota já contida/instalada/publicada em sua tabela de roteamento. E é justamente isto que abordaremos primeiro.

Um roteador precisa ser "ensinado" sobre quais redes são acessíveis em seu domínio de roteamento, e há duas formas de fazermos isto:

1. Administrativamente, através de rotas estáticas
2. Dinamicamente, com o auxílio de protocolos de roteamento

O primeiro caso é bem simples: você, administrador, acessa os seus equipamentos e configura as rotas estáticas conforme desejado. Há vantagens e desvantagens em utilizarmos rotas estáticas, sendo que a principal delas é que eventos de falhas em partes da rede por onde as suas rotas estáticas estiverem configuradas gerarão indisponibilidades nos serviços, mesmo havendo outras alternativas de caminhos, até que você, o administrador, acesse os roteadores para refazer estas rotas estáticas apontando o tráfego para outros caminhos. OBS: há "gambiarras" aqui com rotas estáticas e o uso de ferramentas periféricas. Suprimiremos estas situações neste artigo. O fato é que você precisará de algumas rotas estáticas nos seus projetos. Fato.

O segundo caso implica na adoção de um protocolo de roteamento para que os roteadores aprendam e convirjam dinamicamente sobre as redes conhecidas no domínio de roteamento do seu AS. Para mantermos a objetividade e até mesmo o tamanho deste artigo, não entraremos em detalhes sobre os protocolos de roteamento. Explicaremos apenas o necessário para que você, profissional que atua em um ISP, entenda um pouco mais sobre as funções do roteamento IP.

Os protocolos de roteamento

Os protocolos de roteamento podem ser categorizados e tipificados conforme ilustrado a seguir:

A tabela a seguir sumariza as diferenças entre estes protocolos de roteamento:

Protocolo	Categoria	Métrica	Algoritmo	Protocolo de Transporte	Vantagens	Limitações
Estático	Estático (não é protocolo...)	-	-	-	Permite controle absoluto e administrativo sobre a rota	Processo de configuração manual e sem mecanismos nativos de convergência.
RIPv1	Distance Vector	Hop Count (Saltos)	Bellman-Ford	UDP porta 520 Opera por Broadcast (255.255.255.255)	Simplesmente não há!	Classful (não suporta VLSM), opera por broadcast, redes de diâmetro pequeno, converge muito lentamente, baixa imunidade quanto a routing loops. Métrica estúpida que despreza a capacidade dos circuitos.
RIPv2	Distance Vector	Hop Count (Saltos)	Bellman-Ford	UDP porta 520 Opera por IP Multicast (224.0.0.9)	Protocolo suportado por praticamente qualquer roteador que existe no mercado, até os mais simples. Boa opção para relações PE-CE em redes MPLS L3VPN.	Redes de diâmetro pequeno, converge muito lentamente, possui baixa imunidade quanto a routing loops; envio periódico de toda a sua tabela de rotas. Métrica medíocre, completamente inadequada para um projeto decente de redes.
EIGRP	Distance Vector Avançado	Composite: fatora Banda, Delay, Confiabilidade, Carga	DUAL	IP, protocolo número 88 O EIGRP é transportado diretamente sobre o IP. Utiliza o Reliable Transport Protocol (RTP) para funções que exijam confiabilidade (pacotes Query, Reply, Update). Opera por IP Multicast (224.0.0.10)	Escalável para redes grandes, converge muito rapidamente. Apesar de ser um Distance Vector, implementa recursos confiáveis tipicamente implementados em protocolos de roteamento Link-State. Bom protocolo de roteamento para cenários PE-CE em redes de clientes Cisco com MPLS L3VPN	Apesar de não ser mais proprietário (Cisco), não tem sido aderente em plataformas de outros fabricantes. Não pode ser usado em redes de provedores muito em função de não ser compatível e não suportar o MPLS Traffic Engineering. Apesar dos pesares, continua sendo um protocolo que compreende a rede na perspectiva de um "Distance Vector".
OSPF	Link-State	Cost (Custo)	Dijkstra	IP, protocolo número 89 O OSPF é transportado diretamente sobre o IP. Opera por IP Multicast (224.0.0.5 e 224.0.0.6)	Escalável para redes grandes com um bom projeto de Áreas. Converge rapidamente. Padrão aberto e amplamente suportados pelos fabricantes. Suporta as extensões de MPLS TE. Suporta as tecnologias Segment Routing.	Um pouco engessado ou "burocrático" para projetos com MPLS L3VPN. Requer conhecimento e um bom projeto técnico para performar idealmente. Inundações excessivas de LSAs em projetos com áreas contendo muitos links e roteadores.
IS-IS	Link-State	Metric / Cost	Dijkstra	Utiliza a sua própria pilha de protocolos, denominada CLNS. Não utiliza o IP como transporte para seus pacotes/mensagens	Escalável para redes grandes com um bom projeto de Áreas. Converge rapidamente. Padrão aberto e amplamente suportados pelos fabricantes. Suporta as extensões de MPLS TE. Suporta as tecnologias Segment Routing. É um pouco menos "tagarela" que o OSPF.	Requer conhecimento mais específico.
BGP	Path-Vector	Path Attributes: Well-Known Mandatory Well-Known Discretionary Optional Transitive Optional Non-Transitive	BGP	TCP porta 179 Opera por Unicast, à exemplo de uma aplicação comum (ex: HTTP)	Escalável para redes muito grandes, sendo o único protocolo de roteamento capaz de acomodar tabelas completas de prefixos da Internet. Oferece ferramentas mais robustas e sofisticadas para filtrar anúncios e recebimentos de prefixos, assim como a realização da manipulação desejada para o tráfego de entrada e saída do AS. É um multiprotocolo com suporte a várias famílias de endereços, incluindo IPv4 Unicast, IPv6 Unicast, IPv4 Multicast, IPv6 Multicast, VPNv4, VPNv6, L2VPN...	É um protocolo bem mais complexo de se lidar, tanto na parte teórica quanto nas questões de implementação de políticas de roteamento. Requer maior conhecimento por parte dos administradores da rede. Não funciona "sozinho", no sentido de que o BGP roda no topo de diversos componentes que são pré-requisitos para ele (ex: IGP, L2...). Ou seja, exige analistas mais experientes. O foco do BGP é o controle sobre o tráfego e a escalabilidade da rede (tamanho das tabelas de rotas). O foco do BGP não é a convergência rápida, inclusive é bem lento neste quesito.