Which first? ROUTE, QoS, or BGP + MPLS?

Should I take the ROUTE test first, or the composite BGP/MPLS test first (the QoS will be last)? Or does it matter? Is there a preferred sequence?

Find more posts tagged with

Comments

networker050184

I'd do ROUTE before BGP/MPLS and QoS doesn't much matter really.

down77

+1. You'll need to understand ROUTE before BGP/MPLS. It helps to have a background in ROUTE before QoS but this can be done either before or after the other exams as long as you can grasp the foundations.

spiderjericho

Yeah, it wouldn't make much sense to go about getting the cert in a haphazard manner. Do the fundamental course then do the supplemental courses afterward.

Cat5

How was the ROUTE test? Easy, difficult, or somewhere in-between? I think I also saw that the ROUTE book is one of the thicker ones - especially compared to the SWITCH book.

vinbuck

ROUTE was the hardest Cisco exam I have ever taken. I work for an ISP and get to do iBGP, OSPF and MPLS on a daily basis and rarely touch a router smaller than a 7600 series chassis and it was still incredibly difficult. The upside is that i've become a much better network engineer since I've taken ROUTE. I can't imagine being able to grasp the concepts of BGP and MPLS without understanding the IGPs that they run on top of. It took me 11 months to study and pass it on the first try. I put in comparable lab and reading hours to most of the CCIE candidates on the board for the ROUTE exam.

Lab, Lab and then Lab some more and you will pass ROUTE

Check out the materials in here to get started. especially the free LAB Manuals from Cisco Academy....well worth it.

http://www.techexams.net/forums/ccnp/71743-free-study-materials.html

Cat5

I was unpleasantly surprised that although the ROUTE book came out almost two years ago, the "used" copies on Amazon are still almost identical to the "new" prices. I guess few people get rid of them once they buy them.

Cat5

vinbuck wrote: »

ROUTE was the hardest Cisco exam I have ever taken. I work for an ISP and get to do iBGP, OSPF and MPLS on a daily basis

I'm curious since you're an engineer for an ISP, what you do on a daily basis for them? I'm going to be Tier II support for an ISP, with the engineers above me, and I'd like to know what to gear up for if I want to move up.

Also, in what capacity do you do OSPF, since it's basically a LAN protocol?

Thanks!

vinbuck

Cat5 wrote: »

I'm curious since you're an engineer for an ISP, what you do on a daily basis for them? I'm going to be Tier II support for an ISP, with the engineers above me, and I'd like to know what to gear up for if I want to move up.

Also, in what capacity do you do OSPF, since it's basically a LAN protocol?

Thanks!

Well I work for an ILEC aka Telephone company, so I help plan, design and maintain the core network as well as the access technologies like DSL, FTTH, Wireless, etc. With a larger company like ATT or Comcast, you proably be much more focused on resolving tickets. When you work for a smaller provider, you get your hands in everything and thus get a more broad exposure but the trade off is that you might become an expert in a few select areas if you go with a bigger organization - just depends on what you're after.

As far as OPSF, calling it a LAN protocol isn't really a fair characterization, so i'm guessing you meant that it is commonly used in the enterprise on private networks. However, SPs worldwide rely on OSPF to run iBGP within their ASes. OSPF (IGP is a better way to classify it than LAN) is the foundation for iBGP...you aren't required to use it but your only other options are to use EIGRP (proprietary) or static routes. Service providers usually have to integrate a vast array of manufacturers, so proprietary stuff is usually frowned on unless there is a very strong justification for doing so. This leaves OSPF as the IGP needed to run iBGP/MPLS networks which is why the CCIP requires ROUTE, because to understand how to implement iBGP/MPLS, you first have to understand the IGPs that iBGP needs in order to function.

Cat5

vinbuck wrote: »

Well I work for an ILEC aka Telephone company, so I help plan, design and maintain the core network as well as the access technologies like DSL, FTTH, Wireless, etc. With a larger company like ATT or Comcast, you proably be much more focused on resolving tickets. When you work for a smaller provider, you get your hands in everything and thus get a more broad exposure but the trade off is that you might become an expert in a few select areas if you go with a bigger organization - just depends on what you're after.

As far as OPSF, calling it a LAN protocol isn't really a fair characterization, so i'm guessing you meant that it is commonly used in the enterprise on private networks. However, SPs worldwide rely on OSPF to run iBGP within their ASes. OSPF (IGP is a better way to classify it than LAN) is the foundation for iBGP...you aren't required to use it but your only other options are to use EIGRP (proprietary) or static routes. Service providers usually have to integrate a vast array of manufacturers, so proprietary stuff is usually frowned on unless there is a very strong justification for doing so. This leaves OSPF as the IGP needed to run iBGP/MPLS networks which is why the CCIP requires ROUTE, because to understand how to implement iBGP/MPLS, you first have to understand the IGPs that iBGP needs in order to function.

Very interesting. Thanks for the input.

cisco_trooper

Cat5 wrote: »

How was the ROUTE test? Easy, difficult, or somewhere in-between? I think I also saw that the ROUTE book is one of the thicker ones - especially compared to the SWITCH book.

I haven't taken the ROUTE exam, but I did take its predecessor, the BSCI. This exam would have been difficult, if not impossible, to pass using only CCNP level materials. I used a variety of materials to pass the exam, but the single most valuable resource I found was Routing TCP/IP Volumes I and II. I did well on the exam, but I also prepared for the exam at a level beyond what I expected. It is a good thing otherwise I would have failed.