vSphere client on Surface pro 3 / Windows 8.1 input issues

So here's an irritating issue... I have a Surface Pro 3, I really like it, however there are a few niggles and issues but on the whole it's great. (You generally get issues with new versions of windows anyway, anyone remember vista? and windows 7 wasn't perfect for a long time, although it's pretty damn stable now). 

One of these issues was that I couldn't use the VMware vSphere client to control virtual machines using the console on my SP3. The cursor wasn't in sync with the screen. I'd put the cursor in the middle of the screen and it would register further down and off to the right. This made it almost impossible to click anything. I got around this by creating a virtual machine and using RDP to connect to the virtual machine and then connecting that way but it's a bit of a mess.

So here's the actual solution, if you right click the vSphere client icon > Properties > Compatibility > then check the box which disables display scaling on high DPI.

This runs the application natively on the display, which makes everything very small because the screen resolution is fantastic, but I kinda like this, you get more real-estate. It messes up a few positions such as text boxes slightly screwy but at least it works!

I couldn't find any other pages which detail this issue so hopefully this'll help someone else with the same issue.

installing Windows XP in VMware ESXi

I'm relatively new to VMware, but it's on my list of things to look into / learn about, and as part of my little lab I'm building I've installed ESXi5.1 as the Hypervisor on my server. I've always used VMware Player and Workstation before and they are so easy to use but I wanted to use ESXi because it's a little more "real world".

Windows XP is one of my "go to" VMs, it's so quick and easy to install, I've only got trial versions of 7 and 8 and i'm just not familiar with Linux (although I'm trying... give me time) However XP and ESXi don't seem to get on initially.

It turns out XP, being the old OS that is is, does have the SCSI drivers needed, and ESXi chooses a SCSI hard drive by default.

There are two options here:
Install the 3rd party drivers in the XP host, here are the instructions for this:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000863

Alternatively, you can just change the hard disk type to IDE and that works a treat too:

Bridging Cisco Wireless Router to an AP (Or your Phone!!)

Doesn't it just feel great when you figure something out after being stuck on something for a little while? This was one of those moments...

I'm going through the motions for building a portable lab whereby I can test various applications and software and features and one of my initial considerations was how to get Internet access to the lab. I've got a 1841 with a 3G HWIC module inside it so I could buy a sim and configure that but the plans for 'non-mobile' devices are crazy expensive, plus I'm already paying for an unlimited internet package for my phone so it just feels wrong spending more money. The other option is tethering the phone to the LAN in some way - either via a USB to RJ45 adapter (but then I can't charge and tether my phone at the same time) or 2ndly some way wireless-ly, and it turns out this is very possible with a feature called universal client mode.

Universal Client Mode allows the router / AP to connect to a wireless device as though it was a client, very cool! So I able to use the portable hot-spot functionality of the phone, and connect to the phone from the router as though it was a client, below is a rough diagram of the setup:

"Free" access for my Lab.

So now here's the important bit, the configuration. I couldn't find any other bogs etc where people have done this, there are similar things but not exactly this and as such I spent some time figuring this out so I'm putting it here for future reference, and hopefully it'll help someone else out in the future.

! first of all you need to configure the radio:
interface Dot11Radio0

! Tells the router to act in universal client mode

station-role non-root 

! Set the IP address to be obtained using DHCP
ip address dhcp

! create the ssid - has to be the same as the ssid advertised from the phone
dot11 ssid SSID_NAME

!set the authentication - I've used open
authentication open

! Go back into the dot11 radio interface and associate the ssid to the interface
interface Dot11Radio0
ssid SSID_NAME

At this point you should have a virtual-dot11radio interface configured and it should receive and IP address from the phone.

And from here you just create a default route, setup NAT and "jobs a good 'un".

A couple of notes: you have to make sure there is no vlan X command because Universal Client Mode needs to use the native vlan (I.E. no vlan configured)

Also, when I added the default route I had to manually set the IP address of the phone I.E. 192.168.43.1 (in my case) it didn't work when I set the exit interface as either dot11radio0 or the virtual-dot11radio0. I don't know why, perhaps someone can comment? But that's well worth noting.

Excellent!

Here's a quick update, if you are not happy without any encryption you can add WPA2 encryption with a Pre-Shared Key (PSK) with these commands:

!Under the dot11 SSID config:
 authentication key-management wpa
 wpa-psk ascii 0 password

!Under the dot11radio interface:
encryption mode ciphers aes-ccm


!!Update number 2!!
So I managed to break my NAT translations, I was playing with settings and "cleaning up the config" and I noticed that my lab VMs had lost internet connectivity.
I've since fixed it but my method is not 100% conventional. I had to change my NAT statement to refer to the pool of IP addresses being translated rather than the exist interface (virtual-dot11radio0) for some reason my NAT statement and default route doesn't work if I point to the virtual-dot11radio0 interface. The simple fix is to use the IP address rather than the interface but I'm a little wary because IP addresses can change. We'll see, if I find away around this I will update again. Anyway for the time being, here are the revised NAT statements:

