Quand le VXLAN EVPN flanche en production, la différence entre “tout va bien” et “blackhole” se joue rarement dans un seul show. Il faut corréler BGP EVPN (control-plane), programming ASIC (dataplane) et ressources hardware (TCAM/queues/CoPP), tout en validant l’underlay L3 (MTU/ECMP). Ce guide propose des séquences complètes de diagnostic.
1. Sanity check underlay — prouver que le transport tient (y compris MTU/CoPP)
Avant de toucher à EVPN, prouvez que les VTEPs se joignent via l’underlay, sans fragmentation, et sans contrôle-plane police qui throttle les sessions.
! MTU "vérité terrain" : testez le plus grand paquet possible (DF) entre VTEPs
ping <REMOTE-VTEP-LOOPBACK> source <LOCAL-LOOPBACK> size 8972 df-bit repeat 5 timeout 2
! Route sous-jacente / ECMP
traceroute <REMOTE-VTEP-LOOPBACK> source <LOCAL-LOOPBACK>
! CoPP / BGP throttle : vérifiez que le control-plane ne policie pas vos sessions
show policy-map control-plane input
show policy-map control-plane output
! BFD si utilisé sur underlay
show bfd neighbors detail
! Interfaces physiques & MTU cohérente jusqu'à la fabric
show interface <ETH-UNDERLAY> | inc MTU|errors|drops
2. Control-plane EVPN (BGP) — routes présentes ≠ routes utiles
Validez d’abord l’état BGP EVPN (sessions, familles, update-groups), puis descendez jusqu’au détail route-type par route-target, et suivez un préfixe jusqu’à sa programmation.
! Vue d'ensemble : sessions & nombre de routes
show bgp l2vpn evpn summary
show bgp l2vpn evpn
! Corrélation par type : RT2 (MAC+IP), RT3 (IMET/BUM), RT5 (L3VNI prefixes)
show bgp l2vpn evpn route-type 2
show bgp l2vpn evpn route-type 3
show bgp l2vpn evpn route-type 5
! Filtrage par RD/RT (chasse aux fuites de RT ou aux manques d'import)
show bgp l2vpn evpn | inc RD:|RT:
show bgp l2vpn evpn rd <RD> detail
show bgp l2vpn evpn route-target <RT:xxx:yyy> detail
! Vérifier ce que chaque voisin envoie/reçoit (cohérence RR/leaf)
show bgp l2vpn evpn neighbors <NEIGH-IP> advertised-routes
show bgp l2vpn evpn neighbors <NEIGH-IP> received-routes
! État découverte hôte si ARP/ND suppression : on attend des RT2 MAC/IP "Bind"
show l2route evpn mac-ip all
show l2route evpn mac all
Si la route existe en BGP mais “disparaît” avant l’ASIC, suspectez un écart dans la chaîne L2RIB → FIB. Passez immédiatement à la section suivante.
3. De la RIB au FIB — prouver (ou infirmer) la programmation ASIC
Une route EVPN utile doit se matérialiser dans les tables de forwarding. Corrélez la base l2route/l3 route avec la vue forwarding et, si besoin, les compteurs internes.
! L2/L3 forwarding réellement programmé (ASIC)
show forwarding vxlan tunnel
show forwarding vrf <VRF-NAME> route evpn
show forwarding interface nve1 detail
! Mappage VNI, réplication, anycast-gateway, counters par VNI
show nve vni detail
show nve interface nve1
show fabric forwarding anycast-gateway
! Quand c'est louche : basculer "en rayon X"
show hardware internal counters vxlan
show hardware internal errors vxlan
! (TCAM) Si des objets ne rentrent pas, ils ne seront jamais programmés
show hardware access-list resource utilization
Règle d’or : “BGP dit oui, ASIC dit non” → ce n’est pas routable/bridgeable. Poursuivez en cas concrets.
4. Cas A — NVE UP, RT2 présents, mais trafic L2 blackhole entre leafs
Hypothèse typique : RT2 vu en BGP, l2route montre le MAC/IP, mais pas de paquet retour. Deux suspects fréquents : non-programmation ASIC ou réplication BUM non fonctionnelle (ARP ne résout pas correctement).
! Confirmez chaîne complète jusqu'à l'ASIC
show bgp l2vpn evpn route-type 2 | inc <MAC|IP-VM>
show l2route evpn mac-ip detail | inc <MAC|IP-VM>
show forwarding vrf <VRF> route evpn | inc <IP-VM>
show forwarding vxlan tunnel | inc <REMOTE-VTEP>
! Si l'ARP ne "popule" pas la RT2 (ou se perd) → regardez le BUM
show bgp l2vpn evpn route-type 3
show nve vni <VNI> detail <-- IMET ou mcast-group/ingress-replication
show forwarding vxlan multicast
Si la RT3 (IMET) manque sur certains leafs, l’ARP/ND suppression ne trouvera jamais le prochain-saut. Validez l’underlay multicast si vous êtes en mcast-group, sinon forcez temporairement l’ingress-replication pour isoler.
! Underlay multicast (si utilisé)
show ip pim route vrf <UNDERLAY-VRF>
show ip pim rp vrf <UNDERLAY-VRF>
show ip mroute vrf <UNDERLAY-VRF> <GROUP>
Si tout est “vert” côté control-plane, cherchez un blocage ASCENDANT : TCAM saturé, CoPP trop agressive, ou drop matériel silencieux.
! Le révélateur de drops "silencieux"
show hardware internal forwarding drops reasons
show hardware internal forwarding vxlan counters
! Police control-plane trop serrée ?
show policy-map control-plane input | inc BGP|IGMP|PIM|ARP
5. Cas B — L3VNI : ping inter-VRF impossible, RT5 absents ou inutilisables
Les interconnexions L3VNI échouent souvent car les RT5 ne s’alignent pas (import/export), ou car le RR ne relaie pas correctement (ex : absence d’advertise-pip dans certains designs).
! Les RT5 doivent exister et pointer vers le bon VTEP
show bgp l2vpn evpn route-type 5
show bgp l2vpn evpn neighbors <RR-IP> advertised-routes | inc Type-5|RT:
show bgp l2vpn evpn neighbors <LEAF-PEER> received-routes | inc Type-5|RT:
! Table VRF/CEF (ou équivalent) : la route est-elle réellement "forwardable" ?
show forwarding vrf <VRF> route evpn | inc <PREFIX>
show ip route vrf <VRF> <PREFIX> longer-prefixes
Si le préfixe est visible en BGP mais pas en forwarding, remontez les RT et l’association L3VNI↔VRF. Dans les fabrics multi-site, n’oubliez pas la contrainte BG/BG-only.
! Liaison L3VNI <-> VRF et RT cohérents
show vrf detail | inc VNI|RD|RT
show nve vni <L3VNI> detail
! (Multi-Site) Confiance NVE MS & rôle Border Gateway
show nve multisite border-gateway
show nve multisite fabric-links
6. Cas C — Anycast GW incohérent (IP répond d’un leaf, pas de l’autre)
De multiples “fantômes” L2 viennent d’un anycast-gateway divergent (MAC anycast ou SVI non-symétriques entre vPC-peers). Le symptôme : ARP/ND suppression aléatoire, pings unidirectionnels.
! Assurez-vous que la MAC anycast est identique partout
show fabric forwarding anycast-gateway
! Sur un environnement vPC : cohérence SVI/ARP/HSRP/IGMP
show vpc brief
show vpc consistency-parameters global
show interface vlan <VLAN> | inc MAC|IP|VRF
show mac address-table vlan <VLAN> | inc <ANYCAST-MAC>
Si la MAC anycast diverge entre vPC-peers, vous verrez des RT2 contradictoires et des ré-apprentissages incessants. Corrigez la SVI/anycast, purgez les bindings incohérents et forcez un refresh ARP.
clear l2route evpn mac all
clear ip arp force-delete
7. Cas D — “Tout est up” mais le flux tombe : prouver le dataplane avec capture
Quand les tables semblent correctes mais qu’un flux précis échoue, une capture ciblée tranche vite : paquet VXLAN sort-il de NVE ? arrive-t-il au voisin ? se décapsule-t-il ?
! Capture locale (inband) des paquets VXLAN (UDP/4789)
ethanalyzer local interface inband capture-filter "udp port 4789 and host <REMOTE-VTEP>" limit-captured 200 detail
! ERSPAN "on the wire" (si besoin d'un PCAP externe)
conf t
monitor session 10 type erspan-source
source interface nve1 direction both
destination
erspan-id 10
ip address <COLLECTOR-IP>
origin ip address <LOCAL-LOOPBACK>
end
show monitor session 10
Si vous voyez le VXLAN sortir mais rien n’arriver côté pair, retournez à l’underlay (ECMP asymétrique, MTU, ACL transit, fabric-link down en Multi-Site).
8. Flapping BGP EVPN : stabilité control-plane & timers
Des sessions EVPN “flappent” alors que l’IP est joignable ? Inspectez la santé BGP, les timers, la queue d’updates, et le policing control-plane.
show bgp l2vpn evpn summary
show bgp l2vpn evpn neighbors <NEIGH-IP> timers
show bgp l2vpn evpn neighbors <NEIGH-IP> flap-statistics
show logging last 200 | inc BGP|EVPN|NVE
show policy-map control-plane input | inc BGP
show interface <KERNEL/INBAND> | inc drops|errors
Si la cause n’est pas évidente, un soft reset ciblé peut accélérer la convergence pendant l’analyse :
clear bgp l2vpn evpn <NEIGH-IP> soft in
clear bgp l2vpn evpn <NEIGH-IP> soft out
. Runbook express — prouver, corréler, conclure
Vous pouvez appliquer la séquence ci-dessous à n’importe quel incident VXLAN EVPN pour isoler le fautif (underlay, control-plane, programmation, réplication, ressources) :
### 1. Underlay
ping <REMOTE-VTEP> source <LOCAL-LOOPBACK> size 8972 df-bit
traceroute <REMOTE-VTEP> source <LOCAL-LOOPBACK>
show policy-map control-plane input
### 2. EVPN (BGP)
show bgp l2vpn evpn summary
show bgp l2vpn evpn route-type 2
show bgp l2vpn evpn route-type 3
show bgp l2vpn evpn route-type 5
show bgp l2vpn evpn neighbors <NEIGH-IP> advertised-routes
show bgp l2vpn evpn neighbors <NEIGH-IP> received-routes
### 3. L2/L3 route DB
show l2route evpn mac all
show l2route evpn mac-ip all
show vrf detail | inc VNI|RD|RT
# 4. ASIC / Forwarding réel
show forwarding vxlan tunnel
show forwarding vrf <VRF> route evpn
show nve vni detail
show fabric forwarding anycast-gateway
# 5. BUM / Multicast (si applicable)
show nve vni <VNI> detail
show ip pim route vrf <UNDERLAY>
show ip mroute vrf <UNDERLAY> <GROUP>
# 6. Ressources & drops
show hardware access-list resource utilization
show hardware internal forwarding drops reasons
show hardware internal counters vxlan
# 7. Captures
ethanalyzer local interface inband capture-filter "udp port 4789 and host <REMOTE-VTEP>" limit-captured 200 detail
8. Signaux d’alarme (symptômes → suspect par priorité)
• RT2 OK, ping L2 KO : vérifier RT3/IMET, ARP suppression, puis ASIC (forwarding) et hardware internal drops.
• Inter-VRF KO avec BGP stable : chasse aux RT5 import/export, RR (advertise-pip), L3VNI ↔ VRF, puis ASIC.
• Flux aléatoires, asymétriques : anycast-gateway, vPC consistency, ECMP underlay, CoPP/ACL transit.
• Flap sessions EVPN : timers, policing CP, drops input NVE/CPU, qualité liens underlay.
9. Notes pratiques
• Si BGP “voit” mais ASIC “ignore”, résolvez le différentiel (ressources, bug, filtre).
• N’itérez jamais sans capturer au moins une fois : prouver si le VXLAN sort/arrive coupe court aux suppositions.
• Pendant l’analyse, un soft-clear BGP EVPN peut limiter l’impact sans purger la FIB (clear ... soft in/out).
