Hello   You can query this information with the following command:   moquery -c infraAttEntityP -x 'query-target-filter=eq(infraAttEntityP.name,"<AEP-NAME>") rsp-subtree=full rsp-subtree-class=infraRtAttEntP' Or you can also query direct for the infraRtAttEntP: moquery -c infraRtAttEntP -f 'infra.RtAttEntP.dn*"attentp-<AEP-NAME>/"' | grep tDn   You have to replace <AEP-NAME> with the name of your AEP. For example to get all Policy-Groups which have the AEP "AEP-TEST" configured:   moquery -c infraAttEntityP -x 'query-target-filter=eq(infraAttEntityP.name,"AEP-TEST") rsp-subtree=full rsp-subtree-class=infraRtAttEntP' moquery -c infraRtAttEntP -f 'infra.RtAttEntP.dn*"attentp-AEP-TEST/"' | grep tDn   HTH Marcel ... View more

Hi    You can query the ethpmPhysIf MO and check the "operSt"-attribut (up/down). For example via moquery to get all "down" interfaces: moquery -c ethpmPhysIf -x 'query-target-filter=eq(ethpmPhysIf.operSt,"down") order-by=ethpmPhysIf.dn|asc' | egrep "dn|operSt\b"   Or check the l1PhysIf MO - all unused ports usually report a usage of "discovery": moquery -c l1PhysIf -x 'query-target-filter=eq(l1PhysIf.usage,"discovery") order-by=l1PhysIf.dn|asc' | egrep "dn|discovery"   HTH Marcel ... View more

Hi    The L3out configured with SVIs is correct. Also configuring your "SVI-IP" as a secondary address. But your "physical IP" must be the same for all ports on the same leaf. Leaf-111 eth1/5 IP:  10.1.1.11/24 Secondary-IP: 10.1.1.10/24 Leaf-111 eth1/6 IP: 10.1.1.11/24 Secondary-IP: 10.1.1.10/24   You must change the interface IP only if you connect the FW on another leaf - for example if the FW members are connected on leaf-111 and leaf-112 then the IP will change: Leaf-111 eth1/5 IP:  10.1.1.11/24 Secondary-IP: 10.1.1.10/24 Leaf-112 eth1/5 IP: 10.1.1.12/24 Secondary-IP: 10.1.1.10/24   HTH Marcel       ... View more

Hi Yoann   Because the wcard-Filter is not working with the fvCEp.ip attribute you can use ge and le filters: GET https://APIC/api/class/fvCEp.json?query-target-filter=and(ge(fvCEp.ip,"192.168.0.0"),le(fvCEp.ip,"192.168.255.255")) HTH Marcel ... View more

In a LB-PBR scenario your VIPs will typically be part of the LB-service BD itself, so the VIP-subnet is directly connected to ACI. Have a look at the following whitepaper: https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739971.html   HTH     ... View more

Hi   I would recommend to go for preferred group. vzAny is okay if you do a permit-any kind of design (aka network centric design) - but as soon as you want to apply some more granular polices in the same VRF you might put yourself in a dead end situation.   If you work with a preferred group it's pretty easy: All EPGs inside the preferred group are able to communicate without a contract. EPGs outside of the preferred group must have contracts in place. Also if communication between a EPG outside of the preferred group and a EPG inside the group is needed, a contract must be in place.   Just remeber: the preferred group is not an object, it's just a way how to configure permit statements - so you can't configure a contract between an non preferred group epg (let's assume the name of this EPG is "EPG-X") and the preferred group itself. Instead you must apply a contract between EPG-X and each and every EPG inside the preffered group to which EPG-X must be able to communicate.   Also have a look at the restrictions (for instance if you do transit routing): https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_APIC_Contract_Preferred_Group.html   HTH     ... View more