Fundamentos de Roteamento para Provedores

Introdução

Este artigo tem como principal proposta fornecer conhecimentos acerca de fundamentos básicos de comutação Ethernet e, principalmente, do roteamento IP. Os temas sugeridos para este artigo:

• Revisão do Funcionamento da Comunicação em Rede
• Funcionamento de switches Ethernet
• Funcionamento do roteamento IP

Público-alvo

Este artigo é particularmente destinado aos profissionais de redes que atuam ou que estejam interessados em atuar em provedores de Internet. Com base na experiência que possuo em mais de 24 anos de carreira, atuando diretamente como arquiteto de soluções e engenheiro de redes, usando todo o tipo de aparato tecnológico e ferramentas presentes nas infraestruturas da Tecnologia da Informação e Comunicação, e com quase seis mil horas de "vôo" na condição de instrutor, afirmo com convicção o seguinte: muitos profissionais com os quais eu interagi na carreira, assim como muitos alunos de cursos da área também, revelaram não ter profundo conhecimento, e até mesmo certa dificuldade em alguns casos, justamente sobre os temas que estou destacando neste artigo.

O artigo poderá ser editado posteriormente para aprimorar alguns conceitos ou estender alguns temas funcionais importantes. Fique antenado!

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

Para que se possa compreender bem o funcionamento de uma rede, 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 extenso com a missão de 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 que os profissionais de redes que atuam nos provedores possam seguir evoluindo na área. 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 Systems Interconnection ou simplesmente Modelo OSI. Este modelo de rede foi formalizado no início dos anos 80 com o principal objetivo de organizar e padronizar os múltiplos sistemas e componentes presentes na comunicação entre periféricos de fabricantes distintos, assegurando um modelo funcional que fornecesse as necessárias compatibilidades ou interoperabilidades. Note que o modelo OSI não é o padrão em si. Como o próprio nome sugere, é um modelo de referência apenas, pois o modelo OSI procura esmiuçar uma rede de computadores fazendo uma divisão desta 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 ou mapeiam para 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 para os mais leigos.

À 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 exclusivamente para as 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 sem que tenhamos que nos preocuparmos com o que é feito pelas demais camadas.

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.

Processo de comunicação Host-para-Host

Duas realidades serão apresentadas a seguir:

• Cada camada produz conteúdo que só é útil/consumido pela 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 o mínimo de 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, óticas, sinais, 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 ser funcional.

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 referente ao endereço físico do default gateway, 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. Achavam que as entregas de dados numa rede eram feitas diretamente pelos pacotes produzidos pelo IP, o que não está integralmente correto...

Funcionamento de switches Ethernet

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). Isto significa que todo o processamento de pacotes num switch não se dá por interrupções de software, e sim em estruturas de dados que são programadas nestes processadores de rede.
• Um switch filtra tráfego de forma a fazer uma comutação inteligente, porém simples, e que envolva apenas as portas/interfaces interessadas 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-5E". No entanto este endereço físico navega sempre na porção "Destino" do cabeçalho Ethernet, e nunca na porção origem. Portanto, o switch não possui condições de filtrar este tipo de tráfego.
    • 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 em 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 e serviços 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 será 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.

O roteamento IP é orientado ao encaminhamento de pacotes para os endereços de destino citados nos cabeçalhos IP. 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 e refaça 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 muitos 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.
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. Uma 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", o que não é bom num ISP.
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 melhor 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.

Como os roteadores programam as suas tabelas de roteamento?

Após ter ficado esclarecido que os roteadores podem ser programados de duas formas ("rotas estáticas" e "rotas dinâmicas" (por protocolos de roteamento)), o que é até óbvio para muitos, esclarecerei uma informação que é ao mesmo tempo muito básica e fundamental/importante:

Duas ou mais rotas para um mesmo prefixo representando uma rede de destino, ofertadas por dois ou mais protocolos de roteamento distintos

Em algumas redes é comum rodar mais de um protocolo de roteamento e envolver estes protocolos para operarem com os mesmos prefixos de rede. Algo que não é sequer recomendado, mas que, em alguns casos ou projetos, pode ser exigido. Utilize a ilustração a seguir para acompanhar esta linha de raciocínio:

