Category Archives: NSX

Syslog Configuration for NSX-T Components using API

In this post, quickly i’ll walk through how to Configure the NSX-T components to Forward Log Events to vRealize Log Insight using API.

Once you have VMware vRealize Log Insight (vRLI) designed and deployment, you can use API call to configure your NSX-T components to forward logs to log management servers. In this case i am going to push vRLI VIP FQDN through API call on NSX-T Managers and NSX-T Edges.

  • nsx01a
  • nsx01b
  • nsx01c
  1. Open POSTMAN and configure Authorization –> Select Basic Auth under TYPE and Provide NSX-T Manager username and Password to allow Postman to talk to NSX-T managers. 

2. Next select Headers, set  KEY as Content-Type and VALUE as  application/json

3. Next Select Body –> raw –> and provide Syslog server, protocol, post and log level you want to sent from NSX-T managers to log insight.

4. Next select POST –> https://xx-m01-nsx01a.xxxxx.com/api/v1/node/services/syslog/exporters and Click Send.

In the lower Body section, it will display content which confirms that syslog settings has successfully pushed on NSX-T Manager.

5. Repeat this for another NSX-T Managers node nsx01b and nsx01c.

POST – https://xx-m01-nsx01b.xxxxx.com/api/v1/node/services/syslog/exporters

POST – https://xx-m01-nsx01c.xxxxx.com/api/v1/node/services/syslog/exporters

6. Now time to verify, Clear the text from Body  section and send GET to retrieve configuration data from NSX-T Managers.

GEThttps://xx-m01-nsx01a.xxxxx.com/api/v1/node/services/syslog/exporters

In the lower Body section, it retrieves the configured syslog settings from  NSX-T Manager.

Configure the NSX-T Edges to Forward Log Events to vRealize Log Insight 

Now will Configure the NSX-T Edge nodes to send audit logs and system events to vRealize Log Insight.

To configure on NSX-T Edge nodes first, you retrieve the ID of each edge transport node by using the NSX-T Manager user interface. Then, you use the Postman application to configure log forwarding for all edge transport nodes by sending a post request to each NSX-T Edge request URL.

  1. Login to NSX-T Manager to retrieve the ID of each edge nodes.

  • nsxedge-01 — 16420ffa-d159-41a2-9f02-b4ac30d32636
  • nsxedge-02 — 39fe9748-c6ae-4a32-9023-ad610ea87249

2. Here is syntax for edge node – POSThttps://xx-m01-nsx01.xxxxx.com/api/v1/transport-nodes/16420ffa-d159-41a2-9f02-b4ac30d32636/node/services/syslog/exporters and Send

3. Now time to verify, Clear the text from Body  section and send GET to same url to retrieve configuration data from NSX-T edge node.

Repeat this for rest of the NSX-T edge nodes. 

That’s all.  Hope you enjoyed reading this post. Feel free to share 🙂

 

How to Configure centralized logging for the NSX Manager 6.x.x, NSX Controllers and NSX Edge devices

In my previous article discussed about VMware NSX Manager 6.x.x Backup and Restore and in this article I am going to discuss how to Configure centralized logging for the NSX Manager 6.x.x, NSX Controllers and NSX Edge devices.

In the production environment it is always recommenced to have remote log collector server configured, so that NSX Manager 6.x.x, NSX Controllers and NSX Edge devices sends all audit logs and system events from  NSX Manager 6.x.x, NSX Controllers and NSX Edge devices to the syslog server. This will be handy to troubleshoot or to get the final RCA in the event of any issue.

Let’s start with configuring syslog server for NSX Manager:-

1. Login to the VMware NSX Manager Virtual Appliance with Admin account.b1
2. Go to Manage –> General –> Click Edit in the Syslog Server section.p13. Provide Syslog Server, Port and Protocol details in the syslog server window and Click OK to test and save the  settings.p2

4. Once it is saved. It will show the settings like below.p3This is how we can configure Syslog server for NSX Manager.


