Understand Junos High Availability Operations

0:00Welcome to the content on understanding high availability techniques for your Juniper devices.

0:06Now this content is applicable to both Juniper switches, routers, and well let's go ahead and

0:11throw firewalls in there. So not both but all three of those things. This is really the Junos

0:16operating system. But the Juniper, their JNCIA DC exam blueprint really gives you four different

0:23kinds of high availability and techniques that you can use. Now high availability comes in a bunch

0:29of different shapes and sizes and it's used for a bunch of different well techniques or a bunch of

0:35different reasons. Things that you want to prevent against failure. So we're going to talk about all

0:41of those. The JNCIA DC also wants you to know how to configure three of those four techniques.

0:48So we're going to cover that as well but I am going to tell you a little bit more about the

0:52fourth one as well. I actually have a lot of experience in that fourth one. So without

0:58further ado, let's talk about some of the most important things that you as a network engineer do

1:03with your Juniper devices and this is configuring things that really hedge against failures in the

1:11data center. Let's go.

0:00Let's talk about what high availability,

0:03very frequently abbreviated to HA, is.

0:07And if you're in the systems world already,

0:10you may have seen something called HADR,

0:14and that sets up an even bigger topic.

0:16What is high availability

0:18and what isn't high availability?

0:21What is it not?

0:22Let's think about what the basic concept

0:24of high availability is.

0:26The idea is we have some sort of system,

0:29or some sort of networking device like a router,

0:33or really anything technical at all.

0:35And if a piece or a component of it fails

0:39or goes down for any reason,

0:42there are some expectations with high availability.

0:45One, redundancy already exists.

0:51Redundancy is already in place.

0:55Two, this is really important one,

0:58failure is automatic or failover is automatic.

1:03Let me go ahead and change that a little bit

1:04to be failover is automatic,

1:09meaning it doesn't require some human to intercede

1:12and make a change to the configuration to keep it running.

1:15And three, impact is near zero.

1:24The idea here ultimately is that the end user

1:27who is consuming something on your network

1:30sees nothing, feels nothing.

1:33They have the exact same experience using the application

1:36before and after some component failure.

1:40Now, what could these component failures be,

1:42especially in the networking context?

1:45This could be a link failure,

1:49meaning the fiber got cut.

1:51We see that one a lot, don't we?

1:53The fiber got cut.

1:55Two, it could be the port died.

2:00This usually happens on SFPs,

2:04you know, small form factor pluggables,

2:06things that go into the switch.

2:08Switches these days, if you haven't seen,

2:09let's just pause and talk about this for a second.

2:12Sometimes they kind of look like this EX4100

2:15you see on the screen.

2:16And right here, we see RJ45 ports

2:20going across the whole switch.

2:23But then right here on this section,

2:26we see these blank holes.

2:28What is this all about?

2:30These are the small form factor pluggables.

2:32And the idea here is you can bring your own networking port

2:37and slot it in right there.

2:39Sometimes we just use more RJ45 ports.

2:43That's true.

2:44I mean, we can actually just put in more copper ports.

2:47These also, let's go ahead and say this too.

2:48These could be make something up.

2:50These could all be one gigabit per second ports right here.

2:54And we can slot in 10 gigabit per second RJ45 ports

2:59in these SFPs.

3:01But we can also put fiber ports in here.

3:04The fiber mechanism that, you know,

3:06receives light waves and transmitters and everything

3:10and decodes that, all of that is contained

3:13in like basically a little stick

3:15that you just plug in right there.

3:17And I have this exact same setup in my rack

3:21in my own business right now,

3:22where we're using copper to talk to our servers,

3:26our servers connecting using copper,

3:28and then to connect between switches

3:31or even out to the internet,

3:32we use the SFPs and use fiber.

3:35All of that is to say these SFPs break.

3:40I mean, they break, you know, not a lot,

3:42but it's not a crazy stretch to think

3:44that out of the eight ports that you see right there,

3:47one of them is going to die in the next 12 months.

3:51They get really, really, really hot.

3:53They can consume a lot of electricity

3:55and that just degrades equipment over time.

3:59So if this is connecting in to say a server

4:03that's hosting our website, we want the end user.

4:07If this SFP dies,

4:09we want the end user to not know that it died.

4:13So we're basically saying, you know,

4:15the link gets cut, the SFP or port dies,

4:21but what else is there?

4:23There's actually the software itself.

4:25And I'll say, I haven't really encountered this

4:28too much out there in the open world, but it can happen.

4:31When we say this, you know,

4:33if we really think about it, what is Junos?

4:35Junos is software built on top of free BSD,

4:39which is a lot like a Unix or Linux operating system

4:44at the end of the day.

4:45And like anything that goes on on an operating system,

4:48it's subject to fail.

4:50Applications crash.

4:51And in this case, Junos can crash

4:54or specifically just the routing process.

4:58Specifically, they call these routing daemons

5:01or maybe demons, depending on, you know, your point of view.

5:05Those things can crash, absolutely.

5:08And then of course, the last one that's kind of out there

5:10and you don't really think about this as a failure,

5:12but it's out there, maintenance.

5:15I mean, what happens when we have to patch the software

5:18on a Juniper switch and we take the switch down

5:21because it has to reboot?

5:23What happens to all that traffic

5:25that was flowing through the switch?

5:26Well, it's kind of the idea.

5:29So we flow back to the three things

5:31that we really expect out of high availability.

5:35We have more than one device and more than one link

5:39ready to service this traffic at all time.

5:43That is the redundancy piece of the puzzle.

5:48We can have multiple switches.