1. O roteador R1 demonstrado está rodando 3 protocolos de roteamento, conforme:
   1. RIPv2 com o R2 <--> R3 <--> R4 <--> R8
   2. IS-IS com o R5 <--> R8
   3. OSPF com o R6 <--> R7 <--> R8
2. O roteador R1 recebe anúncios para a rede 172.16.1.0 /24 via os 3 protocolos de roteamento que possui em operação.
3. Neste caso, por tratar-se rigorosamente do mesmo prefixo de rede (172.16.1.0 /24), o R1 opta pela origem da informação que apresentar a melhor Distância Administativa (Administrative Distance) ou Route Preference.
   1. Considerando o nosso cenário, a seleção da melhor rota dependeria de como cada roteador de cada fabricante lida com essa questão. Em plataforma Cisco e Juniper, a melhor opção seria pela oferta do protocolo de roteamento OSPF.
4. De todas as opções referentes a um mesmo prefixo de rede, oriundas de protocolos de roteamento distintos, apenas uma única opção será selecionada.
   1. Isto é amplamente configurável, no sentido que é possível manipular o AD/RP de todas as rotas ofertadas por um protocolo de roteamento, ou fazendo isto apenas para redes "X" e "Z", por exemplo.

O que é uma Distância Administrativa?

Uma Distância Administrativa ou Preferência por Rotas é um critério pré-codificado (porém configurável) no software do roteador que determina o seu grau de preferência por aceitação de rotas para um determinado prefixo de rede, quando as ofertas ou opções de rotas para este prefixo de rede de destino tiverem sido recebidas de múltiplos protocolos de roteamento.

Os fabricantes implementam isto em seus roteadores para que o equipamento saiba identificar qual das rotas recebidas representa a opção mais confiável. Convenhamos, qual protocolo de roteamento é mais "esperto", o RIPv2 ou o OSPFv2? Ao analisar a tabela demonstrada anteriormente, especificamente nas colunas "Vantagens" e "Limitações", você chegará rapidamente à conclusão de que o OSPFv2 é um protocolo de roteamento muito mais robusto, sofisticado, escalável e rápido, se comparado com o RIPv2. Portanto, se o roteador recebe duas opções de caminhos para a mesma rede (ex: 172.16.1.0 /24), sendo que uma das alternativas é pelo RIPv2 e a outra é por OSPF, não há sombra de dúvidas que o roteador adotará a opção fornecida pelo OSPF.

Neste caso, apenas uma única opção fica instalada/publicada na tabela de roteamento.

OBS: a Distância Administrativa ou Preferência por Rotas é uma preferência local, do próprio roteador, e não é divulgada pelos anúncios realizados pelos próprios protocolos de roteamento! É um mecanismo utilizado para influenciar localmente o que o roteador deve julgar ou considerar como melhor opção e confiabilidade de informação!

A tabela a seguir mostra exemplos de distâncias administrativas para os protocolos de roteamento em equipamentos da Cisco e da Juniper. Em qualquer situação, o menor valor de distância administrativa dita a preferência.

Origem da Informação	AD Cisco	AD Juniper
Connected	0	0
Static	1	5
EIGRP Summary	5	-
OSPF Internal	-	10
IS-IS Level 1 Internal	-	15
IS-IS Level 2 Internal	-	18
BGP External	20	-
EIGRP Internal	90	-
OSPF (como um todo)	110	-
IS-IS (como um todo)	115	-
RIP	120	100
OSPF External	-	150
IS-IS Level 1 External	-	160
IS-IS Level 2 External	-	165
EIGRP External	170	-
BGP (como um todo)	-	170
BGP Internal	200	-

Duas ou mais rotas para um mesmo prefixo representando uma rede de destino, ofertadas pelo mesmo protocolo de roteamento

Quando um mesmo protocolo de roteamento oferecer duas ou mais opções de caminhos sobre um mesmo prefixo de rede de destino, o critério de desempate neste caso passa a ser a métrica associada à rota. O que não tem nada a ver com a Distância Administrativa. Neste caso, a opção que oferecer o menor valor de métrica terá a preferência do roteador.

