All right, we're going to jump into a quiz. It's going to be a question. So not
too long here. We just want to spend some time reviewing the virtualization
technology that covers virtual networking, as well as VRS, GRE, and IPSec. And
then we'll worry about Lisbon VX land coming up. First question here, which
type of hypervisors deployed onto bare metal and which type of hypervisors
installed onto an existing operating system. So let's take a moment to remember
what exactly a hypervisor is.
The idea here was that originally, if I had a piece of hardware, that would be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The idea here was that originally, if I had a piece of hardware, that would be
a server. So CPU, memory, all of the different components of a server,
basically the same stuff that makes up a PC, we would install an operating
system. And for all the reasons we discussed, we typically in an enterprise
environment in a data center would install a single application per operating
system.
And this wasn't super efficient. It wasn't an efficient use of our resources.
And so the concept of virtualization came along and virtualization on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so the concept of virtualization came along and virtualization on the
server level allowed us to deploy one piece of hardware. So we're still
deploying a server, maybe with more CPU and RAM, but it's all the same stuff in
the server.
And then the idea here is that we would build on top of this, not an operating
system, but a hypervisor. And this hypervisor will allow us to install
individual virtual machines, which are their own instance of an operating
system, which allows us still to maintain that one to one relationship between WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
system, which allows us still to maintain that one to one relationship between
application and operating system.
But it's no, it breaks the idea that I need a one to one to the hardware. I no
longer need that. Instead, I can place many virtual machines potentially a
handful potentially dozens of virtual machines onto a single piece of hardware.
And a single piece of hardware is now known as a virtual host, while these
virtual machines can be known as guests, although like we said, we don't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
virtual machines can be known as guests, although like we said, we don't
usually call them guests, some people do, but we usually refer to these as
virtual machines or VMS, and the host itself that is absolutely a term we use
that helps us to differentiate between what is a server because is this the
server now is this the server, we don't need to worry about that we try not to
use the word server because that just makes things confusing.
So when we see a hypervisor deployed like this, this is known as a type one,
and this is absolutely what we expect to see in our enterprise corporate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and this is absolutely what we expect to see in our enterprise corporate
environments.
So if I'm going into a data center, I am expecting to find that my virtual
hosts consist of type one hypervisors. These would be hypervisors like VMware v
Sphere and Microsoft hyper V, the two probably biggest branded hypervisors that
are out there.
But there are also plenty others that would qualify as well. Meanwhile, we do
have a residential or maybe a lab, not residual, residential option. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have a residential or maybe a lab, not residual, residential option.
And again, we might see this in enterprise labs, that kind of thing, but we
have the concept of a type two.
Type two is not really intended for enterprise deployments. The idea here is
that I could have now going back to the concept of installing an operating
system directly onto a piece of hardware. So this could be my laptop.
This could be my desktop, or it could be a lab server. We've got lots of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This could be my desktop, or it could be a lab server. We've got lots of
options here. But in the end, usually we're talking about deploying these onto
our home devices.
So I've got my desktop PC here, and I've got my Windows operating system. And
now I can install the type one hypervisor or type two rather type two hyper
visor as an application running on my operating system.
And now I can deploy all of my virtual machines. And so the hypervisor still
has to build internal networking to the operating system, but we don't usually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
has to build internal networking to the operating system, but we don't usually
deal with too many of those details.
It's really designed to be very simple to deploy. And this allows me to deploy
usually virtual appliances that again are especially useful for lab and testing
.
So that's the difference in type one and type two. Let's make sure we
understand the whole concept of virtualization, where it comes from, what a
hypervisor is, and then once again, understanding the differences between a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
hypervisor is, and then once again, understanding the differences between a
type one and a type two.
Question two, what switching mechanism is used by virtual switches in order to
avoid running spanning tree protocol.
So this is kind of a big deal. We have a virtual host, and we've just said that
we're going to deploy individual virtual machines, each of which has its own IP
address.
And we are going to network out to, in theory, a physical switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we are going to network out to, in theory, a physical switch.
So by connecting to the physical switch, that's great. But if I send my network
traffic up, like we said, we're not able to send that traffic back down.
And that's just the basic rules of ethernet. I never forward a frame out the
same interface that I receive it. So how are these virtual machines supposed to
communicate with one another?
Well, that is going to require the virtual switch. The virtual switch is truly
a software package, but it's also a software package that is running very
similar codes.
So it's very similar code to what's running in a physical switch. The idea here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it's very similar code to what's running in a physical switch. The idea here
is that these virtual machines, that's, by the way, are also software, are
going to be sending their packets to this other software package, this virtual
switch, and it will decide what to do with them.
That allows these virtual machines to communicate with one another. So now I
can perform this East West traffic flow, and it stays, interestingly, within
the host.
I just send my packet into the software process that's running the virtual
switch, and then it spits it back out to the virtual machine that I'm trying to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
switch, and then it spits it back out to the virtual machine that I'm trying to
communicate with, which does mean that visibility from a network engineering
perspective isn't always the best, because I usually do like to see those
packets.
That allows me to see what's happening in my network. I might want to run
security, you know, prevent communications in some situations, but I lack that
visibility when the traffic stays inside of that virtual switch.
Now, the virtual switch is going to effectively receive a physical connection. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, the virtual switch is going to effectively receive a physical connection.
Usually we want to do a couple of these. And because we're running a couple
connections, might say, okay, well, this, you know, let's draw it like this.
This could create a network loop. If the virtual switch brings a broadcast
packet in and sends it back out, and it's not running spanning tree, that's
going to cause a major problem.
So we want to prevent this, and we could just bundle these connections together
, but we don't necessarily want to have to rely on that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
, but we don't necessarily want to have to rely on that.
So instead, we use the concept of pinning. Pinning essentially maps a one-to-
one relationship between one of these virtual machines and one of the uplinks.
We pin them to a specific uplink, which means that in this environment, when I
send even broadcast messages out, it's only going to go out one of those, which
does mean by the way that it will loop back around and there's rules to prevent
this virtual switch from forwarding that because the switch is going to do its WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this virtual switch from forwarding that because the switch is going to do its
job and for that broadcast traffic back out. But the good news here is that
when broadcast traffic is received on both of these, once again, the virtual
switch is going to ignore one of those.
And so we create a bunch of loop prevention rules around this, but it's the pin
ning nature that we're using that's going to prevent loops.
And it's important for us to understand how pinning operates and just the fact
that it's used heavily in virtual environments, and by the way, in Cisco UCS WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that it's used heavily in virtual environments, and by the way, in Cisco UCS
products, which is Cisco server, well, line of servers, I guess.
Pinning is very heavily used for the sake of this course and the scope of this
exam. We mostly just should understand that pinning is a concept, what exactly
it is, and that it is used to prevent loops going down to those virtual
switches.
Question three, how can two VRFs communicate with one another on a router? So
remember what we're talking about here. If we've got a router and I want to
carve this up into multiple VRFs virtual routing and forwarding instances, let WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
carve this up into multiple VRFs virtual routing and forwarding instances, let
's say A and B here.
Well, every single layer three interface, whether it's a sub interface or
physical interface, must belong to exactly one of these VRFs. And so we might
have four ports or four sub interfaces, whatever it is coming into this router.
And we've placed these into the appropriate VRF. So if a packet arrives here,
the only eligible option for it to leave this router would be to go out the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the only eligible option for it to leave this router would be to go out the
interface that's in the same VRF, because we have our own dedicated routing
table for each one of these VRFs.
And this routing table does not see that interface or this interface. It doesn
't even see those as options. And so again, it's going to have to stay in its
own VRF. So how can these two VRFs communicate with one another? Believe it or
not, the answer is A, by looping a cable on the device. If I were to loop this
one of these connections over to the other in the other VRF, then I could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one of these connections over to the other in the other VRF, then I could
communicate because it would, or the packet would land on VRFA.
Get routed out this port, land over here in VRFB, and get routed wherever it's
going. Feels a little silly to say this, but you know, we might send this
through a firewall or something like that down here. We've got options and
reasons why we might do this in an enterprise space.
And so just keep in mind that this implementation, as we've pointed out, is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so just keep in mind that this implementation, as we've pointed out, is
known as VRF Lite. Lite just means that we're not running MPLS. And MPLS is how
we are typically deploying VRFs for multi-tenant service provider networks.
In the enterprise space, we're not usually running MPLS. Instead, we are simply
deploying VRFs with the most common example of a VRF being the management VRF.
But there are certainly other spaces we might use them, such as with overlays
and underlays as we saw with GRE. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and underlays as we saw with GRE.
But just keep in mind how exactly VRFs work and that there is a very firm
boundary established here as far as what our options are. And it's really
thanks to the fact that we're running routing tables, unique individual routing
tables in both VRFs.
All right, next question here. How many bytes of overhead are added when using
GRE to tunnel IPv4 traffic? Diagram the header to show the answer. So how
exactly do we handle GRE? So if I bring a layer three packet in here, and we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
exactly do we handle GRE? So if I bring a layer three packet in here, and we're
going to send it out a tunnel interface that's running GRE, what does the
packet look like over here?
What we're going to do is we're going to take this packet and we're going to
turn it into the new payload. So this whole packet, including the IP header,
including the TCP or UDP header, that'd be our layer four, the original payload WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
including the TCP or UDP header, that'd be our layer four, the original payload
. This is all getting wrapped up as the new payload
for our new packet. And so what we're going to do here is we're going to
establish, first of all, a GRE header, and this is four bytes in size. And then
we're going to need that outer IP header. So remember, we end up with the
concept of an inner header here, which is ignored by the underlay, and then the
outer header, which is the only layer three header that the underlay is looking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
outer header, which is the only layer three header that the underlay is looking
at. This is what tells us how to get to the tunnel destination.
This is how we get to the final destination. But again, the underlay might not
know where that final destination is. It just needs to know how to get to the
tunnel destination. And so that's what goes into this IP header.
Well, like we said, the GRE header is four bytes and IP header is 20 bytes. And
we say, well, usually we're not too worried about this. It's part of the 1500
bytes, except we already have that IP header inside of here. So we have to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bytes, except we already have that IP header inside of here. So we have to
account for that.
So it is going to be 20 bytes here that we have to add from an MTU perspective.
So ideally, as we've said, the underlay should support an MTU of 1524. The
tunnel interface will have an MTU of 1476.
But again, that doesn't prevent fragmentation. If we really want to prevent
fragmentation, we must increase the MTU, and it has to be by those 24 bytes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
fragmentation, we must increase the MTU, and it has to be by those 24 bytes.
All right, question five, which scenario leads to recursive routing errors on a
GRE tunnel? So when we look at these answer choices, it doesn't have anything
to do with specific routing protocols.
We could make that argument because if we are creating problems, then the
administrative distance will end up mattering. And if we do have the better
administrative distance running on the overlay, this is where we can cause WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
administrative distance running on the overlay, this is where we can cause
problems for ourselves.
But again, I want to really drive home the underlying core problem with all of
this is simply that we are advertising our underlay routes across the overlay.
And there's no reason for us to do that.
So D here is going to be the answer. If we're advertising our underlay routes
into the overlay, that is a problem, because keep in mind how recursive routing
happens is that these routers need to know how to send to the tunnel
destination. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
destination.
Well, the tunnel destination is part of the underlay. So these layer three
interfaces, let's just draw one device in between here. These layer three
interfaces must be known via the underlay. So this, let's say, actually, let's
say we're going to the right here.
So this is my tunnel destination. When a packet comes in and I encapsulate it
for my tunnel, I now have a new destination. It's this destination here. And I
need to see that I send the packet out the underlay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
need to see that I send the packet out the underlay.
If I think I'm supposed to send it across the tunnel, that's a big problem. So
how would that happen? How do I all of a sudden decide that, hey, my routing
table, it says that that network exists out the overlay of this tunnel
interface?
Well, the only way that happens is if I advertise that subnet out the overlay.
There's no reason of the world that that should happen. Now, maybe accidentally
happened throughout summarization or default routes or any of those kinds of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
happened throughout summarization or default routes or any of those kinds of
things.
But if we just make sure that we are properly advertising it across the under
lay and that this initial, this router knows to send it out the physical under
lay interface, at that point we're good to go.
So we can really get into conversations about metrics and costs and OSPF and E
IGRP and VRFs. But if we simply just don't advertise our underlay routes into
the overlay, then we're going to be fine.
And so that's the biggest takeaway from that recursive routing conversation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so that's the biggest takeaway from that recursive routing conversation.
Alright, question number six. IPsec comes with AHESP transport mode and tunnel
mode options. Which combination is considered to be the most secure?
So we should absolutely know the difference between authentication header and
encapsulated security payload. We also should know the difference between
transport mode and tunnel mode.
And so in general, what we're really looking for is which one of these adds
more security. So authentication header, as the name implies, is going to be a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
more security. So authentication header, as the name implies, is going to be a
little bit more focused on authentication.
Although it doesn't just help with authentication. It also helps with message
integrity, which is an important part of our security framework.
ESP, on the other hand, is going to do all of this. It's going to do
authentication. It's going to do integrity. And it's going to do encryption.
And so for layering encryption on top, then ESP is absolutely going to be the
more secure option. And typically this is what we see used in enterprise spaces WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
more secure option. And typically this is what we see used in enterprise spaces
.
Authentication header was just created as a way to give us an option for
scenarios where number one we probably trust the underlay, but also number two,
we have some devices that just don't have the resources necessary to encrypt
every frame and decrypt every frame, by the way.
And so then we also have transport mode and tunnel mode. So when we're looking
at IPsec, we're going to look at the fact that we have headers and we have the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at IPsec, we're going to look at the fact that we have headers and we have the
payload.
And so as we encapsulate into IPsec, the question is, do we encrypt the payload
only? Because if so, that would be transport mode.
Or do we encapsulate both? If we encapsulate both, this would be tunnel mode.
Well, encapsulating both and encrypting both the header and the payload. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, encapsulating both and encrypting both the header and the payload.
That is typically going to be seen as more secure as well. It should be. And so
tunnel mode is going to be the more secure option.
And so let's make sure we understand the difference in these IPsec options.
Alright, question number seven, and it's actually the last question. I think I
said that there were eight. I thought there were eight, but there's only seven
questions.
So here we go. Map the following message types with either I could be one phase
one or phase two and also identify how many messages are sent for each. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one or phase two and also identify how many messages are sent for each.
So this is a question of just how well do we know I could be one as well as
especially the difference in the phases. So the purpose of phase one is
essentially to establish a control plane tunnel.
This is going to allow us to perform initial communications with the remote
router. And we have two main options here. We can do this in main mode or
aggressive mode.
Main mode is going to require six messages and is considered to be the more WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Main mode is going to require six messages and is considered to be the more
secure option.
Aggressive mode is a whole lot faster. It only uses three messages. But because
it only uses three, it's going to rush things a little bit.
And so it is viewed as a little bit less secure. There's going to be some
identities that are shared in plain text that wouldn't have been shared in
plain text otherwise.
So this is primarily used for scenarios where we just care about speed and we
care about processing and tunnels are getting established and torn down
regularly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
regularly.
But generally speaking, for a more secure option, we'd want to go with main
mode.
So phase two, phase two is all about creating the data plane tunnel, which is
the tunnel that's going to be used for actual traffic.
This is what's referred to as the IPsec tunnel. So our IPsec tunnel will be
carrying our user traffic securely across the underlay.
And as part of phase two, we're just going to use this quick mode option, which
is three messages.
So there's not multiple options within phase two. It's just used to distinguish WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there's not multiple options within phase two. It's just used to distinguish
these messages from the other messages that are in phase one.
So we're either talking about a total of nine messages. If we're using main
mode or six messages, if we're using aggressive mode.
Now, keep in mind as well, even though our focus on this question is like V one
, like V two is going to simplify all of this.
So this is a single option for four messages.
I could be too is certainly the way we want to build our IPsec tunnels these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I could be too is certainly the way we want to build our IPsec tunnels these
days.
But Cisco still expects us to understand how I could be one works because there
's a whole lot of I could be one out in the real world.
So let's make sure we understand how these phases break down with the purpose
of each phases and then even how I could be one compares to I could be two.