Monthly Archives: September 2010

CCNP SWITCH update

Posted on by
1

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.

DevilWAH

Download article as PDF

Time up!

Posted on by
Reply

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.

Download article as PDF

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

Posted on by
Reply

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 192.168.10.254 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 192.168.10.254 and 192.168.20.254 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!!

DevilWAH

Download article as PDF

CCNP EXAM

Posted on by
Reply

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.

DEVILWAH

Download article as PDF

Trouble shooting with ACL’s

Posted on by
1

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.


FIG 1

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  192.168.10.254??

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 192.168.10.254, so logging on the the router create the access list.

ip acccess-list extended 150

permit ip any host 192.168.10.254

permit ip host 192.168.10.254 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 192.168.10.250 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 192.168.10.250 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.

DevilWAH

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.

Download article as PDF

A new way to navigate.

Posted on by
Reply

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.

DevilWAH

Download article as PDF

Music to the Cloud

Posted on by
Reply

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.

DevilWAH

Download article as PDF

Quotes

Posted on by
Reply

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.

Download article as PDF

QoS and leaky Buckets

Posted on by
1

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.

DevilWAH

Download article as PDF

Do you like the Pretty links?

Posted on by
Reply

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

“http://www.devilwah.com/?p=344”

you can have the same link looking like

“http://www.devilwah.com/2010/09/minority-report-the-reality/”

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
</Directory>

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

DevilWAH

Download article as PDF