Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#int fa 0/^Z  <---Arrgh forgot which interface it was, Ctrl+Z out of config mode
% Incomplete command.

Router#sh ip int brief
Interface                  IP-Address      OK? Method Status                Prot
ocol
FastEthernet0/0            10.10.10.1  YES NVRAM  up                    up

FastEthernet0/1            192.168.0.1   YES NVRAM  up                    up

Router#conf t  <---OK found it, back into config mode
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#int fa 0/0
etc

This gets annoying pretty fast, but luckily you can execute exec commands from within config mode by preceding them with ‘do’! This is a lot nicer:

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#int fa 0/  <---Arrgh forgot which interface it was, lets try 'do'
% Incomplete command.

Router(config)#do sh ip int brief
Interface                  IP-Address      OK? Method Status                Prot
ocol
FastEthernet0/0            10.10.10.1  YES NVRAM  up                    up

FastEthernet0/1            192.168.0.1   YES NVRAM  up                    up

Router(config)#int fa 0/0

Much easier right? There are of course a few caveats, the main one being that you can’t use the ‘?’ symbol to remind you of the commands but its still a great little time saver.

Router#sh access-lists 100
Extended IP access list 100
 10 permit tcp any host 192.168.0.10 eq www
 20 permit tcp any host 192.168.0.10 eq 443
 30 deny ip any any

First lets examine this output. Note that we are looking at an extended access list, although our trick will work with standard ACLs too. Also note that there are numbers before each rule. We are going to learn how to harness the power of these numbers. Lets say we want to add another rule, permitting mail to the 192.168.0.10 host. If you try and just add in the rule using the way they teach you in your CCNA, you end up with the following:

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#access-list 100 permit tcp any host 192.168.0.10 eq 25
Router(config)#do sh access-l 100
Extended IP access list 100
 10 permit tcp any host 192.168.0.10 eq www
 20 permit tcp any host 192.168.0.10 eq 443
 30 deny ip any any
 40 permit tcp any host 192.168.0.10 eq smtp
Router(config)#

So not too good really, that rule will never get hit as its been put after the deny. Luckily theres another way, using the “ip access-list” configuration command. Take note here of the rule numbers – first we’ll remove the rule that was put at the end of the ACL, and then we’ll re-add it before the deny:

Router(config)#ip access-list extended 100
Router(config-ext-nacl)#no 40
Router(config-ext-nacl)#25 permit tcp any host 192.168.0.10 eq smtp
Router(config-ext-nacl)#do show access-list 100
Extended IP access list 100
 10 permit tcp any host 192.168.0.10 eq www
 20 permit tcp any host 192.168.0.10 eq 443
 25 permit tcp any host 192.168.0.10 eq smtp
 30 deny ip any any
Router(config-ext-nacl)#

After entering the first command note that we go into config-ext-nacl mode which is where we add and remove rules. Its quite easy – you add a rule by starting with the sequence number of where you want it go and then entering the rest of the rule as normal. You remove a rule with “no” followed by the sequence number.

You might have realised that we can only add so many rules like this before we run out of numbers, but thats fine too as IOS includes a command to let you resequence the list. For example

Router#sh access-lists 100
Extended IP access list 100
 1 permit tcp any host 192.168.0.10 eq www
 2 permit tcp any host 192.168.0.10 eq 443
 3 permit tcp any host 192.168.0.10 eq smtp
 4 deny ip any any
Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#ip access-list resequence 100 10 10
Router(config)#do sh access-l 100
Extended IP access list 100
 10 permit tcp any host 192.168.0.10 eq www
 20 permit tcp any host 192.168.0.10 eq 443
 30 permit tcp any host 192.168.0.10 eq smtp
 40 deny ip any any
Router(config)#

So the key command there is “ip access-list resequence 100 10 10″. Don’t get worried by the raft of numbers, its really simple. The first number (100) is the access list we want to resequence; the second number (10) is what number we want the first rule to start at; the third number (10) is what we want the increment to be for each following rule. Lets try another example, we want the list to start at 50 and have increments of 5:

Router(config)#ip access-list resequence 100 50 5
Router(config)#do sh access-l 100
Extended IP access list 100
 50 permit tcp any host 192.168.0.10 eq www
 55 permit tcp any host 192.168.0.10 eq 443
 60 permit tcp any host 192.168.0.10 eq smtp
 65 deny ip any any
Router(config)#

These few commands have come in incredibly useful for me and have saved me a great deal of ACL related headaches, I recommend you learn them!

The first way is when you have no clue at all what you need to type, and just want a refresher of what options are available. Typing the ‘?’ character will show you all possible commands with a brief description, eg

Router#?
Exec commands:
 <1-99>           Session number to resume
 access-enable    Create a temporary Access-List entry
 access-profile   Apply user-profile to interface
 access-template  Create a temporary Access-List entry
 archive          manage archive files
 audio-prompt     load ivr prompt
 auto             Exec level Automation
 beep             Blocks Extensible Exchange Protocol commands
 bfe              For manual emergency modes setting
 calendar         Manage the hardware calendar
 call             Voice call
 ccm-manager      Call Manager Application exec commands
 cd               Change current directory
 cellular         cellular commands
 clear            Reset functions
 clock            Manage the system clock
 cns              CNS agents
 configure        Enter configuration mode
 connect          Open a terminal connection
 copy             Copy from one file to another
 credential       load the credential info from file system
 crypto           Encryption related commands.
 --More--

Press space to see more. You can also use this on a nested basis, eg

Router#show access-lists ?
 <1-2799>    ACL number
 WORD        ACL name
 compiled    Compiled access-list statistics
 rate-limit  Show rate-limit access lists
 |           Output modifiers
 <cr>

Router#show access-lists

The second, slightly different way to use this is when halfway through a command, it will try and match based on what you have already typed

Router#show ip in?
inspect  interface

Router#show ip i?
icmp  igmp  inspect  interface
ips   irdp

Router#show ip in?
inspect  interface

Router#show ip in

However note that in this case you don’t get the command descriptions.

You can use this from any mode, so it works in config, user exec, privileged exec. A lot of the commands you’ll come to learn by heart, but this is very useful for the ones you use less often.

NAT target

interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 !
ip route 0.0.0.0 0.0.0.0 10.0.0.2

Customer router

interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
 ip nat inside
 !
interface FastEthernet0/1
 ip address 172.0.0.2 255.255.255.0
 ip nat outside
 !
ip route 0.0.0.0 0.0.0.0 172.0.0.3
!
ip nat inside source static 10.0.0.1 172.0.1.2

ISP router

interface FastEthernet0/1
 ip address 172.0.1.3 255.255.255.0 secondary
 ip address 172.0.0.3 255.255.255.0

Looks like it should work right? Not quite. If we try and ping 172.0.1.2 from the ISP router, there is no response. We can see the NAT translation in place on the router, and with a debug arp command we can see the arp requests hitting the customer router, but it doesn’t respond.

Customer#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 172.0.1.2          10.0.0.1           ---                ---
Customer#debug arp
ARP packet debugging is on
Customer#
*Mar  1 00:40:20.147: IP ARP: rcvd req src 172.0.1.3 cc06.11b8.0001, dst 172.0.1.2 FastEthernet0/1
*Mar  1 00:40:22.147: IP ARP: rcvd req src 172.0.1.3 cc06.11b8.0001, dst 172.0.1.2 FastEthernet0/1
*Mar  1 00:40:24.147: IP ARP: rcvd req src 172.0.1.3 cc06.11b8.0001, dst 172.0.1.2 FastEthernet0/1
*Mar  1 00:40:26.111: IP ARP: rcvd req src 172.0.1.3 cc06.11b8.0001, dst 172.0.1.2 FastEthernet0/1
*Mar  1 00:40:28.135: IP ARP: rcvd req src 172.0.1.3 cc06.11b8.0001, dst 172.0.1.2 FastEthernet0/1
Customer#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 172.0.1.2          10.0.0.1           ---                ---
Customer#

We can also look in the arp table on the ISP router and confirm that it has no entry for 172.0.1.2. If we change the NAT statement so that the external natted address is on the 172.0.0.0/24 subnet, everything works so we aren’t hitting proxy-arp issues.

Customer(config)#no ip nat inside source static 10.0.0.1 172.0.1.2
Customer(config)#ip nat inside source static 10.0.0.1 172.0.0.5

ISP#ping 172.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.0.0.5, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 40/77/92 ms
ISP#

To cut a long story short, what we need to do is add the external natted address as a secondary IP on the customer router (or give it a different secondary IP on that subnet).

Customer(config)#int fa 0/1
Customer(config-if)#ip add 172.0.1.2 255.255.255.0 sec
Customer(config-if)#ip add 172.0.1.2 255.255.255.0 secondary

ISP#ping 172.0.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.0.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/49/72 ms
ISP#

Incredibly obvious when you think about it, but it took me a while to work out due to the fact that on Cisco’s firewall line it works without secondary addresses. Hopefully this will save someone else the headaches I went through.

Well actually there are a couple of gotchas to bear in mind when doing this. The first is easy and you’ll probably be hitting yourself – if you are in a vty session (eg you are connected via telnet or ssh) you don’t see the console messages by default. Use the terminal monitor command to view the debug messages:

Router#terminal monitor

The second issue is a bit less obvious (unless you’ve read the command description carefully). Only packets which are process-switched are included in the debug – this makes sense if you think about it because unless they are process switched the CPU never sees them. To see the traffic in your debug you need to somehow disable CEF which can be done globally or on a per interface basis:

Router(config)#no ip cef
Router(config)#int fa 0/0
Router(config-if)#no ip route-cache

If you do it on a per interface basis you need to do it on both the ingress and egress port of the traffic you want to capture, otherwise you will only see it in one direction.

As a final warning, think very carefully before disabling CEF on a production router! You could very easily overload the processor and crash the router.

First a bit of background about Cisco exams. They are organised into three tiers, Associate, Professional and Expert, which correspond to CCxA, CCxP and CCIE tracks respectively. Each tier has different tracks, such as Routing, Security, Voice, Wireless, etc. You can see all the tracks here, and note I don’t count CCENT. The idea is that you start as an Associate in your track, move up to Professional, and if you are really hardcore finally end on Expert. The foundation for pretty much every track is the CCNA – last I checked you had to have this before you could move onto the other tracks.

So lets look at the CCNA exam. If you haven’t done any networking before its not an easy exam to pass, a lot of things are covered and it can get pretty technical. It also has the problem that it doesn’t seem to be aimed at anyone in particular, and you don’t come out of it with knowledge that you can apply to real world problems. On paper it looks great, it covers a lot of ground and all the pieces are there, but it doesn’t show you how to combine them to make something useful. This is not to be disparaging of people who’ve done the cert because it takes a lot of work, instead I speak from experience. It wasn’t until I did the CCNP and gained some real world experience that I learnt how to put the different pieces together. I don’t want to say the CCNA is a useless cert, but it’s hard to tell who the target audience is. A small business won’t need things like managed switches or routing protocols, and a medium to large one will require much more knowledge to set up than you gain in the CCNA. The sweet spot where a CCNA is useful is incredibly narrow. But thats ok because there is also a design syllabus, the CCDA. This should tell us how to pull things together and design our network right?

Not quite. To use a common phrase, I’d describe the CCDA as covering topics which are a mile wide and an inch deep. To make things even worse, almost all the topics in it are Professional level material. A large part of the exam could be seen as ‘CCNP lite’, with the rest corresponding to ‘CCSP lite’ and ‘CCVP lite’. For me this is pretty easy, I’ve done the CCNP, know a fair bit about the security side of things and just need to learn a little more voice. For a CCNA though, this is a huge expansion of what they know. I would have been massively confused if I had looked at this syllabus straight from doing my CCNA. Even worse none of the topics are covered in any great detail, so by the end of the course while they might understand what they should be doing, they have no idea how to do it. I was expecting the CCDA to be fully focused on pulling together the topics in the CCNA and expanding on them with some basic resilient designs which would suit a small to medium business. The syllabus does cover this (in very small detail), but then adds a load more advanced stuff which is totally inappropriate for the people who would potentially be sitting it. I wouldn’t go so far as to say CCNP level knowledge is necessary to do the CCDA, but I can’t see how you would put the CCDA topics into context without it.

Unfortunately you can only make these kind of observations once you are at a much higher level than the target audience by which point it is moot. Until you get there all you can do is realise that sometimes the people who set the syllabus don’t know best, and if you learn everything they say and it still doesn’t quite click it is just as likely their fault as it is yours.

The CCIE consists of two parts, the first is a written exam which tests basic knowledge and after that you do a day long lab exam. The lab exam is considered to be the hardest of the two, with most people requiring multiple attempts. Once you have the certification, you just need to pass the written exam every few years to keep it.

Without any input from those who didn’t recertify its hard to work out why they didn’t bother. Change in job role could account for some but it seems unlikely that this would account for the full 61. Is it just that now there are more people with it, the CCIE is less highly regarded?

One of the most interesting parts for me was psyche of the guy that was behind it – they clearly knew that what they were doing was wrong and that they could get into a lot of trouble for it, but this didn’t override their urge to show off. Even when the Cisco researcher confessed that he’d been decieving them the whole time, they happily went along with his next deception and started giving out even more detailed information.

Another bit that really struck me was the amount of paranoia this individual seemed to have to live with, not only due to law enforcement potentially being after him but because of the possibility of his peers stealing his botnet while he slept.

If you are unfamiliar with the CCNP, the previous track consisted of four exams which can be briefly summed up as follows: BSCI (routing), BCMSN (switching), ONT (QoS + wireless), and ISCW (everything else – VPNs, DSL, MPLS, security). The new track is three exams.

The changes are very interesting – I always saw the core of this track as being routing and switching and Cisco seem to be acknowledging that with the first two exams, ROUTE and SWITCH. If you delve a bit deeper into the actual exam topics you can see that they’ve actually cut a lot of the content which isn’t routing or switching out. ROUTE looks to be basically the BSCI exam, with a very small coverage of the VPN and DSL topics from ISCW. SWITCH is the BCMSN with a bit of security. The third exam is TSHOOT, which is aligning with new CCIE track by adding a dedicated troubleshooting element.

Personally I’m 50/50 about the changes. Cisco seem to be trying to make each track very specific with no overlaps (the current CCNP has some overlap with the CCVP, CCSP and CCIP), and while I can see why they would want to do this I think it will produce less rounded engineers at the end of it. If you do the current CCNP you come out of it knowing a lot about routing and switching, and enough about everything else that you can work out most issues after a little research. Its kind of the jack of all trades qualification, which you might expect based on the acronym. With the changes it is turning more into the CCR&SP.  However I do like is the inclusion of the troubleshooting section since just setting equipment up in the first place is only the start of your job, you then have to go and support it.

Luckily I got my CCNP just last year so I’m not affected by the changes, but candidates who are halfway through theirs can either continue with the current track (until July), or substitute BSCI and BCMSN exams they have already completed for ones on the new track. More info on this here