Um dos aspectos mais intrigantes dos roteadores Cisco, especialmente para quem o roteamento é novidade, é como o roteador escolhe qual rota é a melhor entre as apresentadas pelos protocolos de roteamento, pela configuração manual e vários outros meios. Embora a seleção da rota seja muito mais simples do que você imagina, para entendê-la completamente é preciso ter algum conhecimento sobre como os roteadores Cisco funcionam.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Existem três processos envolvidos na criação e na manutenção da tabela de roteamento em um roteador Cisco:
Diversos processos de roteamento, que realmente executam um protocolo de rede (ou de roteamento), como o Enhanced Interior Gateway Protocol (EIGRP), Border Gateway Protocol (BGP), Intermediate System-to-System (IS-IS) e Open Shortest Path First (OSPF).
A própria tabela de roteamento, que aceita informações dos processos de roteamento e responde às solicitações de informações do processo de encaminhamento.
O processo de encaminhamento solicita informações da tabela de roteamento para decidir sobre o encaminhamento de pacotes.
Vamos examinar a interação entre os protocolos de roteamento e a tabela de roteamento para entender como a tabela é construída.
As principais considerações ao criar a tabela de roteamento são:
Distância administrativa É a medida de fidelidade da origem da rota. Se um roteador aprende sobre um destino de mais de um Routing Protocol, a distância administrativa será comparada e a preferência será atribuída às rotas com distância administrativa menor. Em outras palavras, é a credibilidade da origem da rota.
Métrica - Esta é uma medida utilizada pelo Routing Protocol para calcular o melhor caminho para determinado destino, se ele aprender vários caminhos para o mesmo destino. Cada protocolo de roteamento usa uma métrica diferente.
Comprimento do prefixo
À medida que cada processo de roteamento recebe atualizações e outras informações, ele escolhe o melhor caminho para qualquer destino e tenta instalar esse caminho na tabela de roteamento. Por exemplo, se o EIGRP descobrir um caminho para 10.1.1.0/24 e decidir que esse caminho específico é o melhor caminho EIGRP para esse destino, ele tentará instalar o caminho que descobriu na tabela de roteamento.
O roteador decide se deve ou não instalar as rotas apresentadas pelos processos de roteamento com base na distância administrativa da rota especificada. Se esse caminho tiver a menor distância administrativa para esse destino (quando comparado a outras rotas da tabela), ele será instalado na tabela de roteamento. Se essa rota não for a que tem a melhor distância administrativa, a rota será rejeitada.
Para compreender isso melhor, vamos analisar um exemplo. Suponha que um roteador tenha quatro processos de roteamento em execução: EIGRP, OSPF, RIP e IGRP. Agora, todos os quatro processos aprenderam várias rotas para a rede 192.168.24.0/24, e cada um escolheu o melhor caminho para essa rede através de seus processos e métricas internas.
Cada um desses quatro processos tenta instalar sua rota em direção a 192.168.24.0/24 na tabela de roteamento. A cada um dos processos de roteamento é atribuída uma distância administrativa, que é usada para decidir qual rota deve ser instalada.
Distâncias administrativas padrão | |
---|---|
Conectado | 0 |
Estático | 1 |
eBGP | 20 |
EIGRP (interna) | 90 |
IGRP | 100 |
OSPF | 110 |
IS-IS | 115 |
RIP | 120 |
EIGRP (externo) | 170 |
iBGP | 200 |
Rota do resumo EIGRP | 5 |
Como a rota EIGRP interna possui a melhor distância administrativa (quanto menor a distância administrativa, maior será a preferência), ela estará instalada na tabela de roteamento.
O que fazem os outros protocolos, RIP, IGRP e OSPF, com os roteadores que não foram instalados? E se a rota preferida, aprendida com EIGRP, falhar? O software Cisco IOS® aplica duas abordagens para resolver este problema: A primeira é fazer com que cada processo de roteamento tente instalar suas melhores rotas periodicamente. Se a rota preferida falhar, a próxima melhor rota (de acordo com distância administrativa) sucede na tentativa seguinte. A outra solução é para que o Routing Protocol que falhou instale sua rota na tabela para manter a rota e solicite que o processo da tabela de roteamento informe se o melhor caminho falhar.
O primeiro método é usado para protocolos que não possuem suas próprias tabelas de informação de roteamento, como o IGRP. Sempre que o IGRP recebe uma atualização sobre uma rota, ele tenta instalar as informações atualizadas na tabela de roteamento. Se já houver uma rota para esse mesmo destino na tabela de roteamento, a tentativa de instalação falhará.
Com relação a protocolos que têm seu próprio banco de dados de informações de roteamento, como EIGRP, IS-IS, OSPF, BGP e RIP, uma rota de backup é registrada quando a tentativa inicial de instalação da rota falhar. Se a rota instalada na tabela de roteamento falhar por algum motivo, o processo de manutenção da tabela de roteamento chamará cada processo do protocolo de roteamento que tenha registrado uma rota de backup e solicitará a reinstalação da rota na tabela de roteamento. Se houver vários protocolos com rotas de backup registradas, a rota preferencial será escolhida com base na distância administrativa.
A distância administrativa padrão pode não ser sempre adequada para a sua rede; pode ser necessário ajustá-la para que rotas RIP tenham preferência em relação a rotas IGRP, por exemplo. Antes de explicar como ajustar as distâncias administrativas, precisamos verificar as implicações de alterar a distância administrativa.
Alterar a distância administrativa nos protocolos de roteamento pode ser muito perigoso! Mudar as distâncias padrão pode gerar loops de roteamento e outras singularidades em sua rede. Recomendamos que tenha cautela ao alterar a distância administrativa, e somente após considerar o que deseja obter e todas as conseqüências de suas ações.
Para protocolos inteiros, alterar a distância é relativamente fácil; basta configurar a distância usando o comando distance no modo de subconfiguração do processo de roteamento. Você também pode alterar a distância de rotas descobertas em uma origem, somente em alguns protocolos, e alterar a distância em algumas rotas apenas. Para obter mais informações, consulte Ajustar a distância administrativa para seleção de rota em exemplo de configuração de roteadores Cisco IOS.
Para rotas estáticas, você pode alterar a distância de cada rota inserindo uma distância após o comando ip route:
ip route network subnet mask next hop distance
Você não pode alterar a distância administrativa de todas as rotas estáticas de uma vez.
As rotas são escolhidas e criadas na tabela de roteamento com base na distância administrativa do Routing Protocol. As rotas aprendidas com o protocolo de roteamento com a menor distância administrativa são instaladas na tabela de roteamento. Se houver vários caminhos para o mesmo destino a partir de um único Routing Protocol, os vários caminhos terão a mesma distância administrativa e o melhor caminho será selecionado com base nas métricas. Métricas são valores associados a rotas específicas, classificando-as das mais preferidas para as menos preferidas. Os parâmetros utilizados para determinar as métricas são diferentes para os vários protocolos de roteamento. O caminho com a menor métrica é selecionado como o caminho ideal e instalado na tabela de rotealento. Se houver vários caminhos para o mesmo destino com métricas iguais, o balanceamento de carga será realizado nesses caminhos de custos iguais. Para obter mais informações sobre o balanceamento de carga, consulte ?Como Funciona o Balanceamento de Carga?
Vamos olhar para um outro cenário para ver como o roteador lida com outra situação comum: diferentes comprimentos de prefixo. Vamos supor, novamente, que um roteador tenha quatro processos de roteamento em execução e cada processo tenha recebido estas rotas:
EIGRP (interno): 192.168.32.0/26
RIP: 192.168.32.0/24
OSPF: 192.168.32.0/19
Quais dessas rotas serão instaladas na tabela de roteamento? Já que as rotas internas de EIGRP têm as melhores distâncias administrativas, é tentador assumir que a primeira será instalada. No entanto, como cada uma dessas rotas tem um comprimento de prefixo diferente (máscara de sub-rede), elas são consideradas como destinos diferentes e serão instaladas na tabela de roteamento.
Vejamos como o mecanismo de encaminhamento usa as informações da tabela de roteamento para tomar decisões de encaminhamento.
Vamos dar uma olhada nas três rotas que acabamos de instalar na tabela de roteamento para ver como elas estão no roteador.
router# show ip route .... D 192.168.32.0/26 [90/25789217] via 10.1.1.1 R 192.168.32.0/24 [120/4] via 10.1.1.2 O 192.168.32.0/19 [110/229840] via 10.1.1.3 ....
Se um pacote chegar a uma interface de roteador destinado a 192.168.32.1, qual rota o roteador escolherá? Depende do comprimento de prefixo ou do número de bits definido na máscara de sub-rede. Prefixos mais longos são sempre preferidos a prefixos mais curtos ao encaminhar um pacote.
Nesse caso, um pacote destinado a 192.168.32.1 é direcionado a 10.1.1.1, porque 192.168.32.1 cai dentro da rede 192.168.32.0/26 (192.168.32.0 para 192.168.32.63). Ele também será incluído nas outras duas rotas disponíveis, mas 192.168.32.0/26 possui o prefixo mais longo na tabela de roteamento (26 bits versus 24 ou 19 bits).
Da mesma forma, se um pacote destinado a 192.168.32.100 chega a uma das interfaces do roteador, ele é encaminhado para 10.1.1.2, porque o 192.168.32.100 não se inclui no 192.168.32.0/26 (192.168.32.0 até 192.168.32.63), mas se inclui no destino 192.168.32.0/24 (192.168.32.0 até 192.168.32.255). Novamente, ele cai também no intervalo coberto por 192.168.32.0/19, mas 192.168.32.0/24 tem um comprimento de prefixo mais longo.
Com freqüência, a posição do comando ip classless configuration nos processos de roteamento e encaminhamento é complicada. Na realidade, o IP classless afeta somente a operação dos processos de encaminhamento de IOS; não afeta a forma como a tabela de roteamento é construída. Se o IP classless não estiver configurado (usando o comando no ip classless), o roteador não vai encaminhar pacotes para super-redes. Como exemplo, vamos colocar novamente três rotas na tabela de roteamento e rotear os pacotes por meio do roteador.
Nota: Se a supernet ou a rota padrão for aprendida via IS-IS ou OSPF, o comando no ip classless configuration é ignorado. Nesse caso, o comportamento de switching de pacotes funciona como se o ip classless tivesse sido configurado.
router# show ip route .... 172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks D 172.30.32.0/20 [90/4879540] via 10.1.1.2 D 172.30.32.0/24 [90/25789217] via 10.1.1.1 S* 0.0.0.0/0 [1/0] via 10.1.1.3
Lembrando que a rede 172.30.32.0/24 inclui os endereços que vão de 172.30.32.0 até 172.30.32.255, e a rede 172.30.32.0/20 inclui os endereços que vão de 172.30.32.0 até 172.30.47.255. Podemos, então, tentar fazer switch de três pacotes por meio dessa tabela de roteamento e ver quais são os resultados.
Um pacote destinado a 172.30.32.1 é encaminhado ao 10.1.1.1, pois esta é a correspondência de prefixo mais longa.
Um pacote destinado para 172.30.33.1 é encaminhado para 10.1.1.2, porque esta é a correspondência de prefixo mais longo.
Um pacote destinado a 192.168.10.1 é encaminhado para 10.1.1.3; como essa rede não existe na tabela de roteamento, esse pacote é encaminhado para a rota padrão.
Um pacote destinado a 172.30.254.1 é descartado.
A resposta é surpreendente. Desses quatro, o último pacote é descartado. Está descartado porque o seu destino, 172.30.254.1, está dentro de uma grande rede, 172.30.0.0/16, mas o roteador não reconhece essa sub-rede específica dentro da rede maior.
Essa é a essência de roteamento classful: Se uma parte da rede principal é conhecida, mas a sub-rede (dentro dessa rede principal) à qual o pacote está destinado é desconhecida, o pacote é cancelado.
O aspecto mais confuso dessa regra é que o roteador somente usa a rota padrão caso a rede de destino principal não constar da tabela de roteamento.
Isto pode causar problemas em uma rede em que um local remoto, com uma conexão de volta para o restante da rede, não esteja executando protocolos de roteamento, conforme ilustrado.
O roteador de local remoto é configurado como este:
interface Serial 0 ip address 10.1.2.2 255.255.255.0 ! interface Ethernet 0 ip address 10.1.1.1 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 10.1.2.1 ! no ip classless
Com essa configuração, os hosts no site remoto podem alcançar destinos na Internet (através da nuvem de 10.x.x.x), mas não os destinos dentro da nuvem 10.x.x.x, que é a rede corporativa. Como o roteador remoto sabe sobre alguma parte da rede 10.0.0.0/8, as duas sub-redes diretamente conectadas e nenhuma outra sub-rede de 10.x.x.x, ele presume que essas outras sub-redes não existem e descarta quaisquer pacotes destinados a elas. Tráfego destinado à Internet, porém, não tem um destino na faixa 10.x.x.x de endereços e, portanto, é corretamente roteado pela rota padrão.
A configuração de ip classless no roteador remoto resolve esse problema, permitindo que o roteador ignore os classfull boundaries das redes de sua tabela de roteamento, roteando simplesmente para o maior prefixo correspondente que encontrar.
Resumindo, tomar uma decisão de encaminhamento consiste efetivamente em três conjuntos de processos: os protocolos de roteamento, a tabela de roteamento e o processo real que toma uma decisão de encaminhamento e alterna os pacotes. Estes três conjuntos de processos são ilustrados, junto com sua relação, abaixo.
A compatibilidade de prefixo mais longo sempre vence entre as rotas realmente instaladas na tabela de roteamento, ao passo que o Routing Protocol com a menor distância administrativa sempre vence ao instalar rotas na tabela de roteamento.