Problema de seleção de caminho OMP quando o caminho de saída é forçado no vEdge
Introduction
Este documento descreve o problema que ocorre com um projeto de redundância quando a seleção de caminho do Protocolo de Gerenciamento de Sobreposição (OMP - Overlay Management Protocol) é aplicada em um dispositivo vEdge e não no controlador vSmart que causa resultados indesejados e perda de acessibilidade ao site remoto em caso de falha de link, mesmo se o caminho de backup estiver disponível. Esse problema também é conhecido como "o vSmart não leva em conta o estado da TLOC no vEdge remoto".
Topologia
Para entender melhor o problema, aqui está um diagrama de topologia simples que descreve a configuração:
Configuração
Aqui você pode encontrar a breve descrição da configuração.
- O site DC1 tem cores TLOC "private1" e "biz-internet"
- O site DC2 tem cores TLOC "private1" e "biz-internet"
- O local HQ tem a cor "private1" somente
- Em DC1 e DC2, ambas as cores são usadas para controlar a conexão ao vSmart
Os dois locais DC (DC1 e DC2) anunciam a mesma rede, 198.51.100.0/24.
Em cada site, o vEdge aprende o roteador do DC por meio de algum tipo de protocolo de roteamento dinâmico, por exemplo, BGP (Border Gateway Protocol).
Cada site DC marca o prefixo com uma métrica diferente:
No local DC1 vEdge defina a métrica de origem 32
No local DC2 vEdge setorigmetric 52
| hostname | ID do site | system-ip |
| DC1 | 21 | 10.100.0.21 |
| DC2 | 41 | 10.100.0.41 |
| HQ | 100 | 10.100.0.100 |
| vSmart | 100 | 10.100.0.20 |
Problema
No momento da operação normal:
1. O vSmart recebe 198.51.100.0/24 de DC1 e DC2.
vsmart1# show omp routes 198.51.100.0/24
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
3 198.51.100.0/24 10.100.0.21 36 1003 C,R installed 10.100.0.21 biz-internet ipsec - <===== METRIC 32 (PREFERRED)
10.100.0.21 49 1003 C,R installed 10.100.0.21 private1 ipsec - <===== METRIC 32 (PREFERRED)
10.100.0.41 36 1003 R installed 10.100.0.41 biz-internet ipsec - <===== METRIC 52
10.100.0.41 49 1003 R installed 10.100.0.41 private1 ipsec - <===== METRIC 52
2. O vSmart anuncia à HQ a rota com destino DC1 (via private1 e biz-internet) porque ela tem a menor métrica de origem de acordo com os critérios de seleção de rota OMP.
vsmart1# show omp routes 198.51.100.0/24 vpn 3 detail
---------------------------------------------------
omp route entries for vpn 3 route 198.51.100.0/24
---------------------------------------------------
RECEIVED FROM: <================= RECEIVED FROM vEdge in DC1 in "biz-internet" color
peer 10.100.0.21
path-id 36
label 1003
status C,R
loss-reason not set
lost-to-peer not set
lost-to-path-id not set
Attributes:
originator 10.100.0.21
type installed
tloc 10.100.0.21, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 21
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
RECEIVED FROM: <================= RECEIVED FROM vEdge in DC1 in "private1" color
peer 10.100.0.21
path-id 49
label 1003
status C,R
loss-reason not set
lost-to-peer not set
lost-to-path-id not set
Attributes:
originator 10.100.0.21
type installed
tloc 10.100.0.21, private1, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 21
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
RECEIVED FROM: <================= RECEIVED FROM vEdge in DC2 in "biz-internet" color
peer 10.100.0.41
path-id 36
label 1003
status R
loss-reason origin-metric
lost-to-peer 10.100.0.21
lost-to-path-id 49
Attributes:
originator 10.100.0.41
type installed
tloc 10.100.0.41, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 41
preference not set
tag 1000030041
origin-proto eBGP
origin-metric 52
as-path "65001 65001 65001 65001 65001"
unknown-attr-len not set
RECEIVED FROM: <================= RECEIVED FROM vEdge in DC2 in "private1" color
peer 10.100.0.41
path-id 49
label 1003
status R
loss-reason tloc-id
lost-to-peer 10.100.0.41
lost-to-path-id 36
Attributes:
originator 10.100.0.41
type installed
tloc 10.100.0.41, private1, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 41
preference not set
tag 1000030041
origin-proto eBGP
origin-metric 52
as-path "65001 65001 65001 65001 65001"
unknown-attr-len not set
ADVERTISED TO: <================= WE ADVERTISE TO HQ vEdge ONLY BEST ROUTES WITH METRIC 32
peer 10.100.0.100
Attributes:
originator 10.100.0.21
label 1003
path-id 4410
tloc 10.100.0.21, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
site-id 21
overlay-id 1
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
Attributes:
originator 10.100.0.21
label 1003
path-id 4439
tloc 10.100.0.21, private1, ipsec
ultimate-tloc not set
domain-id not set
site-id 21
overlay-id 1
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
3. O HQ vEdge sinaliza a rota com a TLOC "biz-internet" como "Inv,U" porque este vEdge não tem a TLOC biz-internet.
4. O HQ vEdge sinaliza a rota com TLOC "private1" como "C,I,R" e instala a rota.
Cenário de falha de DC1:
1. No cenário de falha, o uplink DC1 vEdge com cor "private1" falha (a interface fica no estado inativo) enquanto a "biz-internet" permanece ativa.
2. O vSmart recebe 198.51.100.0/24 de DC1 (acessível somente via biz-internet) e DC2 (biz-internet e private1).
3. O vSmart anuncia as rotas do vEdge de HQ para DC1 (via biz-internet) porque o DC1 tem a métrica mais baixa.
vsmart1# show omp routes 198.51.100.0/24 detail
---------------------------------------------------
omp route entries for vpn 3 route 198.51.100.0/24
---------------------------------------------------
RECEIVED FROM:
peer 10.100.0.21
path-id 36
label 1003
status C,R
loss-reason not set
lost-to-peer not set
lost-to-path-id not set
Attributes:
originator 10.100.0.21
type installed
tloc 10.100.0.21, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 21
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
RECEIVED FROM:
peer 10.100.0.41
path-id 36
label 1003
status R
loss-reason origin-metric
lost-to-peer 10.100.0.21
lost-to-path-id 36
Attributes:
originator 10.100.0.41
type installed
tloc 10.100.0.41, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 41
preference not set
tag 1000030041
origin-proto eBGP
origin-metric 52
as-path "65001 65001 65001 65001 65001"
unknown-attr-len not set
RECEIVED FROM:
peer 10.100.0.41
path-id 49
label 1003
status R
loss-reason tloc-id
lost-to-peer 10.100.0.41
lost-to-path-id 36
Attributes:
originator 10.100.0.41
type installed
tloc 10.100.0.41, private1, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 41
preference not set
tag 1000030041
origin-proto eBGP
origin-metric 52
as-path "65001 65001 65001 65001 65001"
unknown-attr-len not set
ADVERTISED TO:
peer 10.100.0.31
Attributes:
originator 10.100.0.21
label 1003
path-id 5906
tloc 10.100.0.21, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
site-id 21
overlay-id 1
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
ADVERTISED TO:
peer 10.100.0.41
Attributes:
originator 10.100.0.21
label 1003
path-id 7689
tloc 10.100.0.21, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
site-id 21
overlay-id 1
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
ADVERTISED TO: <===== THIS IS WHAT WE ADVERTISE TO HQ SITE
peer 10.100.0.100
Attributes:
originator 10.100.0.21
label 1003
path-id 4410
tloc 10.100.0.21, biz-internet, ipsec
ultimate-tloc not set
domain-id not set
site-id 21
overlay-id 1
preference not set
tag 1000030021
origin-proto eBGP
origin-metric 32
as-path "65001 65001 65001"
unknown-attr-len not set
4. O HQ vEdge sinaliza a rota com TLOC "biz-internet" como "Inv,U" porque este vEdge não tem TLOC biz-internet.
O resultado é que o HQ vEdge não pode acessar 198.51.100.0/24.
Solução
O vSmart poderia ter enviado as rotas para DC2 (com métrica mais alta menos preferida) e, nesse caso, o HQ vEdge ainda chegaria ao destino com o uso do TLOC "private1" via DC2, que ainda está ativo:
VEDGE-HQ-1# show bfd sessions site-id 41
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10.100.0.41 41 up private1 private1 192.168.11.1 192.168.41.1 12406 ipsec 7 1000 12:04:02:25 0
Mas não há rota via "private1" TLOC via DC2 no HQ vEdge instalado porque o vSmart já selecionou a rota de Internet de empresa com métrica mais baixa como o melhor caminho. O vSmart não anuncia rotas OMP com métricas diferentes por padrão, portanto, não permite que o dispositivo vEdge de recepção decida qual caminho seguir (e leve em conta as TLOCs disponíveis e seus estados). O vSmart não leva em conta as cores de TLOC disponíveis no dispositivo remoto (HQ vEdge, no nosso caso) para o qual você anuncia a rota e não leva em conta seu estado porque não há nenhum mecanismo desse tipo para controlá-la.
Esse é o caso de canto OMP que pode ser visto em topologia semelhante com o refletor de rota iBGP e peering em endereços de interfaces físicas.
A primeira opção da solução é usar a funcionalidade add path like (RFC7911) disponível no OMP e chamada "send-backup-paths" no vSmart:
omp send-backup-paths
Ele anuncia todos os caminhos disponíveis, de modo que o vEdge de HQ remoto escolhe o caminho com base na disponibilidade de TLOC.
A segunda opção de solução aqui é remover a "métrica definida" da ação da política de rota para o prefixo correspondente em bordas DC1 e DC2 e, em seguida, executar a aplicação centralizada da seleção de rota através da política de controle vSmart como mostrado aqui, por exemplo:
policy
lists
site-list site_11
site-id 11
!
prefix-list PREFIX
ip-prefix 198.51.100.0/24
!
control-policy SET_PREF
sequence 10
match route
prefix-list PREFIX
site-id 21
!
action accept
set
preference 200
!
!
!
sequence 20
match route
prefix-list PREFIX
site-id 41
!
action accept
set
preference 100
!
!
!
default-action accept
!
apply-policy
site-list site_11
control-policy SET_PREF out
!
Aqui, o ID de site 11 é o HQ vEdge e o PREFIX da lista de prefixos contém prefixos que você deseja preferir em relação a uma cor TLOC ou outra. Como ambas as rotas OMP estão no HQ vEdge, uma vez que o vEdge não possa mais acessar a Internet de banda, ele instalará uma rota via private1 na Base de Informações de Roteamento (RIB) da tabela de rotas OMP.
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)