5:50We can have multiple links.

5:51We can have multiple links between multiple switches.

5:55That way there are multiple paths to get

5:57from point A to point Z.

5:59And one doesn't necessarily cost more than the other.

6:01It's redundant.

6:03Secondly, what was the second thing?

6:05It was automatic failover.

6:07This is where the protocols come in.

6:10When we have the redundant links in place,

6:13we then have to tell the Juniper operating systems,

6:16hey, these are redundant links

6:19and you should start monitoring their redundancy.

6:22And in the event that one goes down,

6:24you should fail over very, very quickly,

6:27such that number three, there is near zero impact

6:33to the end user, to the application, to the service itself.

6:39Now, Juniper breaks down four main failover

6:43and high availability mechanisms

6:45that they want you to know on this exam.

6:47And that is what we're going to talk about.

6:49We have a link aggregation group.

6:53That is what it is called

6:54when we have multiple links between devices,

6:57between single devices.

6:59So if I had a router here and a router here,

7:01we can draw the little arrows like so.

7:04We've got two links between them

7:06and we can bundle these two links together

7:08into a link aggregation group.

7:10This is specifically using a protocol called LACP.

7:14We have graceful restart.

7:16Okay, so what does this protect against?

7:18This protects against link failure, okay?

7:20Next we have graceful restart.

7:23This keeps forwarding traffic

7:28even when the software wants to stop forwarding traffic.

7:33Maybe the routing daemon resets

7:35or has to reload or something.

7:38Graceful restart will keep forwarding traffic

7:40with the existing forwarding table

7:42until it's ready to get back,

7:46the routing daemon is ready to get back up and running.

7:49We have bidirectional forwarding detection,

7:51which is a rapid failover protocol

7:54specifically used by routing protocols like OSPF and BGP.

7:59More on that to come.

8:00And then we have virtual chassis.

8:05This is where we bundle a bunch of switches together

8:08and make them believe they're one gigantic switch.

8:11So in the event that one switch fails,

8:15then there's multiple switches in the chassis

8:18that can just keep forwarding the traffic.

8:21The exam wants you to understand all four of these,

8:24but know how to configure lag, graceful restart,

8:29and bidirectional forwarding detection.

8:32Now, what is high availability not?

8:37It is not disaster recovery.

8:41Now, it is something that will help you

8:43in the event of a disaster, in the event of a failure.

8:47But the idea with disaster recovery

8:49is that it is all about catastrophic failovers.

8:53This is usually when we're talking

8:54about geographic natural disasters,

8:58tornadoes, hurricanes, floods, riots,

9:02anything that can really, really, really

9:04disrupt an entire region.

9:06How do we get our services back online quickly

9:11after they are completely offline?

9:13How do we recover from a true disaster?

9:16That's what disaster recovery is all about.

9:18This is where you start invoking your systems teams a lot,

9:21like we got to get to the backups

9:23and bring our VMs back to life

9:26in the cloud or something like that.

9:29So this is what we're talking about

9:31when we talk about high availability.

9:33And now we kind of have an idea as to why it exists

9:36and what are the protocols that we're going to learn about

9:38when we use Junos.

0:01Next up, we're going to begin by talking about one of the biggest high availability protocols that you'll ever run into.

0:07This is an open standard protocol, so that means it will work between a Juniper device and a Cisco device.

0:14If, say, we have a Cisco router right here and a, let's call it a Juniper router right here, guess what?

0:24We can put a second link between them and use link aggregation control protocol on both of these to form a link aggregation group or a LAG for short.

0:38So, this is one of the things that right immediately we're talking about terminology.

0:42And a lot of times you'll see people kind of confuse, not necessarily wrongly, but confuse a LAG with the actual protocol itself, LACP.

0:52LACP creates a LAG.

0:55This standard protocol is also very frequently known as 802.3ad.

1:03So, don't be surprised when you do create an 802.3ad LAG on a Juniper device.

1:11You'll see people just refer to it as 802.3ad.

1:15So, what does it do?

1:16802.3ad is we go in and we say this port right here and this port right here belongs to an ether channel on Juniper devices.

1:32That way it knows, oh, okay, this is going to be some form of LAG.

1:36And we'll tell it specifically use 802.3ad and or L, I got to write this better, LACP.

1:47Very cool.

1:48When we put these two ports into a bundle, they form one logical LAG port that we can put our configurations on.

1:58Because ultimately we want them to act the exact same way.

2:02We want them to pass the same traffic.

2:04So, Juniper will create a virtual interface that encompasses the two underlying physical interfaces.

2:12In Juniper devices, you'll see these written as A, E, and then some number.

2:18So, our first LAG port will be A, E, 0.

2:22If we created another LAG with two different ports, it'll be A, E, 1.

2:27And just like we do with 10 gig interfaces or gigabit interfaces or so on, we'll create the logical subunits of them to do things like the regular switching configuration or the IPv4 configuration.

2:43So, you'll see A, E, 0, unit 1 or A, E, 1, unit 1.

2:52And, of course, we can abbreviate these A, E, 0.0, A, E, 1.1.

2:59I wrote 0 here.

3:00I should have written 1.

3:01A, E, 0.1, A, E, 1.1, and so on and so on and so on.

3:05So, you could have as many logical subunits as you desire or need to configure just like you do physical interfaces.

3:12The configuration works almost the exact same with an A, E interface as you do the physical interfaces.

3:20So, the cool thing about this is when we configure this, of course, that will be reflected on the underlying physical ports, and they'll behave the same way.

3:28Now, 802.3ad, the ultimate purpose of this, of course, is if one of these ports or the cable itself goes down for any reason, we have a second port that can carry all of the traffic.

