You cannot use the vSphere client to edit the settings of virtual machines of version 10 or higher

Image

This was the message that greeted me after upgrading my ESXi Hypervisor with Free license to 5.5.
I’ve applied an Enterprise license to see if there’s a difference to the host license applied and there’s no change to the behaviour.

It seems if you don’t want the hassle of using a CLI to interact with your VM’s on a Hypervisor license, DO NOT UPGRADE THE VIRTUAL HARDWARE OF YOUR VMs to Version 10 hardware. Unless you’re running vCenter of course.

I’m unable to see a way round this to restore the use of the vSphere Client as a tool to modify the settings of the VM, and let’s be clear, all I want to do is change the vSwitch a VM is connected to as my LAB ESXi box is hooked up to four different switches and I move the VM’s around to recreate different scenarios.

I’m gutted. I’ll update if I find anything to help or back myself out of this mess.

Advertisements

Cisco SWITCH Campus VoIP Refresh. Part 3b – QoS Configuration

I can’t believe I’ve had to chop up not just the VoIP refresh section into three parts, but part three into A and B!

It’s surprised me a little and I must have a little more to say on the subject than I thought when I started putting finger to key last night. But, I AM trying to keep this in scope for the SWITCH exam, so we’ll discuss just the req’s for that in this article.

Configuration

First of all, in order to turn on QoS processing on the switch, we need to enable it with the mls qos global command.
This is something that’s easy to overlook as you’ll enter interface commands all day long, without this, they don’t count for anything.

SW3#sh mls qos
QoS is disabled
QoS ip packet dscp rewrite is enabled
SW3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW3(config)#mls qos
SW3(config)#do sh mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

Notice the result of the first command stating that QoS is disabled.
Then the show command entered shows the processing being turned on globally.

Under your switchport interfaces, there are many things that could be done, but as mentioned previously, keeping a tight scope to the SWITCH exam.

To demonstrate a few things here, I’m going to show that the interface is in default configuration and then apply four different commands, two of which are setting the VLAN id’s for Access and Voice VLANs.