Next is how to Configure Syslog Server for VMware NSX controllers :-

For NSX Controllers only supported method to configure syslog Server is through the NSX API. And using Rest API we need to push Syslog Server details on all the NSX controllers one by one.

Before we go ahead and push the syslog server on NSX controllers through REST API, We need to enable/Add REST API client to the browser. You can search for Rest API Client for the browser for Chrome or Mozilla and Add to the Browser.

api1

api2

Once you are done with adding REST API plug-in to your browser. There are couple of thing that needs to be remember.

REST API requests requires Authentication  header and Content-Type as application/xml to send HTTP body.

api4

Now we are ready to send the request body to configure Syslog Server for NSX controllers.

Open the Rest Client to set the request body to configure Syslog for NSX for vSphere Controllers. Make sure you have selected the Method as POST and URL as https://<NSX Manager IP>/api/2.0/vdn/controller/{controller-id}/syslog where controller-id is the name of NSX controller and can be found on the NSX Installation page.

HTTP Request body has to be this:

<controllerSyslogServer>
<syslogServer>x.x.x.x</syslogServer>
<port>514</port>
<protocol>UDP</protocol>
<level>INFO</level>
</controllerSyslogServer>

api3

This is how we can configure Syslog Server on NSX Controllers. If you want to DELETE the Syslog exporter use below request:-

Method :- DELETE and URL:- https://<NSX-Manager-IP>/api/2.0/vdn/controller/{controller-ID}/syslog.


How to configure Syslog Server for Distributed Logical Router.

1.  Login to vCenter Server using vSphere Web Client and choose Networking and Security –> NSX Edges –> and Double click on Logical Router.lrs1

2. Under Manage –> Settings –> Configuration click on Change under Syslog Servers.LRs2

3. Enter the Syslog Server and Protocol details in the Edit Syslog Server Configuration page and Click OK.LRs3

4. Now we can see Syslog is configured and ready to send all the logs to Remote Server.LRs4


How to configure Syslog Server for NSX Edge.

1.  Login to vCenter Server using vSphere Web Client and choose Networking and Security –> NSX Edges –> and Double click on NSX Edge.DRS1

2. Under Manage –> Settings –> Configuration click on Change under Syslog Servers.DRS2

3. Enter the Syslog Server and Protocol details and Click OK.

DRS4

That’s All. This is how you can configure Syslog Server for NSX Manager, NSX Controllers and NSX Edges.

Thank you and Happy learning 🙂

 

VMware NSX Manager 6.x.x Backup and Restore

In this post i am going to discuss how to configure Backup for NSX Manager 6.x.x, Schedule backup for NSX Manager 6.x.x, How to take On-demand Backup for NSX Manager 6.x.x and Restore NSX Manager configuration from a backup.

We can back up and restore NSX Manager data, which includes system configuration, events, and audit log tables. Backup are saved to a remote location and that must be accessible by the NSX manager.

We can back up NSX manager data on-demand or we can schedule as per plan.

Let’s start now how to configure remote server to store the backup of NSX manager.

  1. Login to the VMware NSX Manager Virtual Appliance with Admin account.

b12. Under the NSX Manager Virtual Appliance Management –> Click Backup & Restore.b2

3. To store the NSX Manager Backup we can use FTP server with FTP or SFTP Transport protocol. To configure FTP Sever settings click Change Next to FTP Server Settings.b3

4. Backup Location Window will open up:

  • Enter IP/Host name of the FTP Server.
  • Choose Transfer protocol either FTP or SFTP, based on what the destination server supports.
  • Enter the Port number for Transfer Protocol.
  • Enter the user name and password to connect to backup server.
  • Enter the Backup Directory where you want to store the backup.
  •  Enter the Filename Prefix, Prefix will be added every time with backup file runs for NSX manager.
  • Type the Pass Phrase to secure the backup.
  • Click OK to test connection between NSX Manager and FTP Server and Save the settings.

