Risoluzione dei problemi di perdita imprevista del percorso in ACI

Panoramica

ACI gestisce molte configurazioni di routing e switching tradizionalmente complesse attraverso l'implementazione di regole semplici. Tra queste funzionalità vi è la capacità di trafugare le rotte tra le VFR per facilitare la condivisione dei servizi. In genere, questa operazione richiede la definizione di destinazioni di route, la creazione di famiglie di indirizzi BGP, differenziatori di route e la replica di questa configurazione su più dispositivi.

All'interno di ACI la perdita di percorso viene gestita tramite la combinazione di contratti e l'impostazione di specifici flag condivisi sulle subnet. Tutta la configurazione tradizionale necessaria per risolvere le perdite di percorso viene gestita sul back-end come risultato della configurazione del contratto e della subnet condivisa.

Tuttavia, con questa configurazione astratta, può diventare più difficile identificare quale contratto sta effettivamente causando la perdita di un percorso. Ciò è particolarmente vero in ambienti con un gran numero di epg, vrf e contratti. In caso di perdita imprevista di una route tra le VFR, in che modo un amministratore può identificare la configurazione (contratto) che causa il problema?

Lo scopo di questo documento è quello di dimostrare come identificare la relazione contrattuale che causa la fuoriuscita di un percorso in ACI tra VRF. È utile conoscere già i concetti tradizionali di route-leaking, quali route-target e BGP VPNv4.

Software utilizzato

Tutti gli esempi riportati in questo documento sono basati sul software aci versione 4.2(3j).

Perché una subnet EPG/dominio bridge da VRF x è installata in VRF y?

In questa sezione verrà esaminato lo scenario in cui una subnet BD o EPG viene inaspettatamente resa a un altro file VRF. Affinché una subnet BD/EPG venga persa, è necessario configurare il flag "Condiviso tra VRF". La parte più difficile è capire quale contratto sta causando la diffusione di questo, in modo che questo è ciò che questa sezione affronterà.

Ad alto livello, questo è il flusso di lavoro per ciò che accade quando una subnet BD/EPG viene sfogliata tra vrf.

Figura 1.

*Notare che #3 è applicabile solo quando si annuncia un l3out condiviso. I numeri 1 e 2 vengono sempre applicati indipendentemente dal fatto che venga utilizzato un l3out condiviso o che i servizi condivisi siano interamente interni.

Prima di tutto, come può l'utente sapere se il percorso installato è trapelato come risultato di una subnet BD o EPG?

Quando si esegue il comando "show ip route vrf <nome>", il flag "pervasive" indica che la route è una subnet BD o EPG.

Ad esempio, nella topologia sopra riportata, questo valore viene visualizzato nella foglia del bordo del file vrf esterno (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 
       
     

È inoltre possibile visualizzare il file vrf di destinazione da cui la subnet è stata persa eseguendo il comando seguente:

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 
       
     

*(notare che le informazioni di attraversamento del vrf sono impostate indipendentemente dal fatto che il vrf di destinazione sia diverso dal vrf di ricerca).

Nell'output sopra riportato, il vnid di attraversamento VRF è impostato su 0x258003 o sul valore decimale 2457603. Come è possibile identificare il vrf di tale vnid 2457603?

Dall'APIC è sufficiente eseguire una query sull'oggetto fvCtx e sul filtro in base al segmento.

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

Come previsto, la route viene appresa dal file vrf2 vrf.

A questo punto, non è ancora chiaro quale contratto sia in uso, quale sia l'offerta di epg e quale sia l'opzione utilizzata da epg per installare il percorso. Per quanto riguarda il rapporto tra fornitore e consumatore, occorre tenere presenti alcune considerazioni:
1. Per un rapporto contrattuale inter-vrf, il contratto (e la conseguente regola di suddivisione in zone) è installato solo nel vrf del consumer epg. Di conseguenza, "show zoning-rule" nel file vrf del provider non visualizzerà la relazione.
2. Anche se il contratto è installato solo nel vrf consumer, il vrf provider deve ottenere il percorso per la subnet vrf BD consumer, il che significa che la foglia deve avere alcuni riferimenti di configurazione al contratto.

Identificare il contratto in caso di perdita inattesa del percorso al VRF consumer

L'oggetto ipCons nella foglia viene installato nella foglia che fa riferimento a...

a.) il percorso che viene perduto al vrf consumer

b) il contratto che stabilisce il rapporto

c.) gli epg fornitore e consumatore nella relazione.

