So this is the topology where once again,
I'm gonna be using for IPv4 routing with OSPF version three.
Now one of the things that we wanna be aware of right on the gate is that if we
're using OSPF V3,
which is traditionally for IPv6,
if we're gonna use it with IPv4,
we need to make sure that we've enabled IPv6 on our interfaces,
because even though we're doing routing for IPv4 traffic,
behind the scenes, OSPF V3 is actually using multicast addresses for IPv6
to communicate messages back and forth between peers.
So first and foremost, make sure we have enabled IPv6 on our interfaces. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So first and foremost, make sure we have enabled IPv6 on our interfaces.
And again, that's even if we're not intending to do routing for IPv6,
we need enabled IPv6 interfaces if we wanna support OSPF V3 for the address
family of IPv4.
That also included having IPv6 unicast routing enabled.
So on each of these eight routers,
each of the interfaces already has an IPv6 address,
and IPv6 unicast routing is enabled on all eight routers.
So to configure OSPF V3 for IPv4, we'll go into configuration mode, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So to configure OSPF V3 for IPv4, we'll go into configuration mode,
then further we'll go into router configuration for OSPF V3.
By typing router, OSPF V3,
and then the process ID number that we wanna use.
So in the lab, I'm gonna simply use process ID1 across the board.
And then inside the OSPF V3 routing process configuration,
we have our address families, I'll put AF for short.
So for using IPv6, we'd have an address family for IPv6.
And if we're using IPv4, we have a separate address family for IPv4.
So in this set of videos here, we're gonna focus on the address family for IPv4 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in this set of videos here, we're gonna focus on the address family for IPv4
only.
So I'm gonna go ahead and remove the IPv6 component as we're focusing just on
IPv4.
And then here under the address family, we could go ahead and specify passive
interfaces.
If we wanna do redistribution, we could do redistribution here under the
address family for IPv4.
For example, if R1 had some static IPv4 routes,
and we wanted to redistrue those into OSPF, we would do that within the address
family.
And if we did that redistribution from a static route into the routing process
for OSPF V3 here on R1,
they would make R1 an ASBR and a ton of system boundary router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they would make R1 an ASBR and a ton of system boundary router.
And R3 and R4, because they're connected to the backbone area and also to non
backbone areas.
Router 3 and router 4 would both be ABRs, area border routers.
So let me go ahead and clean this up a little bit.
And let's talk about a few other key points.
And in previous skills, we've taken a look at the LSA types.
And so we have the common LSA types we'd normally find with IPv4.
So LSA type 1, that's the router LSA generated by each router, LSA type 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So LSA type 1, that's the router LSA generated by each router, LSA type 2.
LSA type 2 is the network LSA generated by the designated router on a segment.
If there's two or more speakers or routers on that segment,
three is the interarea prefix LSA.
Or in the traditional flavor of OSPF, it was referred to as the summary.
And those are generated by the ABRs.
So for example, these networks, the 13 network and 12 network and the 24
network and 34 network.
And those are advertised down into area 1.
We aren't sending the actual original LSAs for those, but what we're doing is,
I should say R3 is doing as the ABR, it's sending an LSA type 3 for each of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I should say R3 is doing as the ABR, it's sending an LSA type 3 for each of
those.
And it's the LSA 3s that get propagated down into the other normal areas.
Then we have LSA types 4 and 5 dealing with external routes being redistributed
into OSPF.
So the actual LSA type 5 is the route itself.
For example, we had static routes, we brought them into OSPF.
Those would be LSA type 5s.
And then the area border routers, also going to advertise an LSA type 4,
indicating how to reach the ASBR who did the redistribution.
So that identifies the ASBR and the external route.
Now normally, with just IPv4 and the traditional flavor of implementing it, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now normally, with just IPv4 and the traditional flavor of implementing it,
we wouldn't even deal with LSA types 8 and 9.
However, because we're using OSPF version 3 to support the address family for
IPv4,
there also is an 8 and a 9.
So the 8 is a link LSA and 9 is an intra area prefix LSA.
An intra meaning routes within a given area,
compared to inter area where those are routes that are going and being
advertised between areas.
So intra within, inter between.
And to become fully adjacent neighbors, the neighbors have to agree on several WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And to become fully adjacent neighbors, the neighbors have to agree on several
parameters.
And so we in the past have used STTAMP as a way to help remember some of those
parameters,
including the neighbors have to agree on what is the subnet that they're both
connected to.
So if 10, 0, 12 is the actual network and R1 thinks it's a different network,
than R2 does, they won't neighbor up.
They have to agree on the timers.
So if R1 thinks the hello interval is 11 seconds and R2 thinks it's 10 seconds,
they will not labor up.
They also have to agree on the network type.
So is it, for example, a point-to-point network like a serial interface down WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So is it, for example, a point-to-point network like a serial interface down
here,
or is it a broadcast network?
Or they can dynamically discover other OSPF speakers on the network.
So here I'll put broadcast point-to-point or point-to-multipoint
if we're using things like DMVPN.
And the key here also is that if we're using a broadcast network,
we're expecting to have a DR elected and set up.
And if we're using a point-to-point or point-to-multipoint,
we're not expecting to set up a designated router for the segment.
The A is for area.
They have to agree on the area number. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They have to agree on the area number.
So if router 1 up here believes this is area 0,
that this interface has been assigned to,
and R2 believes this is area 1,
that will cause them to not neighbor up.
Another factor that has to match is the area type.
For example, is the area a normal area, or is it a stub area?
So right here in area, let's go to area 2.
If R4 on the serial 3/1 interface believes it's a stub area,
and R6 has been configured on it's serial 3/2 to believe it's a normal area
that will also prevent them from neighboring up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that will also prevent them from neighboring up.
They also need to agree on the M-T-U.
And normally that only becomes an issue if we're dealing with, for example, a
router
and for example a multilayer switch where the M-T-U's are slightly different.
So if we have two neighbors that don't agree on an M-T-U,
we could go ahead and modify one of them,
or we could configure OSPF2, ignore that, and continue anyway.
But by default the M-T-U needs to match.
And then the P is for password.
And password is way for me to remember that authentication has to be set up
correctly.
So if they have to agree on the type of authentication they're going to use,
and if a password is set, of course that password would need to match as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and if a password is set, of course that password would need to match as well.
Let me clean this up. Let's also chat about the negotiation of a
neighbor ship. I don't think we've done too much elaboration on that yet
as part of this course.
Let's imagine that R1 and R2 have just had these two interfaces brought up at
the exact same time.
And prior to that there's no other router running OSPF on this segment.
One fun way that I used to help remind myself of the process that we're going
to go through
to form an adjacency, a full adjacency between R1 and R2 is IT-LF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to form an adjacency, a full adjacency between R1 and R2 is IT-LF.
So think about an LF like a character that works in IT, the IT-LF,
that can help us remember the sequence.
So initially we're going to have a down state between two neighbors.
And then we're going to have an I, that's the first I here in IT.
And that's the initialization or init state.
And it happens when we receive the hello packet from a neighbor.
Then the T is the two-way state.
And that's when we get a hello message from a neighbor.
And it includes our router ID.
Meaning the neighbor is indicating that it knows about us in its hello messages WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meaning the neighbor is indicating that it knows about us in its hello messages
.
And when that happens in the hello messages,
if it indicates that there's no designated router on the segment,
they'll go ahead and have an election.
So I'm going to put it right here, that they're going to have an election for
the DR.
And then the other router, if there's only two in there,
the other router will become the backup designated router.
And then as we continue the process, the next three letters are LF.
And the E reminds me of two elements.
The X start where they're beginning to negotiate their relationship
and start sending database description packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and start sending database description packets.
And then that continues to the exchange state.
And during that process, they're each identifying what they have in their
database
and what they need to share with the other.
And presuming that all goes well, the next letter here is L.
And that's the loading state.
Which involves the device sending requests to the other side,
asking for updates.
So as part of that, there's links, date, requests,
and links, date updates that are shared between those two routers.
And once that's done and we have a synchronized copy of the database,
that's when it goes to a full state,
which I affectionately refer to as a full adjacency. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which I affectionately refer to as a full adjacency.
And one method that we can use to see that in action is we could bring these
interfaces down for a moment,
gig 1, 0 here on R1 and gig 2, 0 here on R2,
and then bring them up.
And with a debug running, we could actually see the play by play what's
happening.
So let's take a moment and demonstrate that.
So R1, gig 1, 0, and R2, gig 2, 0.
So we'll get R1 here.
And I just realized they don't have OSPF configured on those two routers.
So let's do that real quick.
I'm going to go ahead and take the configuration for R1,
copy and just put it in for this demo. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
copy and just put it in for this demo.
And then we'll do the same thing for R2.
So we'll get R2, grab its config for OSPF version 3,
for address, family, IPv4, copy that, and paste that in.
All right, then on R1, we'll go ahead and do a config T,
interface, gig 1/0.
Let's make sure we have the right interface there.
We'll look at our diagram.
So up on R1, the interface going over to R2 is gig 1, 0.
And on R2 would be interface gig 2, 0.
So I'm going to go ahead and shut this down here on R1.
And we'll do a similar treatment to R2, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but going over to its interface, gig 2/0,
and typing and shut down.
So before we bring the interfaces up, let's go ahead and do a debug here on R1.
I'm going to do there because I'm in configuration mode.
And we'll do a debug, OSPF version 3, adjacency, and detail.
And it'll give us a bunch of information regarding what's going on.
And then I'm going to go ahead and bring both interfaces up at the same time.
That by just simply doing a no shut and an end and I need to add on R1 and R2.
So I'm in interface configuration mode on both routers.
So the no shut will bring both of them up at the same time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the no shut will bring both of them up at the same time.
So we'll go ahead and send that out.
And then we'll watch the debugs.
And here they go.
And I'm going to wait.
It's going to take up to 40 seconds because they both came up.
There's no DR present.
So I'm going to go ahead and give this about 35 more seconds.
And when it's done, I'll turn off the debug.
And then we'll take a look at the play by play as shown by the debug.
All right.
I'm doing an undy bug all.
And let's scroll to the top of this debug output.
So it went into the two A state.
And that's because here in R1, it saw hello messages coming in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's because here in R1, it saw hello messages coming in
that indicated that R2 knew about R1.
So then because there's no DR, BDR on the network,
they begin the process of that election to decide who's going to be the DR and
BDR.
And this is R1 preparing the database exchange,
which implies it was going through Xdart and Exchange.
We then send a request to the 2222 router,
which is R2.
We received an update from 2222.
And then when synchronized, we went to a full state.
And at that point, we got the console message.
We're going to the full adjacency with R2.
It's also showing here the results of the DR BDR election. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's also showing here the results of the DR BDR election.
So the DR is 2222.
And that's because they both have the same default priority
on the segment of one.
And the router ID for 2222 is higher.
And that was the tiebreaker.
So router 1 became the BDR.
And then I turned off debuggy.
So using the idea of IT-ELF, like an LF dressed up like an IT person,
that can help us remember the process that you go through to negotiate.
And if there's a problem, again, just think of STT,
AMP, for all those parameters that need to match that we talked about a little WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
AMP, for all those parameters that need to match that we talked about a little
while ago.
So the objectives for this set of videos
is to give you the opportunity to see and then do some hands-on practice
in configuring OSPF version 3 for IPv4 for that address family.
I also want to walk you through sitting up a passive interface,
which we've done previously with IPv6 and traditional IPv4.
But this time, we're going to do it with OSPF version 3's implementation
of routing for address family IPv4.
I'd also like to walk you through sitting up a stub area
in a totally stub area using OSPF V3 for IPv4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in a totally stub area using OSPF V3 for IPv4.
And also walk through an example of doing summarization
at the area border routers so that we're not setting all the LSA type 3s,
but we can send a summary.
And you can do summarizations, for example, from area 0,
as it goes down here, here on R3,
or you can summarize routes that are over here in area 2
as the ring sent up into area 0.
And the command to do that is the range command.
And it's implemented a little bit differently
because we're going to do it inside the router config
inside of the appropriate address family.
In this case, the address family for IPv4.
So we have a lot on our plate. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we have a lot on our plate.
We're going to start the configuration for OSPF version 3
for address family IPv4 in the very next video.
So I'll see you there in just a moment.