No exemplo a seguir, temos 3 opções de caminhos para a rede de destino 172.16.1.0 /24, isto na perspectiva do roteador R1. Suponhamos que os custos dos links internos, cada enlace entre dois roteadores, tenha o valor de "1". A soma dos custos - que, no caso do OSPF, é uma conta que fatora uma banda de referência dividida pela banda da interface - dos links internos entre o roteador R1 e a referida rede de destino, atrás do roteador R8, produzirá resultados distintos para cada opção. Será preferida, portanto, aquela opção de caminho que apresentar o menor valor da métrica. Ou o menor "custo", já que estamos falando do OSPF aqui. O caminho "R1 --> R5 --> R8", que possui um custo de 3, será o escolhido.

Neste tipo de situação, já que as 3 opções de caminhos eram ofertas de um mesmo protocolo de roteamento (OSPF), e que apenas uma delas poderia ter sido declarada "a melhor opção", justamente por apresentar o menor custo, apenas essa melhor rota será instalada/publicada na tabela de roteamento do roteador.

Rotas de Métricas Iguais ou Equal Cost Multipath (ECMP)

Haverá situações onde o roteador possuirá duas ou mais opções de caminhos para uma mesma rede de destino e oriundas de ofertas de um mesmo protocolo de roteamento, porém com métricas reportadas de igual valor.Neste caso, o roteador passa a considerar estas opções simultaneamente.

Quantas rotas de métricas iguais um roteador pode suportar por padrão - algo que inclusive tem um número padrão, mas configurável - depende da plataforma/equipamento/fabricante.

A distribuição de tráfego não funciona "por pacotes" e sim por "fluxos de tráfego", e isto flui conforme procedimentos de criação de chaves de consultas obtidas através de dados observáveis dos cabeçalhos dos pacotes entrantes e sendo realizado por procedimento de hashing. Consulte este artigo aqui para conhecer como isto funciona no caso do ECMP: Balanceamento de Trafego em Redes MPLS

Encaminhamento de Pacotes

A partir deste momento você já deve ter uma visão aprimorada dos conceitos de como os roteadores montam as suas tabelas de roteamento! E quais critérios são observados quando selecionando, dentre várias opções, as rotas que deverão de fato constar na tabela de roteamento.

O próximo passo é revisarmos como os roteadores de fato determinam os caminhos e fazem o encaminhamento dos pacotes. Permita-me ser rápido e objetivo aqui:

"O critério (e único!) adotado pelo roteador para escolher uma rota para encaminhar um determinado pacote é aquela rota que possuir o comprimento mais específico.".

E isto independentemente do protocolo do roteamento, ou da Distância Administrativa, ou da Métrica!

Entenda claramente:

• A Distância Administrativa e a Métrica são usadas somente para que o roteador decida sobre quais rotas deverão constar na tabela de roteamento. Apenas isso, e nada mais que isso.
• Das rotas que já estiverem constando na tabela de roteamento, ou seja, que já tiverem sido publicadas, aquela que for mais compatível com o endereço IP de destino citado no cabeçalho IP do pacote recebido pelo roteador (rota mais específica; maior comprimento de bits representando a porção rede); esta opção será selecionada.

Para exemplificar isto bem aqui: todos nós sabemos que o RIPv2 é um protocolo "fraco", com métrica fraca, possui baixa escalabilidade, converge lentamente, etc. E que o protocolo de roteamento OSPFv2 é "esperto", escalável, converge rapidamente, etc. Isto não é mais novidade, certo?

Agora imagine a seguinte situação... um computador deseja se comunicar com o endereço IP 172.16.1.1, e encaminha este pacote para o seu default gateway. O roteador possui neste caso duas rotas que atendem o critério de encaminhamento deste pacote:

• Rota RIPv2: 172.16.0.0 /23
• Rota OSPFv2: 172.16.0.0 /16

