Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1712
  • Last Modified:

VM Guest Not Getting A Network Connection On New VLAN

I have a VM environment running and a Cisco UCS with various different VLANs on it, all working. The VM environment has a virtual switch and a Cisco Nexus v1000. I have built the VLAN and spanned it out to the UCS and a test switch elsewhere. I have plugged a physical machine into a switch that has the VLAN spanned to it and was able to obtain a DHCP address form the scope I built so I know that it is working. I have added the VLAN on the correct server on the UCS and allowed its NICs to see it. I then went to VCenter and added the new port group to the vswitch, being we are not using the v1000 on this host, and configured the port group with the appropriate VLAN ID and Network Label. Finally I went to the Guest and assigned it to the new network label, yet the guest will only get limited or no network connectivity. I know I have to be missing something, we have other VLANs on this Host that work just fine with its Guests and they are dynamic as well. Any help is appreciated.
0
Cyprusice
Asked:
Cyprusice
  • 10
  • 6
2 Solutions
 
Danny McDanielClinical Systems AnalystCommented:
did you enable trunking on the port on the switch?
0
 
CyprusiceAuthor Commented:
Inside a vSwitch is the concept of a portgroup. The portgroup is assigned a VLAN ID. Just like you assign a group of ports on a pSwitch to have a VLAN you do the same in the vSwitch using a portgroup. Just make a portgroup on the vSwitch and give it a VLAN ID. This is called Virtual Switch Tagging (VST).
pub
0
 
CyprusiceAuthor Commented:
Well that was not exactly what I wanted to post as far as text, but the idea is the same. When you are referring to enabling trunking I am assuming you are talking about the port on the pSwitch or in this case the core that is connected to the UCS? If that is the case yes it is enabled. It is important to note that this same physical connection delivers other vlans to the blades in the UCS including the one that I am working with. The port group I am using on the vSwitch seems to be identical to the one that works, yet apparently there is something I am missing that is different. Did I answer you question?
0
Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

 
CyprusiceAuthor Commented:
Here is the config for the physical connection to the UCS


interface TenGigabitEthernet1/3
 description UCS_Side_A
 no ip address
 switchport
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 256 mode on
0
 
Danny McDanielClinical Systems AnalystCommented:
if you remove the VLAN ID from the vswitch and leave the other switch configs in place, does the guest then have network connectivity?
0
 
CyprusiceAuthor Commented:
No Sir,  it does not work if I remove the VLAN ID. I have it set to none and the same results occur.
0
 
Danny McDanielClinical Systems AnalystCommented:
so, this problem host doesn't have v1000...is this VLAN working on the hosts do have the v1000?

It's sounding like the UCS is where the disconnect is happening.
0
 
CyprusiceAuthor Commented:
That is right this issue does not involve the v1000 that we have. This is because all the physical NICs we have on this host are connected to the vSwitch instead. We did try the VLAN on another host with the v1000 and it was a no go as well. It does sound like an issue at the UCS but I am not sure where.  
0
 
CyprusiceAuthor Commented:
So here is what I have done with the UCS;
I created the VLAN in the UCS under the VLANs which is found under the LAN tab
then I added the newly created VLAN under each NIC for the Server.
As far as I know that should be it.
Right?
0
 
Danny McDanielClinical Systems AnalystCommented:
0
 
CyprusiceAuthor Commented:
Yep I have followed this document for a Named VLAN.
0
 
Danny McDanielClinical Systems AnalystCommented:
I think I'd give a call to support at this point.  If you bought the EMC/Cisco/Vmware bundle, there's a special number for an integrated support team.  Otherwise; start with Cisco support, then try VMware's group.  the VMware team is used to getting calls that aren't exactly their territory (everybody blames the new guy on the block ;) ), just make sure you select Networking in the phone tree or dropdown.  

Whenever you buy a VMware license, you have to buy support with it, so depending upon how long that initial support was paid for, you may be covered and not know it.
0
 
CyprusiceAuthor Commented:
I agree it looks like it was heading that way. I just opened a TAC case, see what pans out form it. Thanks for you help thus far.
0
 
CyprusiceAuthor Commented:
Turns out that it was a miss-configuration with the channel groups between the connecting switch and the UCS. We think that the reason it was working before was because we were running on an older version on the UCS and recently we upgraded the UCS and that is when we think this issue started.
0
 
Danny McDanielClinical Systems AnalystCommented:
Hey, thanks for updating us on the cause and the undeserved points!  :)  Don't you just hate it when they "fix a glitch" that was working fine before...
0
 
CyprusiceAuthor Commented:
.
0

Featured Post

Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

  • 10
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now