Dépannage des fuites de route inattendues dans l'ACI

Aperçu

L'ACI gère de nombreuses configurations de routage et de commutation traditionnellement complexes grâce au déploiement de politiques simples. Parmi ces fonctionnalités, il y a la possibilité de fuiter des routes entre des VRF afin de faciliter les services partagés. Traditionnellement, il s'agissait de nombreuses étapes, telles que la définition des cibles de route, la création de familles d'adresses BGP, les identificateurs de route et la réplication de cette configuration sur de nombreux périphériques.

Au sein de l'ACI, les fuites de routage sont gérées par la combinaison de contrats et la définition de paramètres partagés spécifiques sur les sous-réseaux. Toute la configuration traditionnelle requise pour faire fonctionner la fuite de route est gérée sur le serveur principal en raison de la configuration du contrat et du sous-réseau partagé.

Cependant, avec cette configuration abstraite, il peut devenir plus difficile d'identifier quel contrat provoque une fuite d'une route. Cela est particulièrement vrai dans les environnements comportant un grand nombre d'epg, de vrfs et de contrats. Si une route est divulguée de manière inattendue entre vrfs, comment un administrateur peut-il identifier la configuration (contrat) à l’origine de cette fuite ?

L'objectif de ce document est de montrer comment identifier la relation contractuelle qui provoque une fuite d'une route dans l'ACI entre les VRF. Il est utile de connaître déjà les concepts traditionnels de fuite de route tels que les cibles de route et le VPNv4 BGP.

Logiciel utilisé

Tous les exemples de ce document sont basés sur le logiciel aci 4.2(3j).

Pourquoi un domaine Bridge / sous-réseau EPG de VRF x est-il installé dans VRF y ?

Cette section porte sur le scénario où un sous-réseau BD ou EPG est inopinément divulgué à un autre vrf. Pour qu'un sous-réseau BD/EPG soit divulgué, l'indicateur « Partagé entre VRF » doit être configuré. La partie la plus difficile est de savoir quel contrat est à l'origine de la fuite de cette information, de sorte que c'est ce que cette section traitera.

À un niveau élevé, il s'agit du workflow pour ce qui se passe lorsqu'un sous-réseau BD/EPG est divulgué entre vrfs.

Figure 1.

*Notez que le n° 3 n'est applicable que lorsque vous annoncez un n3out partagé. Les numéros 1 et 2 s'appliquent toujours, qu'un l3out partagé soit utilisé ou que les services partagés soient entièrement internes.

Tout d'abord, comment l'utilisateur peut-il savoir si la route installée est divulguée à la suite d'un sous-réseau BD ou EPG ?

Lors de l'exécution de "show ip route vrf <name>« , l'indicateur "omniprésent" indique que la route est un sous-réseau BD ou EPG.

Par exemple, dans la topologie ci-dessus, ceci est visible sur la feuille de bordure dans le vrf externe (vrf1) :

leaf103# show ip route 10.100.100.100 vrf jy:vrf1
IP Route Table for VRF "jy:vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
     
     
       ' in via output denotes VRF 
      
        10.100.100.0/24, ubest/mbest: 1/0, attached, direct, 
       pervasive *via 10.3.144.68%overlay-1, [1/0], 21:29:54, static, tag 4294967292 recursive next hop: 10.3.144.68/32%overlay-1 
       
     

En outre, la VRF de destination à partir de laquelle le sous-réseau a été divulgué peut être affichée en exécutant la commande suivante :

leaf103# vsh -c "show ip route 10.100.100.100 detail vrf jy:vrf1"
IP Route Table for VRF "jy:vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
     
     
       ' in via output denotes VRF 
      
        10.100.100.0/24, ubest/mbest: 1/0, attached, direct, 
       pervasive *via 10.3.144.68%overlay-1, [1/0], 21:34:16, static, tag 4294967292 recursive next hop: 10.3.144.68/32%overlay-1 
       vrf crossing information: VNID:0x258003 ClassId:0x18 Flush#:0x2 
       
     

*(notez que les informations de croisement vrf sont définies indépendamment du fait que le vrf de destination soit différent du vrf de recherche).

Dans le résultat ci-dessus, le vnid de croisement vrf est défini sur 0x258003 ou 2457603 décimal. Comment peut-on identifier le vrf qui appartient à la vnid 2457603 ?

À partir de l'APIC, il vous suffit d'interroger l'objet fvCtx et de filtrer en fonction du gid.

apic1# moquery -c fvCtx -f 'fv.Ctx.seg=="2457603"'
Total Objects shown: 1