3:42Now, what's one of the cool things about this is lag can be configured such that, by default, it actually does load balancing.

3:52So, we don't necessarily have an active standby situation here where one link is just hot and carrying all the traffic and the other one does nothing.

4:00No, we can actually load balance this traffic across both links, and I'm not going to say double our bandwidth because that's not necessarily true,

4:09but we're just enabled to carry more traffic than we were before over both links.

4:16That being said, you don't want to get too accustomed to it because, again, the entire point really is that one of these links die and we can continue to carry all of our traffic over just one link.

4:28So, how does it work?

4:29Well, by default, kind of like OSPF, when we turn EtherChannel on with an 802.3ad and LACP configuration, it begins sending kind of like hello packets, except for specifically they call them, let me get my pen back here, LACPDUs.

4:52It says Link Aggregation Control Protocol Data Units, and they are sent also kind of like OSPF, how OSPF sends hello packets to a specific multicast address.

5:04LACPDUs go to a specific MAC address that the other machine will be configured to listen on whenever we turn on 802.3ad.

5:15The MAC address it goes to is 01, colon, 80, colon, C2, colon, 00, colon, 00, colon, 02.

5:31So, this is going to send an LACPDU towards this interface destined for this MAC address.

5:40As long as this interface right here is configured for LACP, it will be listening on that MAC address and it will realize, oh, wait, I can form an LACP neighbor adjacency.

5:55I can form a LAG here.

5:58An LACPDU then contains four important bits of information that the machines need to figure out if they really do belong in a bundle together.

6:07They have the system ID, the port ID, they have what's known as a key, and then they have what's called state flags.

6:21Basically, is this thing up, is it active, is it passive, and so on.

6:26Based on how we configure LACP, these two machines are trying to figure out if they actually do belong in the same Ether channel bundle, if they do belong in the same LAG.

6:39Really, the big thing right there that makes that match is the key.

6:44Ultimately, when these two devices link up together, they're going to try and figure out if we have the same speed, the same duplex, and the same key.

6:56If the answer is yes to these, it's likely that our LAG is going to form successfully.

7:02Now, there's another thing that goes on here that we need to talk about, and that is called port state.

7:08When we configure LAG on these ports, we can configure this as an active port, meaning it is going to aggressively try to send out these LACPDUs and try to initiate the formation of a LAG, or opposite of that, we can set this to be passive.

7:29It is not going to aggressively send out LACPDUs, it is going to wait for a peer to form an adjacency to it.

7:37If we set all of these ports to be passive, it would be known as passive, passive, meaning both routers were configured to passive, and an adjacency will never form.

7:50An adjacency will only form if we have active active or active passive.

7:58That's the only time an adjacency will be formed.

8:01And then, of course, speed, duplex, and key have to match from there.

8:05Juniper's recommendation is to always configure your interfaces as active.

8:12Now, once these things all match, we've discovered our neighbor, we've got the right speed, duplex, and key, we had at least an active passive configuration, and the LAG then forms.

8:26What happens next?

8:28Well, it's time to start sending traffic over the LAG.

8:32And, like I said, it can be load balanced.

8:35But it's not load balanced using something like a round robin, or something like that.

8:41Instead, it uses an LACP hashing algorithm.

8:46Now, I'll tell you right now, the hashing algorithm is a pretty commonly seen 5-tuple structure.

8:54And when I say it's a commonly seen 5-tuple structure, it's actually something that you see a lot on firewalls.

9:01What it's going to do is it's going to take the source IP address, the destination IP address, the source MAC address, the destination MAC address, and then, very frequently, the layer 4 port information, or transport protocol that it's being used here.

9:26And it will take these 5 inputs and generate some form of a hash.

9:30I'll just put A, B, C, 0, 1, 2, as a made-up hash.

9:36And once this traffic flow has been recognized, and we've got this hash right here, that hash will be assigned to, say, this link.

9:45Then, an entirely different flow of traffic will come in, with a source IP, a destination IP, a source MAC, a destination MAC, and a port, and it'll flow over this link instead.

9:57Now, why I say it's not necessarily equal load balancing?

10:02This traffic could simply consume more traffic than, well, this flow right here.

10:10This flow could just be being used more than the secondary flow.

10:15Therefore, this link right here could be being used more than this link right here.

10:20The good news is that the traffic will still be distributed somewhat, so that not all traffic is just flowing over one link.

10:28It's going to be spread out over both of these links.

10:32Now, I'm also going to say this right now.

10:34Out of the four protocols that you learn about when it comes to high availability, LACP, in my opinion, is probably the most in-depth, most complicated one.

10:43So, if you've got to watch this video a couple times, just like, wait, what did he say about these things and those things, that's totally fine.

10:51It can take a few times to really get it, and it's the one that you're probably going to encounter the most throughout your networking career.

11:00So, it's a really important one to get.

11:02Now, in the next video, we're going to jump on the command line and actually start configuring LACP.

0:00Now, of course, comes the fun part where we actually make it come to life.

0:04And of course, well, not of course, but lots of times the making it come to life part

0:08is a lot easier to do than just understanding the concepts.

0:12Here we've got VQ-FX 1 and VQ-FX 2.

0:18Let's say I want to configure a new bundle of lag interfaces right here between the two of these.

0:25Using my little emulation application, Even-G, I'll create a second link between them.

0:31And we'll say, let's put this at the very tail end of our interfaces.

0:35Let's use 8 and 9.

0:37So I'll use 10G08 on both sides and save.

0:44And it makes the link come to life.

