ShortestPathFirst Network Architecture and Design, and Information Security Best Practices

12Sep/1116

Preparation Tips for the JNCIE-SEC Exam

Not a day that goes by since having passed the JNCIE-SEC exam that I don't receive an inquiry in one form or another regarding how I prepared for the exam.  It seems that there is an incredible amount of interest in this exam, especially from all those die-hard ScreenOS folks that are now converting to Junos.  So instead of constantly repeating myself, I figured I'd just put it up on the blog so others can benefit (leaving me more time to do other things, 'heh).

NOTE: For full disclosure, I must reveal that I am an Technical Trainer and Certification Proctor at Juniper Networks.  As such, I take EXTRA responsibility towards protecting the content and integrity of the exam and I take the certification credentials very seriously.  Not only that, I worked REALLY, REALLY hard to achieve my JNCIE certifications, and I believe everyone else should too! As such, I kindly ask that candidates refrain from asking me questions which would be considered a violation of the NDA.  Also, I should add that although I work for Juniper, the viewpoints expressed in this article are my own and may not necessarily be shared by my employer.

Let's first start by looking at the exam objectives and then we will move on to the materials I used for preparation and the hardware requirements for building out a lab which would provide for sufficient preparation.

Exam Objectives

Detailed exam objectives are listed on Juniper's JNCIE-SEC Exam Objectives certification page.  Familiarize yourself with these objectives and try to focus your study towards mastering all of these objectives.  Learn to read between the lines to identify if additional subject matter might need to be explored for full preparation.

In Junos there are typically more than one way to accomplish a given task so you would be wise to learn all the different ways of accomplishing a goal to achieve complete mastery of the subject matter.  For example, can you accomplish bidirectional address translation similar to Static NAT by instead using Source NAT and Destination NAT?  What are the benefits and caveats of each approach?

The current Junos software release that is used throughout the exam is Junos 11.1.  A quick glance through the release notes may be useful to familiarize yourself with some of the new features introduced in this version.

Study Materials

First and foremost, you are going to want to get your hands on the official Juniper courseware for all the requisite curriculum listed under the Junos Security track.  Specifically the following:

If you are unable to attend all of these courses in person, one of the cool things is that Juniper now lets you purchase the course materials for self-study purposes.  Basically you get access to everything that you would normally receive in the class, minus the instructor and access to the lab gear of course.

NOTE: While it is possible to order the materials for self-study, I strongly advocate taking the actual training if you can do so as the instructors tend to augment the subject matter with additional details, first-hand observations and experience not normally found in the materials.  Furthermore, as is the case in classes I normally teach, we tend to reveal tips and techniques which might be useful in certification attempts.

To augment the above, I would highly advise reading the book 'Junos Security' by Rob Cameron, Brad Woodberg, Patricio Giecco, Tim Eberhard, and James Quinn.  I'll be writing a review of this book in a subsequent post but for now I can't overemphasize how important this book was in my preparations. In fact, I would advise reading it twice for good measure.  There is a lot of good coverage in this book.  The majority of what you can expect to see in the exam is covered in this book, and what might be missing is adequately covered in the official courseware material.

I would also suggest making note of the links below.  You would be well advised to make use of both of these links during your preparation.  The first link is the JumpStation to a wide variety of SRX knowledge base articles and the second link provides detailed coverage on configuring High Availability across a number of different SRX platforms.  Familiarize yourself with the subtle differences in HA configuration across all the different platforms as you don't want your first time to be exposed to these differences to be during an examination attempt.

Before moving on to the lab setup, I want to mention that we will be offering JNCIE-SEC bootcamps sometime in the future.  Although there is currently no committed date for such an offering, when available you will get in-depth coverage of the types of topics you will expect to see on the exam in addition to a simulated lab on the final day of class.  Stay tuned for more information regarding our bootcamp offerings on Juniper's Learning Portal.

Lab Buildout

A common question asked throughout the forums is what type of lab setup is required for adequate preparation.  I can tell you that I personally prepared with only two SRX210s and single SRX100 device, but it slowed down my preparations immensely due to constantly having to rearrange and reconfigure the lab setup to accommodate different topologies (hub-and-spoke vs. full-mesh, clustered vs. non-clustered, etc.).  If you can spring for it, I would say purchase as many devices as you possibly can so you can build out a clustered SRX while leaving others as standalone and build complex VPN topologies.  This way you can spend more of your time learning new features rather than having to rearrange your lab setup.

amtrak_labOne of the benefits of having the smaller branch devices is that they are fairly portable.  In fact, as seen in the picture to the left, I was able to set up my lab during a trip from DC to New York on an Amtrak train in business class (although others did give me funny looks).  As you can see, even during a 3 hour trip, I was able to make use of this time for study preparations.

I would also strongly advise purchasing at least one device with the High Memory option as this will let you run the full gamut of IPS and UTM capabilities, assuming you've got the licenses.  Speaking of licenses, you can acquire trial licenses from Juniper which are valid for a period of 4 weeks, so I would advise holding off on activating these until you are completely ready.  Trial licenses are tied to a devices serial number, and although they are only valid for a period of 4 weeks, you can fetch a trial license once per year for each device serial number.

You can find SRX devices on eBay for as little as a few hundred dollars a piece, so building out a lab doesn't have to break the bank.  And the cool thing is that when you are done you can resell them for a fair market value so in the long term you really shouldn't have to spend that much getting a decent lab built out.

Once you have your lab completely set up, I would strongly advise going through all the labs in the official courseware as these are indicative of the types of things you will likely see on the exam.  Unlike JNCIE-ENT and JNCIE-SP, in this lab it really helps to have incorporated some type of client and server throughout the topology so that various features such as NAT and Stateful Firewall Policy can be properly tested.  In lieu of this, and with a bit of creative license, you could actually use one of your SRX platforms with a few Virtual Routers configured to simulate both clients and servers, connected to the Trust ports on the other devices throughout your topology.  This won't give you the same parity as having access to real Clients and Servers, but the idea is to be able to generate sufficient flows to properly trigger things like NAT rules or firewall policy.  A lot can be simulated by simply using 'telnet' and specifying the destination-port required to trigger a particular rule on a downstream device.

Final Notes

A question most often asked is how long should it take to prepare.  The answer to that question really depends on your Junos experience level and background.  If you already have previous working experience with Junos or a JNCIE, I would expect about 4-6 months should be sufficient for adequate preparation.  Otherwise if you are new to Junos or transitioning over from ScreenOS, I wouldn't even suggest starting exam preparations until you've had at least 1-2 years experience working with Junos and the SRX platforms.

Overall, this might seem like a long time but you'd be amazed at how quickly a few months can go by - if you can carve out even just an hour each day over the course of several months you will be infinitely better served than having to do a bunch of cramming in the last few weeks before your exam.  Remember, slow and steady wins the race here... it's a marathon, not a 100-meter dash.

Last but not least, and this may seem a bit silly but it is really important to try to get to bed early on the night of the exam and get a decent nights rest.  If you're not adequately prepared the night before the exam, cramming all night isn't going to do you any good.  Also, wake up early enough to ensure you can get a good breakfast.  Based on personal experience I can tell you that this makes a big difference.  I strongly advise oatmeal since it's low on the Glycemic Index and will give you a slow steady release of energy throughout the morning - the perfect way to ensure your mind is focused and you don't have any of those mid-morning dips in energy levels or mental acuity.

A little tidbit that not many folks are aware of - you can bring your own keyboards when you sit the exam as you might find the keyboards we provide to be difficult to use.  This is one of those little things that can really make a difference when you are used to running all those EMACS command sequences on a keyboard you are familiar with.

I will be proctoring this exam so for those of you attempting to sit the exam in our Herndon office, I look forward to meeting you and wish you the best in your upcoming attempt.  With a little bit of luck and a lot of preparation, you may find success and achieve the highly sought-after JNCIE-SEC designation.  Good luck and may the force be with you!

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to Google Buzz Send Gmail Post to LinkedIn Post to Slashdot Post to Technorati

21Jun/1112

JNCIE Tips from the Field :: Summarization Made Easy

Today we'll start with a series of articles covering tips and techniques that might be utilized by JNCIE candidates, whether pursuing the JNCIE-SP, JNCIE-ENT, or even the JNCIE-SEC.  The tips and techniques I will be covering might prove to be useful during a lab attempt but could also be used in real-world scenarios to save time and minimize configuration burden in addition to eliminating mistakes that might otherwise be made.  I want everyone to understand that what I am about to write is simply a technique.  I am not divulging any materials or topics which are covered under NDA.

NOTE: For full disclosure, I must reveal that I am an employee of Juniper Networks in their Education Services department.  As such, I take the responsibility of protecting the content and integrity of the exam as well as the certification credentials very seriously.  I would never reveal anything which would allow a candidate to have in-depth knowledge of any specific topics or questions that may appear on the exam.  Not only that, I worked REALLY, REALLY hard to achieve my JNCIE certifications, and I believe everyone else should too! It's certainly more rewarding that way too don't you think?!

So without further delay, let's take a look at today's technique.

It is well known that sumarization is a key aspect of any type of practical exam involving routing of some sort.  Those who have ever taken a CCIE Routing & Switching or CCIE Service Provider exam can attest, summarization is one thing every expert level candidate needs to master.  It is no different with Juniper.  In fact, Juniper's certification web page clearly lists as one of the JNCIE-ENT exam objectives the requrement to "Filter/summarize specific routes". 

What I will show you next is a technique which I find quite handy when attempting to determine the best summary for a given route, and you can do so without having to resort to pen and paper and figuring it out the old fashioned way, i.e. looking at prefixes in binary. This technique, rather, allows you to use the power of Junos to your advantage to perform these tasks.  What I will reveal will also show you a fundamental difference between IOS and Junos and highlights why I believe Junos to be a more flexible, powerful, and superior network operating system.  You simply can't do what I am about to do on a Cisco platform running IOS.

So let's start off by looking at a diagram.  Let's say we have a network that has several OSPF areas, and we must summarize some information for each respective area towards the backbone without encompassing routing information that might exist outside of that area.

ospf-summarization-example

Here we can see we have a backbone area, consisting of two routers, P1 and P2.  P1 is acting as an ABR for Area 1 and is connected to both R1 and R2. P2 is acting as an ABR for Area 2 and is connected to R3.  As you can see from the diagram, I have configured more than a single set of IP addresses on many of the physical interfaces as well as the loopbacks.  This way I can represent many more networks and therefore create multiple Network LSAs for purposes of summarization.

So let's assume that we need to create the largest aggregate possible for a particular area and advertise only that aggregate towards the core without encompassing any routes which might be outside the area from which the summary describes.  Now normally, one would take a look at the diagram, get out a pen and paper, and start a lengthy exercise of supernetting based on binary addresses.  This can take several minutes or more and is valuable time that could certainly be used on wide variety of other more important tasks like setting up MPLS LSPs or troubleshooting that Layer 2 VPN connectivity.  So let's take a look at a simple trick that actually takes advantage of Junos to determine what the summary should be.

What we are going to do is take advantage of a feaure inside Junos which automatically shows us a range of prefixes which match a given CIDR block.  The Junos operating system has built-in route matching functionality which allows us to specify a given CIDR block and returns all routes with a mask length equal to or greater than that which is specified.  So by applying this principle, what we want to do is look at the diagram for a particular area, choose the lowest IP within that area as our base, and then apply a subnet mask to it which attempts to encompass that route as well as others. 

For example, looking at this diagram, we see that the lowest IP address being used in Area 1 is the 168.10.32.1 address assigned to R1's loopback.  So let's start by using this as our base for our summary, and then simply apply a subnet mask to it which we think might encompass additional routes:

sfouant@p1# run show route 168.10.32.0/22   
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
168.10.32.1/32     *[OSPF/10] 8w4d 19:04:48, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:48, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:43, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:43, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0


Note: We can do this on any router within Area 1 since the Link-State Database is the same on all devices, but I prefer to perform the work on the ABR since this is where I will be performing the aggregation.  Also, the ABR may have other local and/or direct routes (or perhaps routes from other protocol sources) so we want to see things from the perspective of the ABR.

What we see here is that we have just now determined the summary route which in fact encompasses all the loopback addresses on both R1 as well as R2, but we need to keep going because this doesn't incorporate the Gigabit Ethernet links between all the devices:

sfouant@p1# run show route 168.10.32.0/21   
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
168.10.32.1/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:45, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:45, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0


Not quite. Let's keep trying:

sfouant@p1# run show route 168.10.32.0/20   
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
168.10.32.1/32     *[OSPF/10] 8w4d 19:04:55, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:55, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0


Nope, still not there yet. Let's try again:

sfouant@p1# run show route 168.10.32.0/19   
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
168.10.32.1/32     *[OSPF/10] 8w4d 19:04:58, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:58, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:53, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:53, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0
168.10.48.4/30     *[OSPF/10] 00:36:26, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.48.8/30     *[Direct/0] 8w4d 19:36:13
                    > via ge-0/0/1.0
168.10.48.9/32     *[Local/0] 8w4d 19:36:13
                      Local via ge-0/0/1.0
168.10.60.0/30     *[Direct/0] 8w4d 19:51:31
                    > via ge-0/0/0.0
168.10.60.1/32     *[Local/0] 8w4d 19:51:31
                      Local via ge-0/0/0.0
168.10.60.4/30     *[OSPF/10] 00:36:26, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.60.8/30     *[Direct/0] 8w4d 19:36:13
                    > via ge-0/0/1.0
168.10.60.9/32     *[Local/0] 8w4d 19:36:13
                      Local via ge-0/0/1.0


Ok, this looks more like it.  Here we can see we have all the Gigabit Ethernet links connecting all devices, as well as the loopback addresses.  This might be a suitable summary.  Let's keep going to see what happens:

sfouant@p1# run show route 168.10.32.0/18   
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
168.10.0.1/32      *[Direct/0] 8w4d 19:51:37
                    > via lo0.0
168.10.0.2/32      *[Direct/0] 8w4d 19:36:19
                    > via lo0.0
168.10.0.3/32      *[OSPF/10] 00:28:41, metric 1
                    > to 168.10.18.2 via fe-0/0/2.0
                      to 168.10.26.2 via fe-0/0/2.0
168.10.0.4/32      *[OSPF/10] 00:28:41, metric 1
                    > to 168.10.18.2 via fe-0/0/2.0
                      to 168.10.26.2 via fe-0/0/2.0
168.10.18.0/30     *[Direct/0] 8w4d 19:05:28
                    > via fe-0/0/2.0
168.10.18.1/32     *[Local/0] 8w4d 19:05:28
                      Local via fe-0/0/2.0
168.10.26.0/30     *[Direct/0] 8w4d 19:05:28
                    > via fe-0/0/2.0
168.10.26.1/32     *[Local/0] 8w4d 19:05:28
                      Local via fe-0/0/2.0
168.10.32.1/32     *[OSPF/10] 8w4d 19:05:04, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:05:04, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:59, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:59, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0
168.10.48.4/30     *[OSPF/10] 00:36:32, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.48.8/30     *[Direct/0] 8w4d 19:36:19
                    > via ge-0/0/1.0
168.10.48.9/32     *[Local/0] 8w4d 19:36:19
                      Local via ge-0/0/1.0
168.10.60.0/30     *[Direct/0] 8w4d 19:51:37
                    > via ge-0/0/0.0
168.10.60.1/32     *[Local/0] 8w4d 19:51:37
                      Local via ge-0/0/0.0
168.10.60.4/30     *[OSPF/10] 00:36:32, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.60.8/30     *[Direct/0] 8w4d 19:36:19
                    > via ge-0/0/1.0
168.10.60.9/32     *[Local/0] 8w4d 19:36:19
                      Local via ge-0/0/1.0


Clearly from this command, we can see we have now gone beyond what might be considered a suitable summary because we are now encompassing routes that exist within the backbone Area 0.  So it should be clear from this simple set of commands that the 168.10.32.0/19 would be a suitable address to use for our summary.

We could easily apply a similar example to Area 2 to quickly determine what the best summary would be.  We see from looking at the diagram the lowest IP within Area 2 is the 168.10.96.1 loopback address applied to R3.  When we use that as our base and go through the steps above, we can find our summary:

sfouant@p2# run show route 168.10.96.0/19   
inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
168.10.96.1/32     *[OSPF/10] 01:00:57, metric 1
                      to 168.10.112.2 via fe-0/0/3.0
                    > to 168.10.118.2 via fe-0/0/3.0
168.10.96.2/32     *[OSPF/10] 01:00:57, metric 1
                    > to 168.10.112.2 via fe-0/0/3.0
                      to 168.10.118.2 via fe-0/0/3.0
168.10.112.0/30    *[Direct/0] 01:13:48
                    > via fe-0/0/3.0
168.10.112.1/32    *[Local/0] 01:13:48
                      Local via fe-0/0/3.0
168.10.118.0/30    *[Direct/0] 01:13:48
                    > via fe-0/0/3.0
168.10.118.1/32    *[Local/0] 01:13:48
                      Local via fe-0/0/3.0


And there you have it! As you can see it's really quite simple and if you haven't stumbled upon this already you may be saying to yourself, "Why didn't I think of that before?".  I hear from many candidates that they spend considerable time the old fashioned way to determine summaries and I always ask myself why.  As you can see, there is an easier way!

Clearly the benefit to using a technique such as the above is to easily find the routes that best summarize a bunch of more specific routes.  The utility of such an approach, while very useful during a practical exam, might be considerably lessened in the real-world where it is likely that hierarchy has already been built into the network and you have network diagrams at your disposal.  On the other hand, there may be situations where you inherit a network that was developed with hierarchy in mind, however summarization was never employed, or it was employed improperly.  In such cases, the above technique can be a real time saver, allowing you to spend less time doing binary math and more time doing the fun stuff - like troubleshooting why that MPLS LSP isn't getting established!

Stay tuned for additional articles covering time saving tips and techniques which can be used during your next lab attempt!  Good luck, and may the force be with you!

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to Google Buzz Send Gmail Post to LinkedIn Post to Slashdot Post to Technorati

16Mar/112

Preparation Tips for the JNCIE-ER Exam

As many of you know, Juniper is currently undergoing a massive effort to update their certification program.  The previous track in 'Enterprise Routing' is now changing to 'Enterprise Routing and Switching' incorporating elements from the previous certification track in addition to some new elements essential to Enterprise switching such as Spanning-Tree, VLANs, Layer 2 Security, as well as High Availability features like Virtual Chassis.  We can expect that a lot of the topics like Firewalling and NAT will be removed from this exam as these topics will more properly appear in the Security track.

Although the new JNCIE-ENT certification is planned to be released in August 2011, there are many of you who are currently pursuing the existing JNCIE-ER before time runs out.  The good news is that Juniper plans to continue offering the existing JNCIE-ER exam until October 2011 so there is still quite a bit of time for those who are interested in attaining this certification.

There probably isn't a single day that goes by that I don't receive an email inquiry from someone currently pursuing the JNCIE-ER with a request to learn from my experiences and test preparation techniques.  And although this exam will only be available for another 7 months, I thought I'd write about my preparations and experiences with this exam so those candidates might benefit - not to mention it prevents me from having to keep repeating myself over and over again...

Building the Lab

For this particular exam, you are really going to need to get your hands on several J-Series routers, or at the very least some M/T/MX-Series routers with Adaptive Services capabilities (NOTE: This might require additional hardware on non J-Series devices, such as an Adaptive Services PIC or a Multi-Services PIC).  While it's possible to do a lot of the routing preparation with Olives, a good majority of the exam is on services such as Firewalling, NAT, and IPsec.  Without the right hardware, a candidate cannot properly prepare for these sections as performing these functions in an Olive is impossible.  Olives have no hardware PFE or the appropriate Services PICs or Modules, therefore there is no SP interface which is required to create interface-style and next-hop style service-sets.

If you happen to have a bunch of SSG 300-Series or SSG 500-Series ending in an M in your environment, you may be in luck.  These devices can be successfully converted to an equivalent J-Series box running Junos.  For example, an SSG 320M can be converted to a J2320, and an SSG 350M can be converted to a J2350.

The easiest way to do this is to boot the SSG platform from the USB flash drive which has been formatted with the Junos image.  An easy way to build a loadable Junos image onto a USB flash drive is to insert the USB flash drive into a working J-Series device and then perform the following function:

request system snapshot as-primary partition media compact-flash

This will copy all the appropriate system files and Junos image onto the flash drive and prepare it for booting on another device.

Once this has been done and the USB flash drive inserted into the SSG, the following commands can be issued to force the SSG to boot into Junos rather than ScreenOS:

set boot junos usb
save
reset

NOTE: The SSG 300M-series or SSG 500M-series device must be running ScreenOS version 6.1 or later in order for you to perform the conversion.  If your device is running an earlier ScreenOS version, you must first upgrade it to ScreenOS 6.1 or later.

A more thorough explanation of the upgrade process can be found here: Converting SSG 300M-series and SSG 500M-series Security Devices to J-series Services Routers with a USB Storage Device.

Exam Preparation Materials

In terms of exam study materials, here is what I used for the exam:

  • 'JUNOS Enterprise Routing' by Harry Reynolds and Doug Marschke. Read it twice if you can
  • 'Advanced Juniper Networks Routing in the Enterprise' courseware and labs which used to be available for free on the Juniper FastTrack site.  These are no longer available publicly, but can likely be found with a little digging.  I definitely recommend going through the labs because they are extremely representative of the types of things that you are likely to see on the exam.
  • 'Adaptive Services' chapter in the JUNOS 'Services Interfaces Configuration Guide' - its 500 pages but will definitely educate candidates on all the variants of Junos Services.
  • The 'JNCIP-M Study Guide' by Harry Reynolds is another really useful addition.  The labs in this book will really help with routing policy and configuration of OSPF, RIP, and BGP.
  • Probably the *single* most useful preparation tip I can give to anyone is to take the JNCIE-ER Bootcamp and/or the Remote Proctored lab exams offered by Proteus Networks.  I haven't personally taken the bootcamp, but I did see the materials from a colleague who sat through it and after sitting the exam I can tell you their Bootcamp is spot on.  On another note, I did take their remote proctored lab exams and once again I am not disappointed with my experience with them.  Rick Schenderlein was my proctor with Proteus and he really took the time to help me understand the areas that I could use improvement on.

As with all Expert level lab exams, a very important tip is to make sure you read the full exam in its entirety before starting a single configuration element.  This is truly an expert level exam - one which requires you to think through your design decisions.  There are often things later on in the exam which require you to go back and reconfigure something you've already set up in an previous section.  Reading ahead will allow you to save yourself some time when you've thought your design through fully in advance.

All in all, I didn't think the exam was that tough, but I also had 12+ years of experience working with Junos and a JNCIE-M certification prior to sitting the exam.  If you've already got the JNCIE-M, I think it's actually possible to prepare and pass this exam in just a few short months since there is considerable overlap between these two exams.  In my case, I actually finished the exam in a little over 5 hours and spent another 1-2 hours going over everything just to make sure I had it right. I've heard that most people going in are pretty much down to the wire with time so I'm not sure what happened in my case but simply attribute it to being over-prepared and having spent about a full year of non-stop preparations between the JNCIP-M, JNCIE-M, and the JNCIE-ER exams.  The trick here, as with preparation for anything, is to be consistent and develop a schedule which you can live with - a few hours a day over a span of several months will serve you infinitely better than studying 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 JNCIE-ER certifications, and I wish you the best of luck in your endeavors!

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to Google Buzz Send Gmail Post to LinkedIn Post to Slashdot Post to Technorati

13Jan/109

Preparation Tips for the JNCIP-M/T and JNCIE-M/T Exams

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!

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to Google Buzz Send Gmail Post to LinkedIn Post to Slashdot Post to Technorati