Reassign a vswif to a new vmnic

The VMware host in my lab is a Dell GX620 running ESX3.51 U2.  It has three NIC’s:
The embedded Broadcom BCM5751 Gigabit Adapter  (vmnic0)
3Com 3C905C-TX 10/100 Adapter  (vmnic1)
Intel 8254N Dual Port Gigabit Adapter  (vmnic2 and vmnic3)

The 3C905 isn’t entirely VMware compatible.  It can be used as a service console connection but will not function as a virtual machine uplink on a vSwitch.  It will always show disconnected.

I want to reassign the service console vswif to the 3Com adapter, keep the same IP address and move the service console port group to a new vSwitch.

VMware doesn’t like having two service console connections with different IP addresses in the same subnet, so I have two options.

1.  Create a service console connection in a different subnet and access the host from that subnet using the VIclient.
2.  Enter the commands directly on the host console.

I recommend option two.  Keep in mind that this process temporarily disrupts network communications to the host via the service console IP.

After obtaining physical access to the host’s console (or network access via a DRAC or ILO), log in and su - to establish root.

Remove vswif0 from vSwitch0
esxcfg-vswif -d vswif0  –ip=192.168.68.35  –netmask=255.255.255.0  –portgroup=SCX

Remove the SCX port group from vSwitch0
esxcfg-vswitch –del-pg=SCX vSwitch0

Create a new vSwitch for the service console;
esxcfg-vswitch -a vSwitch3

Assign the 3Com adapter to the newly created vSwitch
esxcfg-vswitch -L vmnic1 vSwitch3

Add the SCX port group to vSwitch3
esxcfg-vswitch -A SCX vSwitch3

Add vswif0 to the SCX port group and assign the IP address and subnet mask
esxcfg-vswif –add –ip=192.168.68.35 –netmask=255.255.255.0 –Portgroup=SC2 vswif0

Restart the VMware management service
service mgmt-vmware restart

Here’s vSwitch0, still connected to vmnic0 but minus the service console

And here’s the new vSwitch3 with the service console reassigned to vmnic1

Experimenting with STP and PortFast

Some STP Basics
On most Cisco Catalyst switches, STP is enabled on all ports by default.   Port initialization requires upwards of 30 seconds to complete, and can take as long as 50 seconds.
This thirty second “delay” can be attributed to the time required for the port to transition from Listening to Learning and finally to Forwarding.
The Listening and Learning transitions each require about 15 seconds.
This transition period can be painful for end users waiting to gain access to the network.  To the untrained IT person it can be misdiagnosed as “some sort of network issue”.

PortFast to the Rescue
Portfast shortens the Listening and Learning states allowing the link to transition to the Forwarding state in as little as three seconds.
This translates to quicker access to the network for the end user when they power on their PC, connect a laptop to a wired port, etc.
Enabling PortFast does not disable STP on the port, it simply allows us to get to the Forwarding state much faster.

Let’s enable PortFast on switch ports 1 – 4 using the spanning-tree portfast command.  IOS provides a reminder of the possible consequences.

Looping ports Fa0/2 and Fa0/3 reveals that we still have adequate loop protection as Fa0/3 transitions to a Blocking state within ~2 seconds.  Other hosts on the switch are not affected.
In this scenario, PortFast protects against mistakes made in the wiring closet or on the off chance that two access ports would become looped under a desk.  (don’t laugh, I’ve seen it happen)
Here’s a partial output from the show spanning-tree command.

Note that Fa0/3’s Role has changed to Back.  This is helpful information as it indicates that two or more ports on the same bridge are connect together.
Fa0/3’s Status has changed to BLK, effectively blocking the loop condition .

The Tech Savvy End-User
Let’s say an end user wants to add a couple of extra network ports to their cubicle.  Instead of calling the help desk and being questioned as to what unauthorized device they are trying to connect to your LAN, they pick up an unmanaged switch from local retailer and connect it to their access port, Fa0/2.  (for the sake of this post let’s assume we’re not MAC locking ports on the switch)

What happens when two ports on the parasite switch connected to access port Fa0/2 become looped?  This partial output from show spanning-tree provides some info.

This should generate a call to the help desk as Fa0/2 immediately transitions to a Blocking state, preventing traffic from the looped parasite switch from entering the network.
Role is indicating Designated (DESG) which means that Fa0/2 is not looped with another port on this switch.  The Type field provides additional information.  Self-looped is a good indicator that something interesting is happening on Fa0/2.  No other hosts on the access switch were impacted.

Conclusions
PortFast is a great feature and can be enabled without compromising loop protection.  You should think twice about ever disabling spanning-tree.  I’ve seen a looped parasite switch bring down a 400 node network where spanning-tree had been disabled or wasn’t available on the particular switches the client has deployed.  Yet another argument for purchasing quality switches for your infrastructure.

CDP, DTP, LOOP Reply and BPDU

A Cisco switch generates a small amount of network traffic as part of it’s normal housekeeping functions.
It’s important to be able to recognize normal “background noise” when looking at a packet capture.

Below is a packet capture from a Catalyst 3560.  The only device connected to the switch is  an Xp virtual machine running Wireshark.
Note the four types of packets that appear at regular intervals, STP, LOOP, DTP and CDP.  (click on the image for a larger view)

STP
A Spanning Tree Bridge Protocol Data Unit (BPDU) is sent every two seconds as part of the loop detection process.
This particular packet tells us that the root bridge is 00:22:be:21:3e:80, which also happens to be the switch we are connected to.

It is possible to prevent BPDU’s from being sent out an interface by enabling BPDU Filtering .

BPDU Filtering can be enabled globally for every port that has PortFast enabled by using the spanning-tree portfast bpdufilter default command.

Note this also disables loop detection on all access ports,  probably not a good idea under most circumstances.

LOOP
LOOP Reply is a Layer 2 keepalive packet that is sent every ten seconds by default.
The LOOP Reply verifies to IOS that the link is up.  The switch does not actually listen for a reply, it simply verifies that was able to send the packet out the interface.
Loss of three consecutive Layer 2 keepalives will cause the interface to transition to a down state.
It is possible to configure the interval between packets by using the keepalive interface configuration command.

DTP
Dynamic Trunking Protocol (DTP) is a Cisco proprietary protocol used to negotiate a common trunking mode between two switches.
A trunk link differs from an access port in that a trunk can transport more than one VLAN.
DTP packets are sent every thirty seconds by default.
If the switch port is configured as an access port using the switchport mode access command, DTP packets will not be sent from that interface.

When an access port is reconfigured as a trunk port, transmission of DTP packets will resume 30 seconds after the port is reconfigured.

CDP
Cisco Discovery Protocol (CDP) packets are sent every sixty seconds by default.
CDP provides information about the capabilities of a device to it’s connected neighbor.
CDP can be disabled and it’s not a bad idea to do so under certain circumstances especially if security is a concern.

CDP can be disabled globally with the no cdp run command.

CDP can also be disabled on a particular interface with the no cdp enable command.