Onverwachte routelekkage voor probleemoplossing in ACI

Overzicht

ACI behandelt veel traditioneel complexe routing en switching configuraties door de implementatie van eenvoudig beleid. Een van deze functies is de mogelijkheid om routes tussen vrf's te lekken om gedeelde diensten te vergemakkelijken. Traditioneel werden hierbij veel stappen genomen, zoals het definiëren van routedoelen, het creëren van BGP-adresfamilies, routekaarten en het repliceren van deze configuratie over veel apparaten.

Binnen de ACI-route wordt het lekken verwerkt door middel van een combinatie van contracten en het instellen van specifieke gedeelde vlaggen op subnetten. Al de traditionele configuratie die nodig is om route-lekken werk te maken wordt op het backend behandeld als resultaat van het contract en gedeelde subnetconfiguratie.

Maar als deze configuratie niet is geabstracteerd, kan het steeds moeilijker worden om te identificeren welk contract er eigenlijk voor zorgt dat een route uitgelekt wordt. Dit geldt vooral voor omgevingen met grote aantallen epg's, vrf's en contracten. Als een route onverwacht tussen vrf's wordt uitgelekt, hoe kan een beheerder dan identificeren welke configuratie (contract) dit veroorzaakt?

Het doel van dit document is aan te tonen op welke wijze de contractuele relatie ertoe leidt dat een route in ACI tussen VRF’s wordt uitgelekt. Het is behulpzaam om al bekend te zijn met traditionele routeslekken concepten zoals routedoelstellingen en BGP VPNv4.

Gebruikte software

Alle voorbeelden in dit document zijn gebaseerd op aci-software 4.2(3j).

Waarom is een Brug Domein/EPG Subnet van VRF x geïnstalleerd in VRF y?

Deze paragraaf zal zich concentreren op het scenario waar een BD of EPG subster onverwacht naar een andere vrf wordt uitgelekt. Om BD / EPG te kunnen uitlekken moet de vlag "Gedeeld tussen VRFs" zijn ingesteld. Het moeilijkste is om te begrijpen welk contract ervoor zorgt dat dit uitgelekt wordt, zodat dit het onderwerp van dit hoofdstuk is.

Op een hoog niveau is dit de werkstroom voor wat er gebeurt wanneer een BD / EPG-subnet tussen vrf's uitgelekt wordt.

Afbeelding 1.

*Merk op dat #3 alleen van toepassing is wanneer je reclame maakt voor een gedeeld l3out. #1 en #2 zijn altijd van toepassing ongeacht of een gedeeld l3out wordt gebruikt of de gedeelde services volledig intern zijn.

Om te beginnen, hoe kan de gebruiker weten of de geïnstalleerde route als resultaat van een BD of EPG subnet wordt uitgelekt?

Wanneer het uitvoeren van "show ip route vrf <name>" de "wijdverspreide" vlag aangeeft dat de route een BD of EPG subtype is.

Bijvoorbeeld, in de bovenstaande topologie zou dit op het grensblad in het externe vrf (vrf1) worden gezien:

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 
       
     

Daarnaast kan de bestemming vrf die van Subnet werd uitgelekt worden bekeken door de volgende opdracht uit te voeren:

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 
       
     

* ( noteer dat de informatie over de oversteek van het vrf is ingesteld ongeacht of de bestemming vrf verschilt van de lookup vrf ) .

In het bovenstaande resultaat is de oversteek van de vrf ingesteld op 0x258003 of decimaal 2457603. Hoe kan het vrf dat vnid 2457603 omvat, worden geïdentificeerd?

Via APIC wordt het fvCtx-object en -filter gewoon gevraagd op basis van het segment.

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

Zoals verwacht wordt de route geleerd van het vrf2 vrf.

Op dit moment is nog niet bekend welke contracten worden gebruikt en welke epg's levert en welke epg's gebruikt om deze route te laten installeren. Er zijn een paar overwegingen die in het achterhoofd moeten worden gehouden met betrekking tot de relatie tussen leverancier en consument:
1. Voor een intervrf-contractuele relatie wordt de overeenkomst (en de daaruit voortvloeiende zonegeregel) alleen in de vrf van de verbruiker aangebracht. Als resultaat hiervan zal "show zoning-Rule" in de provider vrf de relatie niet tonen.
2. Ook al is de overeenkomst alleen in het vrf van de consument geïnstalleerd, de aanbieder van Vrf moet de route voor de BD van de consument ontvangen, wat betekent dat het blad enige configuratieverwijzing naar het contract moet hebben.

Identificeer het contract wanneer de route onverwacht wordt uitgelekt naar de consument VRF

Het voorwerp van ipCons op het blad is geïnstalleerd op het blad wat verwijzingen...

a ) de route die naar de consument wordt uitgelekt

b) de overeenkomst waarbij de relatie wordt aangegaan

c . ) de aanbieder en de consument van epg ' s in de relatie .

