Blank Error While Adding NSX DLR or ESG Interfaces

I recently deployed NSX 6.3.2 in my home lab to do some testing. After deploying a DLR, I went back in to add some additional interfaces and was greeted by a ‘blank’ or null error message. Having run into this problem before, I thought it may be a good idea to give some additional context to VMware KB 2151309.

As you can see above, there is no text associated with the error. There are no problems with the IP or mask I used, and it doesn’t seem clear why this would be failing.

You would expect to find more detail in the NSX Manager vsm.log file, but interestingly there is nothing there at all for this exception. That’s because this isn’t an NSX fault, but rather something in the vSphere Web Client.

Looking at the vSphere Client vsphere_client_virgo.log file on my vCenter Server 6.5 appliance, we can see the tell tale null pointer exception that characterizes this bug:

[2018-05-24T23:01:43.448Z] [WARN ] http-bio-9090-exec-11 org.springframework.flex.core.DefaultExceptionLogger The following exception occurred during request processing by the BlazeDS MessageBroker and will be serialized back to the client: 
flex.messaging.MessageException: java.lang.NullPointerException : null
 at flex.messaging.services.remoting.adapters.JavaAdapter.invoke(JavaAdapter.java:412)
 at com.vmware.vise.messaging.remoting.JavaAdapterEx.invoke(JavaAdapterEx.java:72)
 at flex.messaging.services.RemotingService.serviceMessage(RemotingService.java:180)
 at flex.messaging.MessageBroker.routeMessageToService(MessageBroker.java:1472)
 at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:1046)
 at flex.messaging.endpoints.AbstractEndpoint$$FastClassByCGLIB$$1a3ef066.invoke(<generated>)
 at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)

Unfortunately, this error is completely persistent, and there doesn’t seem to be a way to work around the issue from the UI. KB 2151309 is careful to call out that this only occurs when trying to add or modify interfaces after the ESG/DLR has been created. If you create a new DLR or ESG, those interfaces added during creation will be fine.

Using API Calls as a Workaround

Although you’ll be pretty stuck in the UI, NSX’s powerful REST API can be an effective workaround. Since the API call will bypass the Web Client entirely, this bug will not be encountered and interfaces can be successfully added.

KB 2151309 provides an example API call for both an ESG interface and a DLR interface. Be sure to take note of which you need to add – the API calls are completely different. You can find more information on adding ESG and DLR interfaces in the NSX 6.3 API guide on pages 392 and 388.

In my case, I’ll be adding an interface to the DLR. In the screenshot below, you can see some of the required information, but below is a list:

• name: A simple label for the interface. People usually just put in the portgroup or logical switch name here. Any text string will be fine here.
• primaryAddress: The IP address for the interface. ESGs can have ‘secondaryAddresses’ defined here as well, but for a DLR there is only ‘primaryAddress’.
• subnetMask: Don’t use bit notation here as the GUI wants, use the full mask address.
• mtu: 1500 is the default, I used 9000 in my example below.
• type: The choices are ‘internal’ or ‘uplink’ just like in the UI.
• isConnected: Either true or false. Just indicated whether the interface is enabled or not.
• connectedToId: This is the portgroup or logical switch the interface is connected to. The call expects the moref for either a logical switch or a dvPortgroup – labels won’t work here. You can find more information on how to find these in my post: Finding moref IDs for NSX API Calls.

After preparing the API body and sending the call, I was greeted by a ‘200 OK’ response with the DLR interface configuration repeated in the body.

This is a good sign. Looking at the UI, I can see that the interface was successfully created:

Muddying the Waters

Although I’ve been able to reliably reproduce this problem one hundred percent of the time with vSphere 6.5 U1 and NSX 6.3.2, I should note that this is not the only cause of similar null pointer exceptions and blank error messages in the vSphere Web Client. In fact, I recently worked with a customer who observed an identical symptom and exception in vSphere 6.0 with NSX 6.3.1. That’s why I’d recommend upgrading to at least NSX 6.3.5, which has additional code fixes in place to avoid this problem, rather than 6.3.3 as KB 2151309 suggests.

In my case, I was able to correct this problem by upgrading to NSX 6.3.3.

Conclusion

Until you can upgrade to a newer release, getting familiar with the necessary API calls to add ESG interfaces would be a good idea. Once you get the hang of it, it really doesn’t take any longer than using the UI. PowerCLI/PowerNSX should also be good alternative method that can be used to bypass the vSphere Client.

Please feel free to leave any questions or comments below, or reach out to me on Twitter (@vswitchzero)