Transport Node Profiles are introduced to automatically configure vCenter Clusters for NSX-T. Additionally a Transport Node Profile maintains Transport Node Configuration at the Cluster level to ensure that when a vSphere Host is added or removed from the cluster it will be automatically be configured or unconfigured. Creating a Transport Node profile has a lot of similarities with the Host Migration from VSS/VDS to N-VDS workflow, which is documented in the Host Migration to N-VDS blog post.
In NSX-T 2.4 the NSX-T Manager is a Converged Appliance where Policy, Management and Control Roles are available on each NSX-T Manager Node and creating a Cluster of three NSX-T Managers. The NSX-T Managers in the Cluster also share a Distributed Persistent Datastore where the Desired State is stored. This feature brings the benefit of availability of all management services across the cluster, improves the install and upgrade process and makes operations easier with less systems to monitor and maintain.
In NSX BGP filters work like access lists for route advertisements (prefixes). The NSX BGP filters are prefix lists which work very similarly to firewall access lists. A prefix list contains one or more ordered entries which are processed sequentially. For each prefix entry you can specify inbound or outbound filters to allow certain routes to be advertised to or from the Edge Services Gateway/Distributed Logical Router.
For example you to want to prevent a route for 10.0.0.0/24 from being advertised in BGP from the NSX Edge Services Gateway.
One of our customers is preparing to migrate Virtual Machines from VLAN to VXLAN with the NSX L2 Bridge and asked me how to test the L2 Bridge and get confirmation that it is actually configured correctly and operational. All commands in this blog post are from the NSX Troubleshooting Documentation.
We can test if a bridge is functional by issuing a command on the NSX Manager.
In this blog post I would like to share some information regarding possibilities of on-boarding existing workloads or tenants in new or current VMware NSX deployments.
VMware NSX deployment projects I’ve been involved in mostly are designed and deployed in a greenfield environment where a customer has invested in hardware and software to run their new Cloud environment on. From this point forward new workloads and deployments are aimed to run on that infrastructure and the current (brownfield) environment has to be migrated or will be shut down in a certain amount of time. Migrating applications to NSX and securing them with means of NSX Micro-Segmentation involves obviously good knowledge of your application. In other words: Which Virtual Machines talks to each other, and over which protocols and ports? The more information you’ve got about those applications the better you are able to secure them. A tool like vRealize Network Insight can help a great deal here, but that’s a topic on each own. Another solution would be to have applications isolated with NSX Distributed Firewall allow rules with logging enabled. If you have a solution like Log Insight, you would then see all that traffic logged which includes the protocol communications between source and destination.
Figure 1: Micro-segmentation for a 3-tier application
