[AUDIO LOGO]
So now let's jump in and take a look at TTL
security, which is another one of our protection mechanisms
for our neighborships.
The main idea is we can ensure that neighbors are not
allowed to be more than x number of hops away,
and we'll, of course, be determining that.
But the other thing it does is it
allows BGP to quickly discard packets
that are coming from further away
without it having to fully process them.
So from that perspective, it can also help protect us
from denial of service attacks.
So let's jump in and take a look a little bit
at how the details of TTL security work.
And then of course, we're going to jump onto the command line
and see it in action.
So in addition to preventing neighbors that are too many
hops away from being able to form a neighborship,
TTL security can also help protect BGP from TCP SYN flood
attacks, and the reason this is important
is because even though the default TTL on eBGP
is, in fact, set to 1, that fact does not
prevent an attacker, somebody who's not necessarily
following the rules, from setting their TTL to 255
and therefore allowing their BG packets to reach us no matter
how far away they are.
Now, the return traffic, of course,
still would not be able to get there.
So this would not affect the TTL on the local router.
So again, the return traffic wouldn't get back
to the sender.
We wouldn't actually form a neighborship with them,
and that's part of the preventing
the unwanted neighborships, but this flood of traffic
could very well overwhelm BGP.
So it's best if BGP can essentially throw
the traffic away immediately.
So the way this works is, first, we're
going to set the TTL on all the BGP
packets that were originating to 255 rather than one.
And then in conjunction with that on the receiving side,
we're only going to allow packets
that meet a minimum set TTL.
Any packets that are below that threshold
are instantly discarded.
That's how we're protecting BGP because ultimately, that
saves BGP from processing those frames.
Those frames aren't going to be processed if we're
discarding them right away.
So let's take a look at a chart here
that's going to define a little bit about how
this works as far as options go then with our eBGP peerings.
So first and foremost, we have what's our default.
And of course, since it's the default,
it's not shown in our configuration.
But we default to ebgp-multihop 1, which, of course, means
the TTL is 1, and this is only going
to accept connected routes for reaching our neighborship.
There's also no expected TTL because, well, we're
not doing TTL security.
The expected TTL only applies if we're doing TTL security.
Next is the disable-connected-check.
If we enable this feature, then the TTL is still 1.
However, it will now accept connected, dynamic,
and static routes for finding its neighbors.
So it doesn't have to be directly connected anymore.
However, the TTL is still 1, and there's still no expected TTL
because, again, this is not TTL security.
Next is we have ebgp-multihop X, which would be pretty
much any number higher than 1.
That means the TTL is going to be whatever number you specify.
And since it knows it's going to be more than one hop away,
once again, we can use either connected, dynamic,
or static routes.
And again, we still don't have any expected TTL.
Again, still not TTL security.
Now, for the options that are actually
related to our current topic, ttl-security hops 1 means,
we're going to set the TTL to 255.
We're, once again, only going to accept connected routes,
and we're going to expect a TTL of 254.
This means, of course, that a neighbor can't be two or three
or seven hops away or 100 hops away
because the TTL has to still be 254 on the packet when
it gets to me.
Now, these options can be combined.
So we could do ttl-security hops 1
and turn on disable-connected-check.
What that does for us, it still leaves the TTL at 255,
and it still leaves the expected at 254,
but it allows us to use connected, dynamic,
and static routes.
So in case you're wondering why you
would want that option, that's going
to be a really good option if you are trying
to peer with a directly connected neighbor,
but you're trying to use loopback interfaces.
Loopback interfaces are not going to be connected routes.
They're either going to be statically configured
or learned through a dynamic routing protocol,
some form of an IGP.
But we can't use that if we don't
have disable-connected-check because otherwise,
it will only use connected routes.
Then, of course, we have the option for ttl-security hops X,
where we put in a number higher than 1.
Now, this, of course, is not going
to change the initial TTL this time, unlike what
it did with ebgp-multihop.
The starting TTL with ttl-security is always to 255.
Now, what it does do for us is bring along
those connected, dynamic, and static routes
to use for our neighborship because, again, we're
telling the router essentially, this is not connected.
So it's going to use those other routes.
The way it's calculated is the TTL when it arrives.
So the expected TTL is going to be greater
than or equal to 255 minus x.
So as an example, let's say that we set our TTL hops to 5.
This means that the answer for the required TTL
is going to be 255 minus 5, which, of course, is 250.
That means that when a packet arrives,
it's going to have to have 250 or higher.
Neighbors can be closer but not further away.
So if it arrives with a TTL of 252, that's perfectly fine.
It's closer.
And that's what we said down here in the note
just to point it out.
Again, neighbors can be closer but not further away.
So before we jump on to the command-line
and look at this, let's, of course, look at our diagram
and see what we're going to be building.
So very simply, we're going to use TTL security
on the link between R1 and R9.
That way, we can see this on IOS XE and IOS XR.
However, we are going to do it a little bit different than it
is right now.
Right now, they're peered up on physical interfaces.
We're going to actually peer them up on loopback interfaces
just to make it a little bit more interesting.
So let's jump on to the command-line.
The first thing, of course, we'll have to do
is some routing here.
So we'll just do static routes.
So the routers can get to each other's loopbacks.
Then we'll take out the old neighborships,
put in the new neighborships with our TTL security.
So let's go ahead and jump into the command-line
and get that done.
So we'll start off here on router 1.
We're just going to paste the configuration in,
and all we're doing is adding a static route
to get to router 9's loopback.
We'll do the same thing on router 9 to get to router 1.
And if that worked correctly, we should
be able to ping 10.1.1.1, sourcing it
from our loopback0 interface.
We see this as successful.
So now, we can change our BGP neighborships.
Let's go back over to router 1.
This is a fairly standard configuration.
So once again, we'll just paste it in,
and I'll just highlight the commands
that are a little bit different from what we've been doing.
So two things that are going to make this work.
First, we have the command here under the neighborship
to ignore the connected check.
That's what's going to allow this
to come up between our loopback interfaces.
And then we have our TTL security,
which is going to have and initiate
our packets with a TTL of 255.
Now, let's go make the similar configuration on router 9.
So once again, we'll take out the old neighborship.
We'll put in the new neighborship,
again, sourcing it from our loopbacks
with our ttl-security hops 1 and our disable-connected-check,
and we see here that our neighborship with router 1
has, in fact, come up.
Now, something else we can do here
is do a show ip bgp for the neighbor 10.1.1.1,
and we'll ask to include the TTL.
What we're looking for specifically
here is that the minimum incoming TTL is 254.
That's, of course, the 255 minus the one hop
that we said this neighbor was allowed to be away.
Also note that the outgoing TTL is now 255.
So we can see that this is up and working with TTL security.
Let's verify this, of course, on router 1 as well.
We'll do a show bgp neighbor for 10.9.9.9.
And if we look at our last three lines here,
these are the lines related to what we just configured.
The TTL security is configured.
The external BGP neighbor is not directly connected,
and the next hop check is bypassed for this external BGP
neighbor.
And just as a final verification so
we can see how the TTL is calculated,
let's go back to router 9, and let's
reconfigure this, this time with a hop count of 3
for the neighborship.
If we look at this again now, we see
that the minimum incoming TTL is now 252.
So that's our 255 minus the three hops that we
said it's allowed to be away.
So we can see here how that minimum incoming TTL
is calculated.
In this video, we looked at how TTL security can
be used to prevent neighbors from coming up that are further
away than we want them to be.
The advantage to this, of course,
is that it allows BGP itself to quickly throw away
those packets if the TTL is below the minimum threshold,
therefore, preventing BGP from getting overwhelmed.
I hope this has been informative for you,
and I'd like to thank you for viewing.