Nell'output seguente, "jy:vrf1" è il file vrf consumer a cui viene persa la route e "10.100.100.0/24" è la route che viene trapelata.

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       :

Dall'output sopra riportato, il nome del contratto è "shared", il nome dell'epg consumer è l3out epg "uni/tn-jy/out-jy-ospf/instP-all" e il nome dell'epg provider è "uni/tn-jy/ap-ap1/epg-epg1".

Identificare il contratto in caso di perdita imprevista del percorso al VRF del provider

L'oggetto consNode viene installato nella foglia del file vrf del provider. Fa riferimento alla subnet BD nel file vrf consumer che viene divulgato, al contratto e all'interno della relazione. Prima di eseguire una query su questo oggetto, individuare la subnet BD in cui è configurato il percorso. A tale scopo, è possibile eseguire una query sull'oggetto fvSubnet nell'apic:

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

Il percorso è configurato nel dominio bridge tn-jy/BD-bd1. Utilizzare questa e l'ID del file vrf del provider (a cui la route sta perdendo) per eseguire il comando seguente.

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

Dall'output sopra riportato il nome del contratto è "shared", il nome dell'epg consumer è "uni/tn-jy/ap-ap1/epg-epg1" e il nome dell'epg provider è l3out "tn-jy/out-jy-ospf/instP-all".

Identificare il contratto quando la route viene persa in modo imprevisto da un contratto vzAny consumato

L'esempio di vzAny sarà identico, dal punto di vista della verifica, a un tradizionale rapporto fornitore / consumatore. Gli esempi riportati di seguito illustrano semplicemente l'aspetto che avrebbe. Si noti che un contratto inter-vrf è supportato solo se il cliente è vzAny.

vzAny Esempio 1: Instradamento inatteso alla VRF consumer

Analogamente al primo esempio in cui è stata eseguita la verifica nel file vrf consumer, l'oggetto ipCons verrà utilizzato di nuovo.

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       :

Dall'output sopra riportato il nome del contratto è "shared", l'epg consumer è vrf1 vzAny "tn-jy/ctx-vrf1/any" e il provider epg è "uni/tn-jy/ap-ap1/epg-epg1".

vzAny Esempio 2: Route non prevista al VRF del provider

Analogamente al secondo esempio in cui è stata eseguita la verifica nel file vrf del provider, l'oggetto consNode verrà utilizzato di nuovo. Ricordarsi di ottenere il nome bd del BD in cui è configurata la subnet trafugata e il vnid del vrf in cui è trapelata.

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

Dall'output sopra riportato, il nome del contratto è "shared", l'epg del consumatore è vrf2 vzAny "tn-jy/ctx-vrf2/any" e il provider epg è l3out "tn-jy/out-jy-ospf/instP-all".

Perché un percorso esterno da VRF y è installato in VRF x?

Ad alto livello, questo è il flusso di lavoro per ciò che accade quando una route l3out appresa (esterna) viene persa tra vrfs.

Figura 2.

Come si può vedere sopra, il file vrf interno (vrf2 in questo caso) installa un'importazione route-target che corrisponde al file vrf1. Installa inoltre una mappa di importazione nel processo bgp che deve avere voci di elenco di prefissi corrispondenti a tutto ciò che è definito nell'output l3out e che ha il flag "shared route control subnet" selezionato.

Indipendentemente da quale sia il fornitore o il consumatore, le fasi di verifica sono le stesse in quanto il contratto è sempre responsabile dell'importazione della route-target e degli elenchi di prefissi corrispondenti che perderanno le route da installare.

Prima di tutto, verificare che il percorso venga effettivamente appreso tramite 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 
       
     

Nell'esempio precedente, il fatto che venga appreso dal processo bgp della struttura puntando a un'altra foglia nella sovrapposizione indica che questo proviene da un l3out.

Eseguire le informazioni seguenti per ottenere ulteriori informazioni sul file vrf da cui è stato appreso:

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 
       
     

Come mostrato in precedenza in questo documento, riscrivere il vnid 0x2d0002 / 2949122 è il vrf di destinazione. Il valore rw-vnid impostato su un valore diverso da zero in un esempio di route esterna indica che è stato appreso da un diverso file vrf. L'esecuzione di moquery -c fvCtx -f 'fv.Ctx.seg="2949122"' sull'apic indica che appartiene alla vrf1.

Individuare quindi le importazioni route-target e la route-map di importazione associata al processo 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

