IP : Encapsulamento de Roteamento Genérico (GRE)

Estados da interface do túnel GRE e que impactos eles

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve as circunstâncias diferentes que podem afetar o estado de uma relação do túnel de encapsulamento de roteamento genérico (GRE).

Contribuído por Wen Zhang e por Atri Basu, engenheiros de TAC da Cisco.

Informações de Apoio

Os túneis GRE são projetados ser completamente apátridas. Isto significa que cada ponto final de túnel não mantém nenhuma informação sobre o estado ou Disponibilidade do ponto final de túnel remoto. Uma consequência desta é que, à revelia, o roteador local do ponto final de túnel não tem a capacidade para derrubar o protocolo de linha da interface do túnel GRE se a extremidade remota do túnel é inacessível. A capacidade para marcar uma relação como quando a extremidade remota do link não está disponível é usada para baixo a fim remover todas as rotas (especificamente rotas estáticas) na tabela de roteamento que usarem essa relação como a interface externa. Especificamente, se o protocolo de linha para uma relação é mudado a para baixo, a seguir algumas rotas estáticas que indicarem que a relação está removida da tabela de roteamento. Isto permite a instalação de uma rota estática (de flutuação) alternativa ou o Policy Based Routing (PBR) a fim selecionar um salto seguinte ou uma relação alternativa. Igualmente há outros aplicativos que provocam quando uma relação muda o estado; por exemplo, da “<b-interface> Interface de backup”.

Três estados de túnel diferentes

Há três estados possíveis em que uma interface do túnel GRE pode estar:

  1. Up/Up - Isto implica que o túnel é inteiramente - funcional e está passando o tráfego. É ambos adminstratively ascendentes e seu protocolo está acima também.
  2. Para baixo de Adminstratively/para baixo - Isto implica que a relação esteve fechada administrativamente.
  3. Up/down - Isto implica que, mesmo que o túnel esteja administrativamente acima, algo faz com que o protocolo de linha na relação esteja para baixo.

Quando uma interface de túnel é criada primeiramente e nenhuma outra configuração lhe está aplicada, a relação é nenhum fechado à revelia:

Router#show run interface tunnel 1
Building configuration...

Current configuration : 40 bytes
!
interface Tunnel1
 no ip address
end

Neste estado, a relação é sempre up/down:

Router(config-if)#do show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         172.16.52.1     YES NVRAM  administratively down down    
GigabitEthernet0/1         14.36.128.49    YES NVRAM  down                  down    
GigabitEthernet0/2         unassigned      YES NVRAM  down                  down    
GigabitEthernet0/3         unassigned      YES NVRAM  down                  down    
Loopback1                  192.168.2.1     YES NVRAM  up                    up      
Tunnel1                    unassigned      YES unset  up                    down

Isto é porque a relação é permitida administrativamente, mas desde que não tem um origem de túnel ou um destino de túnel, o protocolo de linha está inativo.

A fim fazer este Up/Up da relação, um origem de túnel válido e o destino de túnel devem ser configurados:

Router#show run interface tunnel  1
Building configuration...

Current configuration : 113 bytes
!
interface Tunnel1
 ip address 1.1.1.1 255.255.255.0
 tunnel source Loopback1
 tunnel destination 10.0.0.1
end

Router#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         172.16.52.1     YES NVRAM  up                    up      
GigabitEthernet0/1         14.36.128.49    YES NVRAM  down                  down    
GigabitEthernet0/2         unassigned      YES NVRAM  down                  down    
GigabitEthernet0/3         unassigned      YES NVRAM  down                  down    
Loopback0                  unassigned      YES unset  up                    up      
Loopback1                  192.168.2.1     YES manual up                    up      
Tunnel1                    1.1.1.1         YES manual up                    up      