0:46And now I'll also put 10G09 on both sides and save.

0:56So now I've got two active links between the two of these.

1:00There's been no configuration put in place.

1:03Let's do that.

1:03Let's put a configuration in place.

1:06So I'll jump over here to my terminal on VQ-FX 1.

1:10We can kind of zoom in a little bit more if we really try to.

1:14And what I'm going to do is I'm going to move into edit mode.

1:17Then what I'm going to do is I'm going to move into edit interfaces and we'll do 10G08.

1:24In fact, you know what?

1:24I'm not.

1:24I'm just going to do edit interfaces.

1:27I'm going to do set 10G08, but I'm not going to use a logical subunit here because I am

1:36trying to configure the physical interface itself to be in the bundle.

1:41And then once we have the AE interface, we'll make all the logical configurations there.

1:47So I'm going to do set 10G08 ether options.

1:53And then, like I said, we're going to say 802.3ad is the option that we're going to enable.

2:01And then we tell it what logical aggregated ethernet interface it belongs to.

2:07Since I don't have any other lags on this particular device, I'll start with the first

2:12one, AE0.

2:14I press enter here and that configuration takes place.

2:18Now, just for good measure, I'm going to do show 10G08 and I do see it has a unit zero

2:26already configured here.

2:27I'm going to make sure I get rid of that just so that there's only the ether options

2:35configuration in place.

2:36So I gave it a delete 10G08 unit zero.

2:41So that's not going to delete 10G08.

2:43That's going to delete unit zero and everything underneath it.

2:48So if I say show XC008, now all I see are my ether options configuration.

2:56Let's do show 10G009 for good measure.

2:59And I see a unit zero there.

3:01So I'm going to delete 10G009 unit zero and then set 10G009 and we said ether options

3:11802.3ad in AE0.

3:14So now if I do show 10G008, we see the ether options putting it in a 802.3ad lag.

3:22Oh, I hit, I dragged and it messed up there.

3:25It shows it in the 802.3ad lag in an interface called AE0.

3:30And if I press up a few times to do the show command, we'll change it to nine and confirm

3:36it looks the exact same way.

3:38Awesome.

3:39So when I commit this, there's going to be an AE0 interface and that AE0 interface won't

3:46be configured.

3:47So what I need to do now is set AE0 and configure its options.

3:53We can look at aggregated ether options and we tell it for LACP, you will be active.

4:01We press enter here.

4:03So that configures AE0 to use LACP's active mode.

4:10We'll also make sure this is a switch port, or at least the bundle is a switch port.

4:15So we'll set AE0 unit zero to have a family of ethernet switching, just like that.

4:24So now when I do show AE0, we see that under aggregated ether options specifically for

4:31the LACP protocol, it's going to be in active mode and unit zero is going to be making the

4:38logical bundle of interfaces, a switch port instead of a routed interface.

4:43Again, we can do show 10 gig 008 and 10 gig 009, and we can see what physical ports make

4:51up AE0 this way.

4:53Now let's do it on the other switch.

4:56Jumping back here, I'll bring up the spine.

4:58We'll launch the iTerm and it comes to life here.

5:02Let's make the font nice and big so that we can see it and I'll give it the exact same

5:09configuration.

5:10I'll move a little bit quicker this time.

5:11I'll move into interfaces.

5:13We're going to delete 10 gig 008 unit zero, unit zero.

5:20We'll also do the same for 10 gig 009.

5:24We'll set 10 gig 008, ether options, 802.3ad and part of AE0 because this switch also doesn't

5:36have an AE0 or a lag or a bundle yet.

5:39So we can use AE0 on this.

5:41We'll do the exact same thing for 10 gig 009.

5:45We'll set AE0, aggregated ether options, LACP in active mode, and we'll set AE0's unit zero

5:57in family ethernet switching.

6:00So at this point, we've done the exact same configuration on both sides.

6:0410 gig 008 and 009 connect to their respective partners.

6:09They're configured to be in 802.3ad bundle creating the logical interface AE0.

6:17Then we told AE0 that you need to have active mode LACP and that you're a switch port or

6:23really a bundle of switch ports.

6:25We'll give it a commit and quit on both sides.

6:28I'll go ahead and just kind of minimize this one.

6:31Let's bring that terminal back up.

6:34Whoops, there was just a tab across the top I had to do.

6:36Let's give this a commit and quit on VQFX1.

6:41And we should have the successful commit operation in place.

6:46The configuration is now complete.

6:48So how do we check to make sure it works?

6:51Let's first do show interfaces AE0 right here.

6:57And we see AE0 is not there on either device.

7:01What's this all about?

7:02This is one of the most classic Junos gotchas you will ever run into.

7:07One of the most interesting things about this is that we have logically created AE0 out

7:14of thin air and Juniper won't actually recognize that until we carve out this interface.

7:22We have to tell Junos in the configuration we plan to use aggregated Ethernet interfaces

7:30up front.

7:32So watch this.

7:32I'm going to go back into configuration mode and we're going to change the chassis to use

7:39aggregated interfaces.

7:41Let's do set chassis aggregated devices for Ethernet.

7:47And then we say the device count will be one because we're only using one lag right here.

7:54This will create an AE0 interface.

7:58If I set the device count to two, that would create an AE0 and an AE1.

8:05Three would create AE0, one, and two, and so on and so on and so on.

8:10So I'll give this a commit and quit.

8:12We'll do the same thing over here on the spine.

8:16Edit set chassis aggregated devices Ethernet device count one commit and quit.

8:25Now that we've actually carved out an aggregated Ethernet interface in the chassis itself,

