Solución de problemas de fuga de ruta inesperada en ACI

Overview

ACI gestiona muchas configuraciones de routing y switching tradicionalmente complejas mediante la implementación de políticas sencillas. Entre estas funcionalidades está la capacidad de filtrar rutas entre vrfs para facilitar los servicios compartidos. Tradicionalmente, esto implicaba muchos pasos, como definir destinos de ruta, crear familias de direcciones BGP, distinguir rutas y replicar esta configuración en muchos dispositivos.

Dentro de la fuga de ruta de ACI se gestiona mediante la combinación de contratos y la configuración de indicadores compartidos específicos en subredes. Toda la configuración tradicional necesaria para que las filtraciones de rutas funcionen se gestiona en el motor como resultado del contrato y la configuración de subred compartida.

Sin embargo, con esta configuración abstraída, puede resultar más difícil identificar qué contrato está causando realmente una fuga de ruta. Esto es especialmente cierto en entornos con un gran número de epg, vrfs y contratos. Si se está filtrando una ruta inesperadamente entre vrfs, ¿cómo puede un administrador identificar qué configuración (contrato) está causando que esto ocurra?

El propósito de este documento es demostrar cómo identificar qué relación de contrato está causando que una ruta en ACI se filtre entre los VRF. Es útil estar familiarizado con conceptos tradicionales de fuga de rutas como route-target y BGP VPNv4.

Software utilizado

Todos los ejemplos de este documento se basan en el software 4.2(3j) de aci.

¿Por qué una subred de Bridge Domain / EPG de VRF x está instalada en VRF y?

Esta sección se centrará en el escenario en el que una subred BD o EPG se está filtrando inesperadamente a otro vrf. Para que se filtre una subred BD/EPG, se debe configurar el indicador "Compartido entre VRF". La parte más difícil es entender qué contrato está causando que esto se filtre, de modo que esta sección se ocupe de eso.

En un nivel alto, éste es el flujo de trabajo para lo que sucede cuando se filtra una subred BD / EPG entre vrfs.

Figura 1.

*Tenga en cuenta que el Nº 3 sólo se aplica cuando se anuncia un l3out compartido. Los números 1 y 2 siempre se aplican independientemente de si se utiliza un l3out compartido o si los servicios compartidos son totalmente internos.

En primer lugar, ¿cómo puede saber el usuario si la ruta instalada se filtra como resultado de una subred BD o EPG?

Al ejecutar el comando "show ip route vrf <name>", el indicador "omnipresente" indica que la ruta es una subred BD o EPG.

Por ejemplo, en la topología anterior esto se vería en la hoja de borde en el vrf externo (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 
       
     

Además, el vrf de destino del que se filtró la subred se puede ver ejecutando el siguiente comando:

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 
       
     

*(observe que la información de cruce de vrf se establece independientemente de si el vrf de destino es diferente del vrf de búsqueda).

En la salida anterior, el vnid de cruce de vrf se establece en 0x258003 o decimal 2457603. ¿Cómo se puede identificar el vrf que pertenece a vnid 2457603?

Desde el APIC, simplemente consulte el objeto fvCtx y el filtro según el segid.

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

Como se esperaba, la ruta se está aprendiendo del vrf2 vrf.

Todavía se desconoce en este punto qué contrato se está utilizando, así como qué epg está proporcionando y qué epg está consumiendo para hacer que esta ruta se instale. Hay un par de consideraciones que hay que recordar con respecto a la relación entre el proveedor y el consumidor:
1. Para una relación de contrato entre vrf, el contrato (y la regla de zonificación resultante) se instala solamente en el vrf del epg de consumidor. Como resultado, "show zoning-rule" en el proveedor vrf no mostrará la relación.
2. Aunque el contrato sólo está instalado en el vrf del consumidor, el vrf del proveedor debe obtener la ruta para la subred BD del vrf del consumidor, lo que significa que la hoja debe tener alguna referencia de configuración al contrato.

Identifique el contrato cuando la ruta se está filtrando inesperadamente al VRF del consumidor

El objeto ipCons de la hoja se instala en la hoja que hace referencia al...

a) la ruta que se está filtrando al vrf de consumidor

b) el contrato por el que se establece la relación

c.) el proveedor y el epg del consumidor en la relación.

