Understand Junos High Availability Operations

0:00Welcome to the content on understanding high availability techniques for your Juniper devices. Now this content is applicable to both Juniper switches, routers, and well let's go ahead and throw firewalls in there. So not both but all three of those things. This is really the Junos operating system. But the Juniper, their JNCIA DC exam blueprint really gives you four different kinds of high availability and techniques that you can use. Now high availability comes in a bunch of different shapes and sizes and it's used for a bunch of different well techniques or a bunch of different reasons. Things that you want to prevent against failure. So we're going to talk about all of 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 fourth one as well. I actually have a lot of experience in that fourth one. So without further ado, let's talk about some of the most important things that you as a network engineer do with your Juniper devices and this is configuring things that really hedge against failures in the data center. Let's go.

0:00Let's talk about what high availability, very frequently abbreviated to HA, is. And if you're in the systems world already, you may have seen something called HADR, and that sets up an even bigger topic. What is high availability and what isn't high availability? What is it not? Let's think about what the basic concept of high availability is. The idea is we have some sort of system, or some sort of networking device like a router, or really anything technical at all.

0:35And if a piece or a component of it fails or goes down for any reason, there are some expectations with high availability. One, redundancy already exists. Redundancy is already in place. Two, this is really important one, failure is automatic or failover is automatic. Let me go ahead and change that a little bit to be failover is automatic, meaning it doesn't require some human to intercede and make a change to the configuration to keep it running.

1:15And three, impact is near zero. The idea here ultimately is that the end user who is consuming something on your network sees nothing, feels nothing. They have the exact same experience using the application before and after some component failure. Now, what could these component failures be, especially in the networking context?

1:45This could be a link failure, meaning the fiber got cut. We see that one a lot, don't we? The fiber got cut. Two, it could be the port died. This usually happens on SFPs, you know, small form factor pluggables, things that go into the switch. Switches these days, if you haven't seen, let's just pause and talk about this for a second. Sometimes they kind of look like this EX4100 you see on the screen.

2:16And right here, we see RJ45 ports going across the whole switch. But then right here on this section, we see these blank holes. What is this all about? These are the small form factor pluggables. And the idea here is you can bring your own networking port and slot it in right there. Sometimes we just use more RJ45 ports. That's true. I mean, we can actually just put in more copper ports.

2:47These also, let's go ahead and say this too. These could be make something up. These could all be one gigabit per second ports right here. And we can slot in 10 gigabit per second RJ45 ports in these SFPs. But we can also put fiber ports in here. The fiber mechanism that, you know, receives light waves and transmitters and everything and decodes that, all of that is contained in like basically a little stick that you just plug in right there.

3:17And I have this exact same setup in my rack in my own business right now, where we're using copper to talk to our servers, our servers connecting using copper, and then to connect between switches or even out to the internet, we use the SFPs and use fiber. All of that is to say these SFPs break. I mean, they break, you know, not a lot, but it's not a crazy stretch to think that out of the eight ports that you see right there, one of them is going to die in the next 12 months.

3:51They get really, really, really hot. They can consume a lot of electricity and that just degrades equipment over time. So if this is connecting in to say a server that's hosting our website, we want the end user. If this SFP dies, we want the end user to not know that it died. So we're basically saying, you know, the link gets cut, the SFP or port dies, but what else is there?

4:23There's actually the software itself. And I'll say, I haven't really encountered this too much out there in the open world, but it can happen. When we say this, you know, if we really think about it, what is Junos? Junos is software built on top of free BSD, which is a lot like a Unix or Linux operating system at the end of the day. And like anything that goes on on an operating system, it's subject to fail. Applications crash. And in this case, Junos can crash or specifically just the routing process.

4:58Specifically, they call these routing daemons or maybe demons, depending on, you know, your point of view. Those things can crash, absolutely. And then of course, the last one that's kind of out there and you don't really think about this as a failure, but it's out there, maintenance. I mean, what happens when we have to patch the software on a Juniper switch and we take the switch down because it has to reboot? What happens to all that traffic that was flowing through the switch? Well, it's kind of the idea.

5:29So we flow back to the three things that we really expect out of high availability. We have more than one device and more than one link ready to service this traffic at all time. That is the redundancy piece of the puzzle. We can have multiple switches. We can have multiple links. We can have multiple links between multiple switches. That way there are multiple paths to get from point A to point Z.