8:34then configured the physical interfaces to be in that, then configured the logical interface

8:39as well as to use LACP active.

8:41Now when we do show interfaces AE0, ah, now we actually see our interfaces up.

8:47We see packets coming in, we see the amount of data coming in, and that is a great sign.

8:53We can also do show LACP interfaces like this, and it actually tells us not only what

9:01our current actor interfaces are, but also what our partner's remote interfaces are.

9:08We see that we're currently using the LACP protocol.

9:11That's great.

9:12And beyond that, we can do show LACP.

9:14You could actually use question mark right here.

9:16One of the next big ones you want to use is statistics just to validate.

9:21Statistics question mark right there.

9:23And then take a look at what's going on on the interfaces themselves.

9:26You can actually see how many LACP received DUs have we seen and how many have we transmitted

9:34ourselves.

9:35So now we've configured and confirmed LACP is up and running.

0:00Next up, we're going to talk about Juniper's Graceful Restart.

0:03And while I'm sure there are competitor tools that do something similar,

0:08I haven't really run into it because I think it's really, really cool.

0:11So let's talk about what it does here for a second.

0:15Let's say we have three routers that are all running OSPF and are connected to each other.

0:22Let's say they're all Juniper routers and they're all configured with Graceful Restart.

0:27The idea with Graceful Restart, and remember with Juniper devices,

0:31is that the control plane is separate from the data plane.

0:36The control plane decides, it uses software, it uses routing protocols,

0:41to decide what routes should exist.

0:45The data plane or the forwarding table says,

0:48if traffic comes in on this interface destined for some other interface,

0:53exit out that this other interface.

0:56It's as simple as, if it's going to this destination, it exits out this interface.

1:02Obviously, the forwarding table comes from the learned routes.

1:07The routing, the control plane and the route table is calculated,

1:11you know, using OSPF and the Dijkstra algorithm and BGP and so on.

1:15And that derives the forwarding table, which just says,

1:19exit this traffic out this interface.

1:21These two can exist separately from each other.

1:24And lots of times they do, in the event of maintenance,

1:29or in the event of some form of control plane failure,

1:34or, you know, routing process gets restarted.

1:37The routing process or OSPF process or anything.

1:41So for whatever reason, if the control plane goes offline,

1:45the data plane keeps working and keeps forwarding.

1:48But this is where it gets really interesting.

1:50There's also introducing the concept of a helper.

1:55The helper will keep its buddy's routing table

2:01and forwarding plane in its memory for a given time.

2:06So that traffic can keep going through the process like so.

2:12And when this comes up,

2:15the helper can remind the neighbor what its routes were.

2:21So the helper basically keeps a copy

2:24of its neighbor's control plane,

2:27so that when the neighbor's control plane recovers,

2:30the helper can get it right back up to speed

2:32as quickly as possible.

2:34And again, because the data plane

2:36stayed online the whole time,

2:38traffic keeps getting forwarded as normal.

2:42So this is called graceful restart,

2:44because it gracefully keeps forwarding traffic

2:48while the control plane more or less gets its act together.

2:53And the introduction of the helper neighbor router

2:57that keeps a copy of its neighbor's routes

3:00ready to rock and roll for when it recovers

3:03is a really, really cool idea

3:05and a really, really cool factor.

3:07So now let's jump in

3:09and see what it's like to configure graceful restart.

0:00Graceful Restart is a relatively simple thing to configure because there's basically only two commands that you need to know.

0:06First of all, we need to tell Graceful Restart that it needs to be on.

0:10So we'll go into edit mode and we'll do Set Routing Options

0:15Graceful Restart. Press Enter and that's it. That's it for turning it on.

0:20But then we really wanted to know that certain routing protocols are constantly changing the control plane and they need to be

0:29advertised or at least we need to leverage that routing protocol to advertise that we are a Graceful Restart router.

0:36And we can also start finding our helpers that way. So we can turn it on for say OSPF.

0:43Let's do Set Protocols

0:45OSPF Graceful Restart and that's it. That's all there is to configuring Graceful Restart.

0:51I'll give it a commit and quit. I'll jump over to a neighboring router. We'll do Edit, Set Routing Options.

0:59Graceful Restart. Set Protocols. OSPF. Graceful Restart. Commit. Oh, oh

1:06And I see it wants actually more information.

1:09So if I do Set Protocols OSPF Graceful Restart

1:12It wants to know how to use Graceful Restart. If I give it a question mark right here, we can tell it these things.

1:20So one of the interesting things is because we set in routing options to be a Graceful Restart router

1:26It's automatically going to advertise this in OSPF and automatically try to be a helper.

1:31We can disable Graceful Restart from OSPF specifically entirely right now.

1:37We can also tell it just don't be a helper.

1:41We can also update the timers for any reason like when do we notify everyone of a Graceful Restart access or

1:50when do we actually say our neighbors must not be a Graceful Restart router anymore.

1:55So I don't actually need to change anything in Set Protocols OSPF Graceful Restart to actually make it be a Graceful Restart router.

2:02We can just commit and quit this as it is right now.

2:06So at this point we've enabled Graceful Restart.

2:10A couple key things that I would look for to confirm this is in Show Route Summary.

2:15We see that we are restart completed for both our IPv4 route table and our IPv6 route table.

2:24Also, if I look in Show OSPF Overview, scroll down just a hair, we see we've got Restart Enabled and our restart timers as well as our Graceful Restart helper modes.

2:40So these are two different ways that we can confirm that Graceful Restart has now been enabled on this router.

0:01Bidirectional forwarding detection is a big deal.

