Forum Discussion
NimbostratusQuerying VIPs' Details When the Name Attribute is Unreliable
I’m tasked with automating some basic f5 tasks, but am not a network admin. I’ll start by thanking this community for the the friendly tips I’ve received since I started this project; y’all have been terrifically helpful.
I have been pulling VIPs using a pretty basic query:
/mgmt/tm/ltm/virtual?\$select=name
I use JQ to filter the JSON data returned by the f5 and get the “name” attribute VIP I’m looking for, like “foo.mydomain-8080”, and when I want some more information, like the pools associated with a particular VIP, I just use the “name” attribute:
/mgmt/tm/ltm/virtual/foo.mydomain-8080?\$select=pool
And this returns a pool, like “Pool-foo.mydomain-8080.” This worked swimmingly for my first application, but it fell over with the second for reasons I don’t quite understand.
With the I get a name attribute for the VIPs with the same query, but when I query a VIP using that attribute’s value, like
/mgmt/tm/ltm/virtual/baz.mydomain-8080?\$select=pool
The f5 returns
{ "code": 404, "message": "01020036:3: The requested Virtual Server (/Common/baz.mydomain-8080) was not found.", "errorStack": [] }
My f5 admin tells me that this is expected, because these VIPs “were built with an IAPP and are in folders,” like:
baz.mydomain-8080.app/baz.mydomain-8080
I don’t really know what this means, but it appears that I’m sunk, because I don’t have a reliable way to pull down a VIP and use its “name” attribute for subsequent queries. I’m exposing this stuff to incident managers and level-one operations, so I’d prefer the identifier to be simple and easily recognized by staff. So, I guess I have two questions:
-
Was I actually using the name attribute earlier, when this worked, or did the name just happen to match whatever I’m really looking for when I request /mgmt/tm/ltm/virtual/foo.mydomain-8080?\$select=pool? If it’s not the name, then what is it?
-
What can I use to ensure that I’m getting an accurate identifier for the VIP that will work when I want to get its associated pool, or change its working state? Why wouldn’t “name” work? Is there another parameter I can pass, like ?recursive=true or something?
Okay, more than two questions…
Thanks for your consideration; I’d be grateful for any explanation you can give me.
syncretismAlso, I've tried selecting "fullPath;" it's uglier than "name," but could do in a pinch:
/mgmt/tm/ltm/virtual/Common/foo.mydomain-8080
But I can't use the "fullPath" attributes value in my subsequent query successfully - the f5 throws a parsing error:
{"code":400,"message":"Found unexpected json pair at configuration item /ltm/virtual/Common. The json pair is \"foo.mydomain-8080\":null.","errorStack":[]}
What am I missing?
cjuniorNacreous
Hello, This may be simpler than it sounds. So, when we request a virtual list, this should be a recursive results.
/mgmt/tm/ltm/virtual?\$select=fullPath
"fullPath": "/Common/foo.mydomain-8080" "fullPath": "/Common/baz.mydomain-8080.app/baz.mydomain-8080"
To get default pools from it, I should replace slash "/" with tilde "~" char:
/mgmt/tm/ltm/virtual/~Common~foo.mydomain-8080?\$select=pool
/mgmt/tm/ltm/virtual/~Common~baz.mydomain-8080.app~baz.mydomain-8080?\$select=pool
Cheers.
selfLink is also a good option. e.g.,
curl -sku admin: https:///mgmt/tm/ltm/virtual?\$select=selfLink { kind: 'tm:ltm:virtual:virtualcollectionstate', selfLink: 'https://localhost/mgmt/tm/ltm/virtual?$select=selfLink&ver=11.6.1', items: [ { selfLink: 'https://localhost/mgmt/tm/ltm/virtual/~Common~TestApp.app~TestApp_vs?ver=11.6.1' }, { selfLink: 'https://localhost/mgmt/tm/ltm/virtual/~Common~http?ver=11.6.1' } ] }Obviously, you need to change the localhost part but it's easier than selectively replacing / to ~ (i.e., | sed 's/localhost/myHost/').
