Lesson 2 Part 2 - Configuring Standard Switch Policies (continued)
Video Activity
Lesson 2 part 2 Configuring Standard Switch Policies (continued) This lesson continues configuration standard switch polices and focuses on: Fail back Fail over order Load Balancing methods Participants in this lesson learn step by step instructions in a lab-based lesson on how to configure standard switch policies.
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
Lesson 2 part 2 Configuring Standard Switch Policies (continued) This lesson continues configuration standard switch polices and focuses on:
-
Fail back
-
Fail over order
-
Load Balancing methods
Participants in this lesson learn step by step instructions in a lab-based lesson on how to configure standard switch policies.
Video Transcription
00:04
then I have to think about fail back. This decides what happens with the physical adapter. In the event of a failure,
00:11
you can set fail back to be automatic,
00:14
which means that if I
00:16
of someone unplug the cable,
00:18
my link state goes down. I might notify the switches that now that link is is no longer available.
00:25
Someone realizes that they've accidentally unplugged the wrong cable. They plug it back in.
00:29
If it failed back is such automatic
00:31
that everything will revert back to the way it was before the failure happened.
00:36
In most cases, that's probably what you want.
00:39
However, there might be a case where you're doing some testing or you're doing some
00:43
configuration changes to your network, so you might want to set sail back to manual.
00:49
So if I unplug it a connection, I failed to another adapter. That's in my list of available adapters and the fail over stays that way until I manually switch it back to its original configuration.
01:00
That's more useful when you're doing a PSA testing or troubleshooting
01:06
and then related to fail back is the fail over order
01:08
as you'll see when you look at the virtual switch configuration.
01:12
You've got various physical adapters that are connected to the switch I can control. The the order of those adaptors with one of the top of the list has highest priority. The 2nd 1 is second highest priority so long.
01:26
So if I only had two adapters
01:27
adapter zeroes here it after one is here. If I have a fail over, those two will switch now and after one becomes the primary and after zero becomes secondary because it's failed or unavailable. For some reason,
01:40
you can control that. Fail over order so that you can
01:44
use the manual load balancing in the event of failures if you don't want to use some of the automatic option.
01:51
So all in all, there's a lot of good choices here to control the way your switch behaves the way your network adapters behave when failures occur in the environment.
02:01
Then we move on to our load balancing methods.
02:06
Load balancing is a way to manage the traffic from virtual machines through virtual switches,
02:13
using your available physical nix
02:15
through the physical switch getting to your different servers.
02:20
So the simplest method
02:23
is the, uh originating virtual port I D.
02:27
So that means that
02:29
a
02:30
a virtual machine.
02:32
Let's say, uh,
02:34
I'll call these.
02:37
I am one
02:38
23
02:44
So, in this case, VM one wants to communicate with Server three.
02:50
So being one initiates its connection request
02:53
and when it hits virtual tze the virtual switch here it comes in on virtual Port. Idea of one.
03:02
And let's say we'll call this one virtual port idea of two and three.
03:09
So it goes in our virtual port idea of one, and the virtual 4 90 of one might map
03:16
to nick zero
03:21
so we can do a one,
03:23
two and three like this.
03:28
So nick zero. Then we'll go to the physical switch.
03:32
Maybe it goes on Port 12 and three on the physical switch as well.
03:44
In the physicals, which has connections to can't have two number ones,
03:50
hold on one second.
03:53
123
03:54
for
03:55
56 and seven.
03:58
Okay,
04:00
again. So virtually she one month's communicate with
04:03
Server three.
04:06
It arrives on Port one of the virtual switch
04:10
virtual switch. Also,
04:13
same problem here. Sorry about that
04:21
virtual switch says I want to send this traffic out on Nick zero because that's the mapping that I've designated for outbound traffic on Port One.
04:32
That that traffic goes to port one of the physical switch
04:35
and the physical switch knows that. Server three
04:39
He's on Port six.
04:41
So routes the traffic.
04:44
So this seems really easy to understand, really, Is it? Use. The problem is,
04:47
every time VM one wants to connect the server three, it will use the same exact ports
04:53
because of the way that the low balancing tries to map it.
04:57
If I am too
04:59
wants to connect to server one,
05:03
it comes in on poor too.
05:06
It might get map to port five to use Nick number one
05:15
and the physical switch,
05:16
uh, inbound on poor too,
05:19
and outbound on port five.
05:24
So every time bm to wants to communicate with server to it will use these same ports.
05:30
So this this is, ah, reasonable way to spread out your traffic.
05:32
Well, what it doesn't do is allow the PM's to communicate on different ports of the virtual switch or the physical switch or the physical. Next, they use the same one every time.
05:45
So well, that's what we say. It's a map to a specific nick.
05:48
Did you get a reasonable performance? However, because the VM Colonel port on the virtual switch here
05:55
doesn't need to look at every every packet to see the source and destination address is it sets up the mapping from the first
06:00
ah connection attempt. And then that mapping is basically maintained
06:05
until that BM gets powered off
06:08
or the host gets rebooted or something. That nature.
06:12
Our second method is to use a source Mac hash.
06:15
So each of these virtual machines has a different source. I p address.
06:20
You know, this one could be 10.10.
06:24
Got
06:26
got 20
06:27
and 30.
06:29
I'm I give a network,
06:31
so that's the source. Address gets hashed. Each hashing of these different source of peas peas gives a different value. So that different
06:41
hash value indicates that a different physical nick should be chosen.
06:46
So when I hash,
06:47
uh,
06:48
you know, 1 92
06:53
1 68 1 68 not 10.
06:57
That might hash to Nick number two.
07:00
So, Doc 10 is actually here
07:01
when I hashtag 20. That might map too
07:05
zero and then not 30.
07:09
Would Matt to nick one?
07:11
It's basically a way of just generating a, uh,
07:15
a different choice for each source address.
07:18
So this is this is very compatible with physical switches. Physical switch doesn't really care
07:24
which which of the Knicks on the host is communicating with it so much. It does its own internal mapping
07:30
to say that if
07:31
0.10 months to communicate with Server four,
07:34
it's going to
07:36
come out of the virtual switch on Nick to into the physicals, which on Port three and then back out in Port seven.
07:45
However, much like the first method, this doesn't utilize the physical mix very well because 0.10 is always gonna hash to Nick, too.
07:55
20 is always gonna hash to Nick zero
07:58
so we don't get a lot of dynamic behavior here.
08:03
The best method from a traffic distribution perspective is to use the I p. Ash.
08:09
So now we take the source and destination addresses into effect.
08:20
So my servers are 0.40 50 60 and 70
08:24
and then I have my sources of 0.10 2030.
08:28
So if if 0.20 wants to communicate with 0.40
08:33
my,
08:33
uh, or the
08:35
the switch will say OK, I'm going to hash the source address, has the the destination address
08:43
and pick my adapters based on that
08:46
information.
08:48
So if I want to use it well, use different color here. So 0.20 wants to communicate with Di 40.
08:54
It goes into the switch on poor, too.
08:58
The switch decides that
09:00
it wants to use
09:03
Nick number two for that traffic,
09:11
and then the physical switch will route that traffic when it comes through.
09:15
However, if Doc 20 wants to communicate with that 60
09:18
it's still going to use the same input port on the virtual switch.
09:22
But now, because of the destination is a little bit different. It might pick Nick number one for this traffic
09:35
because the hashing changed the values of which which physical nick it's chosen here
09:41
and which relative to the source of destination addresses.
09:46
So
09:48
this is the best way to utilize all of your available nick cards
09:52
because every time you're you're VM has a different destination address, it should be using a different physical neck.
10:00
There is some CP overhead, of course, because now every pack it needs to be inspected to see what the source and destination I P addresses are. So the switch can figure out which physical nick to map, too.
10:11
If you do this method. You also have to think about the physical switch.
10:16
This must support 802 not three A. D link aggregation
10:22
Because the physical switch needs to know that these three links
10:26
are these three Knicks that are effectively links
10:28
might be aggregated together to provide this kind of functionality from the virtual switch communication.
10:35
Okay, so we talked about our
10:39
security policies.
10:41
We know we could pick the different
10:45
actions to take for promiscuous mode. Mac address changes and forth transmits.
10:48
We looked at our different traffic shaping policy possibilities as faras, specifying the amount of bandwidth
10:54
recovered. How to do that, Nik teeming, and some of the settings there to control how your adaptors and your switch behaves.
11:03
And then we discussed different low bouncing methods
11:07
and which ones of those might be better suited for certain kinds of environments.
11:13
All right, that concludes Lesson two for module five. Thank you.
Up Next
Similar Content
