Thoughts on the CCDA exam...

I sat the CCDA exam the other day and was stunned to find that I hadn't passed it. Sitting here now I'm still little confused if I'm honest. The exam consists of 55 questions to be completed in 75 minutes which is plenty of  time. I finished with 15 minutes go and that was after I made myself slow down.

Thinking on I'm trying to remember the style of questions I faced and to be honest I'm struggling to remember specifics. I'm not going to challenge the NDA you sign so all I say is that standard of question is no more technically challenging than the level you get in the Office Cert Guide by Bruno and Jordan. I can think of one area however I probably did fall down on. The test papers.

In the Offical Cert Guide and on the Cisco Learning Network there are practice question that you can try. When ever I did them I passed with flying colours. In the practice exams I did 3 attempts and pass them all by a good margin so I felt I was ready. At no point during the exam did I feel that it was getting the better of me and I think there were only 2 questions where I felt I needed to guess. As a result I was actually shocked when it said I hadn't met the grade.

I'm about to reschedule the exam for a few weeks time and today I reviewed the Offical Cert Guide and compared it to the Exam Topics list off the Cisco Learning Network. The main thing that lept out  to me was that while the Exam topics are set out one way, the Offical Cert Guide is set out in a different structure. As a result it's not immediately clear how the study material relates to the exam objectives.

I'm going to spend this week comparing and contrasting the material I have and will ramp up the exam practice. Finally I'll be reviewing (again) Enterprise Architecture, and Network Services.

Onwards and upwards...

Password recovery on a Cisco ME3400 Switch

Continuing my notes on password recovery on various bits of kit. Today's task was an ME3400 Switch.

Perform the following steps to regain access to your switch:

1. Power up the switch and send the Break sequence (dependant on the system you are working from) to access Password Recovery
2. Load the helper files:                                         switch#load_helper
3. Next, verify the name of your config file:            switch#dir
4. Rename said config file:                                     switch#rename flash:config.txt flash:config.txt.old
5. Reboot the system:                                           switch#boot
6. Next you'll be prompt to enter the auto config process. Enter No
7. Enter the PRIV EXEC mode:                           switch>en
8. Rename your config file:                                   switch#rename flash:config.txt.old flash:config.txt
9. Copy the config in the Memory:                       switch#copy flash:config.txt system:running-config
10. Next change your passwords as you see fit
11. Last part is to check the state of your interfaces. You may need to #no shut your appropriate ports.

     Finally apply your changes via switch#wr mem and reboot.

CCNP - ENTERPRISE - Duplex Mismatch

Right, not done any posts for a while so here we go with a note on Duplex Mismatches...

A Duplex Mismatch occurs when 2 devices are directly connected with different duplex modes. One end might be set to auto whilst the other could be set mannually to Full Duplex.

The situation is usually the result of manual configuration of an interface and the result can cause a number of effects on the network.

The most common situation for a duplex mismatch is the example above, one end set to auto (negotiate) and the other set to Full Duplex. With one end trying to negotiate whilst the other end is not the result is that the negotiation fails and the interface fails back to Ethernet standards and sets it's self to half duplex. This default action when negotiation fails allows for older hubs to be in operation in the network.

With one end now automatically set to Half Duplex and the other end manually set to Full Duplex you get the duplex mismatch.

The activity observed on the network can be varied. For example a duplex mismatch will not affect PING as the single packets are sent at 1 second intervals and therefore the link can process the traffic with out any issue being observed. Telnet will be seen as slow but you should still be able to run your session.

The main issue you will see is when both ends of the link attempt to send traffic at the same time. The end set Full Duplex can sendand receive data at the same time. No problems there, however, the end set to Half Duplex will not receive any data because it is busy sending first. The combination will result in packets from the Full Duplex end being lost whilst packets from the Half Duplex end will be slow or lost as that end perceives a collision is occurring and will run CSMA/CD.

As packets are now being lost TCP attempts to perform error recovery and retransmit the packets. This will fail as well due to the mismatch in place.

In the Full Duplex end you will see Frame Check Sequence errors and/or runt frames as packets are lost in transit.

The key to the operation to configure both ends the same. Use only Auto OR Full.

Resolution:
Simply change the setting on one end of the link to match the configuration of the other end.

Off topic - HR: The Spark Way

Have you got to perform a company restructure? need reduce head count? not sure where to start in your vast empire? Never fear the patented Spark method is here to help!

Step one : Obtain a list of all employees in the company and make sure their Job title is included.
Step two : Tell an educated but uninformed individual the job title of the first employee in the list and ask them to describe what that person does
Step three : If the first word out of the individual's mouth is 'Err???....???' then that person can be chopped :o)
Step four : Repeat for all employees and you'll have your list of jobs that can be culled.

Marvellous! :o)

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.