Eric Stinson, Senior Product Marketing Manager, Juniper Networks

How do the New QFX5220 In-Service Software Updates Work?

Data Center
Eric Stinson Headshot
The image is of a rendering of a Juniper QFX5220 switch, so it’s a gray metal box and the end with all the ports is shown. In green at the top are the words “Junos Evolved” and then there are 28 green dots  arranged side by side, seven across and four down. There is a green box with the words “Data Store State” to the left. The Juniper Networks logo in on the switch in the upper right corner.

Data Center QoD: How do the new QFX5220 in-service software updates work?

The Juniper Networks QFX5220 Switch is a next-generation, fixed-configuration spine-and-leaf switch. It enables cloud service providers and network operators to build large, next-generation IP fabrics that support network virtualization and intelligent traffic forwarding based on proven, internet-scale technology.

We recently added an in-service software update (ISSU) to the QFX5220. In this short data center question of the day video, Juniper’s Aninda Chatterjee talks about why we made the updates and explains exactly how the new ISSU improved the capabilities of the QFX5200 data center switch.

This video has all the information you need to see how to upgrade the data center leaf switches in your data center with zero downtime. 

Show more

You’ll learn

  • How Juniper is making the upgrade as non-destructive and disruptive as possible 

  • How exactly an ISSU process works 

  • A new key term command called restart: what it does and when to use it

Who is this for?

Network Professionals Business Leaders


Eric Stinson Headshot
Eric Stinson
Senior Product Marketing Manager, Juniper Networks

Guest speakers

Aninda Chatterjee Headshot
Aninda Chatterjee
Technical Marketing Engineers, Juniper Networks


0:00 [Music]

0:09 [Music]

0:12 hi this is eric stenson with juniper's

0:14 product marketing team and today i'm

0:16 here with aninda chatterjee one of our

0:18 technical marketing engineers welcome

0:20 inda thank you eric uh and what we're

0:23 going to talk about is we've recently

0:25 added in-service software updates to the

0:27 qfx 5220 and aminda is going to

0:30 introduce that kind of why we did it and

0:32 and why it's so better than the old way

0:35 thanks eric so

0:37 yeah 50 to 20s are a really common um

0:41 leaf that we're starting to see from a

0:44 deployment perspective and typically

0:47 these data center leads you're going to

0:48 have

0:49 servers hosts connected behind them

0:52 in most common deployments these servers

0:56 would typically be dual home so that

0:58 means they're going up the two leaves

1:01 but we also

1:02 see quite often that it's just a single

1:05 leaf that is connected to these servers

1:07 right

1:08 now

1:09 from uh from the perspective of trying

1:11 to upgrade these leaves

1:14 it tends to be very intrusive if it's

1:16 just a single leaf because if you're

1:18 trying to

1:19 upgrade the os on the leaf itself

1:22 you most likely have to bring the leaf

1:24 down and the servers essentially are

1:26 disconnected from the network right this

1:28 is where issu kind of plugs in where

1:32 we're trying to do a non-destructive

1:34 update and you're not losing your

1:37 forwarding plane or the forwarding path

1:39 and all of that is retained and the

1:41 servers continue to talk

1:43 through the network while the upgrade of

1:46 the leaf is actually happening at the

1:48 same time

1:49 thanks sunindo that makes a lot of sense

1:52 so just to you know

1:55 now that we kind of know what it is and

1:57 and why we did it could you talk a

1:59 little bit about the issue process yep

2:02 absolutely so

2:04 with the 50 to 20s

2:07 we run junos evolved on the platform and

2:10 juno's evolved is architecturally a

2:12 little different from juno's

2:14 so from an architecture perspective the

2:16 daemons like the rpd

2:19 essentially run as applications

2:21 on the platform and these applications

2:24 stored their state in a distributed data

2:27 store

2:28 now the really cool thing is all of

2:30 these applications or most of these

2:32 applications are restartable and that's

2:35 the key term here we use the restart

2:38 capability of these applications and

2:41 plug that into issu to achieve a

2:44 non-disruptive update of the box itself

2:47 so when the applications restart

2:50 they go back to that distributed data

2:52 store to get their state back so it's

2:55 like a snapshot that's stored in the

2:57 data store itself which can always be

2:59 pulled back once the applications

3:02 restart

3:03 now from a command perspective it's

3:05 really simple it's just one command to

3:07 do the issue itself

3:09 but i want to call it out because it can

3:12 be a little confusing at times so

3:14 previously we would do request system in

3:17 service upgrade and that was the typical

3:18 way of doing iss you are initiating

3:21 issue on the platform itself now we've

3:24 changed that a little bit to uh plug in

3:27 this key term called restart and the

3:30 command now is going to be request

3:32 system add and this is how you do a

3:35 normal upgrade but at the end of it you

3:38 add this term called restart which

3:40 essentially tells the box that you're

3:42 restarting the applications and

3:44 initiating issue well thank you aninda

3:46 that sounds pretty simple and also

3:48 sounds like a great benefit for uh our

3:50 data center customers so i look forward

3:53 to to seeing that in action and i'm sure

3:55 that our customers do as well but thank

3:57 you very much i hope you have a great

3:59 day thank you

Show more