I was asked a question by @cooperlees as to whether I’d see any real-world performance indications on the Juniper MAG 6610 Chassis. Whilst I have deployed about a dozen across the world, it’s still early days to definitively nail this down, but I’d thought I’d share what I can and provide some anecdotes as to what I’ve seen in the real world.
So, in no special order:
- The MAG 6610 Chassis contains no latent processing power, none that you can use anyway. The processing comes from the option cards deployed, either the SM160 or SM360 cards in the context of SSL VPN. Each card is rated at either 1,000 concurrent users or 10,000 concurrent users; two cards can be fitted in a MAG6610, and four can be fitted in the MAG6611.
- To some extent the chassis is irrelevant – it provides a power bus and that’s about it – so I’ll focus on the cards themselves. The SM160 can be considered the equivalent to the old SA4500 chassis, whilst the SM360 can be considered the replacement for the SA6500.
- Juniper have traditionally sold on the basis that each appliance can adequately cope with the maximum license user count (i.e. 1,000/10,000 concurrent users) per blade.
- The only real exception to this was that the old SA4500 had an optional “Cryptographic Module”, an SSL offload card. I’d never seen any hard and fast details on when this was necessary (it was installed as standard on the SA6500 and is included in the SM360). Given that this wasn’t a particularly expensive as an option (~990USD), I always included this as standard in most of my designs. Anecdotal – systems with this card seemed to have lower latency; this was noticeable applications such as Citrix and Terminal Services.
- What mix of applications/access methods you use is going to impact the processor & load on the box. Dynamic content rewriting is going to have a more of a CPU impact than just port tunnel via SAM. The truth of the matter is that the bulk of your transactions are likely to be Network Connect or its prettier sister, Pulse. In both cases this will involve relatively straightforward tunnelling with little or no additional work other than encryption/decryption once the session is established.
- In reality, I’ve never seen any SA in a production environment which genuinely has a CPU issue, usually other factors (such as available internet bandwidth, firewall’s ability to handle a huge number of sessions) trouble the environment before the CPU becomes the bottleneck.
- I find the scalability of the boxes is pretty predictable. Below are some graphs taken from a MAG6611 with a SM160 Blade running 7.1r4 and a SA6000 running 7.0r1. Despite the differences, the graphs show pretty much the same result.
- The other thing that this shows is the bandwidth utilisation. My general rule of thumb is that you should expect 1 megabit of traffic for every 100 concurrent authenticated users. This is obviously going to depend on what your users are up to on the network. Also worth noting that the “Internal in” figure is higher than the “External out” figure, this does at least show the internal software compression is reasonable effective given that it is a “free” feature.
And now, the pretty pictures: SM160 Production Utilisation:
SA6000 Production Utilisation (Average 1500 concurrent users)
If anyone has any particular questions, I’ll see what I can do to help.