b4

5. Once connection testing done it will save the settings. It will show the settings as below.b5

6.  After configuring the FTP Server Settings, We can configure to schedule the backup. Click Change next to Scheduling. We can schedule backup for Hourly, Daily or Weekly basis. Choose your option as per plan ( Recommended is to take daily basis), and Click Schedule to save the settings.

b6

b7

b8

7. Backup will run as per schedule and you can see entry for every day.

b9

8. We can also perform on-demand backup of NSX manger. For On-Demand backup of NSX Manager click Backup Next to Backup History.b10

9. Create Backup window will open up to confirm that you want to start a backup process now, Click Start to start the backup immediately.b11

10. it will take few minutes to complete the Backup process.b12

11. You can see new backup entry in Backup History.b13

Now will discuss how to Restore from a backup.

We can restore a backup only on a freshly deployed NSX Manager Appliance.  So let’s assume that we have some issue with Current NSX manager and can not be recovered.

In this scenario we can deploy new NSX Manager Virtual Appliance, Configure the FTP Server settings to identify the location of the backup to be restored. Select the backup from backup history and Click Restore and Click OK to confirm.b15That’s it. This is how we can configure Remote Server to store NSX Manager backup, Schedule NSX Manager backup, Perform on-demand backup for NSX Manager and Restore from a backup.

Thank you and Keep spreading the knowledge  🙂

 

 

VMware Released NSX for vSphere 6.2.3

VMware released NSX for vSphere 6.2.3 last month with many Changes and also includes a number of bug fixes in the previous version of NSX.

 

Here are Changes introduced in NSX vSphere 6.2.3:-

  • Logical Switching and Routing
    • NSX Hardware Layer 2 Gateway Integration: expands physical connectivity options by integrating 3rd-party hardware gateway switches into the NSX logical network
    • New VXLAN Port 4789 in NSX 6.2.3 and later: Before version 6.2.3, the default VXLAN UDP port number was 8472. See the NSX Upgrade Guide for details.
  • Networking and Edge Services
    • New Edge DHCP Options: DHCP Option 121 supports static route option, which is used for DHCP server to publish static routes to DHCP client; DHCP Options 66, 67, 150 supports DHCP options for PXE Boot; and DHCP Option 26 supports configuration of DHCP client network interface MTU by DHCP server.
    • Increase in DHCP Pool, static binding limits: The following are the new limit numbers for various form factors: Compact: 2048; Large: 4096; Quad large: 4096; and X-large: 8192.
    • Edge Firewall adds SYN flood protection: Avoid service disruptions by enabling SYN flood protection for transit traffic. Feature is disabled by default, use the NSX REST API to enable it.
    • NSX Edge — On Demand Failover: Enables users to initiate on-demand failover when needed.
    • NSX Edge — Resource Reservation: Reserves CPU/Memory for NSX Edge during creation. You can change the default CPU and memory resource reservation percentages using this API. The CPU/Memory percentage can be set to 0 percent each to disable resource reservation.PUT https://<NSXManager>/api/4.0/edgePublish/tuningConfiguration
                  <tuningConfiguration>
                     <lockUpdatesOnEdge>false</lockUpdatesOnEdge>
                     <aggregatePublishing>true</aggregatePublishing>
                     <edgeVMHealthCheckIntervalInMin>0</edgeVMHealthCheckIntervalInMin>
                     <healthCheckCommandTimeoutInMs>120000</healthCheckCommandTimeoutInMs>
                     <maxParallelVixCallsForHealthCheck>25</maxParallelVixCallsForHealthCheck>
                     <publishingTimeoutInMs>1200000</publishingTimeoutInMs>
                     <edgeVCpuReservationPercentage>0</edgeVCpuReservationPercentage>
                     <edgeMemoryReservationPercentage>0</edgeMemoryReservationPercentage>
                     <megaHertzPerVCpu>1000</megaHertzPerVCpu>
                  </tuningConfiguration>
      
    • Change in NSX Edge Upgrade Behavior: Replacement NSX Edge VMs are deployed before upgrade or redeploy. The host must have sufficient resources for four NSX Edge VMs during the upgrade or redeploy of an Edge HA pair. Default value for TCP connection timeout is changed to 21600 seconds from the previous value of 3600 seconds.
    • Cross VC NSX — Universal Distributed Logical Router (DLR) Upgrade: Auto upgrade of Universal DLR on secondary NSX Manager, once upgraded on primary NSX Manager.
    • Flexible SNAT / DNAT rule creation: vnicId no longer needed as an input parameter; removed requirement that the DNAT address must be the address of an NSX Edge VNIC.
    • NSX Edge VM (ESG, DLR) now shows both Live Location and Desired Location. NSX Manager and NSX APIs including GET api/4.0/edges//appliances now return configuredResourcePool and configuredDataStore in addition to current location.
    • Edge Firewall adds SYN flood protection: Avoid service disruptions by enabling SYN flood protection for transit traffic. Feature is disabled by default, use the NSX REST API to enable it.
    • NSX Manager exposes the ESXi hostname on which the 3rd-party VM Series firewall SVM is running to improve operational manageability in large-scale environments.
    • NAT rule now can be applied to a VNIC interface and not only an IP address.

