Pages

Tuesday 18 October 2011

ESXi 5.0 Load Balancing Test: Route based on the originating virtual port ID

Within ESXi 5.0, there are 4 methods of Load Balancing.  As stated in the help

Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.

Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.

Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.


Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.


This test is to review what "Route based on source MAC hash" does and how it perform the required traffic load balancing.

Wednesday 12 October 2011

ESXi 5.0 Load Balancing Test: Route based on IP hash

Within ESXi 5.0, there are 4 methods of Load Balancing.  As stated in the help

Route based on the originating port ID Select an uplink based on the virtual port where the traffic entered the standard switch.


Route based on ip hash Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.

Route based on source MAC hash Select an uplink based on a hash of the source Ethernet.


Use explicit failover order Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.

The test below is to test and study what "Route based on IP hash" does and how it perform traffic load balancing.

ESXi 5.0 Load Balancing Test: Route based on the originating virtual port ID

Within ESXi 5.0, there are 4 methods of Load Balancing.  As stated in the help

Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.

Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.
Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.
This test is to review what "Route based on the originating port ID" does and how it perform the required traffic load balancing.

Tuesday 11 October 2011

vSwitch Network Failover Detection Testing: Beacon Probing and Link Status

In ESXi 5.0, under vSwitch Network NIC Teaming, there is a Network Failover Detection field.  It has two setting, Beacon Probing and Link Status Only.

Under the help Section, it state the following,

Link Status only
Relies solely on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or mis-configured to the wrong VLAN or cable pulls on the other side of a physical switch.
Beacon Probing
Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. This option detects many of the failures mentioned above that are not detected by link status alone.
Note: Do not use beacon probing with IP-hash load balancing.
 

After three days of testing over weekends, I found Beacon Probing is very confusing, but it works.

Link Status is what stated above, nothing much to test.  But Beacon Probing is Beacon + Link State.

Wednesday 5 October 2011

vSwitch Networking Security Testing - Part 2 MAC Address Changes

In ESXi 5.0 Networking Security, each vSwitch has the following Security Policy Tab.


  • Promiscuous Mode: Accept or Reject
  • MAC Address Changes: Accept or Reject
  • Forged Transmits: Accept or Reject
In part 2 of this test lab, I am exploring the MAC Address Changes setting and the effect of setting it to Accept or Reject.

A Windows 2008 R2 Server VM is installed in the ESXi 5.0 Server and a Port Group is created for this VM.


Under the help menu of "Edit Security Policy for a vSphere Standard Switch".  It state the difference between these two setting
  • MAC Address Changes
    • Reject - If you set the MAC Address Changes to Reject and the guest operating system changes the MAC address of the adapter to anything other than what is in the .vmx configuration file, all inbound frames are dropped.
      If the Guest OS changes the MAC address back to match the MAC address in the .vmx configuration file, inbound frames are passed again.
    • Accept - Changing the MAC address from the Guest OS has the intended effect: frames to the new MAC address are received.

  • Forged Transmits 
    • Reject - Any outbound frame with a source MAC address that is different from the one currently set on the adapter are dropped.
    • Accept - No filtering is performed and all outbound frames are passed.
After reading this, I am totally confused.  My understanding from the statement is that if you change the MAC Address of the vNIC of the Guest VM, "Mac Address Changes: Reject" drop inbound traffic and "Forged Transmits: Reject" drop Outbound traffic.

The confusion is, reference to where? or from which perspective?  While doing networking for so many years, I came to understand that when we come to "Inbound" traffic and "Outbound" traffic, we must think like a Router or Switch.  If I am a Router, any traffic that is coming into me is an "Inbound" traffic, the traffic can be from any interfaces.  That goes the same to any traffic that is going out of me, which is an "Outbound" traffic, it can also be going out of any Interfaces.  That goes the same if your are a Server.

But in the case of a Server it's "Inbound" traffic is the Physical Switch "Outbound" traffic, and the Server "Outbound" traffic is the Physical Switch "Inbound" traffic.  When we read the traffic, we have to know where we stand.  Inside the Server? or Inside the Switch.  That is what I called perspective of things.

The problem with the above statement is that it does not state the "Inbound" and "Outbound" is from which perspective.  From the virtual machine or from the virtual switch. 

