L'extension qui permet au BGP de transporter les informations MAC de couche 2 et IP de couche 3 est EVPN et utilise le protocole MP-BGP (Multi-Protocol Border Gateway Protocol) comme protocole pour distribuer les informations d'accessibilité qui appartiennent au réseau de superposition VXLAN.
Dépannage de la TRM EVPN VxLAN sur les commutateurs Catalyst 9000
Table des matières
Introduction
Ce document décrit comment dépanner des problèmes avec TRM (Tenant Routed Multicast) sur EVPN VxLAN.
Conditions préalables
- Il est recommandé que vous soyez familiarisé avec la fonctionnalité Unicast EVPN VxLAN, BGP et MVPN (Multicast Virtual Private Network).
- En outre, vous devez comprendre le fonctionnement de la multidiffusion et les concepts de multidiffusion
Exigences
Ce guide suppose que les homologues BGP et NVE sont déjà corrects. En cas de problèmes avec l'activation de VxLAN EVPN de base (échec de la commande ping de monodiffusion, BGP, homologues NVE désactivés, etc.), veuillez vous reporter aux guides de dépannage BGP, EVPN, route/commutateur, si nécessaire.
Disponibilité des fonctionnalités dans chaque version de code
| Libérer | Fonctionnalité |
| 17.1.1 | TRMv4 avec Anycast RP |
| 17.3.1 | TRMv4 avec RP externe ou RP unique |
| 17.3.1 |
TRMv6 avec Anycast RP |
| 17.3.1 |
TRMv6 avec RP externe ou RP unique |
| 17.3.1 | TRMv4 avec interconnexion MVPN (profile11) avec RP unique côté fabric |
| 17.6.2 et 17.7.1 | TRMv4 Data mdt avec Anycast RP, RP externe ou RP unique |
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- C9300
- C9400
- C9500
- C9600
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Pour configurer EVPN TRM consultez : BGP EVPN VXLAN Configuration Guide, Cisco IOS XE Amsterdam 17.3.x
La multidiffusion routée par le locataire (TRM) est une solution basée sur BGP-EVPN qui permet le routage multidiffusion entre les sources et les récepteurs connectés sur VTEPS dans le fabric VxLAN [RFC7432]. TRM s'appuie sur les routes présentes dans l'EVPN de monodiffusion pour découvrir la source de multidiffusion et le RP de multidiffusion. Comme avec NG-MVPN, les informations de source et de récepteur multidiffusion sont propagées par le protocole BGP parmi les VTEP configurés avec la famille d'adresses MVPN BGP. Aucun paquet PIM/IGMP n'est envoyé au fabric VxLAN à partir d'un VTEP TRM.
Le principal problème résolu par TRM est la capacité des expéditeurs et des récepteurs de multidiffusion situés dans des VLAN différents mais dans le même VRF, à communiquer entre eux. Sans TRM, le trafic de multidiffusion est envoyé dans le cadre de la même infrastructure BUM (Broadcast, Unicast et Multicast) dans le sous-réseau, qui peut être une arborescence de multidiffusion ou une réplication en entrée. Cette infrastructure est construite par VLAN et par conséquent, alors que les sources et les récepteurs de multidiffusion sur le même VLAN peuvent communiquer, ceux qui sont sur des VLAN différents ne le peuvent pas. Avec TRM, la multidiffusion est déplacée hors de BUM et regroupée sous le VRF parent. De ce fait, la communication multidiffusion est entièrement activée, quels que soient les VLAN dans lesquels la source ou le récepteur résident.
TRM fournit un transfert multidiffusion reconnaissant la mutualisation entre les expéditeurs et les récepteurs au sein d'un même sous-réseau ou de sous-réseaux différents, locaux ou sur des VTEP. Voir le guide Guide de configuration de VXLAN EVPN BGP, Cisco IOS XE Amsterdam 17.3.x pour plus de détails
Comment vous orienter dans ce guide :
- Le guide est divisé en 4 scénarios en fonction de l'emplacement du RP.
- Un scénario peut faire référence à des exemples CLI qui ne figurent pas directement dans la section qui vous intéresse. Par exemple, le Scénario 2 de SSM vous renvoie au Scénario 1 pour comprendre comment lire certaines CLI.
- Seul le scénario 1 couvre les protocoles IPv4 et IPv6 car les concepts sont fondamentalement identiques pour les deux familles d'adresses.
- Les exigences répertoriées dans ces scénarios supposent que la source et le récepteur sont directement reliés aux VTEP (voir la section Informations connexes « Sources et récepteurs en dehors du fabric » pour plus d'informations à ce sujet).
| Scénarios |
IPv4/v6 |
Ce qui est couvert dans chaque |
| Détails communs à tous les autres scénarios |
IPv4 |
Toujours requis : le sous-réseau MVPN et le NVE sont sains, le contrôle RPF vers n'importe quelle source TRM est le L3VNI. |
| RP AnyCast (chaque VTEP est un RP avec un IP RP commun) |
IPv4/v6 |
Les commandes BGP, PIM, IGMP, MFIB et FED sont présentées en détail pour IPv4/v6 et les exemples de capture |
| Pas de RP (superposition SSM) |
IPv4 |
Informations spécifiques à SSM. (Reportez-vous au scénario 1 pour obtenir des informations courantes) |
| RP interne au fabric (un RP commun pour le fabric) |
IPv4 |
Les commandes BGP, PIM, IGMP, MFIB et FED sont détaillées pour IPv4 |
| RP externe au fabric (le RP n'est pas dans le fabric) |
IPv4 |
Informations spécifiques à la périphérie IP vers fabric. (Reportez-vous au scénario 3 pour obtenir des informations courantes) |
| RP interne au fabric (un RP commun pour le fabric) avec L2VNI symétrique |
IPv4 |
Met en garde contre l'utilisation d'un RP unique dans le fabric lorsque le VNI est à la fois sur les VTEP expéditeur et récepteur. (Reportez-vous au scénario 3 pour obtenir des informations courantes) |
Dans ce document de dépannage, des commentaires ont été ajoutés à la fin de certaines lignes des sorties des commandes show. Cela a été fait pour mettre en évidence ou expliquer un aspect spécifique de cette ligne de sortie. Si un commentaire commence sur une nouvelle ligne, il fait référence à la ligne de sortie qui précède le commentaire. Cette notation a été utilisée dans tout le document pour mettre en évidence les commentaires dans les sorties des commandes show :
<-— Text highlighted in this format inside a command's output represents a comment.
This is done for explanation purpose only and is not part of the command's output.
Terminologie
| EVPN |
Réseau privé virtuel Ethernet |
|
| VXLAN |
Réseau local (LAN) virtuel extensible |
VXLAN est conçu pour surmonter les limitations inhérentes aux VLAN et au STP. Il s’agit d’une norme IETF proposée [RFC 7348] qui fournit les mêmes services réseau Ethernet de couche 2 que les VLAN, mais avec une plus grande flexibilité. Fonctionnellement, il s’agit d’un protocole d’encapsulation MAC-in-UDP qui s’exécute en tant que superposition virtuelle sur un réseau sous-jacent de couche 3. |
| VTEP |
Terminal de tunnel virtuel |
Il s’agit du périphérique qui effectue l’encapsulation et la désencapsulation |
| NÈVE |
Périphérie de virtualisation du réseau (interface) |
Interface logique sur laquelle l’encapsulation et la désencapsulation ont lieu |
| VNI |
Identificateur de réseau VXLAN |
Identifie de manière unique chaque sous-réseau ou segment de couche 2. Il existe deux types de VNI : Symétrique (L2VNI) : les VTEP ont le même VNI Asymétrique (L3VNI) : les VTEP n'ont pas le même VNI et sont routés via un seul VNI commun. |
| HAR |
Arborescence de distribution multidiffusion |
Arborescence de multidiffusion créée entre les VTEP pour l'encapsulation et la transmission tunnel du trafic multidiffusion du locataire. |
| PARESSEUX |
Diffusion, Monodiffusion inconnue, Multidiffusion |
Le trafic BUM est envoyé via le groupe Mcast lié au VNI dans la configuration NVE. |
| RP |
Point De Rendez-Vous |
Rôle joué par un périphérique en mode intermédiaire PIM. Point de rencontre commun pour les sources et les récepteurs multidiffusion. |
| AnyCast (RP) |
Point de rendez-vous AnyCast |
Deux RP ou plus sont configurés avec la même adresse IP sur les interfaces de bouclage. FHR s'enregistre auprès du RP le plus proche en fonction du routage de monodiffusion. |
| RPT (arborescence) |
Arborescence du chemin racine |
Également appelé arbre partagé ou *,G. Ce chemin est vers le RP |
| SPT (arborescence) |
Arbre du plus court chemin |
Le chemin le plus court vers la source, tel que déterminé par la table de routage de monodiffusion |
| FHR |
Routeur de premier saut |
Périphérique connecté directement (ARP adjacent) à la source. Le FHR enregistre les informations source auprès du RP. |
| LHR |
Routeur de dernier saut |
Périphérique auquel le récepteur est connecté |
| RPF |
Transfert par chemin inverse |
Chemin de monodiffusion vers la source. Les paquets de multidiffusion entrants ne sont pas acceptés/transférés à moins qu'ils ne soient reçus par le même chemin que la table de routage de monodiffusion. (les cas d'utilisation « ip multicast multipath » sont exclus). |
| MRIB |
Base d'informations de routage multidiffusion |
La table de routage de multidiffusion logicielle, également appelée table mroute |
| MFIB |
Base D'Informations De Transmission Multidiffusion |
Équivalent de multidiffusion de CEF. Rempli par les mises à jour de la base MRIB, qui fait partie du plan de transfert et cette structure de données est transmise à FED pour programmer le plan de données. |
| NOURRIR |
Pilote du moteur de transfert |
Le plan de données. Rempli par les informations du plan de transfert. FED est le pilote qui programme la couche ASIC (circuit intégré spécifique à l'application) (matériel). FED contient les informations utilisées pour écrire, réécrire et transférer des paquets. |
| IIF |
Interface entrante |
Interface PIM qui est également le chemin amont RPF monodiffusion vers la source. (vue dans show ip mroute) |
| OIF |
Interface de sortie |
Interface PIM activée en aval vers le récepteur. (vue dans show ip mroute) |
Vérifier
Vérification commune à tous les scénarios
Cette première section couvre les exigences de base nécessaires à l'un des scénarios.
- S'assurer que les homologues NVE requis sont opérationnels
- Assurez-vous que l'interface RPF vers la source dans le VRF du locataire est l'interface SVI L3VNI. Si l'interface RPF n'est pas l'interface SVI L3VNI, BGP n'envoie pas de route de jonction de type 7. Dans n'importe quel scénario, l'interface RPF doit pointer vers cette interface.
- Assurez-vous que le chemin sous-jacent (tunnel MDT) entre les homologues est terminé.
- Assurez-vous que le protocole BGP est utilisé pour le plan de contrôle de multidiffusion (utilisez MVPN par rapport à PIM)
Vérifier l'appairage NVE
Vérifiez que les homologues NVE sont actifs entre les VTEP pour l'un des scénarios de ce guide
- Les homologues NVE sont formés par des adresses apprises à partir de BGP.
Leaf-01#sh nve peers
Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time
nve1 50901 L3CP 172.16.254.4 7c21.0dbd.9548 50901 UP A/-/4 01:54:11 <-- IPv4 peering with Leaf 02
nve1 50901 L3CP 172.16.254.4 7c21.0dbd.9548 50901 UP A/M/6 17:48:36 <-- IPv6 peering with Leaf 02
Leaf-02#sh nve peers
Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time
nve1 50901 L3CP 172.16.254.3 10b3.d56a.8fc8 50901 UP A/-/4 01:55:44 <-- IPv4 peering with Leaf 01
nve1 50901 L3CP 172.16.254.3 10b3.d56a.8fc8 50901 UP A/M/6 17:56:19 <-- IPv6 peering with Leaf 01
Vérification de l'interface RPF dans le VRF du locataire
Si cette interface est une interface autre que l'interface SVI L3VNI, le protocole BGP ne crée pas de jonction MVPN de type 7.
- Si vous ne voyez pas cette interface, vérifiez qu'il n'y a aucun problème avec la configuration qui ferait de la route vers la source une interface qui n'est pas L3VNI.
Leaf-03#sh ip rpf vrf green 10.1.101.11 <-- Multicast source IP
RPF information for ? (10.1.101.11)
RPF interface: Vlan901 <-- RPF interface is the L3VNI SVI
RPF neighbor: ? (172.16.254.3) <-- Underlay Next hop IP
RPF route/mask: 10.1.101.0/24 <-- Network prefix for the Source
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
Vérifier que le plan de contrôle multidiffusion utilise BGP
- mdt overlay use-bgp : indique aux périphériques d'utiliser le type 5/6/7 de MVPN BGP comme protocole de signal (par rapport aux messages PIM)
- spt-only : un mot clé supplémentaire indique au périphérique d'utiliser uniquement les arborescences SPT dans AnyCast RP Scenario. Étant donné que chaque VTEP est un RP, aucune route MVPN de type 6 n'est utilisée.
Leaf-01
!
vrf definition green
rd 1:1
!
address-family ipv4
mdt auto-discovery vxlan
mdt default vxlan 239.1.1.1 <-- Defines MDT default underlay group address
mdt overlay use-bgp [spt-only] <-- Required for VTEP to use MVPN Type 5/6/7 versus PIM for multicast control plane. (spt-only used for Anycast RP scenario)
Vérification du groupe MDT
Le groupe MDT est commun à tous les scénarios, car il s'agit du groupe de tunnel externe dans lequel le groupe TRM est encapsulé.
Vérifiez que le groupe MDT est correctement programmé côté source
- L'interface entrante du groupe MDT est le bouclage côté source
- L'interface sortante du groupe MDT est l'interface sous-jacente
Vérification de Leaf-01 : la mroute MDT est correcte dans MRIB/MFIB
Leaf-01#sh ip mroute 239.1.1.1 172.16.254.3
(172.16.254.3, 239.1.1.1), 00:46:35/00:02:05, flags: FTx
Incoming interface: Loopback1, RPF nbr 0.0.0.0 <-- IIF is local loopback with 0.0.0.0 RPF indicating local
Outgoing interface list:
GigabitEthernet1/0/2, Forward/Sparse, 00:46:35/00:03:12 <-- OIF is the underlay uplink
Leaf-01#sh ip mfib 239.1.1.1 172.16.254.3
(172.16.254.3,239.1.1.1) Flags: HW
SW Forwarding: 2/0/150/0, Other: 1/1/0
HW Forwarding: 1458/0/156/0, Other: 0/0/0 <-- Hardware counters indicate the entry is operating in hardware and forwarding packets
Null0 Flags: A NS <--- Null0 (originated locally)
GigabitEthernet1/0/2 Flags: F NS <-- OIF is into the Underlay (Global route table)
Pkts: 0/0/1 Rate: 0 pps
Vérification de Leaf-01 : entrées FED pour le groupe MDT
Leaf-01#sh platform software fed switch active ip mfib 239.1.1.1/32 172.16.254.3 detail <-- the detail option gives summary of the HW indexes
MROUTE ENTRY vrf 0 (172.16.254.3, 239.1.1.1/32) <-- vrf 0 = global for this MDT S,G pair
HW Handle: 139738317079128 Flags:
RPF interface: Null0(1)): <-- Leaf-01 the Source (Null0)
HW Handle:139738317079128 Flags:A
Number of OIF: 2
Flags: 0x4 Pkts : 71 <-- packets that used this adjacency (similar to mfib command, but shown at the FED layer)
OIF Details:
Null0 A <-- The incoming interface is Local Loopback1 and A-Accept flag set
GigabitEthernet1/0/2 F NS <-- The Underlay Outgoing Interface and F-Forward flag set
Htm: 0x7f175cc0beb8 Si: 0x7f175cc0a6b8 Di: 0x7f175cc09df8 Rep_ri: 0x7f175cc0a1d8 <-- The DI (dest index) handle
DI details
----------
Handle:0x7f175cc09df8 Res-Type:ASIC_RSC_DI Res-Switch-Num:255 Asic-Num:255 Feature-ID:AL_FID_L3_MULTICAST_IPV4 Lkp-ftr-id:LKP_FEAT_INVALID ref_count:1
priv_ri/priv_si Handle:(nil) Hardware Indices/Handles: index0:0x538d mtu_index/l3u_ri_index0:0x0 index1:0x538d mtu_index/l3u_ri_index1:0x0
Brief Resource Information (ASIC_INSTANCE# 1)
----------------------------------------
Destination index = 0x538d
pmap = 0x00000000 0x00000002
pmap_intf : [GigabitEthernet1/0/2] <-- FED has the correct programming for the OIF
==============================================================
Vérifiez que le groupe MDT est correctement programmé côté récepteur
- L'interface entrante du groupe MDT est l'interface RPF de retour au bouclage côté source
- L'interface sortante du groupe MDT est l'interface du tunnel Encap/Decap
Vérification de Leaf-02 : la mroute MDT est correcte dans MRIB/MFIB
Leaf-02#sh ip mroute 172.16.254.3 239.1.1.1 <-- This is the Global MDT group
(172.16.254.3, 239.1.1.1), 00:23:35/00:01:09, flags: JTx <-- Source is Leaf-01 Lo1 IP
Incoming interface: GigabitEthernet1/0/2, RPF nbr 172.16.24.2
Outgoing interface list:
Tunnel0, Forward/Sparse, 00:23:35/00:00:24 <-- Decap Tunnel
Leaf-02#sh ip mfib 239.1.1.1 172.16.254.3
Default <-- Global routing table
(172.16.254.3,239.1.1.1) Flags: HW
SW Forwarding: 1/0/150/0, Other: 0/0/0
HW Forwarding: 5537/0/168/0, Other: 0/0/0 <-- Hardware counters indicate the entry is operating in hardware and forwarding packets
GigabitEthernet1/0/2 Flags: A <-- Accept via Underlay (Global) interface
Tunnel0, VXLAN Decap Flags: F NS <-- Forward to VxLAN decap Tunnel
Pkts: 0/0/1 Rate: 0 pps
Vérifier Leaf-02 : entrées FED pour le groupe MDT
Leaf-02#sh platform software fed switch active ip mfib 239.1.1.1/32 172.16.254.3 detail
MROUTE ENTRY vrf 0 (172.16.254.3, 239.1.1.1/32) <-- vrf 0 = global for this MDT S,G pair
HW Handle: 140397391831832 Flags:
RPF interface: GigabitEthernet1/0/2(57)): <-- RPF interface to 172.16.254.3
HW Handle:140397391831832 Flags:A
Number of OIF: 2
Flags: 0x4 Pkts : 1585 <-- packets that used this adjacency (similar to mfib command, but shown at the FED layer)
OIF Details:
Tunnel0 F NS <-- Send to decap tunnel to remove VxLAN header
(Adj: 0x73 ) <-- Tunnel0 Adjacency
GigabitEthernet1/0/2 A <-- Accept MDT packets from this interface
Htm: 0x7fb0d0f1f388 Si: 0x7fb0d0f1dc08 Di: 0x7fb0d0ed0438 Rep_ri: 0x7fb0d0ed07a8
RI details <-- Rewrite Index is used for VxLAN decapsulation
----------
Handle:0x7fb0d0ed07a8 Res-Type:ASIC_RSC_RI_REP Res-Switch-Num:255 Asic-Num:255 Feature-ID:AL_FID_L3_MULTICAST_IPV4 Lkp-ftr-id:LKP_FEAT_INVALID ref_count:1
priv_ri/priv_si Handle:(nil) Hardware Indices/Handles: index0:0x38 mtu_index/l3u_ri_index0:0x0 index1:0x38 mtu_index/l3u_ri_index1:0x0
Brief Resource Information (ASIC_INSTANCE# 0)
----------------------------------------
ASIC# 0
Replication list :
------------------
Total #ri : 6
Start_ri : 56
Common_ret : 0
Replication entry rep_ri 0x38 #elem = 1
0) ri[0]=0xE803 Dynamic port=88ri_ref_count:1 dirty=0
Leaf-02#sh platform hardware fed sw active fwd-asic resource asic all rewrite-index range 0xE803 0xE803
ASIC#:0 RI:59395 Rewrite_type:AL_RRM_REWRITE_L2_PAYLOAD_IPV4_EVPN_DECAP(118) Mapped_rii:LVX_EVPN_DECAP(246)
<...snip...>
Scénario 1. AnyCast RP (arborescences SPT uniquement) IPv4 et IPv6
Dans ce mode, il y a un RP situé sur chaque VTEP. Ces VTEP ne synchronisent pas les sources apprises via MSDP et il n'y a pas d'arborescence partagée. Au lieu de cela, le mode MDT utilise les informations BGP pour créer uniquement des arborescences de multidiffusion SPT. Ce mode est interchangeable en mode SPT-only ou en mode Anycast-RP distribué. Dans ce mode, chaque VTEP est le RP PIM. Ainsi, l'arbre (*, G) de chaque site est tronqué au niveau du VTEP local lui-même. Il n'est pas nécessaire d'envoyer (*, G) des jointures ou MVPN RT-6 à travers le fabric.
Diagramme du réseau
Pour ce mode, considérez 3 types de route BGP :
- EVPN Route-type 2. Cela permet aux autres PE qui doivent construire une route C-Multicast (MVPN type6/7) de revenir au PE d’origine, d’attacher le RT d’importation C-Multicast approprié afin que le PE d’origine puisse importer la route C-Multicast (RFC 6514 11.1.3) [RFC6514]. L'utilisation de cette VRI dépend de la commande "mdt overlay use-bgp" VRF.
- Route MVPN de type 5. Il s'agit de la même annonce que dans MVPN, et il s'agit de l'annonce d'une source/d'un groupe multidiffusion disponible
- Route MVPN de type 7. Les informations de la couche IGMP ou MLD et de l'EVPN Type-2 sont utilisées pour créer cette jointure de type BGP. Le Type-7 entraîne la création de l'OIF MRIB côté source.
Exigences EVPN de type 2 :
- La source de multidiffusion connectée directement est en ligne.
- FHR (source VTEP) vérifie la contiguïté ARP (ou ND) et CEF (confirme que la source est connectée directement).
- FHR est à l'origine de la mise à jour BGP EVPN Type-2
Configuration requise pour MVPN Type-5 :
- Le besoin de la connexion directe source est résolu
- Le RP est local, donc FHR s'enregistre automatiquement
- FHR lance la mise à jour BGP MVPN de type 5
Configuration requise pour MVPN Type-7 :
- Une entrée EVPN de type 2 est présente (requise pour construire la route C-Multicast de type 7 avec VRI correct et envoyée depuis la source VTEP)
- L'entrée MVPN de type 5 est présente (requise pour résoudre la paire source/groupe disponible pour la jointure SPT)
- Le rapport d'adhésion IGMP ou MLD a été reçu et traité par le VTEP LHR
- L'interface LHR VTEP RPF est l'interface L3VNI du fabric
Vérification des routes EVPN et MVPN BGP
Vérification de Leaf-01 : création de l'EVPN de type 2
### IPv4 ###
Leaf-01#sh bgp l2vpn evpn all route-type 2 0 F4CFE24334C5 10.1.101.11
...or you can also use:
Leaf-01#sh bgp l2vpn evpn detail [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24
BGP routing table entry for [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24, version 6
Paths: (1 available, best #1, table evi_101)
Advertised to update-groups:
1
Refresh Epoch 1
Local
:: (via default) from 0.0.0.0 (172.16.255.3) <-- Leaf-01 locally created
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
EVPN ESI: 00000000000000000000, Label1 10101, Label2 50901
Extended Community: RT:1:1 RT:65001:101 MVPN AS:65001:0.0.0.0
MVPN VRF:172.16.255.3:2 ENCAP:8 Router MAC:10B3.D56A.8FC8 <-- MVPN VRI RT is part of the EVPN Type-2
Local irb vxlan vtep:
vrf:green, l3-vni:50901 <-- Vrf and VxLAN tag
local router mac:10B3.D56A.8FC8
core-irb interface:Vlan901 <-- L3VNI SVI
vtep-ip:172.16.254.3 <-- Leaf-01 VTEP
rx pathid: 0, tx pathid: 0x0
Updated on Dec 16 2020 17:40:29 UTC
### IPv6 ###
Leaf-01#sh bgp l2vpn evpn all route-type 2 0 F4CFE24334C1 FC00:1:101::11
...or you can also use:
Leaf-01#sh bgp l2vpn evpn detail [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36
BGP routing table entry for [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36, version 6
Paths: (1 available, best #1, table evi_101)
Advertised to update-groups:
1
Refresh Epoch 1
Local
:: (via default) from 0.0.0.0 (172.16.255.3) <-- Leaf-01 locally created
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
EVPN ESI: 00000000000000000000, Label1 10101, Label2 50901
Extended Community: RT:1:1 RT:65001:101 MVPN AS:65001:0.0.0.0
MVPN VRF:172.16.255.3:2 ENCAP:8 Router MAC:10B3.D56A.8FC8 <-- MVPN VRI RT is part of the EVPN Type-2
Local irb vxlan vtep:
vrf:green, l3-vni:50901
local router mac:10B3.D56A.8FC8
core-irb interface:Vlan901 <-- L3VNI SVI
vtep-ip:172.16.254.3 <-- Leaf-01 VTEP
rx pathid: 0, tx pathid: 0x0
Updated on Mar 22 2021 19:54:18 UTC
Vérifier Leaf-01 : les débogages ARP/IPv6 ND et EVPN indiquent que ARP/ND est appris, puis que le type de route 2 est créé et envoyé
### IPv4 ###
Leaf-01#sh debugging
ARP:
ARP packet debugging is on
BGP L2VPN EVPN:
BGP updates debugging is on for address family: L2VPN E-VPN
BGP update events debugging is on for address family: L2VPN E-VPN
*Dec 17 17:00:06.480: IP ARP: rcvd rep src 10.1.101.11 f4cf.e243.34c5, dst 10.1.101.11 Vlan101 tableid 2 <-- Multicast Source ARP
*Dec 17 17:00:06.481: BGP: EVPN Rcvd pfx: [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24, net flags: 0 <-- BGP Triggered Type-2 creation
*Dec 17 17:00:06.481: TRM communities added to sourced RT2 <-- TRM extended VRI communities being injected into EVPN Type-2
*Dec 17 17:00:06.481: BGP(10): update modified for [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/30 <-- Modifying the update
*Dec 17 17:00:06.481: BGP(10): 172.16.255.1 NEXT_HOP set to vxlan local vtep-ip 172.16.254.3 for net [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24
*Dec 17 17:00:06.481: BGP(10): update modified for [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/30
*Dec 17 17:00:06.481: BGP(10): (base) 172.16.255.1 send UPDATE (format) [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/30, next 172.16.254.3, metric 0, path Local, extended community RT:1:1 RT:65001:101 MVPN AS:65001:0.0.0.0 MVPN VRF:172.16.255.3:2 ENCAP:8 Router MAC:10B3.D56A.8FC8
<--- Final update sent to RR with standard EVPN community info and required MVPN community attributes
### IPv6 ###
Leaf-01#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
ICMP ND HA events debugging is ON
IPv6 ND:
Mar 23 14:29:51.935: ICMPv6-ND: (Vlan101,FC00:1:101::11) Resolution request
Mar 23 14:29:51.935: ICMPv6-ND: (Vlan101,FC00:1:101::11) DELETE -> INCMP
Mar 23 14:29:51.935: ICMPv6-ND HA: in Update Neighbor Cache: old state 6 new state 0
Mar 23 14:29:51.935: ICMPv6-ND HA: add or delete entry not synced as no peer detected
Mar 23 14:29:51.936: ICMPv6-ND: (Vlan101,FC00:1:101::11) Sending NS
Mar 23 14:29:51.936: ICMPv6-ND: (Vlan101,FC00:1:101::11) Queued data for resolution
Mar 23 14:29:51.953: ICMPv6-ND: (Vlan101,FC00:1:101::11) Received NA from FC00:1:101::11
Mar 23 14:29:51.953: ICMPv6-ND: Validating ND packet options: valid
Mar 23 14:29:51.953: ICMPv6-ND: (Vlan101,FC00:1:101::11) LLA f4cf.e243.34c1
Mar 23 14:29:51.953: ICMPv6-ND HA: modify entry not synced as no peer detected
Mar 23 14:29:51.953: ICMPv6-ND: (Vlan101,FC00:1:101::11) INCMP -> REACH <-- peer is reachable
Leaf-01#debug bgp l2vpn evpn updates
Leaf-01#debug bgp l2vpn evpn updates events
BGP L2VPN EVPN:
Mar 23 14:11:56.462: BGP: EVPN Rcvd pfx: [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36, net flags: 0 <-- BGP Triggered Type-2 creation
Mar 23 14:11:57.462: TRM communities added to sourced RT2
ar 23 14:11:57.474: BGP(10): update modified for [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/42
Mar 23 14:11:57.474: BGP(10): 172.16.255.1 NEXT_HOP set to vxlan local vtep-ip 172.16.254.3 for net [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36
Mar 23 14:11:57.474: BGP(10): update modified for [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/42
Mar 23 14:11:57.474: BGP(10): (base) 172.16.255.1 send UPDATE (format) [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/42, next 172.16.254.3, metric 0, path Local, extended community RT:1:1 RT:65001:101 MVPN AS:65001:0.0.0.0 MVPN VRF:172.16.255.3:2 ENCAP:8 Router MAC:10B3.D56A.8FC8
<--- Final update sent to RR with standard EVPN community info and required MVPN community attributes
Vérifier Leaf-02 : côté source Le type de route 2 est appris dans BGP côté récepteur
### IPv4 ###
Leaf-02#sh bgp l2vpn evpn all | b 10.1.101.11
* i [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24 <-- Remote VTEP route-type 2
172.16.254.3 0 100 0 ?
*>i 172.16.254.3 0 100 0 ? <-- IP of Leaf01 Lo1
Leaf-02#sh bgp l2vpn evpn route-type 2 0 F4CFE24334C5 10.1.101.11
...or you can also use:
Leaf-02#sh bgp l2vpn evpn detail [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24
BGP routing table entry for [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24, version 175
Paths: (2 available, best #2, table EVPN-BGP-Table) <-- In BGP EVPN table
Flag: 0x100
Not advertised to any peer
Refresh Epoch 2
Local
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
EVPN ESI: 00000000000000000000, Label1 10101, Label2 50901
Extended Community: RT:1:1 RT:65001:101 MVPN AS:65001:0.0.0.0
MVPN VRF:172.16.255.3:2 ENCAP:8 Router MAC:10B3.D56A.8FC8
Originator: 172.16.255.3, Cluster list: 172.16.255.2
rx pathid: 0, tx pathid: 0
Updated on Dec 14 2020 19:58:57 UTC
MVPN AS:65001:0.0.0.0 <-- MVPN Autonomous System
MVPN VRF:172.16.255.3:2 <-- VRI Extended Community to be used in MVPN Type-7
Router MAC:10B3.D56A.8FC8 <-- Leaf-01 RMAC
Label2 50901 <-- L3VNI 50901
### IPv6 ###
Leaf-02#sh bgp l2vpn evpn all | b FC00:1:101::11
* i [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36
172.16.254.3 0 100 0 ?
*>i 172.16.254.3 0 100 0 ? <-- IP of Leaf01 Lo1
Leaf-02#sh bgp l2vpn evpn route-type 2 0 F4CFE24334C1 FC00:1:101::11
...or you can also use:
Leaf-02#sh bgp l2vpn evpn detail [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36
BGP routing table entry for [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36, version 659
Paths: (2 available, best #2, table EVPN-BGP-Table) <-- In BGP EVPN table
Flag: 0x100
Not advertised to any peer
Refresh Epoch 2
Local
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
EVPN ESI: 00000000000000000000, Label1 10101, Label2 50901
Extended Community: RT:1:1 RT:65001:101 MVPN AS:65001:0.0.0.0
MVPN VRF:172.16.255.3:2 ENCAP:8 Router MAC:10B3.D56A.8FC8
Originator: 172.16.255.3, Cluster list: 172.16.255.2
rx pathid: 0, tx pathid: 0
Updated on Mar 23 2021 14:11:57 UTC
MVPN AS:65001:0.0.0.0 <-- MVPN Autonomous System
MVPN VRF:172.16.255.3:2 <-- VRI Extended Community to be used in MVPN Type-7
Router MAC:10B3.D56A.8FC8 <-- Leaf-01 RMAC
Label2 50901 <-- L3VNI 50901
Vérifier Leaf-02 : la route source de type 5 est apprise dans BGP sur le récepteur VTEP Leaf-02
### IPv4 ###
Leaf-02#sh bgp ipv4 mvpn all route-type 5 10.1.101.11 226.1.1.1
...or you can also use:
Leaf-02#sh bgp ipv4 mvpn detail [5][1:1][10.1.101.11][226.1.1.1]/18
BGP routing table entry for [5][1:1][10.1.101.11][226.1.1.1]/18, version 72 <-- Type-5 contains advertised S,G pair
Paths: (2 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer) <-- In BGP IPv4 MVPN table
Flag: 0x100
Not advertised to any peer
Refresh Epoch 1
Local
172.16.255.3 (metric 3) from 172.16.255.2 (172.16.255.2) <-- Loopback0 of Leaf-01
Origin incomplete, metric 0, localpref 100, valid, internal
Community: no-export
Extended Community: RT:1:1
Originator: 172.16.255.3, Cluster list: 172.16.255.2
rx pathid: 0, tx pathid: 0
Updated on Dec 15 2020 16:54:53 UTC
### IPv6 ###
Leaf-02#sh bgp ipv6 mvpn all route-type 5 FC00:1:101::11 FF06:1::1
...or you can also use:
Leaf-02#sh bgp ipv6 mvpn detail [5][1:1][FC00:1:101::11][FF06:1::1]/42
BGP routing table entry for [5][1:1][FC00:1:101::11][FF06:1::1]/42, version 11 <-- Type-5 contains advertised S,G pair
Paths: (2 available, best #1, table MVPNV6-BGP-Table, not advertised to EBGP peer) <-- In BGP IPv6 MVPN table
Flag: 0x100
Not advertised to any peer
Refresh Epoch 1
Local
172.16.255.3 (metric 3) from 172.16.255.2 (172.16.255.2) <-- Loopback0 of Leaf-01
Origin incomplete, metric 0, localpref 100, valid, internal
Community: no-export
Extended Community: RT:1:1
Originator: 172.16.255.3, Cluster list: 172.16.255.2
rx pathid: 0, tx pathid: 0
Updated on Mar 23 2021 15:13:06 UTC
Vérifiez que Leaf-02 : a besoin des informations BGP de Leaf-01 pour créer le Type-7. L'exigence finale est que l'IGMP ou le MLD a traité un rapport d'adhésion qui informe le VTEP qu'il y a un destinataire intéressé.
### IPv4 ###
Leaf-02#sh ip igmp snooping groups vlan 102
Vlan Group Type Version Port List
-----------------------------------------------------------------------
102 226.1.1.1 igmp v2 Gi1/0/10 <-- Receiver joined on Gi1/0/10
### IPv6 ###
Leaf-02#sh ipv6 mld vrf green groups detail
Interface: Vlan102 <-- Join on Vlan 102
Group: FF06:1::1 <-- Group joined
Uptime: 06:38:25
Router mode: EXCLUDE (Expires: 00:02:14)
Host mode: INCLUDE
Last reporter: FE80::46D3:CAFF:FE28:6CC1 <-- MLD join from Receiver link-local address
Source list is empty <-- ASM join, no sources listed
Leaf-02#sh ipv6 neighbors vrf green
IPv6 Address Age Link-layer Addr State Interface
FE80::46D3:CAFF:FE28:6CC1 0 44d3.ca28.6cc1 REACH Vl102 <-- Receiver IP & MAC
Leaf-02#sh ipv6 mld snooping address vlan 102 <-- If MLD snooping is on, it can be checked as well
Vlan Group Type Version Port List
-----------------------------------------------------------------------
102 FF06:1::1 mld v2 Gi1/0/10 <-- Receiver joined on Gi1/0/10
Vérifier Leaf-02 : les débogages MVPN indiquent que le type de route 7 est créé lorsque le rapport d'adhésion IGMP/MLD arrive et que les types EVPN 2 et 5 requis sont déjà installés.
### IPv4 ###
Leaf-02#debug bgp ipv4 mvpn updates
Leaf-02#debug bgp ipv4 mvpn updates events
*Dec 14 19:41:57.645: BGP[15] MVPN: add c-route, type 7, bs len 0 asn=0, rd=1:1,
*Dec 14 19:41:57.645: source=10.1.101.11/4,
*Dec 14 19:41:57.645: group=226.1.1.1/4,
*Dec 14 19:41:57.645: nexthop=172.16.254.3, <-- Source is via Leaf-01 IP
*Dec 14 19:41:57.645: len left = 0
*Dec 14 19:41:57.645: BGP[14] MVPN umh lookup: vrfid 2, source 10.1.101.11
*Dec 14 19:41:57.645: BGP[4] MVPN umh lookup: vrfid 2, source 10.1.101.11, net 1:1:10.1.101.11/32, 1:1:10.1.101.11/32 with matching nexthop 172.16.254.3, remote-rd [172.16.]: 0x9:65001:0.0.0.0, 0x10B:172.16.255.3:2,
*Dec 14 19:41:57.646: BGP: MVPN(15) create local route [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22
*Dec 14 19:41:57.646: BGP[15] MVPN: add c-route, type 7, bs len 0 asn=65001, rd=1:1,
### IPv6 ###
Leaf-02#debug bgp ipv6 mvpn updates
Leaf-02#debug bgp ipv6 mvpn updates events
Mar 23 15:46:11.171: BGP[16] MVPN: add c-route, type 7, bs len 0 asn=0, rd=1:1,
Mar 23 15:46:11.171: source=FC00:1:101::11/16,
Mar 23 15:46:11.171: group=FF06:1::1/16,
Mar 23 15:46:11.171: nexthop=::FFFF:172.16.254.3, <-- IPv4 next hop of Leaf-01
Mar 23 15:46:11.171: len left = 0
Mar 23 15:46:11.171: BGP[19] MVPN umh lookup: vrfid 2, source FC00:1:101::11
Mar 23 15:46:11.171: BGP[5] MVPN umh lookup: vrfid 2, source FC00:1:101::11, net [1:1]FC00:1:101::11/128, [1:1]FC00:1:101::11/128 with matching nexthop ::FFFF:172.16.254.3, remote-rd [172.16.]: 0x9:65001:0.0.0.0, 0x10B:172.16.255.3:2,
Mar 23 15:46:11.172: BGP: MVPN(16) create local route [7][172.16.254.3:101][65001][FC00:1:101::11][FF06:1::1]/46
Mar 23 15:46:11.172: BGP[16] MVPN: add c-route, type 7, bs len 0 asn=65001, rd=1:1,
Verify Leaf-01 : MVPN Type-7 reçu de Leaf-02
### IPv4 ###
Leaf-01#sh bgp ipv4 mvpn all route-type 7 172.16.254.3:101 65001 10.1.101.11 226.1.1.1
...or you can also use:
Leaf-01#sh bgp ipv4 mvpn detail [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22
BGP routing table entry for [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22, version 76
Paths: (2 available, best #1, table MVPNv4-BGP-Table) <-- In BGP IPv4 MVPN table
Not advertised to any peer
Refresh Epoch 1
Local
172.16.255.4 (metric 3) from 172.16.255.2 (172.16.255.2) <-- loopback of Leaf-02 Receiver VTEP
Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:172.16.255.3:2 <-- The VRI derived from EVPN Type-2 and added to the MVPN Type-7
Originator: 172.16.255.4, Cluster list: 172.16.255.2
rx pathid: 0, tx pathid: 0
Updated on Dec 15 2020 14:14:38 UTC
### IPv6 ###
Leaf-01#sh bgp ipv6 mvpn all route-type 7 172.16.254.3:101 65001 FC00:1:101::11 FF06:1::1
...or you can also use:
Leaf-01#sh bgp ipv6 mvpn detail [7][172.16.254.3:101][65001][FC00:1:101::11][FF06:1::1]/46
BGP routing table entry for [7][172.16.254.3:101][65001][FC00:1:101::11][FF06:1::1]/46, version 45
Paths: (2 available, best #1, table MVPNV6-BGP-Table) <-- In BGP IPv6 MVPN table
Not advertised to any peer
Refresh Epoch 1
Local
172.16.255.4 (metric 3) from 172.16.255.1 (172.16.255.1) <-- loopback of Leaf-02 Receiver VTEP
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:172.16.255.3:2 <-- The VRI derived from EVPN Type-2 and added to the MVPN Type-7
Originator: 172.16.255.4, Cluster list: 172.16.255.1
rx pathid: 0, tx pathid: 0x0
Updated on Mar 23 2021 15:46:11 UTC
Verify Leaf-01 : les débogages MVPN affichent le type de route 7 reçu avec la cible de route MVPN VRI
*Dec 17 16:16:31.923: BGP(15): 172.16.255.2 rcvd UPDATE w/ attr: nexthop 172.16.255.4, origin ?, localpref 100, metric 0, originator 172.16.255.4, clusterlist 172.16.255.2, extended community RT:172.16.255.3:2 <-- VRI RT
*Dec 17 16:16:31.923: BGP(15): 172.16.255.2 rcvd [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22 <-- Received MVPN Type-7
<...only update from Spine-02 172.16.255.2 ...>
*Dec 17 16:16:31.923: BGP(15): skip vrf default table RIB route [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22
*Dec 17 16:16:31.924: BGP(15): add RIB route (0:0)[7][1:1][65001][10.1.101.11/32][226.1.1.1/32]/22
(Skipping IPv6, see the debugs demonstrated in previous steps)
Verify Leaf-02 : la table BGP complète contient les types EVPN Leaf-01 de type 2 et MVPN de type 5, ainsi que le type 7 généré par le récepteur Leaf-02
### IPv4 ###
Leaf-02#sh bgp l2vpn evpn all | b 10.1.101.11
* i [2][172.16.254.3:101][0][48][F4CFE24334C5][32][10.1.101.11]/24 <-- Remote VTEP route-type 2
172.16.254.3 0 100 0 ?
*>i 172.16.254.3 0 100 0 ? <-- IP of Leaf01 Lo1
Leaf-02#sh bgp ipv4 mvpn all
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green) <-- default RD for vrf green
*>i [5][1:1][10.1.101.11][226.1.1.1]/18 <-- Type-5, source & group
172.16.255.3 0 100 0 ? <-- Next hop Leaf-01 IP
* i 172.16.255.3 0 100 0 ?
Route Distinguisher: 172.16.254.3:101 <-- MVPN RD sent from Source Leaf-01
*> [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22 <-- Type-7 BGP Join Entry
0.0.0.0 32768 ? <-- Locally created (0.0.0.0) by Leaf-02
### IPv6 ###
Leaf-02#sh bgp l2vpn evpn all | b FC00:1:101::11
* i [2][172.16.254.3:101][0][48][F4CFE24334C1][128][FC00:1:101::11]/36 <-- Remote VTEP route-type 2
172.16.254.3 0 100 0 ?
*>i 172.16.254.3 0 100 0 ? <-- IP of Leaf-01 Lo1
Leaf-02#sh bgp ipv6 mvpn all
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green) <-- default RD for vrf green
*>i [5][1:1][FC00:1:101::11][FF06:1::1]/42 <-- Type-5, source & group
172.16.255.3 0 100 0 ? <-- IPv4 Next hop Leaf-01 IP
* i 172.16.255.3 0 100 0 ?
Route Distinguisher: 172.16.254.3:101 <-- MVPN RD sent from Source Leaf-01
*> [7][172.16.254.3:101][65001][FC00:1:101::11][FF06:1::1]/46 <-- Type-7 BGP Join Entry
:: 32768 ? <-- Locally created (::) by Leaf-02
Vérification du groupe TRM Leaf-01 (FHR)
Vérifiez que les groupes MDT et TRM sont correctement formés du côté source.
- L'interface entrante du groupe TRM est l'interface SVI associée au VRF client
- L'interface sortante du groupe TRM est la L3VNI SVI
Vérifier Leaf-01 : le groupe TRM MRIB/MFIB
### IPv4 ###
Leaf-01#sh ip mroute vrf green 226.1.1.1 10.1.101.11
(10.1.101.11, 226.1.1.1), 02:57:56/00:03:14, flags: FTGqx <-- Flags: BGP S-A Route
Incoming interface: Vlan101, RPF nbr 0.0.0.0 <-- Local to Vlan101 Direct connected source
Outgoing interface list:
Vlan901, Forward/Sparse, 02:57:56/stopped <-- OIF is VxLAN L3VNI
Leaf-01#sh ip mfib vrf green 226.1.1.1 10.1.101.11
VRF green <-- Tenant VRF
(10.1.101.11,226.1.1.1) Flags: HW
SW Forwarding: 1/0/100/0, Other: 0/0/0
HW Forwarding: 5166/0/118/0, Other: 0/0/0 <-- Hardware counters indicate the entry is operating in hardware and forwarding packets
Vlan101 Flags: A <-- Accept flag set on Connected Source SVI
Vlan102 Flags: F NS
Pkts: 0/0/1 Rate: 0 pps
Vlan901, VXLAN v4 Encap (50901, 239.1.1.1) Flags: F <-- Forward via Vlan 901. Use MDT group 239.1.1.1, vxlan tag 50901
Pkts: 0/0/0 Rate: 0 pps
### IPv6 ###
Leaf-01#sh ipv6 mroute vrf green
(FC00:1:101::11, FF06:1::1), 01:01:00/00:01:08, flags: SFTGq <-- Flags: q - BGP S-A Route, G - BGP Signal Received
Incoming interface: Vlan101
RPF nbr: FE80::F6CF:E2FF:FE43:34C1 <-- link local address of Source
Immediate Outgoing interface list:
Vlan901, Forward, 01:01:00/never <-- OIF is VxLAN L3VNI
Leaf-01#sh ipv6 mfib vrf green FF06:1::1
VRF green <-- Tenant VRF
(FC00:1:101::11,FF06:1::1) Flags: HW
SW Forwarding: 0/0/0/0, Other: 1/0/1
HW Forwarding: 1968/0/118/0, Other: 0/0/0 <-- Hardware counters indicate the entry is operating in hardware and forwarding packets
Vlan101 Flags: A NS <-- Accept flag set on Connected Source SVI
Vlan901, VXLAN v4 Encap (50901, 239.1.1.1) Flags: F <-- Forward via Vlan 901. Use MDT group 239.1.1.1, vxlan tag 50901
Pkts: 0/0/0 Rate: 0 pps
Vérifier Leaf-01 : le groupe TRM dans FED
### IPv4 ###
Leaf-01#sh platform software fed switch active ip mfib vrf green 226.1.1.1/32 10.1.101.11
Multicast (S,G) Information
VRF : 2 <-- VRF ID 2 = vrf green (from "show vrf detail")
Source Address : 10.1.101.11
HTM Handler : 0x7f175cc08578
SI Handler : 0x7f175cc06ea8
DI Handler : 0x7f175cc067c8
REP RI handler : 0x7f175cc06b38
Flags : {Svl}
Packet count : 39140 <-- packets that used this adjacency (similar to mfib command, but shown at the FED layer)
State : 4
RPF :
Vlan101 A <-- Accept on Vlan 101 in Tenant vrf green
OIF :
Vlan102 F NS
Vlan101 A
Vlan901 F {Remote} <-- Forward via L3VNI interface
(Adj: 0x6a ) <-- Adjacency for this entry
### IPv6 ###
Leaf-01#sh plat soft fed switch active ipv6 mfib vrf green FF06:1::1/128 FC00:1:101::11
Multicast (S,G) Information
VRF : 2 <-- VRF ID 2 = vrf green (from "show vrf detail")
Source Address : fc00:1:101::11
HTM Handler : 0x7fba88d911b8
SI Handler : 0x7fba88fc4348
DI Handler : 0x7fba88fc8dc8
REP RI handler : 0x7fba88fc8fd8
Flags : {Svl}
Packet count : 2113 <-- packets that used this adjacency (similar to mfib command, but shown at the FED layer)
State : 4
RPF :
Vlan101 A {Remote} <-- Accept on Vlan 101 in Tenant vrf green (says remote, but this is a local host)
OIF :
Vlan101 A {Remote}
Vlan901 F {Remote} <-- Forward via L3VNI interface
(Adj: 0x7c ) <-- Adjacency for this entry
Vérification de Leaf-01 : la contiguïté est correcte
### IPv4 ###
Leaf-01#sh platform software fed switch active ip adj
IPV4 Adj entries
dest if_name dst_mac si_hdl ri_hdl pd_flags adj_id Last-modified
---- ------- ------- ------ ------ -------- ----- ------------------------
239.1.1.1 nve1.VNI50901 4500.0000.0000 0x7f175ccd8c38 0x7f175ccd8de8 0x60 0x6a 2020/12/16 17:39:55.747
*** Adjacency 0x6a details ***
Destination = the MDT tunnel multicast group 239.1.1.1
Interface = nve1.VNI50901 (the L3VNI 50901)
### IPv6 ###
Leaf-01#sh platform software fed switch active ipv6 adj
IPV6 Adj entries
dest if_name dst_mac si_hdl ri_hdl pd_flags adj_id Last-modified
---- ------- ------- ------ ------ -------- ------ -------------
239.1.1.1 nve1.VNI50901 4500.0000.0000 0x7fba88cf9fc8 0x7fba88cfa248 0x60 0x7c 2021/03/22 19:54:09.831
*** Adjacency 0x7c details ***
Destination = the MDT tunnel multicast group 239.1.1.1
Interface = nve1.VNI50901 (the L3VNI 50901)
Vérification du groupe TRM Leaf-02 (LHR)
Vérifiez que les groupes MDT et TRM sont correctement formés côté récepteur.
- L'interface entrante du groupe TRM est l'interface SVI associée au L3VNI
- L'interface sortante du groupe TRM est l'interface SVI du client où la jonction IGMP a été traitée.
Vérification de Leaf-02 : la route TRM (Tenant Multicast Route) dans MRIB/MFIB
Leaf-02#sh ip mroute vrf green 226.1.1.1 10.1.101.11 <-- The TRM Client group
(10.1.101.11, 226.1.1.1), 00:26:03/00:02:37, flags: TgQ
Incoming interface: Vlan901, RPF nbr 172.16.254.3 <-- Via L3VNI, RPF to Leaf-01
Outgoing interface list:
Vlan102, Forward/Sparse, 00:26:03/00:03:10 <-- Client Receiver Vlan
Leaf-02#sh ip mfib vrf green 226.1.1.1 10.1.101.11
VRF green <--- The Tenant VRF
(10.1.101.11,226.1.1.1) Flags: HW
SW Forwarding: 1/0/100/0, Other: 0/0/0
HW Forwarding: 39013/0/126/0, Other: 0/0/0 <-- Hardware counters indicate the entry is operating in hardware and forwarding packets
Vlan901, VXLAN Decap Flags: A <-- L3VNI Accept and decapsulate from VxLAN
Vlan102 Flags: F NS <-- Forward to the Tenant Vlan
Pkts: 0/0/1 Rate: 0 pps
Vérifier Leaf-02 : le groupe TRM dans FED
### IPv4 ###
Leaf-02#sh platform software fed switch active ip mfib vrf green 226.1.1.1/32 10.1.101.11 detail <-- Use detail option to resolve DI (Dest Index)
MROUTE ENTRY vrf 2 (10.1.101.11, 226.1.1.1/32)
HW Handle: 140397391947768 Flags: {Svl}
RPF interface: Vlan901(60)): SVI <-- RPF interface = L3VNI SVI Vlan901
HW Handle:140397391947768 Flags:A {Remote}
Number of OIF: 2
Flags: 0x4 Pkts : 39387 <-- packets that used this adjacency (similar to mfib command, but shown at the FED layer)
OIF Details:
Vlan102 F NS <-- Client Vlan
Vlan901 A {Remote} <-- Accept interface is RPF to source via Remote EVPN next hop
(Adj: 0xf80003c1 ) <-- Adj for vlan 901(show plat soft fed sw active ipv4 adj)
Htm: 0x7fb0d0edfb48 Si: 0x7fb0d0ee9158 Di: 0x7fb0d0eca8f8 Rep_ri: 0x7fb0d0ef2b98
DI details <-- Dest index (egress interface) details
----------
Handle:0x7fb0d0eca8f8 Res-Type:ASIC_RSC_DI Res-Switch-Num:255 Asic-Num:255 Feature-ID:AL_FID_L3_MULTICAST_IPV4 Lkp-ftr-id:LKP_FEAT_INVALID ref_count:1
priv_ri/priv_si Handle:(nil) Hardware Indices/Handles: index0:0x538b mtu_index/l3u_ri_index0:0x0 index1:0x538b mtu_index/l3u_ri_index1:0x0
Brief Resource Information (ASIC_INSTANCE# 1) <-- Gi1/0/10 is mapped to instance 1
----------------------------------------
Destination index = 0x538b
pmap = 0x00000000 0x00000200
pmap_intf : [GigabitEthernet1/0/10] <-- Maps to Gi1/0/10, the port toward the client
==============================================================
### IPv6 ###
Leaf-02#sh platform software fed switch active ipv6 mfib vrf green FF06:1::1/128 FC00:1:101::11 detail
MROUTE ENTRY vrf 2 (fc00:1:101::11, ff06:1::1/128)
HW Handle: 139852137577736 Flags: {Svl}
RPF interface: Vlan901(62)): SVI <-- RPF to Source L3VNI SVI 901
HW Handle:139852137577736 Flags:A {Remote}
Number of OIF: 2
Flags: 0x4 Pkts : 7445 <-- Packets use this Entry
OIF Details:
Vlan102 F NS <-- F - Forward. The OIF Vlan SVI 901
Vlan901 A {Remote}
(Adj: 0xf80003e2 ) <-- Adj for vlan 901 (show plat soft fed sw active ipv6 adj)
Htm: 0x7f31dcfee238 Si: 0x7f31dcfba5d8 Di: 0x7f31dcfc2358 Rep_ri: 0x7f31dcfcb1a8
DI details
----------
Handle:0x7f31dcfc2358 Res-Type:ASIC_RSC_DI Res-Switch-Num:255 Asic-Num:255 Feature-ID:AL_FID_L3_MULTICAST_IPV6 Lkp-ftr-id:LKP_FEAT_INVALID ref_count:1
priv_ri/priv_si Handle:(nil) Hardware Indices/Handles: index0:0x5381 mtu_index/l3u_ri_index0:0x0 index1:0x5381 mtu_index/l3u_ri_index1:0x0
Brief Resource Information (ASIC_INSTANCE# 1) <-- Gig1/0/10 is mapped to Instance 1
----------------------------------------
Destination index = 0x5381
pmap = 0x00000000 0x00000200
pmap_intf : [GigabitEthernet1/0/10] <-- Maps to Gig1/0/10, the port toward the client
==============================================================
Leaf-02#sh platform software fed switch active ifm mappings
Interface IF_ID Inst Asic Core Port SubPort Mac Cntx LPN GPN Type Active
GigabitEthernet1/0/10 0x12 1 0 1 9 0 5 15 10 10 NIF Y <-- Instance 1 of ASIC 0
Verify Leaf-02 : La capture de paquets montre le groupe de tunnels MDT externe avec le trafic client interne
Leaf-02#sh mon ca 1 parameter
monitor capture 1 interface GigabitEthernet1/0/2 IN
monitor capture 1 match any
monitor capture 1 buffer size 10
monitor capture 1 limit pps 1000
### IPv4 ###
Leaf-02#sh mon capture 1 buffer detailed
Ethernet II, Src: 7c:21:0d:bd:2c:d6 (7c:21:0d:bd:2c:d6), Dst: 01:00:5e:01:01:01 (01:00:5e:01:01:01) <-- MAC is matching 239.1.1.1
Type: IPv4 (0x0800) <-- IPv4 outer packet
Internet Protocol Version 4, Src: 172.16.254.3, Dst: 239.1.1.1 <- Leaf-01 Source IP and MDT outer tunnel Group
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Time to live: 253
User Datagram Protocol, Src Port: 65287, Dst Port: 4789 <-- VxLAN UDP port 4789
Virtual eXtensible Local Area Network
Flags: 0x0800, VXLAN Network ID (VNI)
Group Policy ID: 0
VXLAN Network Identifier (VNI): 50901 <-- L3VNI value
Type: IPv4 (0x0800) <-- IPv4 inner packet
Internet Protocol Version 4, Src: 10.1.101.11, Dst: 226.1.1.1 <-- Encapsulated IPv4 TRM group
0100 .... = Version: 4
Time to live: 254
Protocol: ICMP (1)
(multiple lines removed from this example capture)
### IPv6 ###
Leaf-02#sh mon capture 1 buffer detailed
Ethernet II, Src: 7c:21:0d:bd:2c:d6 (7c:21:0d:bd:2c:d6), Dst: 01:00:5e:01:01:01 (01:00:5e:01:01:01) <-- DMAC is matching 239.1.1.1
Type: IPv4 (0x0800) <-- IPv4 outer packet
Internet Protocol Version 4, Src: 172.16.254.3, Dst: 239.1.1.1
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 150
Identification: 0x4e4b (20043)
Flags: 0x4000, Don't fragment
0... .... .... .... = Reserved bit: Not set
.1.. .... .... .... = Don't fragment: Set <-- DF flag=1. MTU can be an issue if too low in path
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 253
Protocol: UDP (17)
Header checksum: 0x94f4 [validation disabled]
[Header checksum status: Unverified]
Source: 172.16.254.3
Destination: 239.1.1.1
User Datagram Protocol, Src Port: 65418, Dst Port: 4789 <-- VxLAN UDP port 4789
Source Port: 65418
Destination Port: 4789
<...snip...>
Virtual eXtensible Local Area Network
Flags: 0x0800, VXLAN Network ID (VNI)
0... .... .... .... = GBP Extension: Not defined
.... .... .0.. .... = Don't Learn: False
.... 1... .... .... = VXLAN Network ID (VNI): True
.... .... .... 0... = Policy Applied: False
.000 .000 0.00 .000 = Reserved(R): 0x0000
Group Policy ID: 0
VXLAN Network Identifier (VNI): 50901 <-- L3VNID 50901
Reserved: 0
Ethernet II, Src: 10:b3:d5:6a:00:00 (10:b3:d5:6a:00:00), Dst: 33:33:00:00:00:01 (33:33:00:00:00:01) <-- DMAC matches ff06:1::1
Type: IPv6 (0x86dd) <-- IPv6 inner packet
Internet Protocol Version 6, Src: fc00:1:101::11, Dst: ff06:1::1 <-- Encapsulated IPv6 TRM group
0110 .... = Version: 6
<...snip...>
Source: fc00:1:101::11
Destination: ff06:1::1
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
<...snip...>
Scénario 2 : PIM SSM dans le fabric
Dans ce mode, il n'y a pas de RP dans la superposition et aucun MVPN de type 5 ou 7 n'est utilisé (le Underlay continue à fonctionner comme PIM ASM). Dans SSM, le récepteur envoie et IGMPv3 S, G se joint vers le VTEP LHR. Ce VTEP effectue une recherche RPF pour la source dans le RIB. Si l'interface SVI L3VNI est trouvée comme interface RPF, le VTEP LHR envoie le RT-7 MVPN au VTEP FHR qui reçoit et installe cette route. FHR VTEP informe ensuite PIM d'ajouter L3VNI SVI en tant qu'interface sortante pour S, G mroute.
Cette section présente les différences par rapport au scénario 1. Les étapes et les méthodes identiques sont indiquées uniquement dans le scénario 1.
- Reportez-vous aux étapes de vérification et de débogage pour BGP et PIM dans le scénario 1, car les opérations BGP et PIM sont identiques
Diagramme du réseau
Pour ce mode, considérez ces types de route BGP et leurs origines
Créé par : Source VTEP
- Route EVPN de type 2. Utilisé pour obtenir des informations de monodiffusion et VRI pour la source, et ajouté à la route C-Multicast (MVPN type-7) lorsque le VTEP rejoint l'arborescence STP.
Créé par : Receiver VTEP
- Route MVPN de type 7. Les informations de la couche IGMP ou MLD et de l'EVPN Type-2 sont utilisées pour créer cette jointure de type BGP. Le Type-7 entraîne la création de l'OIF MRIB côté source.
Exigences EVPN de type 2 :
- FHR (source VTEP) vérifie la contiguïté ARP (ou ND) et CEF (confirme que la source est connectée directement).
- FHR est à l'origine de la mise à jour BGP EVPN Type-2
Configuration requise pour MVPN Type-7 :
- Une entrée EVPN de type 2 est présente (requise pour construire la route C-Multicast de type 7 avec VRI correct et envoyée depuis la source VTEP)
- Receiver VTEP : le rapport d'adhésion spécifique à la source IGMPv3 a été reçu et traité par le VTEP LHR
- L'interface LHR VTEP RPF est l'interface L3VNI du fabric
Pour ce mode, une configuration supplémentaire est requise sur le VTEP LHR pour activer la plage SSM et traiter les rapports d'appartenance IGMPv3
Configuration de Leaf-03 : définissez le demandeur IGMP sur la version 3 sous l'interface SVI du locataire
interface Vlan102
vrf forwarding green
ip address 10.1.102.1 255.255.255.0
ip pim sparse-mode
ip igmp version 3 <-- Sets the version to V3
end
Verify Leaf-03 : le demandeur IGMP est défini sur la version 3
Leaf-03#sh ip igmp snooping querier vlan 102
IP address : 10.1.102.1 <-- IP is that of the Vlan102 SVI
IGMP version : v3 <-- Querier is now version 3
Port : Router <-- Mrouter port is "Router" meaning querier is local to this VTEP
Max response time : 10s
Query interval : 60s
Robustness variable : 2
Enable Leaf-03 : la plage SSM requise pour le VRF du locataire
Leaf-03(config)#ip pim vrf green ssm ?
default Use 232/8 group range for SSM <-- Set to the normally defined SSM range
range ACL for group range to be used for SSM <-- use an ACL to define a non-default SSM range
Vérifier la séquence d'événements requise pour ce scénario
Étape 0 EVPN (Leaf-03) : vérifiez qu'il y a un préfixe EVPN que BGP peut trouver le VRI à utiliser dans le MVPN de type 7.
Leaf-03#sh bgp l2vpn evpn all
BGP table version is 16, local router ID is 172.16.255.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green)
* i [2][172.16.254.3:101][0][48][F4CFE24334C1][32][10.1.101.11]/24
172.16.254.3 0 100 0 ?
*>i 172.16.254.3 0 100 0 ? <-- From Leaf-01
Leaf-03#sh bgp l2vpn evpn all route-type 2 0 F4CFE24334C1 10.1.101.11 <-- Detailed view of the EVPN type-2 entry
BGP routing table entry for [2][172.16.254.3:101][0][48][F4CFE24334C1][32][10.1.101.11]/24, version 283
Paths: (2 available, best #2, table EVPN-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
172.16.254.3 (metric 3) (via default) from 172.16.255.1 (172.16.255.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
Extended Community: RT:1:1 MVPN AS:65001:0.0.0.0
MVPN VRF:172.16.255.3:4 ENCAP:8 Router MAC:10B3.D56A.8FC8 <-- BGP finds the VRI in this entry
Originator: 172.16.255.3, Cluster list: 172.16.255.1
rx pathid: 0, tx pathid: 0x0
Updated on May 6 2021 16:17:06 UTC
Étape 1 (Leaf-03) : réception d'un rapport d'adhésion IGMPv3 contenant une source
Leaf-03#show ip igmp snooping groups vlan 102 226.1.1.1
Vlan Group Type Version Port List
-----------------------------------------------------------------------
102 226.1.1.1 igmp v3 Gi1/0/10
Leaf-03#show ip igmp snooping groups vlan 102 226.1.1.1 sources <-- Specify "sources" to see Source information
Vlan Group Type Version Port List
-----------------------------------------------------------------------
Source information for group 226.1.1.1:
Timers: Expired sources are deleted on next IGMP General Query
SourceIP Expires Uptime Inc Hosts Exc Hosts
-------------------------------------------------------
10.1.101.11 00:01:20 00:02:58 1 0 <-- Source specified in IGMP includes one source
Étape 2 (Leaf-03) : BGP est informé de cette jointure, crée et envoie la jointure MVPN de type 7.
debug mvpn
debug ip igmp vrf green 226.1.1.1
May 6 17:11:08.500: IGMP(6): Received v3 Report for 1 group on Vlan102 from 10.1.102.12
May 6 17:11:08.500: IGMP(6): Received Group record for group 226.1.1.1, mode 5 from 10.1.102.12 for 1 sources <-- IGMPv3 type join
May 6 17:11:08.500: IGMP(6): WAVL Insert group: 226.1.1.1 interface: Vlan102 Successful
May 6 17:11:08.500: IGMP(6): Create source 10.1.101.11
May 6 17:11:08.500: IGMP(6): Updating expiration time on (10.1.101.11,226.1.1.1) to 180 secs
May 6 17:11:08.500: IGMP(6): Setting source flags 4 on (10.1.101.11,226.1.1.1)
May 6 17:11:08.500: IGMP(6): MRT Add/Update Vlan102 for (10.1.101.11,226.1.1.1) by 0
May 6 17:11:08.501: MVPN: Received local route update for (10.1.101.11, 226.1.1.1) with RD: 1:1, Route Type: 7, flags: 0x00 <-- MVPN process gets updated
May 6 17:11:08.501: MVPN: Route Type 7 added [(10.1.101.11, 226.1.1.1)] rd:1:1 send:1
May 6 17:11:08.501: MVPN: Sending BGP prefix=[7:0 1:1 : (10.1.101.11,226.1.1.1)] len=23, nh 172.16.254.3, Originate route
May 6 17:11:08.501: MVPN: Originate C-route, BGP remote RD 1:1 <-- MVPN Sends the type-7 join to Source leaf
Leaf-03#sh bgp ipv4 mvpn all
BGP table version is 10, local router ID is 172.16.255.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green)
*> [7][1:1][65001][10.1.101.11/32][226.1.1.1/32]/22 <-- Locally created Type-7
0.0.0.0 32768 ?
Leaf-03#sh ip mroute vrf green 226.1.1.1 <-- for SSM you only see S,G and no *,G
IP Multicast Routing Table
<...snip...>
(10.1.101.11, 226.1.1.1), 00:29:12/00:02:46, flags: sTIg <-- s = SSM, I = Source Specific Join received, g = Sent BGP C-Mroute
Incoming interface: Vlan901, RPF nbr 172.16.254.3 <-- RPF interface is the L3VNI
Outgoing interface list:
Vlan102, Forward/Sparse, 00:29:12/00:02:46
Étape 3 (Leaf-01) : le Leaf source reçoit et installe la route de jonction MVPN de type 7 et informe le PIM de l'installation de L3VNI OIF
debug mvpn
debug ip pim vrf green 226.1.1.1
May 6 18:16:07.260: MVPN: Received BGP prefix=[7:65001 1:1 : (10.1.101.11,226.1.1.1)] len=23, nexthop: 172.16.255.6, router-id: 172.16.255.1, Accept route <-- Receive and accept type-7
May 6 18:16:07.260: MVPN: Received BGP route update for (10.1.101.11, 226.1.1.1) with RD: 1:1, Route Type: 7, flags: 0x01
May 6 18:16:07.260: MVPN: Route Type 7 added [(10.1.101.11, 226.1.1.1), nh 172.16.255.6] rd:1:1 send:0, to us <-- add type-7 route
May 6 18:16:07.260: PIM(4)[green]: Join-list: (10.1.101.11/32, 226.1.1.1), S-bit set, BGP C-Route
May 6 18:16:07.263: PIM(4)[green]: Add Vlan901/0.0.0.0 to (10.1.101.11, 226.1.1.1), Forward state, by BGP SG Join <-- PIM adds Vlan901 L3VNI ad OIF based on BGP join
May 6 18:16:07.264: PIM(4)[green]: Insert (10.1.101.11,226.1.1.1) join in nbr 10.1.101.11's queue
May 6 18:16:07.264: MVPN(green[AF_IPv4]): Add (10.1.101.11, 226.1.1.1) intf Vlan901 olist Join state for BGP C-Rt type 7 Accept <-- MVPN add Vlan901 OIF from type-7
Leaf-01#sh bgp ipv4 mvpn all
<...snip...>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green)
*>i [7][1:1][65001][10.1.101.11/32][226.1.1.1/32]/22
172.16.255.6 0 100 0 ? <-- Recieved from Reciever Leaf-03
* i 172.16.255.6 0 100 0 ?
Leaf-01#sh ip mroute vrf green 226.1.1.1
<...snip...>
(10.1.101.11, 226.1.1.1), 00:42:41/stopped, flags: sTGx <-- s = SSM Group, G = Received BGP C-Mroute
Incoming interface: Vlan101, RPF nbr 10.1.101.11
Outgoing interface list:
Vlan901, Forward/Sparse, 00:42:41/stopped <-- L3VNI installed as OIF interface
Étapes 4 et 5 (Leaf-01 et Leaf-03) : la multidiffusion arrive à la feuille FHR et est envoyée sur le tissu à la feuille LHR. Résumé des commandes de validation fournies ici. Vous pouvez vérifier la validation détaillée de ces commandes dans le scénario 1.
show ip mroute vrf green 226.1.1.1 count <-- software mroute counters
show ip mfib vrf green 226.1.1.1 <verbose> <-- hardware mroute details & counters
sh platform software fed switch active ip mfib vrf green 226.1.1.1/32 10.1.101.11 detail <-- ASIC entry details and counters
Scénario 3 : RP unique à l'intérieur du fabric (mode intermédiaire standard)
Ce mode est interchangeable en tant que mode RP non anycast ou mode RP externe. Dans ce mode, il n'y a qu'un RP dans la superposition. Ainsi, (*, G) l'arborescence dans la superposition peut s'étendre sur plusieurs sites. BGP utilise un RT-6 MVPN pour annoncer (*, G) l'appartenance à l'ensemble du fabric. Si RP et FHR se trouvent sur des sites différents, les registres PIM sont envoyés à travers le fabric. Il s'agit du mode de fonctionnement par défaut pour PIM SM dans la superposition.
Diagramme du réseau
Pour ce mode, considérez ces types de route BGP et leurs origines
Créé par : Source VTEP
- Route EVPN de type 2. Utilisé pour obtenir des informations de monodiffusion et VRI pour la source, et ajouté à la route C-Multicast (MVPN type-7) lorsque le VTEP rejoint l'arborescence STP.
- Route MVPN de type 5. Route A-D source envoyée aux VTEP pour S, G
Créé par : RP VTEP
- Route EVPN de type 5. Utilisé pour obtenir des informations de monodiffusion et VRI pour le bouclage RP. Le bouclage ne crée pas le type de route 2, donc le type 5 est utilisé.
- Route MVPN de type 7. Il s'agit des détails IGMP join + RT VRI extraits de l'EVPN Type-2 et envoyés au VTEP source, et il pilote la création de l'OIF MRIB.
Créé par : Receiver VTEP
- Route MVPN de type 6. Type de route créé par le récepteur VTEP pour joindre l'arborescence partagée *, G (arborescence RPT) vers le RP.
- Route MVPN de type 7. Les informations de la couche IGMP ou MLD et de l'EVPN Type-2 sont utilisées pour créer cette jointure de type BGP. Le Type-7 entraîne la création de l'OIF MRIB côté source.
Exigences EVPN de type 2 :
- FHR (source VTEP) vérifie la contiguïté ARP (ou ND) et CEF (confirme que la source est connectée directement).
- FHR est à l'origine de la mise à jour BGP EVPN Type-2
Exigences EVPN de type 5 :
- Le bouclage RP est configuré et annoncé dans BGP
Configuration requise pour MVPN Type-5 :
Dans ce mode, Leaf sur le site source annonce les messages A-D source actifs pour un (S, G) uniquement si ces deux conditions sont remplies.
- Il reçoit le trafic sur l'interface RPF vers la source. (la source envoie mcast au FHR)
- L'interface SVI L3VNI est ajoutée en tant qu'interface de transfert pour l'entrée (S, G), suite à une jointure S, G du RP dans le cadre du processus d'enregistrement PIM. (L'interface SVI L3VNI est installée dans la liste OIF)
Configuration requise pour MVPN Type-6 :
- RP a annoncé sa route EVPN de type 5 qui contient ses détails d'accessibilité VRI et Unicast.
- Jointure IGMP reçue sur LHR qui déclenche une mise à jour BGP vers RP
Configuration requise pour MVPN Type-7 :
- Une entrée EVPN de type 2 est présente (requise pour construire la route C-Multicast de type 7 avec VRI correct et envoyée depuis la source VTEP)
- L'entrée MVPN de type 5 est présente (requise pour résoudre la paire source/groupe disponible pour la jonction STP)
- Receiver VTEP : le rapport d'adhésion IGMP a été reçu et traité par le VTEP LHR
- RP VTEP : RP a reçu des paquets de registre de multidiffusion, a des routes EVPN et a un récepteur pour S, G (appris via le type-6)
- L'interface LHR VTEP RPF est l'interface L3VNI du fabric
Vérifier la séquence d'événements requise pour ce scénario
Validez les étapes nécessaires pour que le VTEP du récepteur rejoigne initialement l'arborescence partagée, puis passe à l'arborescence du plus court chemin. Cela implique des vérifications des états de création des tables BGP, IGMP et MRIB.
Étape EVPN (Leaf-03) : EVPN Type-5 du RP est appris sur LHR. Ceci est requis pour que le VTEP récepteur puisse créer une route MVPN de type 6
Leaf-03#sh bgp l2vpn evpn all route-type 5 0 10.2.255.255 32
...or you can also use:
Leaf-03#sh bgp l2vpn evpn detail [5][1:1][0][32][10.2.255.255]/17
BGP routing table entry for [5][1:1][0][32][10.2.255.255]/17, version 25
Paths: (2 available, best #1, table EVPN-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
Local
172.16.254.4 (metric 3) (via default) from 172.16.255.1 (172.16.255.1) <-- RP's global next hop IP
Origin incomplete, metric 0, localpref 100, valid, internal, best
EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
Extended Community: RT:1:1 MVPN AS:65001:0.0.0.0
MVPN VRF:172.16.255.4:2 ENCAP:8 Router MAC:7C21.0DBD.9548
Originator: 172.16.255.4, Cluster list: 172.16.255.1
rx pathid: 0, tx pathid: 0x0
Updated on Jan 13 2021 19:09:31 UTC
Refresh Epoch 2
Local
MVPN VRF:172.16.255.4:2 <-- MVPN VRI
Router MAC:7C21.0DBD.9548 <-- Leaf-02 RMAC
Étape 1 (Leaf-03) : réception du rapport d'adhésion IGMP
Leaf-03#sh ip igmp snooping groups
Vlan Group Type Version Port List
-----------------------------------------------------------------------
102 224.0.1.40 igmp v2 Gi1/0/10
102 226.1.1.1 igmp v2 Gi1/0/10 <-- Client has joined
Étape 2 (Leaf-03) : MVPN de type 6 créé, envoyé au RP et reçu par le RP (Leaf-02)
#### Type-6 from the Receiver VTEP perspective ###
Leaf-03#sh bgp ipv4 mvpn all route-type 6 1:1 65001 10.2.255.255 226.1.1.1 <-- Source is RP Loopback
...or you can also use:
Leaf-03#sh bgp ipv4 mvpn detail [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22
BGP routing table entry for [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22, version 13
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (172.16.255.6) <-- Generated locally
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:172.16.255.4:2 <-- VRI Ext Comm added from EVPN Type-5
rx pathid: 2, tx pathid: 0x0
Updated on Jan 14 2021 14:51:29 UTC
#### Type-6 from the RP perspective ###
Leaf-02#sh bgp ipv4 mvpn all route-type 6 1:1 65001 10.2.255.255 226.1.1.1 <-- type-6, RD 1:1, AS 65001, Source/Group
...or you can also use:
Leaf-02#sh bgp ipv4 mvpn detail [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22
BGP routing table entry for [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22, version 25
Paths: (2 available, best #1, table MVPNv4-BGP-Table)
Flag: 0x100
Not advertised to any peer
Refresh Epoch 2
Local
172.16.255.6 (metric 3) from 172.16.255.1 (172.16.255.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:172.16.255.4:2 <-- Contains VRI learned from EVPN Type-5
Originator: 172.16.255.6, Cluster list: 172.16.255.1 <-- Sent from Leaf03 IP to RP
rx pathid: 0, tx pathid: 0x0
Updated on Jan 14 2021 14:54:29 UTC
Étapes 1 et 2 - Débogages (Leaf-01) : rapport IGMP, recherche de source EVPN et création de MVPN Type-6
debug ip igmp vrf green 226.1.1.1
debug bgp ipv4 mvpn updates
debug bgp ipv4 mvpn updates events
### Client sends IGMP membership report ###
### IGMP processes this IGMP report ###
*Feb 1 21:13:19.029: IGMP(2): Received v2 Report on Vlan102 from 10.1.102.12 for 226.1.1.1 <--- IGMP processes received report
*Feb 1 21:13:19.029: IGMP(2): Received Group record for group 226.1.1.1, mode 2 from 10.1.102.12 for 0 sources
*Feb 1 21:13:19.029: IGMP(2): WAVL Insert group: 226.1.1.1 interface: Vlan102 Successful
*Feb 1 21:13:19.029: IGMP(2): Switching to EXCLUDE mode for 226.1.1.1 on Vlan102
*Feb 1 21:13:19.029: IGMP(2): Updating EXCLUDE group timer for 226.1.1.1
*Feb 1 21:13:19.029: IGMP(2): MRT Add/Update Vlan102 for (*,226.1.1.1) by 0 <--- Notify MRT to add Vlan 102 into Outgoing interface list
### BGP is informed by IGMP, does an EVPN source lookup, creates the MVPN Type-6 route, sends to RR ###
(Without the EVPN Type-5 prefix already in BGP you see IGMP debugs trigger, but no subsequent BGP debugs as seen here)
*Feb 1 21:13:19.033: BGP[15] MVPN: add c-route, type 6, bs len 0 asn=0, rd=1:1, <-- Start creation of Type-6 C-multicast Shared Tree Join
*Feb 1 21:13:19.033: source=10.2.255.255/4, <-- RP loopback255
*Feb 1 21:13:19.033: group=226.1.1.1/4, <-- Group IP
*Feb 1 21:13:19.033: nexthop=172.16.254.4, <-- Global Next-Hop learned from EVPN VRI
*Feb 1 21:13:19.033: len left = 0
*Feb 1 21:13:19.033: BGP[14] MVPN umh lookup: vrfid 2, source 10.2.255.255 <-- UMH (upstream multicast hop) as found in the RT of the EVPN type-5
*Feb 1 21:13:19.033: BGP[4] MVPN umh lookup: vrfid 2, source 10.2.255.255, net 1:1:10.2.255.255/32, 1:1:10.2.255.255/32 with matching nexthop 172.16.254.4, remote-rd [1:1]: 0x9:65001:0.0.0.0, 0x10B:172.16.255.4:2, <-- EVPN info adding to MVPN
*Feb 1 21:13:19.033: BGP: MVPN(15) create local route [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22 <--- MVPN creating type-6
*Feb 1 21:13:19.033: BGP[15] MVPN: add c-route, type 6, bs len 0 asn=65001, rd=1:1,
*Feb 1 21:13:19.033: source=10.2.255.255/4,
*Feb 1 21:13:19.033: group=226.1.1.1/4,
*Feb 1 21:13:19.033: nexthop=172.16.254.4,
*Feb 1 21:13:19.033: len left = 0
*Feb 1 21:13:19.033: BGP[14] MVPN umh lookup: vrfid 2, source 10.2.255.255
*Feb 1 21:13:19.033: BGP[4] MVPN umh lookup: vrfid 2, source 10.2.255.255, net 1:1:10.2.255.255/32, 1:1:10.2.255.255/32 with matching nexthop 172.16.254.4, remote-rd [1:1]: 0x9:65001:0.0.0.0, 0x10B:172.16.255.4:2,
*Feb 1 21:13:19.034: BGP(15): skip vrf default table RIB route [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22
*Feb 1 21:13:19.034: BGP(15): 172.16.255.1 NEXT_HOP self is set for sourced RT Filter for net [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22
*Feb 1 21:13:19.034: BGP(15): (base) 172.16.255.1 send UPDATE (format) [6][1:1][65001][10.2.255.255/32][226.1.1.1/32]/22, next 172.16.255.6, metric 0, path Local, extended community RT:172.16.255.4:2 <-- Advertise to RR (172.16.255.1)
Étapes 3 et 4 (Leaf-01) : du point de vue de la FHR, validez les événements S, G create & Register (S, G create & Register se produisent presque en même temps)
3. Le trafic de données démarre et S, G est créé au niveau du VTEP FHR. Les exigences indiquées dans la section « Sources multidiffusion non détectées » s'appliquent ici.
4. Leaf-01 effectue l'enregistrement de la source au RP via son tunnel PIM
Leaf-01#debug ip pim vrf green 226.1.1.1
PIM debugging is on
Leaf-01#debug ip mrouting vrf green 226.1.1.1
IP multicast routing debugging is on
### Debugs for PIM and Mroute show creation of S,G and PIM register encap event ###
*Jan 29 18:18:37.602: PIM(2): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 226.1.1.1
*Jan 29 18:18:58.426: MRT(2): (10.1.101.11,226.1.1.1), RPF install from /0.0.0.0 to Vlan101/10.1.101.11<-- S,G is creation message (MRT process)
*Jan 29 18:18:58.427: PIM(2): Adding register encap tunnel (Tunnel4) as forwarding interface of (10.1.101.11, 226.1.1.1). <-- Sending via register (PIM process)
*Jan 29 18:18:58.427: MRT(2): Set the F-flag for (*, 226.1.1.1)
*Jan 29 18:18:58.427: MRT(2): Set the F-flag for (10.1.101.11, 226.1.1.1)
*Jan 29 18:18:58.428: MRT(2): Create (10.1.101.11,226.1.1.1), RPF (Vlan101, 10.1.101.11, 0/0) <-- S,G is creation message (MRT process)
*Jan 29 18:18:58.428: MRT(2): Set the T-flag for (10.1.101.11, 226.1.1.1)
### Tunnel 4 is PIM Register tunnel (Encap: encapsulate in tunnel to RP) ####
Leaf-01#sh int tunnel4
Tunnel4 is up, line protocol is up
Hardware is Tunnel
Description: Pim Register Tunnel (Encap) for RP 10.2.255.255 on VRF green <-- VRF green for Leaf-02 RP
Interface is unnumbered. Using address of Loopback901 (10.1.255.1) <-- Local Loopback
### S,G is created when Source sends data traffic ###
Leaf-01#sh ip mroute vrf green 226.1.1.1
IP Multicast Routing Table
<...snip...>
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 226.1.1.1), 00:00:16/stopped, RP 10.2.255.255, flags: SPF
Incoming interface: Vlan901, RPF nbr 172.16.254.4
Outgoing interface list: Null
(10.1.101.11, 226.1.1.1), 00:00:16/00:02:47, flags: FTGqx
Incoming interface: Vlan101, RPF nbr 10.1.101.11, Registering <-- S,G created, in Register state, RPF IP is the /32 host prefix for this source
Outgoing interface list:
Vlan901, Forward/Sparse, 00:00:16/00:02:43 <-- OIF is the L3VNI SVI
#### Checking S,G in Hardware ###
Leaf-01#sh platform software fed switch active ip mfib vrf green 226.1.1.1/32 10.1.101.11 de
MROUTE ENTRY vrf 2 (10.1.101.11, 226.1.1.1/32) <-- VRF 2 is the ID for vrf green
HW Handle: 140213987784872 Flags: {Svl}
RPF interface: Vlan101(59)): SVI <-- RPF is Direct connected on a Local Subnet
HW Handle:140213987784872 Flags:A
Number of OIF: 2
Flags: 0x4 Pkts : 336 <-- packets that used this adjacency (similar to mfib command, but shown at the FED layer)
OIF Details:
Vlan101 A <-- Accept interface is programmed correctly
Vlan901 F {Remote} <-- Forward interface is L3VNI SVI
(Adj: 0x5f ) <-- Validate this Adj
Htm: 0x7f861cf071b8 Si: 0x7f861cf04838 Di: 0x7f861cf097a8 Rep_ri: 0x7f861ceecb38
### Check ADJ 0x5f for next hop details ###
Leaf-01#sh platform software fed switch active ip adj
IPV4 Adj entries
dest if_name dst_mac si_hdl ri_hdl pd_flags adj_id Last-modified
---- ------- ------- ------ ------ -------- ----- ------------------------
239.1.1.1 nve1.VNI50901 4500.0000.0000 0x7f861ce659b8 0x7f861ce65b68 0x60 0x5f 2021/01/29 17:07:06.568
Dest = MDT default group 239.1.1.1
Outgoing Interface = Nve1 using L3 VNI 50901
Étape 4 (Leaf-02) : du point de vue du RP, vérifiez que l'enregistrement de la source atteint le RP et que S, G est créé.
### PIM debugs showing PIM register event ###
Leaf-02#debug ip pim vrf green 226.1.1.1
PIM debugging is on
*Jan 29 18:21:35.500: PIM(2): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 226.1.1.1
*Jan 29 18:21:35.500: PIM: rp our address <-- Leaf-02 is the RP
*Jan 29 18:21:41.005: PIM(2): Received v2 Register on Vlan901 from 10.1.255.1 <--- IP of Lo901 on Leaf-01 sent register
*Jan 29 18:21:41.005: for 10.1.101.11, group 226.1.1.1
*Jan 29 18:21:41.006: PIM(2): Adding register decap tunnel (Tunnel4) as accepting interface of (10.1.101.11, 226.1.1.1).
*Jan 29 18:21:41.008: PIM(2): Upstream mode for (10.1.101.11, 226.1.1.1) changed from 1 to 2
### Tunnel 4 is PIM Register tunnel (decap) ####
Leaf-02#sh int tunnel 4
Tunnel4 is up, line protocol is up
Hardware is Tunnel
Description: Pim Register Tunnel (Decap) for RP 10.2.255.255 on VRF green <-- decap side of register tunnel
Interface is unnumbered. Using address of Loopback255 (10.2.255.255) <-- RP IP
### Mroute debugs show pim Register triggering S,G ###
Leaf-02#debug ip mrouting vrf green 226.1.1.1
IP multicast routing debugging is on
*Jan 29 20:44:31.483: MRT(2): (10.1.101.11,226.1.1.1), RPF install from /0.0.0.0 to Vlan901/172.16.254.3 <-- RPF is to Leaf-01
*Jan 29 20:44:31.485: MRT(2): Create (10.1.101.11,226.1.1.1), RPF (Vlan901, 172.16.254.3, 200/0) <-- Create the S,G
*Jan 29 20:44:33.458: MRT(2): Set the T-flag for (10.1.101.11, 226.1.1.1) <-- Set SPT bit for S,G
### S,G is created and traffic is now sent along the *,G shared tree ###
Leaf-02#sh ip mroute vrf green
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 226.1.1.1), 00:05:49/stopped, RP 10.2.255.255, flags: SGx <-- Sparse, Received BGP C-Mroute
Incoming interface: Null, RPF nbr 0.0.0.0 <-- RP is us (Incoming Interface Null with 0.0.0.0 RPF)
Outgoing interface list:
Vlan901, Forward/Sparse, 00:05:49/stopped
(10.1.101.11, 226.1.1.1), 00:01:22/00:01:41, flags: PTXgx <-- Pruned, SPT bit, Sent BGP C-Mroute
Incoming interface: Vlan901, RPF nbr 172.16.254.3 <-- Leaf-01 is RPF next hop
Outgoing interface list: Null
Étape 5 (Leaf-02) : RP dispose d'un récepteur, de sorte que immédiatement créé Type-7 MVPN Source Tree Join route
Leaf-02#sh ip mroute vrf green 226.1.1.1
<...snip...>
(*, 226.1.1.1), 00:02:22/00:00:37, RP 10.2.255.255, flags: SGx
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan901, Forward/Sparse, 00:02:22/00:00:37 <-- L3 VNI is populated from Receiver BGP Type-6 join
#### Debugs showing Type-7 creation from RP ####
Leaf-02#debug bgp ipv4 mvpn updates
BGP updates debugging is on for address family: MVPNv4 Unicast
Leaf-02#debug bgp ipv4 mvpn updates events
BGP update events debugging is on for address family: MVPNv4 Unicast
*Jan 29 18:21:41.008: BGP[15] MVPN: add c-route, type 7, bs len 0 asn=0, rd=1:1,
*Jan 29 18:21:41.008: source=10.1.101.11/4,
*Jan 29 18:21:41.008: group=226.1.1.1/4,
*Jan 29 18:21:41.008: nexthop=172.16.254.3, <-- Leaf-01 Global next hop
*Jan 29 18:21:41.008: len left = 0
*Jan 29 18:21:41.008: BGP[14] MVPN umh lookup: vrfid 2, source 10.1.101.11
*Jan 29 18:21:41.008: BGP[4] MVPN umh lookup: vrfid 2, source 10.1.101.11, net 1:1:10.1.101.11/32, 1:1:10.1.101.11/32 with matching nexthop 172.16.254.3, remote-rd [172.16.]: 0x9:65001:0.0.0.0, 0x10B:172.16.255.3:2, <-- This is the VRI picked up from the EVPN Type-2
*Jan 29 18:21:41.009: BGP: MVPN(15) create local route [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22
*Jan 29 18:21:41.009: BGP[15] MVPN: add c-route, type 7, bs len 0 asn=65001, rd=1:1,
*Jan 29 18:21:41.009: source=10.1.101.11/4,
*Jan 29 18:21:41.009: group=226.1.1.1/4,
*Jan 29 18:21:41.009: nexthop=172.16.254.3,
*Jan 29 18:21:41.009: len left = 0
*Jan 29 18:21:41.009: BGP[14] MVPN umh lookup: vrfid 2, source 10.1.101.11
*Jan 29 18:21:41.009: BGP[4] MVPN umh lookup: vrfid 2, source 10.1.101.11, net 1:1:10.1.101.11/32, 1:1:10.1.101.11/32 with matching nexthop 172.16.254.3, remote-rd [172.16.]: 0x9:65001:0.0.0.0, 0x10B:172.16.255.3:2,
### Type-7 Locally created on RP and sent to Source Leaf-01 ###
Leaf-02#sh bgp ipv4 mvpn all
BGP table version is 81, local router ID is 172.16.255.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 172.16.254.3:101 <-- Note the VRI is learnt from Leaf-01
*> [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22 <-- [7] = type-7 for this S,G / VRI 172.16.254.3:101 learned from Leaf-01
0.0.0.0 32768 ? <-- 0.0.0.0 locally originated with local Weight
Étape 6 (Leaf-01) : le Leaf-01 source reçoit et installe la route MVPN de type 7. (L3 VNI SVI est installé en tant qu'interface de transfert pour S, G)
### Received Type-7 from Leaf-02 RP ###
Leaf-01#debug bgp ipv4 mvpn updates
BGP updates debugging is on for address family: MVPNv4 Unicast
Leaf-01#debug bgp ipv4 mvpn updates events
BGP update events debugging is on for address family: MVPNv4 Unicast
*Jan 29 18:18:58.457: BGP(15): 172.16.255.1 rcvd UPDATE w/ attr: nexthop 172.16.255.4, origin ?, localpref 100, metric 0, originator 172.16.255.4, clusterlist 172.16.255.1, extended community RT:172.16.255.3:2 <-- Type-7 from Route Reflector 172.16.255.1
*Jan 29 18:18:58.457: BGP(15): 172.16.255.1 rcvd [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22 <-- Received [7] Type-7 BGP join route
*Jan 29 18:18:58.457: BGP(15): skip vrf default table RIB route [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22
*Jan 29 18:18:58.458: BGP(15): add RIB route (0:0)[7][1:1][65001][10.1.101.11/32][226.1.1.1/32]/22
### PIM updated by MVPN to install L3 VNI in Outgoing Interface List ###
Leaf-01#debug ip pim vrf green 226.1.1.1
PIM debugging is on
Leaf-01#debug ip mrouting vrf green 226.1.1.1
IP multicast routing debugging is on
*Jan 29 18:18:58.458: PIM(2): Join-list: (10.1.101.11/32, 226.1.1.1), S-bit set, BGP C-Route
*Jan 29 18:18:58.459: MRT(2): WAVL Insert VxLAN interface: Vlan901 in (10.1.101.11,226.1.1.1) Next-hop: 239.1.1.1 VNI 50901 Successful <-- VxLAN info such as VNI, and outer Mcast group during Olist creation
*Jan 29 18:18:58.459: MRT(2): set min mtu for (10.1.101.11, 226.1.1.1) 18010->9198
*Jan 29 18:18:58.460: MRT(2): Add Vlan901/239.1.1.1/50901 to the olist of (10.1.101.11, 226.1.1.1), Forward state - MAC not built <-- OIF is added for the VNI SVI 901
*Jan 29 18:18:58.460: PIM(2): Add Vlan901/0.0.0.0 to (10.1.101.11, 226.1.1.1), Forward state, by BGP SG Join
*Jan 29 18:18:58.460: MRT(2): Add Vlan901/239.1.1.1/50901to the olist of (10.1.101.11, 226.1.1.1), Forward state - MAC not built
Étape 7 (Leaf-01) : Leaf-01 annonce la source MVPN A-D Type-5 pour S, G
Leaf-01#debug bgp ipv4 mvpn updates
BGP updates debugging is on for address family: MVPNv4 Unicast
Leaf-01#debug bgp ipv4 mvpn updates events
BGP update events debugging is on for address family: MVPNv4 Unicast
*Jan 29 18:18:58.461: BGP(15): nettable_walker [5][1:1][10.1.101.11][226.1.1.1]/18 route sourced locally <-- BGP determines route is local to Leaf-01
*Jan 29 18:18:58.461: BGP(15): delete RIB route (0:0)[5][1:1][10.1.101.11][226.1.1.1]/18
*Jan 29 18:18:58.461: BGP(15): 172.16.255.1 NEXT_HOP self is set for sourced RT Filter for net [5][1:1][10.1.101.11][226.1.1.1]/18
*Jan 29 18:18:58.461: BGP(15): (base) 172.16.255.1 send UPDATE (format) [5][1:1][10.1.101.11][226.1.1.1]/18, next 172.16.255.3, metric 0, path Local, extended community RT:1:1 <-- Send Type-5 update
Étape 8 (Leaf-03) : le récepteur VTEP obtient le type 5 et installe la route source A-D pour S, G
Leaf-03#debug bgp ipv4 mvpn updates
BGP updates debugging is on for address family: MVPNv4 Unicast
Leaf-03#debug bgp ipv4 mvpn updates events
BGP update events debugging is on for address family: MVPNv4 Unicast
*Jan 29 19:18:53.318: BGP(15): 172.16.255.1 rcvd UPDATE w/ attr: nexthop 172.16.255.3, origin ?, localpref 100, metric 0, originator 172.16.255.3, clusterlist 172.16.255.1, community no-export, extended community RT:1:1
*Jan 29 19:18:53.319: BGP(15): 172.16.255.1 rcvd [5][1:1][10.1.101.11][226.1.1.1]/18 <-- Type-5 Received from Source VTEP Leaf-01
*Jan 29 19:18:53.319: BGP(15): skip vrf default table RIB route [5][1:1][10.1.101.11][226.1.1.1]/18
Leaf-03#sh bgp ipv4 mvpn all route-type 5 10.1.101.11 226.1.1.1
...or you can also use:
Leaf-03#sh bgp ipv4 mvpn detail [5][1:1][10.1.101.11][226.1.1.1]/18
BGP routing table entry for [5][1:1][10.1.101.11][226.1.1.1]/18, version 41 <-- Type-5 A-D route from Leaf-01
Paths: (2 available, best #2, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Flag: 0x100
Not advertised to any peer
Refresh Epoch 1
Local
172.16.255.3 (metric 3) from 172.16.255.1 (172.16.255.1) <-- Leaf-01 IP
Origin incomplete, metric 0, localpref 100, valid, internal, best
Community: no-export
Extended Community: RT:1:1
Originator: 172.16.255.3, Cluster list: 172.16.255.1
rx pathid: 0, tx pathid: 0x0
Updated on Jan 29 2021 19:18:53 UTC
Étape 9 (Leaf-03) : S, G est créé, Leaf-03 envoie MVPN Type-7 pour rejoindre l'arborescence SPT et commence à accepter le trafic
debug ip mrouting vrf green 226.1.1.1
debug bgp ipv4 mvpn updates
debug bgp ipv4 mvpn updates events
### Debug of Mrouting shows S,G create and call to BGP to create Type-7 BGP S,G join ###
*Feb 12 19:34:26.045: MRT(2): (10.1.101.11,226.1.1.1), RPF install from /0.0.0.0 to Vlan901/172.16.254.3 <-- RPF check done as first operation. Selected L3VNI SVI and Leaf-01 next hop
*Feb 12 19:34:26.046: MRT(2): Create (10.1.101.11,226.1.1.1), RPF (Vlan901, 172.16.254.3, 200/0) <-- RPF successful Creating S,G
*Feb 12 19:34:26.047: MRT(2): WAVL Insert interface: Vlan102 in (10.1.101.11,226.1.1.1) Successful
*Feb 12 19:34:26.047: MRT(2): set min mtu for (10.1.101.11, 226.1.1.1) 18010->9198
*Feb 12 19:34:26.047: MRT(2): Set the T-flag for (10.1.101.11, 226.1.1.1)
*Feb 12 19:34:26.048: MRT(2): Add Vlan102/226.1.1.1 to the olist of (10.1.101.11, 226.1.1.1), Forward state - MAC not built <-- Adding Vlan102 Receiver SVI into OIF list
*Feb 12 19:34:26.048: MRT(2): Set BGP Src-Active for (10.1.101.11, 226.1.1.1) <-- Signaling to BGP that this Source is seen and join SPT path
### BGP Type-7 created ###
Leaf-03#sh bgp ipv4 mvpn all
Route Distinguisher: 172.16.254.3:101 <-- VRI Route Distinguisher
*> [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22 <-- Type [7], VRI, S,G info
0.0.0.0 32768 ? <-- created locally
Leaf-03#sh ip mroute vrf green 226.1.1.1 10.1.101.11
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.101.11, 226.1.1.1), 00:08:41/00:02:13, flags: TgQ <-- SPT bit, Sent MVPN type-7, Received MVPN type-5
Incoming interface: Vlan901, RPF nbr 172.16.254.3 <-- Receive from L3VNI via Leaf-01 IP next hop
Outgoing interface list:
Vlan102, Forward/Sparse, 00:08:41/00:02:22 <-- Send to host in Vlan 102
Étape 10 (Leaf-01) : Leaf-01 reçoit et installe le MVPN Type-7 de Leaf-03
debug bgp ipv4 mvpn updates
debug bgp ipv4 mvpn updates events
### Type-7 Received from Leaf-03 VTEP and installed into RIB ###
*Feb 12 19:55:29.000: BGP(15): 172.16.255.1 rcvd [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22 <-- Type-7 from Leaf-03
*Feb 12 19:55:29.000: BGP(15): skip vrf default table RIB route [7][172.16.254.3:101][65001][10.1.101.11/32][226.1.1.1/32]/22
*Feb 12 19:55:29.000: BGP(15): add RIB route (0:0)[7][1:1][65001][10.1.101.11/32][226.1.1.1/32]/22
Scénario 4 : RP externe au fabric (RP importé de Border Leaf-02 depuis l'espace IP)
Ce scénario est fondamentalement le même que le scénario 3. Un RP unique est utilisé par le fabric dans son ensemble. La différence est que l'adresse IP RP doit être importée d'un espace IP non-fabric dans le fabric et annoncée dans BGP.
Cette section présente les différences par rapport au scénario 3. Les étapes et les méthodes identiques sont indiquées uniquement dans le scénario 3
- Voir Vérifier la séquence d'événements requise pour ce scénario à partir du scénario 3 car les opérations BGP et PIM sont les mêmes
Diagramme du réseau
Vérifier les importations de commutateurs de périphérie d'IP vers le fabric
La principale différence avec cette conception par rapport au scénario 3 est la nécessité d'importer d'abord l'IP RP de l'espace IP vers EVPN.
La bordure doit contenir certaines commandes pour importer/exporter vers et depuis les espaces de fabric et IP :
- route-target <value> commandes de piquage sous la section de configuration VRF
- annoncez l2vpn evpn sous la famille d'adresses VRF BGP
Vérification (Leaf-02) : configuration
Leaf-02#sh run vrf green
Building configuration...
Current configuration : 1533 bytes
vrf definition green
rd 1:1
!
address-family ipv4
mdt auto-discovery vxlan
mdt default vxlan 239.1.1.1
mdt overlay use-bgp
route-target export 1:1
route-target import 1:1
route-target export 1:1 stitching <-- BGP-EVPN fabric redistributes the stitching routes between the EVPN and the IP BGP
route-target import 1:1 stitching
exit-address-family
Leaf-02#sh run | sec router bgp
address-family ipv4 vrf green <--- BGP VRF green address-family
advertise l2vpn evpn <--- Use the 'advertise l2vpn evpn' command and 'export stitching' RTs to push the native routes towards the EVPN
redistribute connected
redistribute static
redistribute ospf 2 match internal external 1 external 2 <-- Learning via external OSPF neighbor in VRF
exit-address-family
Vérifier (Leaf-02) : Importation et annonce de préfixes
debug bgp vpnv4 unicast updates
debug bgp vpnv4 unicast updates events
debug bgp l2vpn evpn updates
debug bgp l2vpn evpn updates events
*Feb 15 15:30:54.407: BGP(4): redist event (1) request for 1:1:10.2.255.255/32 <-- VPNv4 Redistribute statement present in BGP address family
*Feb 15 15:30:54.407: BGP(4) route 1:1:10.2.255.255/32 gw-1 10.2.1.2 src_proto (ospf) path-limit 1
*Feb 15 15:30:54.407: BGP(4): route 1:1:10.2.255.255/32 up
*Feb 15 15:30:54.407: bgp_ipv4set_origin: redist 1, opaque 0x0, net 10.2.255.255
*Feb 15 15:30:54.407: BGP(4): sourced route for 1:1:10.2.255.255/32 path 0x7FF8065EB9C0 id 0 gw 10.2.1.2 created (weight 32768)
*Feb 15 15:30:54.408: BGP(4): redistributed route 1:1:10.2.255.255/32 added gw 10.2.1.2
*Feb 15 15:30:54.408: BGP: topo green:VPNv4 Unicast:base Remove_fwdroute for 1:1:10.2.255.255/32
*Feb 15 15:30:54.408: BGP(4): 1:1:10.2.255.255/32 import vpn re-orig or locally sourced or learnt from CE <-- Prefix learned from external CE
*Feb 15 15:30:54.409: BGP(10): update modified for [5][1:1][0][32][10.2.255.255]/17 <--- EVPN picked up and Type-5 creation
*Feb 15 15:30:54.409: BGP(10): 172.16.255.1 NEXT_HOP set to vxlan local vtep-ip 172.16.254.4 for net [5][1:1][0][32][10.2.255.255]/17 <-- Set NH to Leaf-02 loopback
*Feb 15 15:30:54.409: BGP(10): update modified for [5][1:1][0][32][10.2.255.255]/17
*Feb 15 15:30:54.409: BGP(10): (base) 172.16.255.1 send UPDATE (format) [5][1:1][0][32][10.2.255.255]/17, next 172.16.254.4, metric 2, path Local, extended community RT:1:1 OSPF DOMAIN ID:0x0005:0x000000020200 MVPN AS:65001:0.0.0.0 MVPN VRF:172.16.255.4:2 ENCAP:8 Router MAC:7C21.0DBD.9548 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.255.255:0
<-- BGP EVPN Type update created from Non-fabric Imported prefix and sent to RR
### Verify the NLRI is learned and Imported on Border Leaf-02 ###
Leaf-02#sh bgp vpnv4 unicast all
BGP table version is 39, local router ID is 172.16.255.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green)
AF-Private Import to Address-Family: L2VPN E-VPN, Pfx Count/Limit: 3/1000 <-- Prefix Import details. (Note default import limit of 1000)
*> 10.2.255.255/32 10.2.1.2 2 32768 ? <-- Locally redistributed, Next hop on CE device
Leaf-02#sh bgp l2vpn evpn all route-type 5 0 10.2.255.255 32
...or you can also use:
Leaf-02#sh bgp l2vpn evpn detail [5][1:1][0][32][10.2.255.255]/17
BGP routing table entry for [5][1:1][0][32][10.2.255.255]/17, version 69
Paths: (1 available, best #1, table EVPN-BGP-Table)
Advertised to update-groups:
2
Refresh Epoch 1
Local, imported path from base
10.2.1.2 (via vrf green) from 0.0.0.0 (172.16.255.4) <-- Imported to EVPN Fabric table from IP
Origin incomplete, metric 2, localpref 100, weight 32768, valid, external, best
EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, local vtep: 172.16.254.4, VNI Label 50901, MPLS VPN Label 17 <-- VTEP IP of Leaf-02, L3VNI label
Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000020200
MVPN AS:65001:0.0.0.0 MVPN VRF:172.16.255.4:2 ENCAP:8 <-- MVPN VRI created
Router MAC:7C21.0DBD.9548 OSPF RT:0.0.0.0:2:0
OSPF ROUTER ID:10.2.255.255:0
rx pathid: 0, tx pathid: 0x0
Updated on Feb 15 2021 15:30:54 UTC
Verify (Leaf-02) : chemin de périphérie vers RP
Leaf-02#sh ip mroute vrf green
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 226.1.1.1), 2d21h/stopped, RP 10.2.255.255, flags: SJGx <-- *,G for group and Non-fabric RP IP
Incoming interface: Vlan2001, RPF nbr 10.2.1.2 <-- RPF neighbor is populated for IP next hop outside VxLAN
Outgoing interface list:
Vlan901, Forward/Sparse, 01:28:47/stopped <-- Outgoing is L3VNI SVI
Scénario 5 : MDT de données
Vérification du groupe de données MDT
Le groupe MDT Data est similaire à son groupe MDT Default dans lequel le groupe de tunnel externe pour TRM doit être encapsulé. Cependant, contrairement à la valeur par défaut MDT, ce groupe n'aura de VTEP pour rejoindre cet arbre que s'ils ont des récepteurs intéressés pour le groupe TRM.
Configuration requise
vrf definition green
rd 1:1
!
address-family ipv4
mdt auto-discovery vxlan
mdt default vxlan 239.1.1.1
mdt data vxlan 239.1.2.0 0.0.0.255 <-- Defines MDT Data underlay group address range
mdt data threshold 1 <-- Defines the threshold before cutting over to the Data group (In Kilobits per second)
mdt overlay use-bgp spt-only
route-target export 1:1
route-target import 1:1
route-target export 1:1 stitching
route-target import 1:1 stitching
exit-address-family
!
Vérifiez que le groupe MDT est correctement programmé côté source
- L'interface entrante du groupe MDT est le bouclage côté source
- L'interface sortante du groupe MDT est l'interface sous-jacente
Vérification de Leaf-01 : la mroute MDT est correcte dans MRIB/MFIB
Leaf-01#sh ip mroute 239.1.2.0 172.16.254.3
<snip>
(172.16.254.3, 239.1.2.0), 00:01:19/00:02:10, flags: FT
Incoming interface: Loopback1, RPF nbr 0.0.0.0 <-- IIF is local loopback with 0.0.0.0 RPF indicating local
Outgoing interface list:
TenGigabitEthernet1/0/1, Forward/Sparse, 00:01:19/00:03:10 <-- OIF is the underlay uplink
Leaf-01#sh ip mfib 239.1.2.0 172.16.254.3
<snip>
(172.16.254.3,239.1.2.0) Flags: HW
SW Forwarding: 2/0/828/0, Other: 0/0/0
HW Forwarding: 450/2/834/13, Other: 0/0/0 <-- Hardware counters indicate the entry is operating in hardware and forwarding packets
Null0 Flags: A <-- Null0 (Originated locally)
TenGigabitEthernet1/0/1 Flags: F NS <-- OIF is into the Underlay (Global routing table)
Pkts: 0/0/0 Rate: 0 pps
Vérification de Leaf-01 : entrées FED pour le groupe MDT
Leaf-01#show platform software fed switch active ip mfib 239.1.2.0/32 172.16.254.3 detail <-- The detail option gives summary of the HW indexes
MROUTE ENTRY vrf 0 (172.16.254.3, 239.1.2.0/32) <-- vrf 0 = global for this MDT Data S,G pair
HW Handle: 140028029798744 Flags:
RPF interface: Null0(1)): <-- Leaf-01 is the Source(Null0)
HW Handle:140028029798744 Flags:A
Number of OIF: 2
Flags: 0x4 Pkts : 570 <-- Packets that used this adjacency (similar to the mfib command, but shown at the FED layer)
OIF Details:
TenGigabitEthernet1/0/1 F NS <-- The Underlay Outgoing Interface and F-Forward flag is set
Null0 A <-- The Incoming Interface is local loopback1 and A-Accept flag set
Htm: 0x7f5ad0fa48b8 Si: 0x7f5ad0fa4258 Di: 0x7f5ad0fa8948 Rep_ri: 0x7f5ad0fa8e28 <--The DI (dest index) handle
DI details
----------
Handle:0x7f5ad0fa8948 Res-Type:ASIC_RSC_DI Res-Switch-Num:255 Asic-Num:255 Feature-ID:AL_FID_L3_MULTICAST_IPV4 Lkp-ftr-id:LKP_FEAT_INVALID ref_count:1
priv_ri/priv_si Handle:(nil) Hardware Indices/Handles: index0:0x536e mtu_index/l3u_ri_index0:0x0 index1:0x536e mtu_index/l3u_ri_index1:0x0 index2:0x536e mtu_index/l3u_ri_index2:0x0 index3:0x536e mtu_index/l3u_ri_index3:0x0
<snip>
Brief Resource Information (ASIC_INSTANCE# 3)
----------------------------------------
Destination index = 0x536e
pmap = 0x00000000 0x00000001
pmap_intf : [TenGigabitEthernet1/0/1] <--FED has the correct programing of the OIF
==============================================================
Vérifiez que le groupe MDT est correctement programmé côté récepteur
- L'interface entrante du groupe MDT est l'interface RPF de retour au bouclage côté source
- L'interface sortante du groupe MDT est l'interface du tunnel Encap/Decap
Vérification de Leaf-02 : la mroute MDT est correcte dans MRIB/MFIB
Leaf-03#sh ip mroute 239.1.2.0 172.16.254.3 <-- This is the Global MDT Data Group
<snip>
(172.16.254.3, 239.1.2.0), 00:06:12/00:02:50, flags: JTx <-- Source is Leaf-01 Loopback1 IP
Incoming interface: TenGigabitEthernet1/0/1, RPF nbr 172.16.26.2
Outgoing interface list:
Tunnel0, Forward/Sparse, 00:06:12/00:02:47 <-- Decap Tunnel
Leaf-03#sh ip mfib 239.1.2.0 172.16.254.3
<snip>
Default <-- Global Routing Table
(172.16.254.3,239.1.2.0) Flags: HW
SW Forwarding: 2/0/828/0, Other: 0/0/0
HW Forwarding: 760/2/846/13, Other: 0/0/0 <-- Hardware counters indicate the entry is operating in hardware and forwarding packets
TenGigabitEthernet1/0/1 Flags: A <-- Accept via Underlay (Global) interface
Tunnel0, VXLAN Decap Flags: F NS <-- Forward to VxLAN Decap Tunnel
Pkts: 0/0/2 Rate: 0 pps
Vérifier Leaf-02 : entrées FED pour le groupe MDT
Leaf-03#show platform software fed switch active ip mfib 239.1.2.0/32 172.16.254.3 detail
MROUTE ENTRY vrf 0 (172.16.254.3, 239.1.2.0/32) <-- vrf 0 = global for this MDT Data S,G pair
HW Handle: 140592885196696 Flags:
RPF interface: TenGigabitEthernet1/0/1(55)): <-- RPF Interface to 172.16.254.3
HW Handle:140592885196696 Flags:A
Number of OIF: 2
Flags: 0x4 Pkts : 800 <-- packets that used this adjacency (similar to mfib command, but shown at the FED layer)
OIF Details:
TenGigabitEthernet1/0/1 A <-- Accept MDT packets from this interface
Tunnel0 F NS <-- Forward to Decap Tunnel to remove VxLAN header
(Adj: 0x3c ) <-- Tunnel0 Adjacency
Htm: 0x7fde54fb7d68 Si: 0x7fde54fb50d8 Di: 0x7fde54fb4948 Rep_ri: 0x7fde54fb4c58
<snip>
RI details <-- Rewrite Index is used for VxLAN decapsulation
----------
Handle:0x7fde54fb4c58 Res-Type:ASIC_RSC_RI_REP Res-Switch-Num:255 Asic-Num:255 Feature-ID:AL_FID_L3_MULTICAST_IPV4 Lkp-ftr-id:LKP_FEAT_INVALID ref_count:1
priv_ri/priv_si Handle:(nil) Hardware Indices/Handles: index0:0x1a mtu_index/l3u_ri_index0:0x0 index1:0x1a mtu_index/l3u_ri_index1:0x0 index2:0x1a mtu_index/l3u_ri_index2:0x0 index3:0x1a mtu_index/l3u_ri_index3:0x0
Brief Resource Information (ASIC_INSTANCE# 0)
----------------------------------------
ASIC# 0
Replication list :
------------------
Total #ri : 6
Start_ri : 26
Common_ret : 0
Replication entry rep_ri 0x1A #elem = 1
0) ri[0]=0xE803 Dynamic port=88ri_ref_count:1 dirty=0
<snip>
Leaf-03#show platfomr software fed switch active fwd-asic resource asic all rewrite-index range 0xE803 0XE803
ASIC#:0 RI:59395 Rewrite_type:AL_RRM_REWRITE_L2_PAYLOAD_IPV4_EVPN_DECAP(118) Mapped_rii:LVX_EVPN_DECAP(143)
<snip>
Déboguer le groupe de données MDT
Utilisez le débogage MVPN pour vérifier l'événement de basculement Data MDT
VTEP côté source
Leaf#debug mvpn
<snip>
*Mar 27 12:12:11.115: MVPN: Received local withdraw for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:12:11.115: MVPN: Sending BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nh 0.0.0.0, Withdraw route
*Mar 27 12:12:11.115: MVPN: Route Type 5 deleted [(10.1.101.11, 239.1.1.1), nh 0.0.0.0] rd:1:1 send:1
*Mar 27 12:12:11.115: MVPN: Received BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nexthop: UNKNOWN, router-id: 0.0.0.0, Withdraw route
*Mar 27 12:12:11.115: MVPN: Received BGP withdraw for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:13:00.430: MVPN: Received local route update for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:13:00.431: MVPN: Route Type 5 added [(10.1.101.11, 239.1.1.1), nh 0.0.0.0] rd:1:1 send:1
*Mar 27 12:13:00.431: MVPN: RP 10.2.255.255 updated in newly created route
*Mar 27 12:13:00.431: MVPN: Sending BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nh 0.0.0.0, Originate route
*Mar 27 12:13:00.431: MVPN: Received BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nexthop: UNKNOWN, router-id: 0.0.0.0, Withdraw route
*Mar 27 12:13:00.431: MVPN: Received BGP withdraw for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:13:17.151: MVPN(green[AF_IPv4]): Successfully notified nve fordatamdt adjacency create 239.1.2.0 <-- Notify NVE about creating DATA MDT
*Mar 27 12:13:17.151: MVPN: Received local update <104:0x00:0>(172.16.254.3, 239.1.2.0) next_hop:0.0.0.0 router_id:172.16.255.3 RD:[1:1] Rmt-RD:[1:1] route type:3 <-- Received local update for the data group
*Mar 27 12:13:17.151: MVPN: LSM AD route added [(10.1.101.11,239.1.1.1) : <104:0x00:0>(172.16.254.3, 239.1.2.0)] orig:172.16.255.3 RD:[1:1] Rmt-RD:[1:1] rt:3 snd:1
*Mar 27 12:13:17.151: MVPN(green[AF_IPv4]): Sending VxLAN BGP AD prefix=[3:172.16.255.3 1:1 : (10.1.101.11,239.1.1.1)] len=23, accept=1, af=0 <-- Send the MDT Data Adjacency prefix in VxLAN BGP to remote VTEPS
*Mar 27 12:13:17.151: MVPN(green[AF_IPv4]): Originate VxLAN BGP AD rt:3
*Mar 27 12:13:17.151: MVPN(green[AF_IPv4]): VXLAN MDT-Data, node added for (10.1.101.11,239.1.1.1) MDT: 239.1.2.0 <-- Add a node for the data group
Leaf-01#
VTEP côté récepteur
Leaf#debug mvpn
<snip>
*Mar 27 12:27:54.920: MVPN: Received BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nexthop: 172.16.255.3, router-id: 172.16.255.1, Accept route
*Mar 27 12:27:54.920: MVPN: Received BGP route update for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:27:54.920: MVPN: Route Type 5 found [(10.1.101.11, 239.1.1.1), nh 172.16.255.3]rd:1:1 send:0
*Mar 27 12:27:54.920: MVPN: Received BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nexthop: UNKNOWN, router-id: 0.0.0.0, Withdraw route
*Mar 27 12:27:54.920: MVPN: Received BGP withdraw for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:27:54.920: MVPN: Route Type 5 deleted [(10.1.101.11, 239.1.1.1), nh 172.16.255.3] rd:1:1 send:0
*Mar 27 12:28:27.648: MVPN: Received BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nexthop: UNKNOWN, router-id: 0.0.0.0, Withdraw route
*Mar 27 12:28:27.657: MVPN: Received BGP withdraw for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:28:44.235: MVPN: Received BGP prefix=[5: 1:1 : (10.1.101.11,239.1.1.1)] len=19, nexthop: 172.16.255.3, router-id: 172.16.255.1, Accept route
*Mar 27 12:28:44.235: MVPN: Received BGP route update for (10.1.101.11, 239.1.1.1) with RD: 1:1, Route Type: 5, flags: 0x00
*Mar 27 12:28:44.235: MVPN: Route Type 5 added [(10.1.101.11, 239.1.1.1), nh 172.16.255.3] rd:1:1 send:0
*Mar 27 12:29:00.956: MVPN: Received BGP prefix=[3:172.16.255.3 1:1 : (10.1.101.11,239.1.1.1)] len=23, nexthop: 172.16.255.3, router-id: 172.16.255.2, remote-rd: 1:1, Accept route
*Mar 27 12:29:00.956: MVPN: Received BGP prefix=[3:172.16.255.3 1:1 : (10.1.101.11,239.1.1.1)] len=23, nexthop: 172.16.255.3, router-id: 172.16.255.1, remote-rd: 1:1, Accept route
*Mar 27 12:29:00.956: MVPN: Received BGP update <104:0x00:50901>(172.16.254.3, 239.1.2.0) next_hop:172.16.255.3 router_id:172.16.255.2 RD:[1:1] Rmt-RD:[1:1] route type:3 <-- Received BGP update from source side VTEP
*Mar 27 12:29:00.956: MVPN: LSM AD route added [(10.1.101.11,239.1.1.1) : <104:0x00:50901>(172.16.254.3, 239.1.2.0)] orig:172.16.255.3 RD:[1:1] Rmt-RD:[1:1] rt:3 snd:0 <-- Adding the Data group
*Mar 27 12:29:00.957: MVPN(green[AF_IPv4]): Activating PE (172.16.255.3, 1:1) ad route refcnt:1 control plane refcnt: 0
*Mar 27 12:29:00.958: MVPN(green[AF_IPv4]): Successfully notified datamdt group for NVE (239.1.2.0, TRUE, FALSE) <-- Notify NVE of the DATA MDT
*Mar 27 12:29:00.958: MVPN: Received BGP update <104:0x00:50901>(172.16.254.3, 239.1.2.0) next_hop:172.16.255.3 router_id:172.16.255.1 RD:[1:1] Rmt-RD:[1:1] route type:3
Leaf-03#
Dépannage
Sources de multidiffusion non détectées |
| Avant d'examiner pourquoi un flux de multidiffusion ne fonctionne pas, il est important de comprendre la relation entre ARP et le transfert de multidiffusion Généralement, lorsqu’un hôte devient actif et envoie du trafic, les entrées ARP sont complétées par les procédures normales de détection de la source. Mais, dans le cas des sources de multidiffusion, il est possible que la source commence à envoyer du trafic et que le plan L2 au niveau du FHR traite ce trafic de multidiffusion sans résolution d'ARP pour la source. L'achèvement du protocole ARP joue un rôle important dans la fonctionnalité TRM pour deux raisons.
Assurez-vous que le protocole ARP est résolu et que la source est accessible au sein du fabric EVPN. |
Autres débogages utiles |
| Cette section contient d'autres débogages qui peuvent être utiles pour isoler les problèmes de TRM
|
Sources et récepteurs externes au fabric |
| Dans certains cas, la source et/ou le récepteur peuvent se trouver à un ou plusieurs sauts L3 du ou des VTEP de fabric. Cette conception est valide, mais elle modifie le type de route EVPN qui transporte le VRI, ainsi que le processus responsable de la création des jointures au niveau du VTEP du récepteur.
|
Topologie eBGP à AS multiples (Spine to Spine) |
| Dans certains cas, la topologie peut exiger que BGP envoie des informations de mise à jour à un autre AS/fabric. Il est possible que jusqu'à 30 secondes s'écoulent pour que les informations du plan de contrôle BGP convergent et que la multidiffusion commence à fonctionner.
eBGP inter-as nécessite une commande supplémentaire Utilisez le mot clé inter-as pour les routes de la famille d'adresses MVPN pour traverser les frontières du système autonome BGP (AS). Border-Leaf(config-vrf-af)#mdt auto-discovery vxlan inter-as |
Tunnel de registre avec L2VNI symétrique (FHR bloqué dans l'état de registre PIM) |
| Dans les cas où le VNI existe sur le FHR et sur d'autres VTEP, il est possible que le FHR soit bloqué dans l'état Register Cela est dû au fait que l'IP source du tunnel du registre PIM est la passerelle AnyCast. Lorsque le RP reçoit un registre PIM, il ne sait pas quel est le VTEP approprié pour envoyer l'arrêt du registre, car l'IP est commun à plusieurs périphériques. Problème de route du tunnel du registre PIM (Leaf-01) Il s'agit du FHR réel : envoie des messages Register au RP Leaf-01#sh ip pim vrf green tunnel (Leaf-03) : ce VTEP (et éventuellement d'autres) contient les mêmes adresse IP et SVI que le FHR Leaf-03#sh ip pim vrf green tunnel (Leaf-01) : le FHR reste bloqué dans le registre (il ne reçoit pas d'arrêt de registre de la part du RP) Leaf-01#show ip mroute vrf green 226.1.1.1 10.1.101.11 (Leaf-02) Il s'agit du RP : dans ce cas, il possède également la même adresse IP AnyCast que le FHR, et envoie ainsi le register-stop à lui-même. Si RP n'a pas l2vni mais 2 ou 3 autres vtep le font, register-stop pourrait être envoyé au mauvais VTEP car le RP n'a aucun moyen de sélectionner le bon. Leaf-02#sh ip route vrf green 10.1.101.1 (Leaf-02) : Debug on RP indique le problème où RP a cette route comme Connected Local Leaf-02#debug ip pim vrf green 226.1.1.1 Solution de problème de route de tunnel de registre PIM La solution est d'utiliser une adresse IP de bouclage unique sur tous les VTEP et d'utiliser la configuration notée dans cette section. Leaf-01#sh run int lo 901 |
Informations connexes
Guide de configuration EVPN VxLAN TRM
Dépannage de la monodiffusion EVPN VxLAN
Guide de configuration MVPN 17.3.x (commutateurs Catalyst 9300)
Guide de configuration MVPN 17.3.x (commutateurs Catalyst 9500)
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
4.0 |
13-Aug-2024 |
Type fixe dans le scénario 4 |
3.0 |
17-May-2023 |
Scénario MDT de données ajoutées |
2.0 |
10-Aug-2021 |
Correction de quelques problèmes mineurs de formulation |
1.0 |
03-Jun-2021 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)