[AUDIO LOGO]
Next up is trouble ticket two.
And this one is also using BGP Topology 1.
Again, we probably won't point that out again.
But let's go ahead and take a look at our ticket here.
So it says that router 3 is supposed to be neighbors
with router 7, but it's down.
These are directly connected-- again, always
starting with verifying the ticket.
So why don't we go ahead and jump into the command line
and start on router 3?
So let's start with a show IP BGP summary.
And we see here that neighbor 7, 10.7.7.7, is currently
in the state OpenConfirm.
So that's interesting.
Let's go look at router 7 and see what it says.
If we look at it on this side, it's
listing neighbor 10.3.3.3 as OpenSent.
Now before we get too far into our troubleshooting,
let's talk about some things that we know already
just from these two outputs.
Well, the obvious is that the ticket is correct,
and the neighbors aren't up.
OK, fine.
But beyond that, we see that they're both configured
to peer between their loopbacks because they're
listing the loopbacks on both sides as the neighbor's
address.
So they're both properly configured between loopbacks,
and they can talk to each other, and there's
nothing like an ACL.
As we saw in ticket one, if they can't talk to each other
because of either routing issues or an ACL,
well, then they're going to be flapping
between active and idle.
These aren't doing that.
They're all the way to OpenSent and OpenConfirm.
So that lets us know that they're actually
communicating properly.
So now, let's dig in and start looking at some other issues.
Since we're here on router 7, let's do a show IP BGP neighbor
for the 10.3.3.3.
See if we can get some more detail on this neighborship.
So looking over this first part, everything here looks OK.
Nothing jumps out.
Let's scroll down a bit.
Again, if we look over this section,
everything here looks OK as well.
Here on this section, there's a few things
we should probably point out.
The first is here, where it says that the external BGP neighbor
may be up to one hop away.
So that means that the TTL should theoretically
be sent with a 1.
Now, the next thing says external BGP neighbor
not configured for connected checks.
And that's good because these are peering between loopbacks.
So that would be very important as well.
Those two things look good.
But if we look at this line, it says
the connection is ECN-disabled.
And we don't really care about ECN at this point.
However, it's listing the minimum incoming TTL as 254,
with the outgoing being 255.
So it's not sending with a TTL of 1.
It's sending with a 255 and requiring a 254.
This should be a very clear indicator
that we are doing TTL security.
So that's probably a good thing to check here.
Let's take a look at router 7's configuration.
We'll do a show run section BGP.
And we see here we have things like our disabled connected
check and our update source loopback 0.
But more importantly, there's that ttl-security hops 1
that we were just talking about.
So this is, in fact, using TTL security.
We should probably go verify that on router 3 then.
So here on router 3, let's start with our show
IP BGP neighbor for the 10.7.7.7.
Once again, everything here looks OK.
Everything here looks OK.
Here we have our two messages about the external BGP
neighbors not directly connected.
And that the directly connected next-hop check
is bypassed for that neighbor.
Those two things are good, but notice
there is no mention here of TTL security.
So let's do a show run router BGP.
And we see, for neighbor 10.7.7.7, that, of course,
we have our normal configuration--
things like our update source and our ignore connected
check--
but there's no TTL security here.
So once again, it looks like we may have found our problem.
We have one side configured for TTL security, which
is going to require a minimum incoming TTL of 254.
And then we have the other side that's
not configured for TTL security, and, therefore, would
be originating its packets with a TTL of 1.
And that's not going to meet the minimum requirement
on the other side.
So once again, how do we fix it?
Well, we have a couple of choices,
just like we normally do.
Choice number one, of course, would
be to remove TTL security.
Assuming that's the problem, that would definitely fix it.
But once again, going with the concept that it's
probably here for a reason--
somebody wanted to tell security on this link--
what are some other choices?
Well, of course, we could configure router 3 here,
which is missing the TTL security to have TTL security.
The other choice, though, is a little interesting,
and we're going to do it temporarily just
to show you that it works.
I would not recommend this, but it's just
an interesting exercise in how TTL security actually works.
Remember that what router 7 is expecting
is a TTL of 254 when the packet gets there.
That's really all we have to provide.
So if I were to tell router 3 to use EBGP Multihop
and set the TTL to 255, that would meet the requirement
on router 7, and this neighborship would come up.
You're, in a way, tricking or circumventing the TTL security
at that point.
And again, like I said, I wouldn't recommend it.
But I think it's a good exercise to go through
just so we can see that that's really how TTL security works.
And yes, if we were directly connected,
we could do this and bypass it or circumvent it.
Keep in mind, of course, if we weren't directly connected,
this wouldn't work, right?
If we were really three hops away,
it doesn't matter what we changed EBGP Multihop to.
So although we're working around the TTL security thing,
I don't want you to think that this is a vulnerability in TTL
security.
TTL security is still doing its job as it should.
We're just providing its requirement
in a unique or unusual way.
So like I said, let's go ahead and configure that real quick.
Just make sure the neighbors come up.
And then, of course, we'll fix it right.
But I do want you to see that this does work.
So on router 3 here, let's go into configuration mode.
Router BGP 100, neighbor 10.7.7.7, EBGP Multihop.
And again, we'll set it to the maximum 255.
That way, it'll meet the requirement that's on router 7.
We'll commit that change.
We won't actually exit configuration this time
because we're going to change it in just a moment.
Now it will take these neighbors just a few minutes to come up.
So let's fast forward until that's done.
So it has been a few minutes.
And we can see that now 10.7.7.7 is up and running.
It came up about 33 seconds ago.
So EBGP Multihop does, in fact, work with TTL security.
Now again, not exactly how we probably want to leave it,
but it does work.
So let's go ahead and take this feature off.
We'll commit that change.
And then we'll wait for that neighborship
to go back down just to prove that our other solution works
as well.
So we're now past the whole time.
And we see that neighbor 10.7.7.7 is back to the state
OpenConfirm, which means we're back to not working.
So now let's put in what we would call probably the best
solution.
So we'll turn on TTL security.
We'll commit the changes.
And once again, we will have to wait just a few minutes
for this to come back up.
So it's been a couple of minutes.
Let's go ahead and check our neighborship again.
And we see that 10.7.7.7 is back up.
It's been up for about 30 seconds.
We'll, of course, verify this on router 7 as well.
We'll do our show IP BGP summary.
And we see that 10.3.3.3 is now up as a neighbor.
So that verifies that TTL security was the problem,
and we have solved this ticket.
So in this video, we saw an issue related to TTL security.
Remember that the way TTL security works is
it sends all of its updates with a TTL of 255.
And then, it has a minimum TTL that's
required on the packets it receives.
As long as the neighbor is sending its BGP updates
with the appropriate TTL, then everything will be fine.
Now the way you get the neighbor to do that is, well, as we saw,
one of two ways.
We could theoretically use EBGP Multihop.
Again, probably not the best solution,
but we saw that it does, in fact, work.
The best thing, of course, is to run TTL security on both sides.
I hope this has been informative for you,
and I'd like to thank you for viewing.