3 Replies Latest reply on Nov 27, 2019 2:36 AM by smitmartijn

    Application Dependency Mapping with vRNI.

    Gr33nEye Enthusiast

      Hi guys,



      Just would like to clarify something that I saw in the vRNI doco around Application Dependency creation. To me it looks likes vRNI could be used as an overkill VIN.



      Here is the link to the doco, Step 4.




      I saw a blog here that talk about it and it kinda looks like it could present the same info as VIN, on first glance.




      Has anyone tried it, how is the experience?





      Thank you.

        • 1. Re: Application Dependency Mapping with vRNI.
          smitmartijn Hot Shot
          VMware EmployeesvExpert



          I'm biased, but I'll say that it can indeed do the same functions as VIN. It does so with the flows as you've found in the blog below, but it also does application discovery based on metadata (names, tags) from the vCenter/AWS inventory and pulling apps down from ServiceNowCMDB: Application Discovery

          • 2. Re: Application Dependency Mapping with vRNI.
            Gr33nEye Enthusiast



            How would you say that it does it with flows? Do you have any link to doco on what and how it does it.


            Whats the impact on the VM? VIN was very light/no touch and provided allot of usefully info. Its replacement the the Discovery Management Pack, was,..... well not usefull.


            Is vRNI, something that we can just let run for a week and based on PG flow it will map out the traffic, figure out the type and the potential dependencies. Or will we need to connect to our F5s, switched ect to get useful data?


            I did see that it can collect info from Service Now and other services, but what is the point of vRNI if I already have the dependencies mapped out?

            • 3. Re: Application Dependency Mapping with vRNI.
              smitmartijn Hot Shot
              vExpertVMware Employees

              The security planner (donut) will show all incoming and outgoing connections. The idea is to discover applications using the tags, naming convention, and CMDB sources. Considering these sources are almost always incomplete (it's typically manual work to update the CMDB), vRNI can be used to complete and validate the discovery. If you group by VM or application, and look at the connections, anything that you've missed from the CMDB, tags, or naming convention discovery, will be shown - and you can update the CMDB from it.


              More info in the docs: Analyzing the Application


              There is no impact on the VM, as the data that vRNI ingests, comes from vSphere and the physical infra. If your infra is primarily virtual, no need to include your physical infra to do app discovery and flow analysis. However, for day 2 operations; adding the physical infra is critical.


              Hope that helps,