# fv.Ctx
name                 : vrf2
dn                   : uni/tn-jy/ctx-vrf2
pcEnfDir             : ingress
pcEnfPref            : enforced
pcTag                : 49153
scope                : 2457603
seg                  : 2457603

Comme prévu, la route est apprise à partir du vrf2 vrf.

On ignore encore à ce stade quel contrat est utilisé, quel epg fournit et quel epg consomme pour que cette route soit installée. Il y a quelques considérations à retenir en ce qui concerne la relation fournisseur-consommateur :
1. Pour une relation de contrat inter-vrf, le contrat (et la règle de zonage qui en résulte) n'est installé que dans le vrf du epg consommateur. Par conséquent, « show zoning-rule » dans le vrf du fournisseur n'affichera pas la relation.
2. Même si le contrat n'est installé que dans le VRF grand public, le VRF fournisseur doit obtenir la route pour le sous-réseau BD du VRF grand public, ce qui signifie que le leaf doit avoir une référence de configuration au contrat.

Identifier le contrat lorsque la route est divulguée de manière inattendue au VRF du consommateur

L'objet ipCons sur la feuille est installé sur la feuille qui fait référence...

a.) la route fuitée vers le vrf consommateur

b) le contrat établissant la relation

c.) le fournisseur et le consommateur epg dans la relation.

Dans le résultat ci-dessous, « jy : vrf1 » est le VRF grand public vers lequel la route est divulguée et « 10.100.100.0/24" est la route qui est divulguée.

leaf103# moquery -c ipCons -f 'ip.Cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]"'
Total Objects shown: 1

# ip.Cons
consDn       : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]
subConsDn    :
childAction  :
dn           : sys/ipv4/inst/dom-jy:vrf1/rt-[10.100.100.0/24]/rsrouteToRouteDef-[bd-[uni/tn-jy/BD-bd1]-isSvc-no/epgDn-[uni/tn-jy/ap-ap1/epg-epg1]/rt-[10.100.100.1/24]]/cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[]
lcOwn        : local
modTs        : 2019-12-23T12:50:51.440-05:00
name         :
nameAlias    :
rn           : cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[]
status       :

À partir du résultat ci-dessus, le nom du contrat est « partagé », le epg consommateur est l3out epg « uni/tn-jy/out-jy-ospf/instP-all » et le epg fournisseur est « uni/tn-jy/ap-ap1/epg-epg1 ».

Identifier le contrat lorsque la route est divulguée de manière inattendue au VRF du fournisseur

L'objet consNode est installé sur la feuille dans la vrf du fournisseur. Il fait référence au sous-réseau BD de la VRF grand public qui est divulgué, au contrat et aux epg de la relation. Avant d'interroger cet objet, recherchez le sous-réseau BD où la route est configurée. Pour ce faire, vous pouvez interroger l'objet fvSubnet sur l'icône :

apic1:~> moquery -c fvSubnet -f 'fv.Subnet.dn*"10.100.100"'

# fv.Subnet
ip           : 10.100.100.1/24
dn           : uni/tn-jy/BD-bd1/subnet-[10.100.100.1/24]
preferred    : no
rn           : subnet-[10.100.100.1/24]
scope        : public,shared

La route est configurée dans le domaine de pont tn-jy/BD-bd1. Utilisez ceci et la commande vnid du vrf du fournisseur (vers lequel la route est divulguée) pour exécuter la commande ci-dessous.

leaf103# moquery -c consNode -f 'cons.Node.dn*"2949122"' -f 'cons.Node.dn*"tn-jy/BD-bd1"'
Total Objects shown: 1

# cons.Node
consDn       : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]
annotation   :
childAction  :
descr        :
dn           : consroot-[bd-[uni/tn-jy/BD-bd1]-isSvc-no]-[sys/ctx-[vxlan-2949122]]/consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]
extMngdBy    :
lcOwn        : local
modTs        : 2019-12-23T12:25:36.153-05:00
name         :
nameAlias    :
rn           : consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]
status       :
uid          : 0

À partir de la sortie ci-dessus, le nom du contrat est « partagé », le epg consommateur est « uni/tn-jy/ap-ap1/epg-epg1 » et le epg fournisseur est l3out « tn-jy/out-jy-ospf/instP-all ».

Identifier le contrat lorsque la route est divulguée de manière inattendue par un vz consomméTout contrat

L'exemple vzAny sera identique du point de vue de la vérification à une relation fournisseur/consommateur traditionnelle. Les exemples ci-dessous vous montreront à quoi cela ressemblerait. Notez qu'un contrat inter-vrf n'est pris en charge que par le client vzAny.

vzAny Exemple 1 : Fuite inattendue de la route vers VRF grand public

