Lesson 2 Part 2 - Configuring Standard Switch Policies (continued)
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 *
Already have an account? Sign In »
14 hours 13 minutes
Lesson 2 part 2 Configuring Standard Switch Policies (continued) This lesson continues configuration standard switch polices and focuses on:
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.
then I have to think about fail back. This decides what happens with the physical adapter. In the event of a failure,
you can set fail back to be automatic,
which means that if I
of someone unplug the cable,
my link state goes down. I might notify the switches that now that link is is no longer available.
Someone realizes that they've accidentally unplugged the wrong cable. They plug it back in.
If it failed back is such automatic
that everything will revert back to the way it was before the failure happened.
In most cases, that's probably what you want.
However, there might be a case where you're doing some testing or you're doing some
configuration changes to your network, so you might want to set sail back to manual.
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.
That's more useful when you're doing a PSA testing or troubleshooting
and then related to fail back is the fail over order
as you'll see when you look at the virtual switch configuration.
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.
So if I only had two adapters
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,
you can control that. Fail over order so that you can
use the manual load balancing in the event of failures if you don't want to use some of the automatic option.
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.
Then we move on to our load balancing methods.
Load balancing is a way to manage the traffic from virtual machines through virtual switches,
using your available physical nix
through the physical switch getting to your different servers.
So the simplest method
is the, uh originating virtual port I D.
So that means that
a virtual machine.
Let's say, uh,
I'll call these.
I am one
So, in this case, VM one wants to communicate with Server three.
So being one initiates its connection request
and when it hits virtual tze the virtual switch here it comes in on virtual Port. Idea of one.
And let's say we'll call this one virtual port idea of two and three.
So it goes in our virtual port idea of one, and the virtual 4 90 of one might map
to nick zero
so we can do a one,
two and three like this.
So nick zero. Then we'll go to the physical switch.
Maybe it goes on Port 12 and three on the physical switch as well.
In the physicals, which has connections to can't have two number ones,
hold on one second.
56 and seven.
again. So virtually she one month's communicate with
It arrives on Port one of the virtual switch
virtual switch. Also,
same problem here. Sorry about that
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.
That that traffic goes to port one of the physical switch
and the physical switch knows that. Server three
He's on Port six.
So routes the traffic.
So this seems really easy to understand, really, Is it? Use. The problem is,
every time VM one wants to connect the server three, it will use the same exact ports
because of the way that the low balancing tries to map it.
If I am too
wants to connect to server one,
it comes in on poor too.
It might get map to port five to use Nick number one
and the physical switch,
uh, inbound on poor too,
and outbound on port five.
So every time bm to wants to communicate with server to it will use these same ports.
So this this is, ah, reasonable way to spread out your traffic.
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.
So well, that's what we say. It's a map to a specific nick.
Did you get a reasonable performance? However, because the VM Colonel port on the virtual switch here
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
ah connection attempt. And then that mapping is basically maintained
until that BM gets powered off
or the host gets rebooted or something. That nature.
Our second method is to use a source Mac hash.
So each of these virtual machines has a different source. I p address.
You know, this one could be 10.10.
I'm I give a network,
so that's the source. Address gets hashed. Each hashing of these different source of peas peas gives a different value. So that different
hash value indicates that a different physical nick should be chosen.
So when I hash,
you know, 1 92
1 68 1 68 not 10.
That might hash to Nick number two.
So, Doc 10 is actually here
when I hashtag 20. That might map too
zero and then not 30.
Would Matt to nick one?
It's basically a way of just generating a, uh,
a different choice for each source address.
So this is this is very compatible with physical switches. Physical switch doesn't really care
which which of the Knicks on the host is communicating with it so much. It does its own internal mapping
to say that if
0.10 months to communicate with Server four,
it's going to
come out of the virtual switch on Nick to into the physicals, which on Port three and then back out in Port seven.
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.
20 is always gonna hash to Nick zero
so we don't get a lot of dynamic behavior here.
The best method from a traffic distribution perspective is to use the I p. Ash.
So now we take the source and destination addresses into effect.
So my servers are 0.40 50 60 and 70
and then I have my sources of 0.10 2030.
So if if 0.20 wants to communicate with 0.40
uh, or the
the switch will say OK, I'm going to hash the source address, has the the destination address
and pick my adapters based on that
So if I want to use it well, use different color here. So 0.20 wants to communicate with Di 40.
It goes into the switch on poor, too.
The switch decides that
it wants to use
Nick number two for that traffic,
and then the physical switch will route that traffic when it comes through.
However, if Doc 20 wants to communicate with that 60
it's still going to use the same input port on the virtual switch.
But now, because of the destination is a little bit different. It might pick Nick number one for this traffic
because the hashing changed the values of which which physical nick it's chosen here
and which relative to the source of destination addresses.
this is the best way to utilize all of your available nick cards
because every time you're you're VM has a different destination address, it should be using a different physical neck.
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.
If you do this method. You also have to think about the physical switch.
This must support 802 not three A. D link aggregation
Because the physical switch needs to know that these three links
are these three Knicks that are effectively links
might be aggregated together to provide this kind of functionality from the virtual switch communication.
Okay, so we talked about our
We know we could pick the different
actions to take for promiscuous mode. Mac address changes and forth transmits.
We looked at our different traffic shaping policy possibilities as faras, specifying the amount of bandwidth
recovered. How to do that, Nik teeming, and some of the settings there to control how your adaptors and your switch behaves.
And then we discussed different low bouncing methods
and which ones of those might be better suited for certain kinds of environments.
All right, that concludes Lesson two for module five. Thank you.