[AUDIO LOGO]
Next up is ticket 5.
This, once again, is on OSPF topology 3.
And, well, the ticket itself is going to sound fairly familiar
as well.
This time, we're talking about R9,
but we're still with that-- has no OSPF routes
in its routing table.
So of course, we will start on router 9.
I'm sure we'll do some exploring on router 2
as well, if not even beyond that.
But again, we'll start off with our main focus here being
on this area between R2 and R9.
So let's jump into the CLI.
We'll start on router 9, do some investigation,
and go from there.
So starting off on router 9 with a show ip route ospf,
we see that, as the ticket said, we have no OSPF routes here
on router 9.
So let's look at some of our normal things.
Let's do a show ip ospf interface brief.
According to this, we are, in fact,
running OSPF on the Gigabit 2 interface.
It's in area 1000, like it's supposed to be.
It does have the correct IP address and subnet
mask, configured for point to point, but has zero neighbors.
Now, we could, of course, follow this up
with a show ip ospf neighbors.
We already know this is going to be blank
because all of our interfaces have zero neighbors.
So again, things look relatively OK here on router 9.
So let's do our preliminary checks over on router 2.
So a show ip ospf interface brief.
We see that we again have OSPF enabled on Gigabit 0/0/0/2,
which is correct.
It's in area 1000.
It has the correct IP address and mask.
It's also configured point to point.
And it has no neighbors, at least no complete neighbors.
But notice that we do have one set to connecting.
Let's take a look at our show ip ospf neighbors.
And what we see here is it actually knows about router 9.
It's currently in the init phase,
which is why it's connecting.
It's not full, but it is in the process of connecting.
Now, if we give that just a few seconds, try again,
see if it's moving past init in any way, we see that it's not.
It is currently just stuck here in the initialization phase.
So this actually brings up an interesting situation as far
as troubleshooting.
The fact that router 2 sees router 9 but router 9
sees nothing, indicates that the hello from router 9
is getting to router 2 because we see it,
and we recognize that, hey, as long
as we complete this process, this is going to be a neighbor.
However, it looks like the hello from router 2
is not getting to router 9.
So it looks like we have hellos going in one direction.
Let's investigate this just a little bit further.
Let's take a look at some debugs and maybe even some Wireshark.
So let's start with a debug ospf 1.
And let's start by debugging the hellos.
So what we see right here is that we're receiving a hello
from 10.9.9.9 in area 1000 on our Gigabit 0/0/0/2 interface.
So as we suspected, it's receiving this hello.
And then we see a little bit further down here
that it's sending the hello to 224.0.0.5 in area 1000
on that same interface.
So we see that router 2 is sending and receiving hellos.
Let's take a look at router 9.
The command is a little bit different here on router 9.
It's debug ip ospf hello.
We'll turn on terminal monitor.
We'll let this run here for just a few moments.
So what we see here is clearly we are sending hellos, which
we already knew, because of course,
router 2 is receiving them.
But we're not receiving any hellos from router 2.
So let's actually take a look at what's going on in Wireshark.
So here we have a Wireshark capture
going on, on router 9's Gigabit 2 interface.
And let's go ahead and stop this just for a second
so we can take a look at it.
Now, we can see that we have some OSPF version
3 packets here.
These would be the ones going to ff02::5.
We're of course concerned about the ones going to 224.0.0.5,
because that's OSPF version 2.
So if we were to take a look at packet 6 here, for example,
we can see that this frame is in fact coming from 50.1.29.2.
So that's router 2.
So what is this actually telling us?
This is telling us that the packet is actually arriving
on the interface on router 9.
So something's happening between the packet arriving
on the actual interface and the packet being received
by the OSPF process, because it's not
showing up in our OSPF debugs.
Now, the first thing that comes to mind there
is something that would actually stop the packets
at the ingress interface, which would generally be an ACL.
Let's go ahead and test that theory
and see if there's an access list on router 9.
By the way, before we actually do that,
let's do one other test that can be
an interesting troubleshooting tool as well.
We probably don't need it in this exact case,
but it's a good tool to have in your toolbox.
You can actually ping the OSPF version 2 multicast address.
And what should happen here is we should get a response
from all of our neighbors.
But notice, the only device we got a response from
was ourself.
So once again, this is a pretty good indicator
that we're not receiving the traffic properly.
So let's go ahead and take a look at that interface.
Let's do a show ip interface.
And again, this is all about Gigabit 2.
As suspected, we have an inbound access list
called ACL_FILTER applied to this Gigabit 2 interface.
So let's take a look at that access list.
We'll just do a show ip access-list.
This is actually the only one on this device.
We see that it's permitting UDP if it equals domain--
so DNS traffic.
It's permitting TCP for both normal WWW traffic
as well as SSL traffic on port 443.
But it's not allowing OSPF.
Keep in mind that with an inbound ACL,
it blocks all traffic that's not permitted.
Remember that ACLs have a default deny any at the end.
So even though it's not shown here, it's there.
And it denies all traffic that's not permitted.
With an outbound ACL, this would actually be different
because the router will not filter the traffic generated
by the router itself.
But with an inbound ACL, well, it
doesn't know who generated the traffic.
It's just incoming traffic.
So it's going to block all of it.
So once again, we have a couple of choices on how to fix this.
One, of course, would be simply to take the ACL off.
But if we're looking at this, we could probably
make a reasonable design decision that, well, whoever
put this here probably actually wanted it here
and wanted it working.
So maybe we should just modify it to allow the things we want.
So let's just go ahead and modify this access list.
We'll allow OSPF.
And while we're at it, we'll just
allow pings so that our little troubleshooting tool there
can work properly as well.
So let's just jump in here, change the ACL,
and see if that solves our problem.
We'll just go into configuration mode--
ip access-list extended, and this is called ACL_FILTER.
Now, we could theoretically put these rules anywhere.
But I think we should have a goal of putting them
towards the top since they're actual network functionality.
So maybe we say line 5 permit.
Let's go and do the pings first.
So we'll just do icmp from anyone to anyone.
And then we'll say--
it's not going to matter.
You'll see why in just a moment.
But let's do 8, and we'll say to permit ospf from any to any.
Now, if this actually solves the problem,
OSPF should come up pretty much right away.
We can see here that it has.
However, one thing that I want to fix here
is if I do a do show ip access-list now,
we can see that we have 10 matches on OSPF.
But our line numbering is a little weird.
It's 5, 8, then 10, 20, 30, nice and neat.
So one of the things you can do here
is you can actually resequence this.
So if we drop out of the ACL configuration mode,
we can say, ip access-list resequence.
Then list what we want to resequence--
ACL_FILTER.
Then you give it a starting number.
So let's start at 10.
And then you give it an increment number.
So let's start at 10 and jump by tens.
And then if we say, show ip access-list,
notice that they're now nicely numbered.
10, 20, 30, 40, 50.
This is nice if we've had to add to the list over time.
It started to get a little crowded
in our numbering scheme.
And we need to resequence it.
One quick note on renumbering or resequencing your ACLs,
make sure everybody in the management team
knows that this is happening.
Put it in your documentation, in your log entries,
whatever, because particularly, if you're logging ACL entries--
which were not, in this case, but if we were logging
these entries, all of a sudden, the logging is going to change.
In other words, the traffic that was permitted
by ACL entry 8 a moment ago is now
being permitted by ACL list 20.
So in your logs, that might look a little interesting
why all of a sudden things changed rule numbers and such.
So again, just keep track of what you change.
Always document this kind of thing.
And make sure everybody knows it happened.
Otherwise, it could, again, make troubleshooting
or trying to look through historical events--
could get really interesting if you don't have documentation
that this was resequenced.
Just keep that in mind.
So now that we got the console message that this came up,
we probably don't really need to check.
But you know that we always should.
Let's go ahead and exit out of configuration mode.
We'll do a show ip ospf neighbor.
We see that our neighborship with router 2
is now up and full.
If we do a show ip route ospf, we now
see that we are getting entries in our routing table
where we weren't getting them before.
And just to revisit our troubleshooting tool,
this is what we should have gotten in a proper environment
when we pinged the 224.0.0.5.
Notice that we're now getting a response
both from ourselves and from our neighbor, router 2.
So this is what this should look like if it is working.
And of course, we saw earlier what it looks like if it's not
working properly.
So in this video, we saw an example
of an access list, particularly an inbound ACL,
blocking the OSPF traffic, preventing the neighbor
from coming up.
Now, as you saw, this one's a little trickier
to troubleshoot than some of the other options we've
looked at so far.
We saw that all the hellos looked OK.
All the parameters were configured OK on the devices.
Just the neighbors weren't coming up.
Debugs helped quite a bit.
We could see that one side was both sending and receiving,
while the other side was only sending.
Then, of course, Wireshark helped us out a bit
there by seeing it's actually receiving the traffic.
It's just not getting to the OSPF process.
That pointed us in a pretty good direction
to suspect that it was an ACL to begin with.
Of course, once we fixed the ACL and permitted OSPF,
then our neighbors came right up as they should.
I hope this has been informative for you,
and I'd like to thank you for viewing.