5:59And one doesn't necessarily cost more than the other. It's redundant. Secondly, what was the second thing? It was automatic failover. This is where the protocols come in. When we have the redundant links in place, we then have to tell the Juniper operating systems, hey, these are redundant links and you should start monitoring their redundancy. And in the event that one goes down, you should fail over very, very quickly, such that number three, there is near zero impact to the end user, to the application, to the service itself.

6:39Now, Juniper breaks down four main failover and high availability mechanisms that they want you to know on this exam. And that is what we're going to talk about. We have a link aggregation group. That is what it is called when we have multiple links between devices, between single devices. So if I had a router here and a router here, we can draw the little arrows like so. We've got two links between them and we can bundle these two links together into a link aggregation group.

7:10This is specifically using a protocol called LACP. We have graceful restart. Okay, so what does this protect against? This protects against link failure, okay? Next we have graceful restart. This keeps forwarding traffic even when the software wants to stop forwarding traffic. Maybe the routing daemon resets or has to reload or something. Graceful restart will keep forwarding traffic with the existing forwarding table until it's ready to get back, the routing daemon is ready to get back up and running.

7:49We have bidirectional forwarding detection, which is a rapid failover protocol specifically used by routing protocols like OSPF and BGP. More on that to come. And then we have virtual chassis. This is where we bundle a bunch of switches together and make them believe they're one gigantic switch. So in the event that one switch fails, then there's multiple switches in the chassis that can just keep forwarding the traffic.

8:21The exam wants you to understand all four of these, but know how to configure lag, graceful restart, and bidirectional forwarding detection. Now, what is high availability not? It is not disaster recovery. Now, it is something that will help you in the event of a disaster, in the event of a failure. But the idea with disaster recovery is that it is all about catastrophic failovers.

8:53This is usually when we're talking about geographic natural disasters, tornadoes, hurricanes, floods, riots, anything that can really, really, really disrupt an entire region. How do we get our services back online quickly after they are completely offline? How do we recover from a true disaster? That's what disaster recovery is all about. This is where you start invoking your systems teams a lot, like we got to get to the backups and bring our VMs back to life in the cloud or something like that.

9:29So this is what we're talking about when we talk about high availability. And now we kind of have an idea as to why it exists and what are the protocols that we're going to learn about when 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. This is an open standard protocol, so that means it will work between a Juniper device and a Cisco device. If, say, we have a Cisco router right here and a, let's call it a Juniper router right here, guess what? We 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. And a lot of times you'll see people kind of confuse, not necessarily wrongly, but confuse a LAG with the actual protocol itself, LACP. LACP creates a LAG. This standard protocol is also very frequently known as 802.3ad. So, 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. So, what does it do? 802.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. That way it knows, oh, okay, this is going to be some form of LAG. And we'll tell it specifically use 802.3ad and or L, I got to write this better, LACP.

1:47Very cool. When we put these two ports into a bundle, they form one logical LAG port that we can put our configurations on. Because ultimately we want them to act the exact same way. We want them to pass the same traffic. So, Juniper will create a virtual interface that encompasses the two underlying physical interfaces. In 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. If we created another LAG with two different ports, it'll be A, E, 1. And 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. So, 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. I wrote 0 here. I should have written 1. A, E, 0.1, A, E, 1.1, and so on and so on and so on. So, you could have as many logical subunits as you desire or need to configure just like you do physical interfaces. The configuration works almost the exact same with an A, E interface as you do the physical interfaces. So, 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. Now, what's one of the cool things about this is lag can be configured such that, by default, it actually does load balancing. So, 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, but we're just enabled to carry more traffic than we were before over both links. That 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. So, how does it work? Well, 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. LACPDUs go to a specific MAC address that the other machine will be configured to listen on whenever we turn on 802.3ad. The 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. As 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. I can form a LAG here. An 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. Basically, is this thing up, is it active, is it passive, and so on. Based 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. Ultimately, 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. If the answer is yes to these, it's likely that our LAG is going to form successfully. Now, there's another thing that goes on here that we need to talk about, and that is called port state. When 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. If 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. An adjacency will only form if we have active active or active passive. That's the only time an adjacency will be formed.

