Upgrade IOS on an ASR-1002F

Steps to upgrade IOS on an ARS-1002F are as follows:

1. Copy your IOS .bin file to a USB stick and connect it to USB0 on the front of the ASR
2.  Connect the power and press 'Escape' on startup to access ROMMON
3. At the prompt do > boot usb0:
4. The router will boot using the ASR image you have on the USB
5. Once booted do #copy usb0:asr10~7q.bin bootflash:
6. Confirm the location and the .bin file will transfer
7. Next, set the system to boot from bootflash - #boot system flash bootflash:asr10~7q.bin
8. Next set the config-register to ensure it boots properly - (config)#config-register 0x2102
9. Write this - #wr mem
10. Finally reload the asr and ensure it boots correctly - #reload

Password Recovery on a Catalyst 3750-E

Password recovery on a Catalyst 3750-E

• Press and hold the Mode button on the front of the system then connect the power

• Continue holding until the SYS LED blinks from green, to amber, to green, then turns solid green.

• Release Mode and you should have a prompt for – switch:

• Do – switch: flash_init

• Next do – switch: dir flash:

• Next do - switch:  rename flash:config.text flash:config.old

• Next do – switch: boot

• Once the system reboots you can either save the blank config and work from a clean install                   #wr mem

• Or, recover the old config and reset the password:   

                       #rename flash:config.old flash:config.text

• Then do - #copy flash:config.text system:running-config

• Change all the passwords and apply an appropriate user account:

          (config)#enable secret [password]

          (config)#username Trevor password [password]

          (config)#line con 0

                        password [password]

                        login

          (config)#line vty 0 4

                       password [password]

                       login

• Finally save the config and reload -

                     #wr mem

                     #reload

Password Recovery on a Cisco 5580

 Steps to reset a password on a Cisco ASA 5580

• Boot the system and press escape as the system loads
• At ROMMON set confreg to 0x41 - >confreg 0x41
• then reload >boot
• When prompted type 'No' to by pass the auto configuration steps.
• Once at the command prompt copy the start-up config to running config:

           #conf t

          (config)#copy start run

• Next change the password to on of your choice:

         (config)#password [password]

         (config)#enable password [password]

• Add a user account with priv 15 access:

         (config)#username Trevor password [password] priv 15

• Change the configuration register back to the correct one:

         (config)#config-register 0x1

• Finally write this and then reload:

          #wr mem

         #reload

•  Test and you should be good.

Extend your LAN across multiple sites using L2TPv3 Tunnels

We have a situation where we want to move a number of servers from our office to our data centre. In order for our networking monitoring to remain active we need to be able to present the same subnet at both locations as though they were on a local LAN.

To achieve this we've implemented L2TPv3 Tunnels (L2 tunnel) using Pseudo-wires on routers at each location.

This article is to document the steps taken to implement the solution so I have record it should I want to do this again.

First off a few definitions courtesy of Wikipedia.org:
L2TPv3 -Layer 2 Tunneling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternative protocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communications traffic over IP networks. Like L2TP, L2TPv3 provides a ‘pseudo-wire’ service, but scaled to fit carrier requirements.

Pseudo-wire - a pseudowire (or pseudo-wire) is an emulation of a point-to-point connection over a packet-switching network. The service being carried over the "wire" may be Asynchronous Transfer Mode (ATM), Frame Relay, Ethernet or Time-division multiplexing (TDM) while the packet network may be Multi-protocol label switching (MPLS), Internet Protocol (IPv4 or IPv6), or Layer 2 Tunneling Protocol Version 3 (L2TPv3).

You will need:

• 2 routers capable of configuring L2tpv3 and Pseudo-wires, in our case we used Cisco 1841 routers running IOS:c1841-spservicesk9-mz.124-17b.bin

• Loopback interfaces on each router configured with an IP address (/32) that is routable to. These are the source IP's in your config so make sure you can ping them from each side before you start with the L2TPv3 tunnel config.

The network will look like this:

