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:
- Junos for Security Platforms (JSEC)
- Junos Unified Threat Management (JUTM)
- Advanced Junos Security (AJSEC)
- Junos Intrusion Prevention System Functionality (JIPS)
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.
- SRX Getting Started - Configuration Examples & Troubleshooting (JumpStation)
- SRX Getting Started - Configure Chassis Cluster (High Availability)
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.
One 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!
Juniper SRX Tips :: Altering Default-Deny Behavior
In our previous article, we looked at using apply-groups to alter all the security policies uniformly on an SRX device such that they would all have an implicit logging statement. And while this is fine for all existing policies, it doesn't log traffic which doesn't match any explicitly defined security policy.
The reason for this is due to the fact that in Junos, traffic which doesn't match an explicitly defined security policy matches against the default-deny policy. However, given the fact that the default-deny policy is implicitly defined, apply-group configurations are of little benefit as apply-groups can only be inherited by those elements which have been explicitly defined.
Often in these cases, administrators will simply choose to create their own deny policies with the desired options and place this deny policy as the last policy for traffic going from one zone to another. However, in instances where there are many zones, it might prove too cumbersome and time consuming to manually configure this to accommodate all zones.
Clearly it would be more beneficial to have something akin to the Global Zone in ScreenOS which can be used to match on all traffic which doesn't match against any of the explicitly defined security policies. However, at the time of this writing, Global Zone functionality doesn't exist in Junos.
The good news is that we can use the power of apply-groups once again to our benefit, this time to create an explicitly defined deny policy which will be inherited at the tail-end of all security policies defined within our configuration. Note that this will encompass both Inter-zone as well as Intra-zone traffic.
For this example, let's assume that we want to log everything that would normally hit the default-deny policy. Let's start by taking a look at our baseline configuration:
root@ce-1# show security policies
from-zone Trust to-zone Untrust {
policy allow-outbound {
match {
source-address Users-subnet;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Untrust to-zone Trust {
policy allow-web {
match {
source-address any;
destination-address web-server;
application junos-http;
}
then {
permit;
}
}
}
Here you can see we have a policy allowing all traffic outbound from the Users-subnet in the Trust zone towards the Untrust zone, and another policy allowing inbound HTTP traffic from the Untrust zone towards the Web Server in the Trust zone. Now, in order to change the default-deny behavior and add additional options, we will use an apply-group to inherit a new policy at the tail-end of all previously defined policies, as follows:
groups {
default-log {
security {
policies {
from-zone <*> to-zone <*> {
policy log-all-else {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
}
}
}
}
Finally, let's apply our apply-group at the [security policies] stanza within our configuration:
root@ce-1# set security policies apply-groups default-log
Now that we've completed the configuration, let's examine the results of the application of our apply-group by taking a look at our security policies, this time by displaying the inherited configuration:
root@ce-1# show security policies | display inheritance
apply-groups default-log
from-zone Trust to-zone Untrust {
policy allow-outbound {
match {
source-address Users-subnet;
destination-address any;
application any;
}
then {
permit;
}
}
##
## 'log-all-else' was inherited from group 'default-log'
##
policy log-all-else {
##
## 'match' was inherited from group 'default-log'
##
match {
##
## 'any' was inherited from group 'default-log'
##
source-address any;
##
## 'any' was inherited from group 'default-log'
##
destination-address any;
##
## 'any' was inherited from group 'default-log'
## Warning: application or application-set must be defined
##
application any;
}
##
## 'then' was inherited from group 'default-log'
##
then {
##
## 'deny' was inherited from group 'default-log'
##
deny;
##
## 'log' was inherited from group 'default-log'
##
log {
##
## 'session-init' was inherited from group 'default-log'
##
session-init;
}
}
}
}
from-zone Untrust to-zone Trust {
policy allow-web {
match {
source-address any;
destination-address web-server;
application junos-http;
}
then {
permit;
}
}
##
## 'log-all-else' was inherited from group 'default-log'
##
policy log-all-else {
##
## 'match' was inherited from group 'default-log'
##
match {
##
## 'any' was inherited from group 'default-log'
##
source-address any;
##
## 'any' was inherited from group 'default-log'
##
destination-address any;
##
## 'any' was inherited from group 'default-log'
## Warning: application or application-set must be defined
##
application any;
}
##
## 'then' was inherited from group 'default-log'
##
then {
##
## 'deny' was inherited from group 'default-log'
##
deny;
##
## 'log' was inherited from group 'default-log'
##
log {
##
## 'session-init' was inherited from group 'default-log'
##
session-init;
}
}
}
}
Once again, with just a couple of lines of code we can streamline the configuration to a large extent, in this case creating an explicitly defined deny policy which logs all traffic that would otherwise be silently discarded. And best of all, we can do so without having to resort to manual configuration of each and every one.
In small installations this technique might be of little benefit, but in larger implementations consisting of dozens of zones with a combination of Interzone and Intrazone and bidirectional security policies, the benefit of such an approach cannot be understated. Not only will this ease configuration burden, but it will ensure that all traffic which doesn't match any of the existing security policies will be handled in a consistent manner. Of course, as with previous examples, if there are certain policies that we don't want to inherit this new default-deny, we can simply utilize the apply-group-except statement for each of those respective policies.
In our next article we will examine changing the built-in Junos application defaults so that we can customize timers and other parameters.
Users-subnet
Juniper SRX Tips :: Uniform Security Policy Modification
Often there are instances where we want to affect all security policies configured on an SRX device. For example, let's say that we have thousands of policies configured on our firewall, and we want to enable logging for every single policy. Obviously this would take some time if we were to do this manually on each and every individual policy, so an easier way is desired.
In ScreenOS we have the concept of a Global zone which acts as a container encompassing all zones, but to date, Junos does not support a similar functionality on the SRX. Furthermore, the Global zone doesn't affect existing policies but rather is way to apply a consistent policy to all Inter-zone and Intra-zone traffic that doesn't match any of the existing policies.
However, despite all of this, there is in fact a methodology we can use to uniformly modify all of the existing security policies on our box, in a manner that is actually much more powerful than what is accomplished in ScreenOS with the Global zone.
Let's take a look. First, let's say we have some policies that we would like to enable logging on:
root@ce-1# show security policies
from-zone Trust to-zone Untrust {
policy allow-outbound {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Untrust to-zone Trust {
policy allow-web {
match {
source-address any;
destination-address web-server;
application junos-http;
}
then {
permit;
}
}
}
Here you can see we have a policy allowing all traffic outbound from Trust to Untrust, and another policy allowing inbound HTTP traffic from the Untrust zone towards the Web Server in the Trust zone. Now, let's enable logging for all of our policies by using an apply-group and matching on all policies from any zone to any other zone. Note that this will encompass both Inter-zone as well as Intra-zone traffic:
groups {
global-logging {
security {
policies {
from-zone <*> to-zone <*> {
policy <*> {
then {
log {
session-init;
}
}
}
}
}
}
}
}
Finally, let's apply our apply-group at the [security policies] stanza within our configuration:
root@ce-1# set security policies apply-groups global-logging
Now that we've completed the configuration, let's examine the results of the application of our apply-group by taking a look at our security policies, this time by displaying the inherited configuration:
root@ce-1# show security policies | display inheritance apply-groups global-logging from-zone Trust to-zone Untrust { policy allow-outbound { match { source-address any; destination-address any; application any; } then { permit; ## ## 'log' was inherited from group 'global-logging' ## log { ## ## 'session-init' was inherited from group 'global-logging' ## session-init; } } } } from-zone Untrust to-zone Trust { policy allow-web { match { source-address any; destination-address web-server; application junos-http; } then { permit; ## ## 'log' was inherited from group 'global-logging' ## log { ## ## 'session-init' was inherited from group 'global-logging' ## session-init; } } } }
As you can see, with a couple of lines of code we can alter all of the existing policies on our device without having to resort to manual configuration of each and every one. This type of functionality is perfect when we want to have a singular set of configuration elements apply to all of our policies uniformly. On the other hand, if there are certain policies that we don't want to inherit these settings, we can simply utilize the apply-group-except statement for each of those respective policies.
In our next article we will examine how to change the default-deny behavior on the SRX to also including logging of denied packets.
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.
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!
Day One Guide: Junos Tips, Techniques, and Templates 2011
I am happy to announce that Juniper has just released a new Day One Guide entitled "Junos Tips, Techniques, and Templates 2011". For this particular Day One Guide, Juniper Networks Books and J-Net joined forces and requested the best and brightest Junos tips and techniques from the Junos user community. In fact, the book was created after a thorough selection process which included reviewing over 300 submitted tips by over 100 individuals on the J-Net community boards at forums.juniper.net.
I am honored that Juniper accepted my contributions and decided to include them in this guide. My contribution "Automatically Allow Configured BGP Peers in a Loopback Firewall Filter" covers how to configure a Junos prefix-list in conjunction with the apply-path features to parse a configuration and then dynamically build a list of matching prefixes for use in a firewall filter.
Outside of my meager contribution, this guide is chock full of dozens of useful tips and techniques and is an indispensable guide for anyone involved in managing Juniper platforms on a daily basis.
Junos Tips, Techniques, and Templates 2011 can be ordered on Amazon in hardcopy or Kindle edition, and is also available as a free download in PDF format. Enjoy!
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!
Interview with Chris Grundemann, Author of ‘Day One: Exploring IPv6′
Spend a little time in Juniper, ARIN or a wide variety of other networking forums, and you'll likely see the name Chris Grundemann. Recently, we had the opportunity to catch up with him, and discuss the nature of his involement in deploying IPv6 at tw telecom, as well as his recently published Juniper booklet entitled "Day One: Exploring IPv6".
Thanks Chris for joining us today. Tell us a little bit about yourself and your career experience, and specifically tell us about your day-to-day experience working with IPv6.
Certainly. Career-wise, I am currently engaged as a Network Architect with tw telecom inc. where I am responsible for setting forward looking architectures and leading various technology development efforts. I am also the Founding Chair of the Colorado Chapter of the Internet Society, Founding Editor of Burning with the Bush and an active participant (and current AC nominee) in the ARIN policy development process. Obviously I am also the author of the Juniper "Day One: Exploring IPv6” booklet.
My day-to-day experience with IPv6 is actually pretty minimal at this point. Last year while I was still on the IP backbone team here at tw telecom, I rolled out IPv6 across all of our PE routers - in one night. Since then, there has been very little technical work needed from a networking perspective. We still have plenty of work to fully operationalize IPv6 but it is mostly systems and process issues now, much less exciting.
For any readers who are interested, you can find a lot more about me on my personal site. This includes links to my Facebook and LinkedIn profiles, so feel free to send me an invite to connect!
You rolled out IPv6 across all of your PE routers in a single night! That's a pretty big accomplishment. Would you say that Juniper's implementation of IPv6 made it easy to deploy and support IPv6 across a large number of devices?
Thanks! There was of course plenty of preparation leading up to that night, but we "flipped the switch" all at once and it went extremely smooth.
All of Juniper's carrier routers forward IPv6 in hardware, which is huge. Also, IPv6 was integrated into Junos very well, most of the commands are similar if not the same between IPv4 and IPv6. This makes it really easy operationally speaking. So, yes, I would definitely agree that Juniper's implementation of IPv6 makes it easy to deploy and scale.
Ok, so let's specifically talk about the current state of affairs with IPv6. Hurricane Electric, one of the leading providers of IPv6 connectivity, states that as of the time of this writing we have less than a year remaining until complete IPv4 exhaustion. This is based on the fact that there are only sixteen /8 network blocks available for allocation (approximately 6%). We've heard figures such as this for many years now, but techniques like NAT have allowed people to extend the length of the existing IPv4 address pool. Based on your experience working with IPv6 and also your involvement with ARIN, can you help us to understand what is fact and what is fiction - how long do you really think we have before total address exhaustion becomes a reality and customers will have no choice but to start looking at IPv6 for future deployments?
Let me re-phrase your query into two distinct questions if I may: How long do we have with IPv4 and when will network operators be forced to consider IPv6 deployment? The answers are very different so I think they should be addressed individually.
First, How long do we have with IPv4? As you state, Hurricane Electric's widget gives us less than a year. But let's start with a quick level-set. There are actually three distinct points leading up to what I would call "complete IPv4 exhaustion." The first is IANA unallocated pool exhaustion. This is the point when the global pool of IPv4 /8s designated for unicast routing reaches 5 remaining and subsequently each of the 5 RIRs receives one (thus depleting the unallocated pool completely). The second point is RIR exhaustion, when the Regional Internet Registries can no longer allocate nor assign IPv4 addresses that they received from IANA (because they don't have any). Finally, true exhaustion happens when the ISPs/LIRs exhaust their remaining IPv4 addresses and end users simply cannot get a routable IPv4 address.
As I understand it, Hurricane Electric is getting their data from the IPv4 Address Report built by Geoff Huston and are predicting the date of the first point; exhaustion of the IANA IPv4 unallocated address pool. As of today that date is projected to be 1 July, 2011 - less than a year away. However, this projection is based on the current and historical run-rate, on how fast we have consumed IPv4 addresses up to this point. Because so many folks have not paid attention to IPv6 and are still wholly dependent on IPv4, it is quite likely that the run-rate will increase, perhaps drastically, as we get closer to IANA unallocated pool exhaustion. If this happens, we actually have much less than one year before reaching that first point.
Predicting the second point gets a little murkier, because different folks define this point differently. Should we declare that RIR exhaustion is upon us when the first RIR runs out of unallocated IPv4 address space? When the last one does? Perhaps when the RIR for your region has no unallocated IPv4 to give you? Mr. Huston projects the date "where the first RIR has exhausted its available pool of addresses" and since he has already done all the work, it is a convenient place to set the bar. As of today that date is predicted to be 20 January, 2012. Remember again that this does not take into account any possible run on IPv4 addresses that may happen between now and then and that other RIRs will have IANA allocated IPv4 space for some time after that date.
The final point is the hardest one to pin down. This is mostly because it would be very hard, if not impossible to quantify how much currently allocated/assigned address space is unused or underused.
Many ISPs may be able to feed off of current reserves for months or even years, while many more will run out of IPv4 addresses within weeks of receiving their last traditional allocation from their RIR.
You also have to take into account things like IPv4 address transfers which are now allowed in many regions, other possible policy changes and transition technologies such as carrier-grade-NAT (CGN). All of these things pull IPv4 use in different directions. So no one can intelligently predict this final date.
Although I cannot tell you that IPv4 will be dead in X years, there are some very important facts that we should not overlook. The first is that Geoff Huston's projections have remained quite consistent over the past two years, and the time remaining has steadily decreased over those two years. The second is that we are running out of usable IPv4 addresses. NAT was a stop gap to allow folks time to adopt IPv6. That time has largely been wasted unfortunately. The bottom line is that IPv4 will continue to become more expensive to use on interconnected networks while IPv6 continues to become less expensive.
This is where the second question comes into play: When will network operators be forced to look at IPv6 deployment? The truth is that they should be looking into it now. If you are not adding only IPv6 capable hardware and software to your network now - you are going to be forced to spend extra money upgrading sooner than you would like. As IPv4 becomes ever more expensive (both directly as ISPs charge more for it or you are forced to pay for addresses through a transfer and indirectly as CGNs and other transition mechanisms drive up operational costs), many will turn to IPv6 - more and more as the next two years play out. Businesses that have IPv6 capable networks now will have a competitive advantage over those who are forced to upgrade their network to get IPv6 connectivity.
An often overlooked aspect of this question is security. If your network is not IPv6 enabled today, you likely have IPv6 traffic being tunneled right through your firewalls. Another is mobile access - very soon mobile phone operators will be migrating to 4G technologies that take advantage of IPv6 addressing for all new phones on their networks. These IPv6 mobile devices will be reaching your website(s) via IPv6, if you want them to have the best possible experience your site needs to be running IPv6 natively. As soon as a website is IPv6 only, ISPs will be required to provide IPv6 connectivity or lose customers to those who do.
So, in short, the answer really is now. Everyone should be thinking of IPv6 when planning all future network deployments, starting now (if not yesterday).
Many industry experts are already speculating that an IPv4 black market will exist because of the depletion of IPv4 address space and the lack of a large IPv6 installed base. Do you suspect there will be a black market for IPv4 addresses and what impacts might this have?
The answer varies a bit depending on how you choose to define black market. Under many definitions, that market already exists. I think that it already impacts us and that it will get worse as we near and ultimately cross the free pool depletion threshold. Think spammers and phishers operating out of address blocks that they beg, borrow, steal and often "rent" or "buy." There are also instances where much more legitimate businesses make back-room deals for the use of IP addresses.
Overall some of the most negative impacts surround the WHOIS database, and the integrity of the data it contains. When folks get addresses through grey or black markets, instead of from the RIR they are probably not going to report proper reassignment registration information to the RIR. This leads to stale WHOIS data which makes troubleshooting and abuse reporting much harder for operators and investigation much harder for law enforcement. I helped author a recently adopted ARIN policy change to start addressing some of this and am actually spearheading an effort to continue that work with another policy proposal in the ARIN region as we speak.
Another concern is prefix hijacking, this is not really a black market issue but is another facet of the problems we will face more and more as IPv4 gets more expensive, unless and until IPv6 adoption picks up across the board.
There is a lot of work going on right now within ARIN, the IETF and other RIRs to try and limit the impacts of any IPv4 black market, other abuses and also ease the overall IPv4-IPv6 transition. Anyone interested in this work should join the ARIN-PPML (Public Policy Mailing List) [http://lists.arin.net/mailman/listinfo/arin-ppml] (or their local equivalent) and/or show up at a meeting; and join the conversation. ARIN and the other RIRs are open, transparent, ground-up organizations and your voice can make a huge impact.
It has been observed that the number of Autonomous Systems supporting IPv6 as well as IPv6 DNS Queries, in the form of AAAA records, have significantly increased in the last several years. Have we reached that critical mass where widespread adoption is imminent and if so what can we expect to see in the next few years?
I think that widespread adoption is imminent now but I don't believe that it is an issue of critical mass, more an issue of network operators starting to see the dates we discussed above nearing. I make the distinction because there is still very little IPv6 traffic actually flowing. What I think is happening is that the folks who have been watching this are getting a sense of urgency that is finally breaking through to the folks who write the checks. The real critical mass moment will be when we see IPv6 traffic levels really climbing and IPv4 traffic growth starting to slow. I think you can expect to see that in the next few years. Within five certainly and probably within three.
Let's talk for a minute about the Juniper "Day One" guides. Can you tell us what they are all about, and more specifically, tell us a little bit about the "Day One: Exploring IPv6" guide that you've written. What is it all about and what can potential readers hope to gain from reading it?
The Day One guides are exactly what the name implies, they are booklets that give you everything you need to know to get through your first day working on the covered topic. They are hands-on, example-driven, cut-to-the-chase primers on all sorts of topics surrounding Juniper Networks gear and the Junos OS. In "Exploring IPv6" I tried to really provide that common sense starting point for implementing IPv6. The booklet covers enabling IPv6, adding IPv6 addresses to interfaces, configuring static routes in IPv6, implementing IPv6 IGPs (RIPng, IS-IS and OSPF v3) as well as all the basic verification and troubleshooting that surrounds those topics. If you follow along through the book examples and work through all of the "try it yourself" exercises, you should gain a solid understanding of IPv6 LANs and how IPv6 is implemented in JUNOS, as well as a great general / vendor-agnostic view of IPv6 itself and how it differs from IPv4.
Tell us a little bit about the "Advanced IPv6" Day One Guide that you are currently working on? What should the network practitioner hope to gain from reading it?
Advanced IPv6 is kind of a "Day Two" guide on IPv6 in JUNOS. It continues right where Exploring IPv6 left off and moves onto more advanced topics such as BGP, VRRP, CoS, Multicast and system management. It takes you another big step towards being able to fully implement IPv6 in a production environment.
After you are done with "Advanced IPv6" do you have any other writing aspirations?
I do. Writing is definitely work but I am finding that it's work I really enjoy. Hopefully others like my writing in these Day One booklets and that gives me the opportunity to continue writing!
Thanks for joining us today Chris. This has been extremely informative and we are all really excited about reading your next Day One guide and are anxiously awaiting its arrival!
Book Review :: JUNOS High Availability: Best Practices for High Network Uptime
JUNOS High Availability: Best Practices for High Network Uptime
by James Sonderegger, Orin Blomberg, Kieran Milne, Senad Palislamovic
Paperback: 688 pages
Publisher: O'Reilly Media
ISBN-13: 978-0596523046
High Praises for JUNOS High Availability
Building a network capable of providing connectivity for simple business applications is a fairly straightforward and well-understood process. However, building networks capable of surviving varying degrees of failure and providing connectivity for mission-critical applications is a completely different story. After all, what separates a good network from a great network is how well it can withstand failures and how rapidly it can respond to them.
While there are a great deal of books and resources available to assist the network designer in establishing simple network connectivity, there aren't many books which discuss the protocols, technologies, and the myriad ways in which high availability can be achieved, much less tie it all together into one consistent thread. "JUNOS High Availability" does just that, in essence providing a single, concise resource covering all of the bits and pieces which are required in highly available networks, allowing the network designer to build networks capable of sustaining five, six, or even seven nines of uptime.
In general, there are a lot of misconceptions and misunderstandings amongst Network Engineers with regards to implementing high availability in Junos. One only needs to look at the fact that Graceful Restart (GR) protocol extensions and Graceful Routing Engine Switchover (GRES) are often mistaken for the same thing, thanks in no small part to the fact that these two technologies share similar letters in their acronyms. This book does a good job of clarifying the difference between the two and steers clear of the pitfalls typically prevalent in coverage of the subject matter. The chapter on 'Control Plane High Availability' covers the technical underpinnings of the underlying architecture on most Juniper platforms; coverage of topics like the separation between the control and forwarding planes, and kernel replication between the Master and Backup Routing Engine give the reader a solid foundation to understand concepts like Non-Stop Routing, Non-Stop Bridging, and In-Service Software Upgrades (ISSU). In particular I found this book to be very useful on several consulting engagements in which seamless high availability was required during software upgrades as the chapter on 'Painless Software Upgrades' discusses the methodology for achieving ISSU and provides a checklist of things to be performed before, during, and after the upgrade process. Similarly, I found the chapter on 'Fast High Availability Protocols' to be very informative as well, providing excellent coverage of BFD, as well as the differences between Fast Reroute vs. Link and Node Protection.
Overall I feel this book is a valuable addition to any networking library and I reference it often when I need to implement certain high availability mechanisms, or simply to evaluate the applicability of a given mechanism versus another for a certain deployment. The inclusion of factoring costs into a high availability design is a welcome addition and one that all too many authors fail to cover. Naturally, it only makes sense that costs should be factored into the equation, even when high availability is the desired end-state, in order to ensure that ultimately the business is profitable. If I had to make one suggestion for this book it is that there should be additional coverage of implementing High Availability on the SRX Series Services Gateways using JSRP, as this is a fundamental high availability component within Juniper's line of security products. To the authors credit however, this book was written just as the SRX line was being released, so I don't fault the authors for providing limited coverage. Perhaps more substantial coverage could be provided in the future if a Second Edition is published.
The bottom line is this - if you are a Network Engineer or Architect responsible for the continuous operation or design of mission-critical networks, "JUNOS High Availability" will undoubtedly serve as an invaluable resource. In my opinion, the chapters on 'Control Plane High Availability', 'Painless Software Upgrades', and 'Fast High Availability Protocols' are alone worth the entire purchase price of the book. The fact that you get a wealth of information beyond that in addition to the configuration examples provided makes this book a compelling addition to any networking library.
What’s the BFD with BFD?
Many networks today are striving for "five nines" high availability and beyond. What this means is that network operators must configure the network to detect and respond to network failures as quickly as possible, preferably on the order of milliseconds. This is in contrast to the failure detection inherent in most routing protocols, which is typically on the order of several seconds or more. For example, the default hold-time for BGP in JUNOS is 90 seconds, which means that in certain scenarios BGP will have to wait for upwards of 90 seconds before a failure is detected, during which time a large percentage of traffic may be blackholed. It is only after the failure is detected that BGP can reconverge on a new best path.
Another example is OSPF which has a default dead interval of 40 seconds, or IS-IS which has a default hold-time of 9 seconds (for DIS routers), and 27 seconds (for non-DIS routers). For many environments which support mission-critical data, or those supporting Voice/Video or any real-time applications, any type of failure which isn't detected in the sub-millisecond range is too long.
While it is possible to lower timers in OSPF or IS-IS to such an extent that a failure between two neighbors can be detected rather quickly (~1 second), it comes at a cost of increased protocol state and considerable burden on the Routing Engine's CPU. As an example, let us consider the situation in which a router has several hundred neighbors. Maintaining subsecond Hello messages for all of these neighbors will dramatically increase the amount of work that the Routing Engine must perform. Therefore, it is a widely accepted view that a reduction in IGP timers is not the overall best solution to solve the problem of fast failure detection.
Another reason that adjusting protocol timers is not the best solution is that there are many protocols which don't support a reduction of timers to such an extent that fast failure detection can be realized. For example, the minimum BGP holdtime is 20 seconds, which means that the best an operator can hope for is a bare minimum of 20 seconds for failure detection.
Notwithstanding, this does nothing about situations in which there is no protocol at all, for example, Ethernet environments in which two nodes are connected via a switch as can be seen in the figure below. In this type of environment, R1 has no idea that R2 is not reachable, since R1's local Ethernet segment connected to the switch remains up. Therefore, R1 can't rely on an 'Interface Down' event to trigger reconvergence on a new path and instead must wait for higher layer protocol timers to age out before determining that the neighbor is not reachable. (Note to the astute reader: Yes, Ethernet OAM is certainly one way to deal with this situation, but that is a discussion which is beyond the scope of this article).
Essentially, at the root of the problem is either a lack of suitable protocols for fast failure detection of lower layers, or worse, no protocol at all. The solution to this was the development of Bidirectional Forwarding Detection, or BFD, developed jointly by Cisco and Juniper. It has been widely deployed and is continuing to gain widespread acceptance, with more and more protocols being adapted to use BFD for fast failure detection.
So what is the Big Freaking Deal with Bidirectional Forwarding Detection anyway and why are so many operators implementing it in their networks? BFD is a simplistic hello protocol with the express purpose of rapidly detecting failures at lower layers. The developers wanted to create a low overhead mechanism for exchanging hellos between two neighbors without all the nonessential bits which are typical in an IGP hello or BGP Keepalives. Furthermore, the method developed had to be able to quickly detect faults in the Bidirectional path between two neighbors in the forwarding plane. Originally, BFD was developed to provide a simple mechanism to be used on Ethernet links, as in the example above, prior to the development of Ethernet OAM capabilities. Hence, BFD was developed with this express purpose in mind with the intent of providing fault identification in an end-to-end path between two neighbors.
Once BFD was developed, the protocol designers quickly found that it could be used for numerous applications beyond simply Ethernet. In fact, one of the main benefits of BFD is that it provides a common method to provide for failure detection for a large number of protocols, allowing a singular, centralized method which can be reused. In other words, let routing protocols do what they do best - exchange routing information and recalculate routing tables as necessary, but not perform identification of faults at lower layers. An offshoot of this is that it allows network operators to actually configure higher protocol timer values for their IGPs, further reducing the burden placed on the Routing Engine.
BFD timers can be tuned such that failure detection can be realized in just a few milliseconds, allowing for failure and reconvergence to take place in similar timeframes to that of SONET Automatic Protection Switching. A word of caution - while BFD can dramatically decrease the time it takes to detect a failure, operators should be careful when setting the intervals too low. Very aggressive BFD timers could cause a link to be declared down even when there is only a slight variance in the link quality, which could cause flapping and other disastrous behavior to ensue. The best current practice with regards to BFD timers is to set a transmit and receive interval of 300ms and a multiplier of 3, which equates to 900ms for failure detection. This is generally considered fine for most environments, and only the most stringent of environments should need to set their timers more aggressive than this.
One question that is commonly asked is how is it that BFD can send hello packets in the millisecond range without becoming a burden on the router. The answer to this question lies in the fact that BFD was intended to be lightweight and run in the forwarding plane, as opposed to the control plane (as is the case with routing protocols). It is true that while early implementations of BFD ran on the control plane, most of the newer implementations run in the forwarding plane, taking advantage of the dedicated processors built into the forwarding plane and alleviating the burden which would otherwise be place on the RE. In JUNOS releases prior to JUNOS 9.4, BFD Hello packets were generated via RPD running on the RE. In order to enable BFD to operate in the PFE in JUNOS versions prior to JUNOS 9.4, the Periodic Packet Management Daemon (PPMD) had to be enabled, using the command 'set routing-options ppm delegate processing'. In JUNOS 9.4 and higher this is the default behavior and BFD Hello packets are automatically handled by PPMD operating within the PFE.
Facilitating Firewall Filter Configuration in JUNOS using ‘apply-path’
Undoubtedly, one of the coolest features in JUNOS is the apply-path statement. Using apply-path, an operator can configure a prefix-list which comprises IP prefixes linked to a defined path within JUNOS. This facilitates tasks like configuring firewall filters to allow traffic from configured BGP neighbors, making them highly dynamic.
For example, suppose we have the following configuration:
system {
ntp {
server 192.168.70.10;
server 192.168.72.10;
}
}
protocols {
bgp {
group ibgp {
type internal;
neighbor 192.168.50.100;
neighbor 192.168.50.101;
neighbor 192.168.50.102;
neighbor 192.168.50.103;
neighbor 192.168.50.104;
neighbor 192.168.50.105;
}
}
}
Let's assume we want to restrict BGP and NTP traffic to only those peers with whom we wish to peer with. Without the use of apply-paths, we'd have to configure a prefix-list or add individual source-address statements comprising all of the above addresses and add that to our firewall filter configuration, as in the following:
policy-options {
prefix-list bgp-peers {
192.168.50.100/32;
192.168.50.101/32;
192.168.50.102/32;
192.168.50.103/32;
192.168.50.104/32;
192.168.50.105/32;
}
prefix-list ntp {
192.168.70.10/32;
192.168.72.10/32;
}
}
firewall {
filter re-protect {
term bgp {
from {
prefix-list {
bgp-peers;
}
protocol tcp;
port bgp;
}
then accept;
}
term ntp {
from {
prefix-list {
ntp;
}
protocol udp;
port ntp;
}
then accept;
}
}
}
As you can see, that's a lot of redundant typing especially considering we've already configured these under their respective configuration stanzas within JUNOS. The above example might not seem like a lot, but if you're looking at an ISP edge router it wouldn't be uncommon to see several hundred such BGP neighbor statements. Now multiply that across all of your devices in your network and you will quickly see that prefix-list maintenance can quickly become cumbersome.
Enter the apply-path statement. The idea behind the apply-path statement was to create a method whereby prefix-lists could be created dynamically by simply referencing other portions of the configuration, thus eliminating most of the effort required to maintain a prefix list. The path consists of elements separated by spaces. Each element matches a specific keyword or identifier within the configuration, and you can use wildcards to match more than one identifier. Wildcards must be enclosed in angle brackets, for example, <*>.
As an example, let us take a look at how the above prefix-list definition could be simplified:
policy-options {
prefix-list bgp-peers {
apply-path "protocols bgp group <*> neighbor <*>";
}
prefix-list ntp {
apply-path "system ntp server <*>";
}
}
With the above we've eliminated 8 lines of code and replaced it with 2. The apply-path statement is telling the prefix-list to be generated dynamically by looking at the "protocols bgp group <*> neighbor <*>" and "system ntp server <*>" portions of the configuration.
Although this has simplified the configuration greatly, it comes at the expense of being able to easily identify which addresses are part of a prefix-list. In order to properly determine if the apply-path statement is working correctly and also to identify those addresses which are part of the prefix list, we can use the "show | display inheritence" command, as in the following:
root@jncie-lab# show | display inheritance
prefix-list bgp-peers {
##
## apply-path was expanded to:
## 192.168.50.100/32;
## 192.168.50.101/32;
## 192.168.50.102/32;
## 192.168.50.103/32;
## 192.168.50.104/32;
## 192.168.50.105/32;
##
apply-path "protocols bgp group <*> neighbor <*>";
}
prefix-list ntp {
##
## apply-path was expanded to:
## 192.168.70.10;
## 192.168.72.10;
##
apply-path "system ntp server <*>";
}
In closing, the use of apply-paths in an operational network assists in hardening a network, and can dramatically reduce the operational overhead of maintaining prefix-lists. In addition, it also helps to eliminate configuration errors in which the address added to the prefix list don't match that configured in respective portions within the JUNOS configuration.
Recent Tweets
- No public Twitter messages.
Recent Posts
- What’s a Steiner Tree?
- Preparation Tips for the JNCIE-SEC Exam
- Black Hat OSPF Vulnerabilities: Much Ado About Nothing
- Juniper SRX Tips :: Altering Default-Deny Behavior
- Juniper SRX Tips :: Uniform Security Policy Modification
Juniper News
- Junos Pulse Secure Access Service 7.4 now offers FIPS and Suite B May 21, 2013
- Juniper Networks Delivers Big Data Analytics Solution for Better Network Intelligence and to Drive Informed Decisions May 21, 2013
- Bringing Big Data to Service Provider Networks May 21, 2013
- Juniper Networks Announces Date and Webcast Information for Its 2013 Annual Meeting of Stockholders May 15, 2013
- YAHOO! Japan Deploys Juniper Networks QFabric System May 14, 2013
Monthly Archives
- September 2011
- August 2011
- July 2011
- June 2011
- April 2011
- March 2011
- December 2010
- November 2010
- October 2010
- August 2010
- July 2010
- June 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- February 2009
- December 2008
- October 2007
- June 2006
Categories
- Announcements
- Book Reviews
- Data Center
- DNS
- DoS/DDoS
- Firewalls
- Hacking Tools
- High Availability
- Internet History
- Interviews
- IPv6
- Juniper
- Juniper Certifications
- MPLS
- Multicast
- Network Design
- Network Security
- Podcasts
- Presentations
- Privacy
- Routing Protocols
- Server Virtualization
- VPLS
