Preparation Tips for the JNCIP-M/T and JNCIE-M/T Exams
Written by Stefan Fouant
So it's been a while since I've posted, and I'm just now getting to a point where I can start writing a bit more, not to mention feeling quite a bit more well rested after a grueling month of December. I was quite busy during the last month as I was doing last minute preparations for my JNCIE-M/T exam scheduled for Dec. 17th, not to mention trying to wrap up several projects before years end. I'm delighted to say that I passed the exam and am now the proud recipient of the highly sought-after JNCIE-M/T designation! I'd like to take a few moments to share about my experiences with the rest of you who may also decide to pursue this certification.
Before I delve into the specifics of the JNCIP-M/T and JNCIE-M/T preparations, let me suggest that anyone who is interested in pursuing this track start out with the JNCIA-M/T certification, prior to moving to the JNCIS-M/T. While it is possible to skip directly to the JNCIS-M/T certification, there is so much useful information available in the 'JNCIA Study Guide' that I strongly believe it should be at the top of the list for those who are just starting out with JUNOS.
As for JNCIP-M/T, I prepared entirely using the 'JNCIP Study Guide' by Harry Reynolds. Although this book is long out of print, the Study Guide is available as a free download from Juniper's website, as are the rest of the Study Guides for the Service Provider track. For actual hands-on, I used a testbed comprised entirely of Juniper Olives running in VMware. Yes, it is possible to use an Olive lab exclusively in order to do EVERYTHING needed to prepare for this exam. As this exam is mostly focused on BGP and IGPs there is nothing which actually requires a hardware based PFE or dedicated ASICs, as such an Olive is perfectly acceptable for test preparation.
If you decide to pursue this route and do preparations exclusively in this manner, there are a few things to keep in mind. I've found that the initial install of JUNOS requires quite a bit more memory than it does once its finally completed. I was able to successfully run a VM Olive running JUNOS 8.1 (at the time of this writing JUNOS 8.1 was the version being used in the exam) with as little as 48 MB of memory, however CLI response time was incredibly slow. I've found the sweet spot to be right at around 96MB of RAM for each Olive VM image.
In order to follow through the examples in the JNCIP Study Guide, you're going to want to have at least 8 Olive VMs running simultaneously (7 for the actual routers comprising the student's testbed and another Olive to simulate the EBGP peers using Virtual Routers). Make sure you have at least 768 MB of available memory you can allocate to your VMs. Depending on what version of VMware you are running, you might need to tweak the vmnet interfaces so that each Olive has enough fxp0s, and you might also need to stitch them together logically within the VMware configuration files. Be prepared to get under the hood of VMware configuration in order to get all this working correctly. Perhaps a better option would be to configure an ESX or ESXi Server and run your images off a high-powered server, where you have loads of memory and virtual switching capabilities. Another option is to utilize a single hardware-based chassis, such as the MX240 and segment this using Logical Routers (see below for details on this configuration).
Preparing for the JNCIE-M/T exam is a bit more difficult, as it requires actual hardware to perform many of the tasks required of this exam. Many of the tasks like setting up Multicast or Layer 2 VPN srequire dedicated hardware within the PFE, so using Olives is not an option. Never fear, it is entirely possible to prepare for this exam using as little as a single MX240 coupled with Logical Routers (Logical Systems in JUNOS 9.3 and above). You will need a total of ~40 connections to set this lab up so get your hands on a high density 40x1GE card and a bunch of fiber and you should be ready to go. Make sure the card you use is capable of Layer 3 services, as cards capable of running only Layer 2 services will fall short of many of the configuration tasks. If you're short on SFPs or just don't have enough physical ports, it's also possible to use logical tunnels to stitch your logical routers together, as in the following example:
logical-systems {
dc {
interfaces {
lt-0/0/10 {
unit 0 {
description dc->r7;
encapsulation ethernet;
peer-unit 1;
family inet {
address 10.0.8.13/30;
}
family iso;
}
}
}
}
r7 {
interfaces {
lt-0/0/10 {
unit 1 {
description r7->dc;
encapsulation ethernet;
peer-unit 0;
family inet {
address 10.0.8.14/30;
}
family iso;
}
}
}
}
chassis {
fpc 0 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
network-services ip;
}
The last bit is required in order to make sure you allocate a fixed amount of bandwidth on the PFE for the logical tunnels. The coolest thing about the logical tunnels feature within JUNOS is that you can actually configure them with Ethernet, Frame Relay, or a host of other encapsulation types. Logical tunnel interfaces behave just like regular interfaces and it's entirely possible to configure things like IS-IS across them, as can be seen in the above example where 'family iso' has been enabled.
Navigating the CLI is a bit unwieldy using Logical Routers if you're working from the root of the physical device, so its highly advisable to configure individual user accounts for each logical router. This will enable you to log in to each logical router and be positioned within the root of that logical router as if you were in the root of a real physical router. This can be accomplished with the following configuration:
system {
class dc {
idle-timeout 0;
logical-system dc;
permissions all;
class r7 {
idle-timeout 0;
logical-system r7;
permissions all;
}
user dc {
uid 2014;
class dc;
authentication {
encrypted-password "xxxxxxxxxxxxxxxxxxx"; ## SECRET-DATA
}
}
user r7 {
uid 2010;
class r7;
authentication {
encrypted-password "xxxxxxxxxxxxxxxxxxx"; ## SECRET-DATA
}
}
}
}
In addition to the above lab setup, I used the 'JNCIE Study Guide' from Harry Reynolds. While this is an excellent book in preparation for the exam, my advice is to make sure you also read through the 'MPLS Applications', 'Multicast', and 'VPN' Configuration Guides, and be familiar with as many knobs and configuration options as possible. You are also going to want to make sure you understand IS-IS and OSPF as well as BGP in an even deeper fashion than that required in the JNCIP-M/T exam.
As a word of note, in preparing for both the JNCIP-M/T and the JNCIE-M/T exams, make sure you have a good handle on how to use 'load merge terminal relative', 'load patch terminal', and when to copy and paste portions of code simply using 'show | display set'. It's equally important to know which one of the above commands to use in a given situation. For example, when copying changes to several stanzas from one router to another, it's often quite a bit easier to use the 'load patch' command as you won't have to copy snippets from portions of different stanzas into a notepad prior to loading into the target router. Little things like this can save quite a bit of time and will come in handy when your time would be better served trying to focus on troubleshooting why your IGP isn't coming up.
Finally, I should mention that I also utilized the services of Proteus Networks which offers remote-proctored JNCIP-M/T, JNCIE-M/T and JNCIE-ER practice exams on their lab gear. For $800, their package consists of two 8 hour labs comprising a wide variety of topics you are likely to see on the exam. When you are finished with each, they will grade it and give you feedback on how well you performed. What I liked about Proteus is that they even let me play around with the gear after my exam was graded, and allowed me to go and fix some of my mistakes. In addition, they were highly responsive to my emails, and answered all of my questions in a timely manner. Looking back, I don't think I would have been able to pass the JNCIE-M/T exam without the use of their services as there were several subject areas identified throughout their exam which required additional focus. In my opinion, their remote-proctored exams are a genuine bargain for the price and anyone who is preparing for the JNCIE exams should seriously investigate their offerings.
All in all, the total study time for JNCIP-M/T was approximately 2 months, and the total study time for JNCIE-M/T was approximately 3 months. This usually comprised about an hour or two each day during the week reading, and anywhere from 10-16 hours of lab time on the weekends. I'm lucky in that I have also worked in a Service Provider environment for several years where I was able to intimately familiarize myself with many of these technologies over a span of many years. In addition, I have spent a considerable amount of time reading a plethora of books on a wide variety of networking technologies. If you are new to MPLS, Multicast, Layer 2/3 VPNs, QoS, or IPv6, you may want to factor in additional time into your study schedule. The trick here is to be consistent and develop a schedule which you can live with - you will be infinitely better served by spending a few hours a day over a span of several months rather than hundreds of hours the few weeks before your exam. Slow and steady wins the race here... you'll be surprised at how quick a few months can go by when you're motivated and committed to something!
I hope this helps those of you who are pursuing either the JNCIP-M/T or the JNCIE-M/T certifications, and I wish you the best of luck in your endeavors!
Implementing Provider-Provisioned VPNs using Route Reflectors
Written by Stefan Fouant
MPLS/BGP Provider-Provisioned VPNs, such as those proposed in RFC 4364 (formerly RFC 2547) or draft-kompella variants, suffer from some scalability issues due to the fact that all PE routers are required to have a full iBGP mesh in order to exchange VPN-IPv4 NLRI and associated VPN label information. In a modern network consisting of a large number of PE devices, it becomes readily apparent that this requirement can quickly become unmanageable.
The formula to compute the number of sessions for an iBGP full mesh is n * (n-1)/2. 10 PE devices would only require a total of 45 iBGP sessions (10 * (9)/2 = 45). However, by simply adding 5 additional PEs into this environment your total number of sessions increases exponentially to 105. Scalability issues arise because maintaining this number of iBGP sessions on each PE is an operational nightmare; similarly control plane resources are quickly exhausted.
An alternative to this that has gained widespread adoption is to utilize Route Reflectors to reflect the VPN-IPv4 NLRI and associated VPN label between PE devices. However, several issues arise when using Route Reflectors in such an environment. In a normal environment without the use of Route Reflectors, MPLS tunnels exist between each PE router such that when the VPN-IPv4 NLRI and associated VPN label are received, a PE router can recurse through its routing table to find the underlying MPLS tunnel used to reach the remote BGP next-hop within the VPN-IPv4 NLRI. In the Route Reflection model, the Route Reflector typically doesn't have an MPLS tunnel to each PE for which it is receiving VPN-IPv4 NLRI. Therefore, these routes never become active and are therefore not candidates for reflection back to other client and non-client peers.
A few methods have been developed which circumvent this issue. One method is to simply define MPLS tunnels from the Route Reflector to each PE. This solves the problem by allowing the Route Reflector to find a recursive match (i.e. MPLS tunnel) in order to reach the remote PE. However, this approach suffers from the drawback in that it requires a whole bunch of MPLS tunnels to be configured which only serve to allow the received VPN-IPv4 NLRI to be considered active. Remember, these tunnels are completely useless in that they will never be used for the actual forwarding of data, they are only used within the control plane to instantiate routes.
An alternative and much more graceful solution to this problem is to configure the Route Reflector with a static discard route within the routing table which is used to reference BGP next-hops in MPLS environments (inet.3 for example in JUNOS). This static discard route only serves to function as a recursive match when incoming VPN-IPv4 NLRI are received for the express purpose of making these routes active and therefore candidates for redistribution. In JUNOS, one can accomplish this using the following configuration:
routing-options {
rib inet.3 {
static {
route 0.0.0.0/0 discard;
}
}
}
With the above, any VPN-IPv4 NLRI received from a PE router is immediately made active due to the fact that a static route has been created in inet.3 which is the routing table used in JUNOS to recurse for BGP next-hops in MPLS environments.
An excellent whitepaper entitled "BGP Route Reflection in Layer 3 VPN Networks" expands upon this and describes the benefits of using Route Reflection in such environments. It also builds the case for using a distributed Route Reflection design to further enhance scalability and redundancy.
One thing to keep in mind is that with the Route Reflector approach, we have merely moved the problem set from that of the PE device to that of the Route Reflector. Although it minimizes the number of iBGP sessions required on PE devices, the Route Reflector must be capable of supporting a large number of iBGP sessions and in addition, must be able to store all of the VPN-IPv4 NLRI for all of the VPNs for which it is servicing. It is highly recommended that adequate amounts of memory are in place on the Route Reflector in order to store this large amount of routing information.
Finally, while using Route Reflectors is an acceptable solution in the interim to addressing scaling concerns with Provider-Provisioned VPNs, it is not clear if this approach is sufficient for the long term. There are several other options being examined, with some of them outlined in a presentation entitled "2547 L3VPN Control Plane Scaling" given at APRICOT in Kyoto, Japan in 2005.
Book Review :: IS-IS: Deployment in IP Networks
Written by Stefan Fouant
IS-IS: Deployment in IP Networks
by Russ White, Alvaro Retana
Hardcover: 320 pages
Publisher: Pearson Education
ISBN-13: 978-0201657722
Better off choosing an alternative selection
As IS-IS is one of the more esoteric protocols, understood only by a few people in large scale ISP environments, I thought this book would be a welcome addition to my library as there isn't much else on the market covering this protocol. There are of course ISO 10589 and RFC 1195 which covers these protocols, but seeing as this is a short book I thought it might be able to shed some light on an otherwise complex protocol.
In reviewing this book I've come up disappointed in general. There are certainly a few golden nuggets and I give the book a couple of stars just for attempting to bridge the gap between the purely theoretical and the purely vendor specific. However, the book comes up short on most other points. Often times I found myself wanting to scrap this book in favor of some of the other selections on the market, but since I have respect for these authors I read the whole book hoping that they might be able to redeem themselves by the time I finished.
Obviously the authors have a great deal of knowledge about the subject, and I don't fault them entirely. The quality of the editing is poor with many grammatical and syntactical errors littered throughout the text. There are abundant instances throughout the book where the diagrams used do not match the text describing them. I was rather disappointed because I usually find that Addison-Wesley publishes some of the best texts on the market.
All in all, I thought this book could have been a lot better than it was. After all, these authors have several other titles under their belt, most notably "Advanced IP Network Design". But in this case, I would say that you are better off looking for other similar titles available on the market, such as Jeff Doyle's "Routing TCP/IP Volume 1" or "The Complete IS-IS Routing Protocol" by Hannes Gredler and Walter Goralski.
The Case for Juniper Press
Written by Stefan Fouant
When was the last time you went into a bookstore and found a book on the bookshelf covering Juniper technologies? I've managed to rarely, if ever, find more than one or two titles on JUNOS or any sort of Juniper related technology. On the other hand, you'd be hard pressed to miss the bevy of Cisco related titles covering a vast array of technologies and platforms. When I teach Juniper classes, or I'm on a consulting gig pitching Juniper technologies, one of the things I hear most often is that there aren't enough resources available to people who want to learn more about JUNOS. Often the answer is "Well, there's the Fast Track Program", or "Well, you can download the free books by Joe Soricelli or Harry Reynolds" (which by the way, it's high time we get those books back in print - they are excellent books, well written, and in my opinion, second to none when preparing for the Service Provider track). But often this isn't enough for the folks who want to learn more. While Juniper's Fast Track Program is an extremely valuable resource, it's coverage is limited to only a few select technologies. Furthermore, beyond a handful of books on Amazon, there aren't many additional resources outside of reading Juniper's technical documentation or various white papers for those students who truly wish to expand their knowledge base. Sure, the JNCIA-M/T, JNCIS-M/T, JNCIP-M/T, and JNCIE-M/T study guides are freely available, but more often than not people would prefer to have these in hardcopy format rather than in a PDF and printing a PDF doesn't provide the reader with quite the same experience. I don't care what anyone thinks, electronic formats aren't going to be replacing printed books anytime soon. Just ask yourself when was the last time you read an entire book on a computer screen? NOTE TO AUTHORS: A Kindle version would be nice and this would be a good first step, but then again, how many people do you know that actually own a Kindle?
In 1996, when Cisco Press was formed as a joint publishing partnership with Pearson Education, Cisco realized that providing educational materials to meet the growing demand for networking technologies was going to be a cornerstone to their success. In 1997, "Internet Routing Architectures" by Sam Halabi rolled off the printing press and was an instant best seller. The rest was pretty much history. Cisco understood early on that there was a vacuum in the market for high-quality technical books covering the networking arena, and more specifically Cisco technologies. They met that demand and incidently watched their market share grow to the behemoth they are today. Since its inception, Cisco Press has published well over 400 titles. It's no surprise that given a wealth of educational resources at their disposal, engineers who understand a given technology are more apt to recommend those technologies to their peers, and more importantly, to the people who often end up buying the technology. One only needs to look at the 20,000+ CCIEs in the world today to understand thats a pretty big propaganda machine to silence.
I've worked with both Cisco and Juniper technologies for a long time, and I'm convinced that Juniper's products are infinitely superior, but if Juniper is serious about being a major competitor, especially in the Enterprise market or other market segments outside of the Service Provider arena, it's high time they think about creating a publication arm which can compete with the likes of Cisco Press. It might not be the most profitable business, and in fact, if you're simply looking at dollars and cents with a microscopic view, it might even be a losing proposition. But the demand is out there, and if they meet it, I am fairly certain Juniper will see their marketshare increase in a really big way.



