Contents

Introdução

Informações de Apoio

Problema

Introdução

Este documento descreve o impacto de um atributo de comunidade estendida MAC do roteador configurado incorretamente em uma estrutura da ACI quando recebido de um par BGP (Border Gateway Protocol) externo.

Informações de Apoio

Com o BGP, há uma opção para enviar comunidade e atributos de comunidade estendida com os prefixos que são anunciados aos peers BGP. Esses atributos de comunidade nos permitem modificar políticas de roteamento e alterar dinamicamente a forma como o tráfego roteado é tratado.

Problema

Quando o atributo de comunidade estendida MAC do roteador é enviado com um prefixo AFI IPv4 de um peer de BGP externo para uma estrutura ACI, a programação incorreta de FIB e HAL ocorre em qualquer folha na estrutura que recebe a rota da(s) folha(s) de borda através do processo MP-BGP interno. Isso ocorre porque o atributo extcommunity de RMAC pertence à família de endereços BGP L2VPN EVPN e quando é injetado na família de endereços BGP IPv4, ele é rejeitado. Isso ocorre devido a uma violação da regra 5.2 (Uniform-Propagation-Mode), que é descrita no documento IETF intitulado "EVPN Interworking with IPVPN". Na página 15, no item 4c, a questão específica é chamada:

4.  As discussed, Communities, Extended Communities and Large

Communities SHOULD be kept by the gateway PE from the originating

SAFI route.  Exceptions of Extended Communities that SHOULD NOT

be kept are:

C.  All the extended communities of type EVPN.

The gateway PE SHOULD NOT copy the above extended communities

from the originating ISF route to the re-advertised ISF route.

Link para o documento: Interfuncionamento EVPN com IPVPN

Aqui está um exemplo do problema com o iBGP, no entanto, o problema também é visto com o eBGP.

Diagrama de topologia:

Diagrama de topologia

Configure o mapa de rotas no dispositivo de peer BGP externo (Roteador 1) e defina o atributo extcommunity EVPN RMAC:

Router-1# show run | sec route-map

route-map RMAC permit 10

set extcommunity evpn rmac aaaa.bbbb.cccc

Na configuração da família de endereços IPv4 vizinhos de BGP, configure as comunidades estendidas de BGP e configure o mapa de rotas na direção de saída:

Router-1# show run bgp

<output omitted>

feature bgp

router bgp 65001

vrf example

router-id 192.168.20.20

address-family ipv4 unicast

network 192.168.20.0/24

neighbor 192.168.30.30

remote-as 65001

update-source loopback1

address-family ipv4 unicast

send-community extended

route-map RMAC out

Verifique o status de BGP no BL 101:

leaf-101# show ip bgp 192.168.20.0 vrf example:example

BGP routing table information for VRF example:example, address family IPv4 Unicast

BGP routing table entry for 192.168.20.0/24, version 40 dest ptr 0xa0fec840

