So, quick few tidbits about IPsec, especially as it relates to our traffic flow
.
First of all, let's talk about MTU.
MTU is always a really tricky thing.
We have to understand that there are two different types of MTU.
There's layer 2 MTU and layer 3 MTU.
And when it comes to IPsec, we're talking about layer 3.
Layer 2 is interesting because there's no fragmentation with ethernet.
It doesn't allow it.
And therefore, if we exceed MTU, the packet gets dropped.
Layer 3 is a little more friendly because we will fragment a packet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Layer 3 is a little more friendly because we will fragment a packet.
And that's good because if I don't realize that I sent a big fat jumbo frame to
a router,
well, at that point, it'll just send it out in fragments and the other router
will receive
it and assemble it and send it on its way.
And so that's a good thing for us, but sometimes this fragmentation is
happening and we don't
even realize it.
We're just sitting there happily thinking our network is running and running WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're just sitting there happily thinking our network is running and running
well and properly
and the fragmentation sort of saving us.
And we didn't even know it was happening.
So what's the downside to this?
Or is there one?
Well, the downside is that this ramps up CPU cycles on our routers.
And it's not a big deal if especially we're in a lab environment and we're just
kind of
running ping-tacks and everything's going to go through just fine.
It's when we ramp up a production network and we have loads of packets.
And if every single packet needs to get fragmented or at least a significant WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if every single packet needs to get fragmented or at least a significant
percentage of them,
well, now we're going to start to see CPU overloads on our devices.
So we talked before about GRE and for that matter, as we'll see with VXLAN,
like there's
just a amount of extra bits that get added anytime we're tunneling.
So when we tunnel packets, we're going to use extra encapsulation, which means
that
we have extra headers.
And extra headers show up in two different ways. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And extra headers show up in two different ways.
First of all, it's going to show up as an inner header, which now is part of
the payload.
It wasn't part of the payload before, but now it is.
So something like an IP or possibly IP with TCP or UDP, this can start to add
to our MTU.
The other place it shows up is in the actual tunnel header, such as the GRE or
the VXLAN.
And for that matter, now we're talking about adding ESP or AH as part of IPSec. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for that matter, now we're talking about adding ESP or AH as part of IPSec.
And so this starts to ramp up our bits and bytes as well.
So what very often happens with tunneling is we get exactly this scenario where
we don't
even realize it, but now our packets at 1500 bytes, which would normally have
been fine,
those are going to be too big.
And we're sort of saved by this process by which we rely on fragmentation in
order to
get our packets across.
So yeah, we might have to deal with additional CPU cycles, although devices WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So yeah, we might have to deal with additional CPU cycles, although devices
that are built
for IPSec are going to have a whole lot more resources to handle fragmentation
because it's
such a common part of the process.
Where we might find issue is if we have any kind of situation where our devices
don't
support fragmentation.
For example, VXLAN itself doesn't have fragmentation support.
It's a do not fragment type of scenario.
Not as big of a deal because VXLAN is layer two and layer two doesn't have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Not as big of a deal because VXLAN is layer two and layer two doesn't have
fragmentation.
Anyways, and so we're usually talking about jumbo frames and all kinds of
things that
says, hey, you know, VXLAN's probably not a big deal, we're probably operating
in an
environment that can support the extra bits.
But with IPSec and GRE, these are again a little bit more layer three focused.
And so they're going to be built on an underlay that is probably looking more
at 1500 byte
MTUs rather than something much larger.
And as a result, this 1500 bytes, once we add in inner headers and once we add WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as a result, this 1500 bytes, once we add in inner headers and once we add
in tunnel
headers, now all of a sudden we're going to start to exceed MTU.
So what's the take primary takeaway from this?
There isn't much of one other than awareness.
We just don't want to be clueless that this is happening.
So that if we do see CPU spiking, if we do see packets getting dropped, that we
might
say, hey, maybe we should check in on this fragmentation situation and find out
if this
is going to be a problem for us or not.
And you say, well, is there a way to prevent fragmentation? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And you say, well, is there a way to prevent fragmentation?
Well, there's only two ways to prevent fragmentation.
We can either reduce the MTU coming in, which is very painful to do.
We have to go around to all of our different hosts and make sure that none of
them are sending
with more than 1400 bytes or so of payload data in order to avoid this.
The more realistic goal would be to increase the MTU in the underlay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The more realistic goal would be to increase the MTU in the underlay.
Now you have to ask the question, do we control the underlay?
Is this a service provider?
Is it the internet?
Because if we don't control the underlay, then maybe that's no more realistic
than decreasing
the MTU on all of our Windows PCs, for example.
So fortunately, fragmentation is going to continue to be an option for us.
Let's just make sure we're aware that this is happening.
Now the question also is, OK, but how much are we talking about here?
What should the MTU change by in order for us to support IPsec? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What should the MTU change by in order for us to support IPsec?
Well, IPsec makes things a little bit difficult.
With GRE, it was pretty simple.
I need another IP header, which is 20.
I need the GRE header, which is 4, which as long as we don't include other
options, it
stays at 4.
And so it's a total of 24 bytes.
But with IPsec, things get a little bit more complicated.
For example, are we running ESP?
And if we're running ESP, are we running with AES?
Are we running another encryption algorithm? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Are we running another encryption algorithm?
Are we running with AH?
If we're running on ESP or AH, are we using MD5 hashing?
Are we using SHA hashing?
And all of this changes and creates some amount of variance.
So AH is a little bit smaller, as I might imagine.
There's less going on.
And so we can get as low as 44 bytes of overhead for AH.
And with ESP, depending on our options, we can actually get as high as an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And with ESP, depending on our options, we can actually get as high as an
additional
73 bytes.
And, to be clear, there's a lot of values in between these two that can result
in us,
for us
you know, depending on our options.
We might end up at 70 bytes, for example, or something like that.
So what do we do with this information?
Well, again, if we're going to make changes, either to the hosts or to the
underlay, then
we need to account for probably the worst case scenario here.
And even though we could subtract that from 1500, I will say it's pretty common WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to aim for a 1400 byte type of MTU shift, because that accounts for not just
this overhead,
but also potentially additional overhead if we're doubling capsulating anything
like
that.
At that point, it's not worth trying to eke out every last byte.
We might as well just call it good at 1400 bytes.
So that's something to keep in mind with the MTU and IPsec.
One other thing I wanted to toss out is the concept of crypto maps. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One other thing I wanted to toss out is the concept of crypto maps.
So, crypto maps are a legacy mechanism, but as with all legacy mechanisms, we
're probably
going to run into this at some point, whether in production networks and lab
networks, possibly
on an exam, hopefully not, but you just never know.
So what is a crypto map?
Well, we have focused on two routers having a tunnel connection between them.
Well, we didn't always have the luxury of assuming there was going to be a
tunnel.
We might have just had a bunch of routers in between, and I want to secure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We might have just had a bunch of routers in between, and I want to secure
traffic that's
going from this interface to this interface.
Well, that was the purpose of the crypto map.
The crypto map would see as traffic was really not coming into the router so
much as routing
through the router and going out this interface, the crypto map would apply to
this interface
and use an access control list to identify what was known as interesting
traffic.
This is the phrase that we would use for this.
It said, "Hey, I don't necessarily want to encrypt everything that gets sent WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It said, "Hey, I don't necessarily want to encrypt everything that gets sent
out this
interface, but if it's targeting this IP address or maybe we could even
identify specific
sources out here that we want to encrypt, at that point we're going to call
this interesting
and we're going to apply our encryption headers."
So, the tunnel isn't required.
We can encrypt the tunnel and at that point, sure, we're going to encrypt
everything as
it goes across that tunnel.
But we also, before tunnels were really a major factor, we could use crypto WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we also, before tunnels were really a major factor, we could use crypto
maps in order to
accomplish this.
Now there were several downsides to crypto map.
Maps not the least of which, by the way, is the fact that it didn't support
broadcast
or multicast.
But if we're not supporting broadcast and multicast, then we're not supporting
routing
adjacencies across it either.
So there wasn't a way for us to form a direct EIGRP or OSPF relationship WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there wasn't a way for us to form a direct EIGRP or OSPF relationship
through, again,
what is effectively an underlay here between the two devices.
So tunnels allow us to accomplish this.
This is important, by the way, if this is like the internet and I'm trying to
connect
two sites, I really would want to have a routing relationship.
If it's a different situation, maybe we could just have routing everywhere.
But as we see, it's going to really hold us back.
It was holding us back, relying entirely on crypto maps. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It was holding us back, relying entirely on crypto maps.
So now instead, in a modern network, we're usually forming tunnels and applying
our configuration
to the tunnel, which is going to be what our focus is here within this scale.
But be aware that crypto maps existed and that there's still a thing we can
configure,
but for the most part, it is considered legacy in the modern network.