Well no luck I’m afraid ūüôĀ

I agree with many of the other complaints about this exam, there seems to be a large number of questions that are not covered in the course material. I say that having read the foundation guide, cert guide, flash cards, and quick reference sheets.

CISCO have now made a statement that due to the high levels of complaints they will be reviewing the exam. So rather than wast time trying to pass it again. I will carry on my studies with the ROUTE course, which has had much better reviews, and come back to the SWITCH. Hopfuly by then CISCO will have sorted out the issues.


Time up!

Well a night of study and now its to bed for some sleep before my CCNP SWITCH exam.

Hopefully by the time of my next post I will be one third of the way towards achieving my CCNP.

If I’m honest I have not been impressed with the Cisco Press books, or the BOSON test exam, both I have found many errors in. (Hopefully the fact I spot the errors means I understand the topics)

But all going well I will be back with a little something on getting the CISCO SDM to work in Linux soon.

Trouble Shooting with ACL’s (part 2, naughty CISCO and there firewall)

OK so following on from here ¬†Trouble shooting with ACL’s (part 1).

To recap for un-know¬†reasons packets had begun to get lost on one of my firewalls, and by using a¬†combination¬†of ACL’s applied to interfaces, logging commands and debug commands, I had established that while icmp¬†packets¬†sent from the¬†router¬†to the inside network where¬†coming¬†back in the interface. they where then some how getting lost with out any¬†notifications.

Fig 1

So the last think I had done was enable the “#debug ip packets 150” on the router where 150 was an¬†access¬†list to capture any traffic to or from the address. From this I was¬†receiving (after a display of the packet going and¬†coming) the following last line from the debug.

000801: Sep 13 12:40:35.452 UTC: pak 64A7D05C consumed in enqueue feature , packet consumed, CCE Firewall(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE.

This didn’t really help to much to start with, as any google searches on various parts of that got me no where. I then spent several moments looking at the firewall¬†policy’s. I knew that the router set up as a fire wall, places any¬†connected¬†interfaces¬†in to the “self” zone.¬†¬†So although the interfaces and are servicing two¬†manually¬†configured zones (“inside2 and “management”), the ports them selves are¬†actual¬†part of the “self” zone. So I was looking for any policies between the “inside” and “self” and the “management” and “self” zones.

All I could find was a single policy that was assigned between the “inside” and “self” zone. However the direction for this was from the “inside” to “self“, that allowed ICMP and¬†denied¬†every thing else (so inside network can’t manage the router). So this still did not seem to explain the issue I was seeing, as the default policy unless configured is “self” is allowed to talk to any thing.

However after much searching on the internet I finally came across this.

"Although the router offers a default-allow policy between all zones and the self zone, if a policy is configured from any zone to the self zone, and no policy is configured from self to the router’s user-configurable interface-connected zones, all router-originated traffic encounters the connected-zone to self-zone policy on its return the router and is blocked. Thus, router-originated traffic must be inspected to allow its return to the self zone."

From Cisco’s documentation.

It goes on to¬†describe¬†how if a policy is applied in to “self“, then a policy must also be applied outgoing from self to the zone to allow return traffic to be inspected… So yes that little policy I had noticed above really was causing all the trouble. And guess how it got there?

Well it had¬†originally¬†been an ACL applied to the interface. But when I ran CISCO SDM to help configure Easy-VPN, it had asked to make changes to the fire wall to insure still worked. And created the policy for me and applied it.. Which is the reason for the title of the post. I don’t¬†generally¬†like to use the SDM, but for¬†learning¬†it is useful.¬†However¬†this¬†just¬†shows how important it is to¬†check¬†the configs first and insure you keep ¬†record of exactly what it is doing in case problems arise.

Solution was simple, either remove the policy above and replace it as an ACL assigned to the interface, or others wise set up an out going policy from “self” to “inside“, to either allow all traffic and inspect (or just allow the traffic you want to go to self).

In my view you don’t want any traffic from “inside” to “self“, apart from ICMP. This allows you to check a user can see the DFGW, but prevents any¬†management¬†traffic, so stops any attacks on the router from users or compromised systems inside your network. (Oh if you use IP helper address for DHCP the router must also be able to see these through your policy).

But yes all working fine now and lots more learnt about fire wall policies. Been a slight distraction from my CCNP switch studies but these are still going well. Just 7 points to go over before the exam, all simple ones just want to go through configuring them once more. Wish me luck!!



Well you might notice I am not updating and working on this blog much this week. Main reason is I have my CCNP SWITCH Exam coming up in a few days and hard at work revising!

I think I have it sorted just as long as no silly planning questions catch me out. It seems as though Cisco want you to “forget” things you know, and only come to the exam with the exact information in the book. It doesn’t matter if something is actual correct.. If its not in the book then you are not expected to know it.

config wise and technology I think I am fine though. I have been working on LAYER 2 for 5 years now so apart from a few small bits running through the book has been confirming lots of what I have learnt on the job over that time.

Still had time to play with the links in the blog and add a few more quotes.

And later I have a part 2 for trouble shooting with ACCL’s to write up, and a nice layer 3 NAT scenario to lab up soon to show a use for the “NAT enable” and virtual NAT interfaces. Hopefully get one of them at least sorted out this week, but if not I will do it after my celebrations (I’m thinking positive here) at passing.


Trouble shooting with ACL’s

We all know of ACL’s for use in restricting traffic when applied to an interface, and also for classing traffic such as when used in NAT to chose the ranges to¬†apply¬†NATing to. But they can also be very useful in trouble shooting you network, and the last few days brought this back to me.

It all started with what seemed like a simple problem. On one of my networks the DHCP helper function had stopped working, and clients could no longer get an IP address. However a quick check of he DHCP server and a glance over the config on the network devices and it all seemed fine.

Now the set up is quite simple, your standard basic router on a stick set up. With a CISCO 1841 as the router, which as well as working as the router also is set up as one of the network firewalls. With one interface pointing to the internet (not shown) and the other to the internal network.


We can imagen¬†that the DHCP server is sitting in VLAN 200 and the clients that have¬†stopped¬†working are in VLAN 100. So what’s going on?

Well first move was to look at the DHCP logs on the server to see any sign of requests eing received. Nothing there suggesting the packets whegetting stopped before they gotthere.

Check the router config for the “ip-helper” command. This all looked fine and a quick ping from the router to the DHCP server shows that there is not issue with the router forwarding packets to it. Net step ping the Client PC from the router….. OK¬†here’s¬†an issue router can’t ping the Client? But the client can reach the internet through the router? And stranger still the Client CAN ping the router interface of ¬†

To bypass any other part of the network, I set up two SVI on vlan 100 and 200 on the switch directly connected to the router and checked the trunk was carrying both. Again the switch could ping both the interface on the router, but the router could only ping the IP address assigned to the SVI for vlan 200?

Well the first step was to work out if the router was indeed sending a packet out, as I mentioned the Router also acts as a fire wall so could a policy update be causing the issue?

Here is the first use for ACL’s in trouble shooting. Debug commands in cisco are very useful as we know, and one I have used often is the “debug ip packet detail”. But before you go typing it in to a router to test, be aware it will have a massive hit on the CPU and you will be over¬†whelmed¬†with information as the detail of every packet crossing your router is displayed to you.

Before you start debugging create an access list that will permit all the traffic you are interested in. In this case I only want to see traffic to and from, so logging on the the router create the access list.

ip acccess-list extended 150

permit ip any host

permit ip host any

Then you can run the debug command and only view the details about packets covered by this access list.

debug ip packets 150 detail

Enabling this on the Router and again pinging the address and the debug output show the packets sent out on vlan 100, and to be sure enabling the same debug on the switch and I could see the packets both received from the router and being sent back out the same vlan interface. Yet the router logs show no sign of packets getting dropped or even being received. Neither dose this debug show any sign of the packets this is not surprising as debugging IP packets shows packets that are crossing the control plane of the router and if an  ACL or the fire wall are blocking them they will not reach this.

So here is the next use for a ACL in trouble shooting. One of the first steps a packet takes when¬†received¬†on an interface is getting checked by any applied ACL. This is a¬†reasonable¬†step as for security reasons you want to drop any rogue packets ASAP. ¬†So by creating adding the line “permit ip any any” to the end of the above ACL, and the command “log” to the first two line. I then applied this ACL to the interface in the inward direction.

Now repeating the ping to from the router and I see in the logs packets being transmitted and getting¬†received. Now I know that the issue is with in the firewall¬†policy’s¬†on the router.

So yes ACL’s are not only great for security and for managing live data flows across the network. But they are also¬†useful¬†in trouble shooting,¬†especially¬†when used to filter outputs of show and debug commands to ¬†useful information. And using the log function you can capture¬†sporadic¬†issues with out having to be logged on¬†the whole time¬†watching¬†for it.


PS. There is also the “debug packet” command to capture traffic¬†received¬†on an interface, but I like the simplicity and logging ability of using an ACL.

A new way to navigate.

Unfortunately¬†I¬†can’t¬†get the full paper on this, however the link below is to the¬†article¬†on¬†new scientist.

An alternative to turn by turn

I should point out this is not for car drivers, but for pedestrians walking through¬†city’s¬†and towns. Although I can see how it could¬†easily¬†be adapted for cars. The Idea is simple, with most turn by turn based solutions on our¬†hand-held¬†devices you are directed the most direct way to your destination. This¬†invariable¬†takes you on the main streets, or even worse down some back ally where all the shops are throwing out there rubbish.

In¬†Swansea¬†university they¬†developed¬†a new method. Rather than displaying a map, the device simple vibrates when you point it in the direction you need to take to get to your destination. So if there are several routes your device will vibrate across all of them. Although apart from the¬†strength¬†of the vibration and with of its field, the idea seems to be there is no way to “know”¬†which¬†one is quicker. You simple chose the one you like the look of and continue on your way.

Now I know for many people the best was is the fastest, no matter what you see along the way. But for people on holiday in a new city, often the reason for visiting a city is to see the sites. A system that will keep you pointing in the right general direction, while allowing you a choice of the exact path I think could become a standard feature on hand held devices.

I can also like I said see it being used in cars, Of¬†course¬†we have to be¬†careful¬†here as you don’t want drivers spending to much time worrying about what turning to make.¬†However¬†we already have the¬†ability¬†to avoid motor ways and toll roads. but these still give us a fixed route, and although system will¬†re-root¬†if we take a wrong turn, they don’t upfront give us any information about the¬†alternatives. My be a system where you¬†can¬†set an¬†acceptable¬†%¬†increase¬†of¬†journey¬†time for¬†alternate¬†route to be suggested.¬†Then¬†as you¬†approach¬†a turning where the¬†alternative¬†falls with in this limit, the system alerts you to the¬†alternative¬†and tell you how much time it will add.

I really like this idea as I love to see new areas, but I am hopeless at direction. I hope it makes it through to a hand-held device near me in the future.


Music to the Cloud

So came across this today.

Moving music to the cloud

I wonder if this is just another one of those ideas that will disappear in to the ether, or will it actually take of this time.

It’s all we seem to here now, “the cloud”. But the issues is always going to be that even if there is 99.9% coverage. The times you want to be listening to your music are when driving / holiday / walking, there very times you are most likely to be out side of the¬†coverage¬†areas. And the only way to cope with this is to have off line local storage that you can carry around with you as we do right now.

May be the way to manage a cloud based music system if not to charge for how much music you have access to. But how much you can store off line. So you would pay for a set amount of off line storage that you can save to your music player. Each time you download a song it is subtracted from your allowance and each time you check a song back in it is removed from your device and you account is re-credited.

So you still always have access to all the music, and you can keep your favourite music local to you for those time when you are out of coverage. With the artists getting paid depending on how often there tunes are played through the cloud of when they are downloaded .

But can cloud music possible bet the¬†piracy? In my view Piracy is not winning because it is cheaper (although this is a big factor I grant you), but¬†because¬†there are no ties. Once you have a tune, it is yours, you can leave one piracy site and go to another and you don’t lose what you already have. No one likes to be tied to a company, and this is why I personal¬†dislike¬†I-tunes, the idea that music¬†purchased¬†through¬†it is tied to it. So if a better offer comes along or a better player you can’t take advantage of it.

In my view this is what has got to change and is what will bring people in from piracy, that once you have purchased¬†music¬†it “belongs” to you, or at least for you to listen to how and when you want to. For this to happen there has to be an open DRM standard that all of the industry sign up to. But while all the different¬†companies¬†fight to get customers and then lock them in. Piracy will only get worse.

I like the idea of cloud music, especially the peer to peer model, but I will be surprised if this takes of in any really big way, or really changed the music industry.



Man I seem to be contently adding my quote collection but still no where near the end! In fact not even 20% of the way through! Main trouble is that I have them all over the place with different formats so have to copy each one by hand! Once there all up I shall be tidying up the quote pages.

On a side note added a few more flash cards to Anki, some QoS stuff.

QoS and leaky Buckets

Just been going through QoS in the foundation guide, it has a small bit on the Leaky bucket algorithm, but I think the wikipedia article explains in much clearer.

I had always though of it as the packets where the water running in to the bucket and there was a small hole in the bottom from which it drained out. As long as the average in was less than the drainage hole, and bursting did not over flow the bucket the water flows out with out spilling.

However I see now that in the case of CISCO switches the leaky bucket is a metering method. The packet it self does not flow in to the bucket. Rather how fast the packets flow in to the switch determines how fast the tap above the bucket it flowing. While the bucket it not full the packets can pass through the switch. But if the bucket should over flow the packets are dropped until enough water has run out of the bucket that they can continue.

Like I said the article on wikipedia explains it all very nicely, so if like me it is taking a bit to get your head around have a look.


Do you like the Pretty links?

Getting¬†the pretty Permalink’s to work on this blog has been a bit of a pain,¬†According¬†to¬†word press¬†you click on the format you want under the settings and then they¬†should¬†all¬†work nicely.

so rather than have a link that looks like


you can have the same link looking like


Pretty ūüôā right.. ūüėČ

So how did I get it all up and running?

I found out when first trying to activate it that I came across a “page not found error” suggesting that the mod_rewrite module in¬†Apache¬†was not running correctly. And after lots of searching around I found it this is to do with the “Allowoveride” directive in Apache.

The default setting for the directive in the virtual site file in Unbuntu is,

<Directory />
Options FollowSymLinks
AllowOverride None

Further reading suggests that with this set to none, the .htaccess file that is needed for  mod_rewrite to be able to work will not be used.

Searching the net lots of people suggest changing this to “Allowoverride All”, which after a restart of Apache will work fine. But for a little more security I found “Allowoverride FileInfo” will¬†achieve¬†the same thing.

And that’s it, one little word change is the¬†difference¬†between it all working fine and page not found!

The same can be achieved by editing the httpd.conf and associated config files, but as I use virtual sites I prefer editing these directly.

Thank fully the old style links¬†still¬†work¬†just¬†find, the mod_rewrite simple takes the pretty version of the link and translates it back to the ugly version behind the scene. Leaving you the user with a more¬†pleasurable¬†browsing¬†experience. ¬†ūüôā