Juniper MAG6610 Performance Characteristics

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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:

SM160 Running 7.1r4

SA6000 Production Utilisation (Average 1500 concurrent users)

SA6000 Running 7.0r1


If anyone has any particular questions, I’ll see what I can do to help.



  1. says

    Many thanks ssl_boy. Have you ever seen high memory usage with a SM-360? A customer is reporting that their box is showing 40% memory usage with < 10 users. This does seem a bit excessive, but I will investigate in person tomorrow.

    • says

      Not had my hands on a 360 yet but 40% sounds high for a couple of thousand users, let alone a handful.  Is this swap memory or ACTUAL memory utilisation as per SNMP?

      • Steeve says

        Hi Kemp,
        We have a similar problem, that swap memory should 0 utilization, but with SNMP we received an alert that ACTUAL memory utilization is 92%

        • Glen Kemp says

          Hi, Sadly I haven’t anything to with these boxes for some time now, but I do recall something about a memory leak under some circumstances. Generic advice but I’d check the release notes for the latest build, and failing that, try support..



  2. says

    Hi Ken,

    From a design perspective to get 20k users out of a 6610 you’d need a load balancer on the outside and the boxes configured as Active/Active. However that does give you a small problem if you lost a node as you’d immediately dump 10k users.  Alternatively you can do tricks with wildcard certificates and multiple URLS & the sign-in policy (if you had a multi-tenant environment this would probably be ok).

    If you are considering anything approaching that level of concurrency I’d spend the extra $2000 and get a 6611 and consider an N+1 approach on the cards.

    You don’t necessarily need a massively sophisticated/expensive load balancer to achieve this but obviously you do need to consider the number of sessions it’ll handle.  I do have a rough prototype for a script which will “intelligently” balance users to the IVE with the lowest concurrency based upon iRules; essentially you get what you pay for.

    I do have a lingering hope (this is not based on any fact or knowledge) that there will be an on-box “solution” for load balancing at some point; potential candidates would be either Radware (existing option on MX) or a VMware on the SM161/361 cards (for example Zeus, now owned by Riverbed, doubtless there are other options)


    • Ken O'Kelly says

      Hi Glen, 
      Thanks for your response. It confirms what I suspected was the case. It seems to limit the usefulness of the MAG chassis especially as you can only cluster the units in the 6610 or 6611 and not with another 6610/6611 chassis. 

      I agree it would be great to see some inbuilt LB feature in the future, possibly on another module. I had it sketched up on the White Board today while trying to figure out the answer my self.

      I like the idea of using iRules to build some intelligence into the way the Load balancing occurs.

      Keep up the great posts.

      • says

        There is nothing at all stopping you from clustering across chassis; it’s just that clustering across WAN links is not supported anymore (although there is nothing ACTUALLY stopping you from doing it, just don’t expect JTAC to be mega pleased :)

    • says

      We’ve looked at this. You can could build 2 A/A clusters for a total of 40k users. The config can be sync’d quite easily using the push-config feature to keep in sync outside the cluster, then use an external load balanced.

Leave a Reply

Your email address will not be published. Required fields are marked *