CCDE Pursuit & Blog

malcybood

Hey All,

As it seems to be quite the thing these days, I have decided to document my CCDE Journey here including general musings on progress where my blog will cover technical posts.

Cisco CCDE Study Blog

The blog will be updated regularly over the coming weeks and months. I have around 20 posts in draft which are based on study I've already completed but only have the notes in whiteboard format. I'm working on transferring every whiteboard session into a "readable" format offline and will publish the posts / content as they are completed.

I posted in one of the other threads around my background and CCDE progress, so to give an overview for those who didn't see that post I've copied it over.

I've been focussed on CCDE study since March / April 2015 and been working as an designer / architect as below:

- 2 years in global outsourcing / hosting company (detailed / low level design / engineering)
- 2 years in gold partner (Technical Architect / TDA - Presales HLD / project escalation for design and implementation)
- 2 years in Telco / ISP (Solution Architect designing regional / national MPLS networks with local loop unbundling)
- Current role - 5 months at a Cisco partner working across enterprise WAN, LAN, WLAN, Security, DC solution design)

Prior to that

3 years as network admin at an enterprise and 3 years in IT support / field engineering before that, so I guess I have around 9 years solid networking experience with around 7 or 8 of that being involved in design.

I will be sitting my second attempt of the CCDE Written later this month.

I had less than ideal prep for the 2 or 3 days in the lead up to my first written exam attempt (which I won't dwell on or bore you all with) and failed last week with 618 / 1000, but I think I'm comfortable with the areas I need to brush up on and also the usual time management was an issue. That was only because there was a higher than usual number of questions it also took me a while to get my head around the type and style of questions with it being my first expert level exam that I have taken.

Despite failing the first written attempt I felt OK with the subjects and just need to drill into a couple of the areas I think!

I have been using Cisco Live to study and taken up Safari Books subscription in addition to already having multiple books from previous study where I'll post a book list if and when I pass the written exam. I also invested in a 6ft x 3ft whiteboard to take notes on where I study a topic, take notes on the whiteboard, take a photo on my phone and erase / onto the next topic. First time I've used this approach but I definitely think it is a worthwhile investment for this type of exam.

From what I understand, the key to the CCDE is being able to think as an architect and making the transition from having the mind set of what the ideal solution is (which we commonly identify as engineers) vs what the customer is asking for and why would a particular technology suit their business requirements.

I hope the thread is insightful and useful to someone other than myself to vent

Cheers

Essendon

Lemme be the first to barrack for you during this arduous journey! Though most of what you'd write in here would be waaay OTT for me, I'll use this thread as a source of motivation and inspiration. Good luck mate!

gorebrush

Excellent, good to have you here. There are a number of us still cooking on 1st or 2nd IE's now (as you will have seen)

malcybood

Thanks both.

Business drivers and rationale behind technology selection, design and deployment is a key aspect to the CCDE; therefore today I have posted my first QoS article focussed on business and technical drivers behind QoS deployment.

Cisco CCDE Study Blog: Quality of Service (QoS) Introduction & Business / Technical Deployment Drivers

I had originally started to go for a "QoS" post, but even based fleshing our my original QoS design notes this subject matter is far too large, so I'm breaking it up into a few separate posts to avoid the blog posts being too overkill.

My rationale behind this post is that before you can design a QoS policy, we need to know what the outcome of said policy should be, which applications should be included and how we want to to treat the traffic.

This post will give an overview around some business drivers related to QoS deployment, before we even think about anything technical.

More QoS technology design posts will follow this one.

malcybood

Today has been busy despite it being the last day before returning to work from around 10 days holiday doing some general household tasks and spending time with my son and wife.

Around that I've managed to get around 5 hours in today on the initial QoS blog post and the below follow up, in addition to some general reading on routing theory from Optimal Network Design chapter 7 (HA & Fast Convergence) and Top Down Network Design Chapter 2 & 3 around analyzing the network.

Cisco CCDE Study Blog: QoS Classification, Marking, Shaping & Policing

This is the 2nd QoS blog post and covers

- Classification & Marking
- Shaping
- Policing

Managed to knock up a quick architectural policing / shaping diagram to explain the theory too.

I felt queueing is a subject that can be covered with congestion avoidance and buffering etc.

The next post will change focus from QoS and I'll come back to it as I need to focus on some higher priority areas. Likely to jump into GET VPN, DMVPN and the SP side of things for the next few days as these are areas I think I need to brush up on, so I'll update as I progress.

malcybood

I didn't achieve anything in respect to studying today but thought I'd check in here to keep the momentum going. I hope to get back to the books tomorrow and get a short blog out onto my Blogger page!

First day back at work today and was working on an 3rd line escalation for a new managed service deployment that is experiencing a strange VPN / firewall issue. We are running a hardware VPN in network extension mode and seeing some strange behaviour when traversing through an ASA firewall, where we have deployed hundreds of these hw clients, so that was back to work with a bang and took a bit of digging to help the NOC guys identify the issue.

Think we are getting somewhere with it though and should have it resolved tomorrow!

Packet pushing aside and as mentioned I have not done any study this evening after the troubleshooting day at work and I do the nursery pickup on Monday and Tuesday so had the little man to entertain until around 9pm when he felt like closing his eyes.

Instead of giving myself brain strain studying tech tonight after 9pm I decided to update my CCDE planner which is a CCDE planning tool that Cisco have recently made available at the below links. I'll let you guys look into that yourself as it's ultimately a spreadsheet but a useful one if you are studying towards the CCDE.

Page - https://learningnetwork.cisco.com/community/certifications/ccde/written_exam/study-material
Spreadsheet - https://learningcontent.cisco.com/cln_storage/text/cln/marketing/ccde_writtenexam_prep_resources.xlsx

I've got alot of green (in my opinion) and a fair amount of amber, but you can't know everything right and there is probably some woprk to do even in the green areas. You'll know what I mean if you open the sheet.

Aside from that I have also booked my flights and accommodation to attend Jeremy Filliben's CCDE Practical class in Orlando this November. I spent a few hours trying to identify the best travel package as I'm travelling from the UK to Orlando, but I got something within budget and I'm buzzing to go attend this course later in the year.

Further info here.

Jeremy Filliben: CCDE Practical Bootcamp October 19-23, 2015 - Orlando, Florida

That's all for today and going to catch some zzzz's as I'm into the office tomorrow with a bit of a commute then back to hitting the books tomorrow night.

malcybood

Another busy day at work and hopefully resolved the weird issue I mentioned yesterday but I'll find out tomorrow after the fix has been running for a while and I've returned from a presales meeting with a customer on security. Not quite sure what aspect of security yet but all will be revealed I'm sure!

Tonight I thought I would put something up about virtualized networking, so the following post is me putting some conceptual design principles for virtualized WAN & data centre "down on paper" that can't be lost or buried at the bottom of my laptop rucksack!

Cisco CCDE Study Blog: Network Virtualization Concepts

malcybood

Good day at work with a design meeting and resolving the issue with the managed service setup that I had describer. Amazing what tracking down a duplicate IP address on the LAN can resolve!

Anyway that aside, I'm pretty tired today after long days / nights and probably not getting enough sleep this week, so just a quick(ish) blog on BFD / IP FRR today.

Cisco CCDE Study Blog: Bidirectional Forwarding Detection (BFD) & IP Fast Reroute (IP FRR)

I'm going to recap on ISIS and OSPF deployment in large networks in my next 2 posts, folloed by a couple of days off to revise multicast, where a blog will duely follow some time next week hopefully, subject to workload and life!

Cheers!

ccnpninja

this is going to be interesting.
Good luck Malcybood!

malcybood

Thanks ccnpninja

So then a few days away, swamped at work and just got round to getting an ISIS blog together.

You only realise how much is included within these protocols when you have to write about or explain them.

Either way here is my latest effort to explain architectural design of ISIS in an SP or Enterprise network.

Cisco CCDE Study Blog: Integrated IS-IS Architectural Design Overview

I have not focussed too much on the detail here, more around a solid design with the key concepts always at the forefront of my mind:

- Ease of implementation
- Scalability
- Ease of integration (mergers)
- Fast Convergence from a topological perspective
- Routing aggregation
- Decommissioning of services
- Addition of services

I think this design would cover all of those areas give or take some tweaks.

Dieg0M

Hey Malcy,
First I would like to wish good luck in your journey, i'm sure it will be challenging. Just read quickly over your latest blog on ISIS architecture. In the last portion of it you are talking about benefits of ISIS over OSPF. I'm not sure I fully understand what you are trying to say.

"In OSPF the backbone must consist of an area 0 which all subsequent areas must transit to communicate between each other. Although this is good in respect to having a structured routing approach it can sometimes cause some challenges in respect to scalability in large networks, specifically if a network has grown organically through acquisition." Yes OK, but how is this different than ISIS? My understanding is that ISIS has to have a contiguous collection of L2 routers too.

"[FONT=Arial, Helvetica, sans-serif]ISIS can provide excellent flexibility provided the correct design approach is selected and is a good option for core networks, connected using ethernet / MPLS etc and there is no dependencies on point to multipoint, NBMA or virtual links." How can it provide more flexibility than OSPF? I would think that providing the option for P2M, NBMA networks or VLinks would offer more flexibility.[/FONT]

malcybood

Hi DiegoM,

Thanks for the feedback as it gets me thinking how to justify a certain design which is what the CCDE is all about!

I will attempt to address your points below.

I maybe didn't provide an adequate example or make the detail clear in relation to the rationale of the blog post due to trying to keep the size of the blog posts sensible!

Dieg0M wrote: »

Hey Malcy,
"In OSPF the backbone must consist of an area 0 which all subsequent areas must transit to communicate between each other. Although this is good in respect to having a structured routing approach it can sometimes cause some challenges in respect to scalability in large networks, specifically if a network has grown organically through acquisition." Yes OK, but how is this different than ISIS? My understanding is that ISIS has to have a contiguous collection of L2 routers too.

First of all there is a significant difference here between the protocols and how they operate, where OSPF provides hierarchy through different areas being deployed and all routers operating in an area other than area 0 which need to communicate must be connected to and must traverse the area 0 backbone.

In this scenario all routers in the core network must be connected to area 0 and OSPF operation is the equivalent to having a “flat” Level 2 ISIS network from an area perspective, with no additional areas being defined in the level 2 routing domain, but Level 1 areas could be different which is similar to multi-area OSPF.

If an OSPF design is not thought out properly it can cause issues when merging networks together either using redistribution (with the lack of NSSA) or conflicting areas being used in common POPs and even regions.

If it’s not possible to connect to the area 0 backbone then virtual links are required which over a large number of nodes is not really manageable even as a tactical method let alone strategic. In smaller networks virtual links would “do a job” but I’m not a fan.

ISIS on the other hand uses the concept of Levels in addition to areas. The core network must have contiguous Level 2 or 1 / 2 ISIS routers to provide the ability to communicate between level 1 and / or level 2 areas.

So in my example I mentioned that the edge of the core would be L1/2 routers operating at Level 2 for backbone links and level 1 to the various POPs.

This is fine in a small ISP or enterprise MAN or a national network with a smaller number of nodes.

What if we wanted to implement a global network across different continents?

We would probably make the links into the POPs level 2 in a different area for the continent and could then use level 1 routing in a region. This meaning that routing changes in a region do not have a knock on effect to the core.

The above also reiterates the flexibility of ISIS which brings us onto your next point……….

Dieg0M wrote: »

"[/FONT][FONT=Arial, Helvetica, sans-serif]ISIS can provide excellent flexibility provided the correct design approach is selected and is a good option for core networks, connected using ethernet / MPLS etc and there is no dependencies on point to multipoint, NBMA or virtual links." How can it provide more flexibility than OSPF? I would think that providing the option for P2M, NBMA networks or VLinks would offer more flexibility.[/FONT]

For certain requirements ISIS does provide better flexibility and ease of operation than OSPF……in my opinion and some of the reasons why are below.

As mentioned in the blog post many of the legacy technologies such as Frame Relay or ATM that drive NBMA or point to multipoint topologies and requirements, are not totally but in general being moved to Ethernet based services.

With the above in mind, if I was partaking in a core network design, the use of NBMA and P2MP would not necessarily drive the protocol decision unless the network predominantly used these technologies and there was no plan to change this.

Again, it comes back to size, scale and use case.

It is still possible to run ISIS (or OSPF) in a service provider or enterprise core network and have "pockets" of the network at key POP / interconnect locations to allow for legacy technologies and AToM type links.

IPV6 Integration
Another example of flexibility is where a global network requires IPV6 capability in the future to be added or enabled within the IGP.

In OSPF this is achieved by adding a second control plane and gives the administrators two routing protocols to manage independently of each other - OSPFv2 for IPV4 and OSPFv3 for IPV6.

With ISIS the addition of IPV6 is achieved with adding an "address family" within a single ISIS routing process / control plane and enabling interfaces for IPV6 ISIS. This is similar to the address family concept in BGP and EIGRP.

This is achieved with the use of an additional TLV in the ISIS header and I guess is the same approach that was used to allow the original layer 2 CLNS based ISIS to accommodate IPV4 with integrated ISIS and this approach is even being used in the data centre where technologies such as Fabricpath, OTV and LISP all use ISIS as their underlying technology with additional TLVs.

A large majority of the time ISIS would not be implemented as the main IGP in the enterprise mainly due to skill shortages but as mentioned above it appears to be making a comeback as the underlying technology to cutting edge protocols in the DC and WAN.

malcybood

Hey Guys,

Recap on OSPF architectural design this evening. I had whiteboarded this stuff from a Cisco Live video and had more detail in respect to protocol LSA timers to improve convergence but due to time constraints I'm planning on getting the concepts down in the blog and documenting the advanced features (which I have notes on just not the time) as a follow up.

Cisco CCDE Study Blog: Multi Area OSPF Architectural Overview

I was going to go back to multicast but I've spent a couple of days this week thinking about a multicast project for a customer to move their RPs from a VSS pair of 6500's which they are decommissioning to Nexus 7k's split across two DCs.

The use case for multicast on this particular network is for OTV which they're using for LAN extension between 3 sites.

I have attempt 2 at the CCDE Written booked for Monday and think I'm OK with the routing protocol side of things so one more post on BgP scalability this week and Saturday / Sunday will be focussing on tunnelling.

After I pass the written I will be doing much more stuff in the blog which is lower level and how it will impact the design as I will be sitting the 1st attempt at the practical on November 19th 2015, so I have a few months to work my way through the different scenarios, with a blog every other night.

d4nz1g

I feel like I am just a little kid after reading this lol

gorebrush

d4nz1g wrote: »

I feel like I am just a little kid after reading this lol

Even I have to agree with this and I've done a CCIE lab! I think the difference with the DE and IE R/S is the level of understanding is way different because at IE you are only implementing the solutions you are asked to.

Design - you need to know what you are implementing, and why because understanding why one is better than another is a whole different ball game!

Very impressed with this thread.

Dieg0M

malcybood wrote: »

Hi DiegoM,
ISIS on the other hand uses the concept of Levels in addition to areas. The core network must have contiguous Level 2 or 1 / 2 ISIS routers to provide the ability to communicate between level 1 and / or level 2 areas.


So in my example I mentioned that the edge of the core would be L1/2 routers operating at Level 2 for backbone links and level 1 to the various POPs.


This is fine in a small ISP or enterprise MAN or a national network with a smaller number of nodes.


What if we wanted to implement a global network across different continents?


We would probably make the links into the POPs level 2 in a different area for the continent and could then use level 1 routing in a region. This meaning that routing changes in a region do not have a knock on effect to the core.

IS-IS might use the concept of levels in addition to areas but they are totally different compared to OSPF. Areas in a L2 IS-IS domain are mostly used for administrative purposes and don't determine the SPF boundary. So in your example where you would have the core as L2 routers but in a different area than the continents that are also L2 routers, routing changes would trigger SPF recalculation the same way as if they were in the same area.


This said, I think IS-IS is more flexible in the sense that we can extend the L2 backbone easier than with OSPF because of the fact that the border between domains is considered at the link level rather than at the router level (a router is in 1 area but a link is in the L1-L2 domain).


Concerning the IPv6 integration... OSPFv3 supports both IPv4 and IPv6 with multiple-topologies where IS-IS does not support this by default and can create traffic blackholes in an overlapping IPv6/IPv4 design. With this said, I would consider IS-IS is less flexible than OSPF for an IPv6 implementation.


I also read your last article on OSPF but I found it incomplete and with mistakes. For example, NSSA does not block type 3 LSA's, OSPF dead intervals is 40s not 30s, Totally NSSA missing (this is important as it acts the closest to an ISIS L1 area since it receives a default route and can accept externals), Area type is not a requirement for forming adjacency in OSPF but rather DR/BDR capability and stub flag, also missing the subnet requirement (except for P2P).

malcybood

Hey gorebrush / d4nz1g, thanks for the comments. Hope the post and blog is informative and useful.

The primary objective is for me to transfer my notes somewhere other than a notepad but if it is of use to others even to generate design discussion that's a bonus.

malcybood

Hey DiegoM,

Thanks again, you got me thinking about justifying my answer

I also just want to confirm before I start this response, that I'm referring to a global MPLS that runs ISIS as the IGP for transit, used purely for next hop reachability where only the loopbacks on each node are advertised and no customer routes are known by ISIS.

I'm not referring to an ISIS enterprise network carrying customer routes and would also like to confirm I'm not ruling OSPF out as a feasible option for SP networks as that protocol is suitable up to a certain size of network i.e. a single regional or national network if you live somewhere small like Scotland like I do!

Dieg0M wrote: »

IS-IS might use the concept of levels in addition to areas but they are totally different compared to OSPF. Areas in a L2 IS-IS domain are mostly used for administrative purposes and don't determine the SPF boundary. So in your example where you would have the core as L2 routers but in a different area than the continents that are also L2 routers, routing changes would trigger SPF recalculation the same way as if they were in the same area.

Before I give my take on this, what benefits would you suggest using OSPF would provide us and why would you justify OSPF over ISIS for this type of network?

Technically you are correct from a protocol "out of the box" operation perspective where SPF is not limited in any way when using Level 2 routing between areas, but I don't entirely agree with your point when considering this type of network from a design perspective and tying all of the available protocols and features together in order to tune this type of network.

Please bare in mind there are several other protocols which would work in tandem with ISIS to provide a core MPLS network to improve convergence and ISIS would not carry customer routes, it would only be used for transit.

***Amended below from initial post***
I'm aware that the Level 2 area separation is more for administrative purposes and in large networks this would assist the NOC with troubleshooting.

***Amended below from initial post***
I personally would not recommend a single area Level 2 routing domain in a large SP core or Level 1 in the core, other than potentially at the POPs where PE's were located or close to the locations where the PE's were located! If level 1 was used here the boundary router in these POPs would also be configured as L1 / 2 to provide the flexibility to extend the core from that POP if required.

<Removed ISIS summary info due to being incorrect>

For each continent in my previous example you can tie summary routes into logical area boundaries using level 1 areas providing a summary route for multiple regions within a continent from a design perspective.

When using this type of design then the SPF calculation is suppressed in line with the hierarchical design of areas and summary points chosen by the network designer. Although I take your point around sub-optimal routing this applies to OSPF and ISIS summary routes in addition to BGP route reflectors. There are ways to optimise this such as advertising more specific / longer prefixes and so on and it is a trade off in hiding topology information to improve stability.

***Amended below from initial post***
Cisco advise that they have witnessed up to 400 routers in a single ISIS area which still provides what they regard as fast convergence.

As this scenario would be an MPLS network, MPLS, LDP, MPBGP and fast convergence techniques would be run with ISIS and would be responsible for customer routes being advertised within their respective VRFs and MPLS L3VPNs.

Looking at the case where an SPF algorithm is run, with good network planning and design in respect to having resilient paths and fast convergence in place I don't believe this is a problem for the following reasons.

By including protocols like BFD to detect a failure, IP-FRR, BGP PIC and addpath to ensure that whilst there is a convergence event happening such as SPF being run on the IGP and "microloops" are occurring, the traffic is detected using fast failure detection and routed around the failure using pre-computed backup paths until the IGP and if necessarry BGP have fully converged for the optimial path/s.

One final point here which may or may not be relevant depending on kit used, is that the routers typically used in core and aggregation layers of SP core networks are those such as ASR 9k which are capable of running as a single control plane using nv cluster.

So with this taken into consideration and depending on the network design, in order for a core network SPF convergence event to occur there would need to be multiple physical devices fail and if that did happen then having multiple ISIS level 2 areas PLUS summary routes advertised at logical Level 1 / 2 boundary points in the network, in addition to fast convergence and backup paths will improve stability and minimise network disruption.

Dieg0M wrote: »

This said, I think IS-IS is more flexible in the sense that we can extend the L2 backbone easier than with OSPF because of the fact that the border between domains is considered at the link level rather than at the router level (a router is in 1 area but a link is in the L1-L2 domain).

Agreed

***Amended below from initial post***
Something else that hasn't been mentioned in respect to flexibility is the ISIS metric is by default 10, but it can be changed based on network admin preference and the recommended starting point is 100000 to provide flexibility. This would also need to be planned out at the design phase.

In OSPF the reference bandwidth is used to calculate the best path which is configurable on each link, so when you upgrade backbone links, combine links to run etherchannels this has to be changed per link. Not a task I'd envy doing across a large network.

This is a reason why OSPF is not as flexible as ISIS in my opinion but going back to what I mentioned before OSPF is fine for enterprise or smaller MPLS / SP type deployments from this perspective.

Dieg0M wrote: »

Concerning the IPv6 integration... OSPFv3 supports both IPv4 and IPv6 with multiple-topologies where IS-IS does not support this by default and can create traffic blackholes in an overlapping IPv6/IPv4 design. With this said, I would consider IS-IS is less flexible than OSPF for an IPv6 implementation.

Point taken, but if a network has been in place for a number of years who is going to be running OSPFv3 for IPV4? Don't think I've ever come across a customer doing that.

Out of interest for my own understanding is there a way to convert an existing IPV4 OSPFv2 deployment to OSPFv3 without high risk of disruption? I'm not familiar with that technique to be honest or if there is a way of doing it.

If designing an SP from scratch then sure you could use OSPFv3 for IPV4 but in my opinion it still depends on the size of the network, whether OSPF or ISIS is the right fit.

Dieg0M wrote: »

I also read your last article on OSPF but I found it incomplete and with mistakes. For example, NSSA does not block type 3 LSA's, OSPF dead intervals is 40s not 30s,

My bad, this is just a mistake / typo so I'll fix these.

Dieg0M wrote: »

Totally NSSA missing (this is important as it acts the closest to an ISIS L1 area since it receives a default route and can accept externals), Area type is not a requirement for forming adjacency in OSPF but rather DR/BDR capability and stub flag, also missing the subnet requirement (except for P2P).

Although you are correct and without trying to sound too selfish, my objective with this post and the blog is to record my CCDE journey and due to life / work commitments I don't have time to document every feature of every protocol.

I'm writing most of the blogs at night between 10PM and 1am after a full day at work, 4 hour round trip commute to/from the office and juggling the family, so although it would help the blog readers to document every feature it's not always possible for me to cover everything, especially as I am only covering topics I feel I need to revise before I re-sit the written next week. Perhaps after that I'll have more time to spend on posts as I sit the practical on November 19th 2015.

The blog posts are also short hand of whiteboard sessions I've already completed since I started study in March this year (way before I started this thread or the blog). To give you an idea of my whiteboard sessions I've attached a couple of them for ISIS and OSPF - you will see totally NSSA on the OSPF one if you look closely .

So with the above in mind, I don't include everything from these in the blog, only the points I feel I need to vent about and some of the points I'm comfortable with I leave out.

Sheesh - tonight was meant to be scaling BGP but it's nearly 1am and I need to be in a customer DC in 8 hours, so will pick up on that tomorrow!

Hope that makes sense and thanks again for the feedback.

P.S. I had some incorrect information in this post initially and have amended accordingly where factual information was incorrect and highlighted in bold where amended. I have kept some sections of the post in as I believe they are valid design options / choices

malcybood

Just went back to correct any errors in the OSPF blog and I see what's happened. My notes were taken for this from multiple sources including the CCDE Quick Reference Guide which was written by Russ White and Mosaddac Turabi when I was doing final revision for my first written exam attempt and I've attached a screen shot from the OSPF neighbor section which shows the hello / dead being 10 and 30, but this is an error in the quick reference guide.

I guess everyone makes mistakes, even world renowned Network Architects! Anyway I've amended as per below:

Dieg0M wrote: »

For example, NSSA does not block type 3 LSA's

Amended

Dieg0M wrote: »

OSPF dead intervals is 40s not 30s

Amended but not a massive issue for me personally as I knew this and have just taken this down incorrectly when making my notes. Would have known it was 40s in an exam scenario but good that it was pointed out as I want my blogs to be as factually correct as possible, thanks.

Dieg0M wrote: »

Totally NSSA missing (this is important as it acts the closest to an ISIS L1 area since it receives a default route and can accept externals)

I'm leaving this out as I'm comfortable with this area type and need to move on from OSPF.

Dieg0M wrote: »

Area type is not a requirement for forming adjacency in OSPF but rather DR/BDR capability and stub flag

Sorry, your statement is partially incorrect, as the area ID does need to match as in a link where router A is in area 5 and router B is in area 6 - this wouldn't form a neighbor adjacency. The OSPF process doesn't need to match so I'm not sure if that's what you thought I meant.

Dieg0M wrote: »

also missing the subnet requirement (except for P2P).

I did know this but I have added it to the bullet list anyway.

Now onto my next blog post and I have cleared the whole of Saturday and Sunday to revise for the written exam next week so may be a few blogs over the weekend.

Dieg0M

malcybood wrote: »

You have mentioned that the SPF algorithm would be run due to the ISIS Level 2 area boundary not containing SPF convergence to an area, but this is not necessarily the case. In OSPF the ABR's purpose is to confine the SPF algorithm to run in a single area, but is also used as the point in the network segment to advertise summary routes.


Summary routes cannot be configured in an "all area 0" network, so this is restrictive in a large global core in my opinion. Being restricted in respect to summarization points and by where an ABR is positioned is slightly inflexible.

ISIS is not restricted to advertising summary ranges at area boundaries i.e. L1 / 2 boundaries like OSPF is with ABRs. This can be done anywhere on the ISIS network and when you combine this with being able to define multiple logical areas in an ISIS Level 2 domain. "

Where are you getting this from? I'm not a SP guy but i'm pretty sure ISIS is restricted to advertising summary ranges at L1/L2 boundaries the same as OSPF. IS-IS is a link-state protocol that runs SPF and every SPF domain requires that all routers have an identical view of the topology. The only protocols that allow flexible levels of aggregation are distance/path vectors like RIP/EIGRP/BGP.

malcybood wrote: »

Sorry, your statement is partially incorrect, as the area ID does need to match as in a link where router A is in area 5 and router B is in area 6 - this wouldn't form a neighbor adjacency. The OSPF process doesn't need to match so I'm not sure if that's what you thought I meant.

I said Area type, not Area ID.

Good luck on your exam.

malcybood

Dieg0M wrote: »

Where are you getting this from? I'm not a SP guy but i'm pretty sure ISIS is restricted to advertising summary ranges at L1/L2 boundaries the same as OSPF. IS-IS is a link-state protocol that runs SPF and every SPF domain requires that all routers have an identical view of the topology. The only protocols that allow flexible levels of aggregation are distance/path vectors like RIP/EIGRP/BGP.

I have to hold my hands up here and am cringing a bit at my ISIS onslaught a few posts up.

You are correct and I apologise for my rant. I had misinterpreted something I had read around summary routes in ISIS where you can advertise them as "level 1 only", "level 2 only" or "level 1-2" and jumped the gun, where this is actually done on boundary routers and allows the ability to advertise is a specific direction, towards either the core or the edge!

I'll amend the post with "wrong info provided" removing the baloney

Dieg0M wrote: »

I said Area type, not Area ID.

Fair enough you did, but I mentioned Area Type in my initial blog post as being a dependency in the second bullet point.

The positive here is I was challenged, some discussion was generated, I got it wrong and I stand corrected for future.

Next post is OTV Tunnelling for Layer 2 LAN extension

malcybood

Hey folks,

Had a few days away as I spent 8 hours on saturday and 8 on sunday revising various subjects prior to the written exam on Monday.

The OTV post I mentioned is sitting in draft and I will get to it over the next few days.

Now the written is complete I am treating the practical prep as back to square 1 in respect to learning and reading about the technologies.

I need to focus more on the "why" and "where" to deploy each technology which is why I invested in the whiteboard for the house! Hopefully be able to tie this into my work as my day to day role is design feom a high and low level.

Guess it will depend slightly on what type of projects we win but working on a couple of consultancy audits and also a merger for customers (aside from the day to day presales stuff) at the moment so that will help with the "merge / divest" objectives.

Will get a blog about my written exam prep and the OTV blog finished this week.

Cheers

malcybood

Well what a crazy few weeks. Never did get to finishing the OTV post but will get there at some point!

I have been working on the following over the last few weeks at work:

- re-design / architecture of a customer firewall deployment, which has included peering to Amazon Web Services, using BGP for route advertisement over IPSec. Working on some issues with a legacy design, related to multi-homing and some restrictions imposed by AWS around advertisement of routes and some quirks that were implemented as a workaround by the customer but are not scalable going forward and they had requested we review it.
- Completed a network audit for a new managed service LAN customer.
- DMVPN design for a small wires only MPLS WAN for 7 routers across 4 sites.
- Design of a wireless solution for a customer using workgroup bridge and meshed wireless. Interesting solution to allow cranes on a site to continuously have connectivity to the wired network using wireless bridging, whilst moving about a site. We used Cisco Meraki APs in mesh mode, but also investigated a native Cisco solution using outdoor APs in workgroup bridge mode.
- Started working on a new core network design for a customer who currently runs OSPF over point to point links between 3 data centres, where OTV is run over the top. The design is to optimize the core routing configuration and some of the technologies I'm discussing to implement this are VDC's on the Nexus 7k's to implement a dedicated core "router" and separate the core out from the DC aggregation, OTV, PIM Multicast RP needs to be moved from a legacy 6500 pair to Nexus using MSDP / Anycast and the OSPF design would consist of optimised summary addressing, BFD implementation, IP event dampening for route flaps etc but that has not yet been finalised. In the pipeline for the next month or two, which ties in well with some of my study.

None of the above is really heavy CCDE related design other than the last project if I'm being honest, but it keeps the mind ticking over in the designer / architect mindset as there was / are several business requirements and constraints I had to work through from an acrchitectural design perspective, specifically on the Amazon Web Services side of things.

This weekend I intend to sit the first of the Jeremy Filliben practical exams, so the last week or so I've been revising QoS and tunnelling technologies as the first case study is focussed around these topics.

To expand on that a little the QoS revision has consisted mainly around the 4, 8 and 12 class models and how to map enterprise QoS / CoS at layer 2 & 3 into a SP QoS model.

Also covered the PE DSCP markings conversion into the P node MPLS EXP field / marking for QoS to be honoured end to end across the the MPLS core network.

In general terms how QoS is affected when using tunnelling techniques such as L2VPN, L3VPN, MPLS, GRE, IPSec, DMVPN, GET VPN and IPSec.

Where and when to use pre-classify......

In regard to actual tunnel operation I have put significant focus on phase 3 DMVPN and it's operation in respect to dual hubs and having the ability to create hierarchical DMVPNs with an aggregation layer of hub routers, in addition to mixing spoke-hub-spoke and spoke-spoke communication to meet different requirements in retail environments.

Finally I watched a Cisco Live video on running MPLS over multipoint GRE / DMVPN and noted the differences in respect to how MPLS labelling works and the affect that LDP not running for this solution has on traffic flows.

The benefits are that deployment of multiple VRFs over the tunnel interface is simplified, but because LDP is not run.

Tunnel protection is the technique used in DMVPN to provide an IPSec type encryption to the mGRE tunnel and simplifies the configuration process in comparison to traditional IPSec.

This morning before work I done an hour's reading through chapter 3 case study of Definitive MPLS Designs, but I've not finished it yet.

Finally, I watched BRKMPL-2101 last week from Cisco Live and took several notes on the following:

- VPLS
- VPWS Point to Point
- EVPN (MAC routing using BGP)
- PBB-VPN

That was the second time I had watched this session and it's heavy stuff, although really interesting and I've got a load of notes / downloaded the slides to look over again before the weekend.

malcybood

Wow, 18th August since my last post - shameful!

I have just not had time to post here let alone update my blog, but I have not been any less focussed on study. I have been keeping a note on (some of) the video sessions that I've watched on Cisco Live since 30th August which includes the following:

BRKRST-2045 - 28th August
BRKRST-2101 - 29th August
BRKMPL-1101 (MPLS) - 30th August
BRKSPG-2102 (MPLS) - 30th August
BRKRST-3051 (Core Network: Minimizing Packet Loss) - 1st September
BRKRST-3363 (Routed Fast Convergence) - 5th September
BRKDCT-3103 (OTV Troubleshooting) - 15th September (This was for a project at work but relevant to DCI section of CCDE)
BRKMPL-1261 (Multicast) - 20th September
BRKIPM-3017 (Advanced mVPN) - 28th September
BRKRST-2337 (Troubleshooting OSPF) - 29th September
BRKRST-2327 (Troubleshooting ISIS) - 3rd October
BRKRST-3321 (Scaling BGP) - 4th October
BRKRST-3320 (Troubleshooting BGP) - 4th October

These are only the sessions I remembered to record after / during watching them and I have watched many more sessions (some several times) throughout my study which began in April 2015, but I didn't keep a list of them - just added them to my interests in Cisco Live, where I have 51 sessions in there.

Also been floating in and out of books on my Safari account to supplement and The Art of Network Architecture which I have a hard copy of.

I am now awaiting the CCDE Practical Study Guide book being released on 9th October (been delayed) which I will use as the main book, before heading out to Orlando for Jeremy Filliben's CCDE bootcamp on 19th - 24th October.

On the work front I have been completing all the usual presales / architectural design stuff with an interesting security project, getting hands on with OTV for a specific application issue and developing a new offering for our managed service so quite busy at the moment.

I'm hoping the above and study for the next 6 weeks or so prepares me well for my first attempt at the practical in London on 19th November!

If I'm quiet between now and then, the above is why!

powmia

Good luck man. Keep going hard.

Simrid

Keep going man, I hope to one day be on this journey too!

malcybood

Hi folks, thanks for the best wishes.

I've been quiet here but by no means has my study slowed down.

Since my last update I have been to Orlando for Jeremy Filliben's CCDE bootcamp, which was excellent. Long days of 8am - 6pm then 2 hours homework each night and covered all technologies that I've already focussed on since I started my studies and more.

I got home to the UK on 26th October and had a week or so of downtime to spend with my family after being in the States, then the last week I've been back to it. Working all day and studying / whiteboarding every night.

The last week I have paid particular attention to topics including MPLS Traffic Engineering, RTBH + uRPF and QoS design - specifically mapping 4 layer into 8 and 12 layer models.

I have to say I feel comfortable with the technologies contained in the exam but the CCDE is so much more than "what is technology X".

10 days to go until my first attempt and I have study leave from Weds this week until Tues next week where I set off for London the day before.

8 months of prep including 6 mock exams on Jeremy's bootcamp but I still think you can't know what to expect on this exam until you've actually experienced it.

I'll just have to go for it and see what happens but as things stand I don't feel I can do any more than what I'm already doing to prepare so I think it will be about keeping cool under pressure, reading all of the documentation properly and being configent in my design selections.

I may or may not get a chance to post again before I sit the exam but if not I'll update how I get on after.

Cheers

malcybood

I also meant to mention that I have now received the CCDE study Guide from Cisco Press.

The book arrived whilst I was in the US so I didn't even get a chance to open it until this week after being so busy catching up at work when I got home but I have begun to start picking out select chapters.

With 10 days until the exam I won't get a chance to finish it before unless I dedicated myself to it and there are other resources that I have been working from and know in preparation for my first attempt at the practical so I will use it to cross reference and solidify certain topics from a different perspective where relevant.

I will say that the book appears to be pretty good with lots of technology comparison tables which I understand being a key study tool when selecting technology so if I need another attempt at the exam I will give this book some real focus. Just a couple of months too late being released for me to use as a core resource on this attempt, but looks good!

malcybood

Between Thursday last week and today I have managed to read the CCDE Study Guide in full, which I didn't think I would have time to do.

I admit some of it was skim / speed reading but not so much that I wasn't taking it in. I believe that I've managed to complete it because of the following reasons:

1. I've already drilled around 90% of the topics within the book for around 7-8 months via other resources.
2. It's well written with alot of diagrams included so the 570 odd pages were not as daunting. Typically diagrams on every other page to backup the text.

There is a fair amount of overlap throughout the book concentrating on virtual networking (VRFs, MPLS etc), network convergence, resilience and seamless failover i.e. BFD, MPLS-TE, LFA etc but that is absolutely a good thing as those are the key concepts.

The book does not teach technologies from the ground up and I personally think that it would be difficult to read if you were learning the technologies from scratch, but if you have experience or theoretical knowledge of the topics it's quite an easy and pleasant read.

I will be sitting the practical exam for the first time on Thursday this week in London, so it's difficult to say what areas to focus on within the book but based on what I read and my study to date, I'd say that chapters 5 - 7 on Service Provider technology is pretty key along with Chapter 9 (fast convergence) and chapter 3 as this talks a bit about the main IGPs. Also chapter 10 has some good information on QoS although there is a typo in the diagram relating to QoS Pipe and Short Pipe mode about the marking being honoured end-to-end - the text that supports the diagram is correct however.

In respect to these chapters being key I am of course guessing as I've not had an attempt yet, but I would advise that if preparing for the exam do some reading of other resources to learn the technology then read this book to cross reference / final preparation!

I now feel like I've done more or less all I can do preparation wise for my first attempt which I have listed below, since April / May 2015 and the next couple of days will be revising a few topics (7 or I feel I can brush up on.

Study to date since April / May 2015:

- Thought about several network designs and projects over my career and how I could have designed or deployed in another way.
- Watched approximately 60 Cisco Live videos (1.5 - 2 hours watched most more than once)
- Read several MPLS Design books specifically from Cisco Press from reading list.
- Read relevant sections of end to end QoS Network Design
- CCDE Quick Reference by Russ White (written prep)
- 40 whiteboard sessions on various technologies within the blueprint whilst studying
- Written a few blog posts (6 or 7)
- Attended Jeremy Filliben 5 day CCDE Practical bootcamp in October 2015
- Completed 6 x 2 hour practice exams from Jeremy's course
- Reviewed the approx 320 slides from Jeremy's course (hard copy)
- Read CCDE Study Guide, by Marwan Al-shawi
- Revised implementation steps for L3VPN, L2VPN, Multicast, Adding a QoS class of service, migration to an encryption overlay, add MPLS-TE to an existing MPLS network.

The implementation plan practice at the end is something that I'm unsure how much value it will add in the exam as it won't be straight forward "implement this or that technology". there will be factors to consider to ensure you don't knock service out so the impact of the order for implementation needs to be considered.

I'm working on the basis that if I know the standard implementation of the technology I should hopefully be able to think about how to deviate to accommodate the requirements and deliver the implementation plan to meet the solution.

In addition to all that I've tried to think of ways that I could apply the technologies in the blieprint to real customers that I work with to improve their networks where appropriate.

In regards to exam strategy I intend to walk into the exam as if I'm going to work for the day in London and will try not to get too worked up about it being an exam. I do not intent to take screeds of notes or overuse the highlighter. I have also been advised that there is more than adequate time for this exam by several people including from the Cisco Live CCDE session, which is rare in most Cisco exams so I will be making sure I take the time to read the documents carefully and the first thing I will do in each scenario is to "understand the network and what is going on".

I'm hoping that mental fatigue will not be an issue as I've been going to work all day then studying most evenings and weekends for 8 months now, so that shouldn't be an issue as long as I don't get stressed at any point.

Whether I pass the exam on Thursday or not, this has been a really intense but enjoyable journey to date and if I'm sure of anything, it's that I have obtained a plethora of additional technical knowledge and definitely believe I'm a better network designer as a result of it.

malcybood

I was gutted to fail CCDE practical at first attempt, but I can finally talk about it and wrote a blog with my musings, for anyone that is interested.

Cisco CCDE Study Blog: CCDE Practical Attempt 1 Hangover & Battle Scars

Study stopped for a few weeks after the Nov 2015 exam, where I then resumed with some additional study resources and got back on the horse!

Hoping to attempt again and pass in 2016.

Shedd

Hi malcybood. I'm working on my ccde too.
Have you attenden in any ccde trainings like ERGUN, JEREMY OR ine ? Im asking beause want to compare real exam with training scenarious. Which is more closed?