Comme dans le premier exemple, où la vérification a été effectuée dans la VRF grand public, l'objet ipCons sera de nouveau utilisé.

leaf103# moquery -c ipCons -f 'ip.Cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]"'
Total Objects shown: 1

# ip.Cons
consDn       : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ctx-vrf1/any]/fr-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf1/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf1/any]-any-yes]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]
subConsDn    :
childAction  :
dn           : sys/ipv4/inst/dom-jy:vrf1/rt-[10.100.100.0/24]/rsrouteToRouteDef-[bd-[uni/tn-jy/BD-bd1]-isSvc-no/epgDn-[uni/tn-jy/ap-ap1/epg-epg1]/rt-[10.100.100.1/24]]/cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ctx-vrf1/any]/fr-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf1/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf1/any]-any-yes]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[]
lcOwn        : local
modTs        : 2019-12-23T13:11:08.077-05:00
name         :
nameAlias    :
rn           : cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ctx-vrf1/any]/fr-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf1/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf1/any]-any-yes]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[]
status       :

À partir du résultat ci-dessus, le nom du contrat est « partagé », le epg consommateur est le vrf1 vzAny « tn-jy/ctx-vrf1/any » et le epg fournisseur est « uni/tn-jy/ap-ap1/epg-epg1 ».

vzAny Exemple 2 : Fuite inattendue de la route vers le VRF du fournisseur

Comme dans le deuxième exemple, où la vérification a été effectuée dans le fournisseur vrf, l'objet consNode sera de nouveau utilisé. N'oubliez pas d'obtenir le nom de pont du BD où le sous-réseau divulgué est configuré et le nom de la VRF vers laquelle il est divulgué.

leaf103# moquery -c consNode -f 'cons.Node.dn*"vxlan-2949122"' -f 'cons.Node.dn*"tn-jy/BD-bd1"'
Total Objects shown: 1

# cons.Node
consDn       : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf2/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf2/any]-any-yes]
annotation   :
childAction  :
descr        :
dn           : consroot-[bd-[uni/tn-jy/BD-bd1]-isSvc-no]-[sys/ctx-[vxlan-2949122]]/consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf2/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf2/any]-any-yes]]
extMngdBy    :
lcOwn        : local
modTs        : 2019-12-23T13:06:09.016-05:00
name         :
nameAlias    :
rn           : consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf2/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf2/any]-any-yes]]
status       :
uid          : 0

À partir de la sortie ci-dessus, le nom du contrat est « partagé », le epg consommateur est le vrf2 vzAny « tn-jy/ctx-vrf2/any » et le epg fournisseur est l3out « tn-jy/out-jy-ospf/instP-all ».

Pourquoi une route externe à partir de VRF y est-elle installée dans VRF x ?

À un niveau élevé, il s’agit du workflow de ce qui se passe lorsqu’une route (externe) apprise par l3out est divulguée entre vrfs.

Figure 2.

Comme vous pouvez le voir ci-dessus, le vrf interne (vrf2 dans ce cas) installe une importation route-target qui correspond à vrf1. Il installe également un mappage d'importation sur le processus bgp qui doit avoir des entrées de liste de préfixes correspondant à tout ce défini dans l3out qui a l'indicateur de « sous-réseau de contrôle de route partagé » sélectionné.

Quel que soit le fournisseur ou le consommateur, les étapes de vérification sont les mêmes, car le contrat sera toujours responsable de l'importation route-target et des listes de préfixes correspondantes qui fuiront les routes pour être installées.

Tout d'abord, vérifiez que la route est en fait apprise via un l3out :

leaf101# show ip route 10.9.9.1 vrf jy:vrf2
IP Route Table for VRF "jy:vrf2"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
     
     
       ' in via output denotes VRF 
      
        10.9.9.1/32, ubest/mbest: 1/0 * 
       via 10.3.248.4% 
       overlay-1, [200/5], 00:00:13, 
       bgp-65001, internal, tag 65001 
       
     

Dans l'exemple ci-dessus, le fait qu'il soit appris à partir du processus bgp de la structure pointant vers une autre feuille dans la superposition indique que cela provient d'une sortie l3out.

Exécutez les informations suivantes pour obtenir plus d'informations sur la version dont il a été informé :

leaf101# vsh -c "show ip route 10.9.9.1 detail vrf jy:vrf2"
IP Route Table for VRF "jy:vrf2"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
     
     
       ' in via output denotes VRF 
      
        10.9.9.1/32, ubest/mbest: 1/0 *via 10.3.248.4%overlay-1, [200/5], 00:05:46, bgp-65001, internal, tag 65001 (mpls-vpn) MPLS[0]: Label=0 E=0 TTL=0 S=0 (VPN) client-specific data: 6b recursive next hop: 10.3.248.4/32%overlay-1 extended route information: BGP origin AS 65001 BGP peer AS 65001 
       rw-vnid: 0x2d0002 table-id: 0x17 rw-mac: 0 
       
     

