Suggestions for improving location functionality

[tbainter]

I have a few common issues with how locations work in Cloudscape and fixing these would make the tool much easier to use

Idea 1:  Option to exclude /32 subnets in location determination

Issue addressed:  There are times when our clients don't want us to scan broadly and do true discovery, but they want Cloudscape data for their known servers.  There are also times when teams will rescan individual servers when initial login is unsuccessful.  Because those IPs have a specific subnet, the associated device gets the location information for the specific subnet.  That means it may be necessary for us to manually drag THOUSANDS of IPs to the appropriate location if we want it to appear correctly in Cloudscape.

Solution detail:  In the location screen have a slider or check-box to determine whether or not /32 subnets are considered when mapping an IP to a location.  If inclusion of /32 is not checked/on, matching of subnets will use the smallest subnet that is NOT a /32.  This allows us to have a /24 subnet that has a label for Internal web servers without dragging each individual web server IP to the correct location name

Idea 2: Bulk upload of locations

Issue addressed: The user interface for matching IP subnets to location labels is very clunky.  It looks like it was designed/tested and demoed with a small number of subnets where the functionality seems intuitive.  THIS DOES NOT SCALE - especially if the number of subnets and labels is much larger than a page.  I have had clients with hundreds of subnets and it takes days to make all of the mappings even though we have a readily available table of subnets and names that could easily be bulk uploaded in minutes like we can do with tags and stack membership.

Solution detail:  Allow a .csv file upload with subnet CIDR block in one column and subnet label in another.

Idea 3: Allow location metadata for subnets that have not been scanned

Issue addressed: When looking at communications details, we often have locations like rics-unknown-private.  Very frequently  these are things that are not in scope for Cloudscape discovery.  However, simply knowing it is an IP on the network is not good enough. 

Solution: I would like to be able to have location labels (or an alternative set of labels specific to communications reporting) where I can add information.  For example, there may be an entire subnet of VDI clients.  I don't want to scan them (or the client doesn't want me to).  It would be much more useful to say 10.1.4.0/21 is a VDI subnet and label all comms to the subnet appropriately than to mix that in with other unknown traffic that requires research to identify.  Another use case would be  data center locations that are out of scope for scanning, but we may have information about the subnets.

[EdwardC]

I totally agree with idea #2.  that will save us lots of time. 

[rlant15]

I couldn't agree more with Tbainter for Idea#1. I have experience the same and finds that part alot cumbersome to do Tbainter's suggestion makes alot of sense.

[erickH]

I've been wondering about this same feature myself. a Bulk upload for location would be a nice addition.

[danieltapia]

Totally agree with this. I've been involved in more that 17 Cloudscape projects and these points would be definitly helpfull.

1 - Handling location for individual IPs (/32s) is complex and adds a lot of noise to the analysis

2 - Current location handling is impractical after adding several subnets

3 - Would be a very nice addition

[orestisstefanis]

Allowing metadata for subnets that have not been scanned but we still want to label (maybe because they are out of scope), would have saved me a lot of time. I agree with all of these suggestions.

[vishrantsaini]

Agreed on all the ideas mentioned above. It is extremely time consuming to manually handle the location updates. 

These would be much awaited features since years and it would help in quick tool setup.

[mjamison]

Hi Tbainter,

Thank you for your input. These are some great product ideas. I recommend submitting them to the Ideas board. To do so, you may use the following link. By submitting the Ideas to the Idea board, it will go directly to the Product Manager. 

If you would like, once submitted to the Ideas board, I can reach out to the Product Manager, letting him know you have submitted.

You may use the following link to submit an Idea to the Product Team.

https://flexerasfdc.ideas.aha.io/ideas

Please let me know if there are questions.

Thank you,

Mark Jamison

Flexera Support Team

[tbainter]

Thanks Mark,

This is the link.  https://flexerasfdc.ideas.aha.io/ideas/ITV2-I-18

I didn't see an option for Foundation / Cloudscape, so I picked IT Visibility.  I have no idea if that was the right place.

[mjamison]

Hi Tm,

You are welcome. I am happy to assist. Thank you for the link. The option you would have selected is Cloud Migration. I have already spoken to the  Foundation/CloudScape Product Manager and forwarded the link. 

Thank you,

Mark Jamison

Flexera Support Team

[tbainter]

Thanks, Mark!

[cbustamantep]

I have been in situation were all of those ideas would have been useful. Especially Idea 2: Bulk upload of locations, is the one I would use more frequently.

[pnunez]

 totally agree with both ideas #1 and #2, location assignment has been very anoying when we have to re-scan singe IP addresses

[BWallaceFDP]

Team! Depending on how the environment is addressed, I have found tagging devices with a custom location tag pretty handy. Note that you should NOT use the tag key "Location", as that is already default tag key in the system. I usually call tag key something like "Customername-Area" and the tag value is the location.

If the customer has their environment broken into subnets-supernets you can filter the assets page on the subnet octets and bulk apply tags 100 at a time. For larger or more complex environments, you can use the tag upload feature and filter your .csv import on the subnetting scheme.

Example - 192.168.x.x  all get a tag key of Area and a tag value of NCDC

                     10.10.1.x       all get a tag key of Area tag value of SCDC

These device level tags will be visible in various reports in the platform, and also in your detailed application dependency report. 

-Brooks