In any case, I am doing some test to find out.



Friday 30 September 2011

vSwitch Networking Security Testing - Part 1 Promiscuous Mode

In ESXi 5.0 Networking Security, each vSwitch has the following Security Policy Tab.
  • Promiscuous Mode: Accept or Reject
  • MAC Address Changes: Accept or Reject
  • Forged Transmits: Accept or Reject
In part 1 of this test lab, I am exploring the Promiscuous Mode setting and the effect of setting it to Accept or Reject.

A Windows 7 VM is installed in the ESXi 5.0 Server and connected to the same VLAN as the Management Traffic. 

WireShark is installed in the VM to capture the traffic in the vSwitch.  Microsoft Network Capture is used to open the WireShark captured packet.   MS NCap is use because NCap can do a better job in sorting TCP Session as compare to WireShark.

Wednesday 28 September 2011

ESXi 5.0 Management Network Interface Testing - Part 2

Part 2 of the Management Network Interface Testing is about miscofig of ESXi Management Network Interface.

Misconfiguration happened very day and is part of life.  We learned from our mistake and gain experience from our mistake. 

In this part 2 of the test, three tests will be performed
  • Duplicate IP address of current Management IP in the same network segment.
  • Misconfig of Management Network IP.
  • Delete of Management Network IP that is currently connecting to vCenter.

ESXi 5.0 Management Network Interface Testing - Part 1

During the course of upgrading my ESX 4.1 Server farm.  I notice that the behaviour of ESXi Management Network Interface is different from the Service Console of ESX 4.1.  With that, I decided to further test and understand the concept and deployment of  multiple Management Interface of ESXi 5.0.

Test Objectives
The test objective is to test the redundancy of ESXi Management Network Interface for vCenter connectivity and SSH.  Objective is to recover ESXi remotely should a portion of the network failed.

Saturday 24 September 2011

ESXi 5.0 Kickstart Installation Part 4 - The Kickstart File Result

ESX 5.0 Kickstart Installation

Below is the result of the Kickstart Script. 


vSwitch0



ESXi 5.0 Kickstart Installation Part 3 - The Kickstart File

# +---------------------------------------------------------------------------+
# | Kickstat File : ESX07
# +---------------------------------------------------------------------------+



# +---------------------------------------------------------------------------+
# | Start of ESXi 5.0 Kick Start Script (22 Sept 2011)
# +---------------------------------------------------------------------------+



# +---------------------------------------------------------------------------+
# | Accept License agreement
# +---------------------------------------------------------------------------+
vmaccepteula



# +---------------------------------------------------------------------------+
# | Disk Partitioning
# | Clear all partitions in first detected disk and overwrite any VMFS
# | partitions on the specified drives.
# +---------------------------------------------------------------------------+
clearpart --firstdisk --overwritevmfs


ESXi 5.0 Kickstart Installation Part 2 – Getting the Kickstart Script kicking

ESX 5.0 Kickstart Installation

OK.  I must say, looking into VMware “vSphere Installation and Setup” guide for help doesn’t do much help.  Or, you only got 10% of the script required. 

Limited VMware Documentation

For booting and locating the Kickstart file, you can look into vSphere 5.0 documentation
Under the section "Boot Options", you will find some commands option to tell ESXi where to locate the kickstart script.

As for the kickstart script, you can find some information in
ESXi and vCenter Server 5.0 Documentation > vSphere Installation and Setup > Installing, Upgrading, or Migrating Hosts Using a Script > About Installation and Upgrade Scripts
Under the section “Installation and Upgrade Script Commands”.   You will find some commands there, but it will not bring you far for your scripting customization. 

Most ESX 4.1 Kickstart Script Don't Work
With my experience in creating kickstart script in ESX 4.1, I decided to reuse most of my 4.1 kickstart script. To my surprise, most of the command failed. That left me with no choice but to learn how to write vSphere 5.0 kickstart from basic again. 

ESXi 5.0 Kickstart Installation Part 1 - Getting the USB Drive Ready

ESX 5.0 Kickstart Installation

