Fundamentos de Roteamento para Provedores - Histórico de revisão

Leonardo.furtado em 05h07min de 12 de maio de 2020

2020-05-12T05:07:36Z

Leonardo.furtado em 01h17min de 9 de janeiro de 2020

2020-01-09T01:17:57Z

Leonardo.furtado em 22h48min de 26 de dezembro de 2018

2018-12-26T22:48:45Z

Leonardo.furtado em 04h11min de 17 de dezembro de 2018

2018-12-17T04:11:48Z

Leonardo.furtado em 20h13min de 16 de dezembro de 2018

2018-12-16T20:13:35Z

Leonardo.furtado: Categorização

2018-12-16T20:05:41Z

Categorização

Leonardo.furtado: Primeira conclusão.

2018-12-15T05:48:33Z

Primeira conclusão.

Mostrar alterações

Leonardo.furtado: Mais rascunho

2018-12-15T03:51:00Z

Mais rascunho

Leonardo.furtado: Rascunho.

2018-12-15T02:54:40Z

Rascunho.

Página nova

=== 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:
[[Arquivo:Bpf-fundamentosroteamento-2.png|centro|miniaturadaimagem|650x650px]]
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".
[[Arquivo:Bpf-fundamentosroteamento-3.png|centro|miniaturadaimagem|650x650px]]
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:
[[Arquivo:Bpf-fundamentosroteamento-4.png|centro|miniaturadaimagem|900x900px]]
É 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:
[[Arquivo:Bpf-fundamentosroteamento-5.png|centro|miniaturadaimagem|900x900px]]
# O cenário apresenta dois computadores com interesse de trocar dados: o computador representado à esquerda da topologia, e o computador vizinho à direita.
## '''''Computador 1''''':
### Endereço IP: 10.1.1.1
### Endereço MAC: 1111.1111.aaaa
### Default Gateway: 10.1.1.254
## '''''Computador 2''''':
### Endereço IP: 10.2.2.2
### Endereço MAC: 6666.6666.ffff
# Quanto aos elementos ativos de rede presentes:
## '''''Roteador 1''''':
### Interface 1:
#### Endereço IP: 10.1.1.254
#### Endereço MAC: 2222.2222.bbbb
### Interface 2:
#### Endereço IP: 10.0.0.1
#### Endereço MAC: 3333.3333.ccccc
## '''''Roteador 2''''':
### Interface 1:
#### Endereço IP: 10.0.0.2
#### Endereço MAC: 4444.4444.dddd
### Interface 2:
#### Endereço IP: 10.2.2.254
#### Endereço MAC: 5555.5555.eeee
# O Computador 1 produz dados para serem enviados para o Computador 2:
## O Computador 1 consulta o endereço IP de destino do Computador 2 (10.2.2.2), num procedimento conhecido por '''''Logical AND'''''.
### 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.
### O Computador 1 possui um ''default gateway'' configurado, que, neste caso, é o endereço IP da interface 1 do Roteador 1.
#### Neste momento, a composição do cabeçalho IP na pilha de protocolos do Computador 1 é:
##### IP de Origem: 10.1.1.1
##### IP de Destino: 10.2.2.2
### 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.
#### No entanto, o Computador 1 precisa determinar o endereço físico (MAC) associado ao endereço IP do default gateway/Roteador 1.
##### O Computador 1 consulta o seu ARP cache para identificar esta informação, se possuir.
##### 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.
### O Roteador 1 responde à requisição de ARP feita pelo Computador 1, que por sua vez armazena esta informação em sua tabela ARP.
## O Computador 1 escreve um quadro Ethernet apropriado, onde destacamos os principais campos:
### Endereço Físico de Origem: 1111.1111.aaaa (o endereço MAC do próprio Computador 1)
### Endereço Físico de Destino: 2222.2222.bbbb (o endereço MAC da interface 1 do Roteador 1, seu default gateway).
### EtherType: 0x0800 (denotando que o protocolo sendo transportado pelo quadro Ethernet é o IPv4).
## 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:
[[Arquivo:Bpf-fundamentosroteamento-6.png|centro|miniaturadaimagem|800x800px]]
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:
# '''Administrativamente, através de rotas estáticas'''
# '''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:
[[Arquivo:Bpf-fundamentosroteamento-7.png|centro|miniaturadaimagem|650x650px]]

A tabela a seguir sumariza as diferenças entre estes protocolos de roteamento:
{| class="wikitable"
|+
!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.
|}

← Edição anterior		Edição das 05h07min de 12 de maio de 2020
Linha 1:		Linha 1:
	=== Fundamentos de Roteamento para Provedores ===		=== Fundamentos de Roteamento para Provedores ===
		+
		+	==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====
		+	Consulte [[Direitos Autorais Licenca de Uso\|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].
		+
	'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''		'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''

@@ Linha 1: / Linha 1: @@
 === 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:
@@ Linha 505: / Linha 508: @@
 Espero que este artigo tenha sido útil!
-'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.Furtado Leonardo Furtado]'''
+'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''
 [[Categoria:Capacitação]]
 [[Categoria:Roteamento]]

@@ Linha 505: / Linha 505: @@
 Espero que este artigo tenha sido útil!
-'''Autor: Leonardo Furtado'''
+'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.Furtado Leonardo Furtado]'''
 [[Categoria:Capacitação]]
 [[Categoria:Roteamento]]

@@ Linha 481: / Linha 481: @@
 === 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.
+* 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.

@@ Linha 486: / Linha 486: @@
 ** 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, <u>exceto</u> 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.
 === Considerações finais ===

← Edição anterior		Edição das 20h05min de 16 de dezembro de 2018
Linha 497:		Linha 497:

	'''Autor: Leonardo Furtado'''		'''Autor: Leonardo Furtado'''
		+	[[Categoria:Capacitação]]
		+	[[Categoria:Roteamento]]

@@ Linha 169: / Linha 169: @@
 |Processo de configuração manual e sem
 mecanismos nativos de convergência.
 |-
 |'''RIPv2'''
@@ Linha 352: / Linha 338: @@
 é bem lento neste quesito.
 |}