0:07So what does it do?

0:09This is a independent protocol designed

0:12to be incredibly lightweight

0:15and detect a failure very, very rapidly.

0:18Let's think about OSPF for a second.

0:21If I have routers right here

0:23and they've got a link between them

0:25and they're both configured to OSPF,

0:27do you remember what the timers were?

0:29What was a hello packet timer?

0:32A hello is sent by default every 10 seconds.

0:36And when we miss four hellos in a row,

0:39the dead timer has expired and we declare our neighbor dead.

0:44That means 40 seconds, 40 whole seconds pass by default

0:51before we detect that an OSPF neighbor has gone down.

0:55Here's a little tidbit for you.

0:57We didn't really cover this

0:58because BGP is pretty extensive.

1:00The BGP hold timer, kind of the same thing as a dead timer,

1:04180 seconds or three whole minutes can go down

1:11before we actually detect a failure.

1:14Bidirectional forwarding detection is a separate protocol

1:17that is just designed to do nothing more

1:20than to detect a neighbor adjacency going down

1:24and then send a signal to the routing protocol of choice

1:31that BFD has detected that the neighbor goes down.

1:35So OSPF can use BFD rather than its default dead timers

1:43or hello timers and dead timers and BGP can use BFD.

1:47How quick are we talking about here?

1:50Milliseconds.

1:52When we configure BFD, it really is a function,

1:56it's really a very basic mathematical equation.

1:59We are trying to detect when a neighbor fails.

2:03So we call this the detection time

2:09and it equals our minimum interval,

2:14which is how frequently do we send the BFD packet

2:18times a multiplier.

2:20How many times do you wanna check?

2:22Usually by default with BFD,

2:25we're gonna call it a hello packet, it's not what it is.

2:28We send a BFD hello packet every 300 milliseconds

2:36and we usually set our check to be three times,

2:40meaning we can detect a link failure

2:44and declare a neighbor dead in 900 milliseconds,

2:49less than one second.

2:51Compare that again to OSPF's dead timer of 40 seconds

2:57and BGP's hold timer of 180 seconds.

3:02So what really happens under the hood?

3:04Well, BFD is a protocol.

3:07So when we have our two routers yet again, like so,

3:12what's really happening here?

3:15Just like how we have OSPF establish a neighbor adjacency,

3:19we will establish a BFD adjacency.

3:22Really we call this the BFD session

3:25and things need to match on both sides.

3:28We need to agree really on our timers,

3:31which is that minimum interval

3:38and of course the multiplier.

3:40When do we declare our neighbor dead?

3:42That's really it that needs to match on both sides

3:45to make a BFD session come alive.

3:48And like I say, the little packet

3:49that we send back and forth,

3:51they're really called a BFD keep alive packet.

3:54They're incredibly lightweight,

3:55which makes transmitting them every 300 milliseconds

3:59very reasonable to do.

4:01So when these two things match on both sides,

4:03the timers and the multiplier, we establish a BFD session.

4:07When we stop getting BFD keep alives coming back

4:12throughout our detection timer,

4:14the BFD session, the session itself transitions to down.

4:22And when BFD session goes down,

4:24it then sends through the software a notification

4:28to the OSPF or BGP or ISIS process

4:35that BFD has gone down and that it should begin

4:38transitioning or reconverging its own routing protocol.

4:43It should run whatever algorithm it's supposed to run.

4:46In OSPF and ISIS cases,

4:47that's the shortest path first algorithm,

4:49the Dijkstra algorithm.

4:51In BGP's case, that's the BGP best path selection algorithm.

4:56So routes reconverge, routes get removed,

5:00and then equal cost multipathing gets recalculated.

5:03And then we've got a new routing and forwarding table.

5:06Again, this happens in roughly one second

5:10compared to 40 seconds or 180 seconds

5:14or whatever custom timers you've configured

5:17for the routing protocol.

5:19It's a great way to relieve that timer pressure

5:22as well as quickly reconverge upon network failures

5:27or link failures, and that's the case.

5:31Now, I think one of the most important things

5:32to really understand about this BFD session,

5:36it's not necessarily just about a link failure.

5:40This detects a path failure.

5:45It's not just that the wire got cut or the port went down.

5:48If anything goes wrong in the transmission of data

5:52from point A to point B, BFD is going to figure that out.

5:56It's not going to see traffic going out

5:59and return traffic coming back in.

6:01That's why it is bi-directional.

6:05We can send traffic this way and it could get black holed

6:09and we never get the return traffic coming back.

6:13It is important to know that your OSPF and BGP timers

6:16will still exist.

6:18This is just a supplement to those protocols.

6:22It will only run BFD where you tell it to run BFD.

6:28You can absolutely enable BFD on specific interfaces

6:32and then say, this only applies to OSPF,

6:36don't apply it to BGP or vice versa.

6:39So it's all about detecting path failure

6:42and it's all about supplementing,

6:44not necessarily replacing your current protocol timers.

0:00So how do we configure BFD? Let's take a look because where we want to run this is really

0:06dependent on which routing protocol we want to support. In our topology we configured OSPF

0:13everywhere. Just one second. All of these links that connect the spines to the leaves are running

0:18OSPF except for these two links right here where we were just configuring a lag earlier. So let's

0:23pick on this 10 gig 001 link between vqfx1 and vqfx3. I'll go ahead and bring the terminal up

0:33here so that we bring a tab into the mix. So here we go. I'm going to zoom in nice and big.

0:41Press enter. We're already in edit mode apparently. I don't know what was going on there but I guess

