Sorry for it being a bit quiet over here since the new year, I had a few weeks of on vacation in Disney in Florida and then shortly followed by me moving house so things have been a little hectic to say the least.
I have started to settle down again now however my internet connection is still a few weeks out so I am left with a dodgy 3G connection which seems to be up and down more times than a yo-yo!
The power issue that was affecting the rack I was using for my CCIE studies is now sorted out so I am going to start from the top again (I hadn’t got that far with the INE labs anyway) and continue reading through my pile of books and RFC’s.
At the moment I’m reading through ‘Routing TCP/IP Volume 1’ and whilst it is a bit repetitive in places due to it going over everything again there are definitely things that go more in-depth than other books I’ve read.
Well that one time a year that the entire world grinds to a halt is upon us, yes thats right its Christmas time.
Things have been unfortunately quiet on the studying front for the past couple of weeks, I had started going through the INE Vol1 labs however a temporary power issue has taken my CCIE rack offline and therefore things stopped just as I was getting to the end of the RIP labs.
In the meantime I have been slowly reading through ‘Routing TCP/IP Volume I’ which is a great book however SO much of it has already been covered that at some parts it feels a little like pulling teeth!
Work has been pretty quiet (as it always is around this time) so that is a little bonus, hopefully the power will be restored to the rack shortly so I can get some labbing in in between the christmas and new year break but I don’t know whether that would be a blessing or a curse!?
In other news I have just signed a lease for an apartment and will be moving in at the start of February so no doubt that will delay the studies some more.
On that note I will leave you all, have a Merry Christmas and a Happy New Year and I will see you all on the fresh end of 2012.
Well all that studying seems to have payed off a little, today I sat the CCIE R&S Written exam (350-001) and passed it!
Without going into any NDA-breaking territory the exam was actually pretty easy, partially caused I think by studying some topics at a much deeper level than I perhaps needed.
During my time studying for the written exam I mainly used the Cisco Press CCIE R&S OCG but also used the INE Adv Technologies videos for some of the topics that I felt I needed more details on.
At the moment I can’t decide whether to take a weekend off studying or whether to dive straight into the lab studies.
Doing what I do best I am setting myself a goal to have the lab ready for April ’12. Given my past record with meeting cert deadlines I’m guessing this might get pushed back, but not by too much hopefully.
Going forward from here I am going to try and stick to (more in content than time) the INE study plan as it seems pretty reasonable and I could do with some kind of structured plan, why create your own when someone has already gone to the trouble for you?
My next topic for writing up my notes is the security section.
For this post and all posts following I will be using the CCIE blueprint from Cisco here (you may need CCO access to access that document but that is free).
My reasoning for structuring it like this is to make it easier both myself to reference and hopefully someone else will find it easier as well.
Some of the information is a little basic and will have been covered at CCNA and CCNP levels but seen as CCIE doesn’t actually have any pre-requisites I thought it best not to leave any stone unturned.
Implement access lists
There are two types of access lists that can be used on Cisco platforms; the standard access list and the extended access list.
Standard access lists are a little basic in their use and can only match on the source address of the traffic you are matching.
Extended access lists differ from standard access lists in that they can not only match on both source and destination addresses but they can also match a whole plethora of other things such as L4 src/dst port number, DSCP marking, packet size etc.
Just like there are two different types of access list there are also two different methods of configuring them.
Firstly there is the numbered access-list method (which is the older method) where depending on what number you give to your ACL will depend on what type it is:
1-99 - Standard access list
100-199 - Extended access list
1300-1999 - Expanded standard access list (useful if you have >100 standard ACL's)
2000-2699 - Expanded extended access list (useful if you have >100 extended ACL's)
There is also the named access-list method in which the name that you give to the access list is completely agnostic to type of ACL it is. When you are using named access-lists you have to explicitly tell the CLI which type of access-list you are creating.
Things to remember about all ACL’s:
– All ACL’s end with an implicit deny all
– Order of statements in the ACL is critical (they match on a top down approach)
Continue reading →
With under a week to go until my CCIE written test it’s time to go over my notes and get some of them written up to get them fresh in my mind. Todays notes of choice are my multicast notes.
The notes may be a little sparse in places so if you can add anything or spot any mistakes please let me know.
Common Multicast addresses
All host group which contains all devices on the same network
All routers group which contains all routers on the same network
PIM Version 2
IGMP Version 3
Cisco Auto-RP-Announce address
Cisco Auto-RP-Discovery address
Multicast address types and ranges
Local network – Addresses in the 22.214.171.124 – 126.96.36.199 are assigned by IANA and are designated for applications that are to be used in the local network only and are to not be routed on the internet.
Internetwork control block – Addresses in the range 188.8.131.52 – 184.108.40.206 are assigned by IANA and are designated for the use of applications that should be routed over the internet (such as NTP, 220.127.116.11).
SSM address block – Addresses in the range 18.104.22.168/8 are reserved for the use by source-specific multicast applications.
GLOP addresses – Addresses in the range 22.214.171.124/8 are reserved for use by organizations who have been allocated an AS number, the second and third octets of the address are made from the 16-bits of the AS number.
Admin scoped addresses – The 126.96.36.199/8 range is considered private (much like the RFC1918 unicast address ranges) and therefore should NOT be see routing on the internet.
PIM (Protocol Independent Multicast)
Protocol independent means that it doesn’t matter which type of unicast routing protocol you use underneath.
There are other multicast routing protocols that do rely on particular routing protocols like M-OSPF (multicast OSPF).
There are 3 different types of PIM that are used, these are: Sparse mode, dense mode and sparse-dense mode.
Sparse mode supports two types of trees, the (*,G) tree and the (S,G) tree.
The latter is more efficient as the traffic travels along the shortest path (also known as the SPT) whereas the shared tree can travel along a less than ideal route to the destination.
Dense mode as default runs in a (S,G) mode as it floods all traffic throughout the domain however this is less than ideal as it means that traffic can be flooded to places that do not need it.
Dense mode does allow for traffic to be pruned however this is only a temporary action and therefore needs to be constantly refreshed.
On a shared LAN segment if there a multiple PIM routers then only one of them will forward the join/prune messages towards the RP, this role is called the ‘Designated Router’ and is elected by virtue of whoever has the highest IP is the DR.
Earlier today there was an issue raised on one of our new(ish) ME3400 switches that we have started to deploy to customer sites.
We started getting SNMP traps from it complaining that its CPU was maxing out, not something that we would expect to see from a switch, let alone a switch that was WELL within its operating limits.
After jumping on sure enough the switch was showing a pretty high utilization on the CPU with regular spikes up to the mid 90% range.
After some regular diagnostics by the second line guys it got passed over and it was then that we saw the issue.
The ME3400 has two possible SDM templates, those being ‘Layer-2’ and ‘Default’ and it seems that this switch either came out of the box with ‘Layer-2’ enabled or someone enabled it during deployment (for some reason!?).
Usually having the wrong SDM template on a switch may just vary the amount of a particular amount of ‘things’ that you are allowed, for instance you may be allowed 2k route entries on a certain template but 8k on another etc.
With the ‘Layer-2’ template on the ME3400 however you get (amongst other things) NO space for IPv4 unicast routes which means that the TCAM has no space allocated for it, this is what was causing those horrible CPU spikes!
The ‘Default’ template that we later switched to has room enough for 8,000 route entries which is more than adequate!
For more information on the SDM templates on the ME3400 check out the Cisco page here (you will need a valid CCO login for it though).
Things have been pretty hectic over the last few weeks/month and so I haven’t had much dedicated study time, sometimes only managing a few pages of the CCIE Cert Guide per day.
I know I kind of dropped the ball and that this kind of thing won’t stand when I’m heading for my lab attempt but I fully intend to really knuckle down once the written is out the way.
I have just finished the Multicast chapter in the cert guide and am now part way through the security chapter. Once I’ve completed the cert guide I’m going to run through the Cisco press quick reference guides and also hit up some of the INE ATC videos for any weak subjects.
Hopefully I will get some of the draft posts that I have partially written completed and put out over the coming weeks but I still haven’t picked up a style that feels natural and whenever I re-read one of my articles it just comes across as being a little bare/scarce with the details, as always feedback is more than welcome on anything I’m doing right/wrong.
Thanks for reading and enjoy the rest of your day! — David
Earlier today Network World posted an article regarding a vulnerability that had been discovered in the OSPF (Open Shortest Path First) routing protocol.
The whole of Twitter, G+, Facebook, Forums etc seems to be running with this article and saying how bad it is for everyone.
The exploit that is being discussed is where an attacker can inject falsified LSA’s into the OSPF database therefore possibly creating a MITM (man in the middle) / DoS (denial of service) attack on your network.
When I first read the article it made me think about other protocols that are vulnerable in this very same way. Continue reading →