Tuesday, 22 November 2011

Sysprep and Renaming a VM on VMware

So I dont have to build an OS from scratch each time I want to provision a machine I've been using a Syspreped image, copying it and then renaming it using the VMware console. The procedure is as follows:
Create your Syspreped OS and upload it to a datastore on VMware ESXi/Hypervisor in to a folder called something like 'Master Images'.
Create a copy of the Syspreped image: create a new folder for your new VM with a sensible name then copy just the VMDK file from the Sysprep image to the new folder.
Use the steps 5 to 7 in the following Vmware KB article to rename the VMDK file to something more sensible:
If that link has died since I made this post, the steps were as follows:
6. Navigate to the directory containing the virtual machine. For example: cd /vmfs/volumes/DatastoreName/originalname/.
7. Rename the virtual disk (VMDK) files using the vmkfstools -E command.
vmkfstools -E "originalname.vmdk" "newname.vmdk"
I've tested this on ESXi 4.1.0 and Hypervisor (ESXi 5).

Tuesday, 1 March 2011

Copy files between Cisco routers

On the source router:

ip tftp source-interface dialer1

(dialer1 being the external interface the external TFTP client will be grabbing the file from)


tftp-server flash:/yourfilename 24

(Where 24 is the access list with the IP of the remote TFTP client)


From the other router (this will act as the TFTP client):

copy tftp flash

enter remote router IP

enter source filename as /yourfilename

Sunday, 20 February 2011

Virtual Machine Resource Usage Notes

While there is a decent amount of info available on guidelines for storage, memory, etc for virtualisation, I haven't seen much in the way of real-world data, so thought I'd make some notes on the performance I've noticed in my lab virtualisation environment:

Not enough guest memory leads to high disk utilisation and poor performance

This is by far the most important resource for a virtual machine. You should never let the VM exceed its assigned physical memory otherwise performance of the VM in question, and also potentially other VMs sharing the same physical disk, will grind to a halt. I've noticed that if the guest VM starts to use virtual memory the physical disk utilisation on the host machine shoots up. The VM will max out the disk utilisation, starving any other VMs from timely read/write access to the disk.

Heavy disk utilisation outside of the VMs causes poor VM performance

If you carry out disk read/write operations outside of the VM environment, e.g. copying VMs to/from the disk your VMs are on in a Windows box running VMware Server, this can seriously affect the performance of the VMs on that disk. This is because a copy operation between 2 disks on the host system can grab the full bandwidth available between physical disks on the controller. Server 2008 resource monitor shows this quite nicely - go to the 'Disk' tab and expand the 'Disk Activity' section and look for the files you're copying. If you're copying between disks on the same system you might see read/write numbers in the region of 80,000,000 - 80MB a sec, which on my system is pretty close to the realistic full throughput the controller & disks can support. If this is affecting performance you can confirm by checking in the 'Storage' section and seeing the 'Disk Queue' value for your disk. I find this doesn't affect performance too much until it goes above 5-ish, once it gets to 10+ the VMs start to slow noticeably.

Too little memory and too much contention for access to the disk for multiple VMs

This is a nightmare scenario for VMs and when it happens the VMs will grind to a halt, sometimes event the host machine too, depending on where you store your VMs. If more than one of your VMs maxs out its physical mem and so starts to use virtual memory, both machines will be contending for very high read/write disk utilisation. This might be sustainable in the short term if it was just one machine but more than one then the contention for access to the disk kills the VMs.

Suggestions for a usable virtualisation setup

First and foremost, enough physical memory assigned per VM that the VMs never go above it

A maximum of 2-3 VMs per core seems to provide adequate performance, e.g. 6 VMs on a dual core runs ok, and 8 on a quad runs ok.

6-8 VMs per SATA 7200rpm disk seems to run ok, as long as that disk is only for those VMs, and any ISOs used by the VMs are on a separate disk.

Run your VMs on a dedicated disk - don't share this with anything else, especially the OS!

Avoid copy operations to/from the physical disk the VMs are on while the VMs are busy.


These notes relate specifically to a lab environment, where occasional performance degradation isn't a major problem. For an operational environment you should really be using an enterprise class virtualisation product such as VMware ESX & VMotion or similar and a SAN. That said, the same ideas discussed here apply in an operational enterprise setup.

Friday, 21 January 2011

Troubleshooting IPSec site to site VPN tunnels on Cisco

First, double-check everything (examples below are what you should see in the config). The majority of problems with IPsec tunnels are down to a mis-match in the settings, so it pays to double check all settings before debugging.

Check the peer IP addresses are the correct far end peer IP address:
on Cisco routers check

crypto map ipsectunnels 10 ipsec-isakmp
set peer

and

crypto isakmp key ****** address

On Cisco firewalls check

and


Check the IPsec transform sets match:
on Cisco routers check

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