En el siguiente resultado "jy:vrf1" es el vrf de consumidor al que se está filtrando la ruta y "10.100.100.0/24" es la ruta que se está filtrando.

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       :

De la salida anterior, el nombre del contrato es "shared", el epg del consumidor es l3out epg "uni/tn-jy/out-jy-ospf/instP-all" y el epg del proveedor es "uni/tn-jy/ap-ap1/epg-epg1".

Identifique el contrato cuando la ruta se está filtrando inesperadamente al VRF del proveedor

El objeto consNode se instala en la hoja en el vrf del proveedor. Hace referencia a la subred BD en el vrf de consumidor que se está filtrando, el contrato y los epg dentro de la relación. Antes de consultar este objeto, busque la subred BD donde se configura la ruta. Esto se puede hacer consultando el objeto fvSubnet en la 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

La ruta se configura en el dominio de puente tn-jy/BD-bd1. Utilice esto y el vnid del vrf del proveedor (al que se está filtrando la ruta) para ejecutar el siguiente comando.

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

De la salida anterior, el nombre del contrato es "shared", el epg del consumidor es "uni/tn-jy/ap-ap1/epg-epg1" y el epg del proveedor es l3out "tn-jy/out-jy-ospf/instP-all".

Identifique el contrato cuando un contrato consumado de vzAny está filtrando la ruta de forma inesperada

El ejemplo vzAny será idéntico desde la perspectiva de la verificación a una relación tradicional entre proveedor y consumidor. Los siguientes ejemplos simplemente demostrarán cómo sería esto. Tenga en cuenta que un contrato entre vrf sólo se admite con vzAny como consumidor.

vzAny Ejemplo 1: Ruta inesperadamente filtrada a VRF de consumidor

Al igual que en el primer ejemplo que se observó en el vrf de consumidor, se volverá a utilizar el objeto ipCons.

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       :

De la salida anterior, el nombre del contrato es "shared", el epg del consumidor es el vrf1 vzAny "tn-jy/ctx-vrf1/any" y el epg del proveedor es "uni/tn-jy/ap-ap1/epg-epg1".

vzAny Ejemplo 2: Ruta filtrada inesperadamente al VRF del proveedor

Al igual que en el segundo ejemplo, en el que se examinó dónde se realizó la verificación en el vrf del proveedor, se volverá a utilizar el objeto consNode. Recuerde obtener el nombre del BD donde se configura la subred filtrada y el valor del vrf al que se filtra.

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

De la salida anterior, el nombre del contrato es "shared", el epg del consumidor es el vrf2 vzAny "tn-jy/ctx-vrf2/any" y el epg del proveedor es l3out "tn-jy/out-jy-ospf/instP-all".

¿Por qué se instala una ruta externa de VRF y en VRF x?

A un nivel superior, éste es el flujo de trabajo para lo que sucede cuando se filtra una ruta l3out-learning (externa) entre vrfs.

Figura 2

Como se puede ver arriba, el vrf interno (vrf2 en este caso) instala una importación route-target que coincide con vrf1. También instala un mapa de importación en el proceso bgp que debería tener entradas de lista de prefijos que coincidan con todo lo definido en el l3out que tiene el indicador "subred de control de ruta compartida" seleccionado.

Independientemente de cuál sea el proveedor o consumidor, los pasos de verificación son los mismos porque el contrato siempre será responsable de causar la importación de route-target y las correspondientes listas de prefijos que filtrarán las rutas para que se instalen.

En primer lugar, valide que la ruta se está aprendiendo a través de 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 
       
     

En el ejemplo anterior, el hecho de que se aprenda del proceso fabric bgp que apunta a otra hoja en la superposición indica que esto vino de un l3out.

Ejecute la siguiente información para obtener más información sobre el vrf del que se aprendió:

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 
       
     

Como se muestra anteriormente en este documento, reescribir vnid 0x2d0002 / 2949122 es el vrf de destino. El valor rw-vnid que se establece en un valor distinto de cero en un ejemplo de ruta externa indica que esto se aprendió de un vrf diferente. Si se ejecuta moquery -c fvCtx -f 'fv.Ctx.seg="2949122" en el apic, se indicaría que pertenece a vrf1.

A continuación, busque las importaciones de route-target así como el route-map de importación que está asociado al proceso 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

