Use uma rota estática para a interface Null0 para prevenção de loop

Introdução

Este documento descreve como uma Rota Estática para a interface Nula pode evitar loops de roteamento.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nas versões de software e hardware:

• Versão do software Cisco IOS 12.3.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

A interface Nula é usada tipicamente para impedir loops de roteamento. O Enhanced Interior Gateway Routing Protocol (EIGRP), por exemplo, sempre cria uma rota para a interface Null0 quando ela resume um grupo de rotas. Sempre que um protocolo de roteamento é resumido, isso significa que o roteador pode receber tráfego para qualquer endereço IP dentro desse resumo. Devido a nem todos endereços IP estarem sempre em uso, existe o risco de pacotes de loops, no caso de rotas padrão, serem usados no roteador que recebe o tráfego para o resumo.

Sintaxe do comando

Uma rota estática para Null0 é uma rota estática normal, exceto que aponta para a interface Null0, que é uma interface virtual do Cisco IOS. Consulte a seção ip route do Capítulo: IP Routing Protocol-Independent Commands A a R para obter mais informações sobre o comando ip route . A próxima seção apresenta um exemplo de como usar o comando ip route para criar uma rota estática para Null0.

Exemplo

Um cenário comum onde você pode precisar adicionar uma rota estática para Null0 é o de um servidor de acesso que tem muitos clientes discando. Esse cenário faz com que as rotas de host sejam instaladas na tabela de roteamento do servidor de acesso. Para garantir a acessibilidade a esses clientes, sem inundar toda a rede com rotas de host, outros roteadores na rede normalmente têm uma rota de sumarização que aponta para o servidor de acesso. Nesse tipo de configuração, o servidor de acesso deve ter a mesma rota sumarizada que aponta para a interface Null0 do servidor de acesso. Caso contrário, os loops de roteamento podem ocorrer quando os hosts externos tentam acessar endereços IP que não estão atribuídos atualmente a um cliente discado, mas que fazem parte da rota sumarizada. Isso ocorre porque o servidor de acesso devolveria os pacotes pela rota padrão do servidor de acesso à rede central, porque o servidor de acesso não tem uma rota de host específica para o destino.

Considere este exemplo:

Topologia de rede

Um ISP pequeno (ISP-R1) fornece a um dos usuários um bloco de rede de 192.168.0.0/16. Neste exemplo, o usuário dividiu 192.168.0.0/16 em redes /24 e usa apenas 192.168.1.0/24 e 192.168.2.0/24 no momento. No roteador ISP-R1, o ISP configura uma rota estática para 192.168.0.0/16 em direção ao roteador do usuário (cust-R2). Em seguida, o ISP se conecta a um ISP de backbone, representado pelo roteador BB-R3. O roteador BB-R3 envia uma rota padrão ao ISP-R1 e recebe a rede 192.168.0.0/16 via BGP do ISP-R1.

A acessibilidade agora é garantida da Internet (roteador ISP de backbone BB-R3) para o roteador de usuário cust-R2, pois o cust-R2 tem uma rota padrão configurada para apontar para o ISP-R1. No entanto, se os pacotes forem destinados a blocos de rede que não estejam em uso fora do intervalo 192.168.0.0/16, o roteador cust-R2 usará a rota padrão para ISP-R1 para encaminhar esses pacotes. Em seguida, os pacotes fazem loop entre ISP-R1 e cust-R2 até que o TTL expire. Isso pode ter um grande impacto na utilização da CPU e do link do roteador. Um exemplo de onde esse tráfego para endereços IP não utilizados pode vir pode ser ataques de negação de serviço, varredura de blocos IP para encontrar hosts vulneráveis, etc.

Configurações relevantes:

version 12.3
!
hostname cust-R2
!
ip subnet-zero
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!         
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
!
interface Ethernet1/0
 ip address 192.168.2.1 255.255.255.0
!
interface Serial2/0
 ip address 10.0.0.2 255.255.255.252

!--- This interface leads to ISP-R1.

!
ip classless
ip route 0.0.0.0 0.0.0.0 10.0.0.1

!--- Default route going to ISP-R1.

!
end

version 12.3
!
hostname ISP-R1
!
ip subnet-zero
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252

!--- Interface to cust-R2.

!
interface Serial1/0
 ip unnumbered Loopback0

!--- Interface going to BB-R3.

!
router bgp 65501
 no synchronization
 network 192.168.0.0 mask 255.255.0.0

!--- ISP-R1 injects 192.168.0.0/16 into BGP to 
!--- advertise it to BB-R3.

 neighbor 10.3.3.3 remote-as 65503
 neighbor 10.3.3.3 ebgp-multihop 255
 no auto-summary
!
ip classless
ip route 10.3.3.3 255.255.255.255 Serial1/0
ip route 192.168.0.0 255.255.0.0 Serial0/0

!--- The first route is necessary for the eBGP 
!--- session to BB-R3 to come up.
!--- The route to 192.168.0.0/16 points towards cust-R2.

!
!
end

version 12.3
!
hostname BB-R3
!
ip subnet-zero
!
!
interface Loopback0
 ip address 10.3.3.3 255.255.255.255
