OMP is going to rely on a bunch of timers, but before we get into the timers conversation,
we have to think about the fact that these timers are based on a specific topology,
especially in regards to that software-defined concept of control plane and data plane separation.
So again, we've got two edges here that are communicating with, what, a controller that's out of band.
that allows us to keep our data plane connections online and operational,
but also keep in mind that if information starts to slow down here,
let's say that it's been, I don't know, 10 seconds since I last saw my SD-WAN controller.
Well, I don't want to immediately respond to that.
With OSPF or EIGRP, this would be an enormous amount of time
because if I haven't seen my peer in 10 seconds,
I might as well be sending my traffic into a black hole because that peer is probably down.
I probably need to restructure my table, assuming the peer, which is part of my data plane path, is actually offline.
But if we think about what OSPF and EIGRP use for fast failure detection,
they're using BFD, and they're using BFD at the control plane in order to make sure that my adjacent peer is online.
Well, in SD-WAN, where exactly are we using BFD?
We are using BFD at the data plane.
We're using it to make sure that this tunneled connection is still online.
And so this is the important part of a failure,
meaning that if this edge goes down, then I know that I can no longer reach subnet A.
But if subnet A exists out here and my controller goes down,
then I know that I can still probably reach subnet A as long as nothing has changed in the meantime.
So that separated control plane concept is what we want to keep in mind as we start to explore some of these timers.
Now, the first time we're going to take a look at is known as the EOR timer.
This is fairly unique to SD-WAN. It's not going to have any parallels to EIGRP or OSPF or anything like that.
And EOR stands for end of rib.
The rib is the routing information base and is basically saying the routing table.
So what on earth is this timer all about?
Well, this is going to describe a specific situation.
Let's say that we have, again, this connection. Data plane is online.
And let's say that the controller actually goes offline for a little bit and then comes back online.
Furthermore, let's say that this controller had 30 routes when it went offline.
So I have 30 routes here stored on these edges.
And when it comes back online, it's only giving me 28 routes.
Well, what happened to those other two routes? Where did they go?
I mean, are they gone or should I leave them in my routing table when it comes back online?
This is a really interesting conversation and it's one that's unique to software-defined networking where the controller is out of band.
Where it went down, we were okay with it going down because the data plane stayed online while it was down.
But when it came back up, it doesn't have all the same information.
Well, the end-of-rib timer is going to tell OMP how long to store those missing routes.
The missing routes might not be something that we need to worry about.
And maybe I'm going to get an update pretty soon that has those missing two routes.
Or maybe that never happens.
And so that's the question. How long to store specifically those missing routes once the controller comes back online?
Now, the default timer is 300 seconds for this.
And by the way, we're going to notice that all of our timers are in seconds.
Even though a lot of them are really days and hours or minutes at least.
Like this, for example, is five minutes.
But when we're configuring it, it's always in seconds.
So this is the default timer is 300 seconds.
The range that OMP allows us to configure is between one and 3600 seconds.
Where 3600 seconds is one hour.
So that's the maximum we can set this timer to.
But the default is five minutes.
And usually in production networks, we're probably not going to change this a whole lot.
It's a rather unique situation that does have to be addressed.
But it's hopefully one that doesn't happen very often.
We just talked about what graceful restart is.
And yes, there is that timer that's associated with it.
And this is part of our OMP configuration.
So remember that this is a provided timer.
We'll emphasize that again.
Meaning that if my edge is going to perform the graceful restart, it tells the controller how long to wait.
It provides the timer based on its configuration.
So it's not to say that I'm configuring the edge with the timer to wait.
I'm configuring the edge to tell the controller how long to wait.
And as we already said, the default time is 43,200 seconds, which is 12 hours.
So what is the range? How long can I configure this?
Well, the range is between 1 and 604,800 seconds.
Now that might seem like a random number, but it actually is one week.
That's what that value is.
So if I wanted to, I could set a graceful restart timer to a full week.
If I believe that my vSmarts and my controllers could actually be down that long, then I'd want to configure that.
But hopefully we're never in a situation where SD-WAN controllers are down for that amount of time.
Now the next two timers are going to feel a whole lot like talking about OSPF and EIGRP.
We need to know how long to keep a peer online in the event that it goes down and it stops sending Keep-A-Lives,
as well as how often to update our peers.
So we're going to start with the hold time.
The hold time defines how long to wait for a peer to go down.
And interestingly, this is going to rely on the concept of Keep-A-Lives.
I say interestingly because there isn't a way to configure the Keep-A-Live timer.
Instead, the Keep-A-Lives are going to be sent at one-third the hold time.
So if I want to change the Keep-A-Live time, I need to change the hold time because I can't directly change this timer.
So what's going to happen here is we've got a peering, let's say between an edge and a controller,
and they're both going to be sending Keep-A-Live messages to each other.
So by default, our default timer is also 300 seconds here.
And this is going to, once again, be five minutes translated.
The range is going to be from 0 to 65, 535.
Quite a range.
And it's also worth noting that on older hardware, that the default was actually 5,400 seconds, which is 90 minutes.
So this is a whole lot longer than the five minutes that is the default.
And so if we're running older hardware, especially older Viptela hardware,
then just keep in mind that we might actually see this in our production environments.
So usually we want to tune this to be the same everywhere,
and Cisco in the modern era here of SD-WAN is recommending a five-minute timer.
So think about the way this works.
The default hold time is 300 seconds.
That means we're sending a Keep-A-Live every 100 seconds.
That doesn't seem like much, but again, come back to the topology.
In the end, it doesn't matter a whole lot if the SD-WAN controller goes down,
at least from a moment-to-moment, second-by-second perspective.
Yeah, with OER, GRP, and OSPF, that matters a whole lot,
and therefore losing the path to the controller isn't as big of a deal.
So these Keep-A-Lives are being sent every 100 seconds,
and if we don't receive, let's say we have another edge over here,
and we send a Keep-A-Live, and then all of a sudden we don't, and we don't, and we don't,
well, at that point, we're going to say that, hey, it's been 300 seconds.
I'm going to report that this peer is offline, and I'm going to treat it as such.
So that is how the hold time comes together.
Now, lastly, again, we need to send updates to one another as well,
and that's going to happen per the advertisement interval.
So we could just call this the update timer or something like that,
but no, we got a little fancy.
We're calling it the advertisement interval.
The advertisement interval is simply how often we send updates to our OMP peers,
and the default timer is every one second.
So, yeah, our Keep-A-Live messages are a whole lot less often,
every 100 seconds, give or take, but our advertisement interval is every one second,
and the range, the full range, is between 0 and 65, 535.
So this is how these four different timers come together,
everything from the end-of-rib timer, the graceful restart timer.
especially if we're used to traditional routing protocols,
but then we still have the traditional hold time to detect when a peer goes down,
as well as the advertisement interval, which is how often we send updates to our OMP peers.