A sequência precedente mostra aquela:

  • Um origem de túnel válido consiste em toda a relação que estiver própria no estado up/up e tiver um endereço IP de Um ou Mais Servidores Cisco ICM NT configurado nele. Por exemplo, se o origem de túnel foi mudado a Loopback0, a interface de túnel iria para baixo mesmo que Loopback0 estivesse no estado up/up:

    Router(config-if)#int tun 1
    Router(config-if)#tunnel source loopback 0
    Router(config-if)#
    *Sep  6 19:51:31.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface
    Tunnel1, changed state to down
  • Um destino de túnel válido é um que é roteável. Contudo, não tem que ser alcançável, que pode ser visto deste teste de ping:

    Router#show ip route 10.0.0.1
    % Network not in table
    Router#show ip route | inc 0.0.0.0
    Gateway of last resort is 172.16.52.100 to network 0.0.0.0
    S*    0.0.0.0/0 [1/0] via 172.16.52.100
    Router#ping 10.0.0.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
    .....
    Success rate is 0 percent (0/5)

Até agora, o túnel foi configurado como um túnel GRE (P2P) ponto a ponto, que fosse o padrão. Se este túnel devia ser mudada a um túnel multiponto GRE (mGRE), a seguir tudo que é exigido para que o túnel esteja em um estado ascendente é um origem de túnel válido (um túnel mGRE pode ter muitos destinos de túnel, de modo que não possa ser usado para controlar o estado da interface de túnel):

Router#show run interface tunnel 1
Building configuration...

Current configuration : 129 bytes
!
interface Tunnel1
 ip address 1.1.1.1 255.255.255.0
 no ip redirects
 tunnel source Loopback1
 tunnel mode gre multipoint
end

Router#show ip interface brief | include Tunnel
Tunnel1                    1.1.1.1         YES manual up                    up   

Em qualquer momento, se a interface de túnel é fechada adminstratively, o túnel entra imediatamente em um administrativamente para baixo/estado inativo:

Router#show run interface tunnel 1
Building configuration...

Current configuration : 50 bytes
!
interface Tunnel1
 no ip address
 shutdown
end

Router#show ip interface brief | include Tunnel
Tunnel1                    unassigned      YES unset  administratively down down    

Estado do túnel GRE P2P

Normalmente, uma interface do túnel GRE P2P vem acima assim que estiver configurada com um endereço de origem de túnel ou uma relação válida que seja ascendente e um endereço IP de destino de túnel que seja roteável segundo as indicações da seção anterior.

Protocolo de linha para baixo localmente no roteador

Em circunstâncias normais, há somente três razões para que um túnel GRE esteja no estado up/down:  

  • Não há nenhuma rota, que inclui a rota padrão, ao endereço de destino de túnel.
  • A relação que ancora o origem de túnel está para baixo.
  • A rota ao endereço de destino de túnel é através do túnel próprio, que conduz à recursão.

Estas três regras (rota de falta, relação para baixo, e destino de túnel roteado incorretamente) são problemas locais ao roteador nos pontos finais de túnel e não cobrem problemas na rede de intervenção ou nos outros recursos relativa ao túnel GRE que pôde ser configurado. Este documento descreve as encenações onde outros fatores puderam influenciar o estado do túnel GRE.

Keepalives do túnel GRE

As regras básicas não cobrem o caso em que os pacotes tunelado de GRE são enviados com sucesso, mas são perdidas antes que alcancem a outra extremidade do túnel. Isto causa os pacotes de dados que atravessam o túnel GRE ser “preto furado”, mesmo que uma rota alternativa que se use PBR ou uma Rota estática flutuante através de uma outra relação esteja potencialmente disponível. O Keepalives na interface do túnel GRE é usado a fim resolver o Keepalives desta edição é usado da mesma forma em interfaces física.

Com Cisco IOS ® Software libere 12.2(8)T, ele é possível para configurar o Keepalives em uma interface do túnel GRE P2P. Com esta mudança, a interface de túnel fechou dinamicamente se o Keepalives falha por um determinado período de tempo. A fim compreender melhor como o Keepalives do túnel GRE trabalha, satisfaça referem o Keepalives do túnel GRE.

