Introdução a Redistribuição
A redistribuição é o processo de injetar rotas aprendidas em um protocolo de roteamento dentro de outro protocolo. Em ambientes corporativos e de provedores isso geralmente significa levar rotas internas de um IGP como OSPF, IS-IS ou EIGRP para um EGP como o BGP, e o inverso quando necessário. O objetivo é interligar domínios de roteamento diferentes sem exigir que toda a rede fale o mesmo protocolo, mantendo a autonomia operacional de cada área.
Ao redistribuir do IGP para o BGP você transforma conhecimento de alcance interno em anúncios externos. Isso é comum em borda, onde o roteador aprende prefixos de serviços internos pelo IGP e os publica no BGP para vizinhos upstream, parceiros ou IX. A prática recomendada é não despejar a tabela inteira do IGP no BGP. Prefira anunciar somente os prefixos de serviços e, quando fizer sentido, anunciar rotas agregadas.
O uso de sumarização reduz o tamanho da tabela e limita a propagação de instabilidades. Métricas internas não significam nada no BGP, então o controle de preferência deve ser feito com atributos BGP como local preference, as path, med e comunidades.
No caminho inverso, de EGP para IGP, a regra é ser ainda mais conservador. O caso clássico é injetar apenas uma rota default aprendida no BGP para o IGP, de modo que os roteadores internos saibam para onde enviar tráfego destinado à internet. Redistribuir a tabela completa do BGP para dentro do IGP quase sempre é um erro. O custo é alto em processamento e memória, a convergência degrada e o risco de loops aumenta.
Redistribuição cria fronteiras entre políticas diferentes. Por isso o controle fino é essencial. Use listas de prefixo e route maps para selecionar o que entra e o que sai, defina métricas coerentes ao injetar rotas em IGPs baseados em custo, marque rotas com tags para evitar realimentação acidental em casos de redistribuição mútua e previna loops.
Em OSPF, por exemplo, prefira tipos de LSA externos adequados ao desenho, escolha entre E1 e E2 de forma consciente, e combine com sumarização em áreas de borda. Em IS-IS, ajuste níveis e distâncias administrativas para manter preferências claras entre rotas internas e externas.
A distância administrativa e a preferência de caminho precisam refletir a intenção de engenharia de tráfego. A rede deve preferir rotas internas de um IGP estável e só usar rotas redistribuídas quando a fonte primária não existe. Em BGP, local preference governa a saída dentro do seu AS e deve alinhar com o que o IGP considera alcançável. Em cenários multihomed, atributos como med e community aplicadas na redistribuição ajudam a guiar o tráfego de forma previsível.
Redistribuição de IGP para IGP
A redistribuição IGP para IGP é ocorre quando precisamos interconectar domínios diferentes (ex.: OSPF com EIGRP, OSPF com IS-IS, OSPF com RIP e etc) convertendo rotas internas de um protocolo em rotas externas do outro. Parece simples, mas os protocolos têm métricas e semânticas distintas, então o desenho precisa tratar três pontos: tradução de métrica (seed metric), preferência administrativa e prevenção de loops/realimentação.
Princípios e riscos:
- Anuncie só o necessário. Prefira sumarizar na borda (quando possível) ou anunciar apenas prefixos de serviços. Evite "inundar" um IGP com toda a tabela do outro.
- Métricas não são comparáveis. OSPF/IS-IS usam custo, EIGRP usa métrica composta (bandwidth+delay), RIP usa saltos. Defina seed metric explícita ao redistribuir, senão o equipamento usa defaults nem sempre ideais.
- Distância administrativa (AD) deve manter a preferência pelo “nativo” e usar o redistribuído como último recurso. Ex.: EIGRP interno 90, OSPF 110, IS-IS 115, RIP 120 (em Cisco); ajuste se necessário.
- Evite loops entre IGPs. Use route tags e filtros simétricos: tudo que entra com tag X é bloqueado na volta. Em OSPF, rotas redistribuídas viram LSAs externas (E1/E2); em IS-IS, vão como externas com tag/atributos; em RIP, viram rotas RIPv2 com métrica definida.
- Pontos únicos e determinísticos. Se possível, faça redistribuição em poucos nós bem controlados (e preferencialmente apenas em uma direção). Se precisar de mão-dupla, use tags + sumarização para quebrar a possibilidade de realimentação.
Recomendações práticas:
Escolha do tipo externo no OSPF:
- E2 (default) mantém custo externo fixo; simples e previsível.
- E1 soma o custo intra-área, útil para "puxar" tráfego ao gateway mais próximo.
IS-IS: use metric-style wide, defina métrica explícita para externos e restrinja nível (L2 na borda, por padrão). Use route-maps para tag e filtragem.
EIGRP: defina default-metric (bandwidth, delay, reliability, load, mtu) para qualquer redistribuição; sem isso, a rota pode não ser instalada/anunciada.
Padrão de filtros (tags) para mão-dupla
Use a mesma tag nos dois lados e bloqueie o retorno dessa tag no caminho inverso:
No Cisco:
! Exemplo Cisco IOS – OSPF ↔ EIGRP (IPv4)
ip prefix-list EXPORT_OSPF seq 10 permit 10.10.0.0/16 le 24
ip prefix-list EXPORT_EIGRP seq 10 permit 172.16.0.0/16 le 24
! ----- OSPF lado A -----
router ospf 10
redistribute eigrp 100 subnets route-map OSPF_FROM_EIGRP
!
route-map OSPF_FROM_EIGRP deny 5
match tag 65000 ! evita realimentação
route-map OSPF_FROM_EIGRP permit 10
match ip address prefix-list EXPORT_EIGRP
set metric 20
set metric-type type-1 ! E1 (ou use type-2 para E2)
set tag 65000
! ----- EIGRP lado A -----
router eigrp 100
address-family ipv4 unicast autonomous-system 100
af-interface default
passive-interface
exit-af-interface
network 172.16.0.0 0.0.255.255
default-metric 10000 100 255 1 1500 ! BW, delay, rel, load, MTU
redistribute ospf 10 route-map EIGRP_FROM_OSPF
exit-address-family
!
route-map EIGRP_FROM_OSPF deny 5
match tag 65000
route-map EIGRP_FROM_OSPF permit 10
match ip address prefix-list EXPORT_OSPF
set metric 10000 100 255 1 1500
set tag 65000
No FRRouting:
# Exemplo FRRouting – OSPF ↔ IS-IS
ip prefix-list EXPORT_OSPF seq 10 permit 10.10.0.0/16 le 24
ip prefix-list EXPORT_ISIS seq 10 permit 172.16.0.0/16 le 24
route-map ISIS_FROM_OSPF deny 5
match tag 65000
route-map ISIS_FROM_OSPF permit 10
match ip address prefix-list EXPORT_OSPF
set metric 20
set tag 65000
route-map OSPF_FROM_ISIS deny 5
match tag 65000
route-map OSPF_FROM_ISIS permit 10
match ip address prefix-list EXPORT_ISIS
set metric 20
set metric-type type-1
set tag 65000
router isis CORE
net 49.0001.0000.0000.0001.00
is-type level-2
metric-style wide
redistribute ospf route-map ISIS_FROM_OSPF
router ospf
redistribute isis route-map OSPF_FROM_ISIS
Redistribuição de interface diretamente conectada
A redistribuição de interfaces diretamente conectadas acontece quando um protocolo de roteamento é instruído a incluir rotas de redes que estão diretamente ligadas ao roteador, mas que não pertencem ao conjunto de interfaces que participam nativamente daquele protocolo.
Isso é útil quando se deseja propagar essas redes para outros roteadores que não as alcançariam de forma automática. Mesmo que uma rede esteja conectada fisicamente ao roteador, ela só será anunciada por um protocolo de roteamento como o OSPF ou EIGRP se estiver configurada explicitamente com esse protocolo. Caso contrário, é necessário redistribuí-la como rota conectada.
Ao fazer isso, o protocolo trata a rede como se tivesse sido aprendida por outro meio e a propaga para os vizinhos. Esse tipo de redistribuição exige atenção especial à definição de métricas, já que uma rota conectada não possui todos os atributos necessários de um protocolo de roteamento, e é preciso atribuir manualmente os valores que permitirão sua correta integração no processo de decisão de rotas.
Além disso, é recomendável aplicar filtros e políticas de controle para evitar o vazamento de rotas indesejadas, já que a redistribuição de rotas conectadas pode incluir interfaces de gerenciamento, redes administrativas ou sub-redes específicas que não deveriam ser propagadas.
No exemplo abaixo, estamos configurando o BGP para redistribuir apenas a rota da interface Loopback0, que está diretamente conectada ao roteador. Mesmo sendo uma rota conectada, ela não será anunciada automaticamente pelo BGP. Para que o BGP anuncie essa rota, é necessário redistribuí-la explicitamente com o comando redistribute connected. No entanto, como não queremos redistribuir todas as interfaces conectadas, usamos um route-map para filtrar apenas a interface desejada.
route-map REDISTRIBUTE-LOOPBACK0 permit 10
match interface Loopback0
!
router bgp 65001
address-family ipv4
redistribute connected route-map REDISTRIBUTE-LOOPBACK0
O route-map chamado REDISTRIBUTE-LOOPBACK0 usa a cláusula match interface Loopback0, que faz com que apenas rotas originadas da interface Loopback0 sejam permitidas para redistribuição. Assim, interfaces como Ethernet, WAN, ou outras loopbacks não serão redistribuídas por esse comando, mesmo que estejam ativas no roteador. Isso dá maior controle sobre quais rotas conectadas serão propagadas via BGP, evitando o anúncio acidental de redes de gerenciamento, links ponto a ponto ou outras sub-redes internas.
Redistribuição entre eBGP para iBGP
O comando bgp redistribute-internal é usado para permitir que rotas aprendidas por sessões iBGP possam ser redistribuídas em protocolos de roteamento internos, como OSPF ou EIGRP. Por padrão, o BGP não redistribui rotas internas (iBGP) nesses protocolos, apenas rotas externas (eBGP).
Esse comportamento é uma medida de segurança para evitar loops de roteamento e problemas de propagação excessiva de prefixos. Quando você precisa que rotas iBGP estejam visíveis para roteadores que não participam do BGP, é necessário ativar esse comando, pois apenas com redistribute bgp dentro do OSPF ou EIGRP não será suficiente. As rotas iBGP continuarão sendo ignoradas. Após habilitar o bgp redistribute-internal, essas rotas passam a ser consideradas para redistribuição, desde que você as selecione com filtros adequados.
No entanto, esse comando deve ser usado com extremo cuidado. Se uma rota iBGP for redistribuída para o OSPF, ela pode voltar para outro roteador BGP que redistribui OSPF em BGP, e isso pode criar um loop de roteamento, algo que o próprio BGP tenta evitar ao não reanunciar rotas iBGP para outros peers iBGP.
Além disso, dependendo da quantidade de rotas redistribuídas, pode haver impacto na performance do protocolo interno. É necessário usar route-maps e prefix-lists para restringir com precisão quais prefixos serão redistribuídos, garantindo que apenas os realmente necessários sejam propagados. Depois de ativar o comando no BGP, é obrigatório limpar as sessões BGP com clear ip bgp * para que as alterações surtam efeito.
O uso desse comando é indicado apenas quando há um planejamento claro e justificativa técnica sólida, como por exemplo quando você tem roteadores em uma rede que não rodam BGP mas precisam alcançar redes aprendidas por ele. Mesmo assim, a recomendação da Cisco é sempre aplicar filtros rigorosos e revisar o caminho das rotas para evitar loops.
Redistribuição de rota estática
A redistribuição de rota estática ocorre quando você instrui um protocolo de roteamento dinâmico, como OSPF, EIGRP ou BGP, a incluir em seus anúncios as rotas que foram configuradas manualmente no roteador, ou seja, rotas estáticas. Por padrão, essas rotas não são compartilhadas com outros roteadores, já que são locais e não fazem parte do domínio do protocolo.
Ao redistribuí-las, o protocolo passa a tratá-las como rotas válidas para serem propagadas pela rede. Essa prática é útil quando você precisa anunciar uma rede que não está conectada diretamente ao roteador ou quando quer garantir o alcance de redes específicas por meio de caminhos bem definidos. No entanto, assim como em qualquer redistribuição, é essencial ter cuidado para não redistribuir todas as rotas estáticas indiscriminadamente.
Isso pode incluir rotas de escape, rotas de teste ou rotas de blackhole que não deveriam ser propagadas. Por isso, o uso de filtros com route-map, prefix-list ou distribute-list é altamente recomendado. Além disso, o protocolo de roteamento requer que a rota esteja presente na tabela de roteamento para ser redistribuída com sucesso.
Em alguns casos, é necessário adicionar a opção redistribute static acompanhada de um route-map que define exatamente quais prefixos estáticos serão aceitos. A prática também exige atenção com a atribuição de métricas adequadas, já que a rota estática não carrega atributos de custo nativos do protocolo que a redistribuirá.