Implemente a política de roteamento BGP EVPN nos switches Catalyst 9000 Series

Introdução

Este documento descreve como implementar a política de roteamento em BGP EVPN VXLAN em Catalyst 9000 Series Switches.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Configuração e validação de BGP 
• Mapas de rota e política de roteamento BGP básica
• EVPN VxLAN

Componentes Utilizados

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

• Catalyst 9300
• Catalyst 9400
• Catalyst 9500
• Catalyst 9600
• Cisco IOS® XE 17.11.1 e versões posteriores 

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.

Informações de Apoio

A política de roteamento EVPN VxLAN usa mapas de rotas para controlar o fluxo de tráfego de hosts e quais rotas os VTEPs aprendem e processam:

• Este é um aspecto importante do projeto de tipo de segmento protegido por EVPN (fora do escopo deste documento) em que o tráfego ARP é enviado apenas ao Gateway Central (CGW), de modo que o CGW pode responder por proxy com seu próprio endereço MAC, mesmo para o tráfego de segmento local. 
• O segmento protegido oferece a capacidade de controlar os fluxos de tráfego de tal forma que todo o tráfego possa passar pela inspeção de tráfego e pelas políticas de tráfego de um Firewall. 

A Cisco também implementou o atributo de comunidade estendida de Gateway Padrão (DEF GW) para indicar qual prefixo MAC/IP pertence ao CGW.

Detalhes do documento

Principais detalhes sobre este documento:

• O modo de replicação para o tráfego de BUM é de entrada (túneis de BUM unicast)
• As Vlans usadas são 201 e 202
• As VNIs usadas são 20101 e 20201
• Todo o tráfego roteado é enviado ao CGW (os VTEPs não têm seu próprio SVI)
• Os prefixos BGP tipo 3 de rota IMET são hub e spoke (os Leafs aceitam somente rotas IMET do CGW, não umas das outras)
• Os tipos de rota 2 e 5 são full mesh 

Tipos de rota suportados

• Tipo de rota 3 (rota de tag Ethernet multicast inclusiva)
• Route-type 7 (IGMP Join Synch Routes)
• Route-type 8 (IGMP deixa rotas de sincronização)

Terminologia

VRF	Encaminhamento de roteamento virtual	Define um domínio de roteamento de camada 3 que deve ser separado de outros domínios de roteamento VRF e IPv4/IPv6 global
AF	Família de Endereços	Define quais prefixos de tipo e informações de roteamento o BGP trata
COMO	Sistema autônomo	Um conjunto de prefixos IP roteáveis da Internet que pertencem a uma rede ou a um conjunto de redes gerenciadas, controladas e supervisionadas por uma única entidade ou organização
EVPN	Rede Privada Virtual Ethernet	A extensão que permite que o BGP transporte informações MAC de Camada 2 e IP de Camada 3 é EVPN e O usa o Protocolo de Gateway de Borda Multiprotocolo (MP-BGP - Multi-Protocol Border Gateway Protocol) como o protocolo para distribuir informações de alcance que pertençam à rede de sobreposição de VXLAN.
VXLAN	LAN virtual extensível (rede local)	A VXLAN foi projetada para superar as limitações inerentes de VLANs e STP. É um padrão IETF proposto [RFC 7348] para fornecer os mesmos serviços de rede Ethernet de Camada 2 que as VLANs, mas com maior flexibilidade. Funcionalmente, é um protocolo de encapsulamento MAC-em-UDP executado como uma sobreposição virtual em uma rede de camada 3 subjacente.
CGW	Gateway centralizado	E a implementação do EVPN onde o SVI do gateway não está em cada folha. Em vez disso, todo o roteamento é feito por uma folha específica usando IRB assimétrico (Integrated Routing and Bridging)
DEF GW	Gateway padrão	Um atributo de comunidade estendida de BGP adicionado ao prefixo MAC/IP através do comando "default-gateway advertise enable" na seção de configuração 'l2vpn evpn'.
IMET	Tag Ethernet Multicast Inclusiva (Rota)	Também chamada de rota BGP tipo 3. Esse tipo de rota é usado no EVPN para fornecer tráfego BUM (broadcast / unicast desconhecido / multicast) entre VTEPs.

Configurar

Diagrama de Rede

Configurações

Esta seção mostra exemplos de configuração de switches Leaf-01 e Border Leaf (CGW). Outras configurações de folha são as mesmas, portanto não são repetidas aqui.

• Os exemplos neste documento são baseados na replicação de ingresso e demonstram como aplicar a política para controlar quais VTEPs podem comunicar tráfego de broadcast e outros inundados 

Leaf-01 (configuração EVPN básica)

Leaf-01#show run | sec l2vpn
l2vpn evpn
 replication-type static
 flooding-suppression address-resolution disable  <-- Disables ARP caching so ARP is always sent up to the CGW 
 router-id Loopback1