ip nat pool NAT-POOL 192.168.43.183 192.168.43.183 netmask 255.255.255.0

ip nat inside source list PERMIT-NAT pool NAT-POOL overload

ip access-list standard PERMIT-NAT
permit 172.16.213.0 0.0.0.255

OSFP LSA types 1-7

I'm going through the process of decertifying my CCNP and one thing I can never recall from memory is a good description of each of the OSPF LSA types. Therefore it gets a quick blog post to aid the old memory.

LSA Type 1 (Router LSA):

Routers each create a type 1 LSA for each area they connect to in order to represent themselves within an area. Therefore the LSDB for an area will contain one type 1 LSA  for each router in the area. 

LSA Type 2 (Network LSA):

The type 2 LSA is created by a DR to detail the subnet and connected router interfaces in that subnet.

LSA Type 3 (Network Summary LSA):

The type 3 LSA is used to advertise subnets listed in one area to another area. The is created by an ABR. 

LSA Type 4 (ASBR Summary LSA):

The type 4 LSA is created by an ABR when it receives a type 5 LSA from a ASBR. This LSA is required in order to support the tie breaking logic for best path selection for routers, internal to an area, when calculating the best path to an external network in another area. This is required because E2 external routes do not increment the metric when travelling through the network, therefore a router in an area could have 2 (or more) paths to the external network. The tie break logic says that even though the metrics tie the router should put into the routing table the best route to reach the ASBR. So if it had a fast Ethernet connection and a serial connection even though the metrics would be the same (20 by default for an E2) instead of load balancing the router looks up the best path to reach the ASBR and puts this route into the routing table.

Now the above logic works fine if the router and the ASBR are in the same area. If not then the router can calculate the best path to the ABR but beyond this it has no awareness of the topology. This is where the type 4 LSA comes in. A type 4 LSA is generated by an ABR and details the ABR cost to reach the ASBR. This solves the above problem because where a internal area router has 2 ABRs out of the area, it now knows the cost of each ABR to reach the ASBR in the other area and so can make the best path selection accordingly.

LSA Type 5 (AS External LSA):

The type 5 LSA is used to advertise external routes into an area, this is created by the ASBR.

LSA Type 6 (Group Membership):

Unused on Cisco IOS so I'm ignoring it for the time being

LSA Type 7 (NSSA External LSA):

The type 7 LSA is created by an ASBR in a stub area to advertise external routes from an ASBR within that stub area. Stub areas suppress type 5 LSAs therefore an ASBR in a stub area uses type 7 LSAs within the stub which are then converted to type 5 LSAs at the ABR. Stub areas with an ASBR are NSSAs (Not So Stubby Areas)

I might well update this as I read and learn more but for the time being it's a good reference for me. 

Juniper Part number confusion

So this is another one which should be very obvious but again I'd never questioned it until recently, so I'm jotting it down for reference.

For Juniper's larger routers (MX etc) there are a number of items which are redundant - PSU, RE, SCB etc. Now when looking through the price list these items each have 3 different part code options: -BB, -R, -S

Here are the differences:
-BB = Base Bundle - This item is purchased when buying a new chassis and is often discounted because of this. You cannot purchase this item with the complete chassis.

-R = Redundant - This item is purchased with a complete chassis when you want a redundant item. For example, if you require a chassis with 2 SCB then you would purchase 1 -BB and 1-R.

-S = Spare - This item is purchased often if you are upgrading an existing chassis - I.E. replacing an item in an existing chassis with a new item, or adding a redundant component to an existing chassis.

Cisco MSE Appliances need L2 adjacency for HA operation

HA is a wonderful thing for obvious reasons but you do have to tread carefully sometimes when designing and deploying it.  I am specifically referring to the appliances / applications themselves and their physical location. Some appliances need to be located on the same subnet, which usually means physically very close. You can often fudge this by extending the layer 2 domain (such as using OTV) but this can be dangerous due to latency etc which can cause some unpredictable results, and not always practical.

MSE (7.4) is one of these applications. It maintains a health monitor connection to keep the two appliances synchronised and up to date.

LX4 and LRM optics are not compatible

Here is something I ran into and is certainly worth noting down and remembering:

LX4 and LRM optics are not compatible

This perhaps should be obvious as they are different standards but it wasn't until I looked into it and now I know for certain.

LX4 is standard IEEE 802.3ae and LRM is standard IEEE 802.3aq, you can look into these further on Wikipedia or another resource but the gist of it seems to be that the standard work in different ways making them incompatible. There is a good support forum link in the resources below.

This all came around because a customer wanted to buy more X2-10GB-LX4 optics but these are EOS, the recommended replacement is the X2-10GB-LRM optic which is incompatible. The options here then are to upgrade the existing line cards and replace the old LX4 optics with LRM optics or try to purchase any existing LX4 optics which may be in stock somewhere, but this is only a temporary fix as Cisco are not making them any more.

