Implementazione della policy di routing BGP VPN sugli switch Catalyst serie 9000

Introduzione

Questo documento descrive come implementare la policy di routing nella VXLAN BGP VPN sugli switch Catalyst serie 9000.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Configurazione e convalida BGP 
• Route map e policy di routing BGP di base
• VxLAN VPN

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Catalyst 9300
• Catalyst 9400
• Catalyst 9500
• Catalyst 9600
• Cisco IOS® XE 17.1.1 e versioni successive 

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

La policy di routing VxLAN EVPN utilizza le route map per controllare il flusso del traffico degli host e le route che i VTEP apprendono ed elaborano:

• Questo è un aspetto chiave della progettazione del tipo di segmento protetto da EVPN (al di fuori dell'ambito di questo documento) in cui il traffico ARP viene inviato solo al gateway centrale (CGW) in modo che CGW possa inviare una risposta proxy con il proprio indirizzo MAC anche per il traffico del segmento locale. 
• Il segmento protetto consente di controllare i flussi di traffico in modo che tutto il traffico possa essere trasmesso attraverso le policy di ispezione e di gestione del traffico di un firewall. 

Cisco ha anche implementato l'attributo della community estesa DEF GW (Default Gateway) per indicare il prefisso MAC/IP del CGW.

Dettagli documento

Dettagli principali sul documento:

• Modalità di replica per il traffico BUM in entrata (tunnel BUM unicast)
• Vlan usate: 201 e 202
• VNI utilizzati: 20101 e 20201
• Tutto il traffico indirizzato viene inviato al CGW (i VTEP non hanno una propria SVI)
• I prefissi BGP del tipo di route IMET 3 sono hub e spoke (le foglie accettano solo route IMET da CGW, non l'una dall'altra)
• I tipi di route 2 e 5 sono a maglia piena 

Tipi di route supportati

• Route-type 3 (Inclusive Multicast Ethernet Tag route)
• Route-type 7 (IGMP Join Synch Routes)
• Route-type 8 (IGMP Leave Synch Routes)

Terminologia

VRF	Inoltro routing virtuale	Definisce un dominio di routing di livello 3 che deve essere separato da altri VRF e da un dominio di routing IPv4/IPv6 globale
AF	Famiglia indirizzi	Definisce quali prefissi di tipo e informazioni di routing sono handle BGP
AS	Sistema autonomo	Set di prefissi IP instradabili Internet appartenenti a una rete o a un insieme di reti gestite, controllate e supervisionate da una singola entità o organizzazione
EVPN	Ethernet Virtual Private Network	L'estensione che consente a BGP di trasportare le informazioni MAC di layer 2 e IP di layer 3 è EVPN e utilizza il protocollo MP-BGP (Multi-Protocol Border Gateway Protocol) per distribuire le informazioni sulla raggiungibilità relative alla rete di sovrapposizione VXLAN.
VXLAN	LAN virtuale estendibile (LAN)	La VXLAN è progettata per superare i limiti intrinseci delle VLAN e dell'STP. Si tratta di uno standard IETF [RFC 7348] proposto per fornire gli stessi servizi di rete Ethernet di layer 2 delle VLAN, ma con una maggiore flessibilità. A livello funzionale, è un protocollo di incapsulamento MAC-in-UDP che viene eseguito come sovrimpressione virtuale su una rete sottostante di layer 3.
CGW	Gateway centralizzato	E implementazione di EVPN in cui la SVI del gateway non è su ciascuna foglia. Tutto il routing viene invece eseguito da una foglia specifica utilizzando il protocollo IRB (Integrated Routing and Bridging) asimmetrico
DEF GW	Gateway predefinito	Un attributo della community estesa BGP aggiunto al prefisso MAC/IP tramite il comando "default-gateway annuncio enable" nella sezione di configurazione 'l2vpn evpn'.
IMET	Tag Inclusive Multicast Ethernet (Route)	Chiamata anche route BGP di tipo 3. Questo tipo di route viene utilizzato nell'EVPN per consegnare il traffico BUM (broadcast / unicast sconosciuto / multicast) tra i VTEP.

Configurazione

Esempio di rete

Configurazioni

Questa sezione mostra gli esempi di configurazione degli switch Leaf-01 e Border Leaf (CGW). Le altre configurazioni foglia sono identiche, quindi non vengono ripetute qui.

• Gli esempi riportati in questo documento si basano sulla replica in entrata e mostrano come applicare criteri per controllare quali VTEP possono comunicare il traffico di broadcast e di altro tipo 

Leaf-01 (configurazione EVPN di base)

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 (filtro route)

Determinare la route-destinazione da abbinare.

• Per la semplicità CLI, l'esempio riportato in questo documento utilizza la funzionalità di indirizzamento automatico della destinazione.
• Poiché si tratta di un'operazione automatica, eseguire questo comando per sapere come configurare l'elenco della community

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 (configurazione base)

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

Verifica

Esempio di rete

 

Questo diagramma consente di visualizzare il flusso del processo di risoluzione ARP descritto in questa sezione. 

• La richiesta ARP è visualizzata in viola.
  • Questa richiesta ARP deve risolvere l'indirizzo MAC dell'host 10.1.202.10 off Leaf-01
  • La linea viola termina in corrispondenza del CGW e non raggiunge Leaf-01
• La risposta ARP è visualizzata in verde e contiene l'indirizzo MAC della SVI CGW per la Vlan 202 
  • Si noti che la linea verde proviene dal CGW e non dall'host effettivo
• La X rossa indica che la comunicazione non ha comportato l'invio del traffico a Leaf-01

Criteri tipo di route 3 (foglia-01)

Verificare che le route map applicate alle foglie filtrino correttamente. Dovremmo vedere solo i prefissi IMET dalla CGW, e nessun'altra foglia. 

• Qui è mostrata una sola foglia, ma questo controllo deve essere fatto su tutte le foglie pertinenti 

Per verificare quale route-type 3 è installato, sono disponibili due metodi:

• Controllo delle voci BGP
• Verifica route l2

Verifica voci BGP (Foglia-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 >

Verifica route l2

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

Local Routing (CGW) 

Verificare che CGW risponda con il proprio MAC quando si verifica la risoluzione ARP del segmento locale. 

• Il comando show è disponibile solo per la verifica delle configurazioni, come mostrato nella sezione configure 
• Possiamo verificarlo confermando quale MAC è programmato sull'host quando risolve ARP per un host su un altro Leaf.

Acquisizione di una richiesta di risoluzione ARP inviata dall'host di Leaf-02 all'host di Leaf-01 (ciò è stato fatto utilizzando l'acquisizione EPC sull'interfaccia di accesso di Leaf-02 rivolta verso l'host)

• Leaf-01 host MAC effettivo: 0006.f601.cd45
• CGW MAC che ha risposto alla richiesta 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

Risoluzione dei problemi

Criterio di mapping route di debug (in entrata)

Confermare che le route map in ingresso funzionino come previsto

Abilita debug aggiornamenti VPN L2VPN 

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

Cancella famiglia di indirizzi bgp per creare un'istanza del criterio di route

Leaf-02#clear bgp l2vpn evpn *

Verificare che il tipo di percorso 3 sia accettato solo dal CGW e rifiutato da tutti gli altri fogli 

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;

Verifica criterio di route-map (in uscita)

Verificate che la comunità standard sia applicata ai prefissi di tipo 3 delle foglie controllandoli sul CGW. 

• Questo output di esempio mostra i prefissi BGP di Leaf-01 e Leaf-02 con l'attributo community inserito per il 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

Informazioni correlate

• Documentazione e supporto tecnico – Cisco Systems
• Guida alla configurazione della VXLAN BGP VPN, Cisco IOS XE Dublin 17.11.x (switch Catalyst 9500)
• Documenti di supporto Catalyst EVPN (LogAdvisor)