Problem
I needed access to a Nexus switch located remotely. The switch was connected to a Raritan Dominion SX ii console server but I could not connect as the port was busy. After checking that no-one else was on this switch I established that it was due to an old stale session that had not been timed out by the Raritan. I performed the ‘userlist’ to display the users currently logged in.
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.
1.
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!
This command displays a handy list of all static routes in the routing table that reference a track object and whether the object is up or down. Routes from all VRFs are displayed.
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.
One of the nice features in the Cisco ASR 1k line is the use of a dedicated management interface. On first glance at the chassis it looks like any other regular Gigabit interface, however it can be used for management traffic only. Essentially the interface is in it’s own VRF and can’t be placed in any other (ie. the Global VRF) providing separation at the control plane. You could then configure an IP on the interface, plug it into the Management VLAN on your network and disable SSH/Telnet on your public interfaces for ultimate security.
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.
Game got real!
Time to get back aboard the study express and go back to the beginning with some EIGRP! Ok, here’s the lowdown:
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