Hello everybody. I got an SG500-28 (updated to the lastest version of the firmware, fresh conf) in L2 mode, and two vmware vsphere 5.5 hosts with one vm in each one, connected to a portgroup inside a vswitch that has VLAN 20 ID (that is called virtual switch tagging, VST). Each vswitch is binded to a single NIC on the host, and the NIC is connected to the SG500.
My very simple goal is to ping the vm placed on host A from the vm in host B, but it seems that no data pass through the switch if I change the VLAN ID of the vms networks to anything different than "default". The vms network configuration is ok, I can easily make them communicate moving everything to default vlan (same vswitch, same hosts etc.).
Regarding the SG500 config: I simply create the VLAN (with ID 20 of course) and switchport mode trunk switchport trunk allowed vlan add 20 spanning-tree portfast trunk in the right ports. What I'm doing wrong? I know It's a very simple/trivial question, any help will be apreciated.
Oh, I've tried this config in TWO identical SG500 (it's not a sample issue).
So I wrote out the long explanation below and then realized the issue here may be that there is no inter-VLAN routing going on.
You mentioned that your SG500 was in layer 2 mode, so what is doing the routing on your network? Your VMs can communicate when they are on the default network because they are in the same subnet, so no router is needed. However to communicate with hosts in another VLAN you would need either a router setup to handle the traffic between VLANs, or you can put the SG500 in layer 3 mode, and setup an IP in each VLAN to act as a default gateway for the hosts in each VLAN. That way you would have a device routing the traffic.
In case you already have a router or something else in place to handle inter-VLAN routing, I will include everything else I typed out before I thought of that.
I setup an SG500-28 this weekend to test it with my Vsphere cluster. I have two ESXI 5.5 hosts managed by the Vcenter 5.5 appliance.
Initially they were configured with one NIC connected to a Cisco 3550T. I had already setup VST, with the switch configured as a trunk, with native VLAN as 200 (the VMWare VLAN) and all other VLANs allowed, to be created as needed. On the switch there were also VLANs 200, which was trunked to the 1st ESXI host, but had no VMs in it yet.
I went to one ESXI host and configured the second NIC to use a new vswitch (similair to your setup) and setup two new VM networks set to VLAN tag 400 and 500. I also changed the Physical Adapter settings for the vswitch/NIC to enable Promiscous mode.
I then created a trunk from the 3550 to the SG500, and from the SG500 to the new NIC/vswitch on the second ESXI host. I spun up a few VMs in each of the new vNetworks (the two marked VLAN 400 and 500 and connected to the physical NIC connected to the SG500).
On the 3550 I also created a new VLAN interface for both VLAN 400 and 500 to enable inter-VLAN routing.
Once the VMs were up, I set static IPs for each of them in their respective VLANs and had no problem pining between VLANs on the same ESXi host, between VLANs on two different ESXi hosts, or between any of the hosts and the interfaces on the 3550T. The only way that would all work is if the VST VLAN tags from the ESXi host are being correctly picked up by the SG500, then trunked over to the 3550, routed to the other VLAN, then back to the correct vswitch and host.
Screenshots of ESXi configuration in vSphere Web Client 5.5:
Screenshot of ESXI configuration connected to 3550T:
Introduction:Topology Diagram:Configuration Overview:Related
Information: Introduction: This document describes how to connect SG300
with Catalyst switch via STP. Spanning Tree Protocol (STP) is a Layer 2
protocol that runs on mainly on switches. The spec...
The Sx500 Series Stackable Switches offers different port features. You
can add security to a port, make the port more energy efficient, map a
VLAN to a port, make a port available or not to a specific network
portion, and so forth. The next set of articl...
Recently, HP Networking published a blog post attempting to counter the
favorable third party Miercom report on our Cisco® 200 and 300 Series
Smart and Managed switches: