Wednesday, November 30, 2011

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
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)#password N3tw0rkStud1es
R4#conf t
R4(config)# l2tp-class networkstV3class
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 1 pw-class NETWORKST-PW
   - the xconnect cmd associates the interface f0/1 to the remote peer's pseudo-wire located at
 - the figure 1 is a virtual circuit ID and needs to match at both ends.

R4(config)#int f0/1
R4(config-if)#xconnect 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, port 0
  Local tunnel name is R3
    Internet Address, 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.

Monday, November 28, 2011

Cisco studies - What next...

Since I attained my CCNP I've been looking at what to do next. Should I continue on to the CCIE? or look at exploring some of the specialisms Cisco has developed in the time it took for me to go through CCNA and then CCNP?

At first I thought I would continue straight on the CCIE R&S but I'm struggling to get over the shear volume of knowledge required to go for the written (yes I appreciate it's supposed to be hard but I've got a young family to factor in...) So after a few very interesting weeks at work I've decided to go for CCDA then CCDP.

Starting in January my next posts will be aligned to the CCDA certification. Here goes...

Friday, September 30, 2011

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...

Tuesday, September 27, 2011

CCNP - TSHOOT - TSHOOT in the real world...Part2

The second trouble ticket that I was able to demonstrate my TSHOOT knowledge was the following:

Trouble Ticket #2 - the customer reported that hosts at SiteC were not getting a DHCP allocation from the server at SiteD.

The customer reported that when they performed a traceroute from the LAN at SiteC to on the LAN at SiteD the trace stopped. The network looked like this:

SiteC --> R1 at SiteC --> 'the core network' at R2 --> R3 at SiteD --> DHCP Server on SiteD LAN

For this one I took a look at our Nagios Monitoring and could see that there were no issues reported on R1, R2, or R3. As such I jumped on to R1 at SiteC and performed a traceroute to The trace was successful! Yet from the LAN at SiteC the trace failed?

Based on this information I formed my hypothesis. I asked the customer whether there could be an access-list/firewall between R3 and the DHCP server that could be blocking traffic from the LAN at SiteC? The customer investigated their equipment and found that an earlier change to an access-list on their equipment at SiteD was now stopping DHCP requests from SiteC. They corrected their configuration and the issue was resolved.

Trouble Ticket #2 - Closed

With this ticket because our network monitoring was reporting no issues with R1, R2, R3, I took the 'Shoot from hip' approach and looked to eliminate all L3 issues in one go. The trace route worked indicating that the server was responding to ping and that all L3 connectivity between SiteC and SiteD was fine. I could have tested the L1/L2 physical connectivity on each router in turn but our monitoring would have pick this up  and therefore I was confident the physical connectivity was fine. Once L3 connectivity had been proven on the equipment I have admin access on I could formulate my hypothesis and put it to the customer to test.

CCNP - TSHOOT - TSHOOT in the real world...

When studying for any certification exam it's very easy to end up concentrating on the goal of passing the exam instead of the actual goal which should be gaining knowledge and achieving a certain standard of expertise that can be practically utilised in the real world. The exam simply confirms that you have a certain level of knowledge. The point is to enable you to use it in the real world.

So here I am, studying for my TSHOOT exam, which will complete my CCNP, and in the week before the exam comes 2 real world examples of how studying for the TSHOOT exam has helped me investigate and resolve the issue in hand. The next 2 posts will outline the problem, methodology used and how the TSHOOT exam materials directly related to resolving the problems.

Trouble Ticket #1 - The customer contacted us to state that SiteA no longer had access to the internet via it's default route. 

 Following the TSHOOT troubleshooting methodology I gathered as much relevant information as I could from the client. I then reviewed the information, eliminated the possible causes until I was down to a small   number of possible issues, I then formed my hypothesis, tested it and reviewed the outcome.

For this particular problem the customer stated that following the closure of one office and the migration to a new site access to the internet via it's default route was no longer possible. The customer supplied me their default route - and that it originally routed via the now closed office. I also had the new network diagram outlining the new office and the appropriate routes. The diagram was essentially as follows:

SiteA Firewall ---> R1at SiteA ---> 'The core network' at R2 ---> R3 at SiteB - (trunk link)--> SiteB L3 switch ---> SiteB's ASA firewall --> INTERNET

First job was to see where the routing began to fail. So on to R1 and check the interfaces were up (yes) and then I moved on to the routing table to check for a route for This was a static route pointing to our core network (for this article we'll call all of it R2). I performed a traceoute on R1 to and it failed at R2.

On R2 I did the same, checked that interfaces were up and then checked the routing, This is where the first issue occurred. The static route on R2 was still pointing to the closed office. So the change was made. Static route was now pointing to R3 at SiteB.

I performed a traceroute to the default route from R1 again and it still didn't work. This time the trace stopped at R3.

On to R3 the routing table revealed that there was no route for at all. After referring to the customer they advised me that the traffic had to go via a specific VLAN on the L3 switch so on R3 we needed to create VLAN10 and allowed VLAN10 on the trunk link to the L3 switch at SiteB. Finally the route for was set to go via the SVI for VLAN10.

With this created I tested the route to from R3. It still didn't work? With the information at hand I was able to formulate my hypothesis.

Was VLAN10 a) created on the L3 switch? and b) allowed on the trunk link?

Next I checked the state of the VLANs. VLAN10 was in place on R3, and was allowed on the trunk link to the L3 switch. The trunk link was up and protocol was up. Everything that I had admin access to was now properly configured and had been tested however the traceroute was still not returning. I put this to the customer who inspected their L3 Switch. They reported that VLAN10 had not been created after all on their equipment.

Once the customer applied their configuration on their equipment the route from SiteA to the ASA firewall on the LAN of SiteB worked. It was only after the issue was investigated that it became apparent the customer had neglected to account for the routing required for SiteA when they planned the closure of their old office. As a result none of the required configuration had been prepared before hand and SiteA had been cut off once the old office closed.

Trouble Ticket #1 - Closed.

As you can see on this occasion I was able to use a 'Divide and Conquer' trouble shooting approach. Starting L3 and then checking L1 and L2 when the traceroute failed. On R3 I was able to narrow the issue to L2 and formulate my hypothesis which was then tested.

Saturday, September 24, 2011

CCNP - TSHOOT - Troubleshooting the Routers...

Continuing my TSHOOT methodology, in this post I'm going to look at troubleshooting the network between R4, R3, R2,R1 and out to the web server at

Having not sat the TSHOOT exam the impression I'm getting is the Trouble Ticket (TT) will state something like Client1 cannot access [insert resource]. As such you need to identify the system the issue is on and the resolution.

Again I'll be referring to the actual  TSHOOT topology - here

Let's say Client 1 cannot access the web server at Based on my previous article, also assume Client 1 can ping at R4. In this post I will outline how I see myself troubleshooting the connectivity issue to the web server.

I'll want to prove connectivity to R1. So in turn I'll ping each interface on the way to R1 at If at any point the ping is not returned then log in to the router that you were trying to ping and begin troubleshooting.

1) Are the interface on the link UP/UP? check that one of them is not admin'd down:
#sh ip interfaces brief

2) With interfaces up, is the L2 Frame-Relay topology correct? the diagram shows that the routers are connected via point-to-point links therefore I'm expecting to see a config similar to:
R4(config)#int s0/0/0
R4(config-if)#encapsulation frame-relay point-to-point
R4(config-if)#no shutdown
R4(config)#int s0/0/0.34 point-to-point
R4(config-if)#ip address
R4(config-if)#frame-relay interface dlci 403

3) Assuming L2 is fine move on the routing protocols. Things to check here are:
i - is route redistribution functioning correctly on R4? check the routing table, check config
ii - Are the adjacencies up? Check the neighbor tables/topology tables.
iii -Are the correct networks being advertised to the neighbor? check the ospf network statements
iv -  is there any authentication in place? if so it must match at each end
v - is the routing table including the correct route as per the network diagram? If the route is not in the routing table it won't be advertised out to the neighbor.
vi - Is the routing config command 'passive-interface default' set? if it is then updates will be suppressed by default. You need to either remove the command using #no passive-interface default
Or you specifically list the interfaces you want to participate in dynamic routing using:
#passive-interface default
#no passive-interface f0/0
#no passive-interface f0/1
and so on...

4) Up to R1 I think that would cover off all the major connectivity issues you'd be likely to get. If you still have problems look closer at R1.

On R1 check you can get to the next-hop outside of the network. If you can the config on R1 should be sound. If you can't it could indicate any of the following.
i - Check over the interfaces as per previous points. Ensure they are UP/UP. if they aren't then troubleshoot accordingly.
ii - Check routing/BGP - is the BGP peering up? if not check the config, if the update source being used is a Loopback address then you need the update-source command set in the BGP config. Check the IP's of the Peers, check the remote-as command is correct
iii - Is there a default route? I'd expect there to be one. Simple question. Is it pointing to the correct outbound next-hop? not in towards the LAN?
iv - Are there any access-lists? if so, what are they permitting and what are they blocking? Could the implicit deny  be causing an issue here?
v- Is the default route being correctly redistributed? I'm expecting to see something like:
R1(config)#router ospf 1
R1(config)#default-information originate
vi - Is NAT in operation? check which interface is inside, outside, check the ip nat source statements. Check any NAT pools that my be configured? if a pool is not configured then I'm looking for the 'overload' option in the command :
#ip nat source list 10 interface s0/0/1 overload
With out Overload then port address translation is not working and you'd only be able to have 1 host using NAT at any one time.

Based on the exam topology I'd hope that by running through my structured check list from L1, L2 to L3 to L4 and above that the issue in hand would be revealed.

When I'm in the exam I'll be taking my cue from the information in the TT. As such I might not need to bother with L1/L2 checks if the remote peer is responding as expected.

My next article is going to look at the IPv6 topology and look at how I might be troubleshooting problems there.

Tuesday, September 20, 2011

CCNP - TSHOOT - Considering the Client...

In the TSHOOT exam the bulk of the trouble tickets will pretty much be Client1 cannot access [insert resource here], identify the problem device and present a solution.

The TSHOOT topology is freely available from the Cisco website - here - and so we can take a look and start to suggest possible problems that can be presented. On it we have BGP, OSPF, EIGRP and redistribution, NAT, DHCP, IPv6 Tunnels, OSPFv3 and RIPng redistribution, we've got first hop redundancy and etherchannel, plus OSPF over Frame-Relay. Some pretty tasty stuff.

So, where to start? Well, lets say that Client1 can't access the web server at As I'm looking at client issues assume that the config between the web server all the way in to the network to R4 is fine.

When I'm in the exam I'm going to be looking to ensure connectivity to Client1's default gateway and the DHCP server at R4 is sound. When I find that Client1 is unable to ping the default gateway or obtain a DHCP allocation here is what I'll be looking for:
1) Client1 IP Assignment - The L2/L3 topology diagram states that the address is obtained via DHCP (R4 at On Client1 do >ipconfig - if the address is move to ASW1, if the address is 169.X.X.X then DHCP is not working properly for some reason. In both cases move to ASW1

2) Interface VLAN membership - Client1 should be connected to int f1/0/1 - is it? if not then correct as appropriate. Interface f1/0/1 should be a member of VLAN 10 - does the VLAN exist? :
#sh vlan

Is int f1/0/1 a member of VLAN 10?:
#sh run int f1/0/1 OR #sh vlan

Does ASW1 have any port security?
#sh run int f1/0/1
if so what is configured here? Does any static MAC address match that of Client1? does the port limit number of MAC addresses per interface? Problem is here is if port security is incorrect. Otherwise move on

3) Is VLAN 10 allowed on the trunks?
Firstly prove int Po13 is an active Etherchannel and that interfaces f1/0/19-20 are members
#sh etherchannel summary - Trouble shoot accordingly if this is not the case.

Next is int Po13 a trunk link?
#sh interfaces trunk - if not then problem is here.

Next which VLAN's are allowed on the trunk links?
#sh interfaces po13 trunk - if VLAN10 is not here then you won't get to DSW1

Next, can you see any VLAN filtering in place? if so check that any permited ACL has the correct ip range otherwise traffic from will not be allowed to use VLAN10. Also check the vlan access-map config ensure that the traffic allowed in the ACL is forwarded not dropped.

Do step 3 on both ASW1 and DSW1. If one side is not configured correctly then connectivity will fail.
If everything looks good you should be able to at least ping VLAN10's dfg at on DSW1, move on.

4) Check routing on DSW1:
- DSW1 is an L3 switch that needs to send your DHCPDISCOVER to the DHCP server on a different network. As such ensure ip routing is enabled:
DSW1#sh run | begin ip routing
- Check L3 connectivity between DSW1 and R4 - Ping, check interfaces are UP/UP
DSW1#sh ip interface brief
- Check DSW1 int f1/0/1 is not admin'd down:

- If all looks good here check that the ip-helper command is applied to interface VLAN 10:
DSW1(config)#int vlan10
DSW1(config-if)#ip helper-address
(this will tell DSW1 to forward UDP broadcasts received on this interface)

5) You should now be at R4. If all of the above looks good then you should look above L2/L3 to DHCP or other factors.

6) DHCP configuration:
- Is DHCP running on R4? look for service dhcp in #sh run
- Are there any leases active? check - #sh ip dhcp bindings
Check the Hardware Address with that of Client1 to ensure the correct Client has an assignment. If you've discounted steps 1-4 I'd be surprised if this was the case.
- Check the DHCP address pool is correctly configured:
DSW1#sh run | begin ip dhcp
look for any kind of misconfig here be it incorrect subnet defined for the pool or an exclude address incorrect

7) At this point I'd expect to have uncovered an issue. If that's not case there's still some tactics I can try.
i) Kevin Wallace suggested Abort! - if you think you've narrowed the issue to a point but are unsure of the final solution, hit Abort, dive in to a different ticket and cross check the config. If the config is different the here is your fault. If it's the same then you can discount that area as the source of the problem and move on
ii) Let the question guide you - you've narrowed the issue to, lets say, DSW1 but are still unsure. Review the options available to you in part 2 and part 3 of the trouble ticket and use the information there to gleen if you are looking in the right place.

I think I've covered off the major issues that could be presented. I guess HSRP on DSW1 could be an issue but if DSW2 is the active router (#sh standby) then you should still be able to reach the DHCP server at

Please let me know if I've missed a point or am miss guided in any way. Thanks

CCNP - TSHOOT - 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 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.

Monday, September 12, 2011

CCNP - TSHOOT - Maintenance Models

The main models used in assisting with the maintenance of a network are as follows:

  1. FCAPS - which is - Fault mgmt, Configuration mgmt, Accounting mgmt, Performance mgmt and Security mgmt. Defined by ISO (International Organisation for Standardisation).
  2. ITIL - the IT Infrastructure Library, which is a collection of best practices. When implementing this PLEASE PLEASE PLEASE remember it is Best Practice not THE Practice. I've worked at companies who have idiots Service Delivery Mangers who think that to be 'compliant' they need to implement all of the guidelines regardless of how big the firm is or how suitable the process is to their enterprise </rant>
  3. TMN - Telecommunications Management Network, the ITU-T's variant to FCAPS tailored to the telecommunications field.
  4. Cisco Lifecycle Services - You should be familiar with this from your ROUTE and SWITCH studies Chpt1. Covering the PPDIOO - Prepare, Plan, Design, Implement, Operate, and Optimize life cycle.

Monday, August 8, 2011

CCNP - TSHOOT - 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

Friday, August 5, 2011

CCNP - TSHOOT - 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:

  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

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.

Sunday, July 24, 2011

CCNP - TSHOOT- 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)#path tftp://$h.txt
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://

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.

Sunday, July 17, 2011

CCNP - IPv6 - Some thoughts...

I recently attended a course hosted at UK PLC in Aldermaston, near Reading which was lead by Natalie and Sandra from RIPE NCC in Amsterdam.

Looking at 'IPv6 addressing for LIR's'. The company I work presently has one IPv4 /21 available to allocate and we've just applied for our own IPv6 allocation so the powers that be decided to send me on a course to see what's what and how best to assign subnets to our customers.

So what did I learn? well, in no particular order I took the following from my day:
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.

Wednesday, June 22, 2011

CCNP - TSHOOT - The Plan of Attack

For my final CCNP exam I've fore gone the Cisco Networking Academy and I've decided to self study. The main reason for this was a that I've moved jobs and the costs associated with attending the course are no longer being met by my employer.

Feed back I've had from fellow students who I was with on the CCNP SWITCH course has been that the TSHOOT academy course has not really been up to much. One student reported that he felt that he could have just bought the course manual and studied at home.

I find that disappointing as I had such a positive experience of the Cisco Networking Academy doing my CCNA, ISCW, BSCI and SWITCH Courses. In general I'd recommend that if you get a chance to attend a Cisco Networking Academy do it.

Moving on I think I'm about half way through my CCNP TSHOOT studies. At the present time I'm using the following materials to self-study:

CCNP TSHOOT Official Certification Guide by Kevin Wallace CCIE #7945
CCNP TSHOOT Cert kit by Kevin Wallace CCIE #7945, Brent Stewart, Eric Rivard
Troubleshooting and Maintaining Cisco IP Networks (TSHOOT) - Foundation Learning Guide by Amir Ranjbar CCIE #8669

Also I've taken a look at the TSHOOT demo questions - here - which are a great example to give you an idea of the test environment.

Finally, on the Cisco Learning Network you can obtain the actual L3, L2 and IPv6 topologies use for the TSHOOT Trouble Ticket Questions. You can find them  - here.

Use these topologies well. Inspect the lay out and inspect the notes. Can you see any Video Conferencing (therefore Multicast)? can you see any L3 redundancy? Which? Which VLAN's are in use? what do you think should be present in any trunk configs? Which routing protocols are in use? what would you expect the config to look like using these protocols? can you see any redistribution? can you type up any associated config?

This is where I'm at so far. Next stop my plan for approaching the TT questions in the exam.

CCNP - TSHOOT - What's next....

...It's been a while since my last post during which I have mostly been actually doing my TSHOOT studies rather than writing about them.

Over the next articles I'm going to cover off area's I'd like an on-line record of. You might think something of them are not necessary or indeed rudimentary, however I like to document things so that I have them many months/years later when I might suddenly need to use which ever technology I blogged about so long ago.

I'm going to start with my thoughts on how I will approach the TSHOOT exam. I'll then move on to specific topics and also look at things that can actually be avoided in any depth (and there are some topics).

Onwards and Upwards...

Thursday, April 14, 2011

CCNP - SWITCH - I passed!

I passed the CCNP SWITCH exam on Monday morning at the second attempt :o)

With much relief I'm now having a couple of weeks off the study to catch up on jobs about the house before I crack on with TSHOOT and get my CCNP in bag.

So far as the exam was concerned I felt that it was challenging but not impossible. I believe people regard this as the hardest of the 3 exams and on measure I would say that it has been the toughest Cisco exam I've sat so far.

Without breaking the NDA, I'd say the exam tests a lot of the detail in a narrow spectrum of topics. The same areas kept cropping up in the multiple choice, multiple answer questions and also the labs/simlet questions.

For any one attending a Cisco Networking Academy, you can ignore multicast completely. If you've got the Cisco Press books you'll see that in the Foundation Learning Guide, multicast is present (chpt 7 I think) BUT in David Hucaby's Official Certification Guide it is not. I think Hucaby's book is more recent so this explains the difference. Also check the exam topics on the Cisco Learning Network and you'll note that multicast is not listed in the tested subjects either.

Other than that little bit of advice I'd recommend you watch your time very carefully. I got to question 49 of 50 and was presented with a lab! I was lucky to have sufficient time remaining and was able to calmly complete it working on the gamble that I wouldn't get a 5th lab ( yes I did get 4 labs) at question 50. I might have felt differently had I only had a few minutes remaining for the last 2 questions. So be warned.

Onwards and upwards.

Thursday, April 7, 2011

CCNP - ROUTE - Practical Application of Route-Maps

Bit of an odd one to chuck in here as I'm still to sit my CCNP SWITCH however I thought I'd log an interesting situation I've encountered at work and how the use of a simple route-map can benefit your network.

Imagine you are migrating from one ISP provider to another. The current provider not only offers your web filtering but also your DNS, web mail, and other hosted services so you can't simply cut them off. You need to be able to split out the Web filtering to your new provider whilst maintaining access to the old ISP for the hosted services.

As part of this move you are migrating the internet access of 300 sites. Each site is getting a new firewall as well and the move to the new ISP is taking place as each site gets it's new hardware.

Due to this hardware change you will end up with some sites on the old hardware pointing to the old ISP and some sites on new hardware pointing to the new ISP.

My question is this, with the minimum of in put by your self how do you run both ISP's at the same time and have the new sites point to the new ISP for the web filtering whilst maintaining access to the old ISP for everything else?

Here is the solution, on the router that provides the connection to both the Old ISP and the New ISP:

1) ip route
2) access-list 111 deny ip any
3) access-list 111 permit ip any
4) route-map new-isp permit 10
5) match ip address 111
6) set ip next-hop
7) interface GigabitEthernet0/0
    description ***Inbound Interface towards the ISP's***
    ip policy route-map new-isp

Breaking it down line by line the config is as follows:
1) This is the default route to the old ISP. This required for all sites that have not migrated, also your hosted services are located in this direction. DNS, web mail, Anti-virus are located on servers on the subnet.
2) Extended ACL denies packets from any Host going to the old ISP for hosted services, this stops that packet being processed by the route map and therefore prevents the next hop from being changed. The denied packet will be processed as usual by the routing engine and as such you maintain access to your hosted services.
3) This permits the packet from this subnet, to any destination, to be processed by the Route-map. As each site is kitted out with it's new hardware you add the site's IP range ( a /24) to this ACL. This in turn is permitted to be processed by your route-map and the next hope for web filtering is changed.

Remember that if your newly migrated site still needs access to DNS, web mail etc, this will be caught in the first line, the DENY any statement and will not proceed to the route-map for processing.

4) This is the entry for your route-map
5) The match statement catches permitted IP's in ACL 111
6) Any matched IP's in ACL 111 are then directed to the new ISP at, the New ISP will provide your web filtering only.
7) Apply your route-map to the inbound interface that receives the traffic from all the sites that are being migrated. The route-map is porcessed at this point and the next-hop defined.

So what happens next?
Each time you want to cut over a new site you simply add a permit statement to ACL111.
Straight away the route-map will pick it up and web traffic will be diverted from the old ISP to the New ISP.

Ultimately you will end up with up to 300 sites listed in ACL111. Once all sites have been migrated you can change your default route, remove the route-map and run access to the internet as normal.

Wednesday, April 6, 2011

CCNP - SWITCH - Switch Security Features - IP Source Guard

IP Source is used to prevent IP Spoofing where an attacker impersonates another host by using it's IP address.

IPSG provide per-port filtering of the assigned source IP, it dynamically maintains per port VLAN ACL's based on the IP-to-MAC bindings set out in the DHCP Snooping database.

IPSG is applied on Untrusted ports and can filter a Source IP or a combination of Source IP and MAC address.

When a violation occurs the packet can be dropped and/or an alert be issued.

Apply IPSG to Access Layer interfaces

Configure IP Source Guard
First enable DHCP Snooping:
  SW1(config)#ip dhcp snooping

Next, apply DHCP Snooping against a specific vlan (or vlans):
  SW1(config)#ip dhcp snooping vlan [id]

Enable IPSG on a specific interface:
  SW1(config-if)#ip verify source vlan [id] dhcp snooping*
    - use this command to verify only source IP addresses

  SW1(config-if)#ip verify source vlan [id] dhcp snooping port-security
   - use this command to verify against source IP and MAC address

Optionally, you can also rate limit and interface
  SW1(config-if)#switchport port-security limit rate [invalid-src-MAC] [rate]

You can also statically bind an IP address to a port:
  SW1(config-if)#ip source binding [ip] vlan [id] interface [id]

Verify IP Source Guard
Use the following commands to verify your configuration:
  SW1#show  ip source binding
   - Displays MAC-to-IP binding, type of binding, vlan membership, interface the binding applies to.

 SW1#sh ip verify source
   - Displays your interface, filter type and mode, IP addr, MAC addr, and VLAN

CCNP - SWITCH - Switch Security Features - Dynamic ARP Inspection

DAI is used to prevent invalid or gratuitous ARP requests in the same VLAN.

When ARP is used correctly, a host sends a broadcast to locate the MAC of a destination host. The Destinations host replies with it's MAC and the originator caches that MAC address and applies it to the Dest field in it's packets.

ARP spoofing is where an attacker appears as the Destination host by supplying it's MAC address against the legitimate host's IP address. The Originating host caches the attacker's MAC and directs packets to the rogue Destination instead of the legitimate Destination.

DAI intercepts packets on Untrusted ports, packets are then validated for IP-to-MAC bindings that have been gathered from DHCP Snooping.

Denied packets are dropped and/or logged. Incoming ARP requests from Trusted ports are not inspected. Like DHCP you can also rate limit the ARP requests per second. Rate limiting can help prevent port scanning.

Configure DAI
In general configure all Access ports as Untrusted. Configure all switch trunks as Trusted so that no further inspection of packets is required as the request travels through the Access-Distribution- Core of your infrastructure.

Enable DAI on a per VLAN basis:
  SW1(config)#ip arp inspection vlan [id]

Define your trusted ports:
  SW1(config-if)#ip arp inspection trust

NOTE - default configuration for ports is Untrusted.

Verify DAI
Use the following commands to verify your config:
  SW1#show ip arp inspection interfaces
   - Displays interfaces, trust level, any rate limiting, and any bursts noted.

  SW1#show ip arp inspection vlan 10
   - Displays DAI state for the vlan (Enable/Disabled)

  SW1#show ip dhcp snooping bindings
  - Displays MAC-to-IP bindings.

CCNP - SWITCH - Switch Security Features - DHCP Snooping

The following tools can be used to mitigate against Denial of Service attacks and Spoofing attacks.

DHCP Snooping
Feature found on Catalyst switches, DHCP snooping prevents attacks against DHCP servers by monitoring which ports are allowed to pass DHCP packets.

A typical attack can be where an attacker configures a rogue DHCP server and connects it to a port on your switch. When a client sends a DHCP Request out the rogue DHCP server attempts to respond quicker than legitimate DHCP servers. The rogue DHCP server offers the client IP settings (including default gateway and DNS servers) and can then direct the client to use an Attacker's client as it's own DFG. As a result the attacker can now see all of the client's traffic.

Another type of attack can be a denial of service where the attacker floods the legitimate DHCP with 1000's of DHCP Requests it over runs the server and the server is prevented from responding to legitimate DHCP requests.

How DHCP Snooping works is that once set the switch has Trusted and Untrusted ports for DHCP traffic. A trust port is for ports connected to DHCP servers or links that allow access to DHCP servers. The Trusted port is allowed to pass all DHCP Packet types (DHCP Discover, Offer, Unicast Request, Unicast ACK).

An Untrusted port is a port that shouldn't have a DHCP server on and so only be allowed to make a request to a DHCP Server.

Once configured if a rogue device connected to a DHCP Snooping Untrusted port tries to respond to a legitimate request the switch shuts down the port.

Configure DHCP Snooping
DHCP Snooping is enabled globally:
  SW1(config)#ip dhcp snooping

By default all interfaces are untrusted and you define your trusted ports:
  SW1(config-if)#ip dhcp snooping trust

Optionally, on Untrusted ports you can limit the number of DHCP packets allowed per second:
  SW1(config-if)#ip dhcp snooping limit rate [rate]
     - this command can prevent DHCP Starvation attacks where are available leases are used up.

Finally, you can configure DHCP Snooping on specific VLANs:
  SW1(config)#ip dhcp snooping vlan number [id]

Verifiy DHCP Snooping
Use the command:
  SW1#show ip dhcp snooping
    - displays state of dhcp snooping, configured VLANs, configured interfaces, any rate limiting in effect.

Tuesday, March 29, 2011

CCNP - SWITCH - Planning notes

My list of Planning notes in one place:

Create a Plan to Support Video in the Campus - Here

Create a Plan to Support Voice in the Campus - Here

Create a Plan to Support Wireless in the Campus - Here

Create an Implementation Plan for Inter-VLAN routing - Here

Create a VLAN based Implementation Plan - Here

VLAN best practices notes - Here

CCNP - SWITCH - QoS pointers

This article is a work in progress and I'll keep coming back to this. Apologies if you read this and think there's not much here.

Quality of Service is a mechanism to address the following traffic flow characteristics:
Delay/Latency - time it takes for a packet to reach the destination
Jitter - Variation of the delay or a stream of data
Packet Loss - number of packets lost between the src and dest points.

CCNP - SWITCH - Create a Plan to Support Video in the Campus

Video applications sit at layer 7 of the OSI model. They can demand high bandwidth due to the requirement to send frames as well as audio.

Real time video applications (such as Telepresence) require minimal delay and should be prioritised in the QoS configuration.

One-way videos (such as You-Tube) are not as sensitive to delay and jitter. They can be buffered by the client then replayed to produce a high quality output.

Video traffic is generally 'bursty', groups of images sent together, whilst a pause may result in few packets being sent together.

As a result traffic flow need to be managed and planned for. Consider the following requirements for Video then plan your QoS deployment across the switch infrastructure accordingly.
Video requires High bandwidth, less than 150ms delay, low jitter, <1% packet loss, high availability, potential for PoE (such as Video Conference equipment).

CCNP - SWITCH - Create a Plan to Support Voice in the Campus

Voice over IP services are pretty much standard in the enterprise. Driven by the cost-reduction benefits VoIP delivers an excellent Return on Investment. Usually expensive to first deploy they recoup their costs over the life time of the deployment.

When planning to support VoIP consider the following points;
1) Voice and Data have to co-exist on the same network infrastructure but Voice can be affected by echo, jitter, and dropped audio. Use QoS to prioritise Voice traffic over Data.

2) Define a separate VLAN carry the voice traffic (create the VLAN then apply the interface command #switchport voice vlan [id] -  on the ports carrying your voice traffic )

3) Plan for Power over Ethernet. The phones you use will require power. Usually delivered over the structured cabling, cat5e or such like, you need to be clear that your switch can deliver PoE. If it can make sure it can support the required number of handsets.

4) Plan for the traffic requirements. Voice traffic is generally smooth and predictable when managed properly. Keep in mind that packets are generally small, don't tolerate latency, uses UDP (TCP is pointless as once a word is said it cannot retransmit the data. Should a packet be lost, the conversation and therefore the traffic flow has moved on). Plan for delay to be no more than 150ms across the campus, plan for no more than 1% packet loss. Correct deployment of QoS can pre-empt these issues.

CCNP - SWITCH - Planning a Wireless Deployment

When planning for a a wireless deployment consider the following points in formulating your plan.

1) Will your solution use Standalone Access Points (AP's) or be a Controller-based solution using Lightweight Access Points (LAP's)?
Standalone AP's - Operate independently, have standalone IOS on board, are configured directly on the AP, can be managed via  Wireless LAN Solution Engine (WLSE) and redundancy is offered by deploying multiple AP's.
Controller-Based AP's - Are dependent on a Wireless LAN Controller (WLC), IOS is delivered to the LAP via the WLC, configurations are applied from the WLC, management is via the WLC, and redundancy is provided by the deployment of multiple WLC's.

2) Collect information on the required switch ports to connect your AP's and WLC or WLSE

3) Check the local infrastructure to make sure the new WLAN solution can be implemented, this will include monitoring available bandwidth.

4) Set out a plan for the additional equipment required.

5) Plan your implementation, to include where you intend to locate the AP's, the configuration of the AP's/WLC, necessary configuration of the switch ports (do you require trunks for Standalone AP's or an access port for a LAP?).

6) Develop a plan to test your new WLAN solution which could include check points such as does the client get an IP address? Can the management devices reach the AP's or WLC? Can the WLC reach the RADIUS server (for authentication).

With the information gathered from the points above you should be able to formulate a suitable plan that can be deployed and verified.

Monday, March 28, 2011

CCNP - SWITCH - Create an Implementation Plan for Inter-VLAN Routing

Inter-VLAN routing can be implemented in several ways. You might wish to configure an external router, use an SVI on a Layer3 (L3) switch, or use routed ports on an L3 switch.

Which ever way you choose to implement your configuration you'll need an implementation plan.

The following steps outline the considerations you need to make with regards to using an external router:
1) Know how many VLANs need routing, their ID number, name, and which ports will connect to the router
2) On the router, work out your sub-interface requirements. You'll have a single link running from the router to the switch configured as a trunk. On the router side you'll then need a sub interface for each VLAN you're wishing to provide inter-VLAN routing for. Number each sub-interface logically i.e. - the same as the VLAN it represents. Ensure the encapsulation method is the same across each sub-interface and across the link to the switch. (usually Dot1q all round).
3) Decide on the Native VLAN and ensure it is the same on either end of the link.
   use the command - #int f0/0.[id]
                                #encapsulation dot1q [vlan-id] native*
4) Finally use the interface command - #encapsulation dot1q [vlan-id] - to associate a VLAN to a sub-interface

*Remember that traffic on the Native VLAN is not tagged

The following steps outline the considerations you need to make with regards to using an SVI:
1) On your L3 switch identify the VLANs that require a default gateway.
2) For any SVI's not already present on your L3 switch you will need to create then. As such you will need to decide on suitable numbering for the SVI (should be the VLAN ID number) plus an IP address to associate with it. Don't forget to No Shutdown the interface.
3) To perform L3 routing functions you need to set the L3 switch to be able to perform the routing. To achieve this use the global command - #ip routing - this will enable to switch to route between your VLANs
4) Define any appropriate dynamic routing protocols. Typically required if you are configuring a larger enterprise network that may be subject to change. You can deploy RIP, EIGRP, OSPF which ever you feel is appropriate.
5) Finally with the information above gathered consider if you require any given SVI to be excluded from contributing to the SVI state Up-Down calculation. Do this using the 'Autostate' feature

The following steps outline the considerations you need to make with regards to using an Routed port:
1) Plan your addressing for each VLAN and which port is going to be a routed port.
2) The remaining steps are much like the SVI. Configure your routed port using the command #no switchport - which removes L2 capability. Apply an IP address and enable the port via the #no shutdown command.

 REMEMBER - when you are under pressure and your links are not up use the command - #sh ip int brief - to make sure you have enable the port concerned. If you see 'Administratively Down' against your problem port go back and do a #'no shutdown - Obvious I know but you wouldn't believe how many times I've seen students scratching their heads in a lab because of this.

3) To allow inter-VLAN routing use the global command - #ip routing - then apply any dynamic routing protocols as required.

Sunday, March 27, 2011

CCNP SWITCH - VLAN Best Practices

When deploying VLANs consider the following points for best practice. Sometimes limitations may occur such as budget or physical locations (lack of space in your racks) however where possible try to deploy the configuration points.

  • For local VLANs try to limit access modules to 1-3 VLANs. Limit these local VLANs to the Access and Distribution switches in your switching block
  • Avoid using VLAN 1 as the 'black hole' for unused ports. 
  • Have separate Data, Voice, Management, Native, 'Black Hole' or 'Parked' VLANs 
  •  Avoid VTP for local VLAN deployments (you're not intending on populating the local VLANs across the campus therefore you don't want VTP to inadvertently advertise these VLANs across your switching infrastructure)
  • For Trunk ports - hard set your ports to trunks - don't rely on DTP. (#switchport mode trunk NOT #switchport mode desirable)
  • Use Dot1q not ISL - this has better support for QoS.
  • Manually configure access ports - #switchport mode access
  • Prevent data traffic from VLAN 1, only use it for management protocols that default to using VLAN 1 such as DTP, VTP, STP BPDU's, PAgP, LACP, CDP et al
  • Use SSH for management access not telnet.

CCNP - SWITCH - Create a VLAN based implementation plan

Onwards and upwards.

The first in a series of posts relating to planning is on VLAN implementation.

The steps you should cover when planning a new deployment of VLANs should be as follows:
1) Understand your network. Define the purpose of your VLANs and assign suitable numbers, names, and allocate suitable subnets for each VLAN
2) Document which VLAN should be allocated to which part of the campus. In doing so you need to determine the traffic flow between switches and so which VLANs need to be available across which switches.
3) determine how you allocate unused ports on your switch. Will you leave them as default setting, assign them to a 'Parked' VLAN, assign them to the default or native VLAN?
4) Consider you trunking configuration. Where will they be placed? which VLANs will traverse them? which is your Native VLAN?
5) Determine your VTP stance. Will it be used? if so which switch is your Server? which switches can be Clients? will you need any Transparent switches?
6) Create a plan to test the implementation. Verify the VLANs traverse the network as expected, confirm there is capacity for future growth.

With the information gathered from the steps above you can move to the design stage of the PPDIOO and set out your deployment. From there you can implement your plan and verify it prior to making the deployment operational.

Sunday, March 13, 2011

CCNP SWITCH Exam - why I failed...

So, last Friday morning I turn up to my local test centre ready to face the 642-813 Implementing Cisco IP Switched Networks exam. I had done the labs, read the books (David Hucaby's Official Certification Guide and the Foundation Learning Guide that accompanies the Cisco Networking Academy course), I had also passed my CCNP SWITCH Networking academy course with flying colours. So passing the certification exam was going to achievable wasn't it...WASN'T IT?

After 2 hours I knew I had failed even before the screen pinged up with my score. Close but no cigar. After the initial frustration (taken out on the interior of my car) I ran through the exam result sheet which clearly showed the Simulators sticking out like a sore thumb. Trying to think back at the questions I had faced also revealed another area - 'Planning'?.

Finally, I did a Google search for 'Failed CCNP SWITCH exam' and it was then that 2 + 2 made 4. On forums and chat rooms across the web one acronym kept turning up - BCMSN.

BCMSN! after smacking my fore head for being such a dumb ass I came to the realisation that that was what had let me down. I had used the old CBT Nuggets videos on the BCMSN. I had sourced abridged notes on the BCMSN study material (publically available from your popular studying blogs) combining them with the official SWITCh material I thought I had every thing covered. But I hadn't.

The new CCNP SWITCH focuses on practical hands on tasks required in such roles as a Network Engineer, BUT and here is the crux of my failure, it also focuses on the Preparation, Planning, Design, Implementation, Operation and Optimisation of a network. Some of the area's were tested thoroughly on the BCMSN exam but Preparation, Planning, and Design certainly weren't.

And so there I had it. I had nailed the practical stuff but dropped short on the Preparation, Planning and Design.

So what I am going to do? Well between now and 3 weeks time when I sit this exam again I'll be looking back at Chapter 1 - PPDIOO and tailoring my lab work against each criteria. Goodbye BCMSN videos and  material and hello harder studying.

A (£117) lesson learnt. The hard way.

Friday, February 18, 2011

Cisco Configuration Guides

I thought I'd log the location of the following site:

This is a fanstatic place to stop and read around a subject. Remember to try and use more than one source of material to give yourself a rounded view of a topic.

Tuesday, February 1, 2011

CCNP - SWITCH - the Cisco Networking Academy course

Last night saw me sit the end of course exam for the CCNP SWITCH Network Academy course. I bagged a passed with 75% and passed the course with a score of 86%, which will do for me.

I found it interesting chatting to the guys after the exam that the opinion of the exam and of the course in general was that the difficulty had been ramped up a touch. I've attended my Networking Academy with the same guys for 2 years now and I know roughly where we all sit in ability. In general we were all scoring 5-7% less on the new CCNP track compared to the CCNA track or the old CCNP ISCW and BSCI courses.

My thoughts for the new CCNP course are as follows:
Pro's - Course emphasis is much more on practical, hands on lab work and troubleshooting. Learn the labs and the commands inside out. The course material was easy to follow and well presented and I didn't notice the shocking errors in the chapter quiz's/exams that were present in previous versions of the CCNP

Con's - The course material is now in a book instead of being online via the netacad website. For me this was an annoyance as it wasn't made clear prior to enrolling on the course that I needed to purchase said course manual on top of paying my course fees. I for one would have preferred to have the cost of the book bundled in to the course fees and then it could have been handed out on the first night. Instead I had to order it that week so it would be delivered in time for week 2.

Also in having the course presented in a book it meant that I had to keep the weighty manual on me at all times on the off chance I had a quiet moment to continue my reading. Previously I could have just fired up the website and away I go.

Conclusions - I really enjoyed my time on the course and got a lot out of the lab time and the access to the tutor. I guess your experience will depend greatly on the availability of hardware and the quality of the tutor presenting the course however for me this was great value for money and well worth 16 evenings of my time.

If you get an opportunity to enrol on a Cisco Networking Academy course I highly recommend it.

Monday, January 31, 2011

CCNP - SWITCH - Spanning-tree Protocol - Tools to Prevent Loops

There are a number of tools that can be employed to make the STP topology more stable.

1) Root Guard - prevents an unexpected switch from becoming the Root Bridge. Enable RootGuard on all non-root ports on all switches expect the Root bridge.

If a designated port receives a superior BPDU that could cause the bridge to accept a different switch as the Root Bridge the port enters a 'root-inconsistent' state (instead of transitioning to a Root Port and therefore changing the STP topology).

The 'root-inconsistent' state will remain for as long as there are superior BPDU's being received on the port. Once the BPDU's stop the port cycles through the STP states to return to it's usual function.

Enabled on a per-port basis only:
sw1(config-if)#spanning-tree guard root

2) BPDU Guard - loop prevention mechanism applied to ports using PortFast so that if a BPDU is recieved on the port the port is placed in to an error-disabled state instead of allowing the traffic to be forwarded and potentially creating a loop.

If a BPDU is being received on the port there must, by definition, be another switch on the other end of the link. PortFast enable ports transition to a forwarding state instantly which is a benefit for end-station devices such as PC's which would be requiring a DHCP address as part of it's start up process. If you had a switch connected to a PortFast enable port packets could be forwarded and a loop created. BPDU Guard helps prevent this.

Enabled globally via:
sw1(config)#spanning-tree portfast bpduguard default

Or on per-interface basis via;
sw1(config-if)#spanning-tree bpduguard enable

3) BPDU Filtering - If a BPDU is received on a PortFast Port BPDU Filtering detects this and removes the PortFast status on the port. The port then transitions through the STP stages and the port then takes it place in the STP topology.

It works slightly differently depending on how the command is executed. When applied globally:
sw1(config)#spanning-tree portfast bpdufilter default

The PortFast enabled port loses it's PortFast status and transitions through the STP stages

When applied at interface level:
sw1(config-if)#spanning-tree bpdufilter enable

The PortFast enabled port is prevent from sending and receiving BPDU's entirely.

4) Unidirectional Link Detection - UDLD - A unidirectional link occurs when a physical fault on a link is such that electrical keepalives can pass across the link but can't pass data in both directions. UDLD detects this state by sending periodic hellos across the link which must be acknowledged.

There are 2 modes -
i) Normal - Link state turns to Undetermined State, port is allowed to continue working and UDLD marks the port and generates a syslog message

ii) Aggressive - The port is set to 'error-disabled', manual intervention is then required.

When enabled Globally it ONLY applied to Fibre ports:
sw1(config)#udld {enable | aggressive}

When configured on a per-port basis use the same command however you now have the option to disable it entirely if you are using a fibre optic port.
sw1(config-if)#udld {enable | aggressive | disable}

Re-enable a port shut down due to UDLD:
sw1(config-if)#udld reset

Verifiy UDLD:
sw1#sh udld interface

5) Loop Guard - Prevents loops forming on ports that transition from Blocking to Forwarding due to suddenly not receiving BPDU's from the switch on the other end of the link. If BPDU's stop being received on a blocking port the max-age timer eventually expires (as there haven't been any further BPDU's to refresh the timer) and the port then cycles through the STP states as it thinks there is no longer another switch on the other end of the link.

If the port transitions to a forwarding state then a loop can occur. Loop Guard helps prevent this sequence of events by tracking BPDU activity on non-designated ports.

If BPDU's are suddenly no longer received Loop Guard puts the port in to a 'Loop Inconsistent' blocking state. The port then remains in a blocking state and a loop can be avoided.

Loop Guard automatically enables the port again once BPDU's start being received again.

Enable globally via the command:
sw1(config)#spanning-tree loopguard default

Enable on specific ports using:
sw1(config-if)#spanning-tree guard loop

Loop Guard works on a per VLAN basis so doesn't block the entire port simply the VLAN is blocked.

CCNP - SWITCH - Spanning-tree Protocol Link Convergence Tools

The following tools allow for faster link convergence in relation to STP:
1) Portfast - Applied on access switch ports linked to host devices (not other switches). Transitions the port to a forwarding state straight away instead of transition through the STP states Listening (15 secs), then Learning (15 secs), and finally forwarding. Not to be used on trunk links as it could result in loops occurring.

Applied globally via:
sw1(config)#spanning-tree portfast default

Or per interface:
sw1(config-if)#spanning-tree portfast

Portfast is also applied using the macro interface command:
sw1(config-if)#switchport host

2) UplinkFast - Applied to access switches, allows fast fail-over when dual uplinks are connected to a distribution layer switch. Can incorporate multiple redundant links to an uplink switch (not just 2 links), where there are more than 2 redundant links to a given switch the link with the next lowest root path cost is unlocked  immediately.

UplinkFast bypasses the Listening and Learning stages.

Note that the command is not allowed on a Root bridge as UplinkFast ensures that the local switch does not become the Root bridge. UplinkFast raises the Bridge Priority to 49,152 therefore it is unlikely the switch would become the Root bridge.

Applied globally via:
sw1(config)#spanning-tree uplinkfast

3) BackboneFast - Enabled on ALL switches in the topology, allows for fast convergence to the network backbone or core after an STP topology change. It shortens the STP convergence times by actively determining whether an alternate path exist to the Root bridge when a link goes down. It uses Root Link Query (RLQ) protocol to detect if the upstream switches have a connection to the Root bridge.

BackboneFast shortens the Max-age timer which in turn can reduce convergence times from 50 secs to approx 30 secs.

Applied on All switches in the topolgy using:
sw2(config)# spanning-tree backbonefast

Verify using;
sw2#sh spanning-trree backbonefast

Thursday, January 27, 2011

CCNP - SWITCH - Inter-VLAN routing notes

- The Forward Information Base will be updated when:
i) An ARP entry for a dest next hp changes, or is removed
ii) The RT entry for the next hop changes
iii) The RT entry for a prefix changes

CCNP - SWITCH - Spanning-tree Protocol notes

- Once a root bridge is elected, Configuration BPDU's are sent only by the Root Bridge. All the other switches must forward the BPDU's (or relay them) adding their own send Bridge ID to the Message.

- On a config output if you see 'Spanning tree enabled protocol ieee' it indicates ieee 802.1d (Common SPanning-Tree) is in use REGARDLESS of the ROLES listed.
- Enable Loop Guard on root ports and alternate ports
- If a BPDU is received on a Loop Guard port that is in an inconsistant state the port will transition to the appropriate state as determined by the normal function of the spanning tree verion/type in place
- Root Guard is enabled on a per-port basis, it re-enables a switch port once it stops receiving superior BPDU's
- When you have a link that is configured as Half-duplex on one end and Full on the other the following situations could arise:
 i) The switch with the Full Duplex setting could unblock it's port potentially creating a loop
 ii) The switch with the Full Duplex port will not be performing CSMA/CD
 iii) BPDU's amy not successfully negotiate port states on the link between the two switches.
- A switch running 802.1d (cst) will use the Forward delay timer to age out entries in the MAC address table when a tology change is received.
- MST extends 802.1w to multiple spanning trees.


- When configuring a Trunk link, be sure to configure the same native VLAN at the each end. If you leave a trunk with default settings, VLAN 1 will be used by default.
  If you see the cmd #switchport trunk natvie vlan [id] on one end and not on the other you will get a mismatch error
- On an ISL enabled trunk if it received an unencapsulated frame it will be dropped.

CCNP - SWITCH - Implementing IP Switching notes

- GAP analysis should be conducted at the Plan phase of the Lifecycle Services approach
- NAT can consistantly increase the load on a CPU on a MLS switch.
- TTL decrementing and rewrite of Src and Dest MAC Addresses do not occur on a L2 switch
- L3 switching provides the ability to circumvent CPU processing

CCNP - SWITCH - Preparing the Campus for Advanced Services notes

- With regards to Multicast, IGMP snooping is enabled by default on catalyst switches
- When traffic from a multicast source is received on a port that it not expected the router will drop the packets.
- is reserved for Network Time Protocol
- You might implement Voice services on a network to reduce costs and increase productivity.

CCNP - SWITCH - Port Security notes

- An attacker would launch an MAC Flood Attack to capture data from the network and to initiate a DoS attack.
- use the cmd #sh monitor session 1 detail to observe whether data is being sent in association with that session.

CCNP - SWITCH - First Hop Redundancy notes

- A standby router configured with HSRP will take 9 seconds to detect the loss of an active router (based on default timers)
- With GLBP there is no limit to the number of routers you can implement in a group, however only a maximum of 4 active routers will be forwarding at any given time (due to a limit of 4 virtual MAC addresses that can be used with a group).
- Default GLBP priority is 100, when a router is the Active Virtual Gateway or an Active Virtual forwarder either the priority has been increased from the default on the AVG OR the Priority has been reduced from the default on the AVF

Thursday, January 20, 2011

CCNP - SWITCH - Planning topics

Discussions on the web indicate that the CCNP SWITCH exam asks much more about 'Planning' your deployments.

A good point of reference is - - written by Dave Hucaby who wrote the Official CCNP SWITCH Certification guide, the blog expands on the topics outline in his book particularly on Planning.

It appears that some of the official Cisco material may be lacking in this area so brush up any gaps via Dave's blog and you shouldn't go wrong.

CCNP - SWITCH - Inter-vlan Routing Notes

- Router interfaces on a Router-on-a-stick setup are configured as L3 subinterfaces

- Reasons you wouldn't need to implement an SVI;
i) Provide failover for a failed primary SVI
ii) Provide connectivity to an external router for inter-vlan routing

- The cmd 'Autostate Exclude' could be implemented on a port that is used for monitoring and is connected to an IDS

- A Glean adjacency is when a MLS connects directly to several hosts and the FIB table maintains a prefix for the subnet rather than individual host prefixes

- If you get 'incomplete' or 'drop' adjacencies check the switch hasn't been configured with unsupported software features.

New Year, New Job!

It's been a while since my last entry. We've had Christmas, New Year, family time, work, and studies. I've also had a recruitment process to contend with.

Last week I was pleased to find that I was successful in my application to become a Cisco specialist at an ISP based in North Yorkshire.

My current role is in doubt and so I decided to jump before I was pushed. In my new role i will be getting to develop those skills learned at the Cisco Networking Academy and I'll be able to get hands on with Service Provider technologies such as MPLS VPNs and BGP.

I start in February and I can't wait :o) , the team I'll be working with are really nice and friendly and already I feel I'm going to enjoy working there.

Game On...