l2vpn evpn instance 201 vlan-based
 encapsulation vxlan
 replication-type ingress
 multicast advertise enable
l2vpn evpn instance 202 vlan-based
 encapsulation vxlan
 replication-type ingress
 multicast advertise enable

Leaf-01#show run | sec vlan config
vlan configuration 201
 member evpn-instance 201 vni 20101
vlan configuration 202
 member evpn-instance 202 vni 20201

Leaf-01#show run int nve 1
Building configuration...

Current configuration : 327 bytes
!
interface nve1
 no ip address
 source-interface Loopback1
 host-reachability protocol bgp
 member vni 20201 ingress-replication
 member vni 20101 ingress-replication
end

ip bgp-community new-format     <-- Required to see community in aa:nn format

Leaf-01 (filtragem de rotas)

Determine que destino de rota coincidir.

• Para simplificar a CLI, o exemplo neste documento usa a funcionalidade de destino de rota automática.
• Como isso é automático, execute esse comando para saber como configurar a lista de comunidades

Leaf-01#show l2vpn evpn route-target
Route Target           EVPN Instances
65001:201              201            <-- Route-targets for the Vlan/VNI of interest
65001:202              202    

ip extcommunity-list expanded ALLOW-RT2 permit 65001:20[0-9] <-- match Route-targets 65001:200 - 65001:209
!
ip community-list standard BLOCK-RT3 permit 999:999          <-- Arbitrary RT used to mark IMET prefixes as they are advertised

route-map POLICY-IN deny 5
 match community BLOCK-RT3 exact-match  <-- Deny prefixes that match RT 999:999 in standard community list
!
route-map POLICY-IN permit 10           <-- Permit any other prefixes that do not contain 999:999
!
route-map POLICY-OUT permit 5
 match extcommunity ALLOW-RT2           <-- Match the auto-RT in the extended community list
 match evpn route-type 3                <-- AND match route-type 3 prefixes
 set community 999:999                  <-- Set additional standard community to advertised prefixes  
!
route-map POLICY-OUT permit 10          <-- Permit prefixes that are not RT3 to be sent out without additional attributes added 

router bgp 65001
 bgp router-id 172.16.255.3
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 172.16.255.1 remote-as 65001
 neighbor 172.16.255.1 update-source Loopback0
 neighbor 172.16.255.2 remote-as 65001
 neighbor 172.16.255.2 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv4 mvpn
  neighbor 172.16.255.1 activate
  neighbor 172.16.255.1 send-community both
  neighbor 172.16.255.2 activate
  neighbor 172.16.255.2 send-community both
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 172.16.255.1 activate
  neighbor 172.16.255.1 send-community both       <-- Send both standard and extended community attributes 
  neighbor 172.16.255.1 route-map POLICY-IN in    <-- Apply inbound policy to deny prefixes with 999:999 community string
  neighbor 172.16.255.1 route-map POLICY-OUT out  <-- Apply outbound policy to match RT3 / apply standard community & permit other RT2 prefixes as normal 
  neighbor 172.16.255.2 activate
  neighbor 172.16.255.2 send-community both
  neighbor 172.16.255.2 route-map POLICY-IN in
  neighbor 172.16.255.2 route-map POLICY-OUT out
 exit-address-family

CGW (configuração básica)

CGW#show running-config | beg l2vpn evpn instance 201
l2vpn evpn instance 201 vlan-based
 encapsulation vxlan
 replication-type ingress
 default-gateway advertise enable    <-- adds the BGP attribute EVPN DEF GW:0:0 to the MAC/IP prefix
 multicast advertise enable
!
l2vpn evpn instance 202 vlan-based
 encapsulation vxlan
 replication-type ingress
 default-gateway advertise enable   <-- adds the BGP attribute EVPN DEF GW:0:0 to the MAC/IP prefix
 multicast advertise enable

CGW#show running-config | sec vlan config
vlan configuration 201
 member evpn-instance 201 vni 20101
vlan configuration 202
 member evpn-instance 202 vni 20201

CGW#show run int nve 1
Building configuration...

Current configuration : 313 bytes
!
interface nve1
 no ip address
 source-interface Loopback1
 host-reachability protocol bgp
 member vni 10101 mcast-group 225.0.0.101
 member vni 10102 mcast-group 225.0.0.102
 member vni 20101 ingress-replication local-routing  <-- 'ingress-replication' (Unicast all BUM traffic) / 'local-routing' (Enables vxlan centralized gateway forwarding)
 member vni 20201 ingress-replication local-routing
 member vni 50901 vrf green
end

CGW#show run interface vlan 201
Building configuration...