Muitos profissionais da área falariam "é lógico que a rota a ser considerada será a do OSPF! Afinal de contas, o OSPF é lindo, formoso, etc.". Errado! Se estudarmos os conceitos de longest prefix match (incidência sobre o prefixo de rede mais específico), descobriremos que, apesar do endereço IP de destino 172.16.1.1 poder ser tecnicamente atendido por duas opções factíveis (172.16.0.0 /23 e 172.16.0.0 /16), a opção que de fato melhor atende é a /23 por ser mais específica no comprimento de bits representando a porção rede. Mesmo que o prefixo /23 da tabela de roteamento seja uma rota RIPv2!

Resumo dos fundamentos L2 e L3

Com base em tudo o que foi apresentado neste artigo:

• Switches são bridges transparentes, e, em hipótese alguma, modificam os endereços físicos (MAC) dos quadros em trânsito.
• Os endereços físicos especificados nos cabeçalhos Ethernet somente são modificados a cada salto pelos elementos L3 apenas (roteadores, firewalls).
  • Todo o cabeçalho Ethernet original de um quadro recebido é completamente descartado pelo roteador, após a validação das instruções contidas neste cabeçalho.
  • Um novo cabeçalho L2 é escrito e empurrado para o pacote, conforme especificações e tecnologia de enlace acomodas na interface de saída associada à rota que foi considerada para encaminhar o pacote.
• Os endereços de rede (IP) não são modificados em momento algum, nem mesmo pelos roteadores, exceto se um recurso de NAT estiver sido definido para este serviço. Aí poderá ocorrer modificações no endereço IP de origem ou destino, dependendo do tipo de NAT que estiver sendo implantado.
• Todos os roteadores executam duas funções básicas no que diz respeito ao encaminhamento de pacotes:
  • Determinar caminhos: o roteador consulta o endereço IP de destino especificado no cabeçalho IP do pacote recebido e faz uma busca pela rota mais específica em sua tabela de roteamento. Juntamente com a rota mais específica encontrada, determina a interface de saída associada àquela rota e a respectiva adjacência (o IP de next-hop para o recebimento daquele pacote).
    • Nas plataformas modernas, todas estas instruções já ficam pré-computadas e mantidas em hardware especializado para que todo este procedimento seja feito no plano de dados.
  • Encaminhamento de pacotes: reescrita do cabeçalho IP (ex: TTL e CRC), reescrita do cabeçalho L2 correspondente à tecnologia de enlace da interface de saída da rota, e a efetiva transmissão do pacote.
• Para instalar ou publicar rotas em sua tabela de roteamento:
  • A Distância Administrativa é usada como critério de desempate quando duas ou mais opções de rotas para um mesmo prefixo de rede de destino existirem, oriundas de protocolos de roteamento distintos.
  • A Métrica é usada como critério de desempate quando selecionando duas ou mais opções de rotas para um mesmo prefixo de rede de destino provenientes do mesmo protocolo de roteamento.
• Roteadores e switches possuem duas áreas sistêmicas bem distintas: o Plano de Controle e o Plano de Dados.
  • Posteriormente publicaremos um artigo sobre este tema!

Considerações finais

Realmente não dá para descrever todos os detalhes, mas nem de longe, em um único artigo! Procurei me ater aqui às questões mais fundamentais, básicas, mas não menos importantes! Se você é um profissional que está interessado em atuar na área de infraestrutura de provedores, você deverá ser bom conhecedor de muitas coisas. Começando pelas questões mais fundamentais como estas discutidas neste artigo.

Para manter a objetividade e o tamanho do artigo, procurei empregar expressões e conceitos bem simples, sem colocar elementos complexos onde não foram necessários. Há muita coisa por vir: switches atualmente fazem muito mais do que o que foi descrito aqui neste artigo, roteadores não encaminham tráfego pela tabela de roteamento diretamente, há centenas de recursos e facilidades presentes tanto em roteadores quanto em switches, os quais acarretam em sofisticadas operações com os pacotes em trânsito numa rede, e uma série de coisas absolutamente novas para muitos que aterrizarem por aqui na Wiki do BPF.

Um tópico por vez. Um tema por vez. Roma não foi construída num dia só!

Espero que este artigo tenha sido útil!

Autor: Leonardo Furtado