#vmware nsx

vRealize Network Insight v4.x now supports external sources for NetFlow and sFlows. This means you can perform micro segmentation planning on physical servers (before you migrate them to virtual) and create deep insight into what network traffic is going through your entire network (and not just limited to what’s happening in your virtual network).

Currently, NetFlow versions 5, 7, 9 and IPFIX are supported. Getting started with NetFlow in vRNI is pretty easy, but it is slightly more complicated than regular data sources.

Getting Started

I say it’s slightly more complicated, because you have to have a dedicated Collector VM (previously known as Proxy VM) for NetFlow only. The deployment process of this Collector is a bit different, I’ll guide you through the steps below.

First, get the regular Collector VM OVA file, the same one you used to deploy the Collector that collects data from your vCenter, NSX, etc. Get ready to deploy it via vCenter, but first follow these steps to get a shared secret:

Login to vRNI

Go to the settings (either type “settings” in the search bar or use the menu on the top right)

Select Accounts and Data Sources

Click the Add Source button

Choose Netflow Collector as the data source type (on the bottom)

Click the Add Collector VM button. This will display the following popup:

Deploying the Collector VM

After you’ve generated the shared secret for the Collector VM, you can go ahead and deploy that OVA via vCenter. I’m not going to go through all steps, assuming you know how to deploy an OVA. Remember to select Thin Provisioning. You will get a couple of template customisation options, mostly around network settings, but the last option is the most important one; the shared secret. Here you want to input the shared secret you just generated in the vRNI UI.

If everything looks good, deploy the Collector and go get some coffee. It takes a couple of minutes to deploy the OVA and the boot sequence needs to be completed before you can continue. It takes 10 to 15 minutes total. Don’t be like Fred, don’t stare at the progress bars. Anyway, when it’s done with all that it needs to do, it will show up in the vRNI UI automagically. When it does, give it a nickname and optionally some notes about the Collector. Click the Submit button when you’re done.

You can check if you’re successful by looking at your data source overview and the NetFlow data source turns up and there’s a timestamp on the Last Collection value.

And that’s it, vRealize Network Insight is ready for NetFlow ingestion. Point your NetFlow streams to the IP address of the newly created Collector VM.

Verification

Alright, so now you have the NetFlow Collector running and it’s supposed to gather flow data to present back to you. If you’ve already configured your switch to send NetFlow to your NetFlow Collector VM though. If you haven’t, there are a couple examples at the bottom here.

There’s a search query to test if your vRNI is actually collecting physical NetFlow:

flow where Flow Type = 'Source is Physical' and Flow Type = 'Destination is Internet'

I don’t think I have to explain what you’re looking at.

Creating More Context

Currently, vRNI does not resolve physical IP addresses to names (Also, who has their complete network correctly configured for forward DNS, let alone reverse DNS?). The functionality will be more automated in the future (like reading from a CMDB & IPAM, is my best hope/guess), but for now you can manually create more context for the physical flows you’ll be seeing in the UI.

There are two options to do this in the Settings page, under IP Properties and Subnets.

Physical IP and DNS Mappings

You can upload your Bind zones to vRNI so that it can use DNS names instead of IP addresses. If you don’t have Bind as your DNS server (have to admit, it’s pretty old), you can also upload a simple CSV file with your DNS records in it. Examples of this CSV file and the Bind zones can be found in a downloadable zip file.

Remember to zip up whichever format you use, even if it’s just 1 file.

Physical Subnets and VLANs

The other option to provide more feedback can be a bit more confusing. You can also manually map subnets to IP Subnets. I can hear what you’re thinking: “Isn’t vRNI supposed to do this automatically via its data sources?!?!?” – well, yes. If the NetFlow is coming from a supported data source, it will indeed automatically translate the IP Subnets to a VLAN. But here’s the thing; NetFlow is pretty universal and there’s a somewhat limited (although pretty large) list of supported switches and routers as a data source within vRNI. If you decide to send NetFlow from a switch or router that is not on the supported data source list, vRNI doesn’t know what IP Subnet belongs to what VLAN. That’s why you can configure them manually.

The process is pretty simply; on the Physical Subnets and VLANs settings page, click the Add button. Then enter a Subnet and VLAN ID and press Submit.

NetFlow Configuration

Here are a couple of examples on what configuration is needed on certain switch types. Replace $Collector_VM_IP with the IP address of your vRNI NetFlow Collector.

Disclaimer: Verify commands before you enter them into your equipment. I haven’t been able to test all of these, some are from documentation and theoretical.

flow-export destination inside $Collector_VM_IP 2055 flow-export template timeout-rate 1 flow-export delay flow-create 60 access-list netflow-export extended permit ip any any class-map netflow-export-class match access-list netflow-export policy-map global_policy class netflow-export-class flow-export event-type all destination $Collector_VM_IP service-policy global_policy global

More details and configurations will come soon.

.@Cohesity and VMware NSX: Slayers of Ransomware - WannaCry @vmware @VMwareNSX #NotJustBackup #WannaCry

Last week the world witnessed the impact of a malicious cyberattack which affected several organizations and institutions across the globe. Hospitals, airports, courier delivery service, telecommunications, government agencies, and others all fell victims to what is being described as one of the worst and most extensively spread ransomware attacks in history as reported by CNN Tech called…

Hola que tal

VMware NSX cuenta con los siguientes beneficios:

Despliegue sin Interrupción: Las máquinas virtuales no requieren modificación para poder usar una red virtual. Es tan simple como crear la red virtual y luego ir a la vNIC de la máquina y conectarla a esta red. También se cuenta con un asistente de migración de máquinas virtuales el cual permite tomar varias máquinas y migrarlas a la…