VM connectivity issue

mhasabal · ‎07-02-2010

Happy 4th everyone

Please help me out to understand the no connectivity issue i am experiencing for one of the VMs "V1"

please see attached text config file

interface Vethernet7

inherit port-profile data_vlan172

description V1, Network Adapter 1

vmware dvport 512

port-profile type ethernet vm-data-uplink

vmware port-group

switchport mode trunk

switchport trunk allowed vlan 4,172

no shutdown

system vlan 4,172

state enabled

port-profile type vethernet data_vlan172

vmware port-group

switchport mode access

switchport access vlan 172

no shutdown

system vlan 172

state enabled

----------------------------------------------------------------------------------

N1000vUCS# sh vlan

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Eth3/2, Eth4/4, Eth5/2

4 MGMT_VMWARE1000V active Veth1, Veth2, Veth3, Veth4

Veth5, Veth6, Veth8, Veth9

Veth10, Veth11

120 CONTROL_UCS active

130 PACKET_UCS active

172 VLAN0172 active Veth7

VLAN Type

---- -----

1 enet

4 enet

120 enet

130 enet

172 enet

------------------------------------------------------------------------

i am not able to ping the default GW 172.20.1.254

currently the VM has static IP 172.20.1.35/24

---------------------------------------------------------------------

N1000vUCS# sh ip arp vethernet 7

IP ARP Table

Total number of entries: 0

Address Age MAC Address Interface

-----------------------------------------------------------------------------

N1000vUCS# sh ip arp summary

IP ARP Table - Adjacency Summary

Resolved : 0

Incomplete : 0

Unknown : 0

Total : 0

abbharga · ‎07-02-2010

Hi,

Looking at the outputs, is this N1K running on a UCS system?

If so can you verify if you have defined vlan 172 on the UCS system and also attached it to the vmnic under the service profile? Also if its native vlan on the UCS vmnic you will have to mark it as native on the uplink port-profile.

./Abhinav

mhasabal · ‎07-02-2010

abbharga

thanks for the reply.

vlan 172 is not defined on the UCS, but from the n1k i am able to hit the 4500 core sw

abbharga · ‎07-02-2010

you will have to define the vlan 172 on the UCS. Can you explain more on what you mean by hitting the 4500 from the n1k?

mhasabal · ‎07-02-2010

i am able to ping the gw 172.20.1.254 from the n1k

mhasabal · ‎07-02-2010

i was able to define vlan 172 from the LAN tab for both fabrics A & B when adding the vlan on the service profile it shows an overlap

abbharga · ‎07-03-2010

The ping from the N1k to the GW IP is via the mgmt0 interface, where as the traffic for the VM on vlan 172 will be carried on the uplink interfaces from the blade to the 6120 and up north, for this you need to define the vlan 172 on the UCS, add it to the vmnic (which will trunk the interface from the 6120 to the blade) and automatically add / trunk the vlan on the uplink interface on the 6120.

You need not define the vlans individually on the FI-A & FI-B, whie creating the vlan you can configure it as a global vlan which will define it on both the FI.

./Abhinav

sean.wang · ‎07-20-2010

If your configurations are correct, and if your ping is not even working without going through any routing hops, check if you have hit a bug that causes VM connectivity and ARP issue. I have posted details below, interested in if there are other Nexus 1000v users hitting the same bug.

http://www.seanxwang.com/2010/07/nexus1000v-bug-widespread-vm.html

Robert Burns · ‎07-20-2010

@Sean - Are you referring to CSCte96034 "MAC move packet must be sent to broadcast address" ? This bug was causing MAC move notifications to be discarded based on the destination address being used.

This bug has been fixed in the latest release 4.0.4.SV1.3. Information on this bug can be found in the bug toolkit -> http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCte96034

If this isn't one you're referring to let me know the bug ID if you have it and I'll see if I can provide any further details.

Robert

sean.wang · ‎07-21-2010

Robert, it's a different bug, CSCtg72137. Thanks.

Robert Burns · ‎07-21-2010

That will be fixed in the upcoming maintenance release 4.0(4)SV1(3a) due out next week.

Robert

sean.wang · ‎07-21-2010

Yes, got an early trial, and confirmed the fix.

It was a particularly nasty bug that all users should be warned, given its impact, and difficulty tracking down.

4.0(4)SV1(3a) fixed a number of bugs, and should be upgraded to immediately.