[P&R] Redistribuição de Rotas – parte 2

Conforme prometido, vamos dar prosseguimento ao primeiro post sobre redistribuição de rotas! Pelo visto, este assunto interessou a alguns! É realmente um tópico interessante, vale a pena conhecer um pouco mais. Bom, como eu já havia mencionado no post anterior, redistribuição de rotas é assunto apenas de exames Cisco mais avançados, mas ainda assim, não machuca conhecer alguma coisa sobre o assunto mesmo aqueles que ainda estão estudando para o CCNA.

Recapitulando o que vimos, a utilização de um protocolo de roteamento para anunciar rotas aprendidas via outros meios (como um protocolo de roteamento diferente, rotas estáticas ou mesmo rotas diretamente conectadas) é conhecida como redistribuição. Sempre que mais de um protocolo de roteamento existir em uma rede, a troca de informações entre eles (redistribuição) será necessária. Alguns pontos importantes já foram mencionados no post anterior, e serão mais profundamente analisados neste.

1) Métricas

Quando redistribuímos rotas aprendidas por um protocolo, em outro, as métricas adotadas por cada protocolo desempenham um papel muito importante. Cada protocolo utiliza métricas distintas. Por exemplo, RIP utiliza como métrica exclusivamente a contagem de saltos, enquanto IGRP e EIGRP utilizam uma métrica composta, baseada por default em largura de banda e atraso da linha, mas podendo incluir também a carga e a confiabilidade do link, e MTU. Quando adotamos redistribuição entre estes protocolos, precisamos definir métricas que sejam funcionais ao protocolo destino. Existem basicamente 2 métodos para a definição de métricas durante uma redistribuição. Vamos observar a figura abaixo para os exemplos.

O router central age como “ponte” entre os protocolos RIP e OSPF na rede ilustrada. É ele quem fará a redistribuição de um para o outro.

a) Definição da métrica para redistribuições específicas, somente:

router rip
 redistribute static metric 1
 redistribute ospf 1 metric 2

Neste exemplo, rotas estáticas serão “injetadas” no protocolo RIP com métrica 1 (1 salto), e rotas aprendidas via OSPF serão “injetadas” no protocolo RIP com métrica 2 (2 saltos).

b) Outro método é definir uma métrica default, que será adotada para toda e qualquer redistribuição:

router rip
 redistribute static
 redistribute ospf 1
 default-metric 1

Neste exemplo, tanto rotas estáticas quanto aprendidas via OSPF serão injetadas na rede RIP com métrica 1 (1 salto).

2) Distância Administrativa (AD)

Lembremo-nos que, se um router encontra-se com mais de um protocolo de roteamento ativo e rotas para uma mesma rede destino são aprendidas por intermédio destes diferentes protocolos, a decisão de qual vai para a tabela de roteamento é feita pela AD (Distância Administrativa) de cada protocolo. Para ver a tabela AD, cheque este link (http://www.cisco.com/en/US/customer/tech/tk365/technologies_tech_note09186a0080094823.shtml). Quando estamos fazendo redistribuição de rotas, entretanto, o processo de seleção de rotas via AD pode causar problemas, como loops de roteamento, problemas de convergência, ou roteamento ineficiente. Observe a figura abaixo:

Na topologia ilustrada pela figura acima, se R1 está rodando RIP, e R2 e R5 estão rodando RIP e IGRP e redistribuindo informações de um no outro mutuamente, podemos ter um problema em potencial. Por exemplo, tanto R2 quanto R5 aprendem sobre a rede 192.168.1.0 via R1, utilizando o protocolo RIP. Esta informação é, então, redistribuída no IGRP. R2 aprende sobre a rede 192.168.1.0 via R3, enquanto R5 aprende sobre esta mesma rede via R4, ambos usando IGRP. IGRP possui uma distância administrativa menor que o RIP (100 contra 120) e, portanto, rotas aprendidas via IGRP serão preferidas sobre as aprendidas via RIP. Temos então um loop de roteamento em potencial. Supondo que o mecanismo de split horizon esteja ativado, ainda assim teremos o problema de convergência, ou seja, o tempo necessário para esta rede chegar à um acordo sobre quais rotas devem ser consideradas será bastante elevado.

Se R2 e R5 também estiverem redistribuindo IGRP em RIP (processo este conhecido como redistribuição mútua, onde um protocolo é redistribuído em outro, e vice-versa) e a rede 192.168.1.0 não se encontrar diretamente conectada em R1 (ex: R1 aprende esta rede de algum router acima dele), existe a chance de R1 aprender esta rede de R2 ou R5, ao invés de aprender da fonte original da rota.

NOTA IMPORTANTE: As “leis” de redistribuição em routers Cisco é ditada pela Cisco (são proprietárias). Nestas regras, a Cisco estabelece que uma rota, para ser redistribuída precisa existir na tabela de roteamento. Rotas com menor AD sempre estarão presentes na tabela de roteamento. Por exemplo, se uma rota estática for redistribuída para IGRP em R5, e posteriormente IGRP for redistribuído para RIP neste mesmo router (R5), a rota estática não será redistribuída para RIP pois ela nunca entrou na tabela de roteamento do IGRP. Isso ocorre pois rotas estáticas possuem AD=1, enquanto rotas IGRP possuem AD=100. Para fazer com que a rota estática seja redistribuída para IGRP em R5, é necessário utilizar o comando “redistribute static”, dentro do modo “router rip”.

Como eu já havia dito no post anterior (parte 1), é devido à problemas potenciais como os descritos anteriormente que redistribuição deve sempre ser muito bem planejada. A idéia de realizar testes de mesa, em cenários assim, é muito bem-vinda.

No próximo (e último) post sobre este assunto vamos nos aprofundar ainda mais nos processos de redistribuição. Vamos ver exemplos mais avançados, e também vamos ver o papel dos filtros nos processos de redistribuição.

Abs e até lá!

Marco Filippetti