November 9, 2010 at 4:51 pm #42718
Ok so I have the Zeroshell configured on my VMWare box. I want it to be my VLAN router. I’ve never actually implemented VLAN’s before much less on a VMWare box. So here’s my setup.
Zeroshell ETH00 no VLAN – IP address 172.16.0.210 (This is where I manage the box)
Zeroshell ETH01 assigned to VLAN 2 – IP Address 172.16.12.100
VMWare vmnic1 on vSwitch1 with VLAN2 Port Group configured. (The ZeroShell shows up in VLAN2 in the VMWare network diagram).
On my HP Switch I have port 12 going to vmnic1 configured for tagging VLAN2.
On that same switch I have Port 19 configured for Untagged VLAN2 and have a laptop connected to that port – IP address 172.16.12.201
First issue. I cannot ping from or to the zeroshell and the laptop.
Second, once I can connect via VLAN2 two I’ll configure my additional VLANs and then I’ll need help routing between them.
Can anyone help me?
ThanksNovember 10, 2010 at 7:24 am #51304
Is the vmnic1 aware of vlan tagging?November 10, 2010 at 2:57 pm #51305
It should be it’s a Broadcom NetXtreme II BCM5708 which is capable of being VLAN aware, is there somewhere I can check to see if it’s enabled in VMWare? Thanks for the reply.November 10, 2010 at 3:03 pm #51306
Depends on the operating system of the VM server. Windows usually don’t recognize VLAN tagging by default.November 10, 2010 at 3:08 pm #51307
It’s ESXi 4November 11, 2010 at 5:43 am #51308
Depends on the operating system of the VM server. Windows usually don’t recognize VLAN tagging by defaultNovember 11, 2010 at 7:31 am #51309
As far as I know this is red hat linux based, correct? Try to add the vlan on the interface with the command
Usage: add [interface-name] [vlan_id]
set_flag [interface-name] [flag-num] [0 | 1]
set_egress_map [vlan-name] [skb_priority] [vlan_qos]
set_ingress_map [vlan-name] [skb_priority] [vlan_qos]
* The [interface-name] is the name of the ethernet card that hosts
the VLAN you are talking about.
* The vlan_id is the identifier (0-4095) of the VLAN you are operating on.
* skb_priority is the priority in the socket buffer (sk_buff).
* vlan_qos is the 3 bit priority in the VLAN header
* name-type: VLAN_PLUS_VID (vlan0005), VLAN_PLUS_VID_NO_PAD (vlan5),
DEV_PLUS_VID (eth0.0005), DEV_PLUS_VID_NO_PAD (eth0.5)
* bind-type: PER_DEVICE # Allows vlan 5 on eth0 and eth1 to be unique.
PER_KERNEL # Forces vlan 5 to be unique across all devices.
* FLAGS: 1 REORDER_HDR When this is set, the VLAN device will move the
ethernet header around to make it look exactly like a real
ethernet device. This may help programs such as DHCPd which
read the raw ethernet packet and make assumptions about the
location of bytes. If you don't need it, don't turn it on, because
there will be at least a small performance degradation. Default
November 11, 2010 at 5:10 pm #51310
I haven’t used the command line yet, but I’m willing to try. What’s the command that would show me what is already configured on that interface so I can tell if any of it has been done already via the GUI.
Thanks again for your help.November 12, 2010 at 7:29 am #51311
can show you the available interfaces, so if you see any of them marked like
it most likely is a vlan subinterface.November 15, 2010 at 2:10 pm #51312
Ok so it turns out that it wasn’t VMWare at all. I setup another host on my vmware box and assigned it to the VLAN 2 and I can communicate with it so my VLAN’s are working. However I still cannot ping the zeroshell on VLAN2. Sorry it took a while to respond, I got swamped with other stuff.January 25, 2011 at 10:00 pm #51313
I know it’s a late post but I think it’s beneficial to put this straight for anyone else reading this..
“As far as I know this is red hat linux based, correct?”
— No. ESX (early 2.X and 3.X versions) were somewhat based on RHEL, and used a number of RHEL components in addition to the proprietary VMware ‘vmkernel’ – but things have changed, and ESX 4 and above (especially 4.1 and above) do NOT include RHEL components. In fact, the existing ‘Service Console’ – taken from RHEL – has now been replaced with busybox in 4.1.
With regards to dropping into the ESX shell to ‘tinker’ – be very careful. You’ll void support warranties with most companies by doing this, because ESX is an ‘appliance’ more than it is an OS. Don’t install 3rd party tools unless you’re really linux-savvy, and know how to get yourself back out. I’m not even confident that the build tools are even on the newer releases, so you’ve probably a severe lack of compilers etc..
ESX 4 does bring many options for 3rd party plugins (Storage, Networking, Systems Mgmt etc) but these typically run in CIM memory space.
If you are to type any CLI commands (via local terminal, remote SSH, or VMware Remote CLI) then they should be VMware commands;
some other commands (tcpdump for example) are there – but aren’t always the standard binaries.
Some notes on VLANS and ‘NICs’ – which are actually ‘uplinks’ in ESX;
– vSwitches themselves don’t have any properties for VLANs. They carry anything.
– VM Port Groups allow you to specify a VLAN – so any traffic from VM hosts will come into the Port Group, and will be tagged (802.1Q) as they hit the vSwitch data plane.
– If VM hosts specify VLAN at the NIC driver stage (possible) then the tagged packets will come down through the port group and onto the vSwitch, then onto Uplink adapters to physical switch(es) – I think that the PortGroup will need VLAN 4095 specifying for this to work (4095 is catch-all, all VLANs allowed)
– Physical switch ports should be configured as trunks, able to carry multiple VLANs. You can use an access port (eg: VLAN2) but that will tag everything coming in as VLAN2, which isn’t always what you want.
– Physical NICs on an ESX host don’t have an IP, they are simply a copper pass-through to the physical connections outside the ESX server
– If any changes are to be made to a NIC, it’s usually knocking off features like TSO etc, which is a CLI job. In general, no tweaking is required – you just need to design the aggregation / failover policies depending upon… well… more than I care to detail right here 😛
You must be logged in to reply to this topic.