Receive/Transmit

I recently read this post on Ivan Pepelnjak’s blog, where he discusses a pretty intense debate about whether or not firewalls are actually any good. The area where people are claiming they aren’t is in front of servers. One of the main benefits of a firewall is stateful packet inspection – the firewall monitors what connections are taking place and dynamically opens ports to let permitted return traffic through. However one opinion is that since all packets to a server are unsolicited, stateful tracking is useless and you should instead stick with basic routers and access lists (which don’t fall down as easily in the event of  a DoS/DDoS). I suppose this opinion is talking of servers in the classical sense, where they only ever take inbound connections and don’t initiate outbound ones. Its very interesting reading, especially the comments.

For my part I don’t deal with set ups big enough to hit some of the limits they are discussing but it’s certainly thought provoking. Most people’s standard response is that you should have a firewall in front of everything, but after following the discussion I’m now not so sure

This little problem had me scratching my head for a while, and as usual the solution is pretty simple. The scenario is that you have some kind of link from an ISP with static addresses. At some point you have outgrown your original assignment and have requested a new block, which the ISP has set up at their end. You want NAT an address on the new external subnet to an internal address as shown below. Now on a PIX or ASA you just set up the NAT rules and everything works, but in IOS things are a little more subtle. First the diagram and relevant initial configs. Note that the customer router only has an external IP on the first subnet – in our case this was due to a lack of spare addresses:

(continue reading…)

If you are working on a Cisco, it can be very useful to see details of the traffic going through it. Occasionally you can use a mirrored (SPAN) port to do this, but if you have exotic interfaces or are using Dynamips this can be more difficult. The “debug ip packet” command will dump packet information straight into your terminal. Occasionally though you will have traffic going through the device but no output shows up in the debug, whats that all about?

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

Router#terminal monitor

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

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

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

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

If you work in a technical field, chances are you will have had to earn some vendor certifications. Personally I hold certs from Cisco, Microsoft and Red Hat, with VMware and Riverbed soon to follow. When you start doing these you tend to just go with the flow and learn what they tell you to learn – after all who are we to argue with the wisdom of the technical Gods at company x? Once you’ve done a few though you will find the odd exam where something just isn’t quite right with regards to the content and the target audience. I’m going to pick on Cisco here because I’ve done quite a few of their exam tracks (CCNA, CCNP) and am currently working on another (CCDA). This is applicable to most vendors however.

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

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

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

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