Mecanismos de prevenção de loop (Poison reverse & Split horizon)
Alguns dos protocolos de roteamento utilizados para realização de recursividade, distribuição ou troca de anúncio de rotas internas (no caso do iBGP), utilizados amplamente seriam capazes de gerar loop na topologia caso não existissem os mecanismos poison reverse e split horizon, como é o caso do RIP, IGRP, EIGRP para IGP e do IBGP.
Para iniciar vou explicar o problema fundamental por trás.
Dois dos protocolos citados acima são protocolos conhecidos como vetor de distância (Distance vector) que é o caso do RIP e IGRP. O principal problema dos protocolos DV são os loops de roteamento, uma vez que o algoritmo não pode evitar loop, (algoritmo Bellman-ford), que neste caso poderia acontecer com uma interface se tornando inativa ou roteadores enviando uma informação simultânea, este problema é conhecido como Count to infinity.
Mas o que é o “ Count to infinity “?
Vamos para um exemplo prático, veja abaixo:
R1 sabe que pode chegar até R2 com custo de 1 e até R3 com custo de 2 através de R2.
Sem mecanismo anti loop, caso houvesse uma queda no Link entre R2 e R3,
Teríamos o seguinte comportamento:
R2 saberia que não pode mais chegar até R3 via link direto e removeria da própria tabela, entretanto, seria possível ele receber uma atualização de R1 que pode chegar até R3 com custo 2, como R2 chega até R1 com custo 1, ele atualizaria chegada até R3 com custo de 3, após isso R1 também receberia uma atualização de R2 de que poderia chegar até R3 com custo 4, isso levaria a uma troca infinita, por isso o nome de count to infinity para este problema de protocolos DV.
Então, para solucionar este problema temos os mecanismos Poison Reverse e Split Horizon.
Poison reverse:
Cada protocolo DV, utiliza um valor real de métrica para simular o valor “ infinito “ no caso o RIP utiliza o valor 16 e o EIGRP pode utilizar Delay Infinity ou bandwidth 4.294.967.295, interessante ressaltar que o EIGRP é considerado um advanced distance vector por utilizar uma mescla de DV + LS
No cenário apresentado anteriormente, supomos que tenha uma queda no link entre R3 e R2, R2 enviaria uma atualização para R1 com uma métrica infinita para que R1 veja como impossível alcança-la, (o roteador identifica que uma rota com tal valor é uma rota com falha) o que evitaria o loop.
Entretanto o ponto negativo do poison reverse é que ele pode manter os prefixos na tabela com métrica infinita até o final do holddown timer, o que poderia deixa-lá maior que o necessário momentaneamente.
Split Horizon:
A premissa básica do Split horizon é que qualquer informação de roteamento sobre um pacote nunca poderá ser envianda novamente na direção onde foi recebido, assim evitando loop.
Interessante ressaltar que ambos podem trabalhar em conjunto para ter uma prevenção mais efetiva. O poison reverse é inverso ao Split horizon, então temos aplicação do Split horizon para os roteadores não enviarem rota de uma interface no qual recebeu a mesma, porém se ocorre uma falha o poison reverse anula o Split horizon e envia a rota com métrica infinita na topologia.
Mas no caso do iBGP?
O BGP utiliza o Split horizon e a premissa é a mesma, roteadores que recebem uma rota iBGP não devem anunciar as rotas para outro roteador iBGP, exigindo assim o fullmesh na topologia ou route-reflector no qual já publicado em outro artigo aqui na comunidade, segue o link https://community.cisco.com/t5/artigos-routing-switching/bgp-route-reflectors-redundantes/ta-p/4715049
Certo, falamos de RIP, EIGRP, BGP..., porém como ficam o OSPF e ISIS?
Bom, o OSPF e o ISIS são protocolos Link-state então pelo funcionamento do algoritmo de Djikstra, cada roteador mantém uma arvore de toda a topologia pelo banco de dados, evitando assim qualquer tipo de loop por calcularem individualmente o melhor custo até chegar no prefixo.
Espero que tenham gostado, caso sim, deixe seu like ! este foi um breve artigo sobre os mecanismos de prevenção de loop.
qualquer duvida ou sugestão podem entrar em contato via https://www.linkedin.com/in/natanael-oliveira-36b475111/