!
interface Serial2/0
 ip unnumbered Loopback0

!--- This interface goes to ISP-R1.

!
router bgp 65503
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 65501
 neighbor 10.1.1.1 ebgp-multihop 255
 neighbor 10.1.1.1 default-originate 

!--- BB-R3 injects a default route into BGP and 
!--- sends it to ISP-R1.

 no auto-summary
!
ip classless
ip route 10.1.1.1 255.255.255.255 Serial2/0

!--- This route points to ISP-R1 and is 
!--- used to establish the eBGP peering.

!
end

Fluxo de pacote

Observação: alguns comandos debug foram ativados nos roteadores para ilustrar melhor o fluxo de pacotes, notavelmente debug ip packet e debug ip icmp. Não ative esses comandos em um ambiente de produção, a menos que você compreenda totalmente as consequências.

BB-R3#ping ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

*Oct  6 09:36:45.355: IP: tableid=0, s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), routed via FIB
*Oct  6 09:36:45.355: IP: s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), len 100, sending.
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:36:50.943: ICMP: time exceeded rcvd from 10.0.0.1

BB-R3 envia uma única solicitação ICMP a um endereço IP dentro do bloco 192.168.0.0/16 que não está em uso em cust-R2. BB-R3 recebe um tempo ICMP excedido de volta do ISP-R1.

No ISP-R1:

18:50:22: IP: tableid=0, s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB

O pacote inicial é recebido em serial1/0 no ISP-R1 de BB-R3 e é encaminhado para cust-R2 em serial0/0 como esperado. O mesmo pacote chega de volta ao ISP-R1 em serial0/0 e é enviado imediatamente para a mesma interface, para cust-R2, devido a esta rota:

ISP-R1#show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Advertised by bgp 65501
  Routing Descriptor Blocks:
  * directly connected, via Serial0/0
      Route metric is 0, traffic share count is 1

O que acontece no Cust-R2 que faz com que ele envie esse tráfego de volta para o ISP-R1?

Em cust-R2:

*Oct  6 09:41:43.495: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.515: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB
*Oct  6 09:41:43.515: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.555: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB

Você pode ver que o cust-R2 envia esses pacotes de volta ao ISP-R1, por causa dessa rota:

cust-R2#show ip route 192.168.20.1 longer-prefixes 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.0.0.1 to network 0.0.0.0

cust-R2#

O roteador cust-R2 não tem uma rota para 192.168.20.1 porque essa rede não está em uso na rede do usuário, portanto, a melhor rota para 192.168.20.1 é a rota padrão que aponta para ISP-R1.

O resultado é que os pacotes entram em loop entre ISP-R1 e cust-R2 até que o TTL expire.

Se a solicitação ICMP tivesse ido para um endereço IP dentro de uma rede que está em uso, esse resultado não ocorreria. Por exemplo, se a solicitação ICMP fosse para 192.168.1.x, que está diretamente conectado em cust-R2, não teria ocorrido nenhum loop:

cust-R2#show ip route 192.168.1.1
Routing entry for 192.168.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0
      Route metric is 0, traffic share count is 1

A solução para esse problema é configurar uma rota estática para Null0 para 192.168.0.0/16 em cust-R2.

cust-R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
cust-R2(config)#ip route 192.168.0.0 255.255.0.0 Null0
cust-R2(config)#end
cust-R2#
*Oct  6 09:53:18.015: %SYS-5-CONFIG_I: Configured from console by console

cust-R2#show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

Se você agora reenviar a solicitação ICMP de BB-R3 para 192.168.20.1, cust-R2 enviará esse tráfego para Null0, o que acionará um ICMP inalcançável para ser gerado.

BB-R3#ping ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
U
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:54:33.051: ICMP: dst (10.3.3.3) host unreachable rcv from 10.0.0.2

Pode haver situações em que o uso de uma rota estática sumarizada para Null0 não seja viável. Por exemplo, se no exemplo anterior:

• O bloco 192.168.1.0/24 está conectado a outro roteador que disca para o cust-R2 via ISDN

• ISP-R1 não aloca 192.168.0.0/16, mas apenas 192.168.1.0/24

• Ocorre uma desconexão do link ISDN

Observação: o resultado seria que os pacotes em trânsito ou os aplicativos que tentam acessar esse bloco de endereços IP criariam o mesmo loop de roteamento descrito anteriormente.

Observação: para corrigir esse loop de roteamento, você deve usar o comando ip route 192.168.1.0 255.255.255.0 Null0 200 para configurar uma rota estática flutuante para Null0 para 192.168.1.0/24. O 200 no comando é a distância administrativa. Consulte O que é distância administrativa? para obter mais informações.

Observação: como usamos uma distância administrativa mais alta do que qualquer protocolo de roteamento, se a rota para 192.168.1.0/24 através do link ISDN ficar inativa, o cust-R2 instalará uma rota estática flutuante. Em seguida, os pacotes são enviados para Null0 até que o link ISDN se torne ativo.

Informações Relacionadas

• Suporte técnico e downloads da Cisco