|
0:00:12
|
So, let's take a look at the command line here.
|
|
0:00:15
|
And what I'm gonna do first is just enable the OSPF process on all of the routers,
|
|
0:00:20
|
and we'll put all of the interfaces in area zero.
|
|
0:00:24
|
Now, area zero is going to be the backbone area for OSPF
|
|
0:00:28
|
that all of the other non-backbone areas will have to transit through
|
|
0:00:34
|
in order to reach each other.
|
|
0:00:36
|
So, in any design that we have more than one OSPF area,
|
|
0:00:40
|
we will need are zero in the middle.
|
|
0:00:42
|
But if we were to only use a single area for OSPF ,
|
|
0:00:46
|
it technically could be any value.
|
|
0:00:48
|
So, I coudld run area 1 on everyone
|
|
0:00:50
|
as long as there are not multiple areas anywhere in the topology.
|
|
0:00:56
|
So, from the access server here, I'm gonna use the send command.
|
|
0:01:01
|
And I'll say to everyone "I want to run the router OSPF process 1."
|
|
0:01:07
|
And I'll simply to put a network statement for everything.
|
|
0:01:10
|
So, we'll say Network 0.0.0.0,
|
|
0:01:13
|
the wildcard masks is all 255s.
|
|
0:01:17
|
And every interface is in area zero.
|
|
0:01:23
|
So, this is a quick simple way to enable OSPF on all the interfaces.
|
|
0:01:28
|
The disadvantage of this of course would that be...
|
|
0:01:31
|
you don't have a lot of control as to what links are or are not running the process.
|
|
0:01:37
|
So, essentially any interfaces that now has an IP address assigned,
|
|
0:01:40
|
OSPF area zero is gonna be on it.
|
|
0:01:43
|
So, if we look at router 1 from the diagram,
|
|
0:01:47
|
we see that it has three interfaces:
|
|
0:01:48
|
the Fast Ethernet that goes routers 4 and 6;
|
|
0:01:52
|
the point-to-point link to router 3, and then the frame-relay interface that connects to router 5, the hub.
|
|
0:01:59
|
So, on router 1, if we look at the Show IP OSPF,
|
|
0:02:03
|
this is gonna show us the basic information about the process.
|
|
0:02:07
|
It says that "We're running proces number 1."
|
|
0:02:15
|
Process number 1...
|
|
0:02:17
|
Our router ideas 150.42.1.1,
|
|
0:02:21
|
which was derived from our loopback zero interface.
|
|
0:02:26
|
So, in this case, for today's demos, I'm on rack 42.
|
|
0:02:29
|
So, router 1 is 150.42.1.1.
|
|
0:02:36
|
Some of the optional capabilities we see it supports which is the Opaque LSA,
|
|
0:02:40
|
the link local signaling,
|
|
0:02:43
|
these would be for as I mentioned, like the traffic engineering extensions,
|
|
0:02:46
|
or for the nonstop forwarding is signaled to the link local signaling.
|
|
0:02:51
|
The area transit capability is enabled.
|
|
0:02:54
|
We'll talk a little about that later.
|
|
0:02:56
|
It has to do with virtual links
|
|
0:02:58
|
and how you do a path selection when you have a path over a virtual link
|
|
0:03:03
|
versus a non-area zero transit area in order to reach the destination.
|
|
0:03:11
|
The router is not originating the router LSA's with the maximum metric.
|
|
0:03:16
|
This would be used for the OSPF stub router advertisement feature,
|
|
0:03:22
|
which we'll see is used along with on nonstop forwarding typically
|
|
0:03:27
|
to take a router out of service,
|
|
0:03:30
|
but not have all the routers start to drop traffic in the data plane.
|
|
0:03:36
|
So, if I have a router in the core of the network, then I need to do maintenance on,
|
|
0:03:39
|
and I want to take it out of service,
|
|
0:03:41
|
the first things I would do is set the router LSA to start advertising the maximum metric,
|
|
0:03:46
|
which would mean that other devices would we route around me.
|
|
0:03:51
|
Then, once I'm no longer in the transit path for devices,
|
|
0:03:54
|
then, I could turn the router off or upgrade its IOS.
|
|
0:04:00
|
We also see the default timers for SPF...
|
|
0:04:04
|
says "Your initial delay is 5,000 milliseconds."
|
|
0:04:09
|
It says, "The minimum hold time between two consecutive SPF runs would be 10 seconds.
|
|
0:04:16
|
The maximum wait time between them is also 10 seconds."
|
|
0:04:21
|
So, this is a convergence optimization
|
|
0:04:23
|
that says "If I receive topology change and I start to run OSPF,
|
|
0:04:29
|
or start to run the SPF process",
|
|
0:04:31
|
then, another topology change occurs,
|
|
0:04:34
|
I"m gonna have to wait another 10 seconds before I actually rerun the process.
|
|
0:04:39
|
So, giving a delay for the SPF process usually makes OSPF converge faster.
|
|
0:04:45
|
Then, if it were to run SPF on the reception of every single LSA change in the network.
|
|
0:04:54
|
So, most of the timer stuff here, we'll talk about later.
|
|
0:04:58
|
These would just be minor optimizations of OSPF that you would change by setting these.
|
|
0:05:07
|
It says, "The area backbone which is zero has...
|
|
0:05:12
|
four interfaces.
|
|
0:05:15
|
From this particular router, one of them is a loopback.
|
|
0:05:17
|
We're not running authentication.
|
|
0:05:22
|
There is no do not age LSAs,
|
|
0:05:26
|
or demand circuit bit set. We'll talk about that stuff later,
|
|
0:05:29
|
but the main verifications that you wanna see from here
|
|
0:05:35
|
is just what's the process number, what's the router ID.
|
|
0:05:38
|
Then, if we look at the Show IP OSPF Interfaces,
|
|
0:05:43
|
this is gonna show us all the detail about the link level attributes of OSPF.
|
|
0:05:49
|
So for example, on the point-to-point link that goes over to router 3,
|
|
0:05:53
|
it says, "This is the address that I have assigned. This is my area.
|
|
0:05:58
|
This lin is running process ID 1, which is using this router ID.
|
|
0:06:02
|
The network type is point-to-point."
|
|
0:06:06
|
So, this would then mean on the other end of the link,
|
|
0:06:09
|
they would have to be running some sort of network type that is compatible with point-to-point.
|
|
0:06:14
|
Which would be point-to-point, point-to-multipoint or point-to-multipoint non-broadcast.
|
|
0:06:20
|
OSPF cost value is 64,
|
|
0:06:23
|
which is derived from the interface's bandwidth,
|
|
0:06:27
|
where the higher the bandwidth, the lower the cost value.
|
|
0:06:32
|
Then, we see some of the default timers, like the transit delay, the hello interval is 10 seconds by default,
|
|
0:06:37
|
the dead interval is 40 seconds.
|
|
0:06:42
|
It says that "We have one neighbor.
|
|
0:06:45
|
We have one adjacency'
|
|
0:06:48
|
where technically, there can be a difference between the neighbors and the adjacencies,
|
|
0:06:54
|
and the router ID of that neighbor who we're adjacent with is 150.42.3.3.
|
|
0:07:02
|
So again, this is gonna show us all the details that we would want about the interfaces.
|
|
0:07:07
|
If we just wanna see overall summary...
|
|
0:07:09
|
of what links are running the process,
|
|
0:07:12
|
we can look at the Show IP OSPF Interface Brief.
|
|
0:07:17
|
So, in this case, we see that there are four interfaces running OSPF,
|
|
0:07:22
|
they are the loopback, the point-to-point serial,
|
|
0:07:25
|
the frame-relay, the Fast Ethernet,
|
|
0:07:27
|
they're all in process one, they're all in area zero.
|
|
0:07:31
|
These are their addresses and masks.
|
|
0:07:33
|
These are the cost values.
|
|
0:07:35
|
This is the state of the adjacency.
|
|
0:07:39
|
So, in the case of the loopback, this is in the loopback network type.
|
|
0:07:44
|
The serial 0/1 is running a point-to-point adjacency
|
|
0:07:50
|
on the frame-relay interface, we are the designated router, but there's actually no neighbors on that link.
|
|
0:07:56
|
Then, on the Ethernet, we are neither the DR nor the BDR,we are a drother.
|
|
0:08:02
|
And there are two neighbors on that link.
|
|
0:08:08
|
So, simply based on this output here, Show IP OSPF Interface Brief,
|
|
0:08:12
|
it's gonna tell me that there's something wrong with the OSPF process on serial 0/0.
|
|
0:08:18
|
If this link is supposed to be transit that is going to other routers,
|
|
0:08:22
|
then ideally, they should be forming the adjacencies.
|
|
0:08:26
|
So, we'll get into the details and a little bit with that.
|
|
0:08:29
|
The reasons is gonna have to do with the default network type that the...
|
|
0:08:34
|
frame-relay interface is running and we can see it right here, it's running the network type non-broadcast.
|
|
0:08:39
|
Now, if we were to have any problems with the adjacency due to...
|
|
0:08:44
|
mismatch parameters,
|
|
0:08:46
|
let's say for example that on the link between router 1 and router 3,
|
|
0:08:51
|
my IP OSPF hello interval is different than theirs.
|
|
0:08:55
|
IP OSPF hello interval...
|
|
0:08:59
|
Let's say is 5 seconds.
|
|
0:09:01
|
If we were then to look at the Debug IP OSPF Adjacency,
|
|
0:09:06
|
we should see that when router 1 and router 3 are exchanging packets over that link,
|
|
0:09:12
|
they're not gonna be able to form an adjacency.
|
|
0:09:16
|
So, let's look of the Show Debug IP OSPF Adjacency, events are on.
|
|
0:09:20
|
If we Show Log,
|
|
0:09:24
|
we are logging to the console.
|
|
0:09:27
|
So, let's reset the process here. So, let's say Clear IP OSPF Process.
|
|
0:09:45
|
So, we see some of these adjacencies
|
|
0:09:48
|
have occurred like on the Fast Ethernet link, it says like,
|
|
0:09:51
|
"We have adjacency with router 6 and with route 4."
|
|
0:09:55
|
So we receive link state updates from them.
|
|
0:09:59
|
The LSA count, that's how many link state advertisements they're generating.
|
|
0:10:03
|
Right now, since everyone is in the same area,
|
|
0:10:06
|
each router is only generating one LSA,
|
|
0:10:09
|
which is the router LSA describing all of their links.
|
|
0:10:14
|
So, even though the routers have multiple interfaces running OSPF,
|
|
0:10:18
|
like the loopbacks, the Ethernet, the point-to-point links,
|
|
0:10:21
|
all of that information is contained inside the single router LSA
|
|
0:10:27
|
that is generated by each router for each area that they are a part of.
|
|
0:10:32
|
So, if we have an ABR that's running in area zero and area 1,
|
|
0:10:35
|
it means that we'll have one of router LSA generated for area zero,
|
|
0:10:39
|
then, another router LSA generated for area 1.
|
|
0:10:43
|
If we look at now the Show IP OSPF...
|
|
0:10:47
|
Neighbors,
|
|
0:10:50
|
this is gonna check our adjacency status.
|
|
0:10:52
|
We see that we have the adjacencies with router 4 and 6.
|
|
0:10:57
|
So, router 1 to router 4, router 1 to router 6,
|
|
0:11:01
|
but we don't have an adjacency with router 3 or router 5.
|
|
0:11:06
|
Now, router 5's case, we'll talk about that later over the frame relay,
|
|
0:11:10
|
but if we look at the adjacency with router 3,
|
|
0:11:14
|
and go to router 3 and look at the Debug IP OSPF Adjacency,
|
|
0:11:21
|
we should see the hello packets coming in between the neighbors.
|
|
0:11:25
|
If also, we were to look at the Debug IP OSPF Hello,
|
|
0:11:30
|
we should see that router 1 router 3 are actually receiving each other's hello packets,
|
|
0:11:37
|
but we could see, it says, "Mismatched hello parameters from router 1."
|
|
0:11:41
|
The dead interval received versus my dead interval configured,
|
|
0:11:47
|
they have 20 configured, I have 40 configured.
|
|
0:11:50
|
Where the hello interval received is 5, and I have configured as 10,
|
|
0:11:55
|
so we're not gonna be able to form an adjacency.
|
|
0:12:01
|
If on of the link here, let's say that the MTU was different.
|
|
0:12:06
|
Let's say, our MTU is a hundred bytes.
|
|
0:12:11
|
So, I'll say No IP OSPF Hello Interval.
|
|
0:12:15
|
So we'll revert that back to the default.
|
|
0:12:17
|
We then should see in the debug between these two
|
|
0:12:23
|
that there is a mismatch in the MTU.
|
|
0:12:29
|
So, once we actually go to exchange the LSA's,
|
|
0:12:33
|
we'll see that in the Database Descriptor Packet or the DDP,
|
|
0:12:37
|
there's a field in there that specifies what the MTU value is.
|
|
0:12:41
|
But since their MTU is a hundred, my MTU is different than that,
|
|
0:12:44
|
we're not able to form the adjacency.
|
|
0:12:48
|
One of the outputs that we would see from this...
|
|
0:12:52
|
is that a log messages is gonna show up that says
|
|
0:12:54
|
that there's too many database descriptor detransmissions,
|
|
0:12:59
|
where in the database descriptor,
|
|
0:13:02
|
that's gonna tell the other routers, what are the LSA's that are in my database?
|
|
0:13:08
|
and what is the MTU of the link that I'm actually transiting over?
|
|
0:13:12
|
So eventually, these routers are gonna time the adjacency out,
|
|
0:13:16
|
and we would see that message that says there's too many retransmissions,
|
|
0:13:19
|
we have to shut the neighbor down.
|
|
0:13:21
|
If we look at the Show IP OSPF Neighbors,
|
|
0:13:27
|
we could see that router 3 and router 1, they are stuck in the X-start state.
|
|
0:13:32
|
So, X-start is were we're trying to start the exchange of the actual database.
|
|
0:13:38
|
We first do that by telling each other what does the database look like.
|
|
0:13:43
|
So, we don't give them the details about the LSA's themselves,
|
|
0:13:46
|
we just say "I have LSA is 1, 2, 3 and 4, and these are the properties.
|
|
0:13:51
|
This is the age of it. This is the checksum."
|
|
0:13:53
|
Then, if you need some of these LSAs,
|
|
0:13:56
|
you can send me a link state request, and I'll send you a link state update.
|
|
0:14:00
|
That would happen during the exchange phase.
|
|
0:14:04
|
But since we're not proceeding pass X-start,
|
|
0:14:07
|
it means that there's some attribute
|
|
0:14:10
|
that the neighbors are not agreeing on.
|
|
0:14:12
|
And in this particular case, we know what it is. It's that the MTUs are not matched.
|
|
0:14:18
|
So, these two debugs, the Debug IP OSPF Adjacency,
|
|
0:14:22
|
and the Debug IP OSPF Hello,
|
|
0:14:26
|
these are going to be a good indication of any of those initial problems
|
|
0:14:30
|
where we're trying to start the adjacencies.
|
|
0:14:33
|
So, if the authentication is mismatching, if the stub flags are mismatching,
|
|
0:14:38
|
if there's duplicate router ID's, if there's duplicate addressing, they're on the wrong subnet,
|
|
0:14:44
|
pretty much, these two debugs are gonna show all of those problems exactly clearly what they are.
|
|
0:14:50
|
So, it says before the timers were wrong.
|
|
0:14:52
|
Now, it says the MTU is wrong.
|
|
0:14:56
|
So again, the reason that you would want to do this
|
|
0:15:00
|
is if you're trying to troubleshoot an OSPF network,
|
|
0:15:03
|
a lot of the times, it's easier to look at what are the results of the configuration
|
|
0:15:08
|
as opposed to what are the actual commands in the running config.
|
|
0:15:14
|
Because at least in my experience, it takes me longer to try to debug a configuration,
|
|
0:15:19
|
to try to solve a problem as opposed to looking at one of the results of that,
|
|
0:15:23
|
and would've a different debugs and show commands giving me
|
|
0:15:27
|
as more information about the state of the network.
|
|
0:15:36
|
So, on router 1, let's remove the MTU command.
|
|
0:15:40
|
And we should see that
|
|
0:15:44
|
the now to go back into the full state.
|
|
0:15:48
|
So if we were to look at other portions of the network, let's say that we look at...
|
|
0:15:53
|
switch 1, switch 1 should be forming an adjcency with router 6, router 3, and switch 3.
|
|
0:16:02
|
On, switch 1, if we look at the Show IP OSPF Interface Brief,
|
|
0:16:06
|
we see that OSPF is not running on any interface.
|
|
0:16:11
|
Okay, the reason why, you can see it a little bit further up here.
|
|
0:16:14
|
I tried to run the OSPF process, but IP routing is not on.
|
|
0:16:19
|
So I would wanna spend half an hour troubleshooting reachability
|
|
0:16:25
|
before checking that the OSPF process was actually enabled on the device.
|
|
0:16:29
|
So now, I'll just need to go back. I'll send the OSPF commands again,
|
|
0:16:34
|
but I'm gonna send first turn IP routing on.
|
|
0:16:37
|
Then, Run OSPF 1.
|
|
0:16:41
|
Then, I'll put every interface in...
|
|
0:16:46
|
in area zero.
|
|
0:16:54
|
So now, once switch 1 receives this,
|
|
0:16:57
|
we should see that this is gonna establish some adjacencies.
|
|
0:17:00
|
So, it says, "The neighbor that has the router ID of 150.42.6.6, we're adjacent with them."
|
|
0:17:07
|
So, we went into the full adjacency state.
|
|
0:17:11
|
Then, router 3,
|
|
0:17:13
|
on the point-to-point Ethernet to them, we're adjacent.
|
|
0:17:17
|
Then, we should see within 30 seconds or so, we would establish the adjacency with switch 3 as well.
|
|
0:17:24
|
So, if we look at Show IP OSPF Neighbors,
|
|
0:17:28
|
we see that we are in the two-way state,
|
|
0:17:31
|
where two-way means that switch one sent the hello to switch 3,
|
|
0:17:39
|
and inside of the hello,
|
|
0:17:43
|
it says "My router ID is whatever A.B.C.D."
|
|
0:17:50
|
Switch 3 then responded with its hello...
|
|
0:17:54
|
saying that "My router ID is E.F.G.H." And the other router IDs include A.B.C.D.
|
|
0:18:10
|
So, in the hello packet,
|
|
0:18:12
|
OSPF uses this as in the acknowledgement
|
|
0:18:15
|
to say that I have received your hello packet as well.
|
|
0:18:19
|
So, when the router are in the two-way state, it means that I sent them my hello,
|
|
0:18:23
|
and they acknowledged this
|
|
0:18:25
|
by replying with their own hello with my router ID in the packet.
|
|
0:18:31
|
So once we go pass the two-way state,
|
|
0:18:33
|
then we should see we go to X-start, exchange, and then, finally into the full state.
|
|
0:18:38
|
So now, when we Show IP OSPF Neighbors,
|
|
0:18:41
|
this is what we wanna see, that the neighbors are actually in the full state.
|
|
0:18:47
|
We also see what are their router IDs.
|
|
0:18:50
|
What is their OSPF priority.
|
|
0:18:53
|
Whether they are the DR, the BDR, a drother, or none of those.
|
|
0:19:00
|
So, if we see a dash there,
|
|
0:19:01
|
it would mean we're running a network type that doesn't use the DR and BDR election.
|
|
0:19:08
|
We see how much time is left in the dead timer.
|
|
0:19:10
|
What's the address they have assigned in the interface,
|
|
0:19:13
|
and then what's actually link that they form the adjacency with.
|
|
0:19:18
|
So, if we were to look at the same output on the routers between...
|
|
0:19:26
|
1, 4, and 6,
|
|
0:19:28
|
we should see that one of these neighbors is the DR;
|
|
0:19:31
|
one of them is the BDR;
|
|
0:19:33
|
and whichever one is left over is going to be the drother.
|
|
0:19:36
|
So, it's neither the DR nor the BDR.
|
|
0:19:40
|
If we look at router 1 and look at this with the Show IP OSPF Neighbors,
|
|
0:19:45
|
it says that router 4 is the BDR,
|
|
0:19:48
|
router 6 is the DR,
|
|
0:19:51
|
which would then mean that I am a drother. So, I'm not the DR, I'm not the BDR.
|
|
0:19:58
|
Then, for the adjacency to router 3, we see the dash here.
|
|
0:20:01
|
It means that they are running some network type that does not use
|
|
0:20:05
|
the OSPF DR BDR election.
|
|
0:20:08
|
So, it would either be point-to-point, point-to-multipoint,
|
|
0:20:10
|
or point-to-multipoint non-broadcast.
|
|
0:20:14
|
So, we should be able to assume up to this point that we...
|
|
0:20:18
|
have formed the adjacencies on every link
|
|
0:20:21
|
with the exception of the hub and spoke frame-relay network
|
|
0:20:25
|
between routers 1, 2, 3, 4, and 5.
|
|
0:20:30
|
This is gonna be based simply on the fact
|
|
0:20:32
|
that we have a default network type
|
|
0:20:37
|
that is nonbroadcast.
|
|
0:20:39
|
And we're gonna have to go through some additional steps to establish the adjacency between those neighbors.
|
|
0:20:45
|
But even with that link out of the pitcher,
|
|
0:20:49
|
so without using a frame-relay,
|
|
0:20:51
|
we should be able to...
|
|
0:20:54
|
have the adjacencies established between the other neighbors.
|
|
0:20:57
|
And build the OSPF database.
|
|
0:21:01
|
So, at this point, the network is gonna look like this without the frame-relay.
|
|
0:21:07
|
Now, from any of these routers in the topology,
|
|
0:21:11
|
if we were to look at the Show IP OSPF Database,
|
|
0:21:13
|
we should see that everyone has the identical information
|
|
0:21:17
|
about who are all the routers in the topology,
|
|
0:21:20
|
and what are the connected links that they are advertising.
|
|
0:21:24
|
This is what we would see in the router LSA. The LSA number 1.
|
|
0:21:30
|
Then additionally, for any segments that are running the DR and BDR election,
|
|
0:21:36
|
the designated router will be generating the network LSA.
|
|
0:21:42
|
Now, the network LSA is an optimization of the basically the search function
|
|
0:21:48
|
of the SPF algorithm,
|
|
0:21:51
|
where it's used to cut down on the amount of flooding of LSAs,
|
|
0:21:55
|
but also it simplifies the lookout
|
|
0:21:58
|
by avoiding the case where router 1 says that "I'm adjacent with router 4 and...
|
|
0:22:06
|
router 6."
|
|
0:22:08
|
Router 6 says, "I'm adjacent with router 1 and 4."
|
|
0:22:11
|
Router 4 says, "I'm adjacent with 6 and 1."
|
|
0:22:15
|
So, as the number routers start the scale on the broadcast segment,
|
|
0:22:19
|
it makes the search function more complicated when we look at this from a programmatic point of view.
|
|
0:22:25
|
So instead, what the default behavior is
|
|
0:22:28
|
is that one of these routers is going to be the designated router,
|
|
0:22:32
|
where the DR says "I'm adjacent with router 4, 1, and 6."
|
|
0:22:38
|
Based on that fact, we can assume that router 1 and 6 have connectivity.
|
|
0:22:42
|
And router 1 and 4, and router 4 and 6 have connectivity.
|
|
0:22:48
|
So, the designated router is considered a Pseudo-Node,
|
|
0:22:54
|
which is a separate logical device on the network
|
|
0:22:58
|
that is generating the advertisement about that transit network itself.
|
|
0:23:05
|
So, with just our default configuration of area zero everywhere,
|
|
0:23:09
|
we should only see two different types of LSAs in the database.
|
|
0:23:12
|
LSA Type-1 which is the router LSA;
|
|
0:23:15
|
and LSA-Type 2, which is the network LSA
|
|
0:23:19
|
generated by the designated routers.
|
|
0:23:26
|
So, if we take a look back the command line,
|
|
0:23:28
|
on router 1, let's look of the Show IP OSPF Database.
|
|
0:23:36
|
We see that there are 10 routers in the area.
|
|
0:23:39
|
So, router 1 through router 6, switch 1 through switch 4.
|
|
0:23:43
|
And there are six different network link states.
|
|
0:23:49
|
The first one here, this is LSA...
|
|
0:23:55
|
LSA 1, which is the router LSA.
|
|
0:23:58
|
The network link states, this is LSA 2.
|
|
0:24:03
|
LSA 2 is gonna tell everyone else in the network
|
|
0:24:06
|
how many links do each of these routers have,
|
|
0:24:10
|
and what are the individual properties of them.
|
|
0:24:14
|
So, whhat are the cost values,
|
|
0:24:15
|
who are the other routers that I'm adjacent with,
|
|
0:24:18
|
this is what OSPF is gonna use in order to build the graph of the topology.
|
|
0:24:24
|
Once everyone has synchronized the database and knows what the graph of the network looks like,
|
|
0:24:30
|
then, we use this as the input to the SPF algorithm
|
|
0:24:33
|
to output us with the shortest path tree.
|
|
0:24:38
|
So, the key point about link state protocol like OSPF or IS-IS,
|
|
0:24:43
|
the link state database has to be identical on everyone in the area.
|
|
0:24:48
|
Otherwise, we would result in different calculations for the shortest path tree.
|
|
0:24:53
|
But if I can assume that everyone knows exactly the same view of the network,
|
|
0:24:59
|
then, even though my calculation is independent of router 2, or router 3, or router 4,
|
|
0:25:04
|
since we have the exact same data set that's input to the algorithm,
|
|
0:25:08
|
it means that we're all gonna end up with the same output.
|
|
0:25:13
|
Now, we'll see later we get into some filtering
|
|
0:25:16
|
configurations that be the SPF logic can break down for OSPF.
|
|
0:25:22
|
And we can inadvertently cause traffic black holes
|
|
0:25:25
|
if the devices in the topology do not agree in the database.
|
|
0:25:30
|
So, within the link state area, we should always see that everyone has the same view of the topology.
|
|
0:25:35
|
It's only between the areas that the routers can have different views.
|
|
0:25:40
|
Now, if we look at the details of any of these LSA's, let's say that we wanna look at router 1,
|
|
0:25:45
|
and see what it is advertising.
|
|
0:25:48
|
We would say Show IP OSPF Database
|
|
0:25:50
|
150.42.1.1.
|
|
0:25:54
|
And actually, first, this is a router router LSA.
|
|
0:25:58
|
Show IP OSPF Database for the router LSA.
|
|
0:26:01
|
150.42.1.1.
|
|
0:26:06
|
So it says, "I'm running process number 1.
|
|
0:26:10
|
And that my router ID is 150.42.1.1.
|
|
0:26:15
|
I'm looking at the router LSA
|
|
0:26:19
|
that is being generated by...
|
|
0:26:22
|
this neighbor."
|
|
0:26:23
|
Okay, the advertising router, this is the router ID of router 1.
|
|
0:26:28
|
Router 1 is saying that I have five different links that I am advertising.
|
|
0:26:33
|
One of them is a stub network
|
|
0:26:36
|
that is 150.42.1.1 with a subnet mask of all 255's.
|
|
0:26:44
|
This stub network is my loopback zero interface.
|
|
0:26:51
|
So, by default, we'll see that the loopback interfaces for OSPF,
|
|
0:26:55
|
they're treated as stub networks in the database,
|
|
0:26:59
|
which means that they're advertised with a /32 mask.
|
|
0:27:04
|
So, regardless whether I've actually configured the mask which is /32,
|
|
0:27:07
|
that's what is gonna be inserted into the database's apps.
|
|
0:27:11
|
Also says, "The type of service is zero, the metric is 1."
|
|
0:27:16
|
This is the OSPF cost value.
|
|
0:27:22
|
Originally, the OSPF specification said you could do type of service routing,
|
|
0:27:27
|
but Cisco's implementation doesn't support that.
|
|
0:27:30
|
So really, the only thing that we care about is that
|
|
0:27:33
|
the metric value is 1 here for the link.
|
|
0:27:36
|
Okay, there's a question here, "Brian, I just said that within an area, all routers need the same database."
|
|
0:27:43
|
If an area, let's say area 2 has two entry points.
|
|
0:27:47
|
And on one entry point you filter but not the other for the purpose of traffic engineering,
|
|
0:27:52
|
would the databases in the area still be the same?
|
|
0:27:57
|
So, the question is, if we were to have an inter-area design,
|
|
0:28:02
|
let's say that we have...
|
|
0:28:05
|
let' say we have area 1 that is on the left hand portion of the network,
|
|
0:28:10
|
and then area zero everywhere else.
|
|
0:28:14
|
So between the area zero and area 1, router 4 is an ABR, router 1 is an ABR,
|
|
0:28:21
|
and router 3 is an ABR.
|
|
0:28:24
|
So, the question is, let's say for the VLAN 10 interface that switch 4 is advertising,
|
|
0:28:30
|
we could have a design were when this LSA reaches the ABRs,
|
|
0:28:36
|
that router 4 allows this in, router 1 allows this in, but router 3 does not.
|
|
0:28:43
|
So, router 3 is doing some sort of filtering for the Type-3 LSA.
|
|
0:28:49
|
In this case, this design is valid
|
|
0:28:53
|
because in area 1, all of the routers will agree that router 1 is originating the network,
|
|
0:28:59
|
4 is originating originating the network, but 3 is not.
|
|
0:29:03
|
We'll see, this is okay, because the devices in area 1,
|
|
0:29:07
|
they do not run SPF in order to reach the VLAN 10 destination.
|
|
0:29:13
|
They only need to run SPF to figure how do I get to the ABR.
|
|
0:29:17
|
Then, they'll then use whatever cause the ABR is reporting inside of the summary LSA,
|
|
0:29:22
|
which is LSA 3.
|
|
0:29:26
|
Now, where the problem would happen
|
|
0:29:29
|
would be that if this VLAN 10 is advertised...
|
|
0:29:34
|
to router 4, to router 1, and to router 3,
|
|
0:29:38
|
but then router 5 deleted it from the database,
|
|
0:29:43
|
there would be no way that the other area zero routers
|
|
0:29:47
|
would know that there's someone in the transit path that doesn't have this partiular LSA.
|
|
0:29:53
|
But for inter-area reachability, we'll see, it's a little bit different,
|
|
0:29:57
|
because the inter-area routers, they do not run SPF to reach each other.
|
|
0:30:01
|
As long as everyone within the same area agrees on the database, that's what the key point is gonna be.
|
|
0:30:07
|
So again, from router 1's output here from the Show IP OSPF Database,
|
|
0:30:11
|
it says, "This is my router ID, I have five links.
|
|
0:30:14
|
The first one here is describing the loopback."
|
|
0:30:18
|
The next one is describing the point-to-point adjacency
|
|
0:30:23
|
with this neighbor.
|
|
0:30:27
|
The interface's address that is connected to this neighbor is 155.42.13.1.
|
|
0:30:35
|
So, this now means from everyone else's perspective in the topology,
|
|
0:30:40
|
we now know that router 1 has...
|
|
0:30:45
|
a stub loopback.
|
|
0:30:48
|
And we know we have a point-to-point adjacency with router 3.
|
|
0:30:53
|
The address that router 1 has on this link is 155.42.13.1.
|
|
0:31:03
|
The cost to reach the neighbor is 64.
|
|
0:31:10
|
The cost is 64.
|
|
0:31:12
|
Then, router 1 says, "I also have a stub network...
|
|
0:31:16
|
that is the same link with the actual prefix of the link.
|
|
0:31:20
|
That is 155.42.13.0/24.
|
|
0:31:25
|
So technically, internally, these are treated as two different data structures.
|
|
0:31:30
|
The actual prefix...
|
|
0:31:33
|
versus the link to the adjacent router.
|
|
0:31:37
|
Now, the reason that they're different is that where we're doing the search function of SPF
|
|
0:31:41
|
trying to figure out who are all the routers and who are the adjacencies,
|
|
0:31:45
|
we really only care about this connection that is the point-to-point adjacency.
|
|
0:31:51
|
We don't really care that router 1 has the stub network or the stub loopback.
|
|
0:31:56
|
Those are the actual final destinations,
|
|
0:31:58
|
but those aren't the portions of the graph that we need to use to build the shortest path tree.
|
|
0:32:05
|
We'll also see this for anything that says that it is a transit network,
|
|
0:32:10
|
where a transit network...
|
|
0:32:13
|
is a link that has adjacencies...
|
|
0:32:16
|
that go to the designated router.
|
|
0:32:21
|
So, this means that this link is either network type broadcast or network type non-broadcast.
|
|
0:32:26
|
It says, "My interface's address is 155.42.146.1.
|
|
0:32:32
|
The designated router is 155.42.146.6."
|
|
0:32:38
|
So now, from everyone else in the topology,
|
|
0:32:42
|
they now also know that router 1 has adjacency
|
|
0:32:48
|
that goes to ADR.
|
|
0:32:52
|
Router 1's address on this link is 155.42.146.1.
|
|
0:33:00
|
Now, at this point, we don't know who the other adjacencies that the DR has.
|
|
0:33:05
|
So, if we're gonna build the rest of the graph,
|
|
0:33:08
|
we then need to ask the designated router, who are the other routers on that segment.
|
|
0:33:14
|
This is what the LSA 2 or the network LSA is for.
|
|
0:33:20
|
So internally, once the router see that router 1 is connected to designated router,
|
|
0:33:25
|
then, they're gonna need to know where the details about the DR's advertisement.
|
|
0:33:30
|
So, we know what the DR's address is.
|
|
0:33:32
|
We would then say, Show IP OSPF Database...
|
|
0:33:37
|
for the network 155.42.146.6.
|
|
0:33:46
|
This is a network link state in area zero.
|
|
0:33:49
|
It is being originated by the router 150.42.6.6.
|
|
0:33:55
|
So, this means that whatever device has this router ID,
|
|
0:33:58
|
they are the designated router for this segment,
|
|
0:34:01
|
and they are adjacent with the routers 150.42.6.6,
|
|
0:34:07
|
.1.1 and .4.4.
|
|
0:34:12
|
This now means, from a search point of view in the graph,
|
|
0:34:17
|
everyone now knows that this designated router connects to router 6,
|
|
0:34:21
|
and it connected to router 4.
|
|
0:34:24
|
We now know what are the router IDs of these neighbors.
|
|
0:34:31
|
So then, it means we can now do the LSA 1 lookup on them,
|
|
0:34:36
|
and see what are the links that they are advertising.
|
|
0:34:41
|
So recursively, throughout the network, until the router reaches only links that are stub networks,
|
|
0:34:47
|
we continue to search to figure out who are the adjacencies.
|
|
0:34:51
|
Whether their point-to-point or whether they are over transit links,
|
|
0:34:55
|
and if they're over transit links, then, we need to figure out who is the DR and who is it adjacent with.
|
|
0:35:01
|
Once everyone has completed the search,
|
|
0:35:04
|
they now know what the whole topology looks like, which is this.
|
|
0:35:08
|
They also know what are all the cost values.
|
|
0:35:11
|
So then, they could ultimately calculate what is the best path to reach any of these destinations.
|
|
0:35:20
|
So, if we're trying to look at why a particular router
|
|
0:35:24
|
is forwarding in a particular direction,
|
|
0:35:27
|
this is what we would need to use the database for.
|
|
0:35:29
|
Just looking at the routing table is not gonan tell us.
|
|
0:35:33
|
But the problem is if we were to compare this with like the RIP database or the EIGRP topology,
|
|
0:35:39
|
the OSPF database has a lot more detail that we need to understand how to read.
|
|
0:35:45
|
So again, when we look at this overall, Show IP OSPF Database,
|
|
0:35:50
|
first portion, the router link states,
|
|
0:35:52
|
this is everyone in the area describing what they have directly connected.
|
|
0:35:57
|
They will either have stub networks directly connected
|
|
0:36:01
|
like a loopback or a LAN segment that goes to no routers,
|
|
0:36:06
|
or they will have point-to-point adjacencies or transit adjacencies.
|
|
0:36:11
|
Where the point-to-point adjacencies would be over like a PPP link,
|
|
0:36:15
|
and the transit adjacencies would be over Ethernet or over a multipoint frame-relay.
|
|
0:36:21
|
So, depending on the OSPF network type.
|
|
0:36:24
|
If we were to look at let's say router 5,
|
|
0:36:28
|
and we Show IP OSPF Database...
|
|
0:36:32
|
Router 150.42.5.5,
|
|
0:36:42
|
router 5 says that "It has a link that is connected to a stub network
|
|
0:36:47
|
that is 155.42.5.0.
|
|
0:36:51
|
This is router 5 describing its LAN interface.
|
|
0:36:58
|
So, even though this is network type broadcast by default,
|
|
0:37:02
|
since there no adjacencies on that,
|
|
0:37:04
|
it's considered the edge of the SPF graph.
|
|
0:37:09
|
So, we're telling the other routers,
|
|
0:37:10
|
"You do not need tocontinue to search out this link, because there's no adjacencies."
|
|
0:37:16
|
However, on the link that connects to switch 2,
|
|
0:37:18
|
there are potentially other routers there,
|
|
0:37:21
|
but I don't know who they are.
|
|
0:37:23
|
The designated router would know that so then you need to ask them.
|
|
0:37:32
|
Now, in designs where the network is using only point-to-point links,
|
|
0:37:37
|
you would not want the database
|
|
0:37:40
|
to have to maintain these additional network link states.
|
|
0:37:43
|
So, in a real production design,
|
|
0:37:45
|
if you are only using point-to-point serial like Packet over Sonnet links,
|
|
0:37:50
|
and point-to-point Ethernet
|
|
0:37:51
|
like GigE or 10 GigE that is plugged directly between two routers,
|
|
0:37:56
|
you would want to disable the generation of the network link state
|
|
0:38:01
|
by doing what?
|
|
0:38:05
|
what could we do here to tell the routers not to generate...
|
|
0:38:09
|
the LSA 2?
|
|
0:38:14
|
A good example in our design...
|
|
0:38:17
|
would be on the link between...
|
|
0:38:20
|
switch 2 and switch 4,
|
|
0:38:22
|
or between switch2 and router 5.
|
|
0:38:26
|
If there's only two routers on that segment,
|
|
0:38:29
|
then, we wouldn't need to generate the designated router's advertisement.
|
|
0:38:32
|
So, if we were to set these network types to point-to-point,
|
|
0:38:37
|
then the advertisement of this
|
|
0:38:40
|
would change from the database's point of view,
|
|
0:38:43
|
where it would say that this link on my connection to switch 2,
|
|
0:38:50
|
it's not a transit network, it would be a point-to-point adjacency.
|
|
0:38:53
|
So then, from the the programmatic point of view of the SPF search engine,
|
|
0:39:00
|
it's not gonna have to do a second lookup on the network LSA
|
|
0:39:03
|
before it figures out that the only other router adjacent there is switch 2.
|
|
0:39:10
|
So, if we were to go the link on router 5 here,
|
|
0:39:15
|
and say "On Fast Ethernet 0/0,
|
|
0:39:21
|
the IP OSPF network is point-to-point."
|
|
0:39:25
|
And do the same thing on switch 2's VLAN 58.
|
|
0:39:29
|
IP OSPF Network Point-to-Point.
|
|
0:39:34
|
We should now see that from the other routers in the topology,
|
|
0:39:39
|
so from router 1's point of view,
|
|
0:39:40
|
when it examines the router LSA that router 5 is generating,
|
|
0:39:46
|
router 5 will no longer advertise this is a transit network.
|
|
0:39:51
|
This is now a point-to-point adjacency
|
|
0:39:54
|
that goes to record to that particular neighbor.
|
|
0:39:59
|
So, the advantage of this from a programmatic point of view
|
|
0:40:02
|
is that we know there's only one neighbor on the link.
|
|
0:40:05
|
We don't need to do another recursive lookup on the LSA 2
|
|
0:40:08
|
to figure out is this a multipoint segment that has more than two routers on the link.
|
|
0:40:15
|
So, at this point, once we know that the OSPF process is enabled,
|
|
0:40:19
|
that the neighbors have formed the adjacencies,
|
|
0:40:22
|
we also verified that everyone has populated database,
|
|
0:40:25
|
then, OSPF is actually going to install the routes in the table.
|
|
0:40:29
|
So, once SPF is done, and it comes out with the shortest path tree,
|
|
0:40:33
|
those are the links that actually can go into the forwarding table.
|
|
0:40:37
|
So, the result of those just like it would be in RIP or EIGRP...
|
|
0:40:41
|
is gonna be just to look at the Show IP Route.
|
|
0:40:47
|
Now, in this case, since all of the routers are in the same area,
|
|
0:40:53
|
it means that all of these links...
|
|
0:40:56
|
or all of these are routes are gonna be considered intra-area routes.
|
|
0:41:01
|
So, when we look at the the key at the top of the routing table output,
|
|
0:41:06
|
the upper case "O", this is OSPF intra-area.
|
|
0:41:11
|
So, it's routes within our own area.
|
|
0:41:15
|
This would be all the transit links between the routers.
|
|
0:41:19
|
Then, all of the loopbacks,
|
|
0:41:22
|
where we'll see that the loopback by default are treated as the stub networks.
|
|
0:41:27
|
So, all the loopbacks are being advertised /32
|
|
0:41:31
|
even if that's not the actual native mask on the link.
|
|
0:41:36
|
Now, in a real design, typically, your loopback would be /32,
|
|
0:41:41
|
because there's no reason to assign
|
|
0:41:43
|
anything more than does one address as a loopback,
|
|
0:41:47
|
but in our case were doing them as /24's.
|
|
0:41:50
|
So, we could tell the router to stop treating that as a loopback
|
|
0:41:54
|
and treat it as the normal native mask that's on the interface.
|
|
0:41:58
|
So, if we wanted to do that,
|
|
0:41:59
|
that would be the IP OSPF Network Point-to-Point command at the loopback interface.
|
|
0:42:06
|
So, if I were to go to...
|
|
0:42:07
|
let's say switch 4 here.
|
|
0:42:10
|
And on loopback zero, say IP OSPF Network Point-to-Point.
|
|
0:42:15
|
When, we look at the result of this in router 1's routing table,
|
|
0:42:23
|
we see now 150.42.10.0/24 appears
|
|
0:42:29
|
as opposed to the previous 10.10/32.
|
|
0:42:35
|
So, it is not really gonna make a difference in the routing of traffic.
|
|
0:42:38
|
We will to look at a case later when we get to Layer 3 MPLS VPNs
|
|
0:42:43
|
that if the IGP route
|
|
0:42:46
|
does not match the mask of the actual connected interfaces,
|
|
0:42:50
|
we can have a label distribution protocol label allocation failure,
|
|
0:42:57
|
which means that we wouldn't be able to generate a label number for that loopback.
|
|
0:43:03
|
So, that gonna be outside of the scope of just regular OSPF.
|
|
0:43:07
|
We'll talk about that when we get to MPLS,
|
|
0:43:09
|
but it is an important point to note that the loopback is always advertised /32 by default.
|
|
0:43:15
|
Even if it is not actually configured as that.
|
|
0:43:18
|
So now, when we look at the database, if we Show IP OSPF Neighbor,
|
|
0:43:22
|
or Show IP OSPF Database.
|
|
0:43:24
|
For the router 150.42.10.10,
|
|
0:43:31
|
this network...
|
|
0:43:33
|
or the loopback is now advertised as /24
|
|
0:43:36
|
as opposed to the /32.
|