0:45I'm in edit mode. And what I'm going to do is I'm going to do show and we'll look at protocols

0:50OSPF. And we see here for area 0 I've got this running on all of these interfaces. Once more

0:57I see the link between vqfx3 and vqfx1 right here on the screen. This one that goes right

1:04across the middle is 10 gig 001 on both locations. Right there 10 gig 001. So when I bring this back

1:14into the mix what we're going to do is we're going to set protocols right there. Set. Oh yeah

1:23hang on. Set. There we go. I actually had my writing pin queued up there and that application

1:34takes over the tab button so it wasn't letting me tab to complete protocols. Okay I've removed

1:39the pin. I've got set protocols OSPF area 0 interface 10 gig 001. Now watch this. If I do bfd

1:51and tab to complete we see bfd liveness detection. If I give this a question mark what were the two

1:59main things we needed to have? We needed to have a minimum interval and a multiplier. Now yes there

2:08are a lot of other interesting things like setting up authentication between bfd peers.

2:14I also really like this one only. Only run bfd when we have a full OSPF neighbor adjacency.

2:23So we're not going to run bfd on say a neighbor that's stuck in xstart. Why would we do that?

2:31Because then we're already stuck trying to reconverge. Bfd could be causing it to reconverge

2:39even quicker. So things like that matter but they're not critical to getting bfd up and running

2:44and certainly not critical to the JNCI ADC. So we're going to set our minimum interval to 300

2:52for 300 milliseconds. I'll press enter. I'll hit up and I will set the multiplier to be 3.

3:03So now when I do show protocols OSPF we can see for this particular interface we're going to be

3:11running bfd liveness detection with a minimum interval of 300 milliseconds and a multiplier

3:17of 3. Let's go ahead and make the same configuration on the router that's on the

3:23other side in 10 gig 001. We'll do set interfaces oh wait not set interfaces set protocols OSPF

3:33area 0 interface 10 gig 001. Then we will set this to be bfd tab to autocomplete liveness detection

3:44minimum interval 300 and then the multiplier of 3. So there we go we can commit and quit this

3:56and then validate. With the commit in place we can do things like show bfd and question mark

4:02things that you really care about our session. So if we do show bfd session boom we see our current

4:10state. Now currently the state is down and you might be thinking oh no it must not be working

4:16you must have misconfigured it. Honestly bfd has a lot of problems in virtualized and emulated

4:22environments. It's usually too fast of a protocol for an emulated environment. So ultimately don't

4:31fret when you see a down state in using a bfd session whenever you're trying to use emulated

4:38hardware. This is actually a really common known thing about using even g or cml or whatever it is.

4:44This is definitely how you configure bfd. One last check to make sure you can actually check

4:51OSPF's doc or juniper's documentation on configuring OSPF fault detection with bfd.

4:58If we zoom in real quick and kind of zip down to the minimal code requirement

5:03you can see what they show you the exact same thing set protocols OSPF area zero here's the

5:09interface bfd liveness detection a minimum interval and a multiplier of four. They went ahead and set

5:16it to full neighbors only but it's not necessary it's just not going to work in a virtualized

5:21environment but that's really it and that's what bfd does.

0:00The final thing we're going to talk about is virtual chassis in the Juniper world.

0:04And this really isn't something that you can lab.

0:08Now, as you can see, I've had to like do some Googling and searching so that I can actually

0:12physically show you what a virtual chassis looks like on the Juniper devices.

0:17This is a card that slots into the back of your Juniper switch.

0:22So on the front end of your switch, let me kind of get my pen going here.

0:27Let's say we've got the front end of our switch like this.

0:31And it's got our ports across the front like so.

0:35What does the back of a switch usually look like if you kind of just drew it out like this?

0:39You've got, you know, probably the power cord that goes like this,

0:44and maybe a console port that you can console in on.

0:48And then what? You probably got some fans and not much.

0:51Well, Juniper has this like slot that can go right here in the back of the switches,

0:57and it looks like this.

0:58And you've got this kind of almost like an HDMI cable looking port on the back,

1:03but it's much wider than that.

1:05This is usually, I mean, in the Juniper world, we like to call these the direct attach cable,

1:10a DAC cable.

1:11And what you do is you literally take this cable and you plug it in to the next switch like this.

1:19So if I had a stack of, let's say, three or four switches,

1:27let's say we're looking at the back of these switches.

1:31And there's two of these ports like so, like this, and like this.

1:40This is the back again.

1:41So we've put this module in here for a virtual chassis component.

1:46We see these two cables here.

1:48If I change the color, just to kind of illustrate this,

1:52we'll attach this cable to here.

1:58And then we'll do something like, if I take red for a second,

2:03we'll do this cable to here.

2:08And then we'll do, let's do yellow.

2:11We'll do this cable to here.

2:14That doesn't really show as well as I thought it would.

2:18And then lastly, we'll do kind of a teal.

2:20You can kind of guess where this one's going to go.

2:22This cable is going to go to here.

2:26They all kind of daisy chain each other a little bit like this and plug into each other.

2:31What we'll do is we'll log into each one of these switches, usually on the console,

2:38and we'll now say you all belong to one giant logical switch.

2:45So when I SSH in, I'm going to SSH in into what will eventually become the master node.

2:54And the rest of these will be known as line cards.

2:59So we'll just put LC and LC right here.

3:02When I SSH in, I'll log in and I'll see, you know, the master node here.

3:08And from this master node, I can make configurations on any of the ports that belong to the chassis,

3:15because again, it sees all of these ports as one gigantic switch.

3:20It thinks they all belong to the same.