In de onderstaande output "jy:vrf1" is de consumentenzender vrf dat de route wordt uitgelekt naar en "10.100.100.0/24" is de route die wordt uitgelekt.

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       :

Uit de bovenstaande output blijkt dat de contractnaam "gedeeld" is, de verbruiker-epg is l3out per "uni/tn-jy/out-jy-ospf/AgainstP-all" en de provider-epg is "uni/tn-jy/ap-ap1/epg-epg1".

Identificeer het contract wanneer de route onverwacht naar de VRF wordt uitgelekt

Het object consNode is op het blad van de provider vrf geïnstalleerd. Het verwijst naar het BD-subnet in de consumentenvrf die wordt uitgelekt, het contract, en de epg's binnen de relatie. Alvorens dit object te vragen, vindt u het BD-type waar de route is ingesteld. Dit kan worden gedaan door het object fvSubnet in de apic te verkennen:

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

De route is ingesteld in het tn-jy/BD-bd1 brugdomein. Gebruik dit en de vnid van de provider vrf (dat de route uitgelekt wordt) om de onderstaande opdracht te volgen.

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

Uit de bovenstaande output wordt de contractnaam "gedeeld", is de verbruiker-epg "uni/tn-jy/ap-ap1/epg-epg1" en is de provider-epg l3out "tn-jy/out-jy-ospf/AgainstP-all".

Identificeer het contract wanneer de route onverwacht wordt uitgelekt door een verbruikte VzElk contract

De vzElk voorbeeld zal vanuit het oogpunt van verificatie identiek zijn aan een traditionele relatie tussen leverancier en consument. De onderstaande voorbeelden tonen alleen maar aan hoe dit eruit zou zien. Merk op dat een intervrf-contract alleen met de vzAny als consument wordt ondersteund.

VzAny Voorbeeld 1: Route onverwachts uitgelekt naar consument VRF

Evenals bij het eerste voorbeeld werd gekeken naar de plaats waar de verificatie in het vrf van de consument werd verricht, zal het ipCons-object opnieuw worden gebruikt.

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       :

Uit de bovenstaande output wordt de contractnaam "gedeeld", is de verbruiker-epg de vrf1 vzAny "tn-jy/ctx-vrf1/any" en is de provider-epg "uni/tn-jy/ap-ap1/epg-epg1".

VzAny Voorbeeld 2: Route onverwachts uitgelekt naar provider VRF

Overeenkomstig het tweede voorbeeld werd gekeken naar waar verificatie werd verricht in de provider vrf, dan zal het consNode-object opnieuw worden gebruikt. Denk eraan om de naam van de BD te krijgen, waar het gelekte net wordt ingesteld en de vnid van de vrf waaraan het is gelekt.

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

Uit de bovenstaande output wordt de contractnaam "gedeeld", is de verbruiker-epg de vrf2 vzAny "tn-jy/ctx-vrf2/any" en is de provider-epg l3out "tn-jy/out-ospf/AgainstP-all".

Waarom is een externe route van VRF door geïnstalleerd in VRF x?

Op een hoog niveau is dit de werkstroom voor wat er gebeurt als een l3out-geleerde (externe) route uitgelekt wordt tussen vrf's.

Afbeelding 2.

Zoals hierboven te zien is, installeert interne vrf (vrf2 in dit geval) een route-target import die overeenkomt met vrf1. Het installeert ook een importkaart op het bgp-proces dat prefix-lijst-items moet hebben die alles wat in l3out gedefinieerd is en die de "gedeelde routecontrolenet" vlag heeft geselecteerd.

Ongeacht de vraag welke epg de leverancier of de consument is, zijn de controlestappen hetzelfde, omdat het contract altijd verantwoordelijk zal zijn voor het veroorzaken van de routedoelinvoer en de corresponderende voorrangslijsten, die de te installeren routes zullen lekken.

Bevestig om te beginnen dat de route in feite geleerd wordt door een 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 
       
     

In het bovenstaande voorbeeld geeft het feit dat het geleerd is van het bgp-proces van het weefsel dat wijst op een ander blad in de overlay aan dat dit het resultaat was van een l3out.

Draai de volgende informatie om meer informatie te krijgen over welke vrf het is geleerd:

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 
       
     

Zoals eerder in dit document wordt getoond, is herschrijven van vnid 0x2d002 / 2949122 de bestemming vrf. De rw-vnid waarde die op een niet-nulwaarde in een extern routevoorbeeld wordt ingesteld, geeft aan dat dit van een andere vrf is geleerd. Wanneer moquery -c fvCtx -f'fv.Ctx.seg="2949122" op de apic wordt uitgevoerd, zou dat betekenen dat dit tot vrf1 behoort.

Vind vervolgens de route-target-import en de importroutekaart die gekoppeld is aan het bgp-proces.

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