8:01And then, of course, speed, duplex, and key have to match from there. Juniper's recommendation is to always configure your interfaces as active. Now, 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. What happens next? Well, it's time to start sending traffic over the LAG.

8:32And, like I said, it can be load balanced. But it's not load balanced using something like a round robin, or something like that. Instead, it uses an LACP hashing algorithm. Now, I'll tell you right now, the hashing algorithm is a pretty commonly seen 5-tuple structure. And when I say it's a commonly seen 5-tuple structure, it's actually something that you see a lot on firewalls. What 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. I'll just put A, B, C, 0, 1, 2, as a made-up hash. And once this traffic flow has been recognized, and we've got this hash right here, that hash will be assigned to, say, this link. Then, 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? This traffic could simply consume more traffic than, well, this flow right here. This flow could just be being used more than the secondary flow. Therefore, this link right here could be being used more than this link right here. The 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. Now, I'm also going to say this right now. Out 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. So, 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. It 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. Now, 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. And of course, well, not of course, but lots of times the making it come to life part is a lot easier to do than just understanding the concepts. Here we've got VQ-FX 1 and VQ-FX 2. Let's say I want to configure a new bundle of lag interfaces right here between the two of these. Using 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. Let's use 8 and 9. So I'll use 10G08 on both sides and save. And it makes the link come to life. And now I'll also put 10G09 on both sides and save. So now I've got two active links between the two of these. There's been no configuration put in place.

1:03Let's do that. Let's put a configuration in place. So I'll jump over here to my terminal on VQ-FX 1. We can kind of zoom in a little bit more if we really try to. And what I'm going to do is I'm going to move into edit mode. Then what I'm going to do is I'm going to move into edit interfaces and we'll do 10G08. In fact, you know what? I'm not. I'm just going to do edit interfaces. I'm going to do set 10G08, but I'm not going to use a logical subunit here because I am trying 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. So I'm going to do set 10G08 ether options. And then, like I said, we're going to say 802.3ad is the option that we're going to enable. And then we tell it what logical aggregated ethernet interface it belongs to. Since I don't have any other lags on this particular device, I'll start with the first one, AE0.

2:14I press enter here and that configuration takes place. Now, just for good measure, I'm going to do show 10G08 and I do see it has a unit zero already configured here. I'm going to make sure I get rid of that just so that there's only the ether options configuration in place. So I gave it a delete 10G08 unit zero. So that's not going to delete 10G08. That'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. Let's do show 10G009 for good measure. And I see a unit zero there. So I'm going to delete 10G009 unit zero and then set 10G009 and we said ether options 802.3ad in AE0. So 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. It shows it in the 802.3ad lag in an interface called AE0. And if I press up a few times to do the show command, we'll change it to nine and confirm it looks the exact same way. Awesome. So when I commit this, there's going to be an AE0 interface and that AE0 interface won't be configured. So 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. We press enter here. So that configures AE0 to use LACP's active mode. We'll also make sure this is a switch port, or at least the bundle is a switch port. So 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 the LACP protocol, it's going to be in active mode and unit zero is going to be making the logical bundle of interfaces, a switch port instead of a routed interface. Again, we can do show 10 gig 008 and 10 gig 009, and we can see what physical ports make up AE0 this way. Now let's do it on the other switch.

4:56Jumping back here, I'll bring up the spine. We'll launch the iTerm and it comes to life here. Let's make the font nice and big so that we can see it and I'll give it the exact same configuration. I'll move a little bit quicker this time. I'll move into interfaces. We're going to delete 10 gig 008 unit zero, unit zero. We'll also do the same for 10 gig 009. We'll set 10 gig 008, ether options, 802.3ad and part of AE0 because this switch also doesn't have an AE0 or a lag or a bundle yet.

5:39So we can use AE0 on this. We'll do the exact same thing for 10 gig 009. We'll set AE0, aggregated ether options, LACP in active mode, and we'll set AE0's unit zero in family ethernet switching. So at this point, we've done the exact same configuration on both sides. 10 gig 008 and 009 connect to their respective partners.

6:09They're configured to be in 802.3ad bundle creating the logical interface AE0. Then we told AE0 that you need to have active mode LACP and that you're a switch port or really a bundle of switch ports. We'll give it a commit and quit on both sides. I'll go ahead and just kind of minimize this one. Let's bring that terminal back up. Whoops, there was just a tab across the top I had to do. Let's give this a commit and quit on VQFX1.