Il file VFR interno di cui sopra esporta e importa il proprio router di destinazione (65001:2457603). Sta anche importando 65001:2949122. La 2949122 RT corrisponde al vnid vrf che sta importando (vrf1). bgpRtCtrlMapP è il nome oggetto per la route-map di importazione che contiene gli elenchi di prefissi. bgpRttEntry è il nome dell'oggetto per la route-target di importazione.

Quindi, utilizzando il vnid della vrf interna che sta apprendendo le route vrf esterne, eseguire una query su tutti gli elenchi di prefissi installati nella route-map dei servizi condivisi.

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

Ogni voce deve corrispondere a una subnet esterna. L'attributo "accuracy / inprecise" indica se il flag "aggregate shared" è stato impostato sulla subnet esterna. Il prefisso 0.0.0.0/0 con il flag inesatto indica che corrisponderebbe a tutte le route più specifiche (di fatto tutte). Il prefisso 10.9.9.0/24 con il flag esatto indica che corrisponde solo a /24.

Trovare la voce (o le voci) che corrispondono alla route che viene persa in modo imprevisto. In questo caso, il prefisso è 10.9.9.1/32; nelle uscite precedenti, ai due prefissi corrisponderebbe un prefisso ent-2 e ent-3.

Utilizzando il nome prefisso-elenco, trovare il numero di sequenza nella route-map corrispondente.

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

L'output precedente mostra che questa è la voce route-map 1001. La parte finale è capire quale contratto è stato responsabile della creazione della voce 1001 della route-map all'interno della route-map 2457603-shared-svc-leak. È possibile eseguire una query sulla foglia dall'oggetto 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       :

L'output precedente mostra che il nome del contratto è "shared", il provider epg è "tn-jy/ap-ap1/epg-epg1" e il consumer l3out epg è "tn-jy/out-jy-ospf/instP-all"

Riepilogo

Rotta persa dalla subnet BD/EPG

Se su una route perduta è impostato il flag "pervasivo" in "show ip route", la route viene persa da una subnet BD/EPG configurata. I due comandi seguenti possono essere utilizzati per verificare quale relazione di contratto causa la perdita di informazioni. Verrebbero eseguite sulla foglia in cui il percorso è installato in modo imprevisto.

Se il file VRF in cui il percorso è stato inaspettatamente perso è il consumer:
moquery -c ipCons -f 'ip.Cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]"' <—jy:vrf1 è il nome del vrf a cui la route perde, la route è 10.100.100.0/24

Se il file vrf in cui la route è stata persa in modo imprevisto è il provider:
moquery -c consNode -f 'cons.Node.dn*"2949122"' -f 'cons.Node.dn*"tn-jy/BD-bd1"' <—2949122 è il vnid del vrf a cui è perduto il percorso, tn-jy/BD-bd1 è il nome del BD da cui è configurata la subnet (all'interno del vrf da cui è perduto il percorso).

Route persa da L3out

Se la route perduta viene appresa tramite il processo iBGP dell'infrastruttura interna e l'esecuzione di vsh -c "show ip route x.x.x/y detail vrf <name>" mostra un valore rw-vnid diverso da zero, la route viene appresa da un l3out in un'altra vrf. La convalida è la stessa indipendentemente da quale epg sia il consumer e quale sia il provider.

1. Identificare la route-map di importazione dei servizi condivisi nel processo bgp interno del file vrf:
show bgp process vrf jy:vrf2 | grep "Importa route-map" <—jy:vrf2 è la vrf interna verso la quale la route perde

2. Identificare l'elenco di prefissi all'interno della route-map dei servizi condivisi che corrisponde alla route perduta:
moquery -c rtpfxEntry -f 'rtpfx.Entry.dn*"pfxlist-IPv4'.*'2457603-shared-svc-leak"' | egrep "criteri|dn|pfx|toPfxLen" <—2457603 è il vnid della vrf interna in questo esempio

3. Dopo aver individuato gli elenchi di prefissi che fanno riferimento al percorso, identificare il numero di sequenza del percorso-mappa che fa riferimento agli elenchi:
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 è il nome dell'elenco di prefissi

4. Utilizzando la mappa percorso e il numero di voce, eseguire il comando seguente per individuare la relazione di contratto su cui è stata inserita la voce della mappa percorso:
moquery -c fvAppEpGCons -f 'fv.AppEpGCons.dn*"rtmap-2457603-shared-svc-leak/ent-1001"' <—rtmap-2457603-shared-svc-leak/ent-1001 è il nome della route-map e il numero di voce del passaggio 3.