De hierboven genoemde interne Vrf exporteert en importeert zijn eigen routedoel (65001:2457603). Het land importeert ook 65001:2949122. De RT van 294912 komt overeen met de Vrf vnid die het importeert (vrf1). bgpRtCtrlMapP is de objectnaam voor de importroutekaart die de prefix-lijsten bevat. bgpRttEntry is de objectnaam voor de importroute-target.

Daarna, met behulp van het vnid van de interne vrf die de externe vrf routes leert, vraag alle voorvoegsellijsten die binnen de gedeelde route-kaart van de services zijn geïnstalleerd.

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

Elke ingang zou met externe vorm moeten overeenkomen. De eigenschap "exact / inexact" geeft aan of de "geaggregeerde gedeelde" vlag op het externe net was ingesteld. Het voorvoegsel 0.0.0.0/0 bij de onnauwkeurige markering geeft aan dat het overeenkomt met alle routes die specifieker zijn (effectief alles). Het voorvoegsel van 10.9.9.0/24 met de exacte vlag geeft aan dat het alleen overeenkomt met dat /24.

Vind de ingang (of de ingangen) die de route aanpast die onverwacht wordt uitgelekt. In dit geval is het voorvoegsel 10.9.9.1/32 in de bovenstaande uitgangen gelijk aan ent-2 en ent-3.

Gebruik de voorvoegsel-lijst naam, vind het sequentienummer binnen de route-kaart die het aanpast.

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

De bovenstaande output laat zien dat dit een routekaart-ingang van 1001 is. Het laatste deel hier is om te begrijpen welk contract verantwoordelijk was voor het creëren van route-kaart-ingang 1001 binnen de routekaart-2457603-gedeeld-svc-lek. Dit kan op het blad van het voorwerp fvAppEpGCons worden gevraagd.

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       :

Bovenstaande output laat zien dat de contractnaam "gedeeld" is, de provider epg "tn-jy/ap-ap-ap1/epg-epg1" en de consumentennaam l3out epg "tn-jy/out-jy-ospf/Against-all" is

Samenvatting

Uitgelekt vanuit BD / EPG-subnet

Als een uitgelekte route de "wijdverspreide" vlag in "tonen ip route" heeft dan wordt het uitgelekt van een BD/EPG subtype ingesteld. De volgende twee opdrachten kunnen worden gebruikt om te controleren welke contractrelatie ervoor zorgt dat dit wordt gelekt. Ze zouden worden gerund op het blad waar de route onverwacht is geïnstalleerd.

Indien de vrf waar de route onverwacht wordt uitgelekt, de consument is:
moquery -c ipCons -f 'ip.Cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]" <—jy:vrf1 is de naam van vrf de route is uitgelekt naar, de route is 10.100.100.0/24

Als de Vrf waar de route onverwacht is uitgelekt de leverancier is:
moquery -c consNode -f'cons.Node.dn*"2949122" -f'cons.Node.dn*"tn-jy/BD-bd1" <-2949122 is de vnid van de vrf waar de route naar is uitgelekt, is tn-jy/BD-bd1 de naam van de BD waar het net is ingesteld (binnen de vrf is de route uitgelekt).

Uitgelekt vanuit L3out

Als de uitgelekte route via het interne iBGP-proces van het weefsel wordt geleerd en vsh-c "show ip route x.x.x.x/y detail vrf <name>" toont een niet-nulwaarde rw-waarde dan wordt de route geleerd van een l3out in een andere vrf. De validatie is hetzelfde ongeacht welke epg de consument is en welke aanbieder.

1. Vermeld de routekaart voor de invoer van gedeelde diensten op het interne vrf-bgp-proces:
Bgp-proces vrf jy:vrf2 tonen | grip "Uitvoerroutekaart" <—jy:vrf2 is de interne vrf waarop de route is uitgelekt

2. Identificeer de prefix-lijst die binnen de gedeelde route-kaart is die overeenkomt met de uitgelekte route:
moquery -c rtpfxEntry-f 'rtpfx.Entry.dn*"pfxlist-IPv4".*'2457603-svc-leak" | Voorschrift "criteria |dn|pfx|toPfxLen" <—2457603 is de vnid van het interne vrf in dit voorbeeld

3. Na het vinden van welke voorvoegsellijst(en) verwijzen naar de route, identificeer dan het nummer van de routekaart-reeks van de lijst(en):
moquery -c rtmapRsDstAtt -f 'rtmap.rsRtDstAtt.n*'"pfxlist-IPv4-2949122-24-25-2457603-svc-leak" <—pfxlist-IPv4-2949122-24-25-2457603-gedeeld-svc-leak is de naam van de voorvoegsel-lijst

4. Met behulp van het scenario en entry number voert u de volgende opdracht uit om uit te zoeken welke contract relatie op die route-map-ingang duwde:
moquery -c fvAppEpGCons -f'fv.AppEpGCons.dn*"rtmap-2457603-svc-lek/ent-1001" <—rtmap-2457603-gedeeld-svc-lek/ent-1001 is de route-map-naam en registratienummer van stap 3.