We had an alert in VCenter on a particular VM stating that ‘Virtual machine disk consolidation is needed’. I shut down the VM out of hours, right clicked on the VM then clicked ‘Snapshot’ and ‘Consolidate’ as suggested by VMware here (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2003638)
As soon as I did this I received the following alert:
Status: An error occurred while consolidating disks: Could not open/create change tracking file
Using KB2013520 (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2013520) I discovered the problem was possibly corrupt CTK files. I resolved it taking the following steps:
1. Shutdown affected VM
2. I then discovered which host the VM resided on in Vcenter and then logged onto it via ssh. I also discovered the datastore the host was using as I would need to browse to this directory.
2. I created a ‘tmp’ folder in the VM’s directory on vmfs/volumes/$LUN/$VM
3. Moved all CTDK files into the tmp directory ( mv *-ctdk.vmdk /tmp )
4. Back in VCenter I attempted to consolidate the snapshots again – this time it worked.
5 . Finally I powered on the VM. All good!
There are a myriad of options when it comes to assigning IPv6 attributes to a PPPox connections and in this post I’ll be exploring some of them.
In the network referenced in this post incoming PPP xDSL sessions (DSL, FTTC) are handed off from the wholesale provide over an L2TP tunnel. Upon successful authentication each connection is configured by the LNS with the attributes returned by the radius server. See below:
In the IPv4 world all the leg work was done at layer 2 with the use of IPCP within PPP. IPCP was responsible for configuring the IP address of the connection as well as providing additional information such as DNS servers. Quick and easy.
Before putting our ASR 9001 into production I wanted to update it to the Cisco’s suggested firmware release. I also wanted to configure some LDP label allocation filtering and couldn’t find the commands in my current release so thought an upgrade would help (that turned out to be something else). It was a fairly small jump in terms of releases as I was just moving from 5.1.3. to 5.3.3. It was a fairly smooth process but I did get stuck at one point which I’ll explain later. Anyway here are the steps.
Download tar from cisco.com and FTP/TFTP to the ASR. This was named ASR9K-iosxr-px-K9-5.3.3.tar and contains all the core software as well as the optional PIES (package installation envelopes) you can choose to activate. The file was 1.44 GB so you’re better off using FTP over TFTP. Put the kettle on as this will take a while! Once the TAR file has been successfully transferred to the router you’ll need to extract it with the following command:
RP/0/RSP0/CPU0:ios(admin)#install add tar disk0:/ASR9K-iosxr-px-K9-5.3.3.tar.
This will extract all the PIE files to your compact flash disk so make sure there is enough room before you run this!
Recently I needed to upgrade the code on one of our Metro Ethernet switches as some of the EVC and bridge domain settings weren’t operating quite as I had envisaged.
I’m new to these switches and the upgrade process is slightly different to the traditional ‘copy tftp flash’, reboot and cross fingers method I’m used to with other Cisco routers.
The first difference I noticed is when I looked at the flash directory.
Before diving into the mechanics and processes of various routing protocols it is important to grasp what is exchanged when a neighbour relationship is formed. It’s easy to think that when a neighbour relationship is formed the routers just exchange the contents of the IP routing table (RIB) or even just the contents of the IGP specific table (such as the EIGRP topology table)…both assumptions would be incorrect. We’ll use EIGRP as the IGP in this example.
When the neighbour relationship is formed a flurry of updates packets are exchanged between the neighbours. These updates contain *only* the routes from the EIGRP topology table. Assuming no redistribution has been configured these routes will only be routes seeded into EIGRP with the network command.
Or ‘neighbors’ if your an American or a router…
OSPF, like EIGRP uses the concept of Hello packets to build adjacencies.
OSPF Hellos packets are sent to the multicast address 224.0.0.05
This will mainly be a place to consolidate notes and test labs from my studies in the world of networking. Topics will include OSPF EIGRP, BGP and probably some MPLS. Maybe some switching if I get that far. There may be the odd post that has nothing to do with Networking at all….not that anyone is reading.