Nota: O Keepalives do túnel GRE é somente válido e tem um efeito em túneis GRE P2P; são inválidos e não têm nenhum efeito em túneis mGRE.

Interfaces de túnel multipontos GRE (mGRE)

Para interfaces de túnel mgre, desde que não há nenhum destino de túnel fixo, algumas das verificações precedentes para túneis P2P não são aplicáveis. Estão aqui as razões que o protocolo de linha de um túnel mGRE pode estar em um estado inativo:

  • A relação do origem de túnel está em um estado inativo.
  • Se a característica do controlo estatal de relação está permitida para o Dynamic Multipoint VPN (DMVPN) e nenhuns dos servidores de próximo salto (NHS) não responda, a seguir o protocolo de linha está posto em um estado inativo. Para detalhes na característica do controlo estatal de relação, veja o monitoramento de funcionamento do túnel DMVPN e o manual de configuração da recuperação.

Dependências no estado de redundância

Quando um endereço IP de Um ou Mais Servidores Cisco ICM NT do origem de túnel é configurado enquanto um endereço IP de Um ou Mais Servidores Cisco ICM NT da Redundância (por exemplo, um endereço do IP virtual do protocolo de roteador do standby recente (HSRP VIP)), então o estado da interface de túnel segue o estado de redundância.

Isto adicionou uma verificação adicional, que mantivesse tais interfaces de túnel no estado inativo do protocolo de linha até as mudanças de estado de redundância ao ACTIVE. Neste exemplo, uma configuração padrão desconfigurado da zona ipc faz com que a Redundância esteja no estado da NEGOCIAÇÃO e mantém tais interfaces de túnel em um estado inativo:

Router#show redundancy state
my state = 3 -NEGOTIATION
peer state = 1 -DISABLED
Mode = Simplex
Unit ID = 0

Maintenance Mode = Disabled
Manual Swact = disabled (system is simplex (no peer unit))
Communications = Down Reason: Simplex mode

client count = 16
client_notification_TMR = 60000 milliseconds
RF debug mask = 0x0
Router#show interface tunnel100
Tunnel100 is up, line protocol is down
Hardware is Tunnel
Internet address is 172.16.1.100/24
MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.122.162.254 (GigabitEthernet0/1)
Tunnel Subblocks:
src-track:
Tunnel100 source tracking subblock associated with GigabitEthernet0/1
Set of tunnels with source GigabitEthernet0/1, 2 members (includes
iterators), on interface <OK>
Tunnel protocol/transport multi-GRE/IP
<SNIP>

Troubleshooting

Além do que a verificação das razões esboçadas previamente, a linha avaliação do túnel do estado para ver se há o túnel raciocina para baixo pode ser considerada com o comando oculto do túnel x da interface de túnel da mostra como mostrado aqui:

Router#show tunnel interface tunnel 100
Tunnel100
Mode:multi-GRE/IP, Destination UNKNOWN, Source GigabitEthernet0/1
Application ID 1: unspecified
Tunnel Subblocks:
src-track:
Tunnel100 source tracking subblock associated with GigabitEthernet0/1
Set of tunnels with source GigabitEthernet0/1, 2 members (includes
iterators), on interface <OK>
Linestate - current down
Internal linestate - current down, evaluated down - interface not up
Tunnel Source Flags: Local
Transport IPv4 Header DF bit cleared
OCE: IP tunnel decap
Provider: interface Tu100, prot 47
Performs protocol check [47]
Performs Address save check
Protocol Handler: GRE: key 0x64, opt 0x2000
ptype: ipv4 [ipv4 dispatcher: drop]
ptype: ipv6 [ipv6 dispatcher: drop]
ptype: mpls [mpls dispatcher: drop]
ptype: otv [mpls dispatcher: drop]
ptype: generic [mpls dispatcher: drop]

 Nota: Há um realce aberto para fazer para baixo o túnel raciocinar mais explícito a fim indicar que é devido ao estado de redundância que não é ativo. Isto é seguido pela identificação de bug Cisco CSCuq31060.

Informações Relacionadas


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 118361