NB: In the line above, 'ESP-3DES-SHA' is the name of the transform set you have created by using this command, and 'esp-3des esp-sha-hmac' are the actual ipsec methods allowed in the named transform set you have created. You later assign 'ESP-3DES-SHA' to a crypto map (see below)

and

crypto map ipsectunnels 10 ipsec-isakmp
set transform-set ESP-3DES-SHA

On Cisco firewalls check

and


Check the ISAKMP policies match:
on Cisco routers check

crypto isakmp policy 10
encr 3des
authentication pre-share
group 2

On Cisco firewalls check


Re-enter the shared-secret (to make sure it isnt a typo):
on Cisco routers check

crypto isakmp key ****** address

On Cisco firewalls check

and

NB: On Cisco firewalls, the shared-secret is blanked out with **** when you do a normal show run. Make sure you don't just copy the ***


Check the crypto map is correct and matches the far end:
on Cisco routers check

crypto map ipsectunnels 10 ipsec-isakmp
set peer
set security-association lifetime seconds 86400
set transform-set ESP-3DES-SHA
match address 155

In the above, note the match address 155 - this references an access-list, make sure the access lists, both full source and destination IP range AND subnet mask, match EXACTLY for both ends of the tunnel.

and

crypto map ipsectunnels
The above should be applied to the outbound interface of the router where packets should be encrypted - on an ADSL router this would be the dialer interface that has the public IP (assuming its a public ADSL line).

On Cisco firewalls check

and




If that is all ok, check the status of the tunnels:

Router#show crypto ipsec sa
Router#show crypto isakmp sa

Do an extended ping to force traffic down the tunnels in case your expected traffic isn't making it to the tunnel for some reason

Finnaly, have a look at the debug:

Router#debug crypto ipsec

Router#debug crypto isakmp

Monday, 17 January 2011

No debugging output seen on a terminal session

If you've enabled debugging, issued a term mon command and are still not seeing any debugging output, then the logging level for the monitor (what you're asking to be showing when you issue term mon) may be set to a lower level than debug.

You can see what logging levels are set by using the show log command. Look for the Console logging: and Monitor logging: lines. If it does not say level debugging then you wont see any debug output for that output type.

To enable debug level output for the monitor, type:

Router(config)#logging monitor debug

The just enter

Router#term mon

and you should start seeing the debugging output (assuming you have turned debugging on for something!)

Thursday, 13 January 2011

Cisco IOS Naming Conventions (12.4)

Just had a really interesting read(!) of the Cisco IOS naming convention whitepaper, so to save other peoples sanity I thought I would share my notes :)

The non 'T' train of 12.4 is there to provide the most stable releases. Maintenance deployment (MD) releases of 12.4 (non 'T') are the MD of the 12.3T train. This implies these are the most stable releases available. New releases constitute mostly software fixes

The 'T' train of 12.4 is there to provide new releases with the latest feature and hardware support. Early Deployment (ED) releases of 12.4T introduce new functionality that is not available in the 12.4 train. They also receive software fixes. There will be the occasional MD release of 12.4T

The release number (digits that follow 12.4, e.g. 12.4.xx) are unique across both 12.4 and 12.4T, e.g. 12.4.10a -> 12.4.11T1 -> 12.4.12a -> 12.4.12b -> 12.4.13T1

The rebuild letter follows the release number in the 12.4 train, e.g. 12.4.10b denotes the second rebuild of 12.4.10

The rebuild number follows the release number in the 12.4T train, e.g. 12.4.13T4 denotes the 4th rebuild of 12.4.13T4

In 12.4, 'Releases' include mostly software fixes, and occasionally minimal new feature support and minimal additional hardware support

In 12.4T, 'Releases' include software fixes, new features and additional hardware support

The rebuild designation (a letter for 12.4 and a number for 12.4T) shows that there has been a rebuild of the software to improve stability. The criteria on what changes are made in a rebuild are very strict.

In summary, choose a 12.4 (MD) with the highest release and rebuild letter for the most stable release available and choose 12.4T (ED) with the highest release and rebuild number for the IOS with the latest features and hardware support.

For full details of the IOS naming conventions, see the following link:

http://www.cisco.com/web/about/security/intelligence/ios-ref.html

Wednesday, 12 January 2011

Debugging Cisco ADSL

Use

debug atm events

to see the atm training process. This should show a detailed output as the atm interface comes up

Use

debug ppp auth

to view the dialer auth process. It should be clear from the output if the username/pass is bad

Use

sh dsl int atm0

to view detailed info on the DSL interface atm0. Look out for a very low (close to 1dB) or negative Noise Margin. This is difference between the maximum acceptable noise for ADSL profile assigned by the carrier and the actual noise on the line. The number shown is the actual noise subtracted from the maximum acceptable noise, so a positive number is good.