Comme indiqué précédemment dans ce document, rewrite vnid 0x2d0002 / 2949122 est le vrf de destination. La valeur rw-vnid définie sur une valeur non nulle dans un exemple de route externe indique que ceci a été appris à partir d'un autre vrf. L'exécution de moquery -c fvCtx -f 'fv.Ctx.seg=« 2949122 » sur l'apic indique que cela appartient à vrf1.

Ensuite, recherchez les importations de destination de route ainsi que la route-map d'importation liée au processus bgp.

leaf101# show bgp process vrf jy:vrf2

Information regarding configured VRFs:

BGP Information for VRF jy:vrf2
VRF Type                       : System
VRF Id                         : 23
VRF state                      : UP
VRF configured                 : yes
VRF refcount                   : 0
VRF VNID                       : 2457603
Router-ID                      : 10.100.100.1
Configured Router-ID           : 0.0.0.0
Confed-ID                      : 0
Cluster-ID                     : 0.0.0.0
MSITE Cluster-ID               : 0.0.0.0
No. of configured peers        : 0
No. of pending config peers    : 0
No. of established peers       : 0
VRF RD                         : 101:2457603
VRF EVPN RD                    : 101:2457603

    Information for address family IPv4 Unicast in VRF jy:vrf2
    Table Id                   : 17
    Table state                : UP
    Table refcount             : 5
    Peers      Active-peers    Routes     Paths      Networks   Aggregates
    0          0               2          2          0          0

    Redistribution
        None

    Wait for IGP convergence is not configured
    Import route-map 2457603-shared-svc-leak <-- bgpRtCtrlMapP
    Export RT list:
        65001:2457603
    Import RT list:
        65001:2457603
        65001:2949122 <-- bgpRttEntry
    Label mode: per-prefix

Le vrf interne ci-dessus exporte et importe sa propre route-target (65001:2457603). Il importe également 65001:2949122. Le 2949122 RT correspond au vnid vrf qu'il importe (vrf1). bgpRtCtrlMapP est le nom d'objet de la route-map d'importation qui contient les listes de préfixes. bgpRttEntry est le nom d'objet de la cible de route d'importation.

Ensuite, à l'aide de la commande vnid du vrf interne qui apprend les routes du vrf externe, interrogez toutes les listes de préfixes qui sont installées dans la route-map des services partagés.

leaf101# moquery -c rtpfxEntry -f 'rtpfx.Entry.dn*"pfxlist-IPv4'.*'2457603-shared-svc-leak"' | egrep "criteria|dn|pfx|toPfxLen"
# rtpfx.Entry
criteria         : inexact
dn               : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak/ent-2
pfx              : 0.0.0.0/0
toPfxLen         : 32
# rtpfx.Entry
criteria         : exact
dn               : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak/ent-3
pfx              : 10.9.9.1/32
toPfxLen         : 0
# rtpfx.Entry
criteria         : exact
dn               : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak/ent-1
pfx              : 10.9.9.0/24
toPfxLen         : 0

Chaque entrée doit correspondre à un sous-réseau externe. L'attribut « exact / inexact » indique si l'indicateur « agrégé partagé » a été défini sur le sous-réseau externe. Le préfixe 0.0.0.0/0 avec l'indicateur inexact indique qu'il correspondrait à toutes les routes qui sont plus spécifiques (en fait tout). Le préfixe 10.9.9.0/24 avec l'indicateur exact indique qu'il ne correspondrait qu'à /24.

Recherchez l'entrée (ou les entrées) correspondant à la route qui fait l'objet d'une fuite inattendue. Dans ce cas, le préfixe est 10.9.9.1/32 sera mis en correspondance par ent-2 et ent-3 dans les sorties ci-dessus.

À l'aide du nom de la liste de préfixes, recherchez le numéro de séquence dans la route-map qui lui correspond.

leaf101# moquery -c rtmapRsRtDstAtt -f 'rtmap.RsRtDstAtt.tDn*"pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak"'
Total Objects shown: 1

