NSX -V - Unable to access certain applications on universal logical switch(Stretched vxlan) in Cross VC environment

Problem Description:

I have 2 logical  in a datacenters is a cross vcenter environment.The segregation for datacenters is logical but the physical devices(Nexus,servers,firewall) resides on the same site/location/racks.

Primary Site - Vcenter 6.7

Secondary site - Vcenter 6.7

NSX version - 6.4.3

I have created a universal logical switch of network connected with the universal DLR.

In primary site i have been running the workload for the last 6 months and all the communication is working fine.

Recently we decided to optimize  the use of secondary site and deployed few vmware applications(OVF based) onto the stretched vxlan(10.1 .80.0/24) networks on secondary site.

The issue is I am not able to open the VAMI page of my appliances from my primary site vxlan/vlans to the secondary site stretched vxlan(

Though I can ping/telnet the servers from my primary site to secondary site server but the application refuses to connect.

As per the attached Diagram VM A is not able to access the URL/Applications/vami pages for VM B and vice versa.

Although  VM A can ping/telnet to VM B and vice versa.

Key Points:

Physical firewall is not involved in the entire communication.

NSX firewall/distributed firewalls are disabled.

Ping/telnet is absolutely working fine hence no routing issues.

Attached the logical Diagram.

Does anybody else have faced such weird issue? Or am i missing anything?

0 Kudos
4 Replies

Hi saransh1

are you sure that MTU is 1600 across site??

Best Regards


0 Kudos
VMware Employee
VMware Employee

Looks to be mtu issue on physical network.

Can you confirm if we have 1600 mtu confiured between source and dest. hosts.

ping ++netstack=vxlan –d –s 1572 –I vmkX IP_address_of_destinataion_host_vmk


Anarv Handoo

0 Kudos

From this key point 'Ping/telnet is absolutely working fine hence no routing issues.' VM A can ping VM B?. If so we've to look into firewall  which may be blocking http/https traffic.

0 Kudos

Have you tried to access the VAMIs from the same subnet?

I've had issues where VAMI access did not work when coming from another subnet (routed).

Best regards, Rutger
0 Kudos