3:23So one of the interesting things that you want to know is how ports change

3:26or how the naming conventions change.

3:29Let me change back to a darker color for a second.

3:31Let's say again, we have, you know, a virtual chassis and we have three switches in the mix.

3:40Let's say this one is the master.

3:42This is line card one and line card two.

3:46What this means is in this virtual chassis, this is member zero.

3:52This is member.

3:53Let me get rid of opacity here for a second.

3:55Member one.

3:57And this is member two.

3:59So if you think about this on the front of these switches,

4:02you see all of these ports like 10 gig ports,

4:04and we've been seeing them listed something like zero, zero, zero.

4:08Well, this is actually member.

4:12This is actually basically the PIC or the particular card

4:19that we're interacting with on the motherboard.

4:21And this is the port number.

4:24So if I wanted to interact with the very first port,

4:27the Ethernet port on the first line card,

4:32this would look like XE 100.

4:36And the same thing here would be XE 200.

4:42So when I SSH in right here, of course,

4:44I'll SSH into the one that is currently serving as the master,

4:48but I can do a set interface 10 gig to zero, zero

4:55to configure a port down here.

4:58And as you can imagine,

5:00because we're now creating kind of redundant hardware,

5:05we can now do something like create a lag

5:08that uses a port on the line card two and a port on the master.

5:14In fact, you can actually create a lag.

5:16You're not limited to just two ports when you create a lag.

5:19You can create a lag with basically any even number of ports.

5:23So you can go with two ports or four ports or eight ports and so on.

5:27So if you build a virtual chassis with say eight total switches,

5:34you could actually have a pretty redundant lag

5:36that spans across multiple pieces of hardware.

5:40This isn't just to get you bigger switches.

5:44I mean, it is nice.

5:44You can get bigger switches

5:46and you have a lot of control over how many switch ports you have.

5:50And maybe even the ability to make the SFPs here for fiber

5:56and the SFPs here for copper,

5:58and you can get some more compatibility that way.

5:59But the real big thing here is now you also have the ability

6:03to spread your redundancy objectives,

6:07like building a lag across multiple physical pieces of hardware.

6:12And if for whatever reason line card two dies,

6:16other pieces of your lag could exist,

6:19you know, on a different line card or the main master node.

6:23Now, again, the JNCI ADC does not expect you to know how to configure this.

6:28The configuration isn't particularly hard.

6:31It's really just a set of commands that tell these nodes,

6:35you know, first of all, you're picking which one is the master

6:37and setting is the master.

6:38And then you tell the rest that they're a line card.

6:40And then you simply add them to the virtual chassis.

6:42And you specify that this is happening over these interface cards

6:46that happen on the back.

6:49So, you know, kudos to the Rocket platform

6:51for having an image right here that we can leverage

6:54to actually show you a picture of what the virtual chassis module looks like.

6:59When you buy EX series switches,

7:01you can buy them with this module already installed

7:05and the DAC cables shipped with it.

7:07And you can just plug your DAC cables in

7:09and rack all these switches on top of each other.

7:11So now we understand virtual chassis

7:14and high availability operations on the Junos operating system.

7:19I hope this has been informative for you.

7:20And I'd like to thank you for viewing.

0:00Let's take a moment to review what we learned about high availability in the Junos operating

0:05system. A network engineer configures a lag on Juno switch by assigning two interfaces to AE0

0:12and enabling LACP. The configuration commits, but the command shows interfaces AE0 or show

0:20in the command show interfaces AE0 returns device AE0 not found. We actually encountered this when

0:27I was going through it. What is most likely the cause? Right here on top. The aggregated

0:33Ethernet device count has not been configured. Remember, we have to tell Junos how many AE

0:41interfaces to create in addition to bundling physical interfaces into it and then configuring

0:47the logical settings on it. So the other things are not going to work. The interfaces are

0:52configured with mismatched speeds. Now that would not create the lag. The lag would not become

0:58available, but that would have nothing to do with interface AE0 not being present. LACP must be

1:04enabled in passive mode on both interfaces. That probably has nothing to do. That definitely has

1:09nothing to do with AE0 and it doesn't mean the lag might not come up because we can have both

1:18interfaces in passive mode on a single switch as long as the remote switch has both interfaces in

1:26active mode. Remember, it's okay to be passive as long as the whole configuration is active passive

1:31and the lag must be configured under protocols instead of interfaces. Nope, nothing to do with

1:36that. A router's routing engine is restarted during planned maintenance. Traffic continues

1:42to flow normally and neighbors do not withdraw routes. Which feature is primarily responsible

1:48for this? Again, right on top, graceful restart. The whole point is that we can gracefully restart

1:55our processes without stopping the flow of traffic and it also signals to our neighbors, our helper

2:02neighbors, that hey, we're restarting but it's okay to keep forwarding traffic to me. So it's

2:08not lag, it's not virtual chassis, and it's not BFD. A virtual chassis consists of three switches

2:16with member IDs 0, 1, and 2. An engineer wants to configure port 0 on the second physical switch.

2:26Which interface name should be used? Okay, remember, we've got the way it works is like 10 gig

2:33and then member ID, the PIC or interface card that we're interacting with on that member,

2:41and then the actual port number itself. So since we're saying these switches are member IDs 0,

2:47that comes first, 1, that comes second, and 2, that comes third, and they want to configure port 0,

2:55then the answer is XE100, right there. Because, remember, almost everything in Junos begins with

3:03a 0 index, meaning 0 comes first, so the second item would be 1, it's going to be on the first

3:10PIC, and it is the first switch. So that reinforces what we've learned about Junos high availability.