As I have 7 ESX 4.1 Servers in my Environment each with many VLANs, iSCSI and NFS Setting, I need to find a way to automate the installation and create a script that will bring consistency setting across my ESX farm.  This is where I spend 2 days understanding the different options to automate this process.

I have dropped the use of DHCP+PXE+TFTP as it is too complicated to setup if I have another site to install.  In addition, I can’t bring my whole DHCP+PXE+TFTP Servers setup into another site.  In addition, if the installation site is in Customer environment, addition a DHCP+PXE+TFTP sound like a lot of things to explain and answer to customer.

Upgrade ESX 4.1 update 1 to ESXi 5

vSphere 5 is out! Manage to find some time this week to upgrade my ESX 4.1 update 1 environment to vSphere 5.  For those people out there using ESX(i) whitebox, below is my whitebox configuration that works with ESX(i) 4.1 and ESXi 5.

Item
Description
Qty
Cost
Total (SGD)
1
Gigabyte x58A-UD3R
1
$ 365
$ 365
2
Intel i7-960 3.2 GHz
1
$ 377
$ 377
3
Asus EAH5450 Silent 1 GB DDR3
1
$ 79
$ 79
4
Kingston 12800/1600 (3x4GB in a kit)
2
$ 219
$ 438
5
Seagate 1 TB 32MB 7200rpm
1
$ 82
$ 82
6
Seagate 1.5 TB 32MB 7200rpm
1
$ 105
$ 105
7
Andyson F650M 650W Modular 80+
1
$ 135
$ 135
8
Samsung S222 22x DvD+-RW
1
$ 22
$ 22
9
Intel Gigabit ET Dual Port Server Adapter E1G42ET
2
$ 225
$ 450
10
Normal Casing
1
$ 72
$ 72

Total (in Singapore Dollars)


$2,125

Wednesday 14 September 2011

Switching Lab Core Switch 2 Config

!

!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Core2

Switching Lab Core Router 1 Config

!

!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Core_R1

Switching Lab Distribution Switch 2A Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Dist2A

Switching Lab PC2 in VLAN 22 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PC2_V22

Switching Lab Server 4 in VLAN 12 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SRV4_V12

Switching Lab Server 3 in VLAN 12 Config

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SRV3_V12

Switching Lab Server 2 in VLAN 11 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SRV2_V11

Switching Lab Server 1 in VLAN 11 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SRV1_V11

Switching Lab PC 4 in VLAN 24 Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PC4_V24

Switching Lab PC 3 in VLAN 23 Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PC3_V23

Switching Lab PC2 in VLAN 22 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PC2_V22

Switching Lab PC1 in VLAN 21 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PC1_V21

Switching Lab External Router Config

!
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname EXT_R1

Switching Lab Access Switch 22 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ASW_22

Switching Lab Core Router 1 Config

!

!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Core_R1

Switching Lab Core Router 2 Config

!

!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Core_R2

Switching Lab Access Switch 21 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ASW_21

Switching Lab Access Switch 12 Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ASW_12

Switching Lab Distribution Switch 2B Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Dist2B

Switching Lab Access Switch 11 Config

!

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ASW_11

Switching Lab Distribution Switch 2A Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Dist2A

Switching Lab Distribution Switch 1B Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Dist1B

Switching Lab Distribution Switch 1A Config

!
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Dist1A

Switching Lab Core Switch 2 Config

!

!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Core2

Switching Lab Core Switch 1 Config

!

!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Core1

Cisco Switching Lab on GNS3

Finished conducting an internal training on Cisco CCNP Switching Exam 642-813.  Rather than getting physical Switches and Routers for this internal training, I decided to run the lab virtually on GNS3 in my ESX lab.

It took me one week (5 nights and two full days over weekend) to get the lab up and running on Windows 7 as a guest OS in ESX 4.1.  Reasons for spending such a long time is because of the IOS images problem with 3745, 3725 images.  You can't save 3745 and 3725 configuration.  Have also tried to use 1821 images for emulation of PC (because of the 64MB footprint), but hit into CPU utilisation problem.  I just can't bring down the high CPU utilisation.

Cleared VCP4!

Cleared VMware Certified Professional (VCP4) on 16 June 2011.  Moving forward, will attend VCP5 in the next 3 months.