You are going to configure the tunnel on routers R3 and R4 with the tunnel configuration applied to the LAN side port on each router. The source of the tunnel will be a loopback interface on each router, so this needs to be routable.

Step 1 - Configure your routers for general connectivity. Apply a /32 address to Lo0, apply a public IP to your WAN side interface and leave the LAN side interface with out an IP.

Step 2 - Configure your routing. How ever you choose to configure your routing (EIGRP, OSPF, Static) you need to ensure R3 can ping Lo0 on R4 and visa versa.

Step 3 - Define your L2TPv3 'class' - used to configure connection parameters such as authentication and hello timers. Configure it on each router as follow:
R3#conf t
R3(config)# l2tp-class networkstV3class
R3(config)#authentication
R3(config)#password N3tw0rkStud1es
+++
R4#conf t
R4(config)# l2tp-class networkstV3class
R4(config)#authentication
R4(config)#password N3tw0rkStud1es


Step 4 - Next apply this to a Pseudo-Wire and define your Lo0 interface as the source of the L2TPv3 tunnel:
R3(config)#pseudowire-class NETWORKST-PW
R3(config-pw-class)#encapsulation l2tpv3
R3(config-pw-class)#protocol l2tpv3 networkstV3class
R3(config-pw-class)#ip local interface loopback0
+++

R4(config)#pseudowire-class NETWORKST-PW
R4(config-pw-class)#encapsulation l2tpv3
R4(config-pw-class)#protocol l2tpv3 networkstV3class
R4(config-pw-class)#ip local interface loopback0


Step 5 - Finally apply the pseudo-wire to the interface that connects to your LAN:
R3(config)#int f0/1
R3(config-if)#xconnect 40.40.40.40 1 pw-class NETWORKST-PW
   - the xconnect cmd associates the interface f0/1 to the remote peer's pseudo-wire located at 40.40.40.40
 - the figure 1 is a virtual circuit ID and needs to match at both ends.


R4(config)#int f0/1
R4(config-if)#xconnect 30.30.30.30 1 pw-class NETWORKST-PW

Step 6 - Verify the configuration, use the following command to verify the tunnel is up:
R3#sh l2tun tunnel all
%No active L2F tunnels
L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 60290 is up, remote id is 28046, 1 active sessions
  Tunnel state is established, time since change 20:14:20
  Tunnel transport is IP (115)
  Remote tunnel name is R4
    Internet Address 40.40.40.40, port 0
  Local tunnel name is R3
    Internet Address 30.30.30.30, port 0
  Tunnel domain unknown
  VPDN group for tunnel is not available
  L2TP class for tunnel is l2tp_default_class
  271913 packets sent, 31678 received
  36256510 bytes sent, 2837214 received
  Last clearing of "show vpdn" counters never
  Control Ns 1216, Nr 1218
  Local RWS 1200 (default), Remote RWS 1200 (max)
  Tunnel PMTU checking disabled
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 1
  Total resends 0, ZLB ACKs sent 1217
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0

%No active PPTP tunnels

- here you are really looking at Packet sent and received. Should you find that either is zero then trouble shoot accordingly. Look at physical connectivity and routing.

Once you have active tunnels connect the LAN side interface to a switch on the same VLAN as your office LAN then connect your servers.

CCNP - Job Done.

Yesterday I passed the TSHOOT exam and thus completed my CCNP. I had a tense afternoon as I eagerly waited for my certification tracking account to sync to with Pearson Vue but late last night the e-mail came through from Cisco Training telling me I had achieved the CCNP and I could claim my logos.

My experience sitting the TSHOOT exam was a much improved one from the previous test centre I used to go to. I was advised that my usual company had actually gone out of business. So here I was at a strange test centre hoping to claim my prize.

I'm not going to test the NDA but I will say that the experience of the exam was like none I've ever encountered. It's on record that you can dip in and out of the tickets as you see fit. If you get stuck on one question you can select Abort and check the config in another ticket so see if you're right. I found I needed to do this on 2 occasions to confirm my line of thinking and but it felt like I was cheating some how. In all other Cisco exams once you move on to the next question you can't go back.

