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

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