6:41And we should have the successful commit operation in place. The configuration is now complete. So how do we check to make sure it works? Let's first do show interfaces AE0 right here. And we see AE0 is not there on either device. What's this all about? This is one of the most classic Junos gotchas you will ever run into. One of the most interesting things about this is that we have logically created AE0 out of 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 up front. So watch this. I'm going to go back into configuration mode and we're going to change the chassis to use aggregated interfaces. Let's do set chassis aggregated devices for Ethernet. And 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. If I set the device count to two, that would create an AE0 and an AE1. Three would create AE0, one, and two, and so on and so on and so on. So I'll give this a commit and quit. We'll do the same thing over here on the spine. Edit 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, then configured the physical interfaces to be in that, then configured the logical interface as well as to use LACP active. Now when we do show interfaces AE0, ah, now we actually see our interfaces up. We see packets coming in, we see the amount of data coming in, and that is a great sign. We can also do show LACP interfaces like this, and it actually tells us not only what our current actor interfaces are, but also what our partner's remote interfaces are.

9:08We see that we're currently using the LACP protocol. That's great. And beyond that, we can do show LACP. You could actually use question mark right here. One of the next big ones you want to use is statistics just to validate. Statistics question mark right there. And then take a look at what's going on on the interfaces themselves. You can actually see how many LACP received DUs have we seen and how many have we transmitted ourselves. So now we've configured and confirmed LACP is up and running.

0:00Next up, we're going to talk about Juniper's Graceful Restart. And while I'm sure there are competitor tools that do something similar, I haven't really run into it because I think it's really, really cool. So let's talk about what it does here for a second. Let's say we have three routers that are all running OSPF and are connected to each other. Let's say they're all Juniper routers and they're all configured with Graceful Restart. The idea with Graceful Restart, and remember with Juniper devices, is that the control plane is separate from the data plane.

0:36The control plane decides, it uses software, it uses routing protocols, to decide what routes should exist. The data plane or the forwarding table says, if traffic comes in on this interface destined for some other interface, exit out that this other interface. It's as simple as, if it's going to this destination, it exits out this interface. Obviously, the forwarding table comes from the learned routes.

1:07The routing, the control plane and the route table is calculated, you know, using OSPF and the Dijkstra algorithm and BGP and so on. And that derives the forwarding table, which just says, exit this traffic out this interface. These two can exist separately from each other. And lots of times they do, in the event of maintenance, or in the event of some form of control plane failure, or, you know, routing process gets restarted.

1:37The routing process or OSPF process or anything. So for whatever reason, if the control plane goes offline, the data plane keeps working and keeps forwarding. But this is where it gets really interesting. There's also introducing the concept of a helper. The helper will keep its buddy's routing table and forwarding plane in its memory for a given time. So that traffic can keep going through the process like so.

2:12And when this comes up, the helper can remind the neighbor what its routes were. So the helper basically keeps a copy of its neighbor's control plane, so that when the neighbor's control plane recovers, the helper can get it right back up to speed as quickly as possible. And again, because the data plane stayed online the whole time, traffic keeps getting forwarded as normal. So this is called graceful restart, because it gracefully keeps forwarding traffic while the control plane more or less gets its act together.

2:53And the introduction of the helper neighbor router that keeps a copy of its neighbor's routes ready to rock and roll for when it recovers is a really, really cool idea and a really, really cool factor. So now let's jump in and 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. First of all, we need to tell Graceful Restart that it needs to be on. So we'll go into edit mode and we'll do Set Routing Options Graceful Restart. Press Enter and that's it. That's it for turning it on. But then we really wanted to know that certain routing protocols are constantly changing the control plane and they need to be advertised 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. Let's do Set Protocols OSPF Graceful Restart and that's it. That's all there is to configuring Graceful Restart. I'll give it a commit and quit. I'll jump over to a neighboring router. We'll do Edit, Set Routing Options. Graceful Restart. Set Protocols. OSPF. Graceful Restart. Commit. Oh, oh And I see it wants actually more information.

1:09So if I do Set Protocols OSPF Graceful Restart It wants to know how to use Graceful Restart. If I give it a question mark right here, we can tell it these things. So one of the interesting things is because we set in routing options to be a Graceful Restart router It's automatically going to advertise this in OSPF and automatically try to be a helper. We can disable Graceful Restart from OSPF specifically entirely right now. We 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 when do we actually say our neighbors must not be a Graceful Restart router anymore. So I don't actually need to change anything in Set Protocols OSPF Graceful Restart to actually make it be a Graceful Restart router. We can just commit and quit this as it is right now. So at this point we've enabled Graceful Restart. A 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. Also, 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. So 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. So what does it do? This is a independent protocol designed to be incredibly lightweight and detect a failure very, very rapidly. Let's think about OSPF for a second. If I have routers right here and they've got a link between them and they're both configured to OSPF, do you remember what the timers were? What was a hello packet timer?

0:32A hello is sent by default every 10 seconds. And when we miss four hellos in a row, the dead timer has expired and we declare our neighbor dead. That means 40 seconds, 40 whole seconds pass by default before we detect that an OSPF neighbor has gone down. Here's a little tidbit for you. We didn't really cover this because BGP is pretty extensive. The BGP hold timer, kind of the same thing as a dead timer, 180 seconds or three whole minutes can go down before we actually detect a failure.

1:14Bidirectional forwarding detection is a separate protocol that is just designed to do nothing more than to detect a neighbor adjacency going down and then send a signal to the routing protocol of choice that BFD has detected that the neighbor goes down. So OSPF can use BFD rather than its default dead timers or hello timers and dead timers and BGP can use BFD.

1:47How quick are we talking about here? Milliseconds. When we configure BFD, it really is a function, it's really a very basic mathematical equation. We are trying to detect when a neighbor fails. So we call this the detection time and it equals our minimum interval, which is how frequently do we send the BFD packet times a multiplier.

2:20How many times do you wanna check? Usually by default with BFD, we're gonna call it a hello packet, it's not what it is. We send a BFD hello packet every 300 milliseconds and we usually set our check to be three times, meaning we can detect a link failure and declare a neighbor dead in 900 milliseconds, less than one second.

2:51Compare that again to OSPF's dead timer of 40 seconds and BGP's hold timer of 180 seconds. So what really happens under the hood? Well, BFD is a protocol. So when we have our two routers yet again, like so, what's really happening here? Just like how we have OSPF establish a neighbor adjacency, we will establish a BFD adjacency.

3:22Really we call this the BFD session and things need to match on both sides. We need to agree really on our timers, which is that minimum interval and of course the multiplier. When do we declare our neighbor dead? That's really it that needs to match on both sides to make a BFD session come alive. And like I say, the little packet that we send back and forth, they're really called a BFD keep alive packet.

3:54They're incredibly lightweight, which makes transmitting them every 300 milliseconds very reasonable to do. So when these two things match on both sides, the timers and the multiplier, we establish a BFD session. When we stop getting BFD keep alives coming back throughout our detection timer, the BFD session, the session itself transitions to down. And when BFD session goes down, it then sends through the software a notification to the OSPF or BGP or ISIS process that BFD has gone down and that it should begin transitioning or reconverging its own routing protocol.

4:43It should run whatever algorithm it's supposed to run. In OSPF and ISIS cases, that's the shortest path first algorithm, the Dijkstra algorithm. In BGP's case, that's the BGP best path selection algorithm. So routes reconverge, routes get removed, and then equal cost multipathing gets recalculated. And then we've got a new routing and forwarding table. Again, this happens in roughly one second compared to 40 seconds or 180 seconds or whatever custom timers you've configured for the routing protocol.

5:19It's a great way to relieve that timer pressure as well as quickly reconverge upon network failures or link failures, and that's the case. Now, I think one of the most important things to really understand about this BFD session, it's not necessarily just about a link failure. This detects a path failure. It's not just that the wire got cut or the port went down. If anything goes wrong in the transmission of data from point A to point B, BFD is going to figure that out.

5:56It's not going to see traffic going out and return traffic coming back in. That's why it is bi-directional. We can send traffic this way and it could get black holed and we never get the return traffic coming back. It is important to know that your OSPF and BGP timers will still exist. This is just a supplement to those protocols. It will only run BFD where you tell it to run BFD.

