[AUDIO LOGO]
Next up, of course, is Trouble Ticket 4.
This is, once again, using OSPF topology 3.
For this one, we have a little bit more
of an interesting statement.
This is saying not that we don't have neighborships,
but we have inconsistent neighborships, particularly
on R7.
So, of course, that means we'll be looking at R7
and what we'll have to do first is
figure out which neighborships.
Now in our previous video, we just
did a ticket between router 7 and 8,
and that seems to be consistently up and working.
So we're either going to be looking
at the neighborship with router 3
or the neighborship with routers 6 and 1.
So let's jump into router 7, and get started
and figure out first which neighborships
we're talking about.
And then, of course, we'll try to figure out
what's going on with them.
So let's jump into router 7 and get started.
So here on router 7 let's do our show ip ospf neighbors.
And we see that it's currently neighbors with 6 and 3
as well as 8.
But again, we're going to assume that 8 is OK here since we just
did this in the last ticket.
Let's look at this a couple more times because the ticket did
say inconsistent.
So if we look at this a few times,
it actually looks like it's OK.
Now a lot of times when you're having
neighborship issues with OSPF, it
will generate console messages.
So us being in through SSH, it may not
be a bad idea to turn on terminal monitor
because a lot of times we'll see things happening, of course,
live where we don't necessarily see them in the outputs of show
commands.
So with terminal monitor on, let's give this just a second
and see if we get any kind of message.
Well, here we have a message that router 6 just came up,
and then router 6 went down.
And then router 1 came up, and then router 1 went down.
And now router 6 is back up.
This is clearly some inconsistency.
Now, this is going to be a little hard to work around.
So let's do term no mon again just
to turn those console messages back off while we're
trying to work through here.
And another good thing to do might
be to get an idea of how long this has been going on.
Did this just start, or is it a long-term problem?
So a good way to find that, of course, especially
since we know it's been generating console messages,
would be to do a show log.
If we look at our show log, we actually
see that it is full of these messages.
So it looks like it's been going on probably
since this router booted up or since I
loaded these configurations on here, causing these problems.
So this has been up and running for quite some time,
causing these issues.
So we definitely see what's going on.
And then it's been going on for a while.
Our neighborships are flapping between router 1 and router 6.
But why?
What's causing this?
Let's start with a show ip ospf interface brief.
And let's take a look at that interface that goes out
towards router 6 and router 1.
Specifically, that's gigabit1.
Notice that gigabit1 is showing that it has one neighbor.
It does have one neighbor, doesn't it?
First, it has router 1 as a neighbor.
Then it has router 6 as a neighbor.
Then it has router 1 is a neighbor.
So it only has one neighbor at a time,
but that's currently flapping between R1 and R6.
And we can actually see the problem
right here on the screen already without going
any further depending, of course,
in your environment how much you trust the network diagram.
If we look at our network diagram,
the connection between R7, R6, and R1
is a multi-access network.
In other words, it's a single sub-net.
All three of those routers should be neighbors.
The problem is this is configured as point-to-point.
And a point-to-point OSPF network type, by definition,
means you can only have one neighbor.
There's only two devices on a point-to-point connection,
yourself and your neighbor.
So, in this case, it's trying to bake a neighborship.
And as soon as router 1 sends a hello, it goes,
oh, you must be my neighbor.
It forms a neighborship.
And then next thing you know, router 6 sends a hello,
and it goes, wait, wait, wait a minute.
OK, you must be my neighbor on this segment.
So it switches over, and it becomes neighbors with router 6
just in time for router 1 to send a hello again
and-- you see how this is going to progress.
As it's receiving these different hellos
from these neighbors, it's just flapping back and forth,
trying to figure out which one other neighbor its supposed
to be neighboring with.
So, of course, the fundamental problem
here is we have the wrong OSPF network type.
Now, as we approach this problem, what we have
to consider is how to fix it.
We need an OSPF network type here
that will support more than one neighbor.
So we could, of course, go to the default
here for an Ethernet connection, which would be broadcast.
Technically, we could do non-broadcast
as well, but honestly, that's not done very often anymore.
There's also a few other choices here.
We could set this up as point-to-multipoint and/or
the point-to-multipoint non-broadcast option.
But point-to-multipoint could also work here but not
if we don't change our neighbors to be point-to-point as well.
We can't actually bring this up as just point-to-multipoint.
In fact, if we do, what will end up
happening is we'll just end up with corruption in the database
essentially.
Not unfixable corruption, all we have to do
is change the network type back.
But you can't mix network types that
require a DR, which of course, routers
6 and 1 right now are expecting a DR because they're
set to broadcast.
If we weren't sure, of course, we could go look.
But they are.
If we set this side to point-to-multipoint
and we set our timers to match, well, the neighborship
will come up, but it won't exchange databases.
So ultimately, we're going to have
to set this to broadcast to match routers 6 and 1,
or we're going to have to change this entire multi-access
segment.
So to do this, we'll simply, of course,
go in and configuration mode into interface gigabit1.
And we'll set the ip ospf network to broadcast.
Because of the DR/BDR election, this
will take just a few seconds to come up.
So we'll jump ahead to when this neighborship comes online.
So this has been long enough now that this
should have stabilized.
So if we say show ip ospf neighbor,
we should now be up with both 6 and 1, which
we can see that we are.
Our current state with them is brother.
So we have not been elected as the DR or the BDR, which
would make sense since both of those
were already neighbors with each other, and one of them
had already been elected as the DR and the other as the BDR.
So it would make sense that router 7
would become neither one.
We can also turn terminal monitor back on again
just to make sure that we don't have
any more neighbors flapping.
But more importantly, we can do a show ip ospf neighbor
and then ask to look at one of these neighbors in particular.
We'll just say pick on router 6.
We can see that, in this case, this neighbor has now been up
for 2 minutes and 6 seconds.
Now just based on the speed of the console messages we
saw coming in earlier, we know that if it's
been up for even more than a few seconds, then it's stable.
We can, of course, verify router 1 as well.
It should be close to that, 2 minutes and 24 seconds.
So we can see that now not only are both of these neighbors up
at the same time, not back and forth one then the other,
but they're both up as neighbors.
But they're also stable.
So in this video, we saw an example
of what happens if we have mismatched OSPF network types.
I hope this has been informative for you,
and I'd like to thank you for viewing.