Hello. My name is Dean Pompey. Leo. Welcome to Cyber ERY, where we'll be discussing the virtual ization installation configuration in management activities,
and we'll be working on module five. Lesson true
in this lesson will be configuring standard switch policies,
so we'll be covering things like the security options for your switch
policies and Nick teaming capabilities.
So when we think about policies for our switch, we have to remember that these policies get to find at the switch level
or at the port in port Group level. You have some flexibility there.
This means you can define a policy for an entire switch
than anything that gets any of'em zika connected to that switch with Then inherit that policy.
However, you can handle switch with multiple pork groups and have different policies for each of those poor groups. It just depends on your requirements
and what kinds of traffic flows you're trying to control or harden with very security settings.
So starting off with our security policy
when you go to the properties of your of your virtual switch.
When you see that in your networking, there's the properties linked to the upper right of the switch.
We have a couple of settings right off the top that we need to discuss.
The first is promiscuous mode.
So promiscuous mode is putting an adapter.
Ah, virtual or physical into this. And the promiscuous mode means that that adapter Whoa,
process all the packets that it sees on that network segment.
This is useful if you're running an I. D. S
or some kind of protocol analyzer.
If you were interested in
keeping the security of your system as tight as possible, you might not want to allow promiscuous mode to happen.
Therefore, the the default setting is to reject promiscuous mode.
That means that packets
that end up out on this virtual interface will actually get dropped instead of being processed.
You can change promiscuous mode to accept
in the event that you want to use something like an I. D. S or a snipper, or you might do that for troubleshooting purposes.
Ah, the next thing is Mac address changes. The default setting for this is except
this can be a little bit of a security risk as well.
For instance, you might be in an environment where the Mac addresses are expected to remain static and the and they're not expected to change.
For security reasons, that's a that's a good way to operate.
But, however, if I add a new virtual adapter to a switch, our or someone swaps out a physical dapper that's failed,
or you just add a new switch all together. Somewhere in the environment.
New Mac addresses will appear because now you've got new virtual hardware or new physical hardware,
and you need to be able to accommodate that.
So if you want to reject Mac address changes, then you need to
take responsibility for managing Mac address changes in the environment so that you can allow the ones that are new and unexpected.
Otherwise, you might be stuck in a situation where something's not communicating, and it's because yours, which was not allowing the Mac address change to be to be accepted.
So think about that for your security considerations.
The last item is forged transmits
the default setting, for this is except which might seem a little bit strange.
Uh, and that means that anyone who was spoofing an I P address,
for instance, would be able to get their traffic through
for security reasons. You might wantto set this back to reject
instead so that you can keep a tighter control over which systems are allowed to communicate on your network and your virtual network.
So once you set your security policy again, the whole switch inherits it, or it's inherited at the port or even the port group level.
Then we have to think about how we want to shape the traffic.
Traveling, shaping is disabled by default. This is something you have to enable if you want to use it.
And the idea with traffic traffic shaping is that you can prioritize certain traffic over others.
For instance, you might
have a traffic shaping policy for your I P storage network
to allow the greatest use of banned with within some range.
And then maybe you might want to restrict the band with usage by other types of traffic, like
video streaming traffic that's on your regular user network
or possibly your management network might require only a little bit of band with so you can restrict its usage free up bandwith for other users in the environment.
So remember again, this is disabled.
If you do enable it within the properties of the switch. You'll you'll see this when we look at the lab in just a little bit.
We have three different settings to consider.
These are all in killing bits per second.
So the average man with is just what it sounds like. You can limit the average band with through that device
on a kill a bit per second basis,
and that might be important thing to do. For instance, if you had a ah gigabit network
and you had 10 different switches that were utilizing van with, if you wanted to
divide them up evenly, you could say, Well, no switch should be able to use more than 100 megabits each.
That means that even if all switches were running at maximum capacity, you would still be able to satisfy all of those requirements without
affecting the performance of the of any of one switch over another.
So that's one sighting we can consider.
There's also a peaked in with
This means that for some short period of time,
you can allow the band with utilization for that switch to exceed with the average band with setting my Pete.
So if I had a setting of 100 megabits, for instance, for a switch, I could say a peak of 150
and that's expected to only last for a short period of time,
with the assumption that the other switches would not all be fully utilized or you're using their peak band with at the same moment as this one. Particular switch requires it,
so that gives you some ability to kind of find tune. The band, with your relation will further,
and then our last item is the burst size.
So birth sizes, even a shorter duration event
where perhaps you're you're downloading a large file,
and your peak plan with an average band with is not big enough so you can allow for a burst settings, Let's say 200 megabits per second,
two for a short period of time to allow certain events to happen without having too much performance impact on the other
switches in this or the other switches in the environment
on as you do, you make changes to these settings. You might want to do some
ah little bit of trial and error and some experiments to see what settings work best. for your particular environment.
For the purposes of the labs, however, we're going to leave these settings at their default, which is basically disabled.
Okay, so moving on to Nick teeming
will be Team Nick's.
This is a way of grouping
interfaces together so that we can take advantage of various functionality. There's only applies to physical interfaces. If I do teeming with virtual interfaces, that doesn't really buy me anything,
UH, four Virtual Nick's all going through this to physical. Nix
threw the switch right. I have to uplink ports to physical necks,
but if I team some of my virtual nix together, I don't get any more bandwidth, and I would get from the physical mix that are already available to me.
So that's an important concept to think about. The teeming really only applies to your physical next,
so the load balancing and nick teeming environment is outbound on Lee for standard switches.
If you have a distributed switch
which allows it hosts to be connected together through a switch,
then you can use inbound and outbound
load balancing methods. Since we're only using standard
virtual switches for these labs outbound on Lee would apply.
The first thing to consider in this case is network failure detection.
So what happens when
when I've got a problem with my network, someone pulls a cable, Ah, network interface card dies
you know, switch fails. And now I've lost some connection.
I have two options. For for this case, I can monitor link state,
which is the most basic method of detecting a failure.
So if I If you plug a network cable in you, you get a link light that shows you've got a connection. If that cable comes out, the link state is now down
and you never fail. You detection can work with that.
link state monitoring link. State only monitoring is rather limited. It can't detect any failures upstream from the device that had the failure.
If you use link state plus weakening
now the virtual switch will send out a packet every second
to determine whether other switches that are connected to this virtual switch within that network are alive and well.
So this gives ah more accurate detection of changes in the network topology.
That a very small expense of a tiny bit of overhead for sending out that packet every second. It's only 62 bites, I believe so. It's very small amount.
So in most cases you would want to use links Day plus, beginning to get a better representation of failures in your network.
The next option to think about for Nick Teeny has notify. Switch is just what it sounds like
if there's a change in the network topology. If I lose a connection to my neighboring switch or to a neighboring
selection of switches,
I want to be able to detect that, of course, using one of these two methods.
So this detects failures or new connections.
And when a new connection happens in your in your network topology, or if a failure happens,
all of the switches need to notify each other
in order to remap that networked apology to show what the new available physical paths are.
So if I lose a connection, I want to be able to notify switches in my general area that I'm connected to. Hey, this link is down.
Reorganize your mapping tables to take advantage of the existing links,
and various vendors do this in different ways. Cisco devices do it slightly different than a D link fight device would do, and so on