# rtmap.RsRtDstAtt
tDn          : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak
childAction  :
dn           : sys/rpm/rtmap-2457603-shared-svc-leak/ent-1001/mrtdst/rsrtDstAtt-[sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak]
forceResolve : yes
lcOwn        : local
modTs        : 2019-12-24T11:17:08.668-05:00
rType        : mo
rn           : rsrtDstAtt-[sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak]
state        : formed
stateQual    : none
status       :
tCl          : rtpfxRule
tSKey        : IPv4-2949122-24-25-2457603-shared-svc-leak
tType        : mo

La sortie ci-dessus montre qu'il s'agit de l'entrée de route-map 1001. La dernière partie ici consiste à comprendre quel contrat était responsable de la création de l'entrée de route-map 1001 dans la route-map 2457603-shared-svc-leak. Ceci peut être interrogé sur la feuille de l'objet fvAppEpGCons.

leaf101# moquery -c fvAppEpGCons -f 'fv.AppEpGCons.dn*"rtmap-2457603-shared-svc-leak/ent-1001"'
Total Objects shown: 1

# fv.AppEpGCons
consDn       : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ap-ap1/epg-epg1]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]
childAction  :
descr        :
dn           : uni/ctxrefcont/ctxref-[sys/ctx-[vxlan-2457603]]/epgref-[uni/tn-jy/ap-ap1/epg-epg1]/epgpol-[sys/rpm/rtmap-2457603-shared-svc-leak/ent-1001]/epgcons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ap-ap1/epg-epg1]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]]
lcOwn        : local
modTs        : 2019-12-23T14:36:48.753-05:00
name         :
nameAlias    :
ownerKey     :
ownerTag     :
rn           : epgcons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ap-ap1/epg-epg1]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]]
status       :

Le résultat ci-dessus montre que le nom du contrat est « partagé », que le fournisseur epg est « tn-jy/ap-ap1/epg-epg1 » et que le consommateur l3out epg est « tn-jy/out-jy-ospf/instP-all »

Résumé

Routage fuité à partir du sous-réseau BD/EPG

Si l'indicateur « omniprésent » d'une route fuitée est défini dans « show ip route », elle est fuitée à partir d'un sous-réseau BD/EPG configuré. Les deux commandes suivantes peuvent être utilisées pour vérifier quelle relation contractuelle provoque une fuite. Ils seraient exécutés sur la feuille où la route est installée de manière inattendue.

Si le vrf où la route est fuitée de manière inattendue est le consommateur :
moquery -c ipCons -f 'ip.Cons.dn*« jy:vrf1/rt-\[10.100.100.0/24\]"' < : jy : vrf1 est le nom du vrf vers lequel la route est fuitée, la route est 10.100.100.0/24

Si le vrf où la route est fuitée de manière inattendue est le fournisseur :
moquery -c consNode -f 'cons.Node.dn*« 2949122 »' -f 'cons.Node.dn*« tn-jy/BD-bd1 »' <—2949122 est le nom virtuel du vrf vers lequel la route est fuitée, tn-jy/BD-bd1 est le nom du BD d'où le sous-réseau est configuré (dans le vrf duquel la route provient).

Route fuitée de L3out

Si la route fuitée est apprise via le processus interne iBGP du fabric et que l'exécution de vsh -c « show ip route x.x.x.x/y detail vrf <name>" montre une valeur rw-vnid non-nulle, alors la route est apprise à partir d'un l3out dans un autre vrf. La validation est la même, quel que soit le epg du consommateur et le fournisseur.

1. Identifiez la route-map d'importation des services partagés sur le processus bgp interne vrf :
show bgp process vrf jy:vrf2 | grep « Import route-map » < : jy : vrf2 est le vrf interne vers lequel la route est divulguée

2. Identifiez la liste de préfixes qui se trouve dans la route-map des services partagés qui correspond à la route fuitée :
moquery -c rtpfxEntry -f 'rtpfx.Entry.dn*« pfxlist-IPv4 ».*'2457603-shared-svc-leak »' | egrep « critères|dn|pfx|to PfxLen » <—2457603 est le vID du vrf interne dans cet exemple

3. Après avoir trouvé la ou les listes de préfixes qui font référence à la route, identifiez le numéro de séquence de la route-map qui fait référence à la ou aux listes :
moquery -c rtmapRsRtDstAtt -f 'rtmap.RsRtDstAtt.tDn*« pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak » < : pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak est le nom de la liste de préfixes

4. À l'aide de rtmap et du numéro d'entrée, exécutez la commande suivante pour savoir quelle relation de contrat a poussé cette entrée de route-map :
moquery -c fvAppEpGCons -f 'fv.AppEpGCons.dn*« rtmap-2457603-shared-svc-leak/ent-1001 »' < : rtmap-2457603-shared-svc-leak/ent-1001 est le nom et le numéro d'entrée de la route-map à l'étape 3.