[AUDIO LOGO]
So now that we've taken a deeper look
at things like IS-IS neighborships and packet types,
let's jump in and take a deeper look at the IS-IS database.
So we'll start off by looking at some attributes
and things we need to know about the database.
And then we'll jump into the command line
and take a look at the database itself.
So let's go ahead and jump in and get
started with looking at some of those attributes.
So as we've mentioned previously,
we do exchange LSPs to build the link state
database or the LSDB.
Our focus in this video is going to be on the link state
database itself as we've already sort of looked at those LSPs.
Now what we use the link state database for is to, of course,
build the topology which is, of course, then
used to build the shortest path first tree
which is ultimately going to build our routing table.
Now we've mentioned this a few times as well,
but remember that the level 1 LSPs are for within an area.
So this is the topology for a single area.
And if a router is in just a single level,
well, then it's just going to have that one link state
database and therefore only run SPF once against that link
state database.
So there'll only be just that one calculation.
If it's a level 1 and a level 2 router, well,
then it's going to have to link state databases.
And of course, that means it's going
to also have to run two SPF calculations against the two
link state databases.
If there's two, we have to run SFP twice.
Now something else fundamental to keep in mind
is these link state packets are flooded to all
the neighbors in an area.
Now, of course, it's not going to send it back
to the one that originated it.
There would be no point in doing so.
And we have mentioned this a few times, but just
as a final reminder here, level 1 LSPs
are only flooded within an area, and the level 2 LSPs
are, of course, flooded into the backbone
because level 2 adjacencies are in fact the backbone.
Now, each router is going to originate its own LSPs.
And this is going to be for both level 1 and/or level 2.
Of course, it does depend if the router is level 1 or level 2.
And it identifies itself with the system ID.
Now we do implement error checking here
in the form of a checksum.
And of course, if it's invalid, meaning
it doesn't match up with the checksum,
it's of course, going to be discarded.
We're not going to keep bad LSPs.
Let's also discuss the update process.
So in other words, what happens if we get an LSP, that LSP
is valid meaning it did in fact pass the checksum,
and it's newer than the one that's
currently in our database?
Well, it's a fairly straightforward process.
So the first thing we do, of course,
is update our own database if it's newer information,
we're going to want that newer information.
We then acknowledge the receipt.
That way, the sender knows that we got the updated information.
And then we set the lifetime to 1,200 and seconds.
The entry would time out after that for the purposes
of database maintenance.
Now if that LSP does expire, well, we
keep it for an additional 60 seconds
just to make sure that there's no latency
in the forwarding of the LSP.
And then we go ahead and flood it as well, expired.
And that will remove it from everybody else's database.
Again, this is part of database cleanup and maintenance.
Now we did talk a little bit before also
about these complete versus partial sequence number
PDUs or SNPs.
We actually saw how Wireshark listed these as CSNP or PSNP.
And as we mentioned at the time, the complete
is going to include all of the LSPs,
and the partial will be a subset of the LSPs.
Again, it just depends if we're getting the whole database
or just part of it.
Now, again, both of these carry a summary
of the link state database.
It's just a matter of whether it's
a complete or a partial summary.
And again, remember the whole purpose of this
is to make sure that I have all of the entries that you, you
have all the entries that I have.
We're using these to keep our databases in sync.
Now, since it's synchronizing the database,
hopefully it makes sense that there's also like,
the database itself, SNPs also are
separate for level 1 and level 2 because again, they're
maintaining two different databases.
Now while these are exchanged between neighbors, again,
for the purpose of making sure the databases are synchronized,
this is handled a little bit differently
on our different network types.
So on a broadcast network type, it's
the DIS or the DIS that will send this multicast out.
And it defaults to doing this every 10 seconds.
On point to point, it's going to be a little different.
It's really only sent once when the link comes up.
So since the job of the SNP is to keep
the databases synchronized, if there are any differences,
we're going to send a partial SNP
to indicate which entries need to be updated
or are needed to be sent again.
Just as another point of fact here,
the PSNPs are also used for the acknowledgments
when we actually get an update.
Now with integrated IS-IS, a couple of other things
to keep in mind here.
The best path is calculated to other routers,
and then we simply add those destinations from the database.
The IP or IPv6 routes are treated
as end system information.
And since they're end system information,
if all that changes is IP reachability,
then all we need is that partial route calculation or a PRC.
We don't have to calculate the whole topology.
The main point of these last few points
we just talked about here is we calculate routes
between the routers themselves.
So the best path is all about getting to the router.
The prefixes that are available on that router
are really just a subset of getting to the router itself.
So if that router loses a particular prefix,
an interface goes down, something
like that, all it has to do is remove that IP reachability
from the database.
That doesn't cause a complete recalculation of SPF
because the router itself is still
reachable with the same cost and everything like that.
All it's doing is removing the availability
of a particular address.
So let's jump in to the command line
and take a look at this database,
then we'll sort make a change and see how it propagates
to the other routers.
So let's start by looking at our topology
just to see where we're going to be working.
And then we'll jump into the CLI.
So once again, we'll be using IS-IS basic topology.
And for this example, we're just going to focus on router 1
and router 2.
So basically what we're going to do
is we're going to look at the topology on router 1.
We'll look at some information from router 2.
Then we'll go change that information on router 2
and just see how it propagates to router 1.
So let's jump into the command line on router 1.
So let's start off with just to show IS-IS database.
And basically what this is showing us
is a summary of the information that we have in our database
right now, including all of the devices that we're aware of.
So let's look at some more detailed information
on router 2 specifically.
So we can just hit up to go back to the show IS-IS database.
And then we'll get more specific by saying XR2.00-00,
and we'll ask for the detail.
Now the first thing to note is under the area addresses,
we have metrics to get to its neighbors.
So we can see that it says it has
a metric of 10 to get to router 5 as well as a metric of 10
to get to router 1.
By the way, we have not changed any of the metrics on router 1.
So it's also 10 for router 1 to get to router 2,
although we're not looking at that database
right this moment.
Also notice that router 2 is listing its attached
interfaces, including, for example,
it's 10..2.2.2/32 loopback also with a metric of 10.
Remember that in Cisco iOS, the default for all links is 10.
But what happens if we go change that on router 2?
Let's take a look.
So we jump over to router 2.
We'll simply go in and configuration.
We'll go into our IS-IS instance for our interface loopback 0,
specifically for the address family IPv4.
And we'll simply set the metric.
We're going to set it to 5, but just so we see the range here
depending on whether we're doing narrow or wide metrics.
We're, of course, doing wide metrics.
So we could go all the way up to, well, that big number.
And what we're going to do is, like I said,
we're just going to set it low.
We're going to set it to 5.
But we can see that there is a wide range of numbers
that we can use, particularly if we're on wide metrics.
Let's commit those changes.
We'll exit out of configuration.
And let's go back to router 1 and see what's changed.
So on router 1, if we simply look at the detail for router 2
again, what we see specifically is
that the metric for that loopback is now 5.
And if we were to say, show IP route for IS-IS and we look
specifically at that 10.2.2.2, we see it now has a metric
of 15--
10 to get to router 2 itself and then 5 for the loopback.
So we can see how this information in the database
can, of course, be changed and propagated to other devices
as well as, of course, being used
to propagate the routing table.
In this video, we jumped in and we took a closer look
at the IS-IS database.
Then, of course, we made a change.
We saw how that got propagated to the neighbors, which
of course, it should--
wouldn't be much of a routing protocol if it didn't--
but then how that information is also, of course,
reflected right into the routing table exactly as it should be.
I hope this has been informative for you.
And I'd like to thank you for viewing.