For complete details please refer release note :- http://pubs.vmware.com/Release_Notes/en/nsx/6.2.3/releasenotes_nsx_vsphere_623.html

Thank you and Keep sharing 🙂

NSX Troubleshooting – VMs out of Network on VNI 5XXX

Currently i am working for customer running Network Virtualization (NSX) in their SDDC environment. Few weeks ago faced issues that multiple VMs out of Network in one of the compute cluster. So wanted to share and hope this will be useful for so many folks working on NSX. Customer is running NSX 6.1.1 with multiple VNIs managing networks for multiple environments. (e.g. Prod, DR, DEV,QA, Test etc.)

Here are the steps:-

  1. After receiving the issue we tried to ping random VMs from the list and VMs were not reachable.
  2. Next step was to find out the VNI number for those VMs and see if all are part of same VNI. And yes those VMs were part of same VNI (e.g. 5XXX)
  3. Once we knew the VNI number next step was to find out if all VMs connected to the VNI 5XXX are impacted or few.
  4. From the step 3 we came to know that only few VMs were impacted not all. After drilling down we found that VMs impacted are running on one of the ESXi hosts in the cluster and VNI working fine with other hosts in the cluster.
  5. To bring the VMs online we moved VMs to another host  and after migrating VMs were reachable and User were able to connect to the applications.
  6. Next was to find out the  Root Cause Analysis (RCA) why VMs connected to VNI 5XXX on ESXi host XXXXXXXXXX  lost network.
  7. Putty to ESXi Host and run the following command to check the VNI status on the host :- net-vdl2 -l. You can see below output screen that VXLAN Network 5002 is DOWN and all impacted VMs were part of this.

VNI19. To fix the issue we need to re-start the NETCPA daemon on the host. Here are list of commands to STOP / START  and CHECK STATUS of NETCPA daemon.

1)  Stopped the netcpa daemon by running –>  /etc/init.d/netcpad stop.

2)  Started the netcpa daemon by running –> /etc/init.d/netcpad start.

3) checked the status of service by running –> /etc/init.d/netcpad status.

10. After starting the NETCPA daemon check the VNI status by running command :- net-vdl2 -l. And now you can see that VXLAN 5002 is UP

VNI211. Next step was to move few VMs on this host from VNI 5002 and check the connectivity status of VMs and Application. All were perfectly fine after moving now on this host.

Note:- This issue has been addressed in NSX version 6.1.4e. If you are running NSX 6.1.4e then may be you will not get this issue. As Controller will be monitoring netcpad daemon and start if it failed on any of the hosts.

That’s it ….SHARE & SPREAD THE KNOWLEDGE!!