If I'm honest I'd have to say they could probably do that on this exam. You have to answer all the questions any way and I submitted them in order so that I could manage my time correctly.

In previous posts I've mentioned approaches to tackle the exam, Kevin Wallace recommended the Abort method above, one other method I used was to let the question guide me. On more that one question I had narrowed the problem to a particular device (so that's Q1) and could tell that a particular technology was the issue (so that's Q2 sorted) but I struggled to pin point the cause. I simply reviewed the answers available to me in Q3. Once you eliminate the ridiculous answers you're left with 2 or 3 plausible answers that you can work with.

My final point is about time management. I found this exam very enjoyable and once you pinpoint the cause a problem you rattle through the 3 part trouble ticket quickly. If you know your show commands and can comfortably recall the correct command to display the most helpful information then I genuinely think you shouldn't worry about the time.

Right. Time for a rest then I'm going to put some serious consideration as to whether the CCIE is worth my effort...

CCNP - ENTERPRISE - EIGRP Troubleshooting Targets

For EIGRP issues look to the following:

- If Adjacencies are not forming check:
Timers match, AS number matches
In Frame-Relay topologies check that you have included the 'broadcast' option to allow the multicast packets that are sent to 224.0.0.10 to be forwarded.
Check for any ACL's blocking EIGRP specifically or the subnets in general
Check that the router interfaces are up, you can ping the neighbour ( if it isn't up then troubleshoot the interface config as appropriate)

- If Static/Dynamic routes are not being redistributed in to EIGRP check:
Routes learned by EIGRP are in the Routing Table
Check the EIGRP topology table to see if the route was learned at all
Check the EIGRP config to ensure you are advertising the correct networks
Are there any Distribution Lists filtering your network?
For discontiguous networks check that no auto-summary is applied.

- For the Error 'Not on common Subnet' check:
IP addressing the interfaces that should be forming an adjacency.
Remember EIGRP packets are sourced from the Primary IP address on the interface. As such you can't use a Secondary IP to form the adjacency.

- If Load Balancing does not operate as expected check:
Ensure you have correctly used the Variance command in the Router process (not at the interface)

- Do you get 'Stuck in Active' (SIA) errors?
Check that the router has enough resources to respond to EIGRP updates (#sh processes cpu)
Check the bandwidth parameter on the interface is set correctly
Check #sh interfaces for interface resets, input/output errors.
If you do observe these issues look at hardware upgrades.

CCNP - ENTERPRISE - OSPF Troubleshooting targets

When troubleshooting OSPF look for the following:

1. What routes are present in the routing table
2. Check the status of OSPF adjacencies
3. Check the networks are advertised properly (in subnets)
4. Check your virtual-links are configured correctly
5. Check your timers match at each end of your links
6. Check you have OSPF configured to use the correct network type for your media

CCNP - ENTERPRISE - Troubleshooting Methodology...

Regardless of the particular issue at hand trouble shooting generally flows as follows:

Problem Reported ---------> Diagnosis ---------> Resolution

You'll find the bulk of your time concentrating around the Diagnosis part of the process.

For the CCNP TSHOOT exam you need to know process of troubleshooting an issue, which is:
START

1. Collect information - from users/reports/monitoring
2. Examine the information - such as comparing your gathered information with that of a baseline measurement
3. Eliminate potential causes - this is where you'll use your knowledge about your local network
4. Hypothesise a cause - Consider the most likely cause based on the information you have gathered
5. Verify the hypothesis - Test/reject the theory regarding the cause

END

It's important to note that your should always be methodical. Do not jump about the steps otherwise you'll lose track of what you've done and cause further delay.

Experience engineers may proceed straight to step 4 if they have a good hunch about what is causing the issue however such action (known as 'Shoot from the Hip') can cause time delays if the hypothesis is wrong.

CCNP - ENTERPRISE - notes on Archive cmd features

A useful tool to automatically back up your running-config is the Archive tool set.

Part of Cisco's Archive and Restore features it allows you to take the running-config and archive on to either that  device or to a remote device such as a tftp server.

Set up an Archive using the following:
R1#conf t
R1(config)#archive
R1(config-archive)#path tftp://10.10.10.10/$h.txt
R1(config-archive)#write-memory
R1(config-archive)#time period 10080

In the above you set the destination server, the $h indicates that the archive will automatically be called [the host name of the router]-1.txt. The next archive will be [host name]-2 and so on...

Write-memory prompts the archive process to run every time write-mem is executed and the time period is set in minutes to automatically execute an archive backup.

So you now have your archive running. Next you decide you need an archived config to be restored.

You 'could' perform a #copy tftp run but remember that this will only merge the saved copy into the running config not totally over write it.

You 'could' perform a #copy tftp start but that would require a reload to restart the system and boot using the startup-config.

To immediately install an archived config perform a replace:
R1#configure replace tftp://10.10.10.10/r1-1.txt

What then occurs is the router compares the archive to the running config and compiles the commands needed to apply the archive to the running-config. It then executes them and the configuration the takes immediate effect.

CCNP - ENTERPRISE - IPv6 - Some thoughts...

In no particular order, notes that I took following from my day on a RIPE NCC training course about deploying IPv6:

1) Considering the IPv6 address is 128 bits long when you request an allocation from RIPE NCC (or who ever your RIR is) you get a minimum /32. That's 429,496,796 /64 subnets available for you to assign to your customers as you see fit! which is 18,446,744,073,709,551,616 host addresses! so you've got room to manoeuvre.
2) Best practice states that for a network assignment assign a subnet no longer than a single /64 subnet. The first 64-bits will be the network portion of your host address so the remaining 64 bits use as the host portion of the address.
Which is to say just as you would assign a single /24 , for example, to each VLAN on your network do likewise with an IPv6 /64 subnet. Now, you might only have a single mail server on a VLAN so you think that    having one system using up a /64 subnet is a bit of a waste but consider that there already applications out there that expect you to be using a /64 subnet as the smallest network. If you start allocating random, non-best practice subnets, e.g. a /127, then you might potentially cause problems for your self in the future. Don't do it.
3) Don't fear the waste. Look at the numbers above, give your self plenty of addresses to play with on each VLAN and then when systems come along that have separate IPv6 addresses for individual procedure calls you're well equipped to handle it.
4) When subnetting an IPv6 address, best practice states you should allocate subnets from a 4 bit boundary. Remember that an IPv6 group is made up of 4 hexadecimal figures each of which represents a 4 bit binary figure. keeping the subnetting to nice 4bit boundaries basically stops your head imploding. The network subnets can be as follows- /32, /36, /40, /44, /48, /52, /56, /60, /64.
In our examples on the course we allocated a /48 for a single data centre, then subnetted that in to /60's for your routers/firewall/switches then within the switch infrastructure subnet your switch's /60 into /64's for each VLAN. Nice and tidy.
5) Within your business do not have an IPv6 specialist! you don't have an IPv4 specialist do you? if you avoid looking at IPv6 all that will happen is that you personally will be left behind and then when you're made redundant with no IPv6 experience/knowledge to speak of you'll be screwed.
6) Don't delay. Look at the figures in the widget provided by Hurricane Electric --> IPv6 is coming and fast. Emerging economies in Asia and Africa already have to use IPv6 natively because the IPv4 address have been exhausted. The last thing you want is a new market unable to access your website because you haven't got round to provisioning your website for IPv6.
7) My final thought is that within your organisation you should agree a policy on how to write IPv6 address and stick to it. You can choose to stick with typing out the full 128-bit address (8 groups of 4 Hexadecimal figures), You can choose to simply drop leading zero's, or agree to drop all leading zero's and replace contiguous groups of 4 zeros with a ::. Which ever method of representing an IPv6 address you choose make sure everyone sticks to it because it will make things easier when trouble shooting if the address format appears the same throughout your network.