cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
2661
Views
25
Helpful
8
Replies
vv0bbLeS
Beginner

Moquery - how to find interface of IP address if interface is a VPC

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 ?

0xD2A6762E
2 ACCEPTED SOLUTIONS

Accepted Solutions

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

View solution in original post

@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

 

 

0xD2A6762E

View solution in original post

8 REPLIES 8
Sergiu.Daniluk
VIP Advocate

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

Robert Burns
Cisco Employee

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

vv0bbLeS
Beginner

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!

0xD2A6762E

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

View solution in original post

Robert Burns
Cisco Employee

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

RedNectar
Advocate

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.

 

 

RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

@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

 

 

0xD2A6762E

View solution in original post

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