So a work of caution, don't take the Cisco recommended replacements completely at face value.

As a side note, optics of different form factors are compatible, so a X2 LRM and Xenpak LRM module would be fine, in the same way a LC SFP module can connect to a SC GBIC module if they are both using the SX standard.

Resources
Cisco Support Forum post:
https://supportforums.cisco.com/discussion/11270096/x2-10gb-lx4-sfp-10g-lrm-compatibility

Juniper EX4550 Switches Airflow Confusion

So this is a quick note to clear up some confusion I had regarding the airflow on Juniper EX4550 switches.

The airflow on these switches is either front-to-back or back-to-front however this is not immediately apparent from the datasheet, and this is always my quick go-to place for information. I think this is mainly my fault for not reading this properly but it is also written in a confusing way.

The datasheet states:
"port side to PSU side airflow" which if you are reading this quickly looks suspiciously like "side-to-side"

To be sure I've had this checked with Juniper, and it is verified in the tech doc below, but the airflow is definitely front-to-back, back-to-front PSUs are also available.

References
EX4550 PSU Tech Doc:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/cooling-system-ex4550.html

EX4550 Datasheet:

http://www.juniper.net/us/en/local/pdf/datasheets/1000414-en.pdf

Cisco CME v10 8831 conference Phones issues

We have a bug / issue with conference phones and Cisco Communications Manager Express (CME) v10.

The current Cisco conference phone is the 8831, the previous version was the 7937G. The 7937G is end of sale as of 31st March 2014 which means that the only available conference phone is the 8831 (unless you purchase refurbished / from distribution but this cannot be guaranteed due to stock levels). So realistically the option is the 8831.

The issue however, is that the 8831 is not supported by CME version 10, and CMEv10 is the current version, therefore companies upgrading to version 10 of CME had better be using older conference phones.

There is currently (28th March 2014) no work around for this, if you are running CMEv10 you either need to purchase older 7937G conference phones or wait for CME version 11 to be released, currently targeted for around July 2014.

Working Out Address IPv4 Ranges using Subnet Mask and Wildcard Mask Math

So this probably is old news to a lot of people but I've just come across it and it's going to save me some long hand mathematics so I'm jotting it down here:

There is a quick and easy way to work out the valid range of addresses for a subnet knowing just the IP address and mask.

First you take the network address and mask (obviously work out the network address first if you do not have the network address) - For example 10.17.32.0/19

Write them down in dotted decimal - 10.17.32.0 255.255.224.0

Subtract the subnet mask from the 'all 255's mask' - 255.255.255.255 - 255.255.224.0 = 0.0.31.255

Add this value to the network address - 10.17.32.0 + 0.0.31.255 = 10.17.63.255

And here you have the valid range of addresses 10.17.32.0 - 10.17.63.255

Excellent!

IPSLA to Track Multiple Objects

IPSLA is a very handy feature but one specific use case for it is determining if a connection is up, for example a connection to the Internet. A router can use IPSLA to continuously ping a resource on the Internet (for example Google.com) and if they resource becomes unreachable then the router can act upon this. This is especially useful if your Internet connection is not physically down but it has no connectivity, perhaps there is issues within the service provider but because the interface is not down features like HSRP tracking will not kick in.

One draw back with this is that if the resource on the Internet goes down then the router thinks the connection has gone down and will act upon this. To stop this happening Enhanced Object Tracking can be used with IPSLA so that 2 (or more) objects can be tracked, with a Boolean expression, I.E. Google.com and cisco.com with the AND boolean expression would mean both objects would have to unreachable in order for the router to act, and this is highly unlikely, unless your Internet connection is down.

Flash Directories on Cisco Devices

So here's a little qwirk, some Cisco devices seem to save IOS images within directories and some save them straight the flash. By the IOS image file I'm talking specifically about the .bin file.

I found this out because generally the image files I deal with have all been saved directly to the flash so you can copy them with the copy flash: tftp: command, then you enter the IP address of the server and the file name and off it goes, but I tried this with a new switch I've purchased, a 2960-24TT-L and I kept getting this error message:
%Error reading flash:c2960-lanbase-mz.122-35.SE5 (Is a directory)

After a bit of searching it is exactly as it describes, the IOS image file (.bin file) is in a directory with the same name. So the fix was instead of trying to copy a non-existant image file from the flash:

copy flash:c2960-lanbase-mz.122-35.SE5.bin tftp

= wrong

I had to copy the file from within the directory of the same name:

copy flash:c2960-lanbase-mz.122-35.SE5/c2960-lanbase-mz.122-35.SE5.bin tftp

Easy when you know how...

References:

Here's the link to a Cisco support site which I got my steer from, FYI:

https://supportforums.cisco.com/discussion/9896636/copy-flash-tftp-error