SW3(config-if)#do sh run int fa 0/1
Building configuration...
Current configuration : 33 bytes
!
interface FastEthernet0/1
end
SW3(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled
SW3(config-if)#switchport access vlan 11
SW3(config-if)#switchport voice vlan 22 
SW3(config-if)#auto qos voip trust
SW3(config-if)#do sh run int fa 0/1
Building configuration...
Current configuration : 235 bytes
!
interface FastEthernet0/1
 switchport access vlan 11
 switchport mode access
 switchport voice vlan 22
 srr-queue bandwidth share 10 10 60 20
 priority-queue out 
 mls qos trust cos
 auto qos voip trust 
 spanning-tree portfast
end

So hopefully you can see, from four commands, I received eight lines of configuration.
That’s because the cheeky switchport host command is a macro which sets a port up for an end device, simlarly the auto qos voip trust command is the Auto-QoS command for non-Cisco IP-Phones to be attached to your access interfaces.

From an real world operational standpoint, Auto QoS is pretty much all you need for your access ports, the only thing that I’ll mention is, try and ensure you’re running the same release of IOS on all your particular switch models as QoS maps may be different between releases.

That’s the automatic portion of configuration covered, to just expand a little on manual configuration for the exam…

To configure an IOS switch to trust the markings on traffic entering an interface, use the following:

Switch(config-if)# mls qos trust {dscp | cos}

To configure the switch to trust the traffic markings only if a Cisco phone is connected, use the following:

Switch(config-if)# mls qos trust device cisco-phone

To set a COS value for frames coming from a PC attached to the phone, use the following:

Switch(config-if)# switchport priority extend cos <cos-value>

To verify the QoS parameters on an interface, use the following:

Switch(config-if)# show mls qos interface <interface>

Here we use the last command mentioned to see how the show command interprets the Auto-QoS settings of the commands we used earlier and a second interface which is default, for comparison (no devices are attached at this point).

SW3#sh mls qos interface fa 0/1 
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based
SW3#sh mls qos interface fa 0/2
FastEthernet0/2
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

Cisco SWITCH Campus VoIP Refresh. Part 3a – QoS Theory

QoS, a discussion

Now, funny one this. QoS is really important, right? You’ll hear people say QoS enabled network this, gotta have Quality of Service for VoIP/Video solution that, otherwise it’ll fail.

Read this statement and remember… Quality of Service is meant to combat TEMPORARY network congestion.

As a whole, on a switched campus network with 100Mbps access ports and 1Gbps uplinks everywhere, it’s unlikely, though not impossible that you need QoS. QoS will be there to catch you every time you find a link congested. That’s all!

You could just have QoS misconfigured on your switches – like I did once, thanks to a telco provider I may have mentioned in the past. It meant the campus VoIP solution went in, every one did a dance, we thought that we had a VoIP solution running on a QoS enabled network, which was only a half truth. We had a VoIP solution. The QoS wasn’t configured correctly, but no one knew any different – seemingly the telco’s installation engineers didn’t either – till a few years down the line I viewed the configs to find that they were doing diddly squat in terms of prioritisation.

It didn’t really matter though right? We had enough bandwidth so that the devices on the switches could pass data all day and the interfaces never became congested enough for long enough to cause support calls due to quality, and if there were support calls generated, the call quality could probably be put down to one end being a call to a mobile or another external party.

So that’s all well and good if you’re staying on Campus. Instantly, the moment your voice call traffic is going off Campus, the game changes.

For the SWITCH exam, the remainder of this discussion is a little off-piste, we’re not talking about Routers here which but we may be talking about Multi Layer Switch SVI’s which are default gateways for networks and subsequently may need to consider things like global synchronisation and congestion upstream.

IT Management buy links from an ISP/Telco based on the perceived or measured need for the organisation in chunks of Mbps/Gbps because of prohibitive costing of said links. If all WAN links were the same price per Mb as a campus switchport, everyone would choose big link numbers, but they don’t.

So, importantly, these link sizing decisions are all driven or least heavily influenced by the commoditisation [sic] or lack of, Internet and private link bandwidth.

Because link bandwidth isn’t as cheap as your local switchport bandwidth, It’s very unlikely at this point that you’re going to say, right then, 1Gbps VPLS/MPLS links from all our offices please Mr ISP/Telco!
Notice I said MPLS/VPLS. You could buy xMbps/Gbps Internet links, but your traffic in transit will not be treated with any priority, so all the good work that you do as a result of this article will be for nothing the moment it’s traversing the Internet alongside little Billy’s uTorrent traffic for the latest World of WarCraft ISO rip.

So if you’re putting your inter-handset RTP traffic or SIP trunk traffic on a WAN link, to ensure your QoS model is extended to service that traffic in transit, you need to be on some sort of provider VPN, most likely, VPLS or MPLS.
It’s quite feasible to put your traffic out there on the Internet using a Site-to-Site VPN or an tunnelled Handset/Softphone remote worker to Call Server session, but there’s no guarantees, no SLA’s, if the call quality is dodgy or you have call connection issues, you have to learn to get over it. It totally depends on your requirements and expectations.

Cisco SWITCH Campus VoIP Refresh. Part 2 – Voice VLANs

Voice VLANs

Back in the day, folks used to configure trunks out all the access ports in the switch to provide the ability for the IP Phones to push their voice VLAN data up the link along with the downstream access VLAN data from the PC.

This is a bad thing. I won’t go into it here, but those days are gone. You now use Dual VLANs, Voice VLANs, however you want to describe two VLAN’s only being accepted on an access port.

The idea is that ‘default’ compute data traffic is just assigned to the access VLAN configured on that switch port, and all the voice traffic which is sourced from the phone is punched into the voice VLAN that’s been configured on that switch port thanks to some clever CDP/LLDP communication where amongst other things like power negotiation, the switch informs the phone what it needs to do in terms of 802.1q tagging.

Configuration is particularly simple.

Ensure your switchport is an access port and configure a data VLAN which I hope is not VLAN 1.

SW3(config-if)#switchport mode access
SW3(config-if)#switchport access vlan 22
SW3(config-if)#switchport voice vlan ?
  <1-4094>  Vlan for voice traffic
  dot1p     Priority tagged on PVID
  none      Don't tell telephone about voice vlan
  untagged  Untagged on PVID

To set the voice VLAN, specify a VLAN number, this is by FAR the most common configuration use, and it ends there.

Other options are :
The dot1p option tells the phone to set CoS bits in voice packets while using the data VLAN.
The untagged option tells the phone to use the data VLAN without setting any CoS values.
The none option does what it says on the tin.

There is one other voice VLAN command which is a little obscure but seems to be a protection mechanism

SW3(config-if)#switchport voice detect cisco-phone full-duplex

This command can be entered without the full-duplex keyword.
The best description I can find about this command is that it appears if a device wants to communicate on the voice VLAN is has to have drawn PoE from the switch, speak CDP and be full-duplex.
Without the full-duplex keyword, I think it simply must just have to communicate on the voice VLAN and have drawn PoE from the switch, half-duplex is acceptable.
If these criteria aren’t met, the switchport goes into err-disable.
I guess the summary of that command is that you can’t go plugging anything into the port other than a CDP speaking PoE phone on either half or full duplex.

*Update* I haven’t been able to recreate this using an 1130AG Access Point, an ESXi host and a Switch to Switch link as test devices plugged into access ports.
What does happen however is you get a log message

*Mar  1 00:03:59.066: %CPDE-6-DETECT: Cisco IP Phone 7940 detected on FastEthernet0/24 in full duplex mode

Perhaps this is all it is? You can then use this information to track device usage, deployment from your log aggregation systems. Still, not a feature I’m going to lose sleep over.

 

Cisco SWITCH Campus VoIP Refresh. Part 1 – POE

Support for IP Phones is provided by all modern Cisco Catalyst switches.

The normal functions required to support the phones are:

PoE

This review of PoE goes far beyond the knowledge required for SWITCH 642-813

Standards

IEEE 802.3af known as PoE and providing up to 15.4W per port.
IEEE 802.at known as PoE+ able to provide up to 30W per port.

PoE on Switches which carry this feature is usually on by default.
To review your switches interfaces status for power use commands :

SW3#show power inline 
Available:370.0(w) Used:0.0(w) Remaining:370.0(w)
Interface Admin Oper Power Device Class Max
 (Watts) 
--------- ------ ---------- ------- ------------------- ----- ----
Fa0/1 auto off 0.0 n/a n/a 15.4 
Fa0/2 auto off 0.0 n/a n/a 15.4 
Fa0/3 auto off 0.0 n/a n/a 15.4 
Fa0/4 auto off 0.0 n/a n/a 15.4 
Fa0/5 auto off 0.0 n/a n/a 15.4 
<truncated for brevity>

Also to view consumption configuration

SW3#show power inline consumption 
Interface Consumption Admin 
 Configured Consumption (Watts) 
---------- ----------- -------------------
Fa0/1 NO 0.0
Fa0/2 NO 0.0
Fa0/3 NO 0.0
Fa0/4 NO 0.0
Fa0/5 NO 0.0
<truncated for brevity>

You can remove PoE from an interface by using the interface command

SW3(config)#int fa 0/1
SW3(config-if)#power inline never
SW3(config-if)#do sh power inline
Available:370.0(w) Used:0.0(w) Remaining:370.0(w)
Interface Admin Oper Power Device Class Max
 (Watts) 
--------- ------ ---------- ------- ------------------- ----- ----
Fa0/1 off off 0.0 n/a n/a 15.4 
Fa0/2 auto off 0.0 n/a n/a 15.4 
<truncated for brevity>

You can now see that the Fa0/1 interface will never provide power.

When PoE is enabled, the switch senses the real-time power consumption
of the powered device. The switch monitors the real-time power consumption
of the connected powered device; this is called power monitoring or power sensing.
The switch also polices the power usage with the power policing feature.

One option is to limit the power sensing budget globally, or on a per port basis

By using the power inline consumption wattage configuration command,
you can override the default power requirement specified by the IEEE classification.
The difference between what is mandated by the IEEE classification and what is actually
needed by the device is reclaimed into the global power budget for use by additional devices.
You can then extend the switch power budget and use it more effectively.

For example, if the switch budgets 15,400 milliwatts on each PoE port as it does by default (3560/3750),
you can connect only 24 Class 0 powered devices. If your Class 0 device power
requirement is actually 5000 milliwatts, you can set the consumption wattage to
5000 milliwatts and connect up to 48 devices. The total PoE output power available
on a 24-port or 48-port 3560/3750 PoE switch is 370,000 milliwatts.

Globally:

SW3(config)#power inline consumption default 5000
%CAUTION: Misconfiguring the 'power inline consumption/allocation'
 command may cause damage to the switch and void your warranty. Take
 precaution not to oversubscribe the power supply. Refer to documentation.

Strangely, there doesn’t seem to be a show command which you can see that this global command is in effect.
Neither these commands have a different output as a result of this command being configured.

SW3#show power inline 
SW3#show power inline consumption

Whereas, the per interface configuration below shows up in the command

SW3#show power inline consumption 
Interface Consumption Admin 
 Configured Consumption (Watts) 
---------- ----------- -------------------
Fa0/1 NO 0.0
Fa0/2 YES 5.0
Fa0/3 NO 0.0

Per Interface, you can configure your ports as such

SW3(config-if)#power inline consumption 5000 
%CAUTION: Interface Fa0/2: Misconfiguring the 'power inline
 consumption/allocation' command may cause damage to the switch and void
 your warranty. Take precaution not to oversubscribe the power supply.
 It is recommended to enable power policing if the switch supports it.
 Refer to documentation.

As noted in the warning from the above budget modifications, you should enable power policing to prevent drawing so much power that you cause your switch to fail.

You can do this only on a per interface basis, so I’d recommend an interface range command on all your access ports

SW3(config)#interface range fastethernet 0/1 - 48
SW3(config-if-range)#power inline auto max 5000

Cisco Switch Supervisor Redundancy

Non-Stop Forwarding with Stateful Switch Over

Layers 2–4 (MAC addresses, IP Routes and TCP/UDP Sessions) convergence time is enhanced in Cisco 4500 and 6500 series switches by purchasing redundant route processors (RP) and holding them both in the same 4500/6500 chassis using NSF with SSO.

When using SSO with NSF, only one RP is active. The standby RP synchronizes its configuration and dynamic state information (such as CEF, MAC, and FIB tables) with the active RP. When the active RP fails, SSO enables the standby RP to take over immediately. NSF keeps the switch forwarding traffic during the switchover, using the existing route and CEF tables.

The goal of NSF with SSO is to prevent routing adjacencies from resetting, which prevents a routing flap. The switchover to the new RP must be completed before routing timers expire, or the router’s neighbors will tear down their adjacency and routing will be disrupted.
When the new RP is up, the old routes are marked as stale, and the RP asks its routing peers to refresh them. When
routing is converged, it updates the routing and CEF tables on the switch and the linecards.
NSF is supported with EIGRP, OSPF, ISIS, and BGP. An NSF-capable router supports NSF; an NSF-aware router does
not support NSF but understands it and continues forwarding traffic during SSO.

Use NSF with SSO in locations where you do not have a duplicate switch for failover, such as at the user access or Enterprise network edge. Otherwise it can actually cause longer convergence. Routing protocols timers can be tuned very short to provide fast convergence. With SSO, the switchover to the standby RP might not occur before the tuned routing Dead timer expires, and the adjacency would be reset.

Cisco Logging and Syslog

This short guide can help you plan for your device’s logging parameters from point of installation.

So, you probably want to keep more than what’s in the buffer.
Or, if you don’t, you probably want to make the buffer larger so when you do need it, there’s a chance of some context to the fault that drove you there in the first place.

Interacting with the device

First thing.

Stop the logging messages from interrupting your command statements.

line con 0
logging synchronous
line vty 0 4 
logging synchronous

Now you can read the messages without having your commands wrapping in and around them, what level of messages do you want?

If you’re on the console/ssh session of the device, it’s likely you’re there, and you want to see what’s going on.
The default on these two connection types is (7) debugging and you can leave it there.
If you do choose to change them, the commands are simply

logging console <level> 
logging monitor <level>

Now, choose to keep your logs local or on a central syslog server. It’s not hard to understand why as soon as you’ve more than one or two devices, syslog servers are your friend.
So, for those of you who keep it small and only want the device dealing with the logs, here are your choices.

Setting the level of messages that are kept in the buffer, and the size of the buffer which by default it 4096 bytes (4Kb).

logging buffered <level>
logging buffered <4096-2147483647>

For when you’re keeping log messages centrally in a syslog server, here’s your commands.

logging host 1.1.1.1 
logging on

To verify your configuration use

show logging

You are now setup for a situation where you can enjoy being on the console without the logging messages interfering with your commands and you’ve planned how and where you want your log messages kept.