Are There Secrets behind the RX in SRX?

By michel.tepper posted 05-14-2014 11:58


For the fourth year, we organised “Westcon Juniper 5daagse.” During this five-day  event, where Juniper and Westcon Security presented commercial and technical news, I was given the opportunity to run a technical presentation on SRX devices.


After careful consideration, I decided not to talk about security, but about all the other features of this product line. I talked about routing and switching, features and protocols. To my surprise, much of my presentation was news for many engineers in the audience. Because of this, I decided to write this blog, as well as enlist my friend Valentijn to draw some of his famous pictures to make things even more clear.


Personally, the naming and meaning of the term SRX was a secret for a year and a half. So when I  presented, I asked the audience, “Who knows the etymology of SRX?” Turned out, I hadn’t been alone. Nobody knew! (Well, except for Dennis, in the back of the room . . . but he doesn’t quite count as he’s a Juniper SE.


The funny thing was that when I asked the question, I had a slide behind me with really huge font. I mean really really big. It read, “SRX: Security, Routing, Switching.”  So yeah, you get it, right?  



I presume many people in security are aware of what is possible regarding SRX security.  Maybe the only real “secret” on security is the powerful user-based firewalling when the SRX is connected to an Infranet controller.  Authentication on the Infranet Controller can be configured in many ways, from 802.1x authentication and captive portal to single sign-on when logging into an Active Directory server using SPNEGO/Kerberos.  For those of you who want to read more on this, see Juniper’s KB article KB24435.




But most of the secrets I want to reveal are, as I said, in the RX (Routing and Switching) functionality of the SRX.


Please note: For supported features, there is a difference between the data center models (SRX1400 to SRX5800) and the branch office models (SRX100 to SRX650). In this blog, I am speaking to that which is supported on the branch models; and may not be on their bigger brothers. But a datacentre SRX isn’t a device I would use for routing/switching anyway. You have enough routers and switching in your datacentre to do that job I suppose.  So in a data center large enough for a data center SRX, you will find less need for combining routing/switching on an SRX.



I’m rather sure everybody understands that an SRX firewall supports static routing.  So I won’t consider this as a secret. However, when talking about how to route, static routing isn’t always the best solution. I’m aware of the fact that some security engineers/architects don’t like the idea of dynamic routing on a security device. But I also know that this dislike is quite often based on fear of the unknown. Personally, I fail to see why, with a good security policy in place, it’s not safe to let an SRX participate in OSPF on internal networks. 


In any case, if you decide dynamic routing is not a problem for you, the SRX gives you an astonishing number of options. See the product specs for a complete list, but here is a short list:


MPLS/VPLS        (But not stateful, you have to bypass the flow module for this.) 


To react very fast (sub second is the new magic word) to changes in the network or interfaces going down, both unidirectional and bidirectional, you can use the BFD protocol. BFD sends very small heartbeats in short intervals. As soon as a threshold of subsequent packets is missed on either side of a connection, the upper protocol (BGP, OSPF, or even a static route) is notified. And an alternative route can be activated. A very good use case for this protocol is route-based VPNs, which are described in detail in the Juniper Ambassadors’ Day One Cookbook for Enterprise.




 With the exception of MPLS-related functions (though you can tunnel MLS over GRE), everything is supported when the device does it’s work as a stateful firewall .  But there’s a lot more to tell about the routing capabilities of the branch SRX devices. And the magic statement for that is:


set security forwarding-options family mpls mode packet-based




As strange as it may seems, this statement has nothing to do with MPLS. It places the complete device in packet-mode.  The flow module of the SRX will be completely bypassed by this statement. So no security related functions, such as stateful firewalling, IDP, UTM, NAT, etc., will be available anymore. But the routing function remains. When we look at an SRX240H2, for example, this transforms the device into basically a router with 16 Gbit Ethernet ports and four slots for all kind of interfaces. And this comes for a list price of $2999. That’s $187.50 per port, for a router with high-end protocol support.


Of course, when utilizing all ports, you’re heavily oversubscribing the device. But in stateful mode, it already supports 1,5 Gb/s, so stateless would be a lot more than that!  I didn’t find any numbers, if somebody has them, please reply to this blog. As to the number of routes you can hold on an SRX: don’t try multiple full internet routing tables. But I’ve seen an older SRX (H1) 240 with 1 GB of memory instead of 2 GB holding over 500K BGP routes.



Of course there’s much more to tell about the routing capabilities of the SRX devices. But it’s not my intention to rewrite the user manual. Rather, let’s take look at the switching part of things.

Once again, I’ll take the SRX240 as an example. With 16 ports, it’s possible to use a small switch. There’s even a model with PoE support, so that in a branch office, you can feed you wireless access points, VOIP phones directly from this SRX, which also builds the IPsec VPN to the main office.

But wait. There’s more. A lot of typical switching functionality is built in to an SRX. It’s all configured exactly the same way as on an EX switch. From 802.1x port authentication to 802.1ag OAM fault management, it’s supported in the SRX branch devices.  Moreover, so are different flavours of spanning tree protocols, LAG (802.3ad) interfaces. VLANS, inter vlan routing,  QinQ, LLDP, LLDP MED? It’s all there. Once again, take a look at system documentation to get the full picture.


A complete testlab in one device.

When I was at Juniper’s EMEA office in Amsterdam recently I met this older trainer. He told me he uses the SRX240 at home to simulate almost all the labs from courses he teaches.  And he’s right (in this matter, anyway) there is so much to do with just a bare SRX using virtual routers and tunnel interfaces by example. I studied MPLS and ISIS by creating a lot routing instances and connect them with lt interfaces in my SRX100. You can even put your testlab in a computer bag this way. Or, virtualize it with firefly perimeter (vSRX) and have it always on when your laptop is on!


So are there Secrets behind the RX in SRX? Yes there still are probably but a lot less now I hope.

1 comment



05-15-2014 06:27

Brilliant job Michael.


Very well summarised and makes sense. Been doing Juniper "pre-sales" for almost three years now and I have never looked at SRX like you have explained.


Actually, In a request today, I just proposed an SRX for the Routing.. while they had also asked for a separate device for "normal firewalling"... On average, I'd have automatically looked add them a Routing platform from a separate Product line (say J Series, now EOS or small MX).


Thank You.