El vrf interno anterior está exportando e importando su propio route-target (65001:2457603). También importa 65001:2949122. El 2949122 RT corresponde al vrf vnid que está importando (vrf1). bgpRtCtrlMapP es el nombre del objeto para el route-map de importación que contiene las listas de prefijos. bgpRttEntry es el nombre del objeto para el route-target de importación.

Luego, usando el vnid del vrf interno que está aprendiendo las rutas vrf externas, consulte todas las listas de prefijos que están instaladas dentro del route-map de servicios compartidos.

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

Cada entrada debe corresponder a una subred externa. El atributo "exacto / inexacto" indica si el indicador "agregado compartido" se estableció en la subred externa. El prefijo 0.0.0.0/0 con el indicador inexacto indica que coincidiría con todas las rutas más específicas (efectivamente, todo). El prefijo 10.9.9.0/24 con el indicador exacto indica que sólo coincidiría con ese /24.

Busque la entrada (o entradas) que coincide con la ruta que se está filtrando inesperadamente. En este caso, el prefijo es 10.9.9.1/32 sería coincidente con ent-2 y ent-3 en los resultados anteriores.

Con el nombre de lista de prefijos, busque el número de secuencia dentro del route-map que lo coincida.

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

El resultado anterior muestra que esto es la entrada de mapa de ruta 1001. La última parte aquí es para comprender qué contrato era responsable de crear la entrada de mapa de ruta 1001 dentro del mapa de ruta 2457603-shared-svc-leak. Esto se puede consultar en la hoja del objeto 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       :

El resultado anterior muestra que el nombre del contrato es "compartido", el epg del proveedor es "tn-jy/ap-ap1/epg-epg1" y el epg del consumidor l3out es "tn-jy/out-jy-ospf/instP-all"

Summary

Ruta filtrada de subred BD/EPG

Si una ruta filtrada tiene el indicador "ubicuo" establecido en "show ip route", se filtra de una subred BD/EPG configurada. Los dos comandos siguientes se pueden utilizar para verificar qué relación de contrato está causando que esto se filtre. Se ejecutarían en la hoja donde la ruta se instala inesperadamente.

Si el vrf donde se filtra la ruta inesperadamente es el consumidor:
moquery -c ipCons -f 'ip.Cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]"' <—jy:vrf1 es el nombre del vrf al que se filtra la ruta, la ruta es 10.100.100.0/24

Si el vrf donde se filtra la ruta inesperadamente es el proveedor:
moquery -c consNode -f 'cons.Node.dn*"2949122"' -f 'cons.Node.dn*"tn-jy/BD-bd1"' <—2949122 es el vnid del vrf al que se filtra la ruta, tn-jy/BD-bd1 es el nombre del BD donde se configura la subred (dentro del vrf desde el que se filtra la ruta).

Ruta filtrada desde L3out

Si la ruta filtrada se aprende a través del proceso de iBGP de entramado interno y se ejecuta vsh -c "show ip route x.x.x.x/y detail vrf <name>" muestra un valor rw-vnid distinto de cero, entonces la ruta se está aprendiendo de un l3out en otro vrf. La validación es la misma independientemente de cuál sea el consumidor de epg y cuál el proveedor.

1. Identifique el route-map de importación de servicios compartidos en el proceso bgp vrf interno:
show bgp process vrf jy:vrf2 | grep "Import route-map" <—jy:vrf2 es el vrf interno al que se filtra la ruta

2. Identifique la lista de prefijos que se encuentra dentro del route-map de servicios compartidos que coincide con la ruta filtrada:
moquery -c rtpfxEntry -f 'rtpfx.Entry.dn*"pfxlist-IPv4'.*'2457603-shared-svc-leak"' | egrep "Criteria|dn|pfx|toPfxLen" <—2457603 es el vnid del vrf interno en este ejemplo

3. Después de encontrar qué listas de prefijos hacen referencia a la ruta, identifique qué número de secuencia de mapa de ruta hace referencia a las listas:
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 es el nombre de la lista de prefijos

4. Con rtmap y entry number, ejecute el siguiente comando para averiguar qué relación de contrato impulsó esa entrada de route-map:
moquery -c fvAppEpGCons -f 'fv.AppEpGCons.dn*"rtmap-2457603-shared-svc-leak/ent-1001"' <—rtmap-2457603-shared-svc-leak/ent-1001 es el nombre y número de entrada del route-map desde el paso 3.