Paths: (1 available, best #1)

Flags: (0x80c001a 00000000) on xmit-list, is in urib, is best urib route, is in HW, exported

vpn: version 2725, (0x100002) on xmit-list

Multipath: eBGP iBGP

Advertised path-id 1, VPN AF advertised path-id 1

Path type (0xa96485b8): internal 0x18 0x0 ref 0 adv path ref 2, path is valid, is best path

AS-Path: NONE, path sourced internal to AS

192.168.20.20 (metric 5) from 192.168.20.20 (192.168.20.20)

Origin IGP, MED not set, localpref 100, weight 0 tag 0, propagate 0

Extcommunity:

RT:65001:2162688

COST:pre-bestpath:163:1879048192

Router MAC:aaaa.bbbb.cccc

***Notice that the router mac is present here.***

VNID:2162688

VRF advertise information:

Path-id 1 not advertised to any peer

VPN AF advertise information:

Path-id 1 advertised to peers:

10.0.216.65        10.0.216.66

Verificar RIB na CL 102:

leaf-102# show ip route 192.168.20.0 vrf example:example

IP Route Table for VRF "example:example"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

192.168.20.0/24, ubest/mbest: 1/0

*via 10.0.210.70%overlay-1, [200/0], 00:00:43, bgp-65001, internal, tag 65001, rwVnid: vxlan-2162688

recursive next hop: 10.0.210.70/32%overlay-1

***Notice that we have the route here and our next-hop address is correct (showing the TEP IP of BL 101). Also, notice that there is an rwVnid entry here.***

leaf-102# acidiag fnvread | grep 101

101        1             leaf-101      <output omitted>     10.0.210.70/32    leaf         active   0

Verificar FIB na CL 102:

module-1(DBG-elam-insel6)# show forwarding route 192.168.20.0 vrf example:example

ERROR: no longest match in IPv4 table 0xf5df36b0

***No entry is present.***

Verifique a tabela HAL na CL 102:

module-1(DBG-elam-insel6)# show platform internal hal l3 routes | grep 192.168.20.0

***No entry is present.***

Pings do EP (Host 1) para o host em uma rede externa que vem do par BGP externo (192.168.20.20):

Host-1# ping 192.168.20.20 vrf example

PING 192.168.20.20 (192.168.20.20): 56 data bytes

Request 0 timed out

Request 1 timed out

Request 2 timed out

Request 3 timed out

Request 4 timed out

--- 192.168.20.20 ping statistics ---

5 packets transmitted, 0 packets received, 100.00% packet loss

***No connectivity.***

Verifique o ELAM na CL 102:

leaf-102# vsh_lc

module-1# debug platform internal roc elam asic 0

module-1(DBG-elam)# trigger reset

module-1(DBG-elam)# trigger init in-select 6 out-select 0

module-1(DBG-elam-insel6)# set outer ipv4 src_ip 192.168.10.10 dst_ip 192.168.20.20

module-1(DBG-elam-insel6)# start

module-1(DBG-elam-insel6)# stat

ELAM STATUS

===========

Asic 0 Slice 0 Status Armed

Asic 0 Slice 1 Status Triggered

module-1(DBG-elam-insel6)# ereport

Python available. Continue ELAM decode with LC Pkg

ELAM REPORT

<output omitted>

------------------------------------------------------------------------------------------------------------------------------------------------------

Lookup Drop

------------------------------------------------------------------------------------------------------------------------------------------------------

LU drop reason                          : UC_PC_CFG_TABLE_DROP

***Notice the drop vector here.***

Solução

A solução é parar de enviar o atributo de comunidade estendida MAC do Roteador com um prefixo da família de endereços IPv4 de um par BGP externo para uma estrutura ACI.

Remova o mapa de rotas configurado anteriormente e pare de enviar comunidades estendidas do dispositivo de peer BGP externo (Roteador 1). A remoção de uma dessas configurações, ou de ambas, funcionará:

Router-1# show run bgp

feature bgp

router bgp 65001

vrf example

router-id 192.168.20.20

address-family ipv4 unicast

network 192.168.20.0/24

neighbor 192.168.30.30

remote-as 65001

update-source loopback1

address-family ipv4 unicast

Outra solução (menos preferencial) é simplesmente filtrar todas as comunidades recebidas do dispositivo de peer de BGP externo, criando um mapa de rota no L3Out configurado na ACI.

Navegue até o  Tenant > Policies > Protocol > Route Maps for Route Control > Create Route Maps for Route Control:

Selecione a opção para Criar Mapas de Rotas para Controle de Rotas

Nomeie seu mapa de rotas, ative a opção  Route-Map Continue  e, em seguida, adicionar um contexto. Selecione a opção  +  ícone na tabela Contextos:

Criar Mapa de Rotas e Criar Contexto

Nomeie seu contexto e deixe a ação padrão de  Permit  selecionado e, em seguida, crie uma regra de correspondência selecionando o  +  no ícone  Associated Matched Rules  e selecione  Create Match Rule for a Route Map:

Criar Contexto de Controle de Rotas e selecionar a opção Criar Regra de Correspondência para um Mapa de Rotas

Nomeie sua regra de correspondência e adicione um novo prefixo selecionando o ícone + no  Match Prefix  tabela:

Criar Regra de Correspondência e criar Prefixo de Correspondência

Adicione o prefixo desejado. Este exemplo mostra como adicionar um agregado de todos os prefixos:

Criar Regra de Destino de Rota de Correspondência

Depois de selecionar  OK no  Create Match Route Destination Rule  , você verá que seu prefixo foi adicionado à  Match Prefix  tabela na  Create Match Rule  janela:

O prefixo de correspondência agora foi adicionado à regra de correspondência

Depois de selecionar  Submit  no  Create Match Rule  , selecione  Update  no  Associated Matched Rules  tabela na  Create Route Control Context  janela:

Adicionar Regra de Correspondência Associada ao Contexto de Controle de Rota

Sua regra de correspondência associada agora foi adicionada ao seu contexto:

A regra de correspondência associada agora foi adicionada ao contexto de controle de rota

Em seguida, selecione o menu suspenso ao lado de  Set Rule  e selecione  Create Set Rules for a Route Map:

Selecione a opção para Criar Regras de Definição para um Mapa de Rotas

Nomeie sua regra de conjunto e selecione o  Set Community  e deixe os critérios padrão de  No community  selecionado:

Criar Regra de Definição para Mapa de Rotas

Depois de selecionar Concluir na  Create Set Rules for a Route Map  , você verá sua regra de conjunto selecionada no  Create Route Control Context  janela:

A regra Set foi adicionada ao contexto de controle de rota

Depois de selecionar  OK  no  Create Route Control Context  , você verá seu contexto adicionado à  Contexts  tabela na  Create Route Maps for Route Control  janela. Finalmente, selecione  Submit  para concluir a configuração:

O contexto foi adicionado ao Mapa de Rotas

Navegue até o Perfil de conectividade de peer BGP na L3Out e selecione o  +  no ícone  Route Control Profile  , adicione o mapa de rotas com a direção padrão de  Route Import Policy  selecionado:

Adicionar Mapa de Rota ao Perfil de Conectividade de Par BGP

Depois de selecionar Update para o mapa de rotas, você verá seu mapa de rotas adicionado ao  Route Control Profile  tabela:

O Mapa de Rota agora foi adicionado ao Perfil de Conectividade de Par BGP

*Para obter mais informações sobre as opções de configuração do mapa de rotas na ACI, consulte o White Paper ACI Fabric L3Out

Após implementar uma das soluções acima, verifique se o problema foi resolvido.

Verifique o status de BGP no BL 101:

leaf-101# show ip bgp 192.168.20.0 vrf example:example

BGP routing table information for VRF example:example, address family IPv4 Unicast

BGP routing table entry for 192.168.20.0/24, version 46 dest ptr 0xa0fec840

Paths: (1 available, best #1)

Flags: (0x80c001a 00000000) on xmit-list, is in urib, is best urib route, is in HW, exported

vpn: version 2731, (0x100002) on xmit-list

Multipath: eBGP iBGP

Advertised path-id 1, VPN AF advertised path-id 1

Path type (0xa96485b8): internal 0x18 0x0 ref 0 adv path ref 2, path is valid, is best path

AS-Path: NONE, path sourced internal to AS

192.168.20.20 (metric 5) from 192.168.20.20 (192.168.20.20)

Origin IGP, MED not set, localpref 100, weight 0 tag 0, propagate 0

Extcommunity:

RT:65001:2162688

COST:pre-bestpath:163:1879048192

***Notice that no router mac is present here.***

VNID:2162688

VRF advertise information:

Path-id 1 not advertised to any peer

VPN AF advertise information:

Path-id 1 advertised to peers:

10.0.216.65        10.0.216.66

Verificar RIB na CL 102:

leaf-102# show ip route 192.168.20.0 vrf example:example

IP Route Table for VRF "example:example"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

192.168.20.0/24, ubest/mbest: 1/0

*via 10.0.210.70%overlay-1, [200/0], 00:00:06, bgp-65001, internal, tag 65001

recursive next hop: 10.0.210.70/32%overlay-1

***Notice that no rwVnid entry is present here.***

Observação: a ausência ou presença da entrada rwVnid sozinha não determina se o problema está ocorrendo ou não. Em muitos casos, a entrada rwVnid é removida da rota em questão depois que o problema é resolvido. No entanto, nem sempre é assim. Sempre verifique as tabelas FIB e HAL para verificar se o problema foi resolvido ou não.

Verificar FIB na CL 102:

module-1(DBG-elam-insel6)# show forwarding route 192.168.20.0 vrf example:example

IPv4 routes for table example:example/base

------------------+------------------+----------------------+------------------------

Prefix            | Next-hop         | Interface/VRF        | Additional Info

------------------+------------------+----------------------+------------------------

*192.168.20.0/24      10.0.210.70        overlay-1

***Notice that we have the route here and our next-hop address is correct (showing the TEP IP of BL 101).***

Route Class-id:0x0

Policy Prefix 0.0.0.0/0

leaf-102# acidiag fnvread | grep 101

101        1             leaf-101           10.0.210.70/32    leaf         active   0

Tabela HAL na CL 102:

module-1(DBG-elam-insel6)# show platform internal hal l3 routes | grep 192.168.20.0

| 4662| 192.168.20.0/ 24| UC|  686|     20601| TRIE|   a5| 5/  0| 60a5|A|     8443|    86b6|  ef5| 1/  2|       a5|  0|      0|   f|  3|   0| 0| 1| sc,spi,dpi

***Notice that we have an entry here and it's in the correct VRF.***

module-1(DBG-elam-insel6)# hex 4662

0x1236

module-1(DBG-elam-insel6)# show platform internal hal l3 vrf pi

============================================================================================================

| -- TOR --  | - Spine -  |                ACL                  |     |

Vrf           Hw    I I Vrf     | SB    NB   | Proxy ACI  |      Ing               Egr          | vpn |

VrfId Name          VrfId I S Vnid    | BDId  BDId | Ou Bd Enc  | Lbl      Msk      Lbl      Msk      | lbl |

============================================================================================================

26    example:example         1236  0 0 210000    0     0      0     1      0        0        0        0        0

Pings do EP (Host 1) para o host em uma rede externa que vem do par BGP externo (192.168.20.20):

Host-1# ping 192.168.20.20 vrf example

PING 192.168.20.20 (192.168.20.20): 56 data bytes

64 bytes from 192.168.20.20: icmp_seq=0 ttl=252 time=1.043 ms

64 bytes from 192.168.20.20: icmp_seq=1 ttl=252 time=1.292 ms

64 bytes from 192.168.20.20: icmp_seq=2 ttl=252 time=1.004 ms

64 bytes from 192.168.20.20: icmp_seq=3 ttl=252 time=0.769 ms

64 bytes from 192.168.20.20: icmp_seq=4 ttl=252 time=1.265 ms

--- 192.168.20.20 ping statistics ---

5 packets transmitted, 5 packets received, 0.00% packet loss

round-trip min/avg/max = 0.769/1.074/1.292 ms

***Connectivity is there.***

ELAM na CL 102:

leaf-102# vsh_lc

module-1# debug platform internal roc elam asic 0

module-1(DBG-elam)# trigger reset

module-1(DBG-elam)# trigger init in-select 6 out-select 0

module-1(DBG-elam-insel6)# set outer ipv4 src_ip 192.168.10.10 dst_ip 192.168.20.20

module-1(DBG-elam-insel6)# start

module-1(DBG-elam-insel6)# stat

ELAM STATUS

===========

Asic 0 Slice 0 Status Armed

Asic 0 Slice 1 Status Triggered

module-1(DBG-elam-insel6)# ereport

Python available. Continue ELAM decode with LC Pkg

ELAM REPORT

<output omitted>

------------------------------------------------------------------------------------------------------------------------------------------------------

Lookup Drop

------------------------------------------------------------------------------------------------------------------------------------------------------

LU drop reason                          : no drop

***Traffic forwards correctly.***

Informações Relacionadas

- Esse comportamento também é documentado neste defeito: ID de bug da Cisco CSCvx28929

- Suporte Técnico e Documentação - Cisco Systems