Host Route e o conceito de especificidade da rota

6 thoughts on “Host Route e o conceito de especificidade da rota”

• Só para ajudar a enganjar mais e aceitando ao seu pedido. Um bom assunto para abordar seria uRPF e proteção de ser um vetor de DDoS (trafego espoofado). Muitas pessoas que estudam o tópico de redes meio que ignorar o uRPF e como funciona. Onde aplicar o loose e o strict. Vejo muito "piloto de BGP" que aplica o modo strict e caga o trafego assimétrico… rs

• Rotas específicas sempre são interessantes de estudar para entender melhor o comportamento do trafego. Uma coisa que eu sempre recomendo aos meus pupilos é pensar como o pacote percorrendo a rede (o Packet Tracer é ótimo para ilustrar isso). Facilita até para fazer regras de NAT.

  Sobre a solução apresentada, sei que o cenário é espartano mas, é importante já pensar no troubleshooting adiantado… rs O uso de rotas estáticas em redes com roteamento dinâmico (vou presumir um OSPF maroto em uma única instância rodando ali no lab entre os R1, R2, R3, R4 e R5). Tendo esse cenário em mente, podemos cair no problema do loop de roteamento (também conhecido como loop estático) se: R4 ficar fora ou um de seus dois enlaces ficarem indisponíveis. Todo o trafego para o Server-52 será descartado. O pacote sairá de R1 em direção ao R3 e, R3 só terá rota para a rede 192.168.50.0/24 aprendida por R1. R1, por meio da rota estática irá mandar novamente o pacote para R3 e assim ficará até ocorrer o esgotamento do TTL, o descarte do pacote e uma mensagem ICMP de TTL exceeded para a origem. Existem algumas soluções e, nem sempre é possível aplicar uma ou outra. Seguem as soluções:

  1 – IP SLA para derrubar a rota estática se o caminho ficar inalcançável. Tem uma complexidade mediana já que, precisaria fazer uso de varias checagens para verificar a viabilidade do caminho e, complicaria ainda mais se houvesse a adição de mais um caminho entre R3 e R5.

  2 – Processos de roteamento diferentes para cada rota (OSPF 1 para rota de cima e OSPF 2 para rota de baixo) com anúncios de rotas diferentes em cada processo. Aumenta a complexidade da gestão da rede e aumenta o uso de recursos de hardware. Este ultimo é menos complicado hoje em dia. A vantagem é deixar o protocolo fazer o "trabalho sujo" dinamicamente e sem risco de loops (claro que se deve levar em conta a questão da redistribuição de rotas entre os processos. Isso é algo bem complexo).

  3 – Trabalhar com filtros das tabelas de rotas que o OSPF envia para a FIB. Ideia menos interessante porque quebra a lógica de funcionamento do OSPF (funciona mas, eu não vejo como boa prática).

  4 – Trocar o protocolo de roteamento para o BGP. Assim pode ser feitos filtros específicos para anúncios e recebimentos de rotas. Pode ser melhorado a performance da convergência de rede se combinar o BGP com o BFD. O lado ruim é que, pode aumentar a complexidade da gestão da rede devido ao split-horizon do iBGP e da necessidade do full-mesh mas, pode se lançar mão de um RR.

  Todas as opções tem suas vantagens e desvantagens e cabe avaliar a melhor opção para o cenário e experiência de cada um…

• Vídeo ótimo Kalau! Só vacilou em dar prioridade em dar prioridade ao IPv4.

  PS.: Estava escrevendo a frase acima quando você falou em dar exemplos em IPv6 também… 😂🤣😂🤣❤️❤️❤️

• Valeu

• Próximo Worshop traz sobre Automação e quem sabe a linguagem Python na área de redes, abç.

• Já fez algum hello world, criando uma rede híbrida, recomendo exemplo com a oracle cloud que tem muitos recursos free

Comments are closed.