Current configuration : 231 bytes
!
interface Vlan201
 mac-address 0000.beef.cafe          <-- MAC is static in this example for viewing simplicity. This is not required 
 vrf forwarding red                  <-- SVI is in VRF red
 ip address 10.1.201.1 255.255.255.0
 no ip redirects
 ip local-proxy-arp                 <-- Sets CGW to Proxy reply even for local subnet ARP requests 
 ip pim sparse-mode
 ip route-cache same-interface      <-- This is auto added when local-proxy-arp is configured. However, this is a legacy 'fast switching' command that is not used by CEF & is not required for forwarding 
 ip igmp version 3
 no autostate
end

CGW#show run interface vlan 202
Building configuration...

Current configuration : 163 bytes
!
interface Vlan202
 mac-address 0000.beef.cafe
 vrf forwarding red
 ip address 10.1.202.1 255.255.255.0
 no ip redirects 
 ip local-proxy-arp 
 ip pim sparse-mode
 ip route-cache same-interface
 ip igmp version 3
 no autostate
end

CGW#sh run vrf red
Building configuration...

Current configuration : 873 bytes 
vrf definition red
 rd 2:2
 !
 address-family ipv4
  route-target export 2:2
  route-target import 2:2
  route-target export 2:2 stitching
  route-target import 2:2 stitching
 exit-address-family

Verificar

Diagrama de Rede

 

Este diagrama serve para ajudar a visualizar o fluxo do processo de resolução ARP descrito nesta seção. 

• A Solicitação ARP é exibida em roxo.
  • Essa solicitação ARP é para resolver o endereço MAC do host 10.1.202.10 fora da Leaf-01
  • Observe que a linha roxa termina no CGW e não atinge Leaf-01
• A Resposta ARP é mostrada em verde e contém o MAC do CGW SVI para Vlan 202 
  • Observe que a linha verde vem do CGW, não do host real
• O X vermelho indica que essa comunicação não envolveu o envio de tráfego para a Folha-01

Política de Tipo de Rota 3 (Leaf-01)

Verifique se os mapas de rota aplicados aos Leafs estão filtrando corretamente. Só devemos ver os prefixos IMET do CGW, e nenhum outro folheto. 

• Apenas uma folha é mostrada aqui, mas esta verificação deve ser feita em todas as folhas relevantes 

Há dois métodos para ver que tipo de rota 3 está instalado:

• Verificando entradas BGP
• Verificando l2route

Verificar entradas BGP (Folha-01)

Leaf-01#show bgp l2vpn evpn route-type 3 | inc Tunnel End
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20101, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >  <-- No RT3 prefixes present other than the CGW 172.16.254.6 
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20101, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >

Verificar l2route

Leaf-01-F241.03.23-9300#show l2route evpn imet
  EVI       ETAG   Prod                          Router IP Addr  Type    Label                               Tunnel ID Multicast Proxy
----- ---------- ------ --------------------------------------- ----- -------- --------------------------------------- ---------------
  201          0    BGP                            172.16.254.6     6    20101                            172.16.254.6              No <-- Only remote IMET producer is the CGW
  201          0  L2VPN                            172.16.254.3     6    20101                            172.16.254.3            IGMP
  202          0    BGP                            172.16.254.6     6    20201                            172.16.254.6              No
  202          0  L2VPN                            172.16.254.3     6    20201                            172.16.254.3            IGMP <-- Only remote IMET producer is the CGW

Roteamento local (CGW) 

Verifique se o CGW responde com seu próprio MAC quando ocorre a resolução ARP do segmento local. 

• Não há nenhum comando show além da verificação das configurações mostradas na seção configure 
• Podemos verificar isso confirmando qual MAC está programado no host quando ele resolve o ARP para um host em outra Folha.

Captura de uma solicitação de resolução ARP enviada do host da Folha-02 para o host da Folha-01 (isso foi feito usando a captura EPC na interface de acesso da Folha-02 voltada para o host)

• MAC real do host Leaf-01: 0006.f601.cd45
• CGW MAC que respondeu à solicitação ARP: 0000.beef.cafe

Leaf-02-F241.03.23-9400#show mon cap 1 buff br | i ARP
   32  10.356291 00:06:f6:17:ee:c4 -> ff:ff:ff:ff:ff:ff ARP 64 Who has 10.1.202.10? Tell 10.1.202.11 <-- ARP request from Leaf-02 host
   33  10.357140 00:00:be:ef:ca:fe -> 00:06:f6:17:ee:c4 ARP 68 10.1.202.10 is at 00:00:be:ef:ca:fe   <-- ARP reply is the CGW MAC


Leaf-02-F241.03.23-9400#show mon cap 1 buff det | b Frame 32
Frame 32: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface /tmp/epc_ws/wif_to_ts_pipe, id 0
<...snip...>
    [Protocols in frame: eth:ethertype:vlan:ethertype:arp]
