06-10-2021 01:17 PM
Hello all,
If I have an IP address, and that IP address maps to a single physical port, I can use classes like fvCEp to find the physical port where that IP address resides. However, what if, unbeknownst to me, the IP address is coming not from a single physical port, but from a VPC interface. Is there a class I can search with moquery to find that that IP address belongs to a VPC interface?
Basically, if I know a given IP address, is there a way I can use moquery to find the interface location for that IP address if the interface location is a VPC interface?
For example, say I have IP address 192.168.1.1 and I can't find the physical port location using the fvCEp class, so on the APIC I do a show endpoints ip 192.168.1.1 and the output of that command shows me that the interface is vpc VPC-SERVER1 . Is there a class I could have searched on with moquery to find that the 192.168.1.1 IP address belonged to a VPC interface? Or would I have to do something fancy with the vpc "port block" objects ( infraPortBlk ) maybe, or ?
Solved! Go to Solution.
06-11-2021 09:23 AM
Hi @vv0bbLeS
The command which I mentioned works for all type of interfaces, including vPCs:
apic1# moquery -c fvCEp -f 'fv.CEp.ip=="11.11.11.11"' -x rsp-subtree=children | grep dn dn : uni/tn-MyTenant/ap-AP1/epg-EPG_VLAN100/cep-8C:60:4F:AC:1D:42 dn : uni/tn-MyTenant/ap-AP1/epg-EPG_VLAN100/cep-8C:60:4F:AC:1D:42/rscEpToPathEp-[topology/pod-1/protpaths-102-110/pathep-[vpc_if]] dn : uni/tn-MyTenant/ap-AP1/epg-EPG_VLAN100/cep-8C:60:4F:AC:1D:42/ip-[11.11.11.11] apic1# show endpoints ip 11.11.11.11 Legends: (P):Primary VLAN (S):Secondary VLAN Dynamic Endpoints: Tenant : MyTenant Application : AP1 AEPg : EPG_VLAN100 End Point MAC IP Address Source Node Interface Encap Multicast Address Create TS ----------------- ---------------------------------------- ------------ ---------- ------------------------------ --------------- --------------- -------------------- 8C:60:4F:AC:1D:42 11.11.11.11 learned 102 110 vpc vpc_if vlan-111 not-applicable 2021-06-11T19:16:22. 795+03:00 Total Dynamic Endpoints: 1 Total Static Endpoints: 0
It looks like you have a different problem there.
What version do you run in your fabric?
Sergiu
06-14-2021 08:08 AM
@Sergiu.Daniluk ah ok interesting, glad to know it works for vPC's also! And my fabric is running 4.2(7f) currently!
I tried what @Robert Burns suggested (thanks!) and tried the fvIp class, which I guess is a child of the fvCEp class. Interestingly, I was able to find my 192.168.1.1 address that way:
apic1# moquery -c fvIp -f 'fv.Ip.addr=="192.168.1.1"' Total Objects shown: 1 # fv.Ip addr : 192.168.1.1 annotation : childAction : createTs : 1969-12-31T19:00:00.000-05:00 debugMACMessage : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/ip-[192.168.1.1] extMngdBy : flags : lcOwn : local modTs : 2019-08-24T06:14:37.256-05:00 monPolDn : uni/tn-common/monepg-default rn : ip-[192.168.1.1] status : uid : 0
So, I decided to take the MAC address of that endpoint (in bold above) and try looking for the fvCEp object by the mac address, not the IP:
apic1# moquery -c fvCEp -f 'fv.CEp.mac=="00:01:02:AA:BB:CC"' Total Objects shown: 1 # fv.CEp name : 00:01:02:AA:BB:CC annotation : childAction : contName : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC encap : vlan-196 extMngdBy : id : 0 idepdn : ip : 192.168.1.2 lcC : learned lcOwn : local mac : 00:01:02:AA:BB:CC mcastAddr : not-applicable modTs : 2021-03-17T22:17:54.678-05:00 monPolDn : uni/tn-common/monepg-default nameAlias : rn : cep-00:01:02:AA:BB:CC status : uid : 0 uuid : vmmSrc :
Interestingly, we can see it found an fvCEp object, but notice the IP address is different (192.168.1.2 , instead of .1).
Being fully intrigued, I then tried the query again, but this time included all the child objects in the response:
apic1# moquery -c fvCEp -f 'fv.CEp.mac=="00:01:02:AA:BB:CC"' -x rsp-subtree=children Total Objects shown: 1 # fv.CEp name : 00:01:02:AA:BB:CC annotation : childAction : contName : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC encap : vlan-196 extMngdBy : id : 0 idepdn : ip : 192.168.1.2 lcC : learned lcOwn : local mac : 00:01:02:AA:BB:CC mcastAddr : not-applicable modTs : 2021-03-17T22:17:54.678-05:00 monPolDn : uni/tn-common/monepg-default nameAlias : rn : cep-00:01:02:AA:BB:CC status : modified uid : 0 uuid : vmmSrc : # fv.Ip addr : 192.168.1.2 annotation : childAction : createTs : 1969-12-31T19:00:00.000-05:00 debugMACMessage : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/ip-[192.168.1.2] extMngdBy : flags : lcOwn : local modTs : 2021-03-17T22:17:54.678-05:00 monPolDn : uni/tn-common/monepg-default rn : ip-[192.168.1.2] status : uid : 0 # fv.RsCEpToPathEp tDn : topology/pod-1/protpaths-223-224/pathep-[VPC-MX7000-PROD-DELL01-MGMT01] childAction : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/rscEpToPathEp-[topology/pod-1/protpaths-223-224/pathep-[VPC-MX7000-PROD-DELL01-MGMT01]] forceResolve : yes lcC : learned lcOwn : local modTs : 2021-04-21T07:53:09.310-05:00 rType : mo rn : rscEpToPathEp-[topology/pod-1/protpaths-223-224/pathep-[VPC-MX7000-PROD-DELL01-MGMT01]] state : formed stateQual : none status : tCl : fabricAPathEp tType : mo # fv.Ip addr : 192.168.1.1 annotation : childAction : createTs : 1969-12-31T19:00:00.000-05:00 debugMACMessage : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/ip-[192.168.1.1] extMngdBy : flags : lcOwn : local modTs : 2019-08-24T06:14:37.256-05:00 monPolDn : uni/tn-common/monepg-default rn : ip-[192.168.1.1] status : uid : 0
So, you can see that I have 2 child fvIp objects under a single fvCEp object, and one of those child fvIp objects has my IP in question!
The host behind that MAC address is doing some virtualization, so perhaps that explains the 2 IP address using a single MAC address?
But anyway, mystery solved I guess, but still very strange! I would have expected an fvCEp object to be created for every IP endpoint, but perhaps there is some nuance to creating an fvCEp object that I'm not aware of, and somehow this situation didn't qualify for a second fvCEp object (maybe because every fvCEp object is "keyed" with the mac address, so in this situation a single MAC address means only 1 fvCEp object, and any "extra" IP addresses are created as additional fvIp child objects).
Also, thanks @RedNectar for your suggestion on naming VPC's with leaf and port number! That is a very good idea! I will check out that link you posted. That naming convention would be very useful in a time like this! :- D
Again, thanks everyone for your time in responding! This really is a very strong ACI group, and your suggestions were very helpful and led me down the right path to a solution! Woo! I'm excited to keep learning, and would like to become one of the "elite" ACI members in this group one day :- D
06-11-2021 12:54 AM - edited 06-11-2021 12:55 AM
Hi @vv0bbLeS
I believe this is what you are looking for:
moquery -c fvCEp -f 'fv.CEp.ip=="X.X.X.X"' -x rsp-subtree=children
EDIT: of course you should add some (e)grep to filter the interface.
Stay safe,
Sergiu
06-11-2021 05:17 AM
If you want to look at all the VPC TEP IPs you can use:
moquery -c dhcpClient -f 'dhcp.Client.nodeRole=="vip"' |egrep 'dn|ip'
Robert
06-11-2021 05:37 AM - edited 06-11-2021 05:37 AM
Gentlemen, thank you for your replies! In this case, I'm not looking for the TEP IP addresses, and in my OP, I mentioned that in this particular case, I am unable to find the IP address using the fvCEp class for some reason. Take this output for example:
apic1# apic1# moquery -c fvCEp -f 'fv.CEp.ip=="192.168.1.1"' No Mos found apic1# apic1# apic1# apic1# apic1# show endpoints ip 192.168.1.1 Legends: (P):Primary VLAN (S):Secondary VLAN Dynamic Endpoints: Tenant : MY-TENANT Application : MY-APPLICATION-PROFILE AEPg : VLAN-196 End Point MAC IP Address Source Node Interface Encap Multicast Address ----------------- ------------ -------- -------- ---------------- --------- --------------- 01:02:03:AA:BB:CC 192.168.1.1 learned 223 224 vpc VPC-SERVER1 vlan-196 not-applicable Total Dynamic Endpoints: 1 Total Static Endpoints: 0 apic1# apic1#
As you can see, the fvCEp query returns no results on that IP address, however the show endpoints ip x.x.x.x command returns the information. To be sure I wasn't running my fvCEp query incorrectly, I have also dumped all fvCEp objects whose encap is vlan-196 and manually scrolled the list searching for 192.168.1.1 but it is not in the list.
So, I guess my question is mainly about what class could I use to search and find and IP endpoint if that endpoint is behind a VPC interface?
Thanks again!
06-11-2021 09:23 AM
Hi @vv0bbLeS
The command which I mentioned works for all type of interfaces, including vPCs:
apic1# moquery -c fvCEp -f 'fv.CEp.ip=="11.11.11.11"' -x rsp-subtree=children | grep dn dn : uni/tn-MyTenant/ap-AP1/epg-EPG_VLAN100/cep-8C:60:4F:AC:1D:42 dn : uni/tn-MyTenant/ap-AP1/epg-EPG_VLAN100/cep-8C:60:4F:AC:1D:42/rscEpToPathEp-[topology/pod-1/protpaths-102-110/pathep-[vpc_if]] dn : uni/tn-MyTenant/ap-AP1/epg-EPG_VLAN100/cep-8C:60:4F:AC:1D:42/ip-[11.11.11.11] apic1# show endpoints ip 11.11.11.11 Legends: (P):Primary VLAN (S):Secondary VLAN Dynamic Endpoints: Tenant : MyTenant Application : AP1 AEPg : EPG_VLAN100 End Point MAC IP Address Source Node Interface Encap Multicast Address Create TS ----------------- ---------------------------------------- ------------ ---------- ------------------------------ --------------- --------------- -------------------- 8C:60:4F:AC:1D:42 11.11.11.11 learned 102 110 vpc vpc_if vlan-111 not-applicable 2021-06-11T19:16:22. 795+03:00 Total Dynamic Endpoints: 1 Total Static Endpoints: 0
It looks like you have a different problem there.
What version do you run in your fabric?
Sergiu
06-11-2021 07:32 AM
You can use the following API call:
/api/node/class/fvIp.json?query-target-filter=and(eq(fvIp.addr,"192.168.1.1"))&order-by=fvIp.modTs|desc
Uses the fvIp class instead
Robert
06-11-2021 03:01 PM - edited 06-11-2021 03:01 PM
Hi @vv0bbLeS ,
Oh what a frustrating problem you have! Which is basically that ACI identifies VPCs via the VPC Interface Policy Group, which is one of the reasons I recommend a naming scheme (search for it) that includes the switch and interface identifiers in the name. So on my system:
apic1# moquery -c fvIp -f 'fv.Ip.addr=="10.208.12.200"' | grep fabricPathDn fabricPathDn : topology/pod-1/paths-2202/pathep-[T08:L1201..1202:1:38:1_VPCIPG] apic1# show endpoints ip 10.208.12.200 | egrep -i "Node|vpc" End Point MAC IP Address Source Node Interface Encap Multicast Address Create TS 00:50:56:8A:F8:32 10.208.12.200 learned 2201 2202 vpc T08:L1201..1202:1:38:1_VPCIPG vlan-2084 not-applicable 2021-06-11T21:47:56.
and the other variations offered here that show only the Interface name have the information you need shown in the name.
Now. Back to your problem.
Given that you can use any of the suggestions here (including your own observation that show endpoints only gives you the name of the VPC, what we need is a way of extracting the physical ports of the VPC from the name of the interface policy group.
I don't have time to research that now, but maybe some of the other contributors may be able to build on this idea.
06-14-2021 08:08 AM
@Sergiu.Daniluk ah ok interesting, glad to know it works for vPC's also! And my fabric is running 4.2(7f) currently!
I tried what @Robert Burns suggested (thanks!) and tried the fvIp class, which I guess is a child of the fvCEp class. Interestingly, I was able to find my 192.168.1.1 address that way:
apic1# moquery -c fvIp -f 'fv.Ip.addr=="192.168.1.1"' Total Objects shown: 1 # fv.Ip addr : 192.168.1.1 annotation : childAction : createTs : 1969-12-31T19:00:00.000-05:00 debugMACMessage : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/ip-[192.168.1.1] extMngdBy : flags : lcOwn : local modTs : 2019-08-24T06:14:37.256-05:00 monPolDn : uni/tn-common/monepg-default rn : ip-[192.168.1.1] status : uid : 0
So, I decided to take the MAC address of that endpoint (in bold above) and try looking for the fvCEp object by the mac address, not the IP:
apic1# moquery -c fvCEp -f 'fv.CEp.mac=="00:01:02:AA:BB:CC"' Total Objects shown: 1 # fv.CEp name : 00:01:02:AA:BB:CC annotation : childAction : contName : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC encap : vlan-196 extMngdBy : id : 0 idepdn : ip : 192.168.1.2 lcC : learned lcOwn : local mac : 00:01:02:AA:BB:CC mcastAddr : not-applicable modTs : 2021-03-17T22:17:54.678-05:00 monPolDn : uni/tn-common/monepg-default nameAlias : rn : cep-00:01:02:AA:BB:CC status : uid : 0 uuid : vmmSrc :
Interestingly, we can see it found an fvCEp object, but notice the IP address is different (192.168.1.2 , instead of .1).
Being fully intrigued, I then tried the query again, but this time included all the child objects in the response:
apic1# moquery -c fvCEp -f 'fv.CEp.mac=="00:01:02:AA:BB:CC"' -x rsp-subtree=children Total Objects shown: 1 # fv.CEp name : 00:01:02:AA:BB:CC annotation : childAction : contName : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC encap : vlan-196 extMngdBy : id : 0 idepdn : ip : 192.168.1.2 lcC : learned lcOwn : local mac : 00:01:02:AA:BB:CC mcastAddr : not-applicable modTs : 2021-03-17T22:17:54.678-05:00 monPolDn : uni/tn-common/monepg-default nameAlias : rn : cep-00:01:02:AA:BB:CC status : modified uid : 0 uuid : vmmSrc : # fv.Ip addr : 192.168.1.2 annotation : childAction : createTs : 1969-12-31T19:00:00.000-05:00 debugMACMessage : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/ip-[192.168.1.2] extMngdBy : flags : lcOwn : local modTs : 2021-03-17T22:17:54.678-05:00 monPolDn : uni/tn-common/monepg-default rn : ip-[192.168.1.2] status : uid : 0 # fv.RsCEpToPathEp tDn : topology/pod-1/protpaths-223-224/pathep-[VPC-MX7000-PROD-DELL01-MGMT01] childAction : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/rscEpToPathEp-[topology/pod-1/protpaths-223-224/pathep-[VPC-MX7000-PROD-DELL01-MGMT01]] forceResolve : yes lcC : learned lcOwn : local modTs : 2021-04-21T07:53:09.310-05:00 rType : mo rn : rscEpToPathEp-[topology/pod-1/protpaths-223-224/pathep-[VPC-MX7000-PROD-DELL01-MGMT01]] state : formed stateQual : none status : tCl : fabricAPathEp tType : mo # fv.Ip addr : 192.168.1.1 annotation : childAction : createTs : 1969-12-31T19:00:00.000-05:00 debugMACMessage : dn : uni/tn-MY-TENANT/ap-MY-APPLICATION-PROFILE/epg-VLAN-196/cep-00:01:02:AA:BB:CC/ip-[192.168.1.1] extMngdBy : flags : lcOwn : local modTs : 2019-08-24T06:14:37.256-05:00 monPolDn : uni/tn-common/monepg-default rn : ip-[192.168.1.1] status : uid : 0
So, you can see that I have 2 child fvIp objects under a single fvCEp object, and one of those child fvIp objects has my IP in question!
The host behind that MAC address is doing some virtualization, so perhaps that explains the 2 IP address using a single MAC address?
But anyway, mystery solved I guess, but still very strange! I would have expected an fvCEp object to be created for every IP endpoint, but perhaps there is some nuance to creating an fvCEp object that I'm not aware of, and somehow this situation didn't qualify for a second fvCEp object (maybe because every fvCEp object is "keyed" with the mac address, so in this situation a single MAC address means only 1 fvCEp object, and any "extra" IP addresses are created as additional fvIp child objects).
Also, thanks @RedNectar for your suggestion on naming VPC's with leaf and port number! That is a very good idea! I will check out that link you posted. That naming convention would be very useful in a time like this! :- D
Again, thanks everyone for your time in responding! This really is a very strong ACI group, and your suggestions were very helpful and led me down the right path to a solution! Woo! I'm excited to keep learning, and would like to become one of the "elite" ACI members in this group one day :- D
06-14-2021 08:45 AM
I see that you got your answers, but here is my observation
I think there is some issue with ACI versions regarding the filter
class fvCEp is able to return the endpoints in both the versions that I have tried the moquery
moquery -c fvCEp
however when I used the filter like following moquery command, it returned the result in version 3.2(9b) but not in 5.1(4c)
offcourse I changed the IP address according to the learnt IP endpoint in the respective fabric.
moquery -c fvCEp -f 'fv.CEp.ip=="11.11.11.11"' -x rsp-subtree=children
5.1(4c) - does not work
3.2(9b) - work
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide