- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
Cloud integration module - vDiscovery - stale AWS entries--no way to remove
[ Edited ]- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2019 01:09 PM - edited 02-26-2019 01:12 PM
I cannot, and neither can support at this juncture, figure out a problem that I created.
Scenario:
A test VPC was stood up in AWS. It had these networks configured in it. 10.234.0.0/27, 10.234.0.32/27, 10.234.0.64/27. (I have since manually deleted 10.234.0.64 /27).
I created a vDiscovery job to discover this VPC and it was successful in finding the 3 subnets and also finding another VPC named EKS-VPC-VPC associated with the same tenant ID. That VPC only had 1 subnet 192.168.0.0/16. This is odd because I could find nowhere that we had anything in the 192.168.0.0/16 defined in any VPC in AWS.
Anyway...we shutdown that test VPC and created a new Production VPC. This VPC uses this subnet 10.234.0.0/21 which of course covers up all of the old test /27 subnets.
I created a new job in vDiscovery, and deleted the old job out as it would no longer be necessary. I did this not realizing it was my only way to remove the old, now stale, discovered data. (clear all discovery data)
So I have 2 issues - A. I cannot figure out how to get rid of the old discovered data and tenant.
B. I need to figure out how to NOT have 192.168.0.0/16 network container and all the networks under it associated with the cloud as it is used extensively in our on premise environment I cannot just manually delete it.
Re: Cloud integration module - vDiscovery - stale AWS entries--no way to remove
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2023 02:27 PM
I realize this is a little late for you, but I'm adding it here in case someone else is looking for a way to clean up stale networks from vDiscovery after removing the job. Turns out that, while you can't delete them from the UI, you can delete them from the API (at least in 8.5.4).
I'm using curl for my examples. You may not need all of the flags or need different flags, depending on permissions and settings. These are the ones that worked for my environment. (I use single quotes around the URL in Linux and double quotes in Windows."
First, you have to find the object reference for your network:
curl -k1 --insecure -u <username>:<password> -X GET 'https://<your grid manager>/wapi/v2.11.3/network?network=10.x.x.x/x'
That will return something like the following:
[ { "_ref": "network/ZG5zLm5ldHdvcmskMeTuMTQwLjEzMC4wLzI2LzA:10.x.x.x/x/default", "network": "10.x.x.x/x", "network_view": "default" } ]
You want to grab the value of _ref for the next step, which will have the syntax of network/<IDstring>:<network>/<CIDR>/<network view>
Next, delete the network:
curl -k1 --insecure -u <username>:<password> -X DELETE 'https://<your grid manager>/wapi/v2.11.3/network/ZG5zLm5ldHdvcmskMeTuMTQwLjEzMC4wLzI2LzA:10.x.x.x/x/default'
I'm pretty sure that you only need the ID string, but it's easier for me to grab the whole reference and replace everything after the WAPI version. (It took me far too many attempts to realize I was unnecessarily putting the "network" part twice...)
curl -k1 --insecure -u <username>:<password> -X DELETE 'https://<your grid manager>/wapi/v2.11.3/network/ZG5zLm5ldHdvcmskMeTuMTQwLjEzMC4wLzI2LzA:10.x.x.x/x/default'