Ethernet II, Src: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
    Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
        Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        Address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 202                    <-- Vlan 202 
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = DEI: Ineligible
    .... 0000 1100 1010 = ID: 202
    Type: ARP (0x0806)
    Padding: 0000000000000000000000000000
    Trailer: 00000000
Address Resolution Protocol (request)                          <-- ARP Request 
    Hardware type: Ethernet (1)
    Protocol type: IPv4 (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    Sender MAC address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
    Sender IP address: 10.1.202.11
    Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
    Target IP address: 10.1.202.10                              <-- Leaf-02 Host 

Frame 33: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface /tmp/epc_ws/wif_to_ts_pipe, id 0
<...snip...>
Ethernet II, Src: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe), Dst: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
    Destination: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        Address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe)
        Address: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: CiscoMetaData (0x8909)
Cisco MetaData
    Version: 1
    Length: 1
    Options: 0x0001
    SGT: 0
    Type: ARP (0x0806)
    Padding: 00000000000000000000
    Trailer: 0000000000000000
Address Resolution Protocol (reply)
    Hardware type: Ethernet (1)
    Protocol type: IPv4 (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    Sender MAC address: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe)   <-- ARP Reply is the CGW MAC 0000.beef.cafe
    Sender IP address: 10.1.202.10
    Target MAC address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)   <-- MAC of host off Leaf-02 0006.f617.eec4
    Target IP address: 10.1.202.11

Troubleshooting

Debug Route-Map Policy (Inbound)

Confirme se os mapas de rota de entrada estão funcionando conforme esperado

Habilitar depurações de atualização L2VPN EVPN 

Leaf-02#debug bgp l2vpn evpn updates
BGP updates debugging is on for address family: L2VPN E-VPN

Leaf-02#debug bgp l2vpn evpn updates events
BGP update events debugging is on for address family: L2VPN E-VPN

Limpe bgp address-family para instanciar a política de Rota

Leaf-02#clear bgp l2vpn evpn *

Verificar se o tipo de rota 3 é aceito somente no CGW e negado em todos os outros Leafs 

Leaf-02#show log | i rcvd \[3\]
*Jul  4 06:40:41.556: BGP(10): 172.16.255.2 rcvd [3][172.16.254.6:202][0][32][172.16.254.6]/17    <-- Only accepted Type-3 is from the CGW (172.16.254.6)
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.6:201][0][32][172.16.254.6]/17
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.3:202][0][32][172.16.254.3]/17 -- DENIED due to: route-map;
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.5:202][0][32][172.16.254.5]/17 -- DENIED due to: route-map;
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.3:201][0][32][172.16.254.3]/17 -- DENIED due to: route-map;
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.5:201][0][32][172.16.254.5]/17 -- DENIED due to: route-map;

Verificar política de mapa de rota (saída)

Verifique se a comunidade padrão é aplicada aos prefixos Tipo 3 do Leafs, verificando-os no CGW. 

• Este exemplo de saída mostra prefixos BGP de Leaf-01 e Leaf-02 com o atributo de comunidade injetado para o segmento Vlan 202 

CGW#show bgp l2vpn evpn route-type 3
BGP routing table entry for [3][172.16.254.6:202][0][32][172.16.254.3]/17, version 461855
Paths: (1 available, best #1, table evi_202)                                      <-- The EVI context for the vlan 202 segment 
  Not advertised to any peer
  Refresh Epoch 4
  Local, imported path from [3][172.16.254.3:202][0][32][172.16.254.3]/17 (global)
    172.16.254.3 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 999:999                                                          <-- Route-map logic is good. Standard community applied to the Type-3 
      Extended Community: RT:65001:202 ENCAP:8 EVPN Mcast Flags:1
      Originator: 172.16.255.3, Cluster list: 172.16.255.2
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.3 > <-- Type-3 tunnel 
      rx pathid: 0, tx pathid: 0x0
      Updated on Jan 22 2025 19:02:18 UTC
BGP routing table entry for [3][172.16.254.6:202][0][32][172.16.254.4]/17, version 605955
Paths: (1 available, best #1, table evi_202)
  Not advertised to any peer
  Refresh Epoch 4
  Local, imported path from [3][172.16.254.4:202][0][32][172.16.254.4]/17 (global)
    172.16.254.4 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 999:999
      Extended Community: RT:65001:202 ENCAP:8 EVPN Mcast Flags:1
      Originator: 172.16.255.4, Cluster list: 172.16.255.2
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.4 >
      rx pathid: 0, tx pathid: 0x0
      Updated on Jan 30 2025 18:50:49 UTC

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems
• Guia de Configuração de BGP EVPN VXLAN, Cisco IOS XE Dublin 17.11.x (Switches Catalyst 9500)
• Documentos de suporte do Catalyst EVPN (LogAdvisor)