6:28You can absolutely enable BFD on specific interfaces and then say, this only applies to OSPF, don't apply it to BGP or vice versa. So it's all about detecting path failure and it's all about supplementing, not 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 dependent on which routing protocol we want to support. In our topology we configured OSPF everywhere. Just one second. All of these links that connect the spines to the leaves are running OSPF except for these two links right here where we were just configuring a lag earlier. So let's pick on this 10 gig 001 link between vqfx1 and vqfx3. I'll go ahead and bring the terminal up here 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 I'm in edit mode. And what I'm going to do is I'm going to do show and we'll look at protocols OSPF. And we see here for area 0 I've got this running on all of these interfaces. Once more I see the link between vqfx3 and vqfx1 right here on the screen. This one that goes right across the middle is 10 gig 001 on both locations. Right there 10 gig 001. So when I bring this back into the mix what we're going to do is we're going to set protocols right there. Set. Oh yeah hang on. Set. There we go. I actually had my writing pin queued up there and that application takes over the tab button so it wasn't letting me tab to complete protocols. Okay I've removed the pin. I've got set protocols OSPF area 0 interface 10 gig 001. Now watch this. If I do bfd and 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 are a lot of other interesting things like setting up authentication between bfd peers. I also really like this one only. Only run bfd when we have a full OSPF neighbor adjacency. So 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 even quicker. So things like that matter but they're not critical to getting bfd up and running and certainly not critical to the JNCI ADC. So we're going to set our minimum interval to 300 for 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 running bfd liveness detection with a minimum interval of 300 milliseconds and a multiplier of 3. Let's go ahead and make the same configuration on the router that's on the other side in 10 gig 001. We'll do set interfaces oh wait not set interfaces set protocols OSPF area 0 interface 10 gig 001. Then we will set this to be bfd tab to autocomplete liveness detection minimum interval 300 and then the multiplier of 3. So there we go we can commit and quit this and then validate. With the commit in place we can do things like show bfd and question mark things that you really care about our session. So if we do show bfd session boom we see our current state. Now currently the state is down and you might be thinking oh no it must not be working you 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 fret when you see a down state in using a bfd session whenever you're trying to use emulated hardware. This is actually a really common known thing about using even g or cml or whatever it is. This is definitely how you configure bfd. One last check to make sure you can actually check OSPF'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 you can see what they show you the exact same thing set protocols OSPF area zero here's the interface bfd liveness detection a minimum interval and a multiplier of four. They went ahead and set it to full neighbors only but it's not necessary it's just not going to work in a virtualized environment 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. And this really isn't something that you can lab. Now, as you can see, I've had to like do some Googling and searching so that I can actually physically show you what a virtual chassis looks like on the Juniper devices. This is a card that slots into the back of your Juniper switch. So on the front end of your switch, let me kind of get my pen going here. Let'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. What does the back of a switch usually look like if you kind of just drew it out like this? You've got, you know, probably the power cord that goes like this, and maybe a console port that you can console in on. And then what? You probably got some fans and not much. Well, Juniper has this like slot that can go right here in the back of the switches, and it looks like this. And you've got this kind of almost like an HDMI cable looking port on the back, but 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, a DAC cable. And what you do is you literally take this cable and you plug it in to the next switch like this. So if I had a stack of, let's say, three or four switches, let's say we're looking at the back of these switches. And there's two of these ports like so, like this, and like this.

1:40This is the back again. So we've put this module in here for a virtual chassis component. We see these two cables here. If I change the color, just to kind of illustrate this, we'll attach this cable to here. And then we'll do something like, if I take red for a second, we'll do this cable to here. And then we'll do, let's do yellow.

2:11We'll do this cable to here. That doesn't really show as well as I thought it would. And then lastly, we'll do kind of a teal. You can kind of guess where this one's going to go. This cable is going to go to here. They all kind of daisy chain each other a little bit like this and plug into each other. What we'll do is we'll log into each one of these switches, usually on the console, and 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. And the rest of these will be known as line cards. So we'll just put LC and LC right here. When I SSH in, I'll log in and I'll see, you know, the master node here. And from this master node, I can make configurations on any of the ports that belong to the chassis, because again, it sees all of these ports as one gigantic switch.

3:20It thinks they all belong to the same. So one of the interesting things that you want to know is how ports change or how the naming conventions change. Let me change back to a darker color for a second. Let's say again, we have, you know, a virtual chassis and we have three switches in the mix. Let's say this one is the master. This is line card one and line card two. What this means is in this virtual chassis, this is member zero.

3:52This is member. Let me get rid of opacity here for a second. Member one. And this is member two. So if you think about this on the front of these switches, you see all of these ports like 10 gig ports, and we've been seeing them listed something like zero, zero, zero. Well, this is actually member. This is actually basically the PIC or the particular card that we're interacting with on the motherboard. And this is the port number.

4:24So if I wanted to interact with the very first port, the Ethernet port on the first line card, this would look like XE 100. And the same thing here would be XE 200. So when I SSH in right here, of course, I'll SSH into the one that is currently serving as the master, but I can do a set interface 10 gig to zero, zero to configure a port down here.

4:58And as you can imagine, because we're now creating kind of redundant hardware, we can now do something like create a lag that uses a port on the line card two and a port on the master. In fact, you can actually create a lag. You're not limited to just two ports when you create a lag. You can create a lag with basically any even number of ports. So you can go with two ports or four ports or eight ports and so on. So if you build a virtual chassis with say eight total switches, you could actually have a pretty redundant lag that spans across multiple pieces of hardware.

5:40This isn't just to get you bigger switches. I mean, it is nice. You can get bigger switches and you have a lot of control over how many switch ports you have. And maybe even the ability to make the SFPs here for fiber and the SFPs here for copper, and you can get some more compatibility that way. But the real big thing here is now you also have the ability to spread your redundancy objectives, like building a lag across multiple physical pieces of hardware.

6:12And if for whatever reason line card two dies, other pieces of your lag could exist, you know, on a different line card or the main master node. Now, again, the JNCI ADC does not expect you to know how to configure this. The configuration isn't particularly hard. It's really just a set of commands that tell these nodes, you know, first of all, you're picking which one is the master and setting is the master. And then you tell the rest that they're a line card. And then you simply add them to the virtual chassis. And you specify that this is happening over these interface cards that happen on the back.

6:49So, you know, kudos to the Rocket platform for having an image right here that we can leverage to actually show you a picture of what the virtual chassis module looks like. When you buy EX series switches, you can buy them with this module already installed and the DAC cables shipped with it. And you can just plug your DAC cables in and rack all these switches on top of each other. So now we understand virtual chassis and high availability operations on the Junos operating system. I 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 system. A network engineer configures a lag on Juno switch by assigning two interfaces to AE0 and enabling LACP. The configuration commits, but the command shows interfaces AE0 or show in the command show interfaces AE0 returns device AE0 not found. We actually encountered this when I was going through it. What is most likely the cause? Right here on top. The aggregated Ethernet device count has not been configured. Remember, we have to tell Junos how many AE interfaces to create in addition to bundling physical interfaces into it and then configuring the logical settings on it. So the other things are not going to work. The interfaces are configured with mismatched speeds. Now that would not create the lag. The lag would not become available, but that would have nothing to do with interface AE0 not being present. LACP must be enabled in passive mode on both interfaces. That probably has nothing to do. That definitely has nothing 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 active mode. Remember, it's okay to be passive as long as the whole configuration is active passive and the lag must be configured under protocols instead of interfaces. Nope, nothing to do with that. A router's routing engine is restarted during planned maintenance. Traffic continues to flow normally and neighbors do not withdraw routes. Which feature is primarily responsible for this? Again, right on top, graceful restart. The whole point is that we can gracefully restart our processes without stopping the flow of traffic and it also signals to our neighbors, our helper neighbors, that hey, we're restarting but it's okay to keep forwarding traffic to me. So it's not lag, it's not virtual chassis, and it's not BFD. A virtual chassis consists of three switches with 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 and then member ID, the PIC or interface card that we're interacting with on that member, and then the actual port number itself. So since we're saying these switches are member IDs 0, that comes first, 1, that comes second, and 2, that comes third, and they want to configure port 0, then the answer is XE100, right there. Because, remember, almost everything in Junos begins with a 0 index, meaning 0 comes first, so the second item would be 1, it's going to be on the first PIC, and it is the first switch. So that reinforces what we've learned about Junos high availability.