Forum Discussion

syncretism's avatar
syncretism
Icon for Nimbostratus rankNimbostratus
Jul 07, 2017

Querying 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:

  1. 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?

  2. 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.

3 Replies

  • Also, 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?

  • 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/').