|
0:00:13
|
So, in our first section in OSPF,
|
|
0:00:19
|
the basic fundamentals of the protocol,
|
|
0:00:23
|
how do we deal with adjacencies
|
|
0:00:26
|
Then, we'll get into some more of the
|
|
0:00:30
|
the filtering authentication, and all o
|
|
0:00:35
|
Now, definitely, this would
|
|
0:00:39
|
the core topics within the routing
|
|
0:00:42
|
So, you really do need to be an expert on
|
|
0:00:47
|
Now, we'll see, some of these stuff is gonna
|
|
0:00:52
|
like how we deal with issues with
|
|
0:00:56
|
Not so stubby area, translator elections.
|
|
0:01:00
|
That type of stuff, you don't really
|
|
0:01:04
|
as long as you know what
|
|
0:01:06
|
and then what are the commands that
|
|
0:01:10
|
in order to work through
|
|
0:01:17
|
So, to start as a general overview of OSPF,
|
|
0:01:21
|
it is an open standards protocol.
|
|
0:01:23
|
If you look at RFC 2328,
|
|
0:01:26
|
that's gonna give you any of the real detailed
|
|
0:01:30
|
like what are the packet formats, how does
|
|
0:01:36
|
how does the path selection
|
|
0:01:38
|
So, we're not gonna get into that
|
|
0:01:43
|
but if you need to know that for some reason,
|
|
0:01:48
|
Also, the person that actually
|
|
0:01:54
|
who is John Moy.
|
|
0:01:57
|
There are a few books that he also wrote on...
|
|
0:02:02
|
OSPF
|
|
0:02:03
|
One is the OSPF implementation.
|
|
0:02:06
|
This is OSPF from a programmatic point of view.
|
|
0:02:09
|
So, this would be outside of our
|
|
0:02:12
|
you actually try to write an implementation of OSPF.
|
|
0:02:15
|
But there's also another book by him that is
|
|
0:02:21
|
So, this is the theory behind OSPF,
|
|
0:02:24
|
the problems that he was trying to solve
|
|
0:02:27
|
versus RIP or RIP Version 2 when writing a OSPF.
|
|
0:02:32
|
So, this gonna have a lot of the
|
|
0:02:36
|
similar to the RFC, because if we look at...
|
|
0:02:41
|
RFC 2328, which is OSPF Version 2,
|
|
0:02:46
|
you see that ths gentleman was
|
|
0:02:50
|
So, it's gonna be similar between the...
|
|
0:02:52
|
the two points of these. The RFC and the book
|
|
0:02:58
|
Other good resources for OSPF would be...
|
|
0:03:02
|
Routing TCP IP Volume 1.
|
|
0:03:05
|
There's a lot of good coverage in
|
|
0:03:11
|
There's another book that I don't
|
|
0:03:17
|
it is by Alex Zinin and...
|
|
0:03:23
|
It says, Cisco IP Routing.
|
|
0:03:27
|
This one here Packet Forwarding
|
|
0:03:31
|
This is a lot a good detailed information
|
|
0:03:40
|
A lot of good coverage of EIGRP and OSPF,
|
|
0:03:44
|
and the other protocols.
|
|
0:03:45
|
A lot of just basic logic about how
|
|
0:03:50
|
So if you've already gone through like the Jeff Doyle book,
|
|
0:03:56
|
this one definitely is a very good resource there.
|
|
0:03:58
|
Now, some of the attributes that we'll talk about...
|
|
0:04:01
|
within the scope of OSPF today.
|
|
0:04:03
|
Now, we know that it is a link state protocol
|
|
0:04:08
|
which is gonna have some effects on the
|
|
0:04:14
|
as we compare this to RIP or EIGRP.
|
|
0:04:17
|
We'll see that since OSPF forms active adjacencies,
|
|
0:04:24
|
there's some limitations as to the type
|
|
0:04:28
|
and the logic of a how we can
|
|
0:04:33
|
There's some things that are
|
|
0:04:35
|
based on how the RFC says the OSPF
|
|
0:04:40
|
and the path selection state machine works.
|
|
0:04:42
|
So, we do really need to
|
|
0:04:46
|
to get pass the really advanced
|
|
0:04:51
|
Now, since OSPF is classless, it does
|
|
0:04:55
|
There's no such thing as auto-summary
|
|
0:05:00
|
OSPF is always on the run as
|
|
0:05:05
|
We'll also see that it supports
|
|
0:05:09
|
and Network Layer Reachability
|
|
0:05:13
|
which are technically two separate topics,
|
|
0:05:17
|
where the NLRI summarization would be
|
|
0:05:23
|
where we're taking multiple subnets,
|
|
0:05:25
|
and then combining them
|
|
0:05:28
|
Like taking multiple /24 routes and
|
|
0:05:35
|
Now, the topology summarization
|
|
0:05:38
|
is gonna have to do with the logic of
|
|
0:05:43
|
different than inter-area and external lookups.
|
|
0:05:48
|
Now sometimes, OSPF is described as part
|
|
0:05:54
|
because the SPF algorithm is only to be
|
|
0:06:02
|
We'll see that when we get into
|
|
0:06:05
|
adding additional areas adding
|
|
0:06:09
|
the different types of stub areas,
|
|
0:06:10
|
there is a fundamental difference between how OSPF
|
|
0:06:14
|
does path selection on intra-area destinations
|
|
0:06:18
|
versus inter-area or external routes.
|
|
0:06:21
|
The basic configuration of OSPF
|
|
0:06:26
|
Similar to how was it EIGRP,
|
|
0:06:28
|
where our first up is that we need
|
|
0:06:33
|
Now, in OSPF, we do support multiple
|
|
0:06:38
|
These are going to be determined based
|
|
0:06:43
|
So, the process ID will be locally significant,
|
|
0:06:47
|
but when we actually configure,
|
|
0:06:48
|
either the network statement under the process,
|
|
0:06:54
|
we'll see that we could technically have multiple OSPF
|
|
0:07:01
|
Now, which interface is gonna
|
|
0:07:05
|
is gonna depend on where the
|
|
0:07:07
|
or at the interface level, what
|
|
0:07:13
|
So typically, for clarity, you would use the same
|
|
0:07:18
|
but technically, you don't have to.
|
|
0:07:20
|
As long as two routers are running
|
|
0:07:25
|
it doesn't matter what the process ID is,
|
|
0:07:27
|
because that number is not included in any of
|
|
0:07:35
|
Now, once we initialize the process,
|
|
0:07:37
|
we need to make sure that we have at
|
|
0:07:41
|
that is in the up and up state.
|
|
0:07:43
|
And this is the interface that is used
|
|
0:07:49
|
We'll see that by default,
|
|
0:07:51
|
the OSPF router ID will prefer to
|
|
0:07:55
|
but if there are no loopback
|
|
0:07:58
|
it'll take whatever the highest
|
|
0:08:02
|
So, whether this is a physical interface,
|
|
0:08:06
|
or whether it's a logical interface
|
|
0:08:09
|
we would always prefer the loopbacks
|
|
0:08:15
|
We'll also see, it is very important to make sure the
|
|
0:08:21
|
because this is what the routers use to identify
|
|
0:08:28
|
And if two or more routers are
|
|
0:08:32
|
we'll see that they will have problems trying
|
|
0:08:37
|
and then ultimately to run the SPF process.
|
|
0:08:40
|
So, once we define our global is a process,
|
|
0:08:43
|
then, we're gonna choose what interfaces
|
|
0:08:46
|
and what their area identifiers will be.
|
|
0:08:49
|
We'll see, with the OSPF areas, that's going
|
|
0:08:56
|
and also where SPF going to be run.
|
|
0:09:00
|
So, when we look at the details of actually
|
|
0:09:03
|
and how the lookups are run,
|
|
0:09:05
|
devices in area zero would not perform SPF
|
|
0:09:13
|
And likewise, devices in area 1,
|
|
0:09:16
|
their flooding domain is gonna be separate
|
|
0:09:23
|
Whether we issue the network
|
|
0:09:27
|
or the IP OSPF command at the interface level,
|
|
0:09:29
|
they're essentially going to have the same effect,
|
|
0:09:32
|
but the IP OSPF command,
|
|
0:09:34
|
the second one is probably
|
|
0:09:38
|
and little bit cleaner to read in the configuration,
|
|
0:09:41
|
because with the network
|
|
0:09:44
|
there can be some confusion as to which particular
|
|
0:09:52
|
Now, since in EIGRP, we don't have
|
|
0:09:57
|
We simply have links that the protocol is run on.
|
|
0:10:00
|
The network statement EIGRP is
|
|
0:10:05
|
because OSPF can have multiple network
|
|
0:10:11
|
When that process does occur,
|
|
0:10:14
|
whatever network statement that
|
|
0:10:17
|
towards an interface's IP address,
|
|
0:10:19
|
we'll ultimately determine what
|
|
0:10:24
|
Now, just like EIGRP, the network statement
|
|
0:10:29
|
It's simply used to match the address
|
|
0:10:34
|
So, whether we say in
|
|
0:10:39
|
that would mean that all interfaces
|
|
0:10:44
|
Then, our second statement, we're
|
|
0:10:48
|
saying that "Anything that
|
|
0:10:53
|
it is not gonna be in area zero. Anything
|
|
0:11:01
|
So, the zero in the wildcard mask is saying,
|
|
0:11:06
|
but I don't care what the other ones are."
|
|
0:11:09
|
Then likewise, our third statement here says
|
|
0:11:14
|
that'g gonna be in area 2.
|
|
0:11:16
|
Unless it starts with 1.2.3,
|
|
0:11:20
|
Then, if it is exactly 1.2.3.4,
|
|
0:11:26
|
So, you technically can do this configuration
|
|
0:11:29
|
to have multiple network statements
|
|
0:11:33
|
For clarity of the configuration, a lot of times,
|
|
0:11:39
|
It would be most accurate to
|
|
0:11:44
|
which says exactly this one
|
|
0:11:47
|
is gonna be inside aOSPF area zero,
|
|
0:11:50
|
or if we were to use the
|
|
0:11:55
|
we say IP OSPF for whatever the
|
|
0:11:58
|
Then, this link is in area zero.
|
|
0:12:01
|
We know that regardless of what
|
|
0:12:05
|
based on the interface level configuration,
|
|
0:12:12
|
Now, the only time that
|
|
0:12:15
|
between using the network statement
|
|
0:12:18
|
is that if the link were to be unnumbered,
|
|
0:12:23
|
or if it were to not have an address at all.
|
|
0:12:29
|
So, in the case of an unnumbered link,
|
|
0:12:33
|
let's say we have a serial interface that's
|
|
0:12:36
|
If the loopback has a network statement that
|
|
0:12:44
|
Then the loopback would be in area 4
|
|
0:12:46
|
plus any interfaces that are
|
|
0:12:51
|
Whereas with the link level command,
|
|
0:12:53
|
we would have to manually specify both on
|
|
0:12:58
|
what is the area that the other
|
|
0:13:03
|
But again, in the end it doesn't really
|
|
0:13:07
|
As long as what we do our basic verification,
|
|
0:13:10
|
and look at the...
|
|
0:13:13
|
Show IP OSPF Interfaces,
|
|
0:13:15
|
or Show IP OSPF Interface Brief,
|
|
0:13:18
|
that's gonna tell us what particular
|
|
0:13:25
|
Now, within this scope of the lab exam, unless
|
|
0:13:30
|
that says "Don't use the network statement
|
|
0:13:33
|
then, it's not really gonna matter
|
|
0:13:37
|
Really, the only limitation of them
|
|
0:13:39
|
is whether IOS version actually supports it.
|
|
0:13:43
|
So we'll see in a Catalyst-IOS, since running 12.2,
|
|
0:13:46
|
there's no support for the interface
|
|
0:13:51
|
whereas the routers are running 12.4T
|
|
0:13:55
|
Like EIGRP, we'll see that OSPF...
|
|
0:13:58
|
uses the hello protocol, and it uses its own transport
|
|
0:14:03
|
in order to discover neighbors in the topology.
|
|
0:14:06
|
We'll see that there's...
|
|
0:14:08
|
some more detailed differences between how
|
|
0:14:14
|
There's a lot of additional attributes
|
|
0:14:19
|
before they actually form an adjacency.
|
|
0:14:22
|
And the transport protocol number 89,
|
|
0:14:27
|
can use either two multicast addresses,
|
|
0:14:30
|
which are 224.0.0.5, and 224.0.0.6,
|
|
0:14:34
|
or the hellos could be unicast.
|
|
0:14:38
|
And we'll see, that's gonna be dependent
|
|
0:14:42
|
which is different depending on the
|
|
0:14:48
|
So we would see, with the default operation,
|
|
0:14:50
|
OSPF is gonna behave differently if
|
|
0:14:54
|
versus on Ethernet link, or a
|
|
0:15:00
|
So, from a Layer 2 design point of view,
|
|
0:15:03
|
we would need to take into
|
|
0:15:07
|
before we were choosing how to
|
|
0:15:11
|
or maybe how to configure Ethernet if
|
|
0:15:15
|
The underlying Layer 2 topology
|
|
0:15:19
|
in how OSPF is gonna perform
|
|
0:15:23
|
So, once the OSPF neighbors discover
|
|
0:15:28
|
they're going to exchange the attributes that
|
|
0:15:34
|
Now, neighbors that are adjacent
|
|
0:15:36
|
should then exchange the link state database,
|
|
0:15:40
|
which ultimately means that they can use
|
|
0:15:44
|
and come out with the Shortest
|
|
0:15:49
|
In certain cases, we'll see that not all
|
|
0:15:55
|
under normal design situations,
|
|
0:15:58
|
but also we have some sort of misconfiguration,
|
|
0:16:01
|
we could get to the point where
|
|
0:16:04
|
which ultimately means we cannot
|
|
0:16:07
|
and then cannot actually use
|
|
0:16:11
|
So, this stage in our OSPF configuration,
|
|
0:16:14
|
when we're establishing the adjacency,
|
|
0:16:16
|
this is where the vast majority of
|
|
0:16:21
|
So, if the routers do not agree on
|
|
0:16:25
|
and what their common attributes are gonna be,
|
|
0:16:31
|
then, they won't go pass the point of adjacency
|
|
0:16:38
|
Now, there's essentially only two unique
|
|
0:16:42
|
are true for the OSPF neighbors.
|
|
0:16:44
|
First would be that they have a unique router ID,
|
|
0:16:48
|
because this is the number that is going to
|
|
0:16:54
|
So, from a programmatic point of view,
|
|
0:16:57
|
the SPF algorithm builds a graph of the network,
|
|
0:17:00
|
where the routers are considered the nodes,
|
|
0:17:03
|
and the links are the vertices of a graph.
|
|
0:17:07
|
So essentially, the links that
|
|
0:17:13
|
In OSPF, we are using the router
|
|
0:17:19
|
So, if there are more than one node
|
|
0:17:23
|
then, the routers are not gonna understand
|
|
0:17:28
|
So typically, OSPF is using the logic that
|
|
0:17:32
|
we're gonna assume that you have
|
|
0:17:35
|
So, if I just choose any address
|
|
0:17:38
|
it ideally should be unique throughout
|
|
0:17:43
|
But in the case, we're doing some sort of
|
|
0:17:48
|
basic load-balancing, or any cast for multicast.
|
|
0:17:53
|
Then, we could potentially run into the case
|
|
0:17:57
|
Then, it would ultimately cause those connected
|
|
0:18:03
|
or if the devices with the duplicate
|
|
0:18:07
|
they would not be able to flood LSA's to each other.
|
|
0:18:12
|
So, it's a pretty simple check here. Once we enable
|
|
0:18:17
|
it's gonna tell us what the local router ID is.
|
|
0:18:20
|
If this happens to not be a unique value,
|
|
0:18:23
|
then, we can simply changed it. We can go into the
|
|
0:18:29
|
Whatever value that we wanna define.
|
|
0:18:33
|
The next unique attribute we would have is
|
|
0:18:38
|
So, it doesn't make sense that two routers on the
|
|
0:18:45
|
from a normal routing design point of view.
|
|
0:18:48
|
So, if there's routers on an Ethernet segment,
|
|
0:18:57
|
Now, the common attributes would
|
|
0:19:01
|
which again is going to define what
|
|
0:19:07
|
So, all routers in area zero are
|
|
0:19:11
|
We have a hello interval and the dead interval,
|
|
0:19:13
|
which are to be the timers that determine
|
|
0:19:17
|
and then, how long are we gonna wait
|
|
0:19:22
|
Again this is the opposite of how EIGRP
|
|
0:19:29
|
where the hold time and EIGRP
|
|
0:19:33
|
how long they should wait before
|
|
0:19:39
|
In the case of OSPF, the hello interval and
|
|
0:19:44
|
saying that "This is how
|
|
0:19:47
|
And this is how often I'm going to wait before
|
|
0:19:53
|
So, if there's a mismatch, either between
|
|
0:19:57
|
the routers will not able to form an adjacency.
|
|
0:20:01
|
Next, we have the interface's network address,
|
|
0:20:05
|
which is basically the subnet.
|
|
0:20:07
|
So, the routers would not be able to be
|
|
0:20:11
|
We could potentially see some problems
|
|
0:20:15
|
like for PPP,
|
|
0:20:17
|
or doing some sort of PPP IP CP negotation.
|
|
0:20:21
|
So normally, the OSPF routers would need to be
|
|
0:20:28
|
Next, we have the interfaces MTU,
|
|
0:20:32
|
which is a protection against
|
|
0:20:36
|
in which case the OSPF neighbors would not actually
|
|
0:20:43
|
So, if my interface MTU is a hundred bytes,
|
|
0:20:49
|
when you send a packet at a thousand,
|
|
0:20:51
|
I'm not gonna be able to receive
|
|
0:20:56
|
So typically, all the devices on the physical
|
|
0:21:02
|
We'll see some kind of corner
|
|
0:21:05
|
there are valid cases where the
|
|
0:21:10
|
And we'll have to go through some different
|
|
0:21:18
|
Next, we have the OSPF network type
|
|
0:21:21
|
that is going to control how OSPF
|
|
0:21:26
|
how the next hop value is calculated,
|
|
0:21:30
|
and also what particular LSA's
|
|
0:21:34
|
to do an actual calculation of a graph of the network.
|
|
0:21:38
|
Now, the network type technically does not
|
|
0:21:44
|
We'll see that it just has to be a compatible value.
|
|
0:21:48
|
Under normal circumstances, you would
|
|
0:21:51
|
but it technically doesn't have to.
|
|
0:21:54
|
So, this means that devices that are
|
|
0:21:57
|
would be able to be adjacent with
|
|
0:22:02
|
Or devices running point-to-point could be
|
|
0:22:06
|
but usually there's not any reason
|
|
0:22:12
|
Next, we have the authentication,
|
|
0:22:14
|
where obviously, if I have a different password than
|
|
0:22:19
|
We'll see that OSPF supports three
|
|
0:22:23
|
which are null, clear text and MD-5.
|
|
0:22:27
|
So by default, technically, OSPF does
|
|
0:22:31
|
It just does null authentication, or type
|
|
0:22:37
|
So, if I'm doing clear text authentication,
|
|
0:22:41
|
then, were not gonna be able
|
|
0:22:48
|
Next, we have the stub flags,
|
|
0:22:51
|
which controls what particular
|
|
0:22:55
|
the router will accept in the
|
|
0:23:00
|
So, this means that if we have area 1
|
|
0:23:04
|
all the routers in area 1 need
|
|
0:23:09
|
Likewise would be the same case
|
|
0:23:11
|
So, everyone in the NSSA
|
|
0:23:15
|
that this area is NSSA,
|
|
0:23:17
|
which is gonna change the behavior
|
|
0:23:24
|
Then lastly, we have some
|
|
0:23:28
|
Typically, these would be what is exchanged
|
|
0:23:34
|
in OSPF, where Opaque LSA is used
|
|
0:23:41
|
A good example of this would be
|
|
0:23:45
|
So if one device support traffic
|
|
0:23:49
|
then, they wouldn't be
|
|
0:23:52
|
Now, MPLS TE is gonna be
|
|
0:23:56
|
We will talk about later three MPLS VPNs,
|
|
0:23:59
|
but we're not to get into the details of traffic
|
|
0:24:05
|
So from our point of view, really, the only
|
|
0:24:09
|
is the nonstop forwarding capability of OSPF,
|
|
0:24:13
|
which is also called the "Graceful Restart".
|
|
0:24:17
|
So, it's an ability of one OSPF router
|
|
0:24:22
|
that the control plane is gonna
|
|
0:24:26
|
typically when we're doing some
|
|
0:24:30
|
or route processor redundancy
|
|
0:24:38
|
So, if one of the router supports the
|
|
0:24:42
|
then, it has to signal the other ones
|
|
0:24:46
|
So, once we establish the OSPF process,
|
|
0:24:50
|
we put either the network
|
|
0:24:52
|
or the IP OSPF command at the interface level,
|
|
0:24:55
|
then, we wanna go through a basic
|
|
0:24:59
|
is OSPF actually enabled on
|
|
0:25:02
|
and is it using the correct area identifiers?
|
|
0:25:06
|
We can see this witht the Show
|
|
0:25:11
|
or Show IP OSPF Interface Brief.
|
|
0:25:13
|
Okay, where the last one, Show IP OSPF Interface
|
|
0:25:19
|
to make sure that the router
|
|
0:25:21
|
it has OSPF enabled on the interfaces,
|
|
0:25:24
|
and they're running the correct area IDs.
|
|
0:25:28
|
Once we know the process is actually running,
|
|
0:25:31
|
then, we should establish the
|
|
0:25:35
|
So, if we Show IP OSPF Neighbor,
|
|
0:25:37
|
and we see that there's some problem between
|
|
0:25:42
|
we can look at the Debug IP
|
|
0:25:46
|
That's gonna show us the actual hello exchange
|
|
0:25:49
|
and if there's any variable that
|
|
0:25:52
|
So, maybe the MTU value, or the
|
|
0:25:57
|
We'll see different types of error messages
|
|
0:26:04
|
Then lastly, once adjacency is established,
|
|
0:26:07
|
the link state database should exchange.
|
|
0:26:09
|
And we should be able to see the calculation of
|
|
0:26:14
|
or look at the detail of an individual LSA type.
|
|
0:26:19
|
So today, we're gonna spend a bunch of time
|
|
0:26:23
|
looking at how do we read the difference
|
|
0:26:28
|
versus the network LSA originated by the DR,
|
|
0:26:32
|
or the summary LSA's that are coming
|
|
0:26:38
|
So, the database from any
|
|
0:26:42
|
we should see that we will be able to predict how
|
|
0:26:49
|
because devices in the same area should
|
|
0:26:54
|
So, let's take a look at a basic
|
|
0:26:56
|
OSPF configuration here, if we look at our...
|
|
0:27:00
|
topology to that we were using before.
|
|
0:27:03
|
Right now, I have the basic
|
|
0:27:07
|
And on all the devices on
|
|
0:27:10
|
I have been configured to
|
|
0:27:14
|
So, where in the previous example I have
|
|
0:27:20
|
but in this example everyone is using
|
|
0:27:25
|
Which then is going to imply...
|
|
0:27:28
|
that we would either need to use inverse ARP
|
|
0:27:30
|
in order to resolve our Layer 3 IP
|
|
0:27:35
|
or we would have to use the
|