Uso impróprio do " tloc-list" ajustado da ação de política; Conduz ao buraco negro de tráfego
Introdução
Este documento descreve o aplicativo impróprio da política da ação que da tloc-lista do grupo aquele conduz ao buraco negro de tráfego em determinadas situações quando o link preferido vai abaixo de mas os caminhos backup estão ainda disponíveis.
Informações de Apoio
Com a finalidade da demonstração e a fim compreender melhor o problema descrito mais tarde, considere este diagrama de topologia:
Além disso, está aqui a tabela que resume configurações de sistema:
| hostname | local-identificação | sistema-IP |
| vedge1 | 13 | 10.155.0.118 |
| vedge3 | 13 | 10.155.0.120 |
| vedge4 | 4 | 10.155.0.50 |
| vsmart1 | 1 | 10.155.0.3 |
VEdge1 e vEdge3 têm uma rota estática configurada que pontos a algum salto seguinte no serviço-lado VPN:
vpn 40 ip route 10.223.115.101/32 192.168.40.10 !
A fim conseguir estes objetivos:
1. Faça o link dos metros Ethernet vEdge1 para ser link preferido para local entrando 13" do tráfego de ingresso o “.
2. Faça o link dos metros Ethernet vEdge3 para ser link em segundo preferido para local entrando 13" do tráfego de ingresso o “.
3. Faça vEdge1 o público-Internet ligar para ser link preferido terço para local entrando 13" do tráfego de ingresso o “.
4. Faça vEdge3 o público-Internet ligar para ser menos link preferido para local entrando 13" do tráfego de ingresso o “.
Esta política de controle do vSmart é configurada:
policy
lists
tloc-list SITE13_TLOC_PREF
tloc 10.155.0.118 color metro-ethernet encap ipsec preference 200
tloc 10.155.0.118 color public-internet encap ipsec preference 100
tloc 10.155.0.120 color metro-ethernet encap ipsec preference 150
tloc 10.155.0.120 color public-internet encap ipsec preference 50
!
prefix-list SITE13_PREFIX
ip-prefix 10.223.115.101/32
!
site-list site13
site-id 13
!
control-policy TE_POLICY_2_SITE4
sequence 10
match route
prefix-list SITE13_PREFIX
!
action accept
set
tloc-list SITE13_TLOC_PREF
!
!
!
default-action accept
!
!
apply-policy
site-list site4
control-policy TE_POLICY_2_SITE4 out
!
!
Problema
Condições normal
o vSmart obtém estas rotas com 4 TLOCs possível como saltos seguintes:
vsmart1# show omp routes 10.223.115.101/32 | b PATH
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
40 10.223.115.101/32 10.155.0.118 35 1002 C,R installed 10.155.0.118 metro-ethernet ipsec -
10.155.0.118 37 1002 C,R installed 10.155.0.118 public-internet ipsec -
10.155.0.120 35 1002 C,R installed 10.155.0.120 metro-ethernet ipsec -
10.155.0.120 37 1002 C,R installed 10.155.0.120 public-internet ipsec -
E ajusta uma preferência para rotas anunciadas em conformidade:
vsmart1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED | b "peer 10.155.0.50" | i Attributes\|originator\|\ tloc\|preference
Attributes:
originator 10.155.0.118
tloc 10.155.0.120, public-internet, ipsec
preference 50
Attributes:
originator 10.155.0.118
tloc 10.155.0.120, metro-ethernet, ipsec
preference 150
Attributes:
originator 10.155.0.118
tloc 10.155.0.118, public-internet, ipsec
preference 100
Attributes:
originator 10.155.0.118
tloc 10.155.0.118, metro-ethernet, ipsec
preference 200
vEdge4 seleciona um TLOC apropriado e instala esta rota na tabela de roteamento:
vedge4# show ip routes 10.223.115.101/32 | b PROTOCOL
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
40 10.223.115.101/32 omp - - - - 10.155.0.118 metro-ethernet ipsec F,S
O encaminhamento de tráfego trabalha como pretendido:
vedge4# traceroute vpn 40 10.223.115.101 Traceroute 10.223.115.101 in VPN 40 traceroute to 10.223.115.101 (10.223.115.101), 30 hops max, 60 byte packets 1 192.168.40.4 (192.168.40.4) 0.835 ms 0.984 ms 1.097 ms 2 192.168.40.10 (192.168.40.10) 2.955 ms 3.056 ms 3.218 ms
Condições de defeito
Eventualmente, uma falha ocorre em vEdge1 e o serviço-lado LAN que enfrenta a relação vai para baixo (ou é fechado pelo administrador a fim executar um teste, por exemplo, o resultado será o mesmo):
vedge1# show interface vpn 40
IF IF IF TCP
AF ADMIN OPER TRACKER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE TYPE IP ADDRESS STATUS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
----------------------------------------------------------------------------------------------------------------------------------------------------------
40 ge0/4 ipv4 192.168.40.4/24 Up Down NA null service 1500 00:50:56:be:91:36 - - 1420 - 129768 0
Porque vEdge1 não tem um salto seguinte válido para a rota 10.223.115.101/32, esta rota é removida do roteamento e das tabelas do forwarding e não o anuncia anymore ao vSmart:
vedge1# show ip routes 10.223.115.101/32 | b PROTO
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
40 10.223.115.101/32 static - - 192.168.40.21 - - - - I
vedge1# show ip fib vpn 40 | i 10.223.115.101/32
vedge1#
vedge1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED
vedge1#
Ao mesmo tempo, vEdge3 ainda anuncia esta rota (este é esperado):
vedge3# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED
ADVERTISED TO:
peer 10.155.0.3
Attributes:
originator 10.155.0.120
label 1002
path-id 35
tloc 10.155.0.120, metro-ethernet, ipsec
ultimate-tloc not set
domain-id not set
site-id 13
overlay-id 1
preference not set
tag not set
origin-proto static
origin-metric 0
as-path not set
unknown-attr-len not set
Attributes:
originator 10.155.0.120
label 1002
path-id 37
tloc 10.155.0.120, public-internet, ipsec
ultimate-tloc not set
domain-id not set
site-id 13
overlay-id 1
preference not set
tag not set
origin-proto static
origin-metric 0
as-path not set
unknown-attr-len not set
o vSmart obtém 2 rotas agora de vEdge3 como esperado:
vsmart1# show omp routes 10.223.115.101/32 | b PATH
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
40 10.223.115.101/32 10.155.0.120 35 1002 C,R installed 10.155.0.120 metro-ethernet ipsec -
10.155.0.120 37 1002 C,R installed 10.155.0.120 public-internet ipsec -
Mas ao mesmo tempo, o vSmart continua a anunciar este:
vsmart1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED | b "peer 10.155.0.50" | i Attributes\|originator\|\ tloc\|preference
Attributes:
originator 10.155.0.120
tloc 10.155.0.120, public-internet, ipsec
preference 50
Attributes:
originator 10.155.0.120
tloc 10.155.0.120, metro-ethernet, ipsec
preference 150
Attributes:
originator 10.155.0.120
tloc 10.155.0.118, public-internet, ipsec
preference 100
Attributes:
originator 10.155.0.120
tloc 10.155.0.118, metro-ethernet, ipsec
preference 200
Como você pode ver, o único autor foi mudado e este é comportamento esperado porque os atos da ação da tloc-lista similares a (em geral) “ajustam o salto seguinte” e ajustam vigorosamente o TLOC errado, daqui a alcançabilidade é perdida.
vedge4# ping vpn 40 10.223.115.101 count 5 Ping in VPN 40 PING 10.223.115.101 (10.223.115.101) 56(84) bytes of data. ^C --- 10.223.115.101 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms vedge4# traceroute vpn 40 10.223.115.101 Traceroute 10.223.115.101 in VPN 40 traceroute to 10.223.115.101 (10.223.115.101), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * *
Solução
Como uma solução, esta aproximação é proposta a fim evitar ajustar a informação errada do salto seguinte TLOC:
policy
lists
tloc-list vedge1-tlocs
tloc 10.155.0.118 color metro-ethernet encap ipsec
tloc 10.155.0.118 color public-internet encap ipsec
!
tloc-list vedge1-tlocs-preference
tloc 10.155.0.118 color metro-ethernet encap ipsec preference 200
tloc 10.155.0.118 color public-internet encap ipsec preference 100
!
tloc-list vedge3-tlocs
tloc 10.155.0.120 color metro-ethernet encap ipsec
tloc 10.155.0.120 color public-internet encap ipsec
!
tloc-list vedge3-tlocs-preference
tloc 10.155.0.120 color metro-ethernet encap ipsec preference 150
tloc 10.155.0.120 color public-internet encap ipsec preference 50
!
!
!
policy
control-policy TE_POLICY_2_SITE4
sequence 10
match route
prefix-list SITE13_PREFIX
tloc-list vedge1-tlocs
!
action accept
set
tloc-list vedge1-tlocs-preference
!
!
!
sequence 20
match route
prefix-list SITE13_PREFIX
tloc-list vedge3-tlocs
!
action accept
set
tloc-list vedge3-tlocs-preference
!
!
!
default-action accept
!
!
Tal política melhora a situação e impede a propaganda da rota com o salto seguinte errado TLOC:
vsmart1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED | b "peer 10.155.0.50" | i Attributes\|originator\|\ tloc\|preference
Attributes:
originator 10.155.0.120
tloc 10.155.0.120, public-internet, ipsec
preference 50
Attributes:
originator 10.155.0.120
tloc 10.155.0.120, metro-ethernet, ipsec
preference 150
Attributes:
originator 10.155.0.120
tloc 10.155.0.120, public-internet, ipsec
preference not set
E em consequência, a alcançabilidade durante todo os cenários de falha é preservada:
vedge4# traceroute vpn 40 10.223.115.101 Traceroute 10.223.115.101 in VPN 40 traceroute to 10.223.115.101 (10.223.115.101), 30 hops max, 60 byte packets 1 192.168.40.6 (192.168.40.6) 0.458 ms 0.507 ms 0.617 ms 2 192.168.40.10 (192.168.40.10) 1.928 ms 1.976 ms 2.069 ms vedge4# ping vpn 40 10.223.115.101 Ping in VPN 40 PING 10.223.115.101 (10.223.115.101) 56(84) bytes of data. 64 bytes from 10.223.115.101: icmp_seq=1 ttl=254 time=0.702 ms 64 bytes from 10.223.115.101: icmp_seq=2 ttl=254 time=0.645 ms 64 bytes from 10.223.115.101: icmp_seq=3 ttl=254 time=0.691 ms 64 bytes from 10.223.115.101: icmp_seq=4 ttl=254 time=0.715 ms 64 bytes from 10.223.115.101: icmp_seq=5 ttl=254 time=0.603 ms ^C --- 10.223.115.101 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 0.603/0.671/0.715/0.044 ms
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)