As some readers may note I have been using Juniper’s SRX-110 for my home firewall for some time. It is a very cool piece of kit and an extremely flexible, dynamic, and feature rich. In June, Brad Woodberg and Rob Cameron released the SRX bible. Juniper SRX Series by O’Reilly press is over 1000 pages of tasty, richly written, architectural and functional deep dive into the security platform. I was extremely keen to get my hands on this book well before it was scheduled to be published.
This book follows in the same pedigree of which the Juniper MX series book comes from. A reference book which proves invaluable to engineers, architects, and solution engineers. What is great in Juniper books is that there is a topology defined from the outset. This point of reference allows readers to follow along with the authors. It also enables those with access to similar or the same hardware to actually bring up the labs. I have found it hard with some Cisco Press books to get my mind to quickly adapt to new topologies quickly when in learning mode. This also leads to the point that I really like the diagrams, the fonts and the outlay of the examples. Clear and easy to read is something that I really appreciate.
The technical breadth is phenomenal. Like the MX Series book, the SRX Series is just as superb. The hardware breakdowns give insight into product placement, function, and role with the reasons why behind the models hardware minimums and maximums. If you’re a firewall focused engineer or someone who needs to work on an SRX this is for you. No matter if you’re running a branch SRX or DC SRX you will find what you need. UTM, VPN, Security Zones, Policies, Module compatibility – it’s all there.
One of the highlights of this book is the Best Practice section. Each topic covered or technology that is discussed in the book has a Best practices section. A book alone could be published with just the best practices as they are useful for anyone deploying the platform. Juniper does not have the equivalent of Cisco SRND so these tips are invaluable. It explains Some of the best come around my weaker areas. IPsec VPNs and UTM. For example, it is best to use main mode under IKE1 due to the fact identity information isn’t obfuscated.
After being enlightened recently under the doctrine of Ed Horley, I am becoming slowly more aggressive of the ignorance of IPv6 by many people. The book unfortunately misses a dedicated chapter on this. Although IPv6 appears here and there – the NAT and IPsec chapters mainly – the term IPv6 is only found on 69 pages. I’d love to know in detail how the SRX handles v6 packets, what impact it has on hardware TCAM and other modules, and the SRXs place in v6-only networks. I could be a little harsh in raising this point though it is becoming a personal bug bear of mine lately.
If you work on an SRX or are interested in the SRX then this book is for you. This book is waiting to be devoured. The content in this book is designed to complement Juniper Security book from a few years back. Armed with this book you have a superb firewall reference book to aid you when designing your next internet edge, DMZ, or national branch deployment.
Disclaimer – In my dealings Johnny Konstantas and Ashton Bothman, I was asked if I would be interested in reviewing this book back in May. With a delay in getting copies (due to demand I hope) I received a hardcopy of the book in late July. I was asked to consider a blog on the book with my thoughts. My overall disclaimer is listed here. Thank you for considering me Juniper.
Hi Anthony,
Thank you very much for your review and passion for Juniper! I did want to make one mention regarding the decision not to make IPv6 it’s own chapter. Rob and I thought hard about it, and came the decision to integrate it into the respective feature chapters rather than making it it’s own chapter for two reasons. First, because we felt that IPv6 should no longer be treated as a separate entity but something that is part of every feature’s DNA. Second, because IPv6 is not processed any differently than IPv4, with the exception of the fact that it counts as 2 IPv4 sessions in the various cache locations (NPU, SPU, CP, and FWDD on branch) for FW features. Meaning that if you have a platform that supports 1M IPv4 FW sessions, it could do 500k IPv6 sessions or 500k IPv4 sessions w/250k IPv6 sessions &c. L7 features like IPS are a bit different in the SPU’s because they are very dynamic and the address length is negligible compared to the other state metadata that must be tracked.
Really NAT is the largest area for IPv6 because of the conversion, there’s really nothing special about IPv6 in most of the other features like Policy, which we did cover the policy in NAT as well. Some IPv6 is still being rolled out and is noted as current limitations, but stay tuned to the release notes because that will be changing very soon!
I’d be happy to do an online chapter or something like that if there’s enough need to warrant it, definitely want the readers to be fully equipped!
Best Regards,
Brad Woodberg
Hi Brad,
First of all, Thank you for the comments. It is great to see the authors engaged with the community. You guys have made a great resource and something I use a lot.
I think that the IPv6 in the book is great and I may of had my ‘aggressive’ hat on whilst writing the review. I can understand the idea of integrating across the the book opposed to a standalone chapter – maybe I felt there needed to be a little more?
Thanks for that session information regarding IPv4 and v6. Super handy to know. I’d like to think in 4-5 years time that books will have a few IPv4 references and be predominately IPv6!
From your experience with dealings of those in the field, what is the appetite like for those using the SRX in a IPv6 environment?
Thank for the prompt reply.
Anthony Burke.
Hi Anthony,
More than happy to be involved, I simply love the technology myself and it happens to be a hobby of mine as well. We have had IPv6 in the SRX starting in 10.2, and it was immediately deployed by many of our largest service providers with names you would know doubt know, and also many government customers that needed to support it. That was 3 years ago, and we have steadily filled in the blanks with various feature support. Enterprises have been deploying this feature world-wide, but to be honest, like the global adoption of IPv6 it has still been in slower than most folks would expect given that IPv4 is largely exhausted from a Tier 1 perceptive.
I can say that going forward with feature development, we are working hard to close any gaps that we have, and with new features that we introduce they will be IPv6 capable so that we don’t introduce any new gaps. The main two areas where we are still slightly behind is IPSec and UTM, just about every other feature has full IPv6 support. The good news is that we are closing these gaps quickly–though i can’t say on a public non-NDA forum when, keep posted to the release notes, or even better, get in touch with your Juniper SE and participate in our beta programs for early access! We’d love to get your feedback, and it’s great to get an early glimpse and opportunity to work more closely with the Juniper engineering team to share